From 6e884ac9855da9cb76f9dc01002a4bb1c98671f2 Mon Sep 17 00:00:00 2001
From: GitHub Action اصطلاح "Eth2" معمولا برای توصیف آینده اتریوم قبل از تغییر به اثبات سهام استفاده میشد، اما در راستای اصطلاحات دقیقتر حذف شد. در ابتدا برای متمایز کردن شبکه اتریوم قبل از تغییر به اثبات سهام و شبکه بعد از آن استفاده می شد، یا گاهی اوقات برای اشاره به کاربرهای مختلف اتریوم (کلاینتهای اجرا) به نام کاربرهای ETH1 شناخته میشدند و کاربرهای اجماع گاهی اوقات به عنوان کاربرهای ETH2 شناخته می شدند.
+اکنون به جای اعداد 1 تا 12، تصور کنید ساعت دارای اعداد 0 تا N داشته باشد ( تا ژانویه 2023 تعداد کل حساب های اعتبارسنج که تا کنون در لایه اجماع ثبت شده اند، بیش از 500،000 بوده است).
+عقربه روی ساعت به اعتبارسنج بعدی اشاره میکند که باید برای برداشتهای واجد شرایط بررسی شود. این روند از عدد 0 شروع میشود، و بدون پریدن و رد شدن از هر حساب تا آخر پیش میرود. وقتی که به آخرین اعتبارسنج دست یافت، چرخه پیوسته به آغاز مسیر باز میگردد.
+
نحوه استفاده اینجاست.
+
+
+
+
+
+
+
+5. بسیاری از دارایی ها، مانند Dai یا USDC، روی چندین شبکه وجود دارند. هنگام انتقال توکن های کریپتو، مطمئن شوید که گیرنده از همان شبکه شما استفاده می کند، زیرا آنها قابل معاوضه نیستند.
+6. مطمئن شوید که کیف پول شما ETH کافی برای پوشش دادن کارمزد تراکنش، که بسته به شرایط شبکه متفاوت است، دارد. اکثر کیف پول ها به صورت خودکار کارمزد پیشنهادی را به تراکنش اضافه می کنند که سپس می توانید آن را تایید کنید.
+7. هنگامی که تراکنش شما پردازش شد، مقدار کریپتو مربوطه در حساب گیرنده نشان داده می شود. بسته به مقدار استفاده شده از شبکه در آن لحظه، این عمل ممکن است از چند ثانیه تا چند دقیقه طول بکشد.
+
+## وصل شدن به پروژه ها
+
+آدرس شما در تمام پروژه های اتریوم یکسان خواهد بود. شما نیاز به ثبت نام جداگانه در هیچ پروژه ای ندارید. هنگامی که کیف پول دارید، بدون هیچ اطلاعات اضافی می توانید به هر پروژه اتریوم متصل شوید. هیچ ایمیل یا اطلاعات شخصی دیگری نیاز نیست.
+
+1. از وبسایت هر پروژه بازدید کنید.
+2. اگر صفحه آعازین وبسایت یک پروژه فقط یک توصیف ثابت از پروژه است، باید بتوانید در منو روی دکمه "بازکردن اپلیکیشن" کلیک کنید، که شما را به اپلیکیشن وب واقعی هدایت می کند.
+3. وارد برنامه که شدید روی "Connect" کلیک کنید.
+
+![دکمه ای که به کاربر اجازه می دهد با یک کیف پول به وبسایت متصل شود](./connect1.png)
+
+4. کیف پول خود را از بین لیست گزینه های ارائه شده انتخاب کنید. اگر نمی توانید کیف پول خود را ببینید، ممکن است در زیر گزینه "WalletConnect" پنهان شده باشد.
+
+![انتخاب از لیست کیف پول ها برای اتصال](./connect2.png)
+
+5. برای برقرار کردن اتصال، درخواست امضا را در کیف پول خود تایید کنید. **برای امضای این پیام، نباید به پرداخت هیچ ETH نیاز باشد**.
+6. همین! استفاده از اپلیکیشن را شروع کنید. در [صفحه برنامه های غیرمتمرکز](/dapps/#explore) می توانید پروژه های جالبی را پیدا کنید.
+
+ETH2 چه بود؟
+
+
+
+
+برای اطلاعات بیشتر، این پست وبلاگی از Tim Beiko را در مورد چگونگی تأثیر «ادغام» بر لایۀ برنامۀ اتریوم بررسی کنید.
+
+
حدود 88/7 درصد از صدوری که در لایۀ اجرا به استخراجگرها تعلق میگرفت (4/09 / 4/61 * 100)
میزان 11/3 درصد برای سهامگذاران در لایۀ اجماع صادر میشد ( 0/52 / 4/61 * 100)
+
کاهش خالص در صدور سالانه:حدود88/7 درصد((4/61% - 0/52%) / 4/61% * 100)
+
+
+UserOperation
ساخته شده است که اقدامات یک کاربر را همراه با امضاهای مربوطه بستهبندی میکند. این اشیاء UserOperation
سپس در یک «استخر حافظه» اختصاصی پخش میشوند و در آنجا، اعتبارسنجها میتوانند آنها را در یک «تراکنش بسته» جمعآوری کنند. تراکنش باندل نشاندهنده دنبالهای از بسیاری از عملیات UserOperations
است و میتواند مانند یک تراکنش عادی در بلوکهای اتریوم گنجانده شود و توسط اعتبارسنجها با استفاده از یک مدل مشابه برای انتخاب حداکثرسازی هزینه انتخاب میشود.
+
+نحوه کار کیف پولها نیز تحت EIP-4337 تغییر میکند. به جای اینکه هر کیف پولی منطق ایمنی رایج اما پیچیده را مجدداً پیادهسازی کند، این عملکردها به یک قرارداد کیف پول جهانی بهنام "نقطه ورود" برونسپاری میشوند. این کار عملیاتی مانند پرداخت هزینه و اجرای کد EVM را انجام میدهد تا توسعهدهندگان کیف پول بتوانند بر ارائه تجربیات عالی برای کاربر تمرکز کنند.
+
+توجه داشته باشید که قرارداد نقطه ورودی EIP 4337 در تاریخ 1 مارس 2023 در «شبکه اصلی اتریوم» بکار گرفته شد. میتوانید قرارداد را در Etherscan مشاهده کنید.
+
+AA_TX_TYPE
است که شامل سه فیلد روبرو میشود: nonce
، هدف
و دادهها
، که در آن nonce
یک شمارنده تراکنش است، هدف
آدرس قرارداد نقطه ورودی و دادهها
بایتکد EVM است. برای اجرای این تراکنشها، دو دستورالعمل جدید (معروف به کدهای عملیاتی) باید به EVM اضافه شوند: NONCE
و PAYGAS
. کد عملیاتی NONCE
دنباله تراکنش را دنبال میکند و PAYGAS
گس مورد نیاز برای اجرای تراکنش را از موجودی قرارداد محاسبه و برداشت میکند. این ویژگیهای جدید به اتریوم اجازه میدهد تا از کیف پولهای قرارداد هوشمند بهصورت بومی پشتیبانی کند، زیرا زیرساختهای لازم در پروتکل اتریوم تعبیه شده است.
+
+توجه داشته باشید که EIP-2938 درحال حاضر فعال نیست. جامعه درحال حاضر از EIP-4337 استقبال میکند زیرا نیازی به تغییر در پروتکل ندارد.
+
+AUTH
و AUTHCALL
. با EIP-3074، مزایای کیف پول قرارداد هوشمند بدون نیاز به قرارداد در دسترس قرار میگیرد - در عوض، یک نوع خاص از قراردادِ بدون حالت، غیرقابل اعتماد و غیرقابل ارتقا، معروف به «Invoker»، تراکنشها را مدیریت میکند.
+
+توجه داشته باشید که EIP-3074 درحال حاضر فعال نیست. جامعه درحال حاضر از EIP-4337 استقبال میکند زیرا نیازی به تغییر در پروتکل ندارد.
+
+
gas, addr, val, argOst, argLen, retOst, retLen
| `success` | mem[retOst:retOst+retLen-1] := returndata | |
+| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
+| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] |
+| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
+| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
+| F6-F9 | _invalid_ | | | | | |
+| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
+| FB-FC | _invalid_ | | | | | |
+| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
+| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
+| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract |
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md
new file mode 100644
index 00000000000..df39471d21f
--- /dev/null
+++ b/public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md
@@ -0,0 +1,139 @@
+---
+title: گس و کارمزدها
+description:
+lang: fa
+---
+
+گاز برای شبکهی اتریوم حیاتی است. سوختی است که به شبکه امکان کار کردن میدهد، همانطور که یک اتومبیل نیاز به بنزین دارد.
+
+## پیشنیازها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه میشود که ابتدا [تراکنشها](/developers/docs/transactions/) و [ماشین مجازی اتریوم](/developers/docs/evm/) را مطالعه کنید.
+
+## گاز چیست؟ {#what-is-gas}
+
+گاز به واحدی گفته میشود که میزان زحمت محاسباتی موردنیاز را برای اجرای یک عمل خاص در شبکهی اتریوم اندازهگیری میکند.
+
+از آنجا که هر تراکنش اتریوم برای اجرا به منابع محاسباتی نیاز دارد، این منابع باید پرداخت شوند تا اطمینان حاصل شود که اتریوم در برابر اسپم آسیب پذیر نیست و نمی تواند در حلقه های محاسباتی نامحدود گیر کند. پرداخت برای محاسبه به شکل کارمزد گاز انجام می شود.
+
+کارمزد گاز **مقدار گازی است که برای انجام عملیات استفاده می شود، ضربدر هزینه هر واحد گاز**. کارمزد صرف نظر از موفقیت یا شکست یک تراکنش پرداخت می شود.
+
+![نموداری که نشان میدهد کجا گاز در عملیاتهای EVM مورد نیاز است](./gas.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+کارمزد گاز باید با ارز بومی اتریوم یعنی اتر (ETH) پرداخت شود. قیمت گاز معمولا برحسب Gwei، که یکی از شاخه های ETH است، بیان می شود. هر Gwei برابر با یک میلیاردم ETH است (0.000000001 ETH یا 10-9 ETH).
+
+برای مثال به جای این که بگوییم گاز 0.000000001 اتر است، میتوانید بگویید گاز به انداره 1 gwei است.
+
+کلمه 'Gwei' مخفف 'Giga-wei' است که به معنای 'میلیارد wei' است. یک Gwei برابر یک میلیارد wei است. Wei (نامگذاری شده از [wei Dai](https://wikipedia.org/wiki/Wei_Dai) سازنده [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) خود کوچکترین واحد اتر است.
+
+## چگونه کارمزدهای گاز محاسبه می شوند؟ {#how-are-gas-fees-calculated}
+
+می توانید مقدار گازی را که مایل به پرداخت آن هستید در هنگام ارائه یک تراکنش تنظیم کنید. با پیشنهاد مقدار مشخصی گاز، پیشنهاد می کنید که تراکنش شما در بلاک بعدی قرار گیرد. اگر مبلغ بسیار کمی پیشنهاد دهید، اعتبارسنج ها احتمال کمتری دارند که تراکنش شما را برای ورود انتخاب کنند، به این معنی که ممکن است تراکنش شما دیر انجام شود یا اصلا انجام نشود. اگر بیش از حد پیشنهاد دهید، ممکن است مقداری ETH را هدر دهید. بنابراین، چگونه می توانید بگویید که چقدر باید پرداخت کنید؟
+
+مجموع گاز که پرداخت می کنید به دو بخش تقسیم می شود: `کارمزد پایه` و `کارمزد اولویت` (انعام).
+
+`کارمزد پایه` توسط پروتکل تعیین می شود - شما باید حداقل این مبلغ را پرداخت کنید تا تراکنش شما معتبر تلقی شود. `کارمزد اولویت` انعامی است که شما به کارمزد پایه اضافه می کنید تا تراکنش شما برای اعتبارسنجان جذاب شود تا آنها آن را برای ورود به بلاک بعدی انتخاب کنند.
+
+تراکنشی که تنها `کارمزد پایه` را پرداخت می کند، از نظر فنی معتبر است اما احتمال شامل شدن آن بعید به نظر می رسد زیرا هیچ انگیزه ای برای اعتبارسنجان وجود ندارد که آن را نسبت به تراکنش های دیگر انتخاب کنند. کارمزد `اولویت` "صحیح" با استفاده از شبکه در زمانی که تراکنش خود را ارسال می کنید تعیین می شود - اگر تقاضای زیادی وجود داشته باشد، ممکن است مجبور شوید کارمزد `اولویت` خود را بالاتر تنظیم کنید، اما وقتی تقاضای کمتری وجود داشته باشد، می توانید هزینه کمتری پرداخت کنید.
+
+برای مثال، فرض کنید جردن باید 1 ETH به تیلور بپردازد. یک انتقال ETH به 21000 واحد گاز نیاز دارد و هزینه پایه 10 Gwei است. جردن 2 gwei را بهعنوان انعام اضافه میکند.
+
+حال هزینه کل برابر است با:
+
+`واحدهای گاز مصرفی * (کارمزد پایه + کارمزد اولویت)`
+
+که در آن `کارمزد پایه` مقداری است که توسط پروتکل تعیین می شود و `کارمزد اولویت` مقداری است که توسط کاربر به عنوان انعام به اعتبارسنج تعیین می شود.
+
+یعنی `21,000 * (10 + 2) = 252,000 Gwei` (یا 0.000252 ETH).
+
+زمانی که جردن پول را میفرستد، 1.000252 اتر از حساب جردن کم میشود. تیلور 1.0000 اتر دریافت میکند. اعتبارسنج انعام 0.000042 ETH را دریافت می کند. `هزینه پایه` به مقدار 0.00021 ETH سوزانده می شود.
+
+### کارمزد پایه {#base-fee}
+
+هر بلوک یک کارمزد پایه دارد که بهعنوان قیمت ذخیره عمل میکند. جهت احراز شرایط برای گنجانده شدن در بلوک، قیمت ارائه شده برای گاز باید حداقل به اندازه کارمزد پایه باشد. کارمزد پایه بهطور مستقل از این بلوک محاسبه میشود و توسط بلوکهای قبلی مشخص میشود - که باعث میشود کارمزدهای تراکنش برای کاربران پیشبینیپذیرتر باشند. هنگامی که بلوک ایجاد می شود این **هزینه پایه "سوزانده" می شود** و از گردش خارج می شود.
+
+کارمزد پایه توسط فرمولی که اندازه بلوک قبلی (مقدار گازی که توسط تمام تراکنشها استفاده میشود) را با اندازه هدف مقایسه میکند، محاسبه میشود. اگر اندازه بلوک از اندازه هدف بلوک بیشتر شود، کارمزد پایه حداکثر به اندازه 12.5% در هر بلوک افزایش مییابد. این رشد نمایی باعث میشود که از نظر اقتصادی بهصرفه نباشد که اندازه بلوک تا ابد بالا بماند.
+
+| شمارهی بلوک | گاز لحاظشده | افزایش کارمزد | کارمزد پایهی فعلی |
+| ------------ | ------------:| -------------:| ------------------:|
+| 1 | 15 میلیون | 0% | 100 gwei |
+| 2 | 30 میلیون | 0% | 100 gwei |
+| 3 | 30 میلیون | 12.5% | 112.5 gwei |
+| 4 | 30 میلیون | 12.5% | 126.6 gwei |
+| 5 | 30 میلیون | 12.5% | 142.4 gwei |
+| 6 | 30 میلیون | 12.5% | 160.2 gwei |
+| 7 | 30 میلیون | 12.5% | 180.2 gwei |
+| 8 | 30 میلیون | 12.5% | 202.7 gwei |
+
+با توجه به جدول فوق - برای ثبت یک تراکنش در بلوک شماره 9 یک کیف پول به کاربر اجازه میدهد که با قطعیت بداند که **حداکثر کارمزد پایه** که به بلوک بعدی اضافه میشود برابر با `کارمزد پایه فعلی * 112.5%` یا `202.7 gwei * 112.5% = 228.1 gwei` خواهد بود.
+
+همچنین باید خاطرنشان کرد احتمال اینکه بلوکهای پر ادامه پیدا کنند، به دلیل سرعت بالا رفتن کارمزد پایه قبل از یک بلوک پر، کم است.
+
+| شمارهی بلوک | گاز لحاظشده | افزایش کارمزد | کارمزد پایهی فعلی |
+| ------------ | ------------:| -------------:| ------------------:|
+| 30 | 30 میلیون | 12.5% | 2705.6 gwei |
+| ... | ... | 12.5% | ... |
+| 50 | 30 میلیون | 12.5% | 28531.3 gwei |
+| ... | ... | 12.5% | ... |
+| 100 | 30 میلیون | 12.5% | 10302608.6 gwei |
+
+### کارمزد اولویت (انعام) {#priority-fee}
+
+کارمزد اولویت (انعام) اعتبارسنجان را تشویق می کند تا یک تراکنش را در بلوک بگنجانند. بدون انعام، برای اعتبارسنجان از نظر اقتصادی به صرفه است که بلوکهای خالی را استخراج کنند چرا که همان میزان پاداش بلوک را دریافت میکنند. انعام های کم به اعتبارسنجان انگیزه حداقلی برای گنجاندن یک تراکنش می دهند. برای این که تراکنشها ترجیحاً زودتر از بقیه تراکنشها در بلوک یکسان گنجانده شوند، انعام بیشتری می تواند اضافه شود تا از تراکنش های رقیب پیشی بگیرند.
+
+### حداکثر کارمزد {#maxfee}
+
+برای اجرای یک تراکنش در شبکه، کاربران میتوانند برای پرداخت کارمزد تراکنششان سقف مشخص کنند. این پارامتر دلخواه به نام `maxFeePerGas` شناخته میشود. برای اجرای یک تراکنش، حداکثر کارمزد باید از مجموع کارمزد پایه و انعام بیشتر باشد. فرستنده تراکنش تفاضل حداکثر کارمزد و مجموع کارمزد پایه و انعام را بازپس خواهد گرفت.
+
+### اندازه بلوک {#block-size}
+
+هر بلوک اندازه هدفی به اندازه 15 میلیون گاز دارد اما سایز بلوکها میتواند بسته به تقاضای شبکه بیشتر یا کمتر شود و بیشترین حد آن 30 میلیون گاز است (2 برابر اندازه بلوک). پروتکل از طریق فرایند _tâtonnement_ بهطور میانگین به اندازه بلوک متوازن 15 میلیون دست مییابد. این بدین معنا است که اگر اندازه بلوک از اندازه هدف بلوک بیشتر باشد، پروتکل کارمزد پایه را برای بلوک بعدی بیشتر میکند. به صورتی مشابه، پروتکل زمانی که اندازه بلوک از اندازه هدف بلوک کمتر باشد کارمزد پایه را کاهش میدهد. مقداری که کارمزد پایه با آن تنظیم میشود بستگی به فاصله اندازه بلوک از اندازه هدف دارد. [اطلاعات بیشتر درباره بلوکها](/developers/docs/blocks/).
+
+### محاسبه کارمزدهای گاز در عمل {#calculating-fees-in-practice}
+
+می توانید به صراحت اعلام کنید که برای اجرای تراکنش خود حاضر به پرداخت چه مبلغی هستید. با این حال، اکثر ارائه دهندگان کیف پول به طور خودکار کارمزد تراکنش پیشنهادی (کارمزد پایه + کارمزد اولویت توصیه شده) را تنظیم خواهند کرد تا میزان پیچیدگی تحمیل شده بر کاربران خود را کاهش دهند.
+
+## چرا کارمزد گاز وجود دارد؟ {#why-do-gas-fees-exist}
+
+به طور خلاصه، کارمزد گاز به حفظ امنیت شبکه اتریوم کمک میکند. با درخواست کارمزد برای اجرای هر محاسبه روی شبکه، ما از اسپم کردن شبکه توسط خرابکاران جلوگیری میکنیم. برای جلوگیری از حلقههای بینهایت خواسته یا ناخواسته یا دیگر هدررفتهای محاسباتی در کد، هر تراکنش لازم است مشخص کند که چند گام محاسباتی از اجرای کد را میتواند استفاده کند. واحد محاسباتی پایه «گاز» است.
+
+هر چند که تراکنش حدی دارد، اما گاز استفاده نشده در یک تراکنش به کاربر بازگردانده میشود (یعنی `حداکثر کارمزد - (کارمزد پایه + انعام)` برگردانده میشود).
+
+![شکلی نشاندهندهی نحوهی بازپرداخت گاز مصرفنشده](../transactions/gas-tx.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+## حد گاز چیست؟ {#what-is-gas-limit}
+
+حد گاز به حداکثر میزان گازی که میخواهید برای یک تراکنش مصرف کنید گفته میشود. تراکنشهای پیچیدهتر شامل [قراردادهای هوشمند](/developers/docs/smart-contracts/) نیاز به کار محاسباتی بیشتر دارند، در نتیجه نسبت به یک پرداخت ساده نیاز به حد گاز بالاتری دارند. یک انتقال استاندارد اتر نیاز به حد گازی برابر با 21,0000 واحد گاز دارد.
+
+برای مثال اگر حد گاز را برای یک انتقال ساده اتر برابر با 50,000 قرار دهید، ماشین مجازی اتریوم 21,000 عدد را مصرف کرده و شما 29,000 عدد مانده را پس میگیرید. هر چند، اگر گاز بسیار پایینی مشخص کنید، برای مثال حد گاز برابر 20,000 برای یک انتقال ساده اتر، ماشین مجازی اتریوم همه 20,000 واحد گاز را مصرف میکند تا تراکنش را انجام دهد اما تراکنش کامل نخواهد شد. ماشین مجازی اتریوم همه تغییرات را برمیگرداند اما از آنجا که اعتبارسنج به اندازه 20,000 واحد گاز کار کرده است، آن گاز مصرف میشود.
+
+## چرا کارمزد گاز میتواند انقدر زیاد شود؟ {#why-can-gas-fees-get-so-high}
+
+بالا بودن کارمزد گاز به دلیل محبوبیت اتریوم است. اگر تقاضای بیش از حد وجود داشته باشد، کاربران باید انعام بیشتری بدهند تا تلاش کنند از تراکنشهای دیگر کاربران جلو بیفتند. انعام بیشتر میتواند باعث شود احتمال اینکه تراکنش در بلوک بعدی ثبت شود بیشتر شود. همچنین، اپلیکیشن های پیچیدهتر قرارداد هوشمند ممکن است عملیات زیادی برای پشتیبانی از عملکردهای خود انجام دهند و باعث شوند آن ها گاز زیادی مصرف کنند.
+
+## ابتکارها برای کاهش هزینههای گاز {#initiatives-to-reduce-gas-costs}
+
+[ارتقاهای مقیاسپذیری](/roadmap/) اتریوم در نهایت باید به برخی از مسائل مربوط به کارمزد گاز رسیدگی کند، که به نوبه خود، پلتفرم را قادر میسازد تا هزاران تراکنش را در ثانیه پردازش کند و در سطح جهانی مقیاسپذیر شود.
+
+مقیاسپذیری لایه 2 یک ابتکار اولیه برای بهبود هزینه گاز، تجربه کاربری و مقیاسپذیری است. [اطلاعات بیشتر درباره مقیاسپذیری لایه 2](/developers/docs/scaling/#layer-2-scaling).
+
+## نظارت بر کارمزدهای گس {#monitoring-gas-fees}
+
+اگر میخواهید قیمت گاز را رصد کنید، تا بتوانید اترتان را با هزینه کمتری بفرستید، میتوانید از ابزارهای متفاوتی مثل موارد زیر استفاده کنید:
+
+- [Etherscan](https://etherscan.io/gastracker) _تخمینزنندهی قیمت گاز تراکنش_
+- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _افزونه Chrome برای تخمین گاز با پشتیبانی تراکنشهای نوع 0 میراث (Legacy) و تراکنشهای نوع 2 EIP-1559._
+- [ماشین حساب کارمزد گاز Cryptoneur](https://www.cryptoneur.xyz/gas-fees-calculator) _کارمزد گاز را برای انواع مختلف تراکنش در Mainnet و Arbitrum و Polygon به ارز محلی خود محاسبه کنید._
+
+## ابزارهای مرتبط {#related-tools}
+
+- [پلتفرم گاز Blocknative](https://www.blocknative.com/gas) _وب سرویس تخمین گاز تحت پشتیبانی پلفترم داده استخر حافظه جهانی Blocknative_
+
+## بیشتر بخوانید {#further-reading}
+
+- [توضیحی دربارهی گاز اتریوم](https://defiprime.com/gas)
+- [کاهش مصرف گاز قراردادهای هوشمندتان](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
+- [اثبات سهام در مقابل اثبات کار](https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/)
+- [استراتژی های بهینهسازی گاز برای توسعه دهندگان](https://www.alchemy.com/overviews/solidity-gas-optimization)
+- [اسناد EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
+- [منابع تیم بیکو درباره EIP-1559](https://hackmd.io/@timbeiko/1559-resources).
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/index.md
new file mode 100644
index 00000000000..78e4465405a
--- /dev/null
+++ b/public/content/translations/fa/13) Foundational Docs/developers/docs/index.md
@@ -0,0 +1,25 @@
+---
+title: اسناد توسعه اتریوم
+description: معرفی مستندات توسعه ethereum.org.
+lang: fa
+---
+
+مستندات برای کمک به شما برای ساختن با اتریوم طراحی شدهاند. این مستندات، اتریوم را در مقام یک مفهوم شرح میدهد، پشته فناوری اتریوم را توضیح میدهد و موضوعات پیشرفته را برای اپلیکیشنها و موارد پیچیدهتر مستند میکند.
+
+مستندات به کوشش جامعه متن باز تهیه میشود، پس برای پیشنهاد دادن موضوعات جدید، افزودن محتوای جدید، ساخت مثال و هرچیزی که فکر میکنید مفید است راحت باشید. تمام مستندات میتوانند در گیتهاب ویرایش شوند - اگر مطمئن نیستید چگونه میتوان این کار را انجام دارد، [ این دستورالعملها را دنبال کنید](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
+
+## ماژولهای توسعه {#development-modules}
+
+اگر این اولین تلاش شما برای توسعه اتریوم است، به شما پیشنهاد میکنیم یادگیری و کار را از طریق یک کتاب شروع کنید.
+
+### موضوعات بنیادی {#foundational-topics}
+
+مقدار` 0x3b0559f4 = 990206452 است.
+
+
+
+## انواع تراکنشها {#types-of-transactions}
+
+در اتریوم چند نوع تراکنش مختلف وجود دارد:
+
+- تراکنش های منظم: تراکنش از یک حساب به حساب دیگر.
+- تراکنشهای استقرار قرارداد: تراکنش بدون آدرس «to»، که در آن از فیلد دادهها برای کد قرارداد استفاده میشود.
+- اجرای قرارداد: تراکنشی که با یک قرارداد هوشمند مستقر تعامل دارد. در این مورد، آدرس «to»، آدرس قرارداد هوشمند است.
+
+
+
+### دربارهی گاز {#on-gas}
+
+همانطور که گفته شد، انجام تراکنشها [گاز](/developers/docs/gas/) مصرف میکند. تراکنشهای انتقال ساده به 21000 واحد گاز نیاز دارند.
+
+بنابراین برای اینکه باب 1 اتر را به آلیس با `baseFeePerGas` به میزان 190 gwei و `maxPriorityFeePerGas` به میزان 10 gwei ارسال کند، باب باید هزینهی زیر را بپردازد:
+
+
+
+```
+(190 + 10) * 21000 = 4,200,000 gwei
+--یا--
+0.0042 اتر
+```
+
+
+مقدار **1.0042 اتر** از حساب باب کسر خواهد شد (1 اتر برای آلیس + 0.0042 اتر برای هزینه گاز)
+
+به حساب آلیس **1.0+ اتر** بستانکار خواهد شد
+
+کارمزد پایه **0.00399- اتر** خواهد شد
+
+اعتبارسنج انعام **+0.000210 ETH** را نگه می دارد
+
+![شکلی نشاندهندهی نحوهی بازپرداخت گاز مصرفنشده](./gas-tx.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+هر گازی که در تراکنش استفاده نشده باشد به حساب کاربری مسترد میشود.
+
+
+
+### تعاملات قرارداد هوشمند {#smart-contract-interactions}
+
+گاز برای هر تراکنشی که شامل یک قرارداد هوشمند است، لازم است.
+
+قراردادهای هوشمند همچنین میتوانند دارای عملکردهایی باشند که بهعنوان عملکردهای [`نما`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) یا [`خالص`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) شناخته میشوند، که وضعیت قرارداد را تغییر نمیدهند. به این ترتیب، فراخوانی این توابع از یک EOA نیازی به گاز ندارد. فراخوان RPC اصلی برای این سناریو [`eth_call`](/developers/docs/apis/json-rpc#eth_call) است
+
+برخلاف زمانی که با استفاده از `eth_call` قابل دسترسی است، این توابع `نما` یا `خالص` معمولاً به صورت داخلی نیز فراخوانده می شوند (یعنی از خود قرارداد یا از قرارداد دیگری) که کارمزد گس را به همراه دارد.
+
+
+
+## چرخهی حیات تراکنش {#transaction-lifecycle}
+
+هنگامی که تراکنش ارسال شد، موارد زیر اتفاق میافتد:
+
+1. یک هشِ تراکنش به صورت رمزنگاری شده تولید میشود: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
+
+2. سپس تراکنش شما در شبکه مخابره می شود و به استخری که شامل تمامی تراکنش های شبکه است که در حال انتظار می باشند اضافه می شود.
+
+3. به منظور تایید و "موفقیت آمیز" در نظر گرفته شدن تراکنش شما، یک اعتبارسنج باید تراکنش شما را انتخاب کرده و داخل یک بلوک قرار دهد.
+4. با گذر زمان بلوکی که حامل تراکنش شما است به وضعیت "مشروع" و سپس "نهایی" برروز رسانی می شود. این ارتقاها موجب می شوند که کاملا مطمئن شوید که تراکنش شما موفقیت آمیز بوده و هرگز تغییر نخواهد کرد. زمانی که یک بلوک "نهایی" شد فقط تنها زمانی که مورد یک حمله در حد و سطح شبکه قرار بگیرد می تواند تغییر یابد که چندین میلیارد دلار هزینه به بار خواهد آورد.
+
+
+
+## یک نسخهی آزمایشی تصویری {#a-visual-demo}
+
+آستین را تماشا کنید که شما را دربارهی تراکنشها، گاز و استخراج راهنمایی میکند.
+
+
+
+
+
+## پاکت تراکنش تایپشده {#typed-transaction-envelope}
+
+اتریوم در ابتدا یک قالب برای تراکنشها داشت. هر تراکنش حاوی نانس (nonce)، قیمت گاز، حد گاز، آدرس گیرنده، مقدار، داده، v، r و s بود. این فیلد ها [کدگذاری شده RLP](/developers/docs/data-structures-and-encoding/rlp/) هستند، تا چیزی شبیه این به نظر برسند:
+
+`RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])`
+
+اتریوم به گونهای تکامل یافته است که از چندین نوع تراکنش پشتیبانی میکند تا پیادهسازی ویژگیهای جدیدی مانند لیستهای دسترسی و [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) را بدون تأثیر بر قالبهای تراکنش قدیمی امکانپذیر سازد.
+
+[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) چیزی است که به این رفتار اجازه می دهد. تراکنش ها به صورت زیر تفسیر می شوند:
+
+`نوع معامله || TransactionPayload`
+
+که در آن فیلدها به صورت زیر تعریف میشوند:
+
+- `TransactionType` - عددی بین 0 و 0x7f، برای مجموع 128 نوع تراکنش ممکن.
+- `TransactionPayload` - یک آرایهی بایت دلخواه که توسط نوع تراکنش تعریف شده است.
+
+بر اساس مقدار `TransactionType`، تراکنش را می توان به موارد زیر طبقهبندی کرد
+
+1. **تراکنش های نوع صفر (قدیمی):** فرمت تراکنش اصلی که از زمان راهاندازی اتریوم استفاده شده است. اینها شامل ویژگیهای [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) مانند محاسبات دینامیک هزینه گس یا لیست دسترسی برای قراردادهای هوشمند نمیشوند. تراکنشهای قدیمی فاقد پیشوند خاصی هستند که نوع آنها را به صورت سریالی نشان میدهد، و با بایت `0xf8` هنگام استفاده از رمزگذاری [پیشوند طول بازگشتی (RLP)](/developers/docs/data-structures-and-encoding/rlp) شروع میشوند. مقدار TransactionType برای این تراکنشها `0x0` است.
+
+2. **تراکنشهای نوع یک:**در [پیشنهاد EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) بهعنوان بخشی از [ارتقای برلین](/history/#berlin) اتریوم معرفی شدند، این تراکنشها شامل پارامتر `accessList` هستند. این فهرست اقدام به مشخصکردن آدرسها و کلیدهای ذخیرهسازی میکند که تراکنش انتظار دارد به آنها دسترسی داشته باشد، و به کاهش بالقوه هزینههای [گس](/developers/docs/gas/) برای تراکنشهای پیچیده شامل قراردادهای هوشمند کمک میکند. تغییرات بازار کارمزد EIP-1559 در تراکنشهای نوع یک گنجانده نشدهاند. تراکنشهای نوع 1 همچنین شامل یک پارامتر `yParity` هستند که میتواند `0x0` یا `0x1` باشد که نشاندهنده برابری مقدار y امضای secp256k1 است. تشخیص آنها اینطور است که با بایت `0x01` شناسایی می شوند و مقدار TransactionType آنها `0x1` است.
+
+3. **تراکنشهای نوع 2** که معمولاً به تراکنشهای EIP-1559 گفته میشوند، تراکنشهایی هستند که در [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)، در [بهروزرسانی لندن](/history/#london) اتریوم معرفی شدهاند. آنها به مدل تراکنش استاندارد در شبکه اتریوم تبدیل شدهاند. این تراکنشها یک مکانیزم جدید بازار کارمزد را معرفی میکنند که با تفکیک کارمزد معامله به کارمزد پایه و کارمزد اولویت، قابلیت پیشبینی را بهبود میبخشد. آنها با بایت `0x02` شروع می شوند و شامل فیلدهایی مانند `maxPriorityFeePerGas` و `maxFeePerGas` میشوند. تراکنشهای نوع 2 اکنون به دلیل انعطافپذیری و کارایی، پیشفرض هستند، بهویژه در دورههای شلوغی بالای شبکه به دلیل توانایی آنها در کمک به کاربران در مدیریت قابل پیشبینیتر کارمزد تراکنشها مورد توجه قرار میگیرند. مقدار TransactionType برای این تراکنش ها `0x2` است.
+
+
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [EIP-2718: پاکت تراکنش تایپشده](https://eips.ethereum.org/EIPS/eip-2718)
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
+
+
+
+## موضوعات مرتبط {#related-topics}
+
+- [حسابها](/developers/docs/accounts/)
+- [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)
+- [گاز](/developers/docs/gas/)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
new file mode 100644
index 00000000000..4162df41553
--- /dev/null
+++ b/public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
@@ -0,0 +1,62 @@
+---
+title: Web2 در مقابل Web3
+description:
+lang: fa
+---
+
+Web2 به نسخهای از اینترنت اشاره دارد که امروزه اکثر ما میشناسیم. اینترنت تحت سلطهی شرکتهایی که در ازای اطلاعات شخصی شما خدمات ارائه میدهند. در بافت اتریوم، Web3 به برنامههای غیرمتمرکز اطلاق میشود که روی زنجیرهی بلوکی اجرا میشوند. اینها برنامههایی هستند که به هر کسی امکان میدهند بدون ثبت دادههای شخصی خود مشارکت داشته باشد.
+
+به دنبال منبعی هستید که برای مبتدیان مناسبتر باشد؟ [معرفی Web3](/web3/) ما را ببینید.
+
+## مزایای Web3 {#web3-benefits}
+
+بسیاری از توسعهدهندگان Web3 به دلیل تمرکززدایی ذاتی اتریوم، به سراغ ساختن dappها رفتهاند:
+
+- هر کسی که در شبکه است اجازه استفاده از این سرویس را دارد - یا به عبارت دیگر، مجوز لازم نیست.
+- هیچ کس نمیتواند شما را مسدود کند یا از دسترسی شما به این سرویس جلوگیری کند.
+- پرداختها از طریق توکن بومی، اتر (ETH) انجام میشوند.
+- اتریوم تورینگ کامل است، به این معنی که تقریباً میتوانید هر چیزی را برنامهنویسی کنید.
+
+## مقایسههای عملی {#practical-comparisons}
+
+| Web2 | Web3 |
+| --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| توییتر میتواند هر حساب کاربری یا توییتی را سانسور کند | توییتهای Web3 غیرقابل سانسور هستند زیرا کنترل غیرمتمرکز است |
+| ممکن است سرویس پرداخت تصمیم بگیرد که برای انواع خاصی از کار، پرداخت را مجاز نکند | برنامههای پرداخت Web3 به اطلاعات شخصی نیاز ندارند و نمیتوانند از پرداخت جلوگیری کنند |
+| سرورهای برنامههای اقتصادی کلان ممکن است از کار بیفتند و بر درآمد کارگران تأثیر بگذارند | سرورهای Web3 نمیتوانند از کار بیفتند - آنها از اتریوم، یک شبکه غیرمتمرکز از هزاران رایانه بهعنوان پشتیبان خود استفاده میکنند |
+
+این بدان معنا نیست که همهی خدمات باید به dapp تبدیل شوند. این مثالها تفاوتهای اصلی بین خدمات web2 و web3 را نشان میدهند.
+
+## محدودیتهای Web3 {#web3-limitations}
+
+Web3 در حال حاضر محدودیتهایی دارد:
+
+- مقیاسپذیری - تراکنشها در Web3 کندتر هستند چون غیرمتمرکز هستند. تغییرات در حالت، مانند پرداخت، باید توسط یک گره پردازش شده و در سراسر شبکه منتشر شود.
+- UX – تعامل با برنامههای web3 ممکن است به مراحل، نرم افزار و آموزش اضافی نیاز داشته باشد. این موضوع میتواند مانعی برای پذیرش باشد.
+- قابلیت دسترسی – عدم یکپارچگی در مرورگرهای وب مدرن باعث میشود که Web3 برای اکثر کاربران کمتر در دسترس باشد.
+- هزینه – اکثر dappهای موفق بخشهای بسیار کوچکی از کد خود را روی زنجیرهی بلوکی قرار میدهند، چون این کار گران است.
+
+## تمرکز در مقابل عدم تمرکز {#centralization-vs-decentralization}
+
+در جدول زیر، برخی از مزایا و معایب شبکههای دیجیتال متمرکز و غیرمتمرکز را فهرست کردهایم.
+
+| سیستمهای متمرکز | سیستمهای غیرمتمرکز |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| قطر شبکهی کم (همه شرکتکنندگان به یک مرجع مرکزی متصل هستند). اطلاعات به سرعت منتشر میشود، زیرا انتشار توسط یک مرجع مرکزی با منابع محاسباتی فراوان اداره میشود. | دورترین مشارکت کنندگان در شبکه ممکن است به طور بالقوه از یکدیگر بسیار دور باشند. انتشار اطلاعات از یک طرف شبکه ممکن است زمان زیادی طول بکشد تا به طرف دیگر برسد. |
+| معمولاً کارایی بالاتر (بازدهی بیشتر، منابع محاسباتی مصرفشدهی کمتر در مجموع) و پیادهسازی آسانتری دارند. | معمولاً کارایی کمتر (توان عملیاتی کمتر، منابع محاسباتی مصرفشدهی بیشتر در مجموع) و پیادهسازی پیچیدهتری دارند. |
+| در صورت وجود دادههای متناقض، حل و فصل آنها روشن و آسان است: منبع نهایی حقیقت، قدرت مرکزی است. | اگر همتایان ادعاهای متناقضی در مورد وضعیت دادههایی داشته باشند که قرار است شرکتکنندگان روی آن هماهنگ شوند، یک پروتکل (اغلب پیچیده) برای حل اختلاف موردنیاز است. |
+| تک نقطهی شکست: کاربران مخرب ممکن است بتوانند با هدف قرار دادن بخش مرکزی، شبکه را از بین ببرند. | هیچ نقطهی شکست واحدی وجود ندارد: حتی اگر تعداد زیادی از شرکتکنندگان مورد حمله/خروج قرار گیرند، شبکه همچنان میتواند کار کند. |
+| هماهنگی بین شرکتکنندگان در شبکه بسیار آسانتر است و توسط یک مقام مرکزی اداره میشود. قدرت مرکزی میتواند شرکت کنندگان شبکه را وادار کند که ارتقا، بهروزرسانی پروتکل و غیره را با تنش کمتری انجام دهند. | هماهنگی اغلب دشوار است، زیرا هیچ عاملی حرف آخر را در تصمیمگیریهای سطح شبکه، ارتقای پروتکل و غیره نمیزند. در بدترین حالت، زمانی که در مورد تغییرات پروتکل اختلاف نظر وجود داشته باشد، شبکه مستعد از بین رفتن است. |
+| مرجع مرکزی میتواند دادهها را سانسور کند و به طور بالقوه بخشهایی از شبکه را از تعامل با بقیه شبکه قطع کند. | سانسور بسیار سختتر است، زیرا اطلاعات راههای زیادی را برای انتشار در سراسر شبکه دارند. |
+| مشارکت در شبکه توسط مرجع مرکزی کنترل میشود. | هر کسی میتواند در شبکه مشارکت کند. هیچ «نگهبانی» وجود ندارد. در حالت ایدهآل، هزینهی مشارکت بسیار پایین است. |
+
+توجه داشته باشید که اینها الگوهای کلی هستند که ممکن است در هر شبکهای صادق نباشند. علاوه بر این، در واقعیت، میزان متمرکز/غیرمتمرکز بودن یک شبکه در یک طیف قرار دارد. هیچ شبکهای کاملاً متمرکز یا کاملاً غیرمتمرکز نیست.
+
+## بیشتر بخوانید {#further-reading}
+
+- [Web3 چیست؟](/web3/) - _ethereum.org_
+- [معماری یک برنامه Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _پریتی کسیردی_
+- [معنای تمرکززدایی](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _6 فوریه 2017، ویتالیک بوترین_
+- [چرا تمرکززدایی مهم است](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) _18 فوریه 2018 - کریس دیکسون_
+- [Web 3.0 چیست و چرا مهم است](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _31 دسامبر 2019 - مکس مِرش و ریچارد موریهد_
+- [چرا به وب 3.0 نیاز داریم](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _12 سپتامبر 2018 - گاوین وود_
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md
new file mode 100644
index 00000000000..e92be3f2ac5
--- /dev/null
+++ b/public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md
@@ -0,0 +1,65 @@
+---
+title: رپد اتر (WETH) چیست؟
+description: مقدمه ای بر رپد اتر (WETH) - یک پوشش سازگار با ERC20 برای اتر (ETH).
+lang: fa
+---
+
+# رپد اتر (WETH) {#intro-to-weth}
+
+اتر (ETH) ارز اصلی اتریوم است. از آن برای چندین هدف مانند سهام گذاری، به عنوان ارز، و پرداخت هزینه های گس برای محاسبه استفاده می شود. **WETH عملاً یک شکل ارتقا یافته از ETH با برخی عملکردهای اضافی مورد نیاز بسیاری از برنامهها و [ERC-20 tokens](/glossary/#erc-20)** است که انواع دیگری از داراییهای دیجیتال در اتریوم هستند. برای کار با این توکن ها، ETH باید از همان قوانینی که به عنوان استاندارد ERC-20 شناخته می شوند، پیروی کند.
+
+برای پر کردن این شکاف، رپد اتر (WETH) ایجاد شد. **رپد اتر (WETH) یک قرارداد هوشمند است که به شما اجازه میدهد هر مقدار اتر را به این قرارداد واریز کنید و به ازای هر اتر واریزی، مقدار برابر آن را به صورت توکن WETH ضرب شده دریافت کنید** که مطابق با استاندارد توکن ERC-20 است. WETH گونهای از ETH است که به شما امکان می دهد با آن به عنوان یک توکن ERC-20 تعامل داشته باشید، نه به عنوان ETH دارایی بومی. برای پرداخت هزینه های گس همچنان به ETH بومی نیاز دارید، بنابراین مطمئن شوید که هنگام واریز مقداری پس انداز کرده اید.
+
+با استفاده از قرارداد هوشمند WETH می توانید WETH را به ETH تبدیل کنید. با قرارداد هوشمند WETH می توانید هر مقدار WETH را بازخرید کنید و همان مقدار را به صورت اتریوم دریافت خواهید کرد. سپس WETH سپرده شده سوزانده میشود و از منبع در حال گردش WETH خارج می شود.
+
+**تقریباً 3٪ از عرضه ETH در گردش در قرارداد توکن WETH قفل شده است** و آن را به یکی از پرکاربردترین [قراردادهای هوشمند] تبدیل می کند (/glossary/#smart-contract). WETH به ویژه برای کاربرانی که با برنامههای کاربردی در امور مالی غیرمتمرکز (DeFi) تعامل دارند، مهم است.
+
+## چرا به رپد ETH به عنوان ERC-20 نیاز داریم؟ {#why-do-we-need-to-wrap-eth}
+
+[ERC-20](/developers/docs/standards/tokens/erc-20/) یک رابط استاندارد برای توکنهای قابل انتقال تعریف میکند، بنابراین هر کس میتواند توکنهایی ایجاد کند که به طور یکپارچه با برنامهها و توکنهایی که از این استاندارد در اکوسیستم اتریوم استفاده میکنند، تعامل داشته باشند. از آنجا که **ETH قبل از استاندارد ERC-20** ایجاد شده است، ETH با این مشخصات مطابقت ندارد. این به این معنی است که **شما نمی توانید به راحتی** ETH را با سایر توکنهای ERC-20 مبادله کنید یا **از ETH در برنامه ها با استفاده از استاندارد ERC-20 استفاده کنید**. رپ کردن ETH به شما این فرصت را می دهد که کارهای زیر را انجام دهید:
+
+- **مبادله ETH با توکن های ERC-20**: شما نمی توانید ETH را مستقیماً با سایر توکن های ERC-20 مبادله کنید. WETH گونهای اتر است که با استاندارد توکن قابل تعویض ERC-20 مطابقت دارد و می تواند با سایر توکن های ERC-20 مبادله شود.
+
+- **از ETH در dapp ها استفاده کنید**: از آنجا که ETH با ERC20 سازگار نیست، توسعه دهندگان باید رابط های جداگانه ای (یکی برای ETH و دیگری برای توکن های ERC-20) در dapp ها ایجاد کنند. رپ کردن ETH این مانع را برطرف میکند و توسعهدهندگان را قادر میسازد تا ETH و سایر توکنها را در همان dapp مدیریت کنند. بسیاری از برنامه های مالی غیرمتمرکز از این استاندارد استفاده می کنند و بازارهایی را برای مبادله این توکن ها ایجاد می کنند.
+
+## رپد اتر (WETH) در مقابل اتر (ETH): تفاوت در چیست؟ {#weth-vs-eth-differences}
+
+| | **اتر (ETH)** | **رپد اتر (WETH)** |
+| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| عرضه | عرضه ETH توسط پروتکل اتریوم مدیریت می شود. هنگام پردازش تراکنشها و ایجاد بلوک، [issuance](/roadmap/merge/issuance) اتر توسط اعتبارسنجهای اتریوم مدیریت میشود. | WETH یک توکن ERC-20 است که عرضه آن توسط یک قرارداد هوشمند مدیریت می شود. واحدهای جدید WETH پس از دریافت سپرده های ETH از کاربران توسط قرارداد صادر می شوند، یا زمانی که کاربر می خواهد WETH را برای ETH بازخرید کند، واحدهای WETH سوزانده می شوند. |
+| مالکیت | مالکیت توسط پروتکل اتریوم از طریق موجودی حساب شما مدیریت می شود. | مالکیت WETH توسط قرارداد هوشمند توکن WETH مدیریت می شود که توسط پروتکل اتریوم ایمن شده است. |
+| گاز | اتر (ETH) واحد پرداخت پذیرفته شده برای محاسبه در شبکه اتریوم است. هزینه های گس بر حسب gwei (واحد اتر) تعیین می شود. | پرداخت گس با توکن های WETH به صورت بومی پشتیبانی نمی شود. |
+
+## سوالات متداول {#faq}
+
+
+
+برای رپ یا آنرپ کردن ETH با استفاده از قرارداد WETH هزینه گس می پردازید.
+
+
+
+
+
+WETH به دلیل اینکه بر اساس یک قرارداد هوشمند ساده و آزمایششده ساخته شده است، به طور کلی امن در نظر گرفته میشود. قرارداد WETH نیز به طور رسمی تأیید شده است که بالاترین استاندارد امنیتی برای قراردادهای هوشمند در اتریوم است.
+
+
+
+
+
+علاوه بر پیادهسازی متعارفِ WETH[canonical implementation of WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) که در این صفحه توضیح داده شد، نسخههای دیگری از آن نیز وجود دارند. اینها ممکن است توکنهای سفارشی ایجاد شده توسط توسعهدهندگان اپلیکیشن یا نسخههای منتشر شده در سایر بلاک چینها باشند و ممکن است رفتار متفاوت یا ویژگیهای امنیتی متفاوت داشته باشند. **همیشه اطلاعات توکن را دوباره بررسی کنید تا بدانید با کدام اجرای WETH در حال تعامل هستید.**
+
+
+
+
+
+- [شبکه اصلی اتریوم](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
+- [آربیتروم](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
+- [آپتیمیزم](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
+
+
+
+## ادامه مطلب {#further-reading}
+
+- [آیا WTF WETH است؟](https://weth.tkn.eth.limo/)
+- [اطلاعات توکن WETH در Etherscan](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
+- [تأیید رسمی WETH](https://zellic.io/blog/formal-verification-weth)
diff --git a/public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md b/public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md
new file mode 100644
index 00000000000..933e7e19a27
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md
@@ -0,0 +1,77 @@
+---
+title: آییننامه رفتاری
+description: استانداردهای اصلی که ما در کل فضای ethereum.org برای آنها تلاش میکنیم.
+lang: fa
+---
+
+# آییننامه رفتاری {#code-of-conduct}
+
+## مأموریت {#mission}
+
+توسعه و حفظ جامعترین و دسترسپذیرترین مرکز دانش برای شبکۀ اتریوم.
+
+## ارزشها {#values}
+
+جامعۀ ethereum.org در تلاش است که اینگونه باشد:
+
+- آموزشی؛ با قصد کمک به همه افراد در فهمیدن اتریوم
+- فراگیر
+- در دسترس
+- جامعه-محور
+- متمرکز بر تکنولوژی و کاربردهای اصلی اتریوم
+- متمرکز بر معنای کلی و اصول طراحی اتریوم
+
+## آنچه ما نیستیم {#what-we-are-not}
+
+- وبسایت بنیاد اتریوم
+- یک پلتفرم برای ترویج سرمایهگذاری و یا کسب سود از هر نوعی
+- پلتفرمی برای ارتقا یا حمایت از پروژهها یا سازمانها
+- یک DEX یا CEX یا نوع دیگری از پلتفرمهای مالی
+- پلتفرمی که مشاورۀ مالی یا حقوقی از هر نوع ارائه میدهد
+
+## آییننامه رفتاری {#code-of-conduct}
+
+### تعهد {#pledge}
+
+مشارکت باز و آزادانه، هستۀ اصلی صفات و شخصیت جامعۀ ethereum.org است. ما یک وبسایت و جامعهای استقراریافته توسط هزاران مشارکتکننده هستیم که فقط از طریق ایجاد یک محیط مشارکتی و پذیرا امکانپذیر است. برای این مقصود، مشارکتکنندگان تعهد میدهند که یک محیط عاری از تعرض و آزار برای تمام اعضای مشارکتجو در هر یک از پلتفرمها و انجمنهای ethereum.org به وجود آورند. وبسایت ethereum.org پذیرای هر فردی است که به مشارکت سازنده و دوستانه علاقه دارد و بدون توجه به سن، قومیت، جنسیت، هویت، سطح مهارت و تجربه، زمینۀ کاری، تحصیلات، وضعیت اقتصادی-اجتماعی، ملیت، ظاهر شخصی، نژاد، مذهب یا هر بُعد دیگر گوناگونی، به آنها ارزش مینهد.
+
+### محدوده {#scope}
+
+این آییننامۀ رفتاری در تمام فضای کاری ethereum.org مانند GitHub، Discord، Twitter، Figma Crowdin و سایر پلتفرمهای آنلاین و همچنین هر جا که این جامعه در فضای عمومی دنیای واقعی (نشستها، کنفرانسها و رویدادها) ظاهر میشود، صادق است.
+
+### استانداردهای ما {#our-standards}
+
+مثالهای رفتاری که به ایجاد یک محیط سازنده و مثبت کمک میکند شامل این موارد است:
+
+- استفاده از زبان خوشایند و فراگیر
+- محترم شمردن تجربیات و دیدگاههای متفاوت
+- پذیرش موقرانه و یا طرح همدلانۀ انتقادهای سازنده
+- حفظ آرامش و رفتار حرفهای هنگام حل تعارضها و اختلاف نظر
+- نشان دادن همدلی و بردباری در مواجهه با سایر اعضای جامعه
+- تشویق و تقویت آرا و نظرات جدید در جامعه
+
+مثالهای رفتارهای غیرقابل پذیرش از سوی اعضا شامل این موارد است:
+
+- خشونت فیزیکی، خشونت تهدید آمیز یا ترغیب و ترویج خشونت فیزیکی از هر نوع
+- استفاده از زبان و تصاویر جنسیتزده یا تحمیل توجه جنسی ناخواسته
+- جعل هویت سایرین یا ادعای دروغِ داشتن رابطه با یک فرد یا سازمان
+- مسخره کردن، نظرات توهینآمیز یا تحقیرآمیز و حملات شخصی یا سیاسی
+- آزار رساندن به سایر اعضای جامعه در کانالهای عمومی و خصوصی
+- منتشر کردن اطلاعات خصوصی دیگران مانند آدرس فیزیکی یا الکترونیکی، بدون اجازۀ صریح
+- مهندسی اجتماعی، اسکم کردن یا اعمال نفوذ بر اعضای جامعه
+- تبلیغ و ترویج فرصتهای سرمایهگذاری، توکنها، پروژهها یا هر نوع دیگر از عایدی شخصی مالی یا غیرمالی
+- ارسال اطلاعات هرز به سرور با موضوعات غیرمرتبط
+- بیاعتنایی به درخواستها و هشدارهای مدیران انجمنها و جوامع
+- اقدام به هر گونه رفتار دیگر که در یک محیط حرفهای میتواند نامناسب پنداشته شود
+
+### گزارشدهی {#reporting}
+
+تخطی از آییننامه رفتاری، اغلب بر اعضای جامعه آشکار خواهد بود چون ما هر کاری را در کانالها و فضای باز و عمومی انجام میدهیم، در واقع میگذاریم خودِ اعضای جامعه، پلیس باشند و نظم را برقرار کنند.
+
+به هر حال اگر اتفاقی افتاد که از نظرتان نیاز به توجه و رسیدگی دارد، میتوانید آن را با فردی که نقش میانجیگری دارد (برای مثال راهنمای دیسکورد) مطرح کنید تا بتوانند به فرایند بررسی و واکنش مناسب کمک کنند.
+
+هنگام گزارشدهی بهتر است تا جایی که میتوانید جزئیات مختلف مانند مثالهای خاص و برچسبهای زمان را درج کنید. این کار در دستیابی به نتیجهای عادلانه اثربخش است.
+
+### اعمال قانون {#enforcement}
+
+افرادی که قوانین رفتاری را نقض کنند، بسته به شدت عمل ممکن است هشدار بگیرند، به صورت موقت محروم شوند یا مشمول ممنوعیت دائمی از جامعۀ etheruem.org شوند.
diff --git a/public/content/translations/fa/14) Community Pages/community/events/index.md b/public/content/translations/fa/14) Community Pages/community/events/index.md
new file mode 100644
index 00000000000..373618a54a3
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/events/index.md
@@ -0,0 +1,24 @@
+---
+title: رویدادهای اتریوم
+description: چگونه در انجمن اتریوم شرکت کنیم؟
+lang: fa
+hideEditButton: true
+---
+
+# رویدادهای پیشرو {#events}
+
+**هر ماه، رویدادهای مهم اتریوم در سرتاسر جهان برگزار میشود.** شرکت در یکی از رویدادهای نزدیک به خود را در نظر داشته باشید تا با افراد بیشتری در جامعه آشنا شوید، درباره فرصتهای شغلی اطلاع کسب کنید و مهارتهای جدید را توسعه دهید.
+
+
+
+این یک لیست غیرجامع است که توسط انجمن ما نگهداری می شود. از رویداد آتی اتریوم برای اضافه کردن به این لیست اطلاع دارید؟ [لطفاً آن را اضافه کنید](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-events.json)!
+
+## گردهماییهای اتریوم {#meetups}
+
+رویدادی را نمیبینید که برای شما مفید باشد؟ شرکت در یک گردهمایی را امتحان کنید. گردهماییها رویدادهای کوچکتری هستند که توسط گروههایی از علاقهمندان به اتریوم برگزار میشوند - فرصتی برای افراد علاقهمند به اتریوم تا دور هم جمع شوند، درباره اتریوم صحبت کنند، و در مورد پیشرفتهای اخیر اطلاعات کسب کنند.
+
+
+
+علاقهمند به برگزاری گردهمایی خود هستید؟ [شبکهی BUIDL](https://consensys.net/developers/buidlnetwork/) را بررسی کنید، ابتکاری توسط ConsenSys برای کمک به حمایت از انجمنهای ملاقات اتریوم.
+
+این یک فهرست غیرجامع است که توسط انجمن ما ساخته شده است. میتوانید [گردهماییهای اتریوم بیشتری را در اینجا بیابید](https://www.meetup.com/topics/ethereum/). گروه ملاقات فعالی برای اضافه کردن به این فهرست میشناسید؟ [لطفاً آن را اضافه کنید](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-meetups.json)!
diff --git a/public/content/translations/fa/14) Community Pages/community/get-involved/index.md b/public/content/translations/fa/14) Community Pages/community/get-involved/index.md
new file mode 100644
index 00000000000..ab71b2d4692
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/get-involved/index.md
@@ -0,0 +1,135 @@
+---
+title: چطور میتوانم مشارکت کنم؟
+description: چگونه در انجمن اتریوم شرکت کنیم؟
+lang: fa
+---
+
+# چطور میتوانم مشارکت کنم؟ {#get-involved}
+
+جامعهی اتریوم شامل افرادی با زمینهها و مهارتهای مختلف است. فرقی نمیکند توسعهدهنده باشد، هنرمند یا حسابدار؛ راههایی برای مشارکت وجود دارد. در اینجا فهرستی از پیشنهاداتی که ممکن است به شما در شروع کار کمک کند، وجود دارد.
+
+با مطالعه ماموریت و ارزش های ethereum.org در [منشور اخلاقی](/community/code-of-conduct) ما شروع کنید.
+
+## توسعهدهندگان {#developers}
+
+- در [ethereum.org/developers/](/developers/) درباره اتریوم یاد بگیرید و آن را امتحان کنید
+- در یک هکاتون [ETHGlobal](http://ethglobal.co/) در نزدیکی خود شرکت کنید!
+- [پروژههای مرتبط با حوزهی تخصصی یا زبان برنامهنویسی انتخابی خود را بررسی کنید](/developers/docs/programming-languages/)
+- [فراخوانهای لایه اجماع و اجرا](https://www.youtube.com/@EthereumProtocol/streams) را تماشا کنید یا در آن شرکت کنید
+- [فهرست نیازمندیهای برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/wishlist/) - ابزار، اسناد و مناطق زیرساختی که در آن برنامه حمایت از اکوسیستم اتوریوم فعالانه به دنبال کمک به برنامههای کمکی است
+- [Web3Bridge](https://www.web3bridge.com/) - برای شناسایی، آموزش و حمایت از صدها توسعهدهنده و اعضای انجمن در سراسر آفریقا به جامعهی مشتاق web3 بپیوندید
+- به [ دیسکورد Eth R&&D](https://discord.com/invite/VmG7Uxc) بپیوندید
+- به [دیسکورد Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) بپیوندید
+
+## محققان و دانشگاهیان {#researchers-and-academics}
+
+آیا سابقهای در زمینه ریاضیات، رمزنگاری یا اقتصاد دارید؟ ممکن است به برخی از کارهای پیشرفتهای که در اکوسیستم اتریوم انجام میشود علاقهمند باشید:
+
+- به [ دیسکورد Eth R&&D](https://discord.com/invite/VmG7Uxc) بپیوندید
+- نوشتن یا بررسی یک پیشنهاد بهبود اتریوم
+ - یک EIP (پیشنهاد بهبود اتریوم) بنویسید
+ 1. ایده خود را در [Ethereum Magicians](https://ethereum-magicians.org) ارسال کنید
+ 2. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) را بخوانید - **بله، این _کل_ سند است.**
+ 3. دستورالعمل ها را در EIP-1 دنبال کنید. در حین نگارش پیش نویس، به آن ارجاع دهید.
+ - یاد بگیرید که چگونه یک [ویرایشگر EIP](https://eips.ethereum.org/EIPS/eip-5069) شوید
+ - حالا می توانید EIPها را مورد بازبینی قرار دهید! [PRهای موجود با تگ`e-review` را مشاهده کنید](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review). بازخورد فنی را با کلیک بر `discussion-to` ثبت کنید.
+ - در [حاکمیت پیشنهادهای بهبود اتریوم](https://github.com/ethereum-cat-herders/EIPIP) مشارکت کنید
+ - به [دیسکورد Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) بپیوندید
+ - [اطلاعات بیشتر درباره EIPها](/eips/)
+- [Challenges.ethereum.org](https://challenges.ethereum.org/) - مجموعهای از جایزههای تحقیقاتی با ارزش، که در آن میتوانید تا >100,000 دلار آمریکا کسب کنید
+- [Ethresear.ch](https://ethresear.ch) - انجمن اصلی اتریوم برای تحقیقات، و تأثیرگذارترین انجمن جهان برای اقتصاد رمزنگاری
+- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - مجموعهای ادامهدار از پرسش &و پاسخ با پژوهشگران. با باز شدن هر قسمت جدید، هر کس میتواند سؤالاتش را ارسال کند.
+- [فهرست نیازمندیهای برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/wishlist/) - زمینههای تحقیقاتی که در آنها برنامه پشتیبانی اکوسیستم اتریوم فعالانه به دنبال درخواستهای کمک مالی است
+- [AllWalletDevs](https://allwallet.dev) - انجمنی برای توسعه دهندگان، طراحان و کاربران علاقه مند اتریوم که به طور منظم گرد هم می آیند و درباره کیفپول ها بحث می کنند
+
+[حیطههای پژوهشی فعال بیشتری را کشف کنید](/community/research/).
+
+## مجموعهی مهارتهای غیرفنی {#non-technical}
+
+اگر توسعهدهنده نیستید، ممکن است دانستن اینکه از کجا در اتریوم شروع کنید سخت باشد. در اینجا چند پیشنهاد به همراه منابعی برای زمینههای حرفهای خاص آورده شده است.
+
+### یک گردهمایی در شهر خود ترتیب دهید {#meetups}
+
+- نمیدانید چگونه شروع کنید؟ [شبکهی BUIDL](https://consensys.net/developers/buidlnetwork/) میتواند به شما کمک کند.
+
+### در مورد اتریوم مطلب بنویسید {#write-content}
+
+- اتریوم نیاز به نویسندگان خوبی دارد که بتوانند ارزش آن را به زبان ساده توضیح دهند
+- برای انتشار مقالات خود آماده نیستید؟ کمک به بهبود مطالب و مقالات کنونی موجود در منابع جامعه اتریوم، یا [پیشنهاد محتوای جدید برای ethereum.org](/contributing/) را به عنوان راهی برای مشارکت در نظر بگیرید!
+
+### پیشنهاد یادداشتبرداری برای تماسهای انجمن {#take-notes}
+
+- تماسهای جامعه متنباز بسیاری وجود دارد و داشتن یادداشتنویسی کمک بزرگی است. اگر علاقهمند هستید، به [Ethereum Cat Herders در دیسکورد](https://discord.com/invite/Nz6rtfJ8Cu) بپیوندید و خود را معرفی کنید!
+
+### محتوای اتریوم را به زبان مادری خود ترجمه کنید {#translate-ethereum}
+
+- ethereum.org یک برنامهی ترجمه دارد که وبسایت و سایر منابع را به بسیاری از زبانهای مختلف ترجمه میکند
+- نحوهی مشارکت را در [اینجا](/contributing/translation-program) بیاموزید
+
+### راهاندازی یک گره {#run-a-node}
+
+به هزاران اپراتور گره بپیوندید تا به تمرکززدایی بیشتر اتریوم کمک کنید.
+
+- [اطلاعات بیشتر در مورد نحوهی اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/)
+
+### اتر خود را سهامگذاری کنید {#staking}
+
+با سهامگذاری ETH خود میتوانید پاداش به دست آورید و در عین حال به ایمنسازی شبکه اتریوم کمک کنید.
+
+- [اطلاعات بیشتر درباره سرمایهگذاری](/staking/)
+
+### حمایت از پروژهها {#support-projects}
+
+اکوسیستم اتریوم به دنبال تأمین مالی کالاهای عمومی و پروژههای تأثیرگذار است. با کمکهای مالی بسیار کوچک میتوانید حمایت خود را نشان دهید و کمک کنید کارهای مهم محقق شود.
+
+- [Gitcoin](https://gitcoin.co/fund)
+- [clr.fund](https://clr.fund/#/about)
+
+## متخصصان مالی و حسابداران {#financial-professionals}
+
+- اتریوم خانهی اکوسیستم «امور مالی غیرمتمرکز» است - شبکهای از پروتکلها و برنامههای کاربردی که یک سیستم مالی جایگزین را ارائه میدهد. اگر در امور مالی حرفهای هستید، به برخی اپلیکیشنهای اقتصادی غیرمتمرکز (DeFi) در [DeFi Pulse](https://defillama.com/) یا [DeFiPrime](https://defiprime.com) سر بزنید
+- حسابدار هستید؟ داراییهای موجود در اتریوم - اتر، توکنها، دیفای و غیره - بسیاری از مسائل جدید حسابداری را معرفی میکنند. میتوانید با بررسی پروژههایی که هدفشان کمک به کاربران ارزهای دیجیتال برای حل چالشهای دفترداری و حسابداری است، مانند [Rotki](https://rotki.com/)، شروع کنید
+
+## مدیران محصول {#product-managers}
+
+- اکوسیستم اتریوم به استعدادهای شما نیاز دارد! بسیاری از شرکتها در حال استخدام برای سمت مدیر محصول هستند. اگر میخواهید با مشارکت در یک پروژه منبع باز شروع کنید، با [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) یا [RaidGuild](https://www.raidguild.org/) تماس بگیرید
+
+## بازاریابی {#marketing}
+
+- موقعیتهای بازاریابی و ارتباطی زیادی در اکوسیستم اتریوم وجود دارد!
+
+## فرصتهای شغلی اتریوم {#ethereum-jobs}
+
+**میخواهید یک شغل مرتبط با اتریوم پیدا کنید؟**
+
+- [فرصتهای شغلی ethereum.org](/about/#open-jobs)
+- [سایت استخدامی بنیاد اتریوم (Lever)](https://jobs.lever.co/ethereumfoundation)
+- [سایت استخدامی بنیاد اتریوم (BambooHR)](https://ethereum.bamboohr.com/jobs/)
+- [JobStash](https://jobstash.xyz)
+- [فرصتهای شغلی مرتبط با ارزهای رمزنگاریشده](https://cryptocurrencyjobs.co/ethereum/)
+- [مشاغل در ConsenSys](https://consensys.net/careers/)
+- [فهرست فرصتهای شغلی رمزنگاری](https://cryptojobslist.com/ethereum-jobs)
+- [سایت استخدامی Bankless](https://pallet.xyz/list/bankless/jobs)
+- [فرصتهای شغلی وب 3](https://web3.career)
+- [Web3 Army](https://web3army.xyz/)
+- [فرصتهای شغلی Crypto Valley](https://cryptovalley.jobs/)
+- [فرصتهای شغلی اتریوم](https://startup.jobs/ethereum-jobs)
+- [CryptoJobster](https://cryptojobster.com/tag/ethereum/)
+
+## پیوستن به DAO {#decentralized-autonomous-organizations-daos}
+
+«DAOها» سازمانهای مستقل غیرمتمرکز هستند. این گروهها از فناوری اتریوم برای تسهیل سازماندهی و همکاری استفاده میکنند. به عنوان مثال، برای کنترل عضویت، رأی دادن در مورد پیشنهادها، یا مدیریت داراییهای مشارکتی. درست است که DAOها هنوز آزمایشی هستند، اما فرصتهایی را برای شما فراهم می کنند تا گروههایی را که با آنها همسو هستید پیدا کنید و تأثیر خود را روی جامعه اتریوم افزایش دهید. [درباره DAOها بیشتر بدانید](/dao/)
+
+- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _مفهوم DAO را در زمینه غیر فناوری ترویج میکند و در ایجاد ارزش از طریق DAO به افراد کمک میکند_
+- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _جامعهی سازندگانی که به مالکیت جمعی اینترنت اعتقاد دارند_
+- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - *شرکت جمعی توسعهی Web3 Freelancer که بهعنوان DAO کار میکند*
+- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) - *حاکمیت اجتماعی DAOhaus*
+- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - *مهندسی حقوقی*
+- [Machi X](https://machix.com) [@MachiXOfficial](https://twitter.com/MachiXOfficial) - *جامعهی هنری*
+- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - *سرمایه گذاری برای پروژه های کریپتو پیش از آغاز به کار*
+- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) - *مکانیزمهای بازیهای MMORPG در زمان حال*
+- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - *برندهای پوشاک دیجیتالی*
+- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - *جامعهای با تمرکز بر تأمین مالی توسعهی اتریوم*
+- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - *مجموعهی سازندگان Web3*
+
+لطفا هر زمان خواستید در ethereum.org مشارکت کنید به یاد داشته باشید از [منشور اخلاقی](/community/code-of-conduct) ethereum.org پیروی کنید!
diff --git a/public/content/translations/fa/14) Community Pages/community/grants/index.md b/public/content/translations/fa/14) Community Pages/community/grants/index.md
new file mode 100644
index 00000000000..0cbd9a0ca1c
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/grants/index.md
@@ -0,0 +1,47 @@
+---
+title: بنیاد اتریوم و برنامههای کمک مالی جامعه
+description: فهرستی از برنامههای کمک مالی در کل اکوسیستم اتریوم.
+lang: fa
+---
+
+# کمکهای مالی اتریوم {#ethereum-grants}
+
+برنامههای فهرست شده در زیر، کمکهای مالی گوناگونی برای پروژهها جهت موفقیت و رشد اکوسیستم اتریوم اعطا میکنند. از این فهرست بهعنوان یک راهنما برای یافتن و درخواست کردن کمکهای مالی جهت کمک به موفقیت پروژه بعدی اتریوم خود استفاده کنید.
+
+این فهرست توسط جامعهی ما جمعآوری میشود. اگر چیزی ناقص یا نادرست است، لطفاً این صفحه را ویرایش کنید!
+
+## اکوسیستم گستردهی اتریوم {#broad-ethereum-ecosystem}
+
+این برنامهها از اکوسیستم گستردهی اتریوم با اعطای کمکهای مالی به دامنهی وسیعی از پروژهها حمایت میکنند. راهحلهایی جهت مقیاسپذیری، جامعهسازی، ایمنی، حریم شخصی و غیره از این جمله هستند. این کمکهای مالی مختص به یک پلتفرم اتریوم خاص نیستند و اگر مردد هستید نقطهی خوبی برای شروع است.
+
+- [برنامه پشتیبانی اکوسیستم بنیاد اتریوم](https://esp.ethereum.foundation) - _تامین مالی پروژههای منبع بازی که به اتریوم سودرسانی میکنند، با تمرکز بر ابزار های جهانی، زیرساخت، پژوهش و منافع عمومی_
+- [Moloch DAO](https://www.molochdao.com/) - _حریم خصوصی، مقیاسپذیری لایهی 2، امنیت کاربر و غیره_
+- [ کمکهای مالی DAO](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _صفحهگسترده Google از سازمانهای ارائهدهندهی کمکهای مالی_
+- [کمکهای مالی تحصیلی](https://esp.ethereum.foundation/academic-grants)-_کمکهای مالی برای تحقیقات آکادمیک مربوط به اتریوم_
+- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworks یک مجموعه جامع از تمامی کمکهای مالی، RFPها، و پاداشهای گزارش اشکالات._
+
+## خاص هر پروژه {#project-specific}
+
+این پروژهها برای پروژههایی که در راستای توسعه و آزمایش فناوری خود هستند کمکهای مالی خود را ساختهاند.
+
+- [برنامهی کمکهای مالی Aave](https://aavegrants.org/) - _[Aave](https://aave.com/) DAO_ را اعطا میکند
+- [Balancer](https://grants.balancer.community/) – _صندوق اکوسیستم [Balancer](https://balancer.fi/)_
+- [Chainlink Grants Program](https://chain.link/community/grants) - _ کمکهای مالی جامعه [Chainlink](https://chain.link/)_
+- [برنامه کمکهای مالی Decentraland](https://governance.decentraland.org/grants/) – _[Decentraland](https://decentraland.org/) DAO Metaverse_
+- [سازمان کمکهای مالی اکوسیستم Lido (LEGO)](https://lido.fi/lego) – _[اکوسیستم تأمین مالی Lido](https://lido.fi/)_
+- [برنامهی Metamask](https://metamaskgrants.org/) - _[سازمان خودمختار غیرمتمرکز کمکهای مالی کارمندمحور MetaMask](https://metamask.io/)_
+- [برنامه کمکهای مالی شبکه SKALE](https://skale.space/developers#grants) - _[اکوسیستم شبکه ](https://skale.space/)SKALE_
+- [برنامه کمک مالی بنیاد Swarm](https://my.ethswarm.org/grants) - _اکوسیستم [بنیاد Swarm](https://www.ethswarm.org/)_
+- [The Graph](https://thegraph.com/ecosystem/grants/) – _اکوسیستم [The Graph](https://thegraph.com/)_
+- [برنامه کمک مالی Uniswap](https://www.uniswapfoundation.org/approach) - _جامعه [Uniswap](https://uniswap.org/)_
+
+## کمک مالی درجهی دوم {#quadratic-funding}
+
+ریشههای متنباز اتریوم منجر به رشد مدل جدید و جالبی از جذب سرمایه شد: کمک مالی درجهی دوم. این مدل بهطور بالقوه میتواند روش کمک مالی ما به انواع و اقسام کارهای عامالمنفعه را بهبود دهد. کمک مالی درجهی دوم اطمینان حاصل میکند پروژههایی سرمایهی بیشتری جذب میکنند که دارای بیشترین تقاضای منحصربهفرد هستند. به عبارت دیگر، پروژههایی که هدفشان بهبود زندگی اکثریت مردم است. [اطلاعات بیشتر درباره کمک مالی درجهی دوم.](/defi/#quadratic-funding)
+
+- [Gitcoin](https://gitcoin.co/grants)
+- [clr.fund](https://clr.fund/)
+
+## کار کردن در اتریوم {#work-in-ethereum}
+
+آیا آمادهی شروع پروژهی شخصی خود نیستید؟ صدها شرکت هستند که به دنبال افراد پرشور برای کار و شرکت در اکوسیستم اتریوم هستند. اطلاعات بیشتر میخواهید؟ [مشاغل مرتبط با اتریوم را بررسی کنید](/community/get-involved/#ethereum-jobs)
diff --git a/public/content/translations/fa/14) Community Pages/community/language-resources/index.md b/public/content/translations/fa/14) Community Pages/community/language-resources/index.md
new file mode 100644
index 00000000000..5d37dbbb7c5
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/language-resources/index.md
@@ -0,0 +1,153 @@
+---
+title: منابع زبانی
+description: منابع غیرانگلیسی برای یادگیری در مورد اتریوم
+lang: fa
+---
+
+# منابع زبانی {#language-resources}
+
+جامعهی اتریوم یک جامعهی جهانی است و متشکل از میلیونها غیرانگلیسی زبان است.
+
+هدف ما ارائهی محتوای آموزشی به همه زبانها و کمک به غلبه بر موانع زبانی است که ورود افراد از سراسر جهان به اتریوم را به چالش تبدیل میکند.
+
+اگر ترجیح میدهید به زبان مادری خود مطالعه کنید یا فردی را میشناسید که انگلیسی صحبت نمیکند، میتوانید فهرستی از منابع مفید غیرانگلیسی را در زیر بیابید. صدها هزار نفر از مشتاقان اتریوم در این انجمنهای آنلاین گرد هم میآیند تا خبرها را به اشتراک بگذارند، درباره پیشرفتهای اخیر صحبت کنند، درباره مسائل فنی بحث کنند و آینده را تصور کنند.
+
+منبع آموزشی به زبان خود میشناسید؟ برای افزودن به فهرست [مسألهای مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new/choose)!
+
+## منابع Ethereum.org {#ethereum-org}
+
+وبسایت Ethereum.org بهطور بومی به بیش از 40 زبان ترجمه شده است که می توانید با استفاده از منوی انتخابگر زبان که در بالای هر صفحه قرار دارد، آنها را بیابید.
+
+![منوی انتخاب زبان](./language-selector-menu.png)
+
+اگر دوزبانه هستید و میخواهید به ما کمک کنید تا افراد بیشتری را جذب کنیم، میتوانید در [برنامهی ترجمه ethereum.org](/contributing/translation-program/#translation-program) نیز مشارکت داشته باشید و به ما کمک کنید تا وبسایت را ترجمه کنیم.
+
+## منابع انجمن {#community}
+
+### پرتغالی برزیلی {#br-pt}
+
+**اخبار**
+
+- [BeInCrypto](http://www.beincrypto.com.br) - اخبار و مقالات ارزهای دیجیتال، از جمله فهرستی از صرافیهای موجود در برزیل
+- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - نسخهی برزیلی Cointelegraph، یک رسانه خبری مهم ارزهای دیجیتال
+- [Livecoins](http://www.livecoins.com.br/ethereum) - ابزارها و اخبار ارزهای رمزنگاریشده
+- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - اخبار و گزارشهای ارزهای رمزنگاریشده
+- [Modular Crypto](https://modularcrypto.xyz/) - اخبار و مقالات آموزشی در مورد رمزارز
+
+**آموزشی**
+
+- [web3dev](https://www.web3dev.com.br/) - مرکز محتوا و انجمن دیسکورد برای توسعهدهندگان web 3.
+- [Web3Brasil](https://github.com/web3brasil/web3brasil) - منابعی برای آموزش Web3 و DeFi
+- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - اخبار و آموزش ارزهای رمزنگاریشده، از جمله «اتریوم برای مبتدیان» و «دیفای» برای مبتدیان
+- [CriptoAtivos](http://www.criptoativos.wiki.br/) - اطلاعاتی از فضای رمزارز، آموزش و وبلاگ
+- [Cointimes](http://www.cointimes.com.br/) - اخبار و آموزش ارزهای رمزنگاریشده
+- [بستهی آغازین Web3](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - راهنمایی برای پاسخ به سؤالات پرتکرار و سؤالات بنیادی ارزهای رمزنگاریشده
+
+### چینی {#zh}
+
+**منابع کلی**
+
+- [Ethereum.cn](https://www.ethereum.cn/) - محتوای نگهداریشده توسط انجمن، پوشش ارتقای لایه اجماع، تمام یادداشتهای گردهماییهای برنامهنویسی هسته، لایهی 2 و غیره.
+- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - همهچیز را از اصول اولیه تا موضوعات پیشرفتهی اتریوم بیاموزید
+- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - محتوای نگهداری شده توسط انجمن، پوشش دانش مرتبط با اتریوم، دیفای، NFT، Web3
+- [123ETH](https://123eth.org/) - دروازهای به اکوسیستم اتریوم
+- [Zhen Xiao](http://zhenxiao.com/blockchain/) - دورههای آنلاین رایگان درباره ارزهای دیجیتال و کاربردهای آن
+- [Whitepaper اتریوم](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6) - نسخهی چینی وایتپیپر
+
+**اکوسیستم اتریوم**
+
+- [ETHPlanet](https://www.ethplanet.org/) - هکاتونهای آنلاین و حضوری، ارائهدهندهی آموزش به دانشجویان دانشگاه
+- [PrimitivesLane](https://www.primitiveslane.org/) - یک گروه تحقیقاتی غیرانتفاعی با تمرکز بر فناوری زنجیرهی بلوکی
+- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - انجمنی که به ترجمهی محتوای آموزشی اتریوم اختصاص دارد
+
+**برای توسعهدهندگان**
+
+- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - یک گروه آموزشی برای مطالعهی پروژههای dapp و تبادل اندیشه و نظرات بهصورت هفتگی
+- [LearnBlockchain](https://learnblockchain.cn/) - انجمنی برای توسعهدهندگان جهت اشتراکگذاری اطلاعات در مورد فناوری زنجیرهی بلوکی
+
+**برای محققین رمزنگاری**
+
+- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - یک حساب WeChat که رمزنگاری، امنیت و غیره را توضیح میدهد
+- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - یک حساب WeChat که فناوری zk را توضیح میدهد
+
+### چک {#cs}
+
+- [Gwei.cz](https://gwei.cz) - جامعهی محلی با محوریت Web3 که محتوای آموزشی تولید میکند و رویدادهای آنلاین و حضوری را ساماندهی میکند
+- [Gwei.cz Příručka](https://prirucka.gwei.cz/) - راهنمای اتریوم برای مبتدیان
+- [DAO Příručka](https://dao.gwei.cz/) - راهنمای DAOها برای مبتدیان
+- [تبحر در اتریوم](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - یادگیری زیروبم اتریوم به زبان چک
+
+### فرانسوی {#fr}
+
+- [اتریوم فرانسه](https://www.ethereum-france.com/) - اتریوم فرانسه رویدادها را سازماندهی میکند، محتوا تولید میکند و بحثهای مربوط به اتریوم را ترویج میکند
+- [Ethereum.fr](https://ethereum.fr/) - اخبار و آموزش اتریوم
+- [BanklessFR](https://banklessfr.substack.com/) - خبرنامهی Bankless به زبان فرانسوی
+- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - انجمن ارزهای رمزنگاری شده با زیرصفحهای برای اتریوم
+
+### آلمانی {#de}
+
+- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - از Solidity استفاده کنید
+- [Microsoft Learn (قراردادهای هوشمند)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - نوشتن قراردادهای هوشمند اتریوم با Solidity
+- [Microsoft Learn (شبکههای اتریوم)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - آموزش اتصال به شبکههای اتریومی و استقرار آنها
+- [Microsoft Learn (زنیرههای بلوکی)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - ورود به حوزهی توسعهی زنجیرهی بلوکی
+
+### عبری {#he}
+
+- [Udi Wertheimer - چیزهایی که کاربران بیت کوین می توانند از Ethereum یاد بگیرند](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/)
+- [عمر گرایسمان (OpenZeppelin) - چگونه از هک 15 میلیارد دلاری قرارداد هوشمند جلوگیری کردیم](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/)
+- [شای داتیکا (INX) - توکنیزه کردن و آینده وثیقه ها، از جمله این که آیا اتریوم یک وثیقه است](https://www.cryptojungle.co.il/shy-datika-tokenization/)
+- [روی کونفینو (Lemonade) - بیمه در اتریوم](https://www.cryptojungle.co.il/roy-confino-insurance/)
+- [ایدان اُفرات (Fireblocks) - پذیرش موسسهای](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/)
+- [گل وایزمن (MetaMask) - MetaMask چیست؟](https://www.cryptojungle.co.il/gal-weizman-metamask/)
+- [درور اَویلی (Consensys) - مرکز اتریوم](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/)
+- [نیر روزین - کریپتوپانک بودن](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/)
+- [اَدَن کِدِم - بازی & Metaverse](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/)
+- [اوری کولودنی (Starkware) - اتریوم و لایههای بلاکچین](https://www.cryptojungle.co.il/uri-kolodny-starkware/)
+- [اودی وِرتهایمر - اتریوم 2.0 در برابر رقابت](https://www.cryptojungle.co.il/udi-on-eth2/)
+- [بن ساموچا (myself) - اتریوم 2.0 - یک فرصت؟](https://www.cryptojungle.co.il/etherurm2-week-summary/)
+- [الان موراچ (Bloxstaking) - اتریوم 2.0 چیست؟](https://www.cryptojungle.co.il/alon-moroch-eth2/)
+- [ایلوم اَویو (Collider Ventures) - مشکل اتریوم 2.0 چه چیز میتواند باشد؟](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/)
+- [ایلون اَویو (Collider Ventures) - چرا به اتریوم 2.0 نیاز داریم؟](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/)
+
+### ایتالیایی {#it}
+
+- [اتریوم ایتالیا](https://www.ethereum-italia.it/) - آموزش، رویدادها و اخبار اتریوم با تمرکز بر قراردادهای هوشمند و فناوری زنجیرهی بلوکی
+- [پادکست اتریوم ایتالیا](https://www.ethereum-italia.it/podcast/) - پادکست اتریوم به زبان ایتالیایی
+- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - یاد بگیرید چگونه از Solidity استفاده کنید
+- [Microsoft Learn (قراردادهای هوشمند)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - با نوشتن قراردادهای هوشمند با استفاده از Solidity آشنا شوید
+- [Microsoft Learn (dappها)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) - یک رابط کاربری با برنامههای غیرمتمرکز بسازید
+
+### ژاپنی {#ja}
+
+- [انجمن تبادل داراییهای مجازی و رمزنگاریشدهی ژاپن](https://jvcea.or.jp/)
+- [انجمن تجارت داراییهای رمزنگاریشدهی ژاپن](https://cryptocurrency-association.org/)
+- [با توسعهی زنجیرهی بلوکی شروع کنید - بیاموزید | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - این سایت، شما را با مسیر یادگیری زنجیرهی بلوکی و توسعه در پلتفرم اتریوم آشنا میکند
+- [تبحر در اتریوم](https://www.oreilly.co.jp/books/9784873118963/) - یادگیری زیروبم اتریوم به زبان ژاپنی
+- [توسعهی قراردادهای هوشمند بهصورت عملی با Solidity و اتریوم](https://www.oreilly.co.jp/books/9784873119342/) - توسعهی قراردادهای هوشمند عملی با Solidity و اتریوم به زبان ژاپنی
+
+### روسی {#ru}
+
+- [آکادمی سایبر](https://cyberacademy.dev) - فضای آموزشی برای سازندگان وب 3
+- [Forklog](https://forklog.com) - اخبار و مقالات درباره کریپتو به طور کلی، فنآوریهای موجود و ارتقاهای آینده بلاکچینهای متفاوت
+- [BeInCrypto](https://ru.beincrypto.com) - اخبار، تحلیل قیمت کریپتو و مقالات غیرفنآوری با توضیحات ساده درباره همهچیز در کریپتو
+
+### اسپانیایی {#es}
+
+- [اتریوم مادرید](https://ethereummadrid.com/) - دورهها، رویدادها و وبلاگ در مورد زنجیرهی بلوکی، DeFi و حاکمیت
+- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - راهنمای اتریوم برای مبتدیان به زبان اسپانیایی
+- [Tutoriales online](https://tutoriales.online/curso/solidity) - Solidity و برنامهنویسی در اتریوم را بیاموزید
+- [دورهی معرفی توسعهی اتریوم](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - اصول Solidity، تست کردن و ساختن اولین قرارداد هوشمند خود
+- [دوره مقدماتی امنیت و هک در اتریوم](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - آسیبپذیریها و مشکلات امنیتی رایج در قراردادهای هوشمند واقعی را متوجه شوید
+- [مقدمه ای بر دورهی توسعه DeFi](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - یاد بگیرید که قراردادهای هوشمند دیفای چگونه با Solidity کار میکنند و بازارساز خودکار (Automated Market Maker) خود را بسازید
+- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - آموزش زنجیرهی بلوکی به زبان غیرفنی از سطح مقدماتی تا سطح پیشرفته. همهچیز را دربارهی رمزارز و اتریوم یاد بگیرید.
+
+### ترکی استانبولی {#tr}
+
+- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - دورهی آموزشی با تمرکز بر زنجیرهی بلوکی و رمزارزها
+- [تغییر نام عالی: چه اتفاقی برای Eth2 افتاد؟](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - ترجمهی ترکی پست وبلاگی تغییر نام عالی که فاصله گرفتن از اصطلاح «Eth2» را توضیح میدهد
+
+### ویتنامی {#vi}
+
+- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - مرور کلی اتریوم، dAppها، کیف پولها و سؤالات متداول
+- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - پلتفرم وب با زیرصفحاتی در مورد اخبار و آموزش اتریوم
+- [Coin68](https://coin68.com/ethereum-tieu-diem/) - درگاه رمزارزها با اخبار و محتوای آموزشی اتریومی
diff --git a/public/content/translations/fa/14) Community Pages/community/online/index.md b/public/content/translations/fa/14) Community Pages/community/online/index.md
new file mode 100644
index 00000000000..0410fdb710c
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/online/index.md
@@ -0,0 +1,50 @@
+---
+title: جوامع آنلاین
+description: فهرستی از برنامههای کمک هزینه از سرتاسر اکوسیستم اتریوم.
+lang: fa
+---
+
+# جوامع آنلاین {#online-communities}
+
+صدها هزار نفر از مشتاقان اتریوم در این انجمنهای آنلاین گرد هم میآیند تا خبرها را به اشتراک بگذارند، درباره پیشرفتهای اخیر صحبت کنند، درباره مسائل فنی بحث کنند و آینده را تصور کنند.
+
+## انجمنها {#forums}
+
+r/ethereum - همهچیز اتریوم
+r/ethfinance - جنبهی مالی اتریوم، از جمله دیفای
+r/ethdev - متمرکز بر توسعهی اتریوم
+r/ethtrader - روندها و تحلیل بازار
+r/ethstaker - خوشآمدگویی به همهی علاقهمندان به سهامگذاری در اتریوم
+Fellowship of Ethereum Magicians - جامعهای با محوریت استانداردهای فنی در اتریوم
+Ethereum Stackexchange - بحث و کمک برای توسعهدهندگان اتریوم
+Ethereum Research - تأثیرگذارترین تالار گفتگ برای تحقیقات اقتصادی رمزارزها
+
+## اتاقهای گفتگو {#chat-rooms}
+
+Cat Herderهای اتریوم - جامعهای با محوریت ارائهی کمک در بحث مدیریت پروژه برای توسعهی اتریوم
+هکرهای اتریوم - فضای گفتگوی Discord تحت مدیریت ETHGlobal: یک انجمن آنلاین برای هکرهای اتریوم در سراسر جهان
+CryptoDevs - انجمن Discord متمرکز بر توسعهی اتریوم
+دیسکورد EthStaker - راهنمایی، آموزش، حمایت و مجموعه منابعی برای سهام گذاران کنونی و آینده که از سوی اعضای جامعه Ethstaker تهیه شده و اداره میشود
+تیم وب سایت Ethereum.org - با تیم و افراد جامعه توسعه و طراحی وب ethereum.org گفتگو کنید
+دیسکورد Matos - جامعه خالقان web3 که در آن سازندگان، چهرههای مطرح صنعت و علاقهمندان به اتریوم دور هم جمع میشوند. ما مشتاق توسعه، طراحی و فرهنگ Web3 هستیم. بیایید در ساختن، همراه ما شوید.
+Solidity Gitter - فضای گفتگو برای توسعه solidity (Gitter)
+Solidity Matrix - فضای گفتگو برای توسعه solidity (Matrix)
+بورس سهام اتریوم *- انجمن پرسش و پاسخ*
+Peeranha *- انجمن پرسش و پاسخ غیرمتمرکز*
+
+## یوتیوب و توییتر {#youtube-and-twitter}
+
+بنیاد اتریوم - از تازهترین اخبار «بنیاد اتریوم» مطلع شوید
+@ethereum - حساب رسمی بنیاد اتریوم
+@ethdotorg - پایگاه اینترنتی اتریوم، ساختهشده برای جامعهی جهانی در حال رشد ما
+فهرست حسابهای تأثیرگذار اتریوم در توییتر
+
+
+
+
+
+
+ درباره DAOها بیشتر بدانید
+
+
+
diff --git a/public/content/translations/fa/14) Community Pages/community/research/index.md b/public/content/translations/fa/14) Community Pages/community/research/index.md
new file mode 100644
index 00000000000..a57086aa479
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/research/index.md
@@ -0,0 +1,399 @@
+---
+title: حوزههای تحقیقات در حال انجام در اتریوم
+description: حوزههای مختلف تحقیق باز را کاوش کنید و یاد بگیرید که چگونه مشارکت کنید.
+lang: fa
+---
+
+# حوزه های فعال تحقیقات اتریوم {#active-areas-of-ethereum-research}
+
+یکی از نقاط قوت اولیه اتریوم این است که یک جامعه تحقیق و مهندسی فعال به طور مداوم آن را بهبود می بخشد. بسیاری از افراد ماهر و مشتاق در سرتاسر جهان مشتاقند که در زمینه مسائل مهم اتریوم مشغول به کار شوند اما فهمیدن آن که کدام مسائل در درجه اول اهمیت قرار دارند همیشه آسان نیست. این صفحه، به عنوان یک راهنمایی کلی درباره آخرین پیشرفتهای اتریوم، به حوزههای تحقیقاتی مهم و کلیدی اشاره میکند.
+
+## تحقیقات اتریوم چطور کار میکند {#how-ethereum-research-works}
+
+تحقیقات اتریوم باز و شفاف است و اصول [علم غیرمتمرکز (DeSci)] (https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science) را در بر می گیرد. یکی از اصول اتریوم این است که ابزارها و خروجیهای تحقیق تا حد امکان در دسترس و تعاملی باشند، مثلاً از طریق دفترچههای قابل اجرا. تحقیقات اتریوم بهسرعت پیش میرود و یافتههای جدید در انجمنهایی مانند [ethresear.ch](https://ethresear.ch/) پست شده و مورد بحث قرار میگیرد، نه اینکه پس از دورهای بررسی همتایان از طریق انتشارات سنتی به جامعه برسد.
+
+## منابع تحقیقات عمومی {#general-research-resources}
+
+صرف نظر از موضوع خاص، اطلاعات زیادی در مورد تحقیقات اتریوم در [ethresear.ch](https://ethresear.ch) و [کانال Eth R&D Discord](https://discord.gg/qGpsxSA) وجود دارد. این دو اصلیترین منابعی هستند که محققان اتریوم درباره آخرین ایدهها و فرصتهای توسعه در آنجا بحث و تبادل نظر میکنند.
+
+این گزارش که در ماه می 2022 توسط [DelphiDigital] (https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) منتشر شده است، نمای کلی خوبی از نقشه راه اتریوم ارائه می دهد.
+
+## منابع تامین هزینه {#sources-of-funding}
+
+شما میتوانید برای شرکت در پروژههای تحقیقاتی اتریوم دستمزد بگیرید! به عنوان مثال، [بنیاد اتریوم](/foundation/) اخیراً یک [دور کمک های مالی دانشگاهی] (https://esp.ethereum.foundation/academic-grants) را اجرا کرد. میتوانید اطلاعات مربوط به فرصتهای مالی فعال و آینده را در [صفحه کمکهای مالی اتریوم] (/community/grants/) بیابید.
+
+## تحقیقات پروتکل {#protocol-research}
+
+تحقیقات پروتکل به لایه پایه اتریوم برمیگردد - این لایه مجموعهای از قوانینیست که نحوه اتصال، ارتباط، تبادل و ذخیره دادههای اتریوم توسط گرهها را تعریف میکنند و در مورد وضعیت بلاکچین به اجماع میرسند. تحقیقات پروتکل به دو دسته تقسیم میشود: اجماع و اجرا.
+
+### اجماع {#consensus}
+
+تحقیقات اجماع مربوط به [مکانیزم اثبات سهام اتریوم] (/developers/docs/consensus-mechanisms/pos/) است. چند نمونه از موضوعات تحقیق اجماع عبارتند از:
+
+- شناسایی و اصلاح آسیبپذیریها؛
+- کمی کردن امنیت اقتصاد رمزنگاری؛
+- افزایش امنیت یا عملکرد اجراهای کاربر؛
+- و توسعه کاربرهای سبک.
+
+علاوه بر تحقیقات آیندهنگر، برای بهبود عمده اتریوم، در حال حاضر تحقیق روی برخی از طراحیهای مجدد و مهم پروتکل، مانند نهایی شدن تک اسلات، نیز در جریان است. علاوه بر این، کارایی، ایمنی و نظارت بر شبکههای همتا به همتا بین کاربرهای اجماع نیز از موضوعات مهم تحقیقاتی است.
+
+#### مطالعه پیشزمینه {#background-reading}
+
+- [مقدمه ای بر اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+- [مقاله Casper-FFG](https://arxiv.org/abs/1710.09437)
+- [شرح Casper-FFG](https://arxiv.org/abs/1710.09437)
+- [مقاله Gasper](https://arxiv.org/abs/2003.03052)
+
+#### تحقیقات اخیر {#recent-research}
+
+- [اجماع Ethresear.ch](https://ethresear.ch/c/consensus/29)
+- [دوراهی دسترسیپذیری/نهاییپذیری](https://arxiv.org/abs/2009.04987)
+- [نهاییسازی تک اسلات](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259)
+- [تفکیک پیشنهاددهنده-سازنده](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
+
+### اجرا {#execution}
+
+لایه اجرا مربوط به اجرای تراکنشها، اجرای [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) و تولید بارهای اجرایی برای انتقال به لایه اجماع است. در این حوزه موضوعات فعالی برای تحقیق وجود دارد، از جمله:
+
+- پشتیبانی کاربر سبک؛
+- تحقیق در مورد حدود گس؛
+- و گنجاندن ساختارهای داده جدید (به عنوان مثال Verkle Tries).
+
+#### مطالعه پیشزمینه {#background-reading-1}
+
+- [مقدمه ای بر ماشین مجازی اتریوم](/developers/docs/evm)
+- [لایه اجرای Ethresear.ch](https://ethresear.ch/c/execution-layer-research/37)
+
+#### تحقیقات اخیر {#recent-research-1}
+
+- [بهینه سازی های پایگاه داده](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md)
+- [انقضای حالت] (https://notes.ethereum.org/@vbuterin/state_expiry_eip)
+- [راه های انقضای حالت](https://hackmd.io/@vbuterin/state_expiry_paths)
+- [پیشنهاد انقضای Verkle و حالت](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal)
+- [مدیریت سابقه] (https://eips.ethereum.org/EIPS/eip-4444)
+- [درختان Verkle](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
+- [نمونهسازی در دسترس بودن داده](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)
+
+## توسعه کاربر {#client-development}
+
+کاربرهای اتریوم در واقع اجراهای پروتکل اتریوم هستند. توسعه کاربر نتایج تحقیقات پروتکل را با ساختن آنها در این کاربرها به واقعیت تبدیل میکند. توسعه کاربر شامل به روز رسانی ویژگیهای کاربر و نیز ایجاد اجراهای ویژه است.
+
+برای اجرای دو بخش از نرمافزار به یک گره اتریوم نیاز است:
+
+1. کاربر اجماع برای ردیابی راس بلاکچین، بلوکهای بیمورد و مدیریت منطق اجماع
+2. یک کاربر اجرا برای پشتیبانی ماشین مجازی اتریوم و اجرای تراکنشها و قراردادهای هوشمند
+
+برای جزئیات بیشتر در مورد گرهها و کاربرها و فهرستی از تمام اجراهای کاربر فعلی، به [صفحه گرهها و کاربرها](/developers/docs/nodes-and-clients/) مراجعه کنید. همچنین میتوانید تاریخچه تمام ارتقاهای اتریوم را در [صفحه تاریخچه] (/history/) بیابید.
+
+### کاربرهای اجرا {#execution-clients}
+
+- [مشخصات کاربر اجرا](https://github.com/ethereum/execution-specs)
+- [مشخصات API اجرا](https://github.com/ethereum/execution-apis)
+
+### کاربرهای اجماع {#consensus-clients}
+
+- [مشخصات کاربر اجماع](https://github.com/ethereum/consensus-specs)
+- [مشخصات API بیکن](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot)
+
+## مقیاسپذیری و عملکرد {#scaling-and-performance}
+
+مقیاسپذیری اتریوم برای محققان اتریوم جای پژوهش زیادی دارد. رویکردهای فعلی شامل بارگذاری تراکنشها روی رول-آپها و ارزانتر کردن آنها با استفاده از تودههای داده متمرکز است. اطلاعات مقدماتی در مورد مقیاسپذیری اتریوم در [صفحه مقیاسپذیری] ما در دسترس است (/developers/docs/scaling).
+
+### لایه 2 {#layer-2}
+
+در حال حاضر چندین پروتکل لایه 2 وجود دارد که با استفاده از تکنیکهای مختلف برای دستهبندی تراکنشها و ایمن کردن آنها در لایه 1، اتریوم را مقیاسبندی میکنند. این بخش به سرعت در حال رشد است و پتانسیل تحقیق و توسعه زیادی دارد.
+
+#### مطالعه پیشزمینه {#background-reading-2}
+
+- [معرفی لایه 2](/layer-2/)
+- [Polynya: رولآپها، DA و زنجیرههای مدولار](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d)
+
+#### تحقیقات اخیر {#recent-research-2}
+
+- [ترتیب منصفانه آربیتروم برای ترتیب دهنده ها](https://eprint.iacr.org/2021/1465)
+- [لایه 2 ethresear.ch](https://ethresear.ch/c/layer-2/32)
+- [نقشه راه رول آپ محور](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)
+- [L2Beat](https://l2beat.com/)
+
+### پل ها {#bridges}
+
+یکی از حوزههای لایه 2 که نیاز به تحقیق و توسعه بیشتر دارد، پلهای ایمن و کارآمدند. این شامل پلهایی بین لایههای 2 مختلف و پلهای بین لایه 1 و لایه 2 است. این حوزه تحقیقاتی بسیار مهمی است زیرا پلها از اهداف مورد علاقه هکرها هستند.
+
+#### مطالعه پیشزمینه {#background-reading-3}
+
+- [مقدمه ای بر پل های بلاکچین](/bridges/)
+- [مقاله ویتالیک درباره پل ها](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/)
+- [مقاله پلهای بلاکچین](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8)
+- [ارزش محبوس در پلها](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\))
+
+#### تحقیقات اخیر {#recent-research-3}
+
+- [پلهای اعتبارسنجی](https://stonecoldpat.github.io/images/validatingbridges.pdf)
+
+### زنجیرهایسازی {#sharding}
+
+زنجیرهای سازی بلاکچین اتریوم مدتهاست که بخشی از نقشه راه توسعه بوده است. با این حال، راهحلهای مقیاسبندی جدید مانند دنکشاردینگ در حال حاضر در مرکز توجهاند.
+
+پیشرو برای دنک شاردینگ کامل که با عنوان پروتو-دنک شاردینگ شناخته میشود، با ارتقاء شبکه Cancun-Deneb ("Dencun") فعال شد.
+
+[اطلاعات بیشتر در مورد ارتقاء Dencun](/roadmap/dencun/)
+
+#### مطالعه پیشزمینه {#background-reading-4}
+
+- [یادداشتهای پروتو-دنکشاردینگ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq)
+- [ویدیوی دنکشاردینگ بدون بانک](https://www.youtube.com/watch?v=N5p0TB77flM)
+- [خلاصه تحقیق زنجیرهایسازی اتریوم](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view)
+- [دنکشاردینگ (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe)
+
+#### تحقیقات اخیر {#recent-research-4}
+
+- [EIP-4844: پروتو-دنکشاردینگ](https://eips.ethereum.org/EIPS/eip-4844)
+- [نظر ویتالیک درباره زنجیرهایسازی و نمونهسازی دسترسی داده](https://hackmd.io/@vbuterin/sharding_proposal)
+
+### سخت افزار {#hardware}
+
+[گرههای در حال اجرا](/developers/docs/nodes-and-clients/run-a-node/) روی سختافزار متوسط، برای غیرمتمرکز نگه داشتن اتریوم ضروری است. بنابراین، بررسی راههای به حداقل رساندن نیازهای سختافزاری برای اجرای گرهها یکی از حوزههای مهم تحقیقات است.
+
+#### مطالعه پیشزمینه {#background-reading-5}
+
+- [اتریوم در ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)
+
+#### تحقیقات اخیر {#recent-research-5}
+
+- [ecdsa در FPGAها](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738)
+
+## امنیت {#security}
+
+امنیت شبکه، حوزه گستردهای است که جلوگیری از هرزنامه/کلاهبرداری، امنیت کیف پول، امنیت سختافزار، امنیت ارز دیجیتال، پیدا کردن باگها و آزمایش اپلیکیشنها و نرمافزار کاربر و مدیریت کلید را در بر میگیرد. انباشت اطلاعات در این زمینه به افزایش پذیرش در جریان اصلی کمک میکند.
+
+### رمزنگاری و ZKP {#cryptography--zkp}
+
+اثباتهای دانش صفر (ZKP) و رمزنگاری، برای حفظ حریم خصوصی و امنیت در اتریوم و اپلیکیشنهای آن حیاتیاند. دانش صفر، فضایی نسبتا جدید اما به سرعت در حال پیشرفت است و در خود فرصتهای زیادی برای توسعه و تحقیق دارد. برخی از احتمالات عبارتند از توسعه پیادهسازیهای کارآمدتر [الگوریتم هشسازی Keccak] (https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview)، یافتن تعهدات چند جمله ای بهتر از آنچه در حال حاضر وجود دارد یا کاهش هزینه تولید کلید عمومی ecdsa و مدارهای تأیید امضا.
+
+#### مطالعه پیشزمینه {#background-reading-6}
+
+- [0xparc blog](https://0xparc.org/blog)
+- [zkp.science](https://zkp.science/)
+- [پادکست دانش صفر](https://zeroknowledge.fm/)
+
+#### تحقیقات اخیر {#recent-research-6}
+
+- [پیشرفت اخیر در رمزنگاری منحنی بیضی](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346)
+- [Ethresear.ch ZK](https://ethresear.ch/c/zk-s-nt-arks/13)
+
+### کیف پول ها {#wallets}
+
+کیف پولهای اتریوم به شکل افزونههای مرورگر، اپلیکیشنهای دسکتاپ و موبایل یا قراردادهای هوشمند روی اتریوم در دسترساند. کیف پولهای بازیابی اجتماعی همچنان موضوع مهمی برای بررسی و پژوهشاند که برخی از خطرات مربوط به مدیریت کلید کاربر را کاهش میدهند. همراه با توسعه کیفهای پول، اشکال جایگزین انتزاع حساب هم حوزه تحقیقات مهم اما نوپایی است.
+
+#### مطالعه پیشزمینه {#background-reading-7}
+
+- [معرفی کیف های پول](/wallets/)
+- [مقدمه ای بر امنیت کیف پول](/security/)
+- [ethresear.ch امنیت](https://ethresear.ch/tag/security)
+- [EIP-2938 انتزاع حساب](https://eips.ethereum.org/EIPS/eip-2938)
+- [EIP-4337 انتزاع حساب](https://eips.ethereum.org/EIPS/eip-4337)
+
+#### تحقیقات اخیر {#recent-research-7}
+
+- [کیفپولهای قرارداد هوشمند متمرکز بر اعتبارسنجی](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603)
+- [آینده حساب ها](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603)
+- [کدگذاری های EIP-3074 AUTH و AUTHCALL](https://eips.ethereum.org/EIPS/eip-3074)
+- [انتشار کد در یک آدرس EOA] (https://eips.ethereum.org/EIPS/eip-5003)
+
+## جامعه، آموزش و پشتیبانی {#community-education-and-outreach}
+
+اتریوم برای جذب کاربران جدید به منابع آموزشی و رویکردهای جدید برای پشتیبانی نیازمند است. این ممکن است شامل پستها و مقالات وبلاگ، کتابها، پادکستها، میمها، منابع آموزشی، رویدادها و هر چیز دیگری باشد که باعث ایجاد انجمنها، استقبال از شروعکنندگان جدید و آموزش مردم در مورد اتریوم میشود.
+
+### UX/UI {#uxui}
+
+همچنین برای جذب کاربران بیشتر به اتریوم، اکوسیستم باید UX/UI را بهبود بخشد. این امر مستلزم آن است که طراحان و کارشناسان محصول، طرح کیف پولها و اپلیکیشنها را دوباره بررسی کنند.
+
+#### مطالعه پیشزمینه {#background-reading-8}
+
+- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24)
+
+#### تحقیقات اخیر {#recent-research-8}
+
+- [دیسکورد طرح Web3](https://discord.gg/FsCFPMTSm9)
+- [اصول طراحی Web3] (https://www.web3designprinciples.com/)
+- [بحث UX جادوگران اتریوم](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3)
+
+### اقتصاد {#economics}
+
+تحقیقات اقتصادی در اتریوم دو رویکرد مشخص دارند: اعتبارسنجی امنیت مکانیسمهای متکی بر انگیزههای اقتصادی (اقتصاد خرد) و تجزیه و تحلیل جریانهای ارزش بین پروتکلها، اپلیکیشنها و کاربران (اقتصاد کلان). فاکتورهای پیچیده اقتصاد کریپتو در رابطه با توکن اتریوم (اتر) و توکنهای ساخته شده روی آن (به عنوان مثال NFTها و توکنهای ERC20) وجود دارد.
+
+#### مطالعه پیشزمینه {#background-reading-9}
+
+- [گروه مشوق های بزرگ](https://ethereum.github.io/rig/)
+- [کارگاه ETHconomics در Devconnect](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm)
+
+#### تحقیقات اخیر {#recent-research-9}
+
+- [تحلیل تجربی EIP1559](https://arxiv.org/abs/2201.05574)
+- [تعادل عرضه در حال گردش](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954)
+- [کمی سازی MEV: جنگل چقدر تاریک است؟](https://arxiv.org/abs/2101.05511)
+
+### فضای بلوک و بازارهای کارمزد {#blockspace-fee-markets}
+
+بازارهای بلاکاسپیس، شمول تراکنشهای کاربر نهایی، چه به طور مستقیم در اتریوم (لایه 1) یا در پلها، به عنوان مثال، رول-آپها (لایه 2) را کنترل میکنند. تراکنشها در اتریوم به بازار کارمزد فرستاده میشوند که درون پروتکل بهعنوان EIP-1559 اجرا شده و از شبکه در برابر اسپمها و تراکم قیمتگذاری محافظت میکند. در هر دو لایه، تراکنشها ممکن است تأثیرات بیرونی داشته باشند که به عنوان حداکثر ارزش استخراج (MEV) شناخته میشود، که باعث خواهد شد ساختارهای بازار جدید این تاثیرات را بگیرند یا مدیریت کنند.
+
+#### مطالعه پیشزمینه {#background-reading-10}
+
+- [طراحی مکانیزم کارمزد تراکنش برای بلاک چین اتریوم: تحلیل اقتصادی EIP-1559 (تیم رافگاردن، 2020)](https://timroughgarden.org/papers/eip1559.pdf)
+- [شبیهسازی EIP-1559 (گروه مشوقهای قوی)] (https://ethereum.github.io/abm1559)
+- [اقتصاد رولآپ از اصول اولیه](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url)
+- [Flash Boys 2.0: پیشروی، ترتیب دوباره تراکنش، و ناپایداری اجماع در صرافیهای غیرمتمرکز](https://arxiv.org/abs/1904.05234)
+
+#### تحقیقات اخیر {#recent-research-10}
+
+- [ارائه ویدئویی چند بعدی EIP-1559](https://youtu.be/QbR4MTgnCko)
+- [MEV چند دامنهای](http://arxiv.org/abs/2112.01472)
+- [حراجهای MEV](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788)
+
+### مشوقهای اثبات سهام {#proof-of-stake-incentives}
+
+اعتبارسنجها، از دارایی بومی اتریوم (اتر) برای جلوگیری از رفتارهای غیرصادقانه به عنوان وثیقه استفاده میکنند. اقتصاد کریپتویی آن، امنیت شبکه را تضمین میکند. اعتبارسنجهای پیشرفته، میتوانند با سوءاستفاده از تفاوتهای جزئی لایه پاداش، حملات صریحی برای شبکه تدارک ببینند.
+
+#### مطالعه پیشزمینه {#background-reading-11}
+
+- [مستر کلاس اقتصاد اتریوم و مدل اقتصادی](https://github.com/CADLabs/ethereum-economic-model)
+- [شبیهسازیهای مشوقهای PoS (گروه مشوقهای قوی)] (https://ethereum.github.io/beaconrunner/)
+
+#### تحقیقات اخیر {#recent-research-11}
+
+- [افزایش مقاومت سانسوری تراکنشها تحت جداسازی پیشنهاددهنده/سازنده (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ)
+- [سه حمله به اثبات سهام اتریوم](https://arxiv.org/abs/2110.10086)
+
+### سهامگذاری نقد و مشتقات {#liquid-staking-and-derivatives}
+
+کاربرانی که کمتر از 32 اتر دارند با سهام گذاری نقدینه میتوانند با معاوضه توکنی که اتر سهام گذاری شده را نمایندگی میکند سود دریافت کنند. با این حال، انگیزهها و پویاییهای بازار مرتبط با سهام گذاری نقدینه و همچنین تأثیر آن بر امنیت اتریوم (مانند خطرات متمرکز شدن) هنوز باید بررسی شود.
+
+#### Background reading {#background-reading-12}
+
+- [Ethresear.ch liquid staking](https://ethresear.ch/search?q=liquid%20staking)
+- [Lido: The road to trustless Ethereum staking](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/)
+- [Rocket Pool: Staking protocol introduction](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd)
+
+#### Recent research {#recent-research-12}
+
+- [Handling withdrawals from Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873)
+- [Withdrawal credentials](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722)
+- [The risks of Liquid Staking Derivatives](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
+
+## Testing {#testing}
+
+### Formal verification {#formal-verification}
+
+راستیآزمایی رسمی، نوشتن کدی برای تأیید صحت و بدون اشکال بودن مشخصات اجماع اتریوم است. یک نسخه قابل اجرا از مشخصات نوشته شده در Python وجود دارد که نیاز به نگهداری و توسعه دارد. تحقیقات بیشتر میتواند به بهبود پیادهسازی مشخصات Python کمک کند و ابزارهایی را اضافه کند که سلامت شبکه را قویاً تأیید و مشکلات آن را شناسایی کنند.
+
+#### Background reading {#background-reading-13}
+
+- [Introduction to formal verification](https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html)
+- [Formal Verification (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf)
+
+#### Recent research {#recent-research-13}
+
+- [Formal verification of the deposit contract](https://github.com/runtimeverification/deposit-contract-verification)
+- [Formal verification of the Beacon Chain specification](https://github.com/runtimeverification/deposit-contract-verification)
+
+## Data science and analytics {#data-science-and-analytics}
+
+برای آگاهی از فعالیت در اتریوم و سلامت شبکه نیاز به ابزارهای تجزیه و تحلیل داده ها و داشبوردهای بیشتری وجود دارد.
+
+### Background reading {#background-reading-14}
+
+- [Dune Analytics](https://dune.com/browse/dashboards)
+- [Client diversity dashboard](https://clientdiversity.org/)
+
+#### Recent research {#recent-research-14}
+
+- [Robust Incentives Group Data Analysis](https://ethereum.github.io/rig/)
+
+## Apps and tooling {#apps-and-tooling}
+
+لایه اپلیکیشن از اکوسیستم متنوعی از برنامهها پشتیبانی میکند که تراکنشها را در لایه پایه اتریوم مستقر میکنند. تیم توسعه، با ایجاد نسخههای قابل ترکیب، بینیاز از مجوز و مقاوم در برابر سانسور از برنامههای مهم Web2 یا ایجاد مفاهیم کاملاً جدید بومی Web3، بهصورت پیوسته در حال یافتن راههای جدیدی برای استفاده از اتریوم است. در همین زمان، ابزار جدیدی در حال توسعه است که باعث میشود ساخت اپلیکیشنهای غیرمتمرکز در اتریوم سادهتر شود.
+
+### DeFi {#defi}
+
+امور مالی غیرمتمرکز (DeFi) یکی از کلاسهای اصلی اپلیکیشنهای ساخته شده بر روی اتریوم است. هدف DeFi ایجاد «لگوهای پول» قابل ترکیب است که با آن کاربران میتوانند با استفاده از قراردادهای هوشمند داراییهای رمزارزی را ذخیره کنند، انتقال دهند، وام بگیرند و روی رمزارزها سرمایهگذاری کنند. دیفای با سرعت بالایی در حال پیشرفت و بهروزرسانی است. تحقیق در مورد پروتکلهای ایمن، کارآمد و قابل دسترس، به صورت مستمر ضروری است.
+
+#### Background reading {#background-reading-15}
+
+- [DeFi](/defi/)
+- [Coinbase: What is DeFi?](https://www.coinbase.com/learn/crypto-basics/what-is-defi)
+
+#### Recent research {#recent-research-15}
+
+- [Decentralized finance, centralized ownership?](https://arxiv.org/pdf/2012.09306.pdf)
+- [Optimism: The road to sub-dollar transactions](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92)
+
+### DAOs {#daos}
+
+سازماندهی غیرمتمرکز با DAO ها یکی از موارد قابل توجه از اتریوم است. در مورد اینکه چطور میتوان برای اجرای فرمهای بهتر حکمرانی، بهعنوان یک ابزار هماهنگی با حداقل اعتماد، DAOها را در اتریوم توسعه داد، تحقیقات زیادی در حال انجام است.
+
+#### Background reading {#background-reading-16}
+
+- [Introduction to DAOs](/dao/)
+- [Dao Collective](https://daocollective.xyz/)
+
+#### Recent research {#recent-research-16}
+
+- [Mapping the DAO ecosystem](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy)
+
+### Developer tools {#developer-tools}
+
+ابزارهای توسعهدهندگان اتریوم به سرعت در حال بهبودند. تحقیقات و توسعههای زیادی در این زمینه عمومی در حال انجام است.
+
+#### Background reading {#background-reading-17}
+
+- [Tooling by programming language](/developers/docs/programming-languages/)
+- [Developer Frameworks](/developers/docs/frameworks/)
+- [Consensus developer tools list](https://github.com/ConsenSys/ethereum-developer-tools-list)
+- [Token standards](/developers/docs/standards/tokens/)
+- [CryptoDevHub: EVM Tools](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools)
+
+#### Recent research {#recent-research-17}
+
+- [Eth R&D Discord Consensus Tooling channel](https://discordapp.com/channels/595666850260713488/746343380900118528)
+
+### Oracles {#oracles}
+
+اوراکلها دادههای بیرون از زنجیره را به روشی بینیاز از مجوز و غیرمتمرکز وارد بلاکچین میکنند. با دریافت این دادهها در زنجیره، اپلیکیشنهای غیرمتمرکز میتوانند نسبت به پدیدههای دنیای واقعی مانند نوسانات قیمت در داراییهای دنیای واقعی، رویدادهای اپلیکیشنهای خارج از زنجیره یا حتی تغییرات آبوهوا واکنش نشان دهند.
+
+#### Background reading {#background-reading-18}
+
+- [Introduction to Oracles](/developers/docs/oracles/)
+
+#### Recent Research {#recent-research-18}
+
+- [Survey of blockchain oracles](https://arxiv.org/pdf/2004.07140.pdf)
+- [Chainlink white paper](https://chain.link/whitepaper)
+
+### App security {#app-security}
+
+هکرهای اتریوم معمولاً به جای خود پروتکل از آسیبپذیریهای اپلیکیشنها سوء استفاده میکنند. هکرها و توسعهدهندگان اپلیکیشنها، در رقابت تسلحیاتی برای توسعه حملات و دفاعهای جدید قفل شدهاند. بنابراین، برای ایمن نگهداشتن اپلیکیشنها و جلوگیری از هک شدن آنها تحقیقات در این زمینه اهمیت بالایی دارد.
+
+#### Background reading {#background-reading-19}
+
+- [Wormhole exploit report](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/)
+- [List of Ethereum contract hack post-mortems](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191)
+- [Rekt News](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg)
+
+#### Recent research {#recent-research-19}
+
+- [ethresear.ch Applications](https://ethresear.ch/c/applications/18)
+
+### Technology stack {#technology-stack}
+
+تمرکززدایی از پشته فناوری در اتریوم یک حوزه تحقیقاتی مهم است. در حال حاضر، dappهایی که روی اتریوم ساخته شدهاند معمولا به واسطه اتکا به ابزارها یا زیرساختهای متمرکز بهطور کامل غیرمتمرکز نیستند.
+
+#### Background reading {#background-reading-20}
+
+- [Ethereum stack](/developers/docs/ethereum-stack/)
+- [Coinbase: Intro to Web3 Stack](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0)
+- [Introduction to smart contracts](/developers/docs/smart-contracts/)
+- [Introduction to decentralized storage](/developers/docs/storage/)
+
+#### Recent research {#recent-research-20}
+
+- [Smart contract composability](/developers/docs/smart-contracts/composability/)
diff --git a/public/content/translations/fa/14) Community Pages/community/support/index.md b/public/content/translations/fa/14) Community Pages/community/support/index.md
new file mode 100644
index 00000000000..b7ab4916c40
--- /dev/null
+++ b/public/content/translations/fa/14) Community Pages/community/support/index.md
@@ -0,0 +1,104 @@
+---
+title: پشتیبانی اتریوم
+description: در اکوسیستم اتریوم پشتیبانی دریافت کنید.
+lang: fa
+---
+
+# پشتیبانی اتریوم {#support}
+
+## پشتیبانی رسمی اتریوم {#official-support}
+
+آیا به دنبال پشتیبانی رسمی اتریوم هستید؟ اولین چیزی که باید بدانید این است که اتریوم غیرمتمرکز است. این بدان معناست که هیچ سازمان مرکزی، نهاد یا شخصی مالک اتریوم نیست و به همین دلیل، هیچ کانال پشتیبانی رسمی وجود ندارد.
+
+درک ماهیت غیرمتمرکز اتریوم بسیار مهم است زیرا هرکسی که ادعا میکند پشتیبان رسمی اتریوم است، احتمالاً سعی دارد از شما کلاهبرداری کند! بهترین محافظت در برابر کلاهبرداران، آموزش خود و جدی گرفتن امنیت است.
+
+
+ امنیت اتریوم و جلوگیری از کلاهبرداری
+
+
+
+ اصول اتریوم را بیاموزید
+
+
+علیرغم عدم پشتیبانی رسمی، بسیاری از گروهها، جوامع و پروژهها در سراسر اکوسیستم اتریوم با کمال میل به شما کمک میکنند و شما میتوانید اطلاعات و منابع مفید زیادی را در این صفحه بیابید. هنوز سؤالی دارید؟ به [دیسکورد ethereum.org](/discord/) بپیوندید، و ما سعی میکنیم کمکتان کنیم.
+
+## پرسشهای متداول {#faq}
+
+### من به کیف پول اشتباهی اتر فرستادهام {#wrong-wallet}
+
+تراکنش ارسالشده روی اتریوم برگشتناپذیر است. متأسفانه اگر به کیف پول اشتباهی اتر ارسال کرده باشید، هیچ راهی برای برگرداندن آن وجود ندارد. هیچ سازمان مرکزی، نهاد یا شخصی مالک اتریوم نیست، به این معنی که هیچکس نمیتواند تراکنشها را برگشت دهد. بنابراین، همیشه ضروری است که تراکنشهای خود را قبل از ارسال دوباره بررسی کنید.
+
+### چگونه میتوانم هدایای اتریوم خودم را مطالبه کنم؟ {#giveaway-scam}
+
+هدایای اتریوم کلاهبرداریهایی است که برای سرقت اتریوم شما طراحی شدهاند. در معرض وسوسهی پیشنهادهایی که به نظر خیلی خوب و واقعی به نظر میرسند قرار نگیرید - اگر اتوریومی را به یک آدرس هدیهدهنده ارسال کنید، هدیهای دریافت نخواهید کرد و نمیتوانید وجوه خود را بازیابی کنید.
+
+[اطلاعات بیشتر در مورد پیشگیری از کلاهبرداری](/security/#common-scams)
+
+### تراکنش من گیر کرده است {#stuck-transaction}
+
+اگر به دلیل تقاضای شبکه کارمزد تراکنش کمتری را نسبت به آنچه که لازم است ارسال کرده باشید، تراکنشهای اتریوم گاهی ممکن است گیر کنند. بسیاری از کیف پولها گزینهای برای ارسال مجدد همان تراکنش با کارمزد تراکنش بالاتر را ارائه میدهند تا امکان پردازش تراکنش فراهم شود. از طرف دیگر، میتوانید با ارسال یک تراکنش به آدرس خودتان و استفاده از nonce همان تراکنش معلق، یک تراکنش معلق را لغو کنید.
+
+[نحوهی سرعت بخشیدن یا لغو تراکنش معلق در MetaMask](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction)
+
+[چگونه تراکنشهای معلق اتریوم را لغو کنیم؟](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/)
+
+### چگونه میتوانم اتریوم استخراج کنم؟ {#mining-ethereum}
+
+استخراج اتریوم دیگر امکانپذیر نیست. وقتی اتریوم از [اثبات کار](/glossary/#pow) به [اثبات سهام](/glossary/#pos) منتقل شد، استخراج خاموش شد. اکنون به جای ماینر، اتریوم اعتبارسنج دارد. هر کس میتواند برای اجرای نرمافزار اعتبارسنج برای ایمن کردن شبکه، اتر را [سهامگذاری](/glossary/#staking) کرده و پاداشهای سهامگذاری را دریافت کند.
+
+### چطور یک سهامگذار شوم / یک اعتبارسنج اجرا کنم؟ {#how-to-stake}
+
+برای تبدیل شدن به یک اعتبارسنج، باید 32 اتر در قرارداد سپردهگذاری کنید و یک گرهی اعتبارسنج راهاندازی کنید. اطلاعات بیشتر در [صفحات سهامگذاری](/staking) و در [سکوی پرتاب سهامگذاری](https://launchpad.ethereum.org/) ما در دسترس است.
+
+## ساخت برنامههای غیرمتمرکز (dappها) {#building-support}
+
+ساختن میتواند سخت باشد. در اینجا برخی از فضاهای متمرکز توسعه با توسعهدهندگان باتجربهای وجود دارند که خوشحال میشوند به شما کمکی کنند.
+
+- [دانشگاه شیمی](https://university.alchemy.com/#starter_code)
+- [دیسکورد CryptoDevs](https://discord.com/invite/5W5tVb3)
+- [StackExchange اتریوم](https://ethereum.stackexchange.com/)
+- [StackOverflow](https://stackoverflow.com/questions/tagged/web3)
+- [دانشگاه Web3](https://www.web3.university/)
+- [LearnWeb3](https://discord.com/invite/learnweb3)
+
+همچنین میتوانید مستندات و راهنمای توسعه را در بخش [منابع توسعهدهندگان اتریوم](/developers/) ما بیابید.
+
+### ابزارسازی {#dapp-tooling}
+
+آیا سؤال شما به ابزار، پروژه یا کتابخانه خاصی مربوط میشود؟ بیشتر پروژهها دارای سرورهای چت یا انجمنهایی هستند که برای پشتیبانی از شما اختصاص دادهشدهاند.
+
+در اینجا برخی از نمونههای محبوب آورده شده است:
+
+- [Solidity](https://gitter.im/ethereum/solidity)
+- [ethers.js](https://discord.gg/6jyGVDK6Jx)
+- [web3.js](https://discord.gg/GsABYQu4sC)
+- [Hardhat](https://discord.gg/xtrMGhmbfZ)
+- [Alchemy](http://alchemy.com/discord)
+- [Tenderly](https://discord.gg/fBvDJYR)
+
+## راهاندازی یک گره {#node-support}
+
+اگر از یک گره یا یک اعتبارسنج استفاده میکنید، در اینجا چند انجمن وجود دارد که به شما در شروع کار کمک میکنند.
+
+- [دیسکورد EthStaker](https://discord.gg/ethstaker)
+- [ردیت EthStaker](https://www.reddit.com/r/ethstaker)
+
+اکثر تیمهایی که کلاینت های اتریومی را میسازند، فضاهای اختصاصی و عمومی دارند که میتوانید از آنها پشتیبانی دریافت کنید و سؤال بپرسید.
+
+### کلاینتهای اجرا {#execution-clients}
+
+- [Geth](https://discord.gg/FqDzupGyYf)
+- [Nethermind](https://discord.gg/YJx3pm8z5C)
+- [Besu](https://discord.gg/p8djYngzKN)
+- [Erigon](https://github.com/ledgerwatch/erigon/issues)
+- [Reth](https://github.com/paradigmxyz/reth/discussions)
+
+### کلاینتهای اجماع {#consensus-clients}
+
+- [Prysm](https://discord.gg/prysmaticlabs)
+- [Nimbus](https://discord.gg/nSmEH3qgFv)
+- [Lighthouse](https://discord.gg/cyAszAh)
+- [Teku](https://discord.gg/7hPv2T6)
+- [Lodestar](https://discord.gg/aMxzVcr)
+
+همچنین میتوانید [نحوهی اجرای یک گره را در اینجا بیاموزید](/developers/docs/nodes-and-clients/run-a-node/).
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
new file mode 100644
index 00000000000..a26391d9d4c
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
@@ -0,0 +1,89 @@
+---
+title: نود آرشیو در اتریوم
+description: مروری بر نود آرشیو در اتریوم
+lang: fa
+sidebarDepth: 2
+---
+
+یک گره آرشیو نمونهای از کاربر اتریوم است که برای آرشیو تمامی وضعیتهای تاریخی شبکه پیکربندی شده است. این گره ابزاری مفید برای استفاده در موارد خاص بوده ولی ممکن است اجرای آن نسبت به گره کامل دشوارتر باشد.
+
+## پیشنیازها {#prerequisites}
+
+شما باید قبل از استفاده از نود آرشیوگر درک درستی از مواردی مانند [مفهوم نود در اتریوم](/developers/docs/nodes-and-clients/) ،[معماری آن](/developers/docs/nodes-and-clients/node-architecture/), [استراتژیهای همگامسازی](/developers/docs/nodes-and-clients/#sync-modes), تمرینهای مرتبط با [راهاندازی](/developers/docs/nodes-and-clients/run-a-node/) و [استفاده از این نوع نودها](/developers/docs/apis/json-rpc/).
+
+## گره آرشیوگر چیست؟
+
+برای درکی درست از اهمیت یک گره آرشیو، بیایید مفهوم «حالت» را برایتان روشن کنیم. اتریوم را میتوان به عنوان _ماشین حالتی که مبتنی بر تراکنش است_ نامگذاری نمود. این ماشین شامل حسابها و برنامههایی است که با اجرای تراکنشها وضعیت خود را تغییر میدهند. دادههای جهانی به همراه اطلاعات هر حساب و قرارداد، در یک پایگاه دادۀ درختی به نام وضعیت ذخیرهسازی میشوند. این عمل توسط کاربر در لایۀ اجرا (EL) انجام میگیرد که شامل موارد زیر است:
+
+- موجودیها و نانسهای حساب
+- کد قرارداد و ذخیرهسازی
+- دادههای مربوط به اجماع مانند قرارداد سهام گذاری
+
+برای تعامل با شبکه، تایید و تولید بلاک جدید، کاربرهای اتریوم باید با آخرین تغییرات (انتهای زنجیرۀ شبکه) و وضعیت فعلی آن همگام باشند. کاربر لایۀ اجرا که به عنوان یک نود کامل پیکربندی شده است آخرین وضعیت شبکه را تایید و از آن پیروی میکند اما فقط چند حالت گذشته را میتواند در خود ذخیره کند، به عنوان مثال، تنها قابلیت ذخیرهسازی وضعیت مرتبط با 128 بلوک آخر در شبکه را دارد، بنابراین این کاربر میتواند سازماندهی مجدد زنجیره را مدیریت کرده و دسترسی سریع به دادههای اخیر را فراهم نماید. وضعیت اخیر حالتی است که تمامی کاربرها برای تایید تراکنشهای دریافتی و استفاده از شبکه به آن نیاز دارند.
+
+شما میتوانید وضعیت را به عنوان اسنپشات شبکه در یک بلوک مشخص و آرشیو را به عنوان بازپخش تاریخی آن تصور کنید.
+
+وضعیتهای تاریخی را میتوان با خیال راحت از بین برد، چون این وضعیتها برای عملکرد شبکه ضروری نیستند و نگهداری از تمامی دادههای قدیمی برای کاربر بیهوده است. وضعیتهایی که قبل از چند بلوک اخیر وجود داشتهاند (مانند 128 بلوک از آخر) دور ریخته میشوند. گرههای کامل تنها دادههای تاریخی بلاکچین را نگهداری میکنند (بلوکها و تراکنشها) و اسنپشاتهای تاریخی میتوانند گهگاه در صورت درخواست برای بازسازی دوبارۀ وضعیتهای قدیمیتر استفاده شوند. آنها این کار را با اجرای مجدد تراکنشهای گذشته در EVM انجام میدهند، که زمانی که وضعیت موردنظر از نزدیکترین اسنپشات فاصله دارد، ممکن است سخت باشد.
+
+با این حال، این بدین معنی است که دسترسی به یک وضعیت تاریخی در یک گره کامل، محاسباتی زیادی لازم دارد. کاربر ممکن است نیاز به اجرای تمام تراکنشهای گذشته و محاسبۀ یک وضعیت تاریخی از پیدایش داشته باشد. گرههای آرشیو این مشکل را با ذخیرهسازیِ نه فقط وضعیتهای اخیر بلکه تمام وضعیتهای تاریخی ایجاد شده بعد از هر بلوک حل میکنند. این کار اساساً نوعی مبادلۀ دو طرفه با فضای بیشتر دیسک را ایجاد میکند.
+
+توجه به این نکته بسیار مهم است که شبکه به گرههای آرشیو برای نگهداری و ارائه تمام دادههای تاریخی وابسته نیست. همانطور که در بالا اشاره شد، تمام وضعیتهای موقت تاریخی میتوانند از طریق گرههای کامل به دست آیند. تراکنشها توسط هر گره کامل ذخیره میشوند (در حال حاضر کمتر از 400G) و میتوان برای ساخت کل آرشیو، مجدداً آنها را در شبکه پخش کرد.
+
+### موارد استفاده
+
+استفادۀ منظم از شبکۀ اتریوم مانند ارسال تراکنشها، استقرار قراردادها، تایید اجماعها و غیره نیازی به دسترسی داشتن به وضعیتهای تاریخی ندارد. به طور کلی کاربران هرگز برای تعامل استاندارد با شبکه نیازی به گره آرشیو ندارند.
+
+مزیت اصلی آرشیوِ وضعیت، دسترسی سریع به درخواستهای مرتبط با وضعیتهای تاریخی است. برای مثال، گره آرشیو با سرعت زیادی به نتایجی مانند موارد زیر میرسد:
+
+- _موجودی حساب اتریومی 0x1337… در بلوک 15537393 چقدر بود؟_
+- _موجودی توکن 0x در بلوک 1920000 چقدر است؟_
+
+همانطور که در بالا توضیح داده شد، یک گره کامل باید این دادهها را با اجرای EVM که از CPU استفاده میکند و بسیار زمانبر است، تولید کند. گرههای آرشیو به تمام این دادهها بر روی دیسک دسترسی دارند و بلافاصله پاسخها را نسبت به این قبیل مسائل ارائه میدهند. این ویژگی برای بخشهای خاصی از زیرساخت شبکه مفید است، برای مثال:
+
+- ارائهدهندگان سرویسهایی مثل جستجوگرهای بلوک
+- پژوهشگران
+- تحلیلگران امنیتی
+- توسعهدهندگان برنامههای غیرمتمرکز یا Dappها
+- حسابرسی و انطباق
+سرویسهای رایگان مختلف وجود دارند که امکان دسترسی به دادههای تاریخی را فراهم میکنند. از آنجا که اجرای یک گره آرشیو پرزحمت تر است، دسترسی به آن از طریق سرویسهای مختلف عمدتاً محدود بوده و ممکن است این سرویسها تنها بعضی اوقات کار کنند. اگر پروژۀ شما نیاز به دسترسی پیوسته به دادههای تاریخی دارد، بهتر است خودتان یک گره آرشیو بر روی سیستمتان اجرا کنید.
+
+
+
+## اجراها و کاربرد
+
+گره آرشیو به معنای دادههای ارائه شده از سوی کاربرهایی است که با کاربرهای لایه اجرا روبه رو هستند زمانی که آنها پایگاه دادۀ وضعیت را مدیریت کرده و نقاط پایانی JSON-RPC را فراهم میکنند. گزینههای پیکربندی، زمان همگامسازی و سایز دادهها ممکن است بسته به کاربر متفاوت باشد. برای جزئیات بیشتر، لطفا به اسناد ارائه شده توسط کاربرتان رجوع کنید.
+
+قبل از شروع راهاندازی گره آرشیوتان، در رابطه با تفاوتهای بین کاربرها و علی الخصوص [نیازمندیهای سختافزاریشان](/developers/docs/nodes-and-clients/run-a-node/#requirements) مطالعه کنید. شایان ذکر است که اکثر کاربرها بهینهسازی نشدهاند و آرشیوشان نیاز به فضای بیش از 12 ترابایت دارد. در مقابل، پیادهسازیهایی مانند Erigon میتوانند همان داده را در کمتر از 3 ترابایت ذخیره کنند که موثرترین راه برای اجرای یک گره آرشیو محسوب میشود.
+
+
+
+## اقدامات توصیه شده
+
+جدا از [توصیههای کلی برای اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/)، یک گره آرشیو ممکن است از نظر سختافزار و نگهداری الزامات بیشتری داشته باشد. با توجه به [ویژگیهای کلیدی](https://github.com/ledgerwatch/erigon#key-features) عملیترین رویکرد در این زمینه همان استفاده از پیادهسازی کاربر [Erigon](/developers/docs/nodes-and-clients/#erigon) است.
+
+
+
+### سختافزار
+
+همیشه مطمئن شوید که الزامات سخت افزاری برای یک حالت معین در اسناد کاربر را تایید میکنید. بزرگترین نیاز برای گرههای آرشیو فضای دیسک است. این فضا بسته به کاربر، میتواند از 3 ترابایت تا 12 ترابایت متفاوت باشد. حتی اگر HDD راهحل بهتری برای حجم زیادی از داده به نظر رسد، برای همگامسازی و به روزرسانی پیوستهاش با زنجیرۀ شبکه، به درایوهای SSD نیاز خواهد داشت. درایوهای [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) به اندازۀ کافی خوب هستند ولی باید کیفیت قابل اعتماد حداقل در حد [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences) داشته باشند. دیسکها را میتوان بر روی کامپیوتر یا یک سرور با اسلات کافی نصب کرد. چنین دستگاههایی برای اجرای گره با زمان کاریِ بالا ایده آل و مناسب هستند. اجرای آن بر روی لپ تاپ نیز امکانپذیر است ولی قابل حمل بودنش هزینۀ اضافی به همراه خواهد داشت.
+
+تمامی دادهها باید در یک حجم قرار گیرند بنابراین دیسکها باید به عنوان مثال توسط [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) یا [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html) به هم متصل شوند. همچنین ممکن است استفاده از سیستم فایل [ZFS](https://en.wikipedia.org/wiki/ZFS) از آنجا که از ویژگی Copy-on-write پشتیبانی میکند، ارزشمند باشد، در واقع این ویژگی اطمینان حاصل میکند که دادهها به درستی بر روی دیسک و بدون هیچ گونه خطای سطح پایین نوشته شده باشند.
+
+برای ثبات و امنیت بیشتر به منظور جلوگیری از خرابی تصادفی در پایگاه داده، به خصوص در تنظیمات حرفهای، از [ECC memory](https://en.wikipedia.org/wiki/ECC_memory) در صورتی که توسط سیستمتان پشتیبانی میشود، استفاده کنید. به طور کلی توصیه میشود سایز RAM هم اندازۀ گره کامل باشد ولی در کل RAM بیشتر میتواند به سرعت همگامسازی کمک کند.
+
+در طول همگامسازی اولیه، کاربرها در حالت آرشیو هر تراکنشی را از زمان پیدایش اجرا میکنند. سرعت اجرا بیشتر توسط CPU محدود میشود، بنابراین CPU سریعتر میتواند به زمان همگامسازی اولیه کمک کند. در یک کامپیوتر معمولی، زمان همگامسازی اولیه میتواند تا یک ماه طول بکشد.
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [گره کامل اتریوم در مقایسه با گره آرشیو](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode، سپتامبر 2022_
+- [گره آرشیو اتریوم خودتان را بسازید](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _تامس جی راش، اوت 2021_
+- [چگونه Erigon را نصب کنیم، RPC اِریگون و TrueBlocks (اسکریپ و API) به عنوان خدمات](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– ماگنون هانسن، بهروز رسانی سپتامبر 2022_
+
+
+
+## موضوعات مرتبط {#related-topics}
+
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+- [راهاندازی یک گره](/developers/docs/nodes-and-clients/run-a-node/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
new file mode 100644
index 00000000000..34e555578f9
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
@@ -0,0 +1,31 @@
+---
+title: مقدمه ای بر بوتنودهای اتریوم
+description: اطلاعات اولیه ای که برای درک بوت نودها نیاز دارید
+lang: fa
+---
+
+هنگامی که یک گره جدید به شبکه اتریوم میپیوندد، باید به گرههایی که از قبل در شبکه هستند متصل شود تا همتاهای جدید را کشف کند. به این نقاط ورود به شبکه اتریوم، بوت نود می گویند. کاربرها معمولاً فهرستی از بوت نودها را دارند که در آنها کدگذاری شده است. این بوت نودها معمولاً توسط تیم توسعه دهنده بنیاد اتریوم یا خود تیم های کاربر اجرا می شوند. توجه داشته باشید که بوت نودها با گره های استاتیک یکسان نیستند. گره های استاتیک بارها و بارها فراخوانی می شوند، در حالی که بوت نودها فقط زمانی فراخوانی می شوند که همتاهای کافی برای اتصال به آن ها وجود نداشته باشد و یک گره نیاز به بوت استرپ برخی از اتصالات جدید داشته باشد.
+
+## اتصال به یک بوت نود {#connect-to-a-bootnode}
+
+اکثر کاربرها فهرستی از بوتنودها را در خود دارند، اما ممکن است بخواهید بوتنود خود را نیز اجرا کنید، یا از یکی استفاده کنید که بخشی از لیست کدهای سخت کاربر نیست. در این مورد، می توانید آنها را هنگام راهاندازی کاربر خود به شرح زیر مشخص کنید (به عنوان مثال برای Geth، لطفاً اسناد کاربر خود را بررسی کنید):
+
+```
+geth --bootnodes "enode://@:"
+```
+
+## اجرای یک بوت نود {#run-a-bootnode}
+
+بوت نودها گره های کاملی هستند که پشت NAT نیستند ([ترجمه آدرس شبکه](https://www.geeksforgeeks.org/network-address-translation-nat/)). هر گره کامل تا زمانی که در دسترس عموم باشد می تواند به عنوان یک بوت نود عمل کند.
+
+هنگامی که یک گره را راهاندازی می کنید، باید [enode](/developers/docs/networking-layer/network-addresses/#enode) شما را ثبت کند، که یک شناسه عمومی است که دیگران می توانند از آن برای اتصال به گره شما استفاده کنند.
+
+این enode معمولاً در هر راهاندازی مجدد بازسازی میشود، بنابراین مطمئن شوید که به مستندات کاربر خود در مورد نحوه ایجاد یک enode پایدار برای بوتنود خود نگاه کنید.
+
+برای اینکه بوتنود خوبی باشید، ایده خوبی است که حداکثر تعداد همتاهایی را که میتوانند به آن متصل شوند، افزایش دهید. اجرای یک بوت نود با همتایان زیاد، پهنای باند مورد نیاز را به میزان قابل توجه افزایش می دهد.
+
+## بوت نودهای موجود {#available-bootnodes}
+
+فهرستی از بوت نودهای داخلی در go-ethereum را میتوانید [اینجا](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) پیدا کنید. این بوت نودها توسط بنیاد اتریوم و تیم go-ethereum نگهداری می شوند.
+
+لیست های دیگری از بوت نودها وجود دارد که توسط داوطلبان نگهداری می شوند. لطفاً مطمئن شوید که همیشه حداقل یک بوتنود رسمی گنجانده شده است، در غیر این صورت ممکن است تحت حمله Eclipse قرار بگیرید.
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
new file mode 100644
index 00000000000..9a2fcf0b6b2
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
@@ -0,0 +1,109 @@
+---
+title: تنوع کلاینتها
+description: توضیح سطح بالایی از اهمیت تنوع کلاینت در اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+رفتار یک گرهی اتریوم توسط نرمافزار کلاینتی که اجرا میکند کنترل میشود. چندین کلاینت اتریوم در سطح تولید وجود دارند که هر کدام به زبانهای مختلف توسط تیمهای جداگانه توسعه یافته و نگهداری میشوند. کلاینتها بر اساس مشخصات مشترکی ساخته شدهاند که تضمین میکند کلاینتها بهطور یکپارچه با یکدیگر ارتباط برقرار میکنند و عملکرد یکسانی دارند و تجربهی کاربری برابری را ارائه میدهند. با این حال، در حال حاضر توزیع کلاینتها در سراسر گرهها به اندازهی کافی برای تحقق این تقویت شبکه با پتانسیل کامل آن برابر نیست. در حالت ایدهآل، کاربران تقریباً بهطور مساوی بین کلاینتهای مختلف تقسیم میکنند تا بیشترین تنوع کلاینت را به شبکه بیاورند.
+
+## پیشنیازها {#prerequisites}
+
+اگر از قبل نمیدانید گرهها و کاربرها چیست، [گرهها و کاربرها](/developers/docs/nodes-and-clients/) را بررسی کنید. لایههای [اجرا](/glossary/#execution-layer) و [اجماع](/glossary/#consensus-layer) در واژهنامه تعریف شدهاند.
+
+## چرا چندین کلاینت وجود دارد؟ {#why-multiple-clients}
+
+کلاینتهای متعددی وجود دارند که بهطور مستقل توسعه یافته و نگهداری میشوند زیرا تنوع کلاینت شبکه را در برابر حملات و اشکالهای نرمافزاری سرسختتر میکند. تعدد کلاینتها یک نقطهی قوت منحصربهفرد برای اتریوم است - سایر زنجیرههای بلوکی بر مصونیت یک کلاینت از خطای تکیه دارند. با این حال، صرفاً در دسترس داشتن چندین کلاینت کافی نیست، آنها باید توسط جامعه پذیرفته شوند و کل گرههای فعال بهطور نسبتاً مساوی در بین آنها توزیع شوند.
+
+## چرا تنوع کلاینت مهم است؟ {#client-diversity-importance}
+
+داشتن کلاینتهای توسعهیافته بهطور مستقل و نگهداریشدهی متعدد برای سلامت یک شبکهی غیرمتمرکز حیاتی است. بیایید دلایل آن را بررسی کنیم.
+
+### اشکالات نرمافزاری {#bugs}
+
+یک اشکال در یک کلاینت منفرد که نمایندهی اقلیتی از گرههای اتریوم باشد، خطر کمتری برای شبکه دارد. با توزیع تقریباً یکنواخت گرهها در بین بسیاری از کلاینتها، احتمال اینکه اکثر کلاینتها از یک مشکل مشترک رنج ببرند اندک است و در نتیجه شبکه قویتر است.
+
+### تابآوری در برابر حملات {#resilience}
+
+تنوع کلاینت همچنین باعث تابآوری در برابر حملات میشود. بهعنوان مثال، حمله ای که [یک کلاینت خاص را به سمت شاخهی خاصی از زنجیره فریب دهد](https://twitter.com/vdWijden/status/1437712249926393858) بعید است موفقیت آمیز باشد زیرا بعید است سایر کلاینتها به همان شیوه فریب بخورند و زنجیرهی متعارف خراب نمیشود. تنوع کم کلاینت، خطر مرتبط با هک در کلاینت غالب را افزایش میدهد. قبلاً ثابت شده است که تنوع کلاینت، دفاع مهمی در برابر حملات مخرب در شبکه است. بهعنوان مثال، حملهی محرومسازی از سرویس شانگهای در سال 2016 به این خاطر امکانپذیر بود که مهاجمان توانستند کلاینت غالب (Geth) را فریب دهند که یک دیسک آهستهی عملیات i/o را دهها هزار بار در هر بلوک اجرا کند. از آنجایی که کلاینتهای جایگزین نیز آنلاین بودند و آسیبپذیری را نداشتند، اتریوم توانست در مقابل حمله مقاومت کند و تا زمانی که آسیبپذیری در Geth رفع شد، به کار خود ادامه دهد.
+
+### قطعیت اثبات سهام {#finality}
+
+یک باگ در یک کاربر توافقی با بیش از 33 درصد از گرههای اتریوم میتواند از نهایی شدن لایه اجماع جلوگیری کند، به این معنی که کاربران نمیتوانند اعتماد کنند که تراکنشها در مقطعی بازگردانده یا تغییر نخواهند کرد. این برای بسیاری از برنامه های ساخته شده در بالای اتریوم، به ویژه DeFi، بسیار مشکل ساز خواهد بود.
+
+ بدتر از آن، یک اشکال حیاتی در کلاینت با اکثریت دو سوم میتواند باعث شود که زنجیره بهاشتباه تقسیم و نهایی شود، که باعث میشود مجموعهی بزرگی از اعتبارسنجها در زنجیرهای نامعتبر گیر کنند. اگر بخواهند دوباره به زنجیرهی درست بپیوندند، این اعتبارسنجها با برخورد شدید یا خروج و فعالسازی مجدد داوطلبانهی آهسته و پرهزینه مواجه میشوند. شدت برخورد شدید متناسب با تعداد گرههای مقصر است و دو سوم اکثریت مورد شدیدترین برخورد قرار میگیرند (32 اتر).
+
+اگرچه این سناریوها بعید هستند، اما اکوسیستم اتریوم میتواند ریسک آنها را با یکنواخت کردن توزیع کلاینتها در سراسر گرههای فعال کاهش دهد. در حالت ایده آل، هیچ کاربر اجماع هرگز به سهم 33% از کل گره ها نخواهد رسید.
+
+### مسئولیت مشترک {#responsibility}
+
+داشتن اکثریت کلاینتها هزینهی انسانی هم دارد. این کار، فشار و مسئولیت بیش از حدی بر دوش یک تیم توسعهی کوچک وارد میکند. هرچه تنوع کلاینت کمتر باشد، بار مسئولیت توسعهدهندگانی که از کلاینت اکثریت نگهداری میکنند، بیشتر میشود. پخش کردن این مسئولیت بین تیمهای متعدد، هم برای سلامت شبکهی گرههای اتریوم و هم برای شبکهی افراد آن مفید است.
+
+## تنوع کلاینت فعلی {#current-client-diversity}
+
+![نمودار دایرهای که تنوع کلاینت را نشان میدهد](./client-diversity.png) _دادههای نمودار از [ethernodes.org](https://ethernodes.org) و [ clientdiversity.org](https://clientdiversity.org/)_
+
+دو نمودار دایرهای بالا تصاویری فوری از تنوع کلاینت فعلی برای لایههای اجرا و اجماع (در زمان نگارش در ژانویه 2022) را نشان میدهند. لایهی اجرا غالباً در سلطهی [Geth](https://geth.ethereum.org/) است، [Open Ethereum با فاصله دوم است، ](https://openethereum.github.io/) [Erigon](https://github.com/ledgerwatch/erigon) سوم است و [Nethermind](https://nethermind.io/) چهارم است، و در عین حال سایر کلاینتها که کمتر از 1% شبکه را تشکیل میدهند. رایجترین کلاینت مورد استفاده در لایهی اجماع - [Prysm](https://prysmaticlabs.com/#projects) - به اندازه Geth غالب نیست، اما در عین حال بیش از 60% از شبکه را نمایندگی میکند. [Lighthouse](https://lighthouse.sigmaprime.io/) و [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) به ترتیب 20% و حدود 14% حضور دارند و سایر کلاینتها بهندرت استفاده میشوند.
+
+داده های لایه اجرا از [Ethernodes](https://ethernodes.org) در 23 ژانویه 2022 به دست آمدند. دادههای کلاینتهای اجماع از [Michael Sproul](https://github.com/sigp/blockprint) گرفته شده است. بهدست آوردن دادههای کاربر اجماع دشوارتر است، زیرا کاربرهای لایه اجماع همیشه دارای ردپاهای واضحی نیستند که بتوان از آنها برای شناسایی استفاده کرد. دادهها با استفاده از یک الگوریتم طبقهبندی تولید شدهاند که گاهی برخی از کلاینتهای اقلیت را گیج میکند (برای جزئیات بیشتر به [اینجا](https://twitter.com/sproulM_/status/1440512518242197516) مراجعه کنید). در نمودار بالا، این طبقهبندیهای مبهم یک برچسب یا این/یا آن (بهعنوان مثال Nimbus/Teku) دارند. با وجود این، واضح است که اکثریتِ شبکه Prysm را اجرا میکند. دادهها، تصویری از مجموعهی ثابتی از بلوکها هستند (در این مورد، بلوکهای بیکن در اسلاتهای 2048001 تا 2164916) و حضور غالب Prysm گاهی اوقات بالاتر و بیش از 68% بوده است. علیرغم صرفاً یک تصویر بودن، مقادیر نمودار درک کلی خوبی از وضعیت فعلی تنوع کلاینت ارائه میدهند.
+
+داده های به روز شده تنوع مشتری، برای لایه اجماع اکنون در [clientdiversity.org](https://clientdiversity.org/) در دسترس است.
+
+## لایهی اجرا {#execution-layer}
+
+تا به حال، گفتگو پیرامون تنوع کلاینت عمدتاً بر لایهی اجماع متمرکز بوده است. با این حال، کلاینت اجرای [Geth](https://geth.ethereum.org) در حال حاضر حدود 85% از کل گرهها را تشکیل میدهد. این درصد به دلایل یکسان برای کلاینتهای اجماع مشکلساز است. برای مثال، یک اشکال نرمافزاری در Geth که روی انجام دادن تراکنش تأثیر میگذارد یا پیلودهای اجرایی درست میکند، میتواند منجر به این شود که کلاینتهای اجماع تراکنشهای مشکلساز یا مشکلدار را نهایی کنند. بنابراین، اتریوم با توزیع یکنواختتری از کلاینتهای اجرایی سالمتر خواهد بود. حالت ایدهآل این است که هیچ کلاینتی بیش از 33% از شبکه را نمایندگی نکند.
+
+## از کلاینت اقلیت استفاده کنید {#use-minority-client}
+
+توجه کردن به تنوع کلاینت به بیش از کاربران منفردی نیاز دارد که کلاینتهای اقلیت را انتخاب کنند - این کار نیازمند استخرهای استخراج/ اعتبارسنج و نهادهایی مانند dappها و صرافیهای اصلی است تا کلاینتها را هم تغییر دهند. با این حال، همهی کاربران میتوانند سهم خود را در اصلاح عدم توازن فعلی و عادیسازی استفاده از تمام نرمافزارهای موجود اتریوم انجام دهند. پس از ادغام، تمام عملگرهای گره ملزم به اجرای یک کلاینت اجرا و یک کلاینت اجماع خواهند بود. انتخاب ترکیبی از کلاینتهای پیشنهادشده در زیر به افزایش تنوع کلاینت کمک میکند.
+
+### کلاینتهای اجرا {#execution-clients}
+
+[Besu](https://www.hyperledger.org/use/besu)
+
+[Nethermind](https://downloads.nethermind.io/)
+
+[Erigon](https://github.com/ledgerwatch/erigon)
+
+[Go-Ethereum](https://geth.ethereum.org/)
+
+### کلاینتهای اجماع {#consensus-clients}
+
+[Nimbus](https://nimbus.team/)
+
+[Lighthouse](https://github.com/sigp/lighthouse)
+
+[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
+
+[Lodestar](https://github.com/ChainSafe/lodestar)
+
+[Prysm](https://docs.prylabs.network/docs/getting-started)
+
+کاربران فنی میتوانند با نوشتن آموزشها و مستندات بیشتر برای کلاینتهای اقلیت و تشویق همتایان گرهگردان خود به مهاجرت کردن دور از کلاینتهای غالب، به تسریع این فرایند کمک کنند. راهنماهای تغییر به کلاینت اجماع اقلیت در [clientdiversity.org](https://clientdiversity.org/) موجود است.
+
+## داشبوردهای تنوع کلاینت {#client-diversity-dashboards}
+
+چند داشبورد آمار تنوع کلاینت را بهصورت لحظهای برای لایهی اجرا و اجماع ارائه میدهند.
+
+**لایهی اجماع:**
+
+- [Rated.network](https://www.rated.network/)
+- [clientdiversity.org](https://clientdiversity.org/) **لایه اجرا:**
+
+- [supermajority.info](https://supermajority.info//)
+- [Ethernodes](https://ethernodes.org/)
+
+## اطلاعات بیشتر {#further-reading}
+
+- [تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
+- [ادغام اتریوم: کلاینت اکثریت را با ریسک خودتان اجرا کنید!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) - _دانکراد فیست، 24 مارس 2022_
+- [اهمیت تنوع کلاینت](https://our.status.im/the-importance-of-client-diversity/)
+- [فهرست خدمات گرهی اتریوم](https://ethereumnodes.com/)
+- [«پنج چرا»ی مشکل تنوع کلاینت](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
+- [تنوع اتریوم و نحوه حل آن (یوتیوب)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
+- [clientdiversity.org](https://clientdiversity.org/)
+
+## موضوعات مرتبط {#related-topics}
+
+- [اجرای یک گرهی اتریوم](/run-a-node/)
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
new file mode 100644
index 00000000000..97ad557b24c
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
@@ -0,0 +1,307 @@
+---
+title: گرهها و کلاینتها
+description: نگاهی اجمالی بر گرهها و نرمافزار کلاینت اتریوم، به علاوهی نحوهی راهاندازی یک گره و علت انجام آن.
+lang: fa
+sidebarDepth: 2
+---
+
+اتریوم یک شبکه توزیعشده از رایانهها (معروف به گرهها) است که نرمافزاری را اجرا میکنند که میتواند بلوکها و دادههای تراکنش را تأیید کند. نرم افزار باید بر روی رایانهی شما اجرا شود تا آن را به یک نود اتریوم تبدیل کند. برای تشکیل یک گره، دو بخش مجزا از نرمافزار (که به عنوان "کلاینت" شناخته می شوند) مورد نیاز است.
+
+## پیشنیازها {#prerequisites}
+
+پیش از آن که نمونهی کلاینت اتریوم خود را اجرا کنید و در این موضوع عمیق شوید باید [مبانی ماشین مجازی اتریوم](/developers/docs/evm/) و شبکهی همتا به همتا را بدانید و متوجه شوید. به [معرفی اتریوم](/developers/docs/intro-to-ethereum/) ما نگاهی بیندازید.
+
+اگر با موضوع گرهها تازه کار هستید، توصیه میکنیم ابتدا مقدمه کاربرپسند ما در مورد [اجرای گره اتریوم](/run-a-node) را بررسی کنید.
+
+## کلاینتها و گرهها چه هستند؟ {#what-are-nodes-and-clients}
+
+"گره" هر نمونهای از نرمافزار مشتری اتریوم است که به رایانه های دیگری که نرمافزار اتریوم را نیز اجرا می کنند متصل است و یک شبکه را تشکیل میدهد. یک کلاینت یک نرمافزار پیادهسازی اتریوم است که داده ها را بر اساس قوانین پروتکل تأیید می کند و شبکه را ایمن نگه می دارد. یک گره باید دو کلاینت را اجرا کند: یک کلاینت اجماع و یک کلاینت اجرا.
+
+- کلاینت اجرا (همچنین به عنوان مهندس اجرا، کلاینت EL یا قبلاً کلاینت Eth1 شناخته می شود) به تراکنشهای جدید پخش شده در شبکه گوش می دهد، آنها را در EVM اجرا می کند و آخرین وضعیت و پایگاه داده تمام داده های فعلی اتریوم را نگه می دارد.
+- کلاینت اجماع (همچنین به عنوان نود بیکن، کلاینت CL یا قبلاً کلاینت Eth2 شناخته میشود) الگوریتم اجماع اثبات سهام را پیادهسازی میکند، که شبکه را قادر میسازد بر اساس دادههای معتبر از کلاینت اجرا به اجماع برسد. همچنین نرمافزار سومی وجود دارد که به عنوان "اعتبارسنج" شناخته می شود که می تواند به کلاینت اجماع اضافه شود و به یک گره اجازه می دهد تا در ایمنسازی شبکه مشارکت کند.
+
+این کلاینتها با هم کار می کنند تا سر زنجیره اتریوم را پیگیری کنند و به کاربران اجازه دهند با شبکه اتریوم تعامل داشته باشند. طراحی مدولار با چندین نرمافزار که با هم کار می کنند [پیچیدگی کپسوله شده](https://vitalik.eth.limo/general/2022/02/28/complexity.html) نامیده می شود. این رویکرد اجرای یکپارچه [مرج](/roadmap/merge) را آسانتر میکند، نگهداری و توسعه نرمافزار کلاینت را آسانتر میکند، و استفاده مجدد از کلاینتهای تنها را، برای مثال، در [اکوسیستم لایه2](/layer-2/) ممکن میسازد.
+
+![کلاینت اجرا و اجماع کنار هم](./eth1eth2client.png) نمودار سادهشدهی کلاینت اجرا و اجماع کنار هم.
+
+### تنوع کلاینتها {#client-diversity}
+
+هم [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients) و هم [کلاینتهای اجماع](/developers/docs/nodes-and-clients/#consensus-clients) در انواع زبان های برنامه نویسی که توسط تیم های مختلف توسعه یافتهاند وجود دارند.
+
+پیادهسازی های متعدد کلاینت می تواند شبکه را با کاهش وابستگی آن به یک پایگاه کد، قویتر کند. هدف ایده آل دستیابی به تنوع بدون هرگونه تسلط کلاینت بر شبکه است و در نتیجه یک نقطه شکست بالقوه را از بین می برد. تنوع زبان ها همچنین جامعه توسعه دهندگان گسترده تری را دعوت می کند و به آنها اجازه می دهد تا به زبان دلخواه خود ادغام ایجاد کنند.
+
+درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) بیشتر بدانید.
+
+وجه مشترک این پیاده سازی ها این است که همه آنها از یک مشخصات واحد پیروی می کنند. مشخصات نحوه عملکرد شبکه اتریوم و بلاکچین را تعیین می کند. هر جزئیات فنی تعریف شده است و مشخصات را می توان به صورت زیر یافت:
+
+- در اصل، [زردنامه اتریوم](https://ethereum.github.io/yellowpaper/paper.pdf)
+- [مشخصات لایه اجرا](https://github.com/ethereum/execution-specs/)
+- [مشخصات لایه اجماع](https://github.com/ethereum/consensus-specs)
+- [EIPهای](https://eips.ethereum.org/) پیادهسازی شده در گسترهای از [ارتقاهای شبکه](/history/)
+
+### ردیابی نودها در شبکه {#network-overview}
+
+ردیابهای متعدد یک نمای کلی از گرهها در شبکه اتریوم در زمان واقعی ارائه میدهند. توجه داشته باشید که با توجه به ماهیت شبکه های غیرمتمرکز، این خزنده ها تنها می توانند دید محدودی از شبکه ارائه دهند و ممکن است نتایج متفاوتی را گزارش کنند.
+
+- [نقشه نودها](https://etherscan.io/nodetracker) توسط Etherscan
+- [Ethernodes](https://ethernodes.org/) توسط Bitfly
+- [Nodewatch](https://www.nodewatch.io/) توسط Chainsafe، که در نودهای اجماع میخزد
+
+## انواع گره {#node-types}
+
+اگر میخواهید [گرهی خودتان را اجرا کنید](/developers/docs/nodes-and-clients/run-a-node/)، باید بدانید که گرههای مختلفی وجود دارند که دادههای مختلفی را استفاده میکنند. در واقع، کلاینتها می توانند سه نوع مختلف از گره را اجرا کنند: سبک، کامل و آرشیو. همچنین گزینههایی از استراتژیهای همگامسازی مختلف وجود دارد که زمان همگامسازی سریعتر را امکانپذیر میکند. همگامسازی به این اشاره دارد که با چه سرعتی میتوان بهروزترین اطلاعات را در مورد وضعیت اتریوم دریافت کرد.
+
+### گره کامل {#full-node}
+
+گرههای کامل اعتبارسنجی بلوک به بلوک زنجیره بلوک را انجام میدهند، از جمله دانلود و تأیید بدنه بلوک و دادههای حالت برای هر بلوک. کلاسهای مختلفی از گره کامل وجود دارد - برخی از بلوکهای پیدایش شروع میکنند و تک بلوکها را در کل تاریخچه بلاکچین تأیید میکنند. برخی دیگر تأیید خود را در بلوکی جدیدتر که به معتبر بودن آن اعتماد دارند شروع میکنند (مثلاً «همگامسازی فوری» Geth). صرف نظر از جایی که تأیید شروع می شود، گره های کامل فقط یک کپی محلی از داده های نسبتاً اخیر (معمولاً 128 عدد از جدیدترین بلوک ها) را نگه می دارند، که اجازه می دهد تا داده های قدیمی برای صرفهجویی در فضای دیسک حذف شوند. داده های قدیمی را می توان در صورت نیاز دوباره تولید کرد.
+
+- دادههای زنجیرهی بلوکی کامل را بهطور کامل ذخیره میکند (اگرچه حشو و زواید این دادهها به صورت دورهای حذف میشود، بنابراین یک گرهی کامل تمام دادههای حالت را از زمان پیدایش تاکنون ذخیره نمیکند)
+- در اعتبارسنجی بلوکها شرکت میکند و همهی وضعیتها و بلوکها را تأیید میکند.
+- همه حالت ها را می توان یا از حافظه محلی بازیابی کرد یا از «اسنپشاتهایی» توسط یک گره کامل بازسازی کرد.
+- در خدمت شبکه است و دادهها را در زمان درخواست ارائه میدهد.
+
+### گره آرشیو {#archive-node}
+
+گره های آرشیوی گره های کاملی هستند که هر بلوک را از پیدایش تأیید می کنند و هرگز هیچ یک از دادههای دانلود شده را حذف نمی کنند.
+
+- هر چیزی که در گره کامل نگهداری میشود را ذخیره میکند و یک آرشیو کامل از حالتهای تاریخی میسازد. اگر میخواهید چیزی مانند موجودی حساب را در بلوک شماره 4،000،000 جستجو کنید، یا به سادگی و با اطمینان مجموعه تراکنشهای خود را بدون استخراج آنها با استفاده از ردیابی آزمایش کنید، به چنین چیزی نیاز است.
+- این دادهها واحدهای ترابایت را نشان میدهند، که گرههای آرشیوی را برای کاربران متوسط جذابتر میکند، اما میتواند برای خدماتی مانند کاوشگرهای بلوک، فروشندگان کیفپول و تحلیل زنجیره مفید باشد.
+
+همگامسازی کلاینتها در هر حالتی غیر از آرشیو منجر به کاهش دادههای زنجیرهی بلوکی میشود. این بدان معناست که هیچ آرشیوی از تمام حالتهای تاریخی وجود ندارد اما گرهی کامل قادر است آنها را بنا به تقاضا بسازد.
+
+درباره [نودهای آرشیوی](/developers/docs/nodes-and-clients/archive-nodes) بیشتر بدانید.
+
+### گره سبک {#light-node}
+
+به جای دانلود هر بلوک، گره های سبک فقط هدر بلوک ها را دانلود می کنند. این هدرها حاوی اطلاعات خلاصه ای در مورد محتویات بلوک ها هستند. هر اطلاعات دیگری که گره سبک نیاز دارد از یک گره کامل درخواست می شود. سپس گره سبک میتواند به طور مستقل دادههایی را که دریافت میکند با توجه به ریشههای حالت در هدرهای بلوک تأیید کند. گرههای سبک به کاربران امکان میدهند بدون سختافزار قدرتمند یا پهنای باند بالا که برای اجرای گرههای کامل لازم است، در شبکهی اتریوم مشارکت کنند. در نهایت، گرههای سبک ممکن است روی تلفنهای همراه یا دستگاههای تعبیهشده اجرا شوند. گرههای سبک در اجماع شرکت نمیکنند (یعنی نمیتوانند ماینر/اعتبارسنج باشند)، اما میتوانند با همان عملکرد و تضمینهای امنیتی یک گره کامل به بلاکچین اتریوم دسترسی داشته باشند.
+
+کلاینت های سبک ناحیهای برای توسعه فعال اتریوم هستند و انتظار داریم به زودی شاهد کلاینت های سبک جدید برای لایه اجماع و لایه اجرا باشیم. همچنین مسیرهای بالقوهای برای ارائهی دادههای کلاینت سبک از طریق [شبکهی شایعه](https://www.ethportal.net/) وجود دارد. این خودش مزیت است، زیرا شبکهی شایعه میتواند شبکهای از گرههای سبک را بدون نیاز به گرههای کامل برای ارائهی درخواستها پشتیبانی کند.
+
+اتریوم هنوز از گرههای سبک پرتعدادی پشتیبانی نمیکند، اما پشتیبانی از گرههای سبک حوزهای است که انتظار میرود در آیندهی نزدیک بهسرعت توسعه یابد. به طور خاص، کلاینتهایی مانند [Nimbus](https://nimbus.team/) و [Helios](https://github.com/a16z/helios) و [LodeStar](https://lodestar.chainsafe.io/) در حال حاضر به شدت بر روی گره های سبک متمرکز شده اند.
+
+## چرا باید یک گرهی اتریوم را اجرا کنم؟ {#why-should-i-run-an-ethereum-node}
+
+اجرای یک گره به شما این امکان را می دهد که به طور مستقیم، بدون نیاز به شخص ثالث و به صورت خصوصی از اتریوم استفاده کنید و در عین حال از شبکه با قوی تر و غیرمتمرکز نگه داشتن آن پشتیبانی کنید.
+
+### مزایا برای شما {#benefits-to-you}
+
+اجرای گره شما را قادر می سازد از اتریوم به صورت خصوصی، خودکفا و بدون نیاز به شخص ثالث استفاده کنید. نیازی نیست به شبکه اعتماد کنید زیرا میتوانید دادهها را خودتان با کلاینت خود تأیید کنید. «اعتماد نکنید، اعتبارسنجی کنید» یکی از شعارهای اصلی زنجیرهی بلوکی است.
+
+- گره شما تمام تراکنشها و بلوکها را با توجه به قوانین اجماع به تنهایی اعتبارسنجی میکند. این نکته به این معنی است که شما نیازی به اتکا به هیچ گرهی دیگری در شبکه یا اعتماد تام به آنها ندارید.
+- می توانید از کیف پول اتریوم با گره خود استفاده کنید. میتوانید از دپها به صورت ایمنتر و خصوصیتر استفاده کنید، زیرا مجبور نخواهید بود آدرسها و موجودیهای خود را به واسطهها فاش کنید. همهچیز میتواند با کلاینت خودتان بررسی شود. [متاسک](https://metamask.io) و [Frame](https://frame.sh/) و [بسیاری از کیفپولهای دیگر](/wallets/find-wallet/) ورود RPC را پشتیبانی میکنند و به آنها امکان میدهد از گره شما استفاده کنند.
+- میتوانید سرویسهای دیگری را که به دادههای اتریوم وابسته هستند، اجرا و میزبانی کنید. به عنوان مثال، این ممکن است یک اعتبار سنج بیکنچین، نرمافزاری مانند لایه2، زیرساخت، کاوشگرهای بلوک، پردازشگرهای پرداخت و غیره باشد.
+- شما می توانید [نقاط پایانی RPC](/developers/docs/apis/json-rpc/) سفارشی خود را ارائه دهید. حتی می توانید این نقاط پایانی را به صورت عمومی به جامعه ارائه دهید تا به آنها کمک کنید از ارائهدهندگان متمرکز بزرگ اجتناب کنند.
+- شما میتوانید با استفاده از **ارتباط بین پردازشی (IPC)** گرهی خود را متصل کنید یا برای بارگذاری برنامهی خود بهعنوان افزونه آن را بازنویسی کنید. این کار لتنسی کمی را به همراه دارد، که کمک بسیاری می کند، به عنوان مثال، هنگام پردازش دادههای زیادی با استفاده از کتابخانههای وب3.0 یا زمانی که باید تراکنشهای خود را با بیشترین سرعت ممکن جایگزین کنید (یعنی frontrunning).
+- شما میتوانید مستقیماً اتر را برای ایمنسازی شبکه و کسب پاداش سهامگذاری کنید. بخش [سهامگذاری انفرادی](/staking/solo/) را برای شروع ببینید.
+
+![چگونه با استفاده از برنامههای کاربردی و گرهها به اتریوم دسترسی داشته باشید](./nodes.png)
+
+### مزایای شبکه {#network-benefits}
+
+داشتن مجموعهی متنوعی از گرهها برای سلامت، امنیت و انعطافپذیری عملیاتی اتریوم حائظ اهمیت است.
+
+- گره های کامل قوانین لایه اجماع را اجرا می کنند بنابراین نمی توان آنها را فریب داد تا بلوک هایی را بپذیرند که از آن قوانین پیروی نمی کنند. این امر امنیت بیشتری را در شبکه ایجاد می کند زیرا اگر همه گره ها گره های سبک باشند که تأیید کامل را انجام نمی دهند، اعتبار سنجها می توانند به شبکه حمله کنند.
+- در صورت حمله ای که بر دفاعیات اقتصاد رمزنگاریشدهی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/#what-is-pos) غلبه کند، می توان با انتخاب گره های کامل که از زنجیره صادقانه پیروی می کنند، یک بازیابی اجتماعی انجام داد.
+- گرههای بیشتر در شبکه منجر به ایجاد یک شبکه متنوعتر و قویتر میشود، هدف نهایی تمرکززدایی، که سیستمی مقاوم در برابر سانسور و قابل اعتماد را امکانپذیر میسازد.
+- گره های کامل دسترسی به داده های بلاکچین را برای کلاینتهای سَبُکی که به آن وابسته هستند، فراهم می کند. گرههای سبک همهی زنجیره بلوکی را ذخیره نمیکنند و به جای آن دادهها را با [ریشهی حالت درون هدر بلوکها](/developers/docs/blocks/#block-anatomy) اعتبارسنجی میکنند. آنها می توانند در صورت نیاز اطلاعات بیشتری را از گره های کامل درخواست کنند.
+
+اگر یک گره کامل را اجرا کنید، کل شبکه اتریوم از آن سود می برد، حتی اگر اعتبارسنج را اجرا نکنید.
+
+## اجرای گرهی خودتان {#running-your-own-node}
+
+دوست دارید کلاینت اتریوم خودتان را اجرا کنید؟
+
+جهت مطالعهی مقدمهای ویژهی مبتدیان، از صفحهی [اجرای یک گره](/run-a-node)ی ما دیدن کنید تا بیشتر بدانید.
+
+اگر بیشتر یک کاربر فنی هستید، جزئیات و گزینههای بیشتری را در مورد نحوه [ثبتنام گره خود](/developers/docs/nodes-and-clients/run-a-node/) بررسی کنید.
+
+## جایگزینها {#alternatives}
+
+راهاندازی گره خود میتواند برای شما زمان و منابع هزینه داشته باشد، اما همیشه نیازی به اجرای نمونه خود ندارید. در این مورد، می توانید از یک ارائه دهنده API شخص ثالث استفاده کنید. برای مروری بر استفاده از این سرویسها، [گرهها بهعنوان سرویس](/developers/docs/nodes-and-clients/nodes-as-a-service/) را مطالعه کنید.
+
+اگر شخصی یک گره اتریوم را با یک API عمومی در انجمن شما اجرا می کند، می توانید کیف پول های خود را از طریق RPC سفارشی به یک گره انجمن هدایت کنید و از حریم خصوصی بیشتری نسبت به شخص ثالث مورد اعتماد تصادفی برخوردار شوید.
+
+از طرف دیگر، اگر کلاینت را اجرا میکنید، میتوانید آن را با دوستان خود که ممکن است به آن نیاز داشته باشند به اشتراک بگذارید.
+
+## کلاینتهای اجرا {#execution-clients}
+
+جامعهی اتریوم چندین کلاینت اجرای منبعباز (که قبلاً به عنوان «کلاینتهای Eth1» یا صرفاً «کلاینتهای اتریوم» شناخته میشدند) را نگهداری میکند که توسط تیمهای مختلف با استفاده از زبانهای برنامه نویسی مختلف توسعه یافتهاند. این شبکه را قویتر و [متنوعتر](/developers/docs/nodes-and-clients/client-diversity/) میکند. هدف ایدهآل، دستیابی به تنوع بدون تسلط هیچ کلاینتی برای کاهش هر نقطهی شکستی است.
+
+این جدول، اطلاعات کلاینتهای مختلف را بهطور خلاصه نشان میدهد. همهی آنها در [آزمایشهای کلاینت](https://github.com/ethereum/tests) قبول شدهاند و بهطور فعال نگهداری میشوند تا با ارتقاهای شبکه همگام بمانند.
+
+| کلاینت | زبان | سیستمعامل | شبکهها | راهبرد همگامسازی | هرس کردن وضعیت |
+| ------------------------------------------------------------------------ | ---------- | ----------------------- | --------------------------- | -------------------------------------------------------------- | ----------------------- |
+| [Geth](https://geth.ethereum.org/) | Go | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [Snap](#snap-sync), [Full](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Nethermind](https://www.nethermind.io/) | C#, .NET | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [Snap](#snap-sync) (without serving), Fast, [Full](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Besu](https://besu.hyperledger.org/en/stable/) | جاوا | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [فوری](#snap-sync), [سریع](#fast-sync), [پر](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Erigon](https://github.com/ledgerwatch/erigon) | Go | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [کامل](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Reth](https://reth.rs/) | Rust | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [کامل](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | لینوکس، ویندوز، مکاواس | Sepolia, Holesky | [کامل](#full-sync) | Pruned |
+
+جهت کسب اطلاعات بیشتر دربارهی شبکههای پشتیبانیشده [شبکههای اتریوم](/developers/docs/networks/) را بخوانید.
+
+هر کلاینت دارای موارد استفاده و مزایای منحصربهفردی است، بنابراین شما باید یکی را بر اساس ترجیحات خود انتخاب کنید. تنوع اجازه میدهد تا پیادهسازیها بر روی ویژگیهای مختلف و مخاطبان کاربر متمرکز شوند. ممکن است بخواهید کلاینت را بر اساس ویژگیها، پشتیبانی، زبان برنامهنویسی یا مجوزها انتخاب کنید.
+
+### Besu {#besu}
+
+هایپرلجر Besu یک کلاینت اتریوم در ردهی سازمانی برای شبکههای عمومی و مجوزدار است. این کلاینت تمام ویژگیهای اصلی اتریوم، از ردیابی گرفته تا GraphQL را اجرا میکند، نظارت گستردهای دارد و توسط ConsenSys، هم در کانالهای جامعه باز و هم از طریق SLAهای تجاری برای شرکتها، پشتیبانی میشود. این کلاینت به زبان جاوا نوشته شده است و دارای مجوز Apache 2.0 است.
+
+[اسناد](https://besu.hyperledger.org/en/stable/) گسترده Besu شما را در تمام جزئیات مربوط به ویژگیها و تنظیمات آن راهنمایی میکند.
+
+### Erigon {#erigon}
+
+Erigon که قبلاً به عنوان Turbo-Geth شناخته می شد، به عنوان یک فورک Go Ethereum با جهت گیری سرعت و کارایی فضای دیسک شروع به کار کرد. Erigon یک نرمافزار کاملاً بازسازیشده از اتریوم است که در حال حاضر با زبان Go نوشته شده است اما نرمافزارهایی به زبانهای دیگر در دست توسعه دارد. هدف Erigon ارائهی پیادهسازی سریعتر، ماژولارتر و بهینهتر اتریوم است. میتواند با استفاده از حدود 2 ترابایت فضای دیسک، در کمتر از 3 روز، همگامسازی گره آرشیو کامل را انجام دهد.
+
+### Go Ethereum {#geth}
+
+Go Ethereum (به طور خلاصه geth) یکی از پیادهسازیهای اصلی برای پروتکل اتریوم است. در حال حاضر، geth رایجترین کلاینت با بزرگترین پایگاه کاربران و ابزارهای متنوع برای کاربران و توسعهدهندگان است. این کلاینت به زبان Go نوشته شده است، کاملاً منبعباز است و مجوز آن تحت GNU LGPL v3 است.
+
+درباره Geth در [اسناد](https://geth.ethereum.org/docs/) آن بیشتر بیاموزید.
+
+### Nethermind {#nethermind}
+
+Nethermind یک نرمافزار اتریومی است که با پشته فناوری C#.NET، دارای مجوز LGPL-3.0 است که بر روی تمام پلتفرمهای اصلی از جمله ARM اجرا میشود. این پیادهسازی در رابطه با موارد زیر، کارکردی عالی دارد:
+
+- یک ماشین مجازی بهینه
+- دسترسی به حالت
+- شبکه و ویژگیهای غنی مانند داشبوردهای Prometheus/Grafana، پشتیبانی از گزارش سازمانی seq، ردیابی JSON-RPC، و افزونههای تجزیه و تحلیل.
+
+Nethermind همچنین [مستندات مشروح](https://docs.nethermind.io)، پشتیبانی توسعهی قوی، یک جامعهی آنلاین و پشتیبانی 24 ساعته در 7 روز هفته برای کاربران پرمیوم دارد.
+
+### Reth {#reth}
+
+Reth (مخفف Rust Ethereum) یک پیادهسازی گره کامل اتریوم است که بر کاربرپسند بودن، بسیار ماژولار، سریع و کارآمد تمرکز دارد. Reth در اصل توسط Paradigm ساخته و به جلو هدایت شد و تحت مجوز Apache و MIT مجوز دارد.
+
+Reth آماده تولید است و برای استفاده در محیطهای حیاتی مانند سرویسها یا سرویسهای با زمان بالا مناسب است. در موارد استفاده که عملکرد بالا با حاشیه های زیاد مورد نیاز است مانند RPC، MEV، ایندکسینگ، شبیه سازی و فعالیت های P2P، عملکرد خوبی دارد.
+
+با بررسی [Reth Book](https://reth.rs/) یا [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) بیشتر بیاموزید.
+
+### در حال توسعه {#execution-in-development}
+
+این کلاینتها هنوز در مراحل اولیه توسعه هستند و هنوز برای استفاده در تولید توصیه نمی شوند.
+
+#### EthereumJS {#ethereumjs}
+
+کلاینت اجرای EthereumJS (EthereumJS) با TypeScript نوشته شده است و متشکل از تعدادی بسته، از جمله هسته های اولیه اتریوم که توسط کلاس های Block، Transaction و Merkle-Patricia Trie و اجزای اصلی مشتری شامل پیادهسازی ماشین مجازی اتریوم (EVM)، کلاس بلاکچین و پشته شبکه DevP2P ارائه می شود.
+
+با خواندن [اسناد](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) در مورد آن بیشتر بیاموزید
+
+## کلاینتهای اجماع {#consensus-clients}
+
+چندین کلاینت اجماع (که قبلاً بهعنوان کلاینتهای «Eth2» شناخته میشدند) وجود دارد که از [ارتقاهای اجماع](/roadmap/beacon-chain/) پشتیبانی میکنند. آنها مسئول همه منطق مربوط به اجماع از جمله الگوریتم انتخاب فورک، پردازش گواهیها و مدیریت پاداشها و مجازاتهای [اثبات سهام](/developers/docs/consensus-mechanisms/pos) هستند.
+
+| کلاینت | زبان | سیستمعامل | شبکهها |
+| ------------------------------------------------------------- | ---------- | ----------------------- | --------------------------------------------------------------- |
+| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Pyrmont, Sepolia, Ropsten، و غیره |
+| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Sepolia, Ropsten، و غیره |
+| [Nimbus](https://nimbus.team/) | Nim | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Sepolia, Ropsten، و غیره |
+| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | لینوکس، ویندوز، مکاواس | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten، و غیره |
+| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | جاوا | لینوکس، ویندوز، مکاواس | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten، و غیره |
+
+### Lighthouse {#lighthouse}
+
+Lighthouse یک زیرساخت کلاینت اجماع است که با زبان Rust تحت مجوز Apache-2.0 نوشته شده است. توسط Sigma Prime نگهداری می شود و از زمان پیدایش Beacon Chain پایدار و آماده تولید بوده است. شرکت های مختلف، استخرهای سهامگذاری و افراد به آن متکی هستند. هدف آن این است که در محیطهای مختلف، از رایانههای شخصی رومیزی گرفته تا پیادهسازیهای خودکار پیچیده، ایمن و کارآمد و قابل اجرا باشد.
+
+اسناد را می توان در [کتاب Lighthouse](https://lighthouse-book.sigmaprime.io/) پیدا کرد
+
+### Lodestar {#lodestar}
+
+Lodestar یک زیرساخت کلاینت اجرا آماده تولید است که با زبان Typescript تحت مجوز LGPL-3.0 نوشته شده است. این سیستم توسط ChainSafe Systems نگهداری می شود و جدیدترین کلاینت اجماع برای سهامگذاران انفرادی، توسعه دهندگان و محققین است. Lodestar متشکل از یک Beacon Node و کلاینت اعتبارسنج است که توسط زیرساخت جاوا اسکریپت پروتکلهای اتریوم پشتیبانی می شود. هدف Lodestar بهبود قابلیت استفاده اتریوم با کلاینتهای سبک، گسترش دسترسی به گروه بزرگتری از توسعه دهندگان و کمک بیشتر به تنوع اکوسیستم است.
+
+اطلاعات بیشتر را می توانید در [وب سایت Lodestar](https://lodestar.chainsafe.io/) ما بیابید
+
+### Nimbus {#nimbus}
+
+Nimbus یک زیرساخت کلاینت اجماع است که با زبان Nim تحت مجوز Apache-2.0 نوشته شده است. این یک کلاینت آماده تولید است که توسط سهامگذاران انفرادی و استخرهای سهامگذاری استفاده می شود. Nimbus برای بهره وری از منابع طراحی شده است، و اجرای آن را بر روی دستگاه های دارای محدودیت منابع و زیرساخت های سازمانی با سهولت یکسان، بدون به خطر انداختن ثبات یا عملکرد پاداش آسان می کند. ردپای منبع سبکتر به این معنی است که کلاینت دارای حاشیه ایمنی بیشتری در زمانی که شبکه تحت استرس است باشد.
+
+در [اسناد Nimbus](https://nimbus.guide/) بیشتر بیاموزید
+
+### Prysm {#prysm}
+
+Prysm یک کلاینت اجماع با امکانات کامل و منبع باز است که با زبان Go تحت مجوز GPL-3.0 نوشته شده است. دارای یک رابط کاربری وب اپلیکیشن اختیاری است و تجربه کاربر، اسناد و قابلیت پیکربندی را هم برای کاربران شرکتی و هم برای کاربران سازمانی در اولویت قرار می دهد.
+
+برای اطلاعات بیشتر به [اسناد Prysm](https://docs.prylabs.network/docs/getting-started/) مراجعه کنید.
+
+### Teku {#teku}
+
+Teku یکی از کلاینت های اصلی Beacon Chain Genesis است. در کنار اهداف معمول (امنیت، استحکام، پایداری، قابلیت استفاده، عملکرد)، Teku به طور خاص به دنبال مطابقت کامل با استانداردهای مختلف کلاینت اجماع است.
+
+Teku گزینه های استقرار بسیار انعطاف پذیری را ارائه می دهد. گره beacon و کلاینت اعتبارسنج را می توان با هم به عنوان یک فرآیند واحد اجرا کرد که برای سهامگذاران انفرادی بسیار راحت است، یا گره ها را می توان به طور جداگانه برای عملیات های پیچیده ای اجرا کرد. علاوه بر این، Teku به طور کامل با [Web3Signer](https://github.com/ConsenSys/web3signer/) برای امضای امنیت کلید و حفاظت از جریمه قابل استفاده است.
+
+Teku به زبان جاوا نوشته شده و دارای مجوز آپاچی 2.0 است. این کلاینت توسط تیم Protocols در ConsenSys که مسئولیت Besu و Web3Signer را نیز بر عهده دارد، توسعه یافته است. در [اسناد Teku](https://docs.teku.consensys.net/en/latest/) بیشتر بیاموزید.
+
+## حالات همگامسازی {#sync-modes}
+
+برای پیگیری و تأیید دادههای جاری در شبکه، کلاینت اتریوم باید با آخرین حالت شبکه همگام شود. این کار با بارگیری کردن دادهها از همتایان، تأیید رمزنگاری یکپارچگی آنها و ایجاد یک پایگاه دادهی محلی زنجیرهی بلوکی انجام میشود.
+
+حالتهای همگامسازی رویکردهای متفاوتی را برای این فرایند با بدهبستانهای مختلف نشان میدهند. کلاینتها همچنین در پیادهسازیهای الگوریتمهای همگامسازی تفاوت دارند. برای اطلاع از جزئیات پیادهسازی، همیشه به مستندات رسمی کلاینت انتخابی خود مراجعه کنید.
+
+### حالتهای همگامسازی لایه اجرا {#execution-layer-sync-modes}
+
+لایه اجرا ممکن است در حالتهای مختلف اجرا شود تا با موارد استفاده متفاوت مطابقت داشته باشد، از اجرای مجدد حالت سراسریبلاکچین گرفته تا فقط همگامسازی با نوک زنجیره از یک نقطه بازرسی قابل اعتماد.
+
+#### همگامسازی کامل {#full-sync}
+
+یک همگامسازی کامل همه بلوکها (از جمله سرصفحهها و بدنههای بلوک) را دانلود میکند و با اجرای هر بلوک از زمان بلوک جنسیس، حالت بلاکچین را بهصورت تدریجی بازسازی میکند.
+
+- اعتماد را به حداقل میرساند و با تأیید هر تراکنش، بالاترین امنیت را ارائه میدهد.
+- ٰبا افزایش تعداد تراکنشها، پردازش همه تراکنشها ممکن است روزها تا هفتهها طول بکشد.
+
+[گرههای آرشیو](#archive-node) یک همگامسازی کامل را برای ایجاد (و حفظ) تاریخچه کاملی از تغییرات حالت ایجاد شده توسط هر تراکنش در هر بلوک انجام میدهند.
+
+#### همگامسازی سریع {#fast-sync}
+
+همانند یک همگامسازی کامل، یک همگامسازی سریع همه بلوکها (از جمله سرصفحهها، تراکنشها و رسیدها) را دانلود میکند. با این حال، بهجای پردازش مجدد تراکنشهای تاریخی، یک همگامسازی سریع هنگامی که به وضعیت وارد کردن و پردازش کردن بلوکها تغییر مییابد تا یک فول نود را تهیه کند، تا زمانی که به سررسید اخیر برسد، به رسیدها متکی است.
+
+- استراتژی همگامسازی سریع.
+- تقاضای پردازش را به نفع استفاده از پهنای باند کاهش می دهد.
+
+#### همگامسازی فوری {#snap-sync}
+
+همگامسازیهای سریع نیز زنجیره را بلوک به بلوک تأیید میکنند. با این حال، به جای شروع از بلوک جنسیس، یک همگامسازی فوری در یک نقطه بازرسی جدیدتر «معتمد» که به عنوان بخشی از بلاکچین واقعی شناخته شده است، شروع می شود. گره در حین حذف داده های قدیمی تر از سن معین، نقاط بازرسی دوره ای را ذخیره می کند. این اسنپشاتها برای بازسازی دادههای حالت در صورت نیاز به جای ذخیرهسازی برای همیشه استفاده میشوند.
+
+- سریعترین استراتژی همگام سازی، در حال حاضر به طور پیش فرض در شبکه اصلی اتریوم.
+- صرفهجویی در مصرف حافظه و پهنای باند شبکه بدون به خطر انداختن امنیت.
+
+[جزئیات بیشتر همگامسازی سریع](https://github.com/ethereum/devp2p/blob/master/caps/snap.md).
+
+#### همگامسازی سبک {#light-sync}
+
+حالت کلاینت سبک همهی هدرهای بلوک و دادههای بلوک را بارگیری میکند و برخی را بهطور تصادفی تأیید میکند. فقط نوک زنجیره را از نقاط بررسی مطمئن همگامسازی میکند.
+
+- با تکیه بر اعتماد به توسعهدهندگان و مکانیزم اجماع، تنها آخرین وضعیت را دریافت میکند.
+- کلاینت ظرف چند دقیقه با وضعیت فعلی شبکه آماده استفاده است.
+
+**نکته** همگامسازی سبک هنوز با اتریوم اثبات سهام کار نمیکند - نسخههای جدید همگامسازی سبک به زودی عرضه میشوند!
+
+[بیشتر در مورد کلاینت های سبک](/developers/docs/nodes-and-clients/light-clients/)
+
+### حالتهای همگامسازی لایه اجماع {#consensus-layer-sync-modes}
+
+#### همگامسازی خوشبینانه {#optimistic-sync}
+
+همگامسازی خوشبینانه یک استراتژی همگامسازی پس از ارتقاء مرج است که بهمنظور سازگاری با انتخاب و عقبنشینی طراحی شده است و به گرههای اجرا اجازه میدهد از طریق روشهای تعیینشده همگام شوند. موتور اجرا می تواند _بهطور خوشبینانه_ بلوک های بیکن را بدون تأیید کامل آنها وارد کند، آخرین هد را پیدا کند و سپس شروع به همگام سازی زنجیره با روش های بالا کند. سپس، پس از اینکه کلاینت اجرا به نتیجه رسید، اعتبار تراکنشهای موجود در زنجیره بیکن را به کلاینت اجماع اطلاع میدهد.
+
+[حزئیات بیشتر همگامسازی خوشبینانه](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md)
+
+#### همگامسازی نقطه بازرسی {#checkpoint-sync}
+
+همگامسازی نقطه بازرسی، که به عنوان همگامسازی ذهنی ضعیف نیز شناخته میشود، تجربه کاربری برتری را برای همگامسازی Beacon Node ایجاد میکند. این مبتنی بر فرضیات [فردیت ضعیف](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) است که امکان همگام سازی زنجیره بیکن از یک نقطه بازرسی ذهنی ضعیف اخیر را به جای جنسیس فراهم می کند. همگامسازیهای نقطه بازرسی با مفروضات اعتماد مشابهی مانند همگامسازی از زمان بلوک [جنسیس](/glossary/#genesis-block)، زمان همگامسازی اولیه را به میزان قابل توجهی سریعتر میکند.
+
+در عمل، این بدان معناست که گره شما به یک سرویس راه دور متصل می شود تا حالت های نهایی را بارگیری کند و به تأیید داده ها از آن نقطه ادامه می دهد. شخص ثالثی که داده ها را ارائه می دهد مورد اعتماد است و باید با دقت انتخاب شود.
+
+جزئیات بیشتر [همگامسازی نقطه بازرسی](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)
+
+## بیشتر بخوانید {#further-reading}
+
+- [اتریوم مقدماتی - بخش دوم - فهم گرهها](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _- ویل بارنز، 13 فوریه 2019_
+- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جاستین لروکس، 7 نوامبر 2019_
+
+## موضوعات مرتبط {#related-topics}
+
+- [بلوکها](/developers/docs/blocks/)
+- [شبکهها](/developers/docs/networks/)
+
+## آموزشهای مرتبط {#related-tutorials}
+
+- [Raspberry Pi 4 خود را فقط با اتصال کارت MicroSD به یک گره اعتبارسنج تبدیل کنید – راهنمای نصب](/developers/tutorials/run-node-raspberry-pi/) _– Raspberry Pi 4 خود را فلش کنید، یک کابل اترنت به آن وصل کنید، دیسک SSD را وصل کنید و دستگاه را روشن کنید تا Raspberry Pi 4 را به یک گره کامل اتریوم که لایه اجرا (شبکهی اصلی) و / یا لایه اجماع (زنجیرهی بیکن / اعتبارسنج) را اجرا میکند، تبدیل کنید._
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
new file mode 100644
index 00000000000..bc48499e54c
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
@@ -0,0 +1,61 @@
+---
+title: کاربرهای رقیق
+description: مقدمهای بر کاربر سبک اتریوم.
+lang: fa
+---
+
+اجرای گره کامل روشی خصوصی، مقاوم به سانسور و غیر متمرکز برای تعامل با شبکۀ اتریوم است. با داشتن یک گره کامل در واقع نسخۀ خود از بلاک چین را خواهید داشت که میتوانید از طریق آن به شبکۀ همتا به همتای اتریوم دسترسی مستقیم داشته باشید و در لحظه از آن پرس و جو کنید. به هر حال، اجرای گره کامل نیازمند مقادیر قابل توجه از منابع محاسباتی مانند حافظه، فضای ذخیرهسازی و قدرت پردازش است. بنابراین هر کس در شبکه نمیتواند گره خود را اجرا کند. در نقشۀ راه اتریوم چندین راهحل برای این مسئله وجود دارد برای مثال بیوضعیت بودن یکی از این راهحلهاست که البته چندین سال با اجرای آن فاصله داریم. برای آیندهای نزدیک، چارهای جز فدا کردنِ برخی از مزایای گره کامل در برابر بهبود کارکردی نداریم، این راهکار به افراد اجازه میدهد با الزامات سختافزاری حداقلی بتوانند گرههایی اجرا کنند. گرههایی که این کار را میکنند گره سبک نام دارند.
+
+## کاربر سبک چیست؟ {#what-is-a-light-client}
+
+گره سبک گرهای است که نرمافزار کاربر سبک را اجرا میکند. به جای نگهداری از نسخه های محلی از زنجیرهی بلوکی و تائید مستقل همه تغییرات، در عوض آنها داده های لازم را از بعضی از ارائه دهندگان درخواست می کنند. ارائه دهنده ممکن است به گره کامل دسترسی مستقیم، یا طریق یک سرور RPC متمرکز شده، داشته باشد. پس از آن داده توسط گره سیک تائید می شود، که اجازه می دهد با سر یا راس زنجیره همگام شود. در واقع گره سبک فقط سرتیتر بلوکها را پردازش و نگهداری میکند و فقط در شرایط خاصی محتوای کامل یک بلوک را دانلود میکند. گرهها بسته به ترکیب نرمافزار سَبُکی و کاربر کاملی که اجرا میکنند، میتوانند از نظر سَبُکی متفاوت باشند. برای مثال، سبکترین پیکربندی شامل اجرای یک کاربر اجرای سبک و یک کاربر اجماع سبک خواهد بود. همچنین ممکن است بسیاری از گرهها بخواهند یک گره کامل در لایه اجرا و یک گره سبک در لایه اجماع یا بالعکس باشند.
+
+## کاربرهای سبک چگونه کار میکنند؟ {#how-do-light-clients-work}
+
+زمانی که شبکه اتریوم شروع به استفاده از مکانیزم اجماع اثبات سهام کرد، زیرساخت جدیدی مخصوص پشتیبانی از کاربرهای سبک معرفی شد. این سیستم با انتخاب تصادفی یک زیرمجموعه از دستههای متشکل از 512 گره اعتبارسنج در هر 1.1 ثانیه کار میکند که به عنوان یک **کمیتۀ همگامسازی** عمل میکند. این کمیته همگامسازی، سرتیتر بلوکهای جدید را امضا میکند. سرتیتر هر بلوک شامل امضای تجمیعی اعتبارسنجهای کمیته همگامسازی و نیز یک bifield است که نشان میدهد کدام اعتبارسنجها امضا کرده و کدام یک امضا نکردهاند. به علاوه در سرتیتر بلوک یک لیست اعتبارسنجهایی وجود دارد که انتظار میرود د امضای بلوک بعدی شرکت کنند. در نتیجه یک گره سبک به سرعت میتواند تایید کمیته اعتبارسنج و همچنین اصالت کمیته را بررسی کند، آنها این کار را با مقایسۀ دادههای دریافتی با دادۀ مورد انتظارشان در بلاک قبلی انجام میدهند. از این طریق، گره سبک میتواند بدون دانلود زنجیرۀ کامل اتریوم و تنها با استفاده از سرتیترها، خود را با آخرین وضعیت بلاک چین همگام کند.
+
+در لایۀ اجرا هیچ مشخصات دقیقی برای گرههای سبک وجود ندارد. گره سبک در لایۀ اجرا میتواند یک «حالت سبک» از گره کامل باشد که مشابه با آن دارای تمام قابلیتهای شبکه و ماشین مجازی اتریوم است اما تنها سرتیتر بلاکها را بدون دانلود آنها تایید میکند، یا ممکن است یک کلاینت خلاصهتر باشد که برای تعامل خود با شبکه اتریوم به درخواستهای RPC ارسالی به یک سرور خارجی متکی است.
+
+## چرا گرههای سبک مهم هستند؟ {#why-are-light-clients-important}
+
+گره سبک از این منظر اهمیت دارد که به کاربران امکان میدهد به جای اعتماد کورکورانه به خدمات یک اپراتور واسطه، دادههای ورودی را با تنها کسر کوچکی از منابع محاسباتی یک گره کامل تایید کنند. گرههای سبک میتوانند درستی دادههای دریافتی را با سرتیتر بلاکها که میدانند توسط حداقل دو سومِ مجموعهای تصادفی از 512 اعتبارسنج اتریوم امضا شدهاند، کنترل کنند. این میتواند مدرکی قوی از صحت دادهها باشد.
+
+اجرای یک گره سبک فقط به مقدار کمی قدرت محاسباتی، حافظه و فضای ذخیرهسازی نیاز دارد، بنابراین با یک دستگاه موبایل و از طریق اپلیکیشن یا افزونه مرورگر میتوان به یک گره سبک در شبکه تبدیل شد. در واقع گره سبک روشی بینیاز از اعتماد برای دسترسی به اتریوم است که به همان اندازۀ وابستگی به طرف یک واسطه یا اپراتور خارجی، بدون زحمت و آسان است.
+
+یک مثال ساده را میتوان برای روشن شدن موضوع در نظر گرفت. فرض کنید میخواهیم آخرین موجودی آدرس خود را چک کنیم. برای این کار باید درخواستی را به یک گره کامل اتریوم ارسال کنیم. گره کامل پس از بررسی نسخۀ محلی خود از وضعیت اتریوم میتواند موجودی حساب را به شما اعلام کند. به هر حال، بسیاری از کاربران دسترسی مستقیم به یک گره کامل ندارند و باید از اپراتورهای متمرکز که این خدمات را ارائه میدهند، استفاده کنند. درخواست به آنها ارسال میشود و نتیجه به شما باز میگردد. یک مشکل جدی وجود دارد، باید به آن اپراتور خارجی و صحت دادههایش اعتماد کنید. تا خودتان به عنوان یک گره آنها را تایید نکنید، هرگز راهی وجود ندارد تا از صحت اطلاعات به طور کامل مطمئن شوید.
+
+گره سبک این مشکل را رفع میکند. البته لازم به ذکر است که همچنان دادهها باید از یک اپراتور خارجی درخواست شوند اما وقتی دادهها دریافت شد، گره سبک میتواند صحت آنها را با اطلاعات موجود در سرتیتر بلاکها کنترل کند، در این صورت است که میتوان از درستی دادهها اطمینان داشت. در واقع، اینجا، به جای یک اپراتور مورد اعتماد، خودِ شبکۀ اتریوم است که درستی دادهها را تایید میکند.
+
+## با گره سبک چه ابداعاتی ممکن میشوند؟ {#what-innovations-do-light-clients-enable}
+
+توانمندسازی افراد در دسترسی به شبکۀ اتریوم به صورت مستقل و با سطحی حداقلی از الزامات سختافزاری و اتکا به واسطهها، مزیت اصلی گره سبک است. این برای کاربران سودمند است زیرا میتوانند دادهها را خود تایید کنند و برای شبکه خوب است چون تعداد و تنوع گرههای مشارکتکننده در تایید بلاکها را افزایش میدهد.
+
+توانایی در اجرای گره اتریوم روی دستگاههایی با فضای ذخیره، حافظه و قدرت پردازش محدود، اصلیترین زمینۀ نوآوریهای بعدی است که به واسطۀ راهحل گره سبک شکوفا خواهند شد. در حالی که گرههای اتریوم در حال حاضر نیاز به مقدار قابل توجهی منابع محاسباتی دارند، گره سبک میتواند در مرورگرها تعبیه شود، روی دستگاه موبایل یا حتی دستگاههای کوچکتر مثل ساعت هوشمند اجرا شود. این بدان معناست که کیف پولهای اتریوم با کلاینتهای تعبیهشده میتوانند روی تلفن همراه اجرا شوند. بنابراین کیف پولهای موبایل میتوانند بیشتر از این غیر متمرکز شوند زیرا نیازی به دادههای تامینکنندگان متمرکز ندارند.
+
+فراتر از این، نوآوری گره سبک به **پیادهسازی فناوری اینترنت اشیا (IoT)** کمک میکند. یک گره سبک میتواند به سرعت مالکیت یک توکن یا NFT را تایید کند و فعالیتهایی را در شبکۀ اینترنت اشیا انجام دهد. یک [سرویس کرایۀ دوچرخه](https://youtu.be/ZHNrAXf3RDE?t=929) را در نظر بگیرید که با اجرای یک گره سبک به سرعت میتواند توکن NFT مربوط به سرویس دوچرخه را تایید کند و قفل دوچرخه را برای استفادۀ کاربر باز کند!
+
+رولآپهای اتریوم نیز میتوانند از گرههای سبک بهرهمند شوند. یکی از مشکلات اساسی آنها حملات هکری به پلتفرمهای پل است که برای انتقال داراییها از شبکۀ اصلی اتریوم به یک رولآپ استفاده میشوند. آسیبپذیری اصلی در اراکل بروز میکند که برای اطلاع از واریز شدنِ وجوه کاربر در پلتفرم پل، توسط رولآپ استفاده میشوند. اگر یک اراکل دادههای غلط بفرستد میتواند رولآپ را متقاعد کند که وجوه کاربر به پلتفرم پل فرستاده شدهاند و موجب شود وجوهی را به اشتباه آزاد کند. اجرای گره سبک در یک رولآپ میتواند در برابر اراکل مخرب ایستادگی کند زیرا واریز وجوه به پلتفرم پل توسط خودِ رولآپ تایید میشود. همین مفهوم میتواند برای سایر پلتفرمهای پل بینرنجیرهای نیز صادق باشد.
+
+گرههای سبک همچنین به ارتقای کیف پولهای اتریوم کمک میکنند. به جای اعتماد به دادههای یک اپراتور خارجی، کیف پول شما میتواند با استفاده از یک گره سبک دادهها را به صورت مستقیم تایید کند. این موضوع به افزایش امنیت کیف پولهای اتریوم میانجامد. اگر اپراتور خارجی، متقلب باشد و دادههای نادرست در اختیارتان بگذارد، گره سبک به شما خواهد گفت!
+
+## وضعیت فعلی پیشرفت گره سبک چگونه است؟ {#current-state-of-development}
+
+اکنون چندین نوع گره سبک در حال توسعه هستند که گرههای اجرای سبک، گرههای اجماع سبک یا ترکیبی از این دو هستند. اینها مثالهایی از پیادهسازی گره سبک هستند که تا زمان نوشتن این صفحه وجود دارند:
+
+- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): گره سبک اجماع در زبان TypeScript
+- [Helios](https://github.com/a16z/helios): گره سبک ترکیبی اجماع و اجرا در زبان Rust
+- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): گره سبک اجرا در زبان Go
+- [Nimbus](https://nimbus.guide/el-light-client.html): گره سبک اجماع در زبان Nim
+
+تا آنجا که میدانیم هیچ کدام از این موارد هنوز تولید نهایی نیستند.
+
+همچنین تلاش زیادی لازم است تا راههای دسترسی گرههای سبک به دادههای شبکۀ اتریوم بهبود داده شوند. در حال حاضر، فناوری گره سبک به درخواستهای RPC از گرههای کامل که از مدل سرور/ کلاینت استفاده میکنند، متکی است، اما در آینده، دادهها میتوانند به روشی غیرمتمرکز با استفاده از شبکههای اختصاصی مانند [Portal Network](https://www.ethportal.net/) درخواست شوند که دادههای گره سبک را با استفاده از پروتکل گاسیپ فرد به فرد تامین میکنند.
+
+سایر موارد موجود در [نقشۀ راه اتریوم](/roadmap/) مانند [درخت ورکل](/roadmap/verkle-trees/) و [بیوضعیت بودن](/roadmap/statelessness/) در نهایت میتوانند امنیت گرههای سبک را به امنیت یک گره کامل برسانند.
+
+## بیشتر بخوانید {#further-reading}
+
+- [Zsolt Felfodhi در کلاینتهای Geth light](https://www.youtube.com/watch?v=EPZeFXau-RE)
+- [Etan Kissling در شبکههای کلاینتهای سبک](https://www.youtube.com/watch?v=85MeiMA4dD8)
+- [Etan Kissling درباره کلاینتهای سبک بعد از ادغام](https://www.youtube.com/watch?v=ZHNrAXf3RDE)
+- [Piper Merriam: جاده پر پیچ و خم به سمت مشتریان سبک کاربردی](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
new file mode 100644
index 00000000000..d98b0f7bc75
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
@@ -0,0 +1,57 @@
+---
+title: معماری گره
+description: مقدمهای درباره نحوه سازماندهی گرههای اتریوم.
+lang: fa
+---
+
+یک گره اتریوم از دو کاربر تشکیل شده است: یک [کاربر اجرا](/developers/docs/nodes-and-clients/#execution-clients) و یک [کاربر اجماع](/developers/docs/nodes-and-clients/#consensus-clients).
+
+زمانی که اتریوم از [مکانیسم اثبات کار](/developers/docs/consensus-mechanisms/pow/) استفاده میکرد، یک کاربر اجرا برای اجرای یک گره کامل اتریوم کافی بود. اما، از زمان اجرای [مکانیسم اثبات سهام](/developers/docs/consensus-mechanisms/pow/)، کاربر اجرا میبایست در کنار نرمافزار دیگری به نام [کاربر اجماع ](/developers/docs/nodes-and-clients/#consensus-clients) استفاده شود.
+
+نمودار زیر رابطۀ بین دو کاربر اتریوم را نشان میدهد. هر یک از این دو کاربر به شبکههای همتا به همتای (P2P) مخصوص خود متصل میشوند. دلیل نیاز به شبکههای همتا به همتای جداگانه این است که: کاربرهای اجرا تراکنشها را از طریق شبکۀ همتا به همتای خود شایعه میکنند که آنها را قادر میسازد استخر تراکنشهای محلی خود را مدیریت کنند، در حالی که کاربرهای اجماع، بلوکها را از طریق شبکۀ همتا به همتا شایعه میکنند، که امکان اجماع و رشد زنجیره را فراهم میکند.
+
+![](node-architecture-text-background.png)
+
+برای اینکه این ساختار دوکاربری بتواند کار کند، کاربرهای اجماع باید دستهای از تراکنشها را به کاربر اجرا منتقل کنند. اجرای تراکنشها به صورت محلی اینگونه است که کاربر تایید میکند تراکنشها هیچ یک از قوانین اتریوم را نقض نمیکنند و بهروزرسانی پیشنهادی برای حالت اتریوم صحیح است. به همین ترتیب، هنگامی که گره به عنوان تولیدکنندۀ بلوک برگزیده میشود، کاربر اجماع باید بتواند دستهای از تراکنشها را از Geth درخواست کند تا در بلوک جدید گنجانده شود و آنها را برای بهروزرسانی حالت کل شبکه اجرا کند. این ارتباط بینِ کاربری توسط یک اتصال RPC محلی با استفاده از [موتور API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) اداره میشود.
+
+## کاربر اجرا چه میکند؟ {#execution-client}
+
+کاربر اجرا مسئول رسیدگی به تراکنش، شایعه تراکنش، مدیریت حالت و پشتیبانی از ماشین مجازی اتریوم ([EVM](/developers/docs/evm/)) است. ولی مسئولیتی در قبال ساخت بلوک، شایعه بلوک یا مدیریت منطق اجماع **ندارد**. این موارد، در حیطۀ اختیارات کاربر اجماع است.
+
+کاربر اجرا، پیلودهای اجرا را ایجاد میکند که شامل فهرست تراکنشها، آزمایش حالت بهروزشده و سایر دادههای مربوط به اجرا میشود. کاربرهای اجماع شامل پیلود اجرا در هر بلوک است. کاربر اجرا همچنین مسئول اجرای مجدد تراکنشها در بلوکهای جدید به منظور اطمینان از معتبر بودن آنها است. اجرای تراکنشها بر روی کامپیوتر تعبیهشدۀ کاربر اجرا به نام [ماشین مجازی اتریوم (EVM)](/developers/docs/evm) انجام میشود.
+
+کاربر اجرا همچنین از طریق [روشهای RPC](/developers/docs/apis/json-rpc) یک رابط کاربری برای اتریوم فراهم میکند که کاربران را قادر میسازد از بلاکچین اتریوم درخواست اطلاعات کنند، تراکنشها را ارسال کنند و قراردادهای هوشمند را به شیوهای مؤثر به کار گیرند. معمولا تماسهای RPC توسط کتابخانهای مانند [Web3js](https://docs.web3js.org/) یا [Web3py](https://web3py.readthedocs.io/en/v5/) یا یک رابط کاربری مانند کیف پول مرورگر انجام میشود.
+
+به طور خلاصه، کاربر اجرا عبارت است از:
+
+- یک دروازۀ کاربری به اتریوم
+- خانۀ ماشین مجازی اتریوم، استخر تراکنش و حالت اتریوم.
+
+## کاربر اجماع چه میکند؟ {#consensus-client}
+
+کاربر اجماع با تمام منطقی سر و کار دارد که یک گره را قادر میسازد با شبکۀ اتریوم همگام بماند. این موارد شامل دریافت بلوکها از همتایان و اجرای یک الگوریتم انتخاب فورک است تا اطمینان حاصل شود گره همواره زنجیرهای با بیشترین انباشت گواه را دنبال میکند (وزندهیشده توسط ترازهای مؤثر اعتبارسنج). مشابه کاربر اجرا، کاربرهای اجماع نیز شبکۀ همتا به همتای خود را دارند که از طریق آن بلوکها و تصدیقها را به اشتراک میگذارند.
+
+کاربر اجماع در تایید یا پیشنهاد بلوکها شرکت نمیکند - این کار توسط یک اعتبارسنج انجام میشود که یک افزونۀ اختیاری برای کاربر اجماع محسوب میشود. یک کاربر اجماع بدون یک اعتبارسنج تنها با سر زنجیره همگام میشود و به گره اجازۀ همگامسازی میدهد. این امر به کاربران امکان میدهد با استفاده از کاربر اجرای خود با اتریوم تراکنش کنند با این اطمینان که در زنجیرۀ صحیح قرار دارند.
+
+## اعتبارسنج ها {#validators}
+
+اپراتورهای گره میتوانند با واریز 32 اتریوم در قرارداد سپرده، یک اعتبارسنج را به کاربر اجماع خود اضافه کنند. کاربر اعتبارسنج با کاربر اجماع همبسته است و میتواند در هر زمان به یک گره اضافه شود. اعتبارسنج، تصدیقها و پیشنهادهای بلوک را مدیریت میکند. آنها یک گره را قادر میسازند تا از طریق جریمه یا اسلشینگ به جمعآوری پاداش بپردازد یا ETH از دست بدهد. اجرای نرمافزار اعتبارسنج همچنین باعث انتخاب یک گره واجد شرایط برای پیشنهاد یک بلوک جدید میشود.
+
+[در مورد سهام گذاری بیشتر بخوانید](/staking/).
+
+## مقایسۀ اجزای گره {#node-comparison}
+
+| کاربر اجرا | کاربر اجماع | اعتبارسنج |
+| --------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------ |
+| تراکنشهای را از طریق شبکۀ همتا به همتای خود شایعه میکند | از طریق شبکۀ همتا به همتای خود، بلوکها و تصدیقها را شایعه میکند | بلوکها را پیشنهاد میکند |
+| تراکنشها را اجرا/ بازاجرا میکند | الگوریتم انتخاب فورک را اجرا میکند | پاداشها/جریمهها را میگیرد |
+| تغییرات حالت ورودی را تایید میکند | سر زنجیره را پیگیری میکند | تصدیقها را میسازد |
+| تلاشهای حالت و رسیدها را مدیریت میکند | حالت بیکن را مدیریت میکند (شامل اطلاعات اجماع و اجرا) | برای سهام گذاری شدن به 32 اتریوم نیاز دارد |
+| پیلود اجرا را ایجاد میکند | تصادفی بودن انباشتهشده در RANDAO را ردیابی میکند | قابل اسلش شدن است |
+| JSON-RPC API را برای تعامل با اتریوم در معرض قرار میدهد | توجیه و نهایی شدن را پیگیری میکند | |
+
+## بیشتر بخوانید {#further-reading}
+
+- [اثبات سهام](/developers/docs/consensus-mechanisms/pos)
+- [پیشنهاد بلوک](/developers/docs/consensus-mechanisms/pos/block-proposal)
+- [پاداشها و جریمههای اعتبارسنج](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
new file mode 100644
index 00000000000..603008296b5
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
@@ -0,0 +1,419 @@
+---
+title: گرهها بهعنوان سرویس
+description: مرور کلی خدمات گره، مزایا و معایب آنها و ارائهدهندگان محبوب برای تازهواردان.
+lang: fa
+sidebarDepth: 2
+---
+
+## مقدمه {#Introduction}
+
+اجرای [گره اتریوم](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) میتواند چالش برانگیز باشد، به خصوص زمانی که به سرعت شروع میشود یا هنگامی که به سرعت مقیاسپذیر میشود. [سرویسهای متعددی](#popular-node-services) وجود دارند که زیرساختهای گرهی بهینهسازیشدهای را برای شما اجرا میکنند، بنابراین میتوانید به جای آن بر توسعهی برنامه یا محصول خود تمرکز کنید. ما نحوهی عملکرد سرویسهای گره، مزایا و معایب استفاده از آنها را توضیح میدهیم و در صورت تمایل به شروع، ارائهدهندگان آنها را فهرست خواهیم کرد.
+
+## پیشنیازها {#prerequisites}
+
+اگر از قبل درک درستی از گرهها و کلاینتها ندارید، به [گرهها و کلاینتها](/developers/docs/nodes-and-clients/) مراجعه کنید.
+
+## سهام گذاران {#stakoooooooooooooors}
+
+سهامداران انفرادی به جای اتکا به ارائه دهندگان شخص ثالث، باید زیرساخت خود را اجرا کنند. این به معنای اجرای یک کلاینت اجرا همراه با یک کلاینت اجماع است. قبل از [ادغام](/roadmap/merge)، این امکان وجود داشت که فقط یک کلاینت اجماع اجرا شود و از یک ارائه دهنده متمرکز برای داده های اجرا استفاده شود. این دیگر امکانپذیر نیست - یک سهام گذار انفرادی باید هر دو مشتری را اجرا کند. با این حال، خدماتی برای تسهیل این فرآیند وجود دارد.
+
+[در مورد اجرای یک گره بیشتر بخوانید](/developers/docs/nodes-and-clients/run-a-node/).
+
+خدماتی که در این صفحه توضیح داده شده است برای گره های بدون شرط بندی است.
+
+## سرویسهای گره چگونه کار میکنند؟ {#how-do-node-services-work}
+
+ارائهدهندگان خدمات گره، کلاینتهای گره توزیع شده را در پشتصحنه برای شما اجرا میکنند، بنابراین نیازی ندارید که خودتان آنها را انجام دهید.
+
+این سرویسها معمولاً یک کلید API ارائه میکنند که میتوانید از آن برای نوشتن و خواندن از زنجیرهی بلوکی استفاده کنید. آنها اغلب علاوه بر شبکهی اصلی به [شبکههای تست اتریوم](/developers/docs/networks/#ethereum-testnets) نیز دسترسی دارند.
+
+برخی از سرویسها، گره اختصاصی خودشان را به شما ارائه میدهند و آنها را برای شما مدیریت میکنند، در حالی که برخی دیگر از متعادلکنندههای بار برای توزیع فعالیت در گرهها استفاده میکنند.
+
+ادغام با اغلب سرویسهای گره بهشدت آسان است، که معمولاً شامل یک خط تغییر در کد خود برای تعویض گرهی که خودتان میزبانی میکنید یا حتی جابجایی آنها بین خودشان میشود.
+
+سرویسهای گره اغلب [کلاینتهای گره](/developers/docs/nodes-and-clients/#execution-clients) و [انواع گره](/developers/docs/nodes-and-clients/#node-types) گوناگونی را اجرا میکنند که به شما این امکان را میدهد علاوه بر روشهای خاص کلاینت در یک API به گرههای کامل و بایگانیشده نیز دسترسی داشته باشید.
+
+خاطرنشان میشود که سرویسهای گرهْ کلیدهای خصوصی یا اطلاعات شما را نباید و نمیتوانند ذخیره کنند.
+
+## مزایای استفاده از یک سرویس گره چیست؟ {#benefits-of-using-a-node-service}
+
+مزیت اصلی استفاده از سرویس گره این است که نیازی به صرف زمان مهندسی برای نگهداری و مدیریت گرهها ندارید. این کار به شما امکان میدهد بهجای نگرانی در مورد تعمیر و نگهداری زیرساخت، روی ساخت محصول خود تمرکز کنید.
+
+اجرای گرههای شخصی شما از ذخیرهسازی تا پهنای باند و زمان مهندسی ارزشمند شما، میتواند بسیار هزینهبر باشد. مواردی مانند چرخش تعداد بیشتری گره هنگام مقیاسبندی، ارتقای گرهها به آخرین نسخهها و اطمینان از ثبات وضعیت، میتواند حواس را از ساختن و صرف منابع روی محصول Web3 موردنظر شما منحرف کند.
+
+## معایب استفاده از یک سرویس گره چیست؟ {#cons-of-using-a-node-service}
+
+با استفاده از یک سرویس گره، وضعیت زیرساختی محصول خود را متمرکز میکنید. به همین دلیل، پروژههایی که در آنها تمرکززدایی از اهمیت بالایی برخوردار است، ممکن است گرههای خود میزبان را به برونسپاری به طرف ثالث ترجیح دهند.
+
+درباره [مزایای اجرای گره خودتان](/developers/docs/nodes-and-clients/#benefits-to-you) بیشتر بخوانید.
+
+## سرویسهای گره محبوب {#popular-node-services}
+
+در اینجا فهرستی از محبوب ترین ارائهدهندگان گره اتریوم آورده شده است، بهراحتی میتوانید مواردی که درج نشدهاند را اضافه کنید! هر سرویس گره علاوه بر سطوح رایگان یا پولی، مزایا و ویژگیهای مختلفی را ارائه میکند، شما باید قبل از تصمیمگیری، بررسی کنید که کدامیک به بهترین شکل با نیازهای شما مطابقت دارند.
+
+- [**شیمی**](https://alchemy.com/)
+ - [مستندات](https://docs.alchemyapi.io/)
+ - ویژگیها
+ - دارای بزرگترین سطح کاربری رایگان با 300 میلیون واحد محاسباتی در ماه (حدود 30 میلیون درخواست getLatestBlock)
+ - پشتیبانی چند زنجیرهای برای Polygon، Starknet، Optimism، Arbitrum
+ - قدرتبخشی به حدود 70% بزرگترین dappهای اتریوم و حجم تراکنش دیفای
+ - هشدارهای قلابهای وب لحظهای از طریق Alchemy Notify
+ - بهترین پشتیبانی و اطمینانپذیری / ثبات در این سطح
+ - NFT API متعلق به Alchemy
+ - داشبورد با Request Explorer، Mempool Watcher و Composer
+ - دسترسی به فاست شبکهی تست یکپارچه
+ - انجمن سازنده Active Discord با 18 هزار کاربر
+
+- [**همه آن نود**](https://allthatnode.com/)
+ - [مستندات](https://docs.allthatnode.com/)
+ - ویژگیها
+ - 50000 درخواست در روز با ردیف آزاد
+ - پشتیبانی از بیش از 40 پروتکل
+ - از JSON-RPC (EVM, Tendermint) و REST و APIهای وبسوکت پشتیبانی میشود
+ - دسترسی نامحدود به داده های آرشیو
+ - پشتیبانی فنی 24/7 و آپتایم 99.9 درصد
+ - فاست در چند زنجیر موجود است
+ - دسترسی نامحدود به اندپوینت با تعداد نامحدود کلیدهای API
+ - پشتیبانی از ردیابی/دیباگ API
+ - بهروزرسانیهای خودکار
+
+- [**بلاک چین مدیریت شده آمازون**](https://aws.amazon.com/managed-blockchain/)
+ - [مستندات](https://aws.amazon.com/managed-blockchain/resources/)
+ - ویژگیها
+ - گره های کاملاً مدیریت شده اتریوم
+ - موجود در شش منطقه جغرافیایی
+ - JSON-RPC از طریق HTTP و WebSocket های امن
+ - پشتیبانی از 3 زنجیره
+ - SLAها، پشتیبانی 24/7 از AWS
+ - Go-ethereum و Lighthouse
+
+- [**Ankr**](https://www.ankr.com/)
+ - [مستندات](https://docs.ankr.com/)
+ - ویژگیها
+ - پروتکل Ankr - دسترسی به نقاط پایانی وب سرویس RPC عمومی را برای بیش از 8 زنجیره باز میکند
+ - تعادل بار و نظارت بر سلامت گره برای یک گذرگاه سریع و قابلاعتماد به نزدیکترین گره موجود
+ - سطح ممتاز که نقطه پایانی WSS و محدودیت نرخ بدون سقف را فعال میکند
+ - استقرار گره کامل و اعتبارسنج با یک کلیک برای بیش از 40 زنجیره
+ - مقیاسپذیری دلخواه
+ - ابزارهای تحلیل
+ - داشبورد
+ - نقاط پایانی RPC، HTTPS و WSS
+ - پشتیبانی مستقیم
+
+- [**انفجار**](https://blastapi.io/)
+ - [مستندات](https://docs.blastapi.io/)
+ - ویژگیها
+ - پشتیبانی RPC و WSS
+ - میزبانی از گره در چندین منطقه
+ - زیرساخت غیرمتمرکز
+ - API عمومی
+ - طرح رایگان اختصاصی
+ - پشتیبانی از چند زنجیره (بیش از 17 بلاکچین)
+ - نودهای آرشیوی
+ - پشتیبانی 24/7 در Discord
+ - مانیتورینگ و هشداردهی 24/7
+ - SLA کلی در سطح 99.9 درصد
+ - پرداخت با رمزارز
+
+- [**BlockDaemon**](https://blockdaemon.com/)
+ - [مستندات](https://ubiquity.docs.blockdaemon.com/)
+ - مزایا
+ - داشبورد
+ - بر اساس پایه گره
+ - تجزیه و تحلیل
+
+- [**BlockPI**](https://blockpi.io/)
+ - [مستندات](https://docs.blockpi.io/)
+ - ویژگیها
+ - قوی & ساختار گره توزیع شده
+ - حداکثر 40 نقطه پایانی HTTPS و WSS
+ - بسته ثبتنام رایگان و بسته ماهانه
+ - روش ردیابی + پشتیبانی از دادههای آرشیو
+ - بستهها تا 90 روز اعتبار دارند
+ - برنامهریزی سفارشی و پرداخت دلخواه
+ - پرداخت با رمزارز
+ - پشتیبانی مستقیم & پشتیبانی فنی
+
+- [**Chainbase**](https://www.chainbase.com/)
+ - [مستندات](https://docs.chainbase.com)
+ - ویژگیها
+ - سرویس RPC بسیار در دسترس، سریع و مقیاسپذیر
+ - پشتیبانی از چندزنجیره
+ - تعرفههای رایگان
+ - داشبورد کاربرپسند
+ - خدمات داده بلاک چین را فراتر از RPC ارائه میدهد
+
+- [**Chainstack**](https://chainstack.com/)
+ - [مستندات](https://docs.chainstack.com/)
+ - ویژگیها
+ - گرههای اشتراکی رایگان
+ - گرههای اشتراکی آرشیو
+ - پشتیبانی از GraphQL
+ - نقاط پایانی RPC و WSS
+ - گرههای کامل و بایگانی اختصاصی
+ - همگامسازی سریع برای استقرار اختصاصی
+ - اتصال به سرویسهای ابری خود
+ - هزینهی ساعتی
+ - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
+
+- [**DataHub**](https://datahub.figment.io)
+ - [اسناد](https://docs.figment.io/)
+ - ویژگیها
+ - گزینهی سطح کاربری رایگان با 3,000,000 درخواست در ماه
+ - نقاط پایانی RPC و WSS
+ - گرههای کامل و بایگانی اختصاصی
+ - مقیاسبندی خودکار (تخفیف حجمی)
+ - دادههای بایگانیشدهی رایگان
+ - تجزیه و تحلیل سرویس
+ - داشبورد
+ - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
+ - پرداخت با رمزارز (سازمانی)
+
+- [**DRPC**](https://drpc.org/)
+ - [مستندات](https://docs.drpc.org/)
+ - ویژگیها
+ - گرههای RPC غیرمتمرکز
+ - بیش از 15 ارائه دهنده گره
+ - تعادل گره
+ - واحدهای محاسباتی نامحدود ماهانه به صورت رایگان
+ - تایید دادهها
+ - نقاط پایانی سفارشی
+ - نقاط پایانی HTTP و WSS
+ - کلیدهای نامحدود (ردیف رایگان و پولی)
+ - گزینههای بازگشتی یا فالبک انعطافپذیر
+ - [نقطه پایانی عمومی](https://eth.drpc.org)
+ - گرههای بایگانیشدهی اشتراکی رایگان
+
+- [**GetBlock**](https://getblock.io/)
+ - [مستندات](https://getblock.io/docs/get-started/authentication-with-api-key/)
+ - ویژگیها
+ - دسترسی به بیش از 40 گره زنجیره بلوکی
+ - 40 هزار درخواست رایگان روزانه
+ - کلیدهای API نامحدود
+ - سرعت اتصال بالا به میزان 1 گیگابایت بر ثانیه
+ - ردیابی+آرشیو
+ - تجزیه و تحلیل پیشرفته
+ - بهروزرسانیهای خودکار
+ - پشتیبانی فنی
+
+- [**InfStones**](https://infstones.com/)
+ - ویژگیها
+ - گزینه ردیف رایگان
+ - مقیاسپذیری دلخواه
+ - تجزیه و تحلیل
+ - داشبورد
+ - نقاط پایانی منحصربهفرد API
+ - گرههای کامل اختصاصی
+ - همگامسازی سریع برای استقرار اختصاصی
+ - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
+ - دسترسی به بیش از 50 گره زنجیره بلوکی
+
+- [**Infura**](https://infura.io/)
+ - [مستندات](https://infura.io/docs)
+ - ویژگیها
+ - گزینه ردیف رایگان
+ - مقیاسپذیری دلخواه
+ - دادههای بایگانیشدهی پولی
+ - پشتیبانی مستقیم
+ - داشبورد
+
+- [**Kaleido**](https://kaleido.io/)
+ - [مستندات](https://docs.kaleido.io/)
+ - ویژگیها
+ - ردیف رایگان برای شروع کار
+ - استقرار گره اتریوم با یک کلیک
+ - کلاینتها و الگوریتمهای قابل تنظیم (Geth، Quorum و Besu || PoA، IBFT و Raft)
+ - بیش از 500 API اداری و خدماتی
+ - رابط RESTful برای ارسال تراکنش اتریوم (با پشتیبانی Apache Kafka)
+ - جریانهای خروجی برای ارائه رویداد (با پشتیبانی Apache Kafka)
+ - مجموعهای عمیق از خدمات «خارج زنجیره» و فرعی (مانند حملونقل پیامهای رمزگذاریشدهی دوجانبه)
+ - نصب راحت و سریع روی شبکه با کنترل دسترسی مبتنی بر نقش و حاکمیت
+ - مدیریت پیشرفتهی کاربر هم برای مدیران و هم برای کاربران نهایی
+ - زیرساخت بسیار مقیاس پذیر، تابآورتر و در سطح سازمانی
+ - مدیریت کلید خصوصی Cloud HSM
+ - اتصال شبکهی اصلی اتریوم
+ - گواهینامههای ISO 27k و SOC 2، نوع 2
+ - پیکربندی پویای زمان اجرا (بهعنوان مثال افزودن ادغامهای ابری، تغییر ورودی گرهها و غیره)
+ - پشتیبانی از ارکستراسیونهای چند ابری، چند منطقهای و ترکیبی استقرار
+ - قیمتگذاری ساعتی ساده مبتنی بر SaaS
+ - SLAها و پشتیبانی شبانهروزی در تمام ایام هفته
+
+- [**شبکه لاوا (Lava)**](https://www.lavanet.xyz/)
+ - [مستندات](https://docs.lavanet.xyz/)
+ - ویژگیها
+ - استفاده رایگان از شبکهی تست
+ - افزونگی غیرمتمرکز برای آپ تایم بالا
+ - متن باز
+ - SDK کاملا غیرمتمرکز
+ - ادغام Ethers.js
+ - رابط مدیریت پروژه بصری
+ - یکپارچگی داده مبتنی بر اجماع
+ - پشتیبانی چند زنجیرهای یا مالتی چین
+
+- [**Moralis**](https://moralis.io/)
+ - [مستندات](https://docs.moralis.io/)
+ - ویژگیها
+ - گرههای اشتراکی رایگان
+ - گرههای بایگانیشدهی اشتراکی رایگان
+ - تمرکز بر حفظ حریم خصوصی (سیاست عدم حفظ سوابق کار)
+ - پشتیبانی از زنجیرهی متقاطع
+ - مقیاسپذیری دلخواه
+ - داشبورد
+ - SDK اتریوم منحصربهفرد
+ - نقاط پایانی منحصربهفرد API
+ - پشتیبانی فنی مستقیم
+
+- [**مگانود نودرئال**](https://nodereal.io/)
+ - [مستندات](https://docs.nodereal.io/nodereal/meganode/introduction)
+ - ویژگیها
+ - خدمات RPC ایپیآی قابل اعتماد، سریع و مقیاسپذیر
+ - API پیشرفته برای توسعهدهندگان Web3
+ - پشتیبانی از چندزنجیره
+ - شروع به استفاده به صورت رایگان
+
+- [**NOWNodes**](https://nownodes.io/)
+ - [اسناد](https://documenter.getpostman.com/view/13630829/TVmFkLwy)
+ - ویژگیها
+ - دسترسی به بیش از 50 گره زنجیره بلوکی
+ - کلید API رایگان
+ - جستجوگرهای بلوک
+ - زمان پاسخ API ⩽ 1 ثانیه
+ - تیم پشتیبانی شبانهروزی در تمام ایام هفته
+ - مدیر حسابهای شخصی
+ - گرههای مشترک، بایگانیشده، پشتیبانی و اختصاصی
+
+- [**شبکهی Pocket**](https://www.pokt.network/)
+ - [اسناد](https://docs.pokt.network/home/)
+ - ویژگیها
+ - پروتکل و بازار RPC غیرمتمرکز
+ - 1 میلیون درخواست در روز در سطح رایگان (به ازای هر نقطهی پایانی، حداکثر 2)
+ - [نقاط پایانی عمومی](https://docs.pokt.network/developers/public-endpoints)
+ - برنامهی +Pre-Stake (در صورت نیاز به بیش از 1 میلیون درخواست در روز)
+ - پشتیبانی از بیش از 15 زنجیرهی بلوکی
+ - بیش از 6400 گره که برای خدمترسانی به برنامههای کاربردی POKT کسب میکنند
+ - گرهی بایگانیشده، گرهی بایگانیشده با ردیابی و پشتیبانی از گرهی شبکهی تست
+ - تنوع در کلاینت گره شبکهی اصلی اتریوم
+ - هیچ نقطهی شکستی وجود ندارد
+ - زمان خاموشی صفر
+ - اقتصاد توکنی نزدیک به صفر و مقرونبهصرفه (برای پهنای باند شبکه، یک بار POKT را سهامگذاری کنید)
+ - بدون هزینههای ماهانه، زیرساختهای خود را به یک دارایی تبدیل کنید
+ - تعادل بار در پروتکل تعبیه شده است
+ - تعداد درخواستها در روز و تعداد گرهها را در هر ساعت بهطور بینهایت مقیاسپذیر کنید
+ - خصوصیترین و مقاومترین گزینه در برابر سانسور
+ - پشتیبانی عملی از توسعهدهندگان
+ - داشبورد و تجزیه و تحلیل [پورتال Pocket](https://bit.ly/ETHorg_POKTportal)
+
+- [**QuickNode**](https://www.quicknode.com)
+ - [اسناد](https://www.quicknode.com/docs/)
+ - ویژگیها
+ - پشتیبانی فنی شبانهروزی در تمام ایام هفته و جامعه توسعهدهندگان در Discord
+ - شبکهای دارای تعادل جغرافیایی، چند ابری/فلزی، با تأخیر کم
+ - پشتیبانی چند زنجیرهای (Optimism، Arbitrum، Polygon + 11 مورد دیگر)
+ - لایههای میانی برای سرعت و پایداری (مسیریابی تماس، حافظهی پنهان، نمایهسازی)
+ - نظارت بر قرارداد هوشمند از طریق Webhooks
+ - داشبورد بصری، بستهی تجزیه و تحلیل، نویسندهی RPC
+ - ویژگیهای امنیتی پیشرفته (JWY، ماسک کردن، قرار دادن در فهرست سفید)
+ - API دادهها و تجزیه و تحلیل NFT
+ - [دارای گواهینامه SOC2](https://www.quicknode.com/security)
+ - مناسب برای اشخاص مختلف، از توسعهدهندگان گرفته تا سازمانها
+
+- [**Rivet**](https://rivet.cloud/)
+ - [اسناد](https://rivet.readthedocs.io/en/latest/)
+ - ویژگیها
+ - گزینه ردیف رایگان
+ - مقیاسپذیری دلخواه
+
+- [**SenseiNode**](https://senseinode.com)
+ - [اسناد](https://docs.senseinode.com/)
+ - ویژگیها
+ - گرههای اختصاصی و اشتراکی
+ - داشبورد
+ - میزبانی خاموش AWS در چندین ارائه دهنده میزبانی در مکان های مختلف در آمریکای لاتین
+ - کلاینتهای Prysm و Lighthouse
+
+- [**SettleMint**](https://console.settlemint.com/)
+ - [اسناد](https://docs.settlemint.com/)
+ - ویژگیها
+ - دورهی آزمایشی رایگان
+ - مقیاسپذیری دلخواه
+ - پشتیبانی از GraphQL
+ - نقاط پایانی RPC و WSS
+ - گرههای کامل اختصاصی
+ - اتصال به سرویسهای ابری خود
+ - ابزارهای تحلیل
+ - داشبورد
+ - هزینهی ساعتی
+ - پشتیبانی مستقیم
+
+- [**Tenderly**](https://tenderly.co/web3-gateway)
+ - [اسناد](https://docs.tenderly.co/web3-gateway/web3-gateway)
+ - ویژگیها
+ - بخش رایگان شامل 25 میلیون واحد مناقصه در ماه
+ - دسترسی رایگان به دادههای تاریخی
+ - خوانایی بخشهای سنگین تا 8 برابر سریعتر
+ - دسترسی به خواندن 100٪ ثابت
+ - نقاط پایانی JSON-RPC
+ - سازنده درخواست RPC و پیش نمایش درخواست مبتنی بر رابط کاربری
+ - کاملاً با ابزارهای توسعه، اشکالزدایی یا دیباگ کردن و تست تندرلی یکپارچه شده است
+ - شبیهسازی تراکنشها
+ - تجزیه و تحلیل و فیلتر کردن استفاده
+ - دسترسی آسان به مدیریت کلید
+ - پشتیبانی مهندسی اختصاصی از طریق چت، ایمیل و دیسکورد
+
+- [**توکن ویو**](https://services.tokenview.io/)
+ - [اسناد](https://services.tokenview.io/docs?type=nodeService)
+ - ویژگیها
+ - پشتیبانی فنی شبانهروزی در تمام ایام هفته & و جامعه توسعهدهندگان در Telegram
+ - پشتیبانی از چند زنجیره (بیت کوین، اتریوم، ترون، زنجیره هوشمند بایننس، اتریوم کلاسیک)
+ - هر دو نقطه پایانی RPC و WSS برای استفاده باز هستند
+ - دسترسی نامحدود به داده های آرشیو API
+ - داشبورد با Request Explorer و Mempool Watcher
+ - ایپیآی دیتا انافتی (NFT data API) و Webhook اطلاع رسانی میکنند
+ - پرداخت با رمزارز
+ - پشتیبانی خارجی برای الزامات رفتاری اضافی
+
+- [**Watchdata**](https://watchdata.io/)
+ - [اسناد](https://docs.watchdata.io/)
+ - ویژگیها
+ - اطمینانپذیری دادهها
+ - اتصال بدون وقفه بدون توقف
+ - خودکارسازی فرایند
+ - تعرفههای رایگان
+ - سقف بالا برای امکانات گوناگون که برای هر کاربری مناسب است
+ - پشتیبانی از گرههای مختلف
+ - مقیاسپذیری منابع
+ - سرعت پردازش بالا
+
+- [**ZMOK**](https://zmok.io/)
+ - [اسناد](https://docs.zmok.io/)
+ - ویژگیها
+ - پیشدستی بهعنوان سرویس
+ - استخر حافظهی معاملات جهانی با روشهای جستجو/فیلتر
+ - هزینهی TX نامحدود و گاز بینهایت برای ارسال تراکنشها
+ - دریافت بلوک جدید و خواندن زنجیرهی بلوکی به سریعترین شکل ممکن
+ - تضمین بهترین قیمت برای هر فراخوانی API
+
+- [**Zeeve**](https://www.zeeve.io/)
+ - [اسناد](https://www.zeeve.io/docs/)
+ - ویژگیها
+ - پلتفرم اتوماسیون بدون کد درجه سازمانی که استقرار، نظارت و مدیریت گره ها و شبکه های بلاکچین را ارائه می دهد
+ - بیش از 30 پروتکل پشتیبانی شده & یکپارچهسازی، و افزودن موارد دیگر
+ - خدمات زیرساخت Web3 با ارزش افزوده مانند ذخیرهسازی غیرمتمرکز، هویت غیرمتمرکز و APIهای داده دفتر کل بلاکچین برای موارد استفاده در دنیای واقعی
+ - پشتیبانی 24 ساعته و نظارت فعال، سلامت گره ها را همیشه تضمین می کند.
+ - نقاط پایانی RPC اقدام به ارائه دسترسی تأیید شده به API ها، مدیریت بدون دردسر با داشبورد و تجزیه و تحلیل بصری میکنند.
+ - هم سرویس ابری مدیریت شده را ارائه می دهد و هم گزینه های ابری خود را برای انتخاب می آورد و از همه ارائه دهندگان ابر اصلی مانند AWS و Azure و Google Cloud و Digital Ocean و سرویس محلی پشتیبانی میکند.
+ - ما هر بار از مسیریابی هوشمند برای رسیدن به نزدیکترین گره به کاربر شما استفاده می کنیم
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [فهرست خدمات گرهی اتریوم](https://ethereumnodes.com/)
+
+## موضوعات مرتبط {#related-topics}
+
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+
+## آموزشهای مرتبط {#related-tutorials}
+
+- [شروع توسعهی اتریوم با استفاده از Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/)
+- [راهنمای ارسال تراکنشها با استفاده از web3 و Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
new file mode 100644
index 00000000000..f01d54b0da4
--- /dev/null
+++ "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
@@ -0,0 +1,480 @@
+---
+title: چرخاندن گرهی اتریوم خودتان
+description: مقدمهای عمومی بر اجرای نمونهی خودتان از کلاینت اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+اجرای گرهی خودتان مزایای متنوعی برای شما دارد، امکانات جدیدی را در اختیارتان قرار میدهد و به پشتیبانی از اکوسیستم کمک میکند. این صفحه شما را برای چرخاندن گرهی خودتان و ایفای نقش برای اعتبارسنجی تراکنشهای اتریوم راهنمایی میکند.
+
+توجه داشته باشید که پس از [ادغام](/roadmap/merge)، دو کلاینت برای اجرای یک گره اتریوم مورد نیاز است. یک کلاینت **لایه اجرا (EL)** و یک سرویس گیرنده **لایه اجماع (CL)**. این صفحه، نحوه نصب، پیکربندی و اتصال این دو کلاینت برای اجرای یک گره اتریوم را نشان می دهد.
+
+## پیشنیازها {#prerequisites}
+
+شما باید بدانید که گرهی اتریوم چیست و چرا ممکن است بخواهید یک کلاینت را اجرا کنید. این موضوع در [گرهها و کلاینتها](/developers/docs/nodes-and-clients/) بررسی شده است.
+
+اگر موضوع اجرای یک گره برایتان تازه است یا به دنبال راهی هستید که کمتر فنی باشد، توصیه میکنیم ابتدا به مقدمهی کاربرپسند ما دربارهی [اجرای یک گرهی اتریوم](/run-a-node) نگاهی بیاندازید.
+
+## انتخاب یک رویکرد {#choosing-approach}
+
+اولین گام برای چرخاندن گرهی خودتان، انتخاب رویکردتان است. بر اساس الزامات و احتمالات مختلف، شما باید پیاده سازی کلاینت (هم از کلاینتهای اجرا و هم اجماع)، محیط (سخت افزار، سیستم) و پارامترهای تنظیمات کلاینت را انتخاب کنید.
+
+این صفحه شما را از طریق این تصمیمات راهنمایی می کند و به شما کمک می کند تا مناسب ترین راه را برای اجرای نمونه اتریوم خود پیدا کنید.
+
+برای انتخاب از بین پیادهسازیهای کلاینت، همه [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients)، [کلاینتهای اجماع](/developers/docs/nodes-and-clients/#consensus-clients) آماده در شبکه اصلی را ببینید و درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity) اطلاعات کسب کنید.
+
+با در نظر گرفتن [نیازهای](#requirements) کلاینتها، تصمیم بگیرید که آیا نرم افزار را روی [سخت افزار خود یا در فضای ابری](#local-vs-cloud) اجرا کنید.
+
+پس از آمادهسازی محیط، کلاینت های انتخابی را با [رابط مناسب برای مبتدیان](#automatized-setup) یا [به صورت دستی](#manual-setup) با استفاده از ترمینال با گزینه های پیشرفته نصب کنید.
+
+هنگامی که گره در حال اجرا و همگام سازی است، شما آماده [استفاده از آن](#using-the-node) هستید، اما مطمئن شوید که مراقب [نگهداری](#operating-the-node) آن هستید.
+
+![نصب کلاینت](./diagram.png)
+
+### محیط زیست و سختافزار {#environment-and-hardware}
+
+#### محلی یا ابری {#local-vs-cloud}
+
+کلاینتهای اتریوم میتوانند روی رایانههای درجه مصرفکننده کار کنند و به سختافزار خاصی مانند ماشینهای استخراج نیاز ندارند. بنابراین، شما گزینه های مختلفی برای استقرار گره بر اساس نیاز خود دارید. برای سادهسازی، بیایید اجرای یک گره را هم در یک ماشین فیزیکی محلی و هم در یک سرور ابری بررسی کنیم:
+
+- ابر
+ - ارائهدهندگانْ زمان بهکار (uptime) سرور بالا و آدرسهای آیپی (IP) عمومی ثابت ارائه میدهند
+ - گرفتن سرور اختصاصی یا مجازی ممکن است راحتتر از ساختن سرور شخصی باشد
+ - بدهبستان بر سر این است که به یک شخص ثالث - ارائهدهدهی سرور اعتماد کنیم
+ - به دلیل اندازهی حافظهی لازم برای گرهی کامل، هزینهی اجارهی سرور ممکن است بالا باشد
+- سختافزار شخصی
+ - رویکرد بیاعتمادتر و حاکمیتیتر
+ - سرمایهگذاری برای یک بار
+ - امکان خرید ماشینهای پیشپیکربندیشده
+ - شما باید بهطور فیزیکی دستگاه و شبکه را آماده، نگهداری و احتمالاً عیبیابی کنید
+
+هر دو گزینه مزایای متفاوتی دارند که در بالا خلاصه شده است. اگر به دنبال راهحل ابری هستید، علاوه بر بسیاری از ارائهدهندگان سنتی پردازش ابری، سرویسهایی هم وجود دارند که بر روی بهکارگیری گرهها تمرکز دارند. برای گزینه های بیشتر در مورد گره های میزبان، [گره ها را به عنوان یک سرویس](/developers/docs/nodes-and-clients/nodes-as-a-service/) بررسی کنید.
+
+#### سختافزار {#hardware}
+
+با این حال، یک شبکهی غیرمتمرکز و مقاوم در برابر سانسور نباید بر ارائهدهندگان ابری متکی باشد. در عوض، اجرای گره تان بر روی سختافزار محلی خودتان برای اکوسیستم سالم تر است. [تخمینها](https://www.ethernodes.org/networkType/Hosting) سهم بزرگی از گرههای اجرا شده روی ابر را نشان میدهد که میتواند به یک نقطه شکست تبدیل شود.
+
+کلاینت های اتریوم می توانند بر روی کامپیوتر، لپ تاپ، سرور یا حتی یک کامپیوتر تک برد شما اجرا شوند. در حالی که اجرای کلاینت ها بر روی رایانه شخصی شما امکانپذیر است، داشتن یک ماشین اختصاصی فقط برای گره می تواند عملکرد و امنیت آن را به میزان قابل توجهی افزایش دهد و در عین حال تأثیر آن را بر روی رایانه اصلی شما به حداقل برساند.
+
+استفاده از سخت افزار خودتان می تواند بسیار آسان باشد. بسیاری از گزینه های ساده و همچنین تنظیمات پیشرفته برای افراد فنی بیشتر وجود دارد. بنابراین بیایید به الزامات و ابزارهای اجرای کلاینت های اتریوم بر روی دستگاه شما نگاه کنیم.
+
+#### الزامات {#requirements}
+
+نیازهای سختافزاری برای هر کلاینت متفاوت است، اما معمولاً آنقدر زیاد نیست، چون گره فقط باید همگام بماند. آن را با استخراج که به قدرت محاسباتی بسیار بیشتری نیاز دارد، اشتباه نگیرید. با این حال، سختافزار قدرتمندتر زمان همگامسازی و عملکرد را بهبود میبخشد.
+
+پیش از نصب هر کلاینتی مطمئن شوید که رایانهی شما منابع لازم را برای اجرای آن دارد. در زیر می توانید الزامات حداقل و توصیه شده را بیابید.
+
+گلوگاه سخت افزار شما بیشتر فضای دیسک است. همگام سازی بلاکچین اتریوم بسیار فشرده ورودی/خروجی است و به فضای زیادی نیاز دارد. بهتر است یک **حافظه اس اس دی** با صدها گیگابایت فضای خالی حتی پس از همگام سازی داشته باشید.
+
+اندازه پایگاه داده و سرعت همگام سازی اولیه به مشتری انتخابی، پیکربندی و [استراتژی همگام سازی](/developers/docs/nodes-and-clients/#sync-modes) بستگی دارد.
+
+همچنین مطمئن شوید که اتصال اینترنت شما دارای [محدودیت پهنای باند](https://wikipedia.org/wiki/Data_cap) نباشد. توصیه میشود از یک اتصال نامحدود به اینترنت استفاده کنید، چون حجم پهنای لازم برای همگامسازی اولیه و پخش دادهها در شبکه ممکن است از محدودیت حجمی پهنای باند شما بیشتر باشد.
+
+##### سیستمعامل
+
+همهی کلاینتها از سیستمعاملهای اصلی یعنی لینوکس، مکاواس و ویندوز پشتیبانی میکنند. این بدان معناست که میتوانید گرهها را با سیستمعاملی (OS) که برای شما مناسبتر است، روی رایانههای رومیزی یا سرورهای معمولی اجرا کنید. مطمئن شوید که سیستمعامل شما بهروز است تا از مشکلات احتمالی و آسیبپذیریهای امنیتی جلوگیری شود.
+
+##### الزامات حداقلی
+
+- پردازنده با حداقل 2 هسته
+- 8 گیگ رم
+- 2 ترا SSD
+- پهنای باند حداقل 10 مگابیت بر ثانیه
+
+##### مشخصات پیشنهادی
+
+- پردازندهی سریع با حداقل 4 هسته
+- حداقل 16 گیگابایت رم
+- SSD سریع بالای 2 ترا
+- پهنای باند حداقل 25 مگابیت بر ثانیه
+
+حالت همگامسازی و سرویس گیرندهای که انتخاب میکنید بر فضای مورد نیاز تأثیر میگذارند، اما ما فضای دیسک مورد نیاز برای هر مشتری را در زیر تخمین زدهایم.
+
+| کلاینت | اندازه دیسک (همگام سازی فوری) | فضای حافظه (آرشیو کامل) |
+| ---------- | ----------------------------- | ----------------------- |
+| Besu | 800GB+ | 12TB+ |
+| Erigon | شامل نمیشود | 2.5TB+ |
+| Geth | 500GB+ | 12TB+ |
+| Nethermind | 500GB+ | 12TB+ |
+| Reth | شامل نمیشود | 2.2TB+ |
+
+- توجه: Erigon و Reth همگامسازی فوری را ارائه نمیدهند، اما هرس کامل امکانپذیر است (حدود 2 ترا برای Erigon و حدود 1.2 ترا برای Reth)
+
+برای کلاینتهای اجماع، فضای مورد نیاز به پیادهسازی کلاینت و ویژگیهای فعال (مثلاً جریمهکننده اعتبارسنج) نیز بستگی دارد، اما معمولاً با 200 گیگابایت دیگر مورد نیاز برای دادههای بیکن محاسبه میشود. با تعداد زیادی اعتبارسنج، بار پهنای باند نیز افزایش می یابد. میتوانید [جزئیات مربوط به الزامات کلاینت اجماع را در این تحلیل بیابید](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc).
+
+#### راهکارهای عملی {#plug-and-play}
+
+سادهترین گزینه برای اجرای یک گره با سختافزار خود استفاده از جعبه های راهاندازی آسان است. دستگاههای از پیش تنظیم شده توسط فروشندگان سادهترین تجربه را ارائه می دهند: سفارش، اتصال، اجرا. همه چیز از قبل پیکربندی شده است و به طور خودکار با یک راهنمای بصری و داشبورد برای نظارت و کنترل نرمافزار اجرا می شود.
+
+- [DappNode](https://dappnode.io/)
+- [Avado](https://ava.do/)
+
+#### اتریوم روی رایانهی تکبرد {#ethereum-on-a-single-board-computer}
+
+یک راه آسان و ارزان برای اجرای یک گره اتریوم، استفاده از کامپیوتر تک بردی است، حتی با معماری ARM مانند Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) تصاویری با قابلیت اجرا و اجرای چندگانه مشتری را برای رزبری پای و دیگر بردهای ARM فراهم میکند.
+
+دستگاه های کوچک، مقرون به صرفه و کارآمد مانند این ها برای اجرای یک گره در خانه ایده آل هستند، اما عملکرد محدود آنها را در نظر داشته باشید.
+
+## چرخاندن گره {#spinning-up-node}
+
+راهاندازی واقعی کلاینت را میتوان با راهاندازهای خودکار یا به صورت دستی انجام داد و مستقیماً نرمافزار کلاینت را راهاندازی کرد.
+
+برای کاربران نا آشناتر، رویکرد پیشنهادی استفاده از یک لانچر است، نرمافزاری که شما را در نصب راهنمایی میکند و فرآیند راهاندازی کلاینت را خودکار میکند. با این حال، اگر تجربه استفاده از ترمینال را دارید، مراحل تنظیم دستی باید ساده باشد.
+
+### نصب با راهنما {#automatized-setup}
+
+چندین پروژه کاربرپسند قصد بهبود تجربه راهاندازی یک کلاینت را دارند. این لانچرها نصب و پیکربندی خودکار کلاینت را ارائه میکنند و برخی حتی یک رابط گرافیکی برای راهاندازی و نظارت بر کلاینتها ارائه میدهند.
+
+در زیر چند پروژه وجود دارد که می تواند به شما در نصب و کنترل کلاینت ها فقط با چند کلیک کمک کند:
+
+- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - که همراه دستگاه خریداری شده از یک فروشنده ارائه نمی شود. این نرمافزار، راهانداز گره واقعی و مرکز کنترل با ویژگی های بسیار می توانند بر روی سختافزار دلخواه استفاده شوند.
+- [eth-docker](https://eth-docker.net/) - راهاندازی خودکار با استفاده از داکر با تمرکز بر روی استقرار آسان و ایمن، نیاز به دانش پایه و ترمینال داکر دارد که برای کاربران کمی پیشرفتهتر توصیه میشود.
+- [Stereum](https://stereum.net/ethereum-node-setup/) - یک لانچر برای نصب کلاینتها روی سرور راه دور از طریق اتصال SSH با راهنمای راهاندازی رابط کاربری گرافیکی، مرکز کنترل، و بسیاری از ویژگیهای دیگر.
+- [NiceNode](https://www.nicenode.xyz/) - یک لانچر با تجربه کاربری ساده برای اجرای یک گره در رایانه شما. فقط کلاینتها را انتخاب کنید و آنها را با چند کلیک شروع کنید. همچنان تحت توسعه است.
+- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - ابزار تنظیم گره که به طور خودکار یک پیکربندی داکر را با استفاده از ویزارد CLI ایجاد می کند. توسط Nethermind با زبان Go نوشته شده.
+
+### راهنماب دستی نصب کلاینت {#manual-setup}
+
+گزینه دیگر، دانلود، تأیید و پیکربندی نرمافزار کلاینت به صورت دستی است. حتی اگر برخی از کلاینتها یک رابط گرافیکی ارائه دهند، راهاندازی دستی همچنان به مهارت های اولیه با ترمینال نیاز دارد اما تطبیق پذیری بسیار بیشتری را ارائه می دهد.
+
+همانطور که قبلا توضیح داده شد، راهاندازی گره اتریوم خود مستلزم اجرای یک جفت کلاینت اجماع و اجرا است. برخی از کلاینتها ممکن است شامل یک کلاینت سبک از نوع دیگر باشند و بدون نیاز به نرمافزار دیگری همگام شوند. با این حال، تأیید کامل بدون نیاز به شخص ثالث نیاز به هر دو پیادهسازی دارد.
+
+#### دریافت نرمافزار کلاینت {#getting-the-client}
+
+ابتدا، باید نرمافزار [کلاینت اجرا](/developers/docs/nodes-and-clients/#execution-clients) و [کلاینت اجماع](/developers/docs/nodes-and-clients/#consensus-clients) دلخواه خود را بدست آورید.
+
+شما به سادگی می توانید یک برنامه اجرایی یا بسته نصبی را دانلود کنید که مناسب سیستم عامل و معماری شما باشد. همیشه امضاها و checksumهای بسته های دانلود شده را بررسی کنید. برخی از مشتریان همچنین مخازن یا تصاویر داکر را برای نصب و به روز رسانی آسان تر ارائه می دهند. همه کلاینت ها منبع باز هستند، بنابراین می توانید آنها را از سمت منبع نیز بسازید. این روش پیشرفتهتر است، اما در برخی موارد ممکن است نیاز باشد.
+
+دستورالعملهای نصب هر کلاینت در اسنادی که در فهرست کلاینتهای فوقالذکر پیوند داده شدهاند، ارائه شده است.
+
+در اینجا صفحات انتشار کلاینت ها وجود دارد که می توانید باینری های از پیش ساخته شده آنها یا دستورالعمل های نصب را پیدا کنید:
+
+##### کلاینتهای اجرا
+
+- [Besu](https://github.com/hyperledger/besu/releases)
+- [Erigon](https://github.com/ledgerwatch/erigon/releases)
+- [Geth](https://geth.ethereum.org/downloads/)
+- [Nethermind](https://downloads.nethermind.io/)
+- [Reth](https://reth.rs/installation/installation.html)
+
+همچنین شایان ذکر است که تنوع کلاینتها یک [مسئله در لایه اجرا](/developers/docs/nodes-and-clients/client-diversity/#execution-layer) است. توصیه می شود که خوانندگان به اجرای یک نسخه حداقلی از کلاینت اجرا فکر کنند.
+
+##### کلاینتهای اجماع
+
+- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest)
+- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (یک باینری از پیش ساخته شده ارائه نمی دهد، فقط یک تصویر داکر یا باید از منبع ساخته شود)
+- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest)
+- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest)
+- [Teku](https://github.com/ConsenSys/teku/releases)
+
+[تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) برای گره های اجماع که اعتبارسنج را اجرا می کنند بسیار مهم است. اگر اکثر اعتبارسنجها پیادهسازی یک کلاینت واحد را اجرا کنند، امنیت شبکه در خطر است. بنابراین توصیه می شود که یک کلاینت اقلیتی را در نظر بگیرید.
+
+[آخرین استفاده از کلاینت شبکه را ببینید](https://clientdiversity.org/) و درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity) بیشتر بدانید.
+
+##### تایید نرم افزار
+
+هنگام دانلود نرمافزار از اینترنت، توصیه می شود بینقص بودن آن را بررسی کنید. این مرحله اختیاری است، اما به خصوص در مورد زیرساخت های حیاتی مانند مشتری اتریوم، مهم است که از بردارهای حمله احتمالی آگاه باشید و از آنها اجتناب کنید. اگر یک باینری از پیش ساخته شده دانلود کرده اید، باید به آن اعتماد کنید و خطر این را در نظر بگیرید که مهاجم ممکن است بتواند فایل اجرایی را با یک فایل مخرب تعویض کند.
+
+توسعه دهندگان، باینری های منتشر شده را با کلیدهای PGP خود امضا می کنند تا بتوانید به صورت رمزنگاری تأیید کنید که دقیقاً نرم افزاری را که ایجاد کرده اند اجرا می کنید. شما فقط باید کلیدهای عمومی مورد استفاده توسعه دهندگان را به دست آورید که می توانند در صفحات انتشار کلاینت یا در اسناد یافت شوند. پس از دانلود نسخه کلاینت و امضای آن، می توانید از پیادهسازی PGP استفاده کنید، به عنوان مثال [GnuPG](https://gnupg.org/download/index.html) تا به راحتی آنها را تأیید کنید. آموزش تأیید نرمافزار منبع باز با استفاده از `gpg` در [لینوکس](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) یا [ویندوز/مک](https://freedom.press/training/verifying-open-source-software/) را بررسی کنید.
+
+شکل دیگر تأیید این است که مطمئن شوید هش، اثر انگشت رمزنگاری منحصربهفرد، نرمافزاری که دانلود کردهاید با آنچه توسعهدهندگان ارائه کردهاند مطابقت دارد. این حتی ساده تر از استفاده از PGP است و برخی از کلاینتها فقط این گزینه را ارائه می دهند. فقط تابع هش را روی نرمافزار دانلود شده اجرا کنید و آن را با یکی از صفحه انتشار مقایسه کنید. برای مثال:
+
+```sh
+sha256sum teku-22.6.1.tar.gz
+
+9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde
+```
+
+#### نصب کلاینت {#client-setup}
+
+پس از نصب، دانلود یا کامپایل نرمافزار کلاینت، آماده اجرای آن هستید. این فقط به این معنی است که باید با پیکربندی مناسب اجرا شود. کلاینتها گزینه های پیکربندی خوبی را ارائه می دهند که میتوانند ویژگی های مختلفی را فعال کنند.
+
+بیایید با گزینه هایی شروع کنیم که می توانند به طور قابل توجهی بر عملکرد کلاینت و استفاده از داده تأثیر بگذارند. [حالتهای همگامسازی](/developers/docs/nodes-and-clients/#sync-modes) روشهای مختلف بارگیری و اعتبارسنجی دادههای زنجیرهی بلوکی را نشان میدهند. پیش از آغاز گره، باید تصمیم بگیرید که از کدام شبکه و کدام حالت همگامسازی استفاده نمایید. مهمترین چیزهایی که باید در نظر بگیرید فضای دیسک و زمان همگام سازی مورد نیاز کلاینت است. برای تعیین اینکه کدام حالت همگام سازی پیش فرض است، به اسناد کلاینت توجه کنید. اگر برای شما مناسب نیست، یکی دیگر را بر اساس سطح امنیت، داده های موجود و هزینه انتخاب کنید. به غیر از الگوریتم همگامسازی، میتوانید هرس (pruning) انواع مختلف دادههای قدیمی را نیز تنظیم کنید. هرس امکان حذف دادههای قدیمی را فراهم میکند، بهعنوان مثال حذف گرههای درخت وضعیت که از بلوکهای اخیر غیرقابلدسترسی هستند.
+
+سایر گزینه های پیکربندی اولیه عبارتند از، به عنوان مثال. انتخاب یک شبکه - شبکه اصلی یا شبکههای آزمایشی، فعال کردن نقطه پایانی HTTP برای RPC یا WebSockets و غیره. شما می توانید تمام ویژگی ها و گزینه ها را در اسناد کلاینت بیابید. پیکربندی های مختلف کلاینت را می توان با اجرای کلاینت با پرچم های مربوطه به طور مستقیم در فایل CLI یا پیکربندی تنظیم کرد. هر کلاینت کمی متفاوت است. لطفاً برای جزئیات بیشتر در مورد گزینه های پیکربندی، همیشه به اسناد رسمی یا صفحه راهنمای آن مراجعه کنید.
+
+برای اهداف آزمایشی، ممکن است ترجیح دهید یک کلاینت را در یکی از شبکه های تست نت اجرا کنید. [مشخصات کلی شبکههای پشتیبانیشده را مشاهده کنید](/developers/docs/nodes-and-clients/#execution-clients).
+
+نمونه هایی از اجرای کلاینت های اجرایی با پیکربندی اولیه را می توان در بخش بعدی یافت.
+
+#### آغاز بهکار کلاینت اجرا {#starting-the-execution-client}
+
+قبل از راهاندازی نرمافزار کلاینت اتریوم، آخرین بررسی را انجام دهید که آیا محیط شما آماده است. برای مثال، مطمئن شوید که:
+
+- فضای دیسک کافی با توجه به شبکه انتخابی و حالت همگام سازی وجود دارد.
+- حافظه و پردازنده توسط برنامههای دیگر استفاده نمیشود.
+- سیستم عامل به آخرین نسخه آپدیت شده است.
+- سیستم زمان و تاریخ صحیح را دارد.
+- روتر و فایروال شما اتصالات را در پورتهای شنونده (listening ports) میپذیرند. به طور پیشفرض کلاینتهای اتریوم از یک پورت شنونده (TCP) و یک پورت یابنده (UDP) که هر دو بهطور پیشفرض روی 30303 هستند استفاده میکنند.
+
+کلاینت خود را ابتدا روی شبکهی تست اجرا کنید تا مطمئن شوید که همهچیز بهدرستی کار میکند.
+
+شما باید هرگونه تنظیمات کلاینت که به صورت پیشفرض وجود ندارند را در ابتدا مشخص کنید. میتوانید از پرچمها و فایلهای پیکربندی برای مشخص کردن پیکربندی موردنظر استفاده کنید. مجموعه ای از ویژگی ها و نحو پیکربندی هر کلاینت متفاوت است. برای جزئیات، اسناد کلاینت خود را بررسی کنید.
+
+کلاینتهای اجرا و اجماع از طریق یک نقطه پایانی تأیید شده مشخص شده در [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine) ارتباط برقرار می کنند. برای اتصال به یک کلاینت اجماع، کلاینت اجرا باید یک [`jwtsecret`](https://jwt.io/) در یک مسیر شناخته شده ایجاد کند. به دلایل امنیتی و پایداری، کلاینتها باید روی یک ماشین اجرا شوند و هر دو کلاینت باید این مسیر را بدانند زیرا برای تأیید اعتبار یک اتصال RPC محلی بین آنها استفاده میشود. کلاینت اجرا همچنین باید یک پورت شنونده (listening port) برای APIهای تایید شده تعریف کند.
+
+این نشانه به طور خودکار توسط نرمافزار کلاینت تولید می شود، اما در برخی موارد، ممکن است لازم باشد خودتان آن را انجام دهید. میتوانید آن را با [OpenSSL](https://www.openssl.org/)تولید کنید:
+
+```sh
+openssl rand -hex 32 > jwtsecret
+```
+
+#### اجرای یک کلاینت اجرا {#running-an-execution-client}
+
+این بخش شما را از طریق راهاندازی کلاینت های اجرا راهنمایی می کند. این فقط به عنوان نمونه ای از یک پیکربندی اولیه عمل می کند که کلاینت را با این تنظیمات شروع میکند:
+
+- شبکه ای را برای اتصال به شبکه اصلی در مثال های ما مشخص می کند
+ - در عوض میتوانید [یکی از شبکههای آزمایشی](/developers/docs/networks/) را برای آزمایش اولیه تنظیمات خود انتخاب کنید
+- دایرکتوری داده را تعریف می کند، جایی که تمام داده ها از جمله بلاکچین در آن ذخیره می شود
+ - مطمئن شوید که مسیر را با یک مسیر واقعی جایگزین کنید، به عنوان مثال به درایو خارجی شما اشاره می کند
+- رابط ها را برای برقراری ارتباط با کلاینت فعال می کند
+ - از جمله JSON-RPC و Engine API برای ارتباط با کلاینت اجماع
+- مسیر `jwtsecret` را برای API احراز هویت شده تعریف می کند
+ - مطمئن شوید که مسیر مثال را با یک مسیر واقعی جایگزین کنید که برای کلاینتها قابل دسترسی باشد، مثلاً `/tmp/jwtsecret`
+
+لطفاً به خاطر داشته باشید که این فقط یک مثال اولیه است، تمام تنظیمات دیگر به طور پیش فرض تنظیم می شوند. برای اطلاع از مقادیر، تنظیمات و ویژگیهای پیشفرض، به مستندات هر کلاینت توجه کنید. برای ویژگی های بیشتر، به عنوان مثال برای اجرای اعتبارسنج، نظارت و غیره، لطفاً به مستندات کلاینت خاص مراجعه کنید.
+
+> توجه داشته باشید که جریمههای معکوس `\` در مثال ها فقط برای اهداف قالب بندی هستند. پرچم های پیکربندی را می توان در یک خط تعریف کرد.
+
+##### اجرای Besu
+
+این مثال Besu را در شبکه اصلی شروع میکند، دادههای بلاکچین را در قالب پیشفرض در `/data/ethereum` ذخیره میکند، JSON-RPC و Engine RPC را برای اتصال کلاینت اجماع فعال میکند. Engine API با نشانه `jwtsecret` احراز هویت می شود و فقط تماس از `localhost` مجاز است.
+
+```sh
+besu --network=mainnet \
+ --data-path=/data/ethereum \
+ --rpc-http-enabled=true \
+ --engine-rpc-enabled=true \
+ --engine-host-allowlist="*" \
+ --engine-jwt-enabled=true \
+ --engine-jwt-secret=/path/to/jwtsecret
+```
+
+Besu همچنین دارای یک گزینه لانچر است که یک سری سوالات را می پرسد و فایل پیکربندی را ایجاد می کند. لانچر تعاملی را با استفاده از موارد زیر اجرا کنید:
+
+```sh
+besu --Xlauncher
+```
+
+[اسناد Besu](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) حاوی گزینههای اضافی و جزئیات پیکربندی است.
+
+##### اجرای Erigon
+
+این مثال Erigon را در شبکه اصلی شروع میکند، دادههای بلاکچین را در `/data/ethereum` ذخیره میکند، JSON-RPC را فعال میکند،تعیین می کند که چه فضاهای نامی مجاز است و احراز هویت را برای اتصال کلاینت اجماع که توسط مسیر `jwtsecret` تعریف می شود، فعال می کند.
+
+```sh
+erigon --chain mainnet \
+ --datadir /data/ethereum \
+ --http --http.api=engine,eth,web3,net \
+ --authrpc.jwtsecret=/path/to/jwtsecret
+```
+
+Erigon به طور پیش فرض یک همگام سازی کامل را با 8 گیگابایت هارد دیسک انجام می دهد که منجر به بیش از 2 ترابایت داده آرشیو می شود. مطمئن شوید که `datadir` به دیسک با فضای خالی کافی اشاره می کند یا به پرچم `--prune` نگاه کنید که می تواند انواع مختلف داده را هرس کند. برای کسب اطلاعات بیشتر، `--help` مربوط به Erigon را بررسی کنید.
+
+##### اجرای Geth
+
+این مثال Geth را در شبکه اصلی شروع میکند، دادههای بلاکچین را در `/data/ethereum` ذخیره میکند، JSON-RPC را فعال میکند و مشخص میکند که کدام فضاهای نام مجاز هستند. همچنین احراز هویت را برای اتصال کلاینت اجماع فعال می کند که به مسیر `jwtsecret` نیاز دارد و همچنین گزینه ای را که در مثال ما فقط از `localhost` مجاز است، تعیین می کند.
+
+```sh
+geth --mainnet \
+ --datadir "/data/ethereum" \
+ --http --authrpc.addr localhost \
+ --authrpc.vhosts="localhost" \
+ --authrpc.port 8551
+ --authrpc.jwtsecret=/path/to/jwtsecret
+```
+
+[اسناد برای همه گزینههای پیکربندی](https://geth.ethereum.org/docs/fundamentals/command-line-options) را بررسی کنید و درباره [اجرای Geth با یک کلاینت اجماع](https://geth.ethereum.org/docs/getting-started/consensus-clients) بیشتر بدانید.
+
+##### اجرای Nethermind
+
+Nethermind [گزینه های نصب](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) مختلفی را ارائه می دهد. این بسته با باینریهای مختلف، از جمله یک لانچر با راهاندازی هدایتشده ارائه میشود که به شما در ایجاد پیکربندی به صورت تعاملی کمک میکند. از طرف دیگر، Runner را پیدا میکنید که خود فایل اجرایی است و فقط میتوانید آن را با پرچمهای پیکربندی اجرا کنید. JSON-RPC بهصورت پیشفرض فعال است.
+
+```sh
+Nethermind.Runner --config mainnet \
+ --datadir /data/ethereum \
+ --JsonRpc.JwtSecretFile=/path/to/jwtsecret
+```
+
+اسناد Nethermind یک [راهنمای کامل](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) در مورد اجرای Nethermind با کلاینت اجماع ارائه می دهد.
+
+یک کلاینت اجرا، توابع اصلی، نقاط پایانی انتخابی خود را آغاز می کند و شروع به جستجوی همتا می کند. پس از یافتن موفق همتایان، کلاینت شروع به همگامسازی میکند. کلاینت اجرا منتظر اتصال از سمت کلاینت اجماع خواهد بود. دادههای کنونی زنجیرهی بلوکی زمانی آماده خواهد بود که کلاینت بهطور موفقیتآمیز با وضعیت فعلی همگامسازی کرده باشد.
+
+##### اجرای Reth
+
+این مثال با استفاده از موقعیت مکانی داده پیش فرض، Reth را در شبکه اصلی شروع می کند. احراز هویت JSON-RPC و Engine RPC را برای اتصال کلاینت اجماع که توسط مسیر `jwtsecret` تعریف شده است، فعال می کند و فقط تماس از `localhost` مجاز است.
+
+```sh
+reth node \
+ --authrpc.jwtsecret /path/to/jwtsecret \
+ --authrpc.addr 127.0.0.1 \
+ --authrpc.port 8551
+```
+
+برای اطلاعات بیشتر در مورد دایرکتوری های داده پیش فرض داده، به [پیکربندی Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) مراجعه کنید. [اسناد Reth](https://reth.rs/run/mainnet.html) حاوی گزینههای اضافی و جزئیات پیکربندی است.
+
+#### آغاز بهکار کلاینت اجماع {#starting-the-consensus-client}
+
+کلاینت اجماع باید با پیکربندی پورت مناسب شروع شود تا یک اتصال RPC محلی به کلاینت اجرا برقرار شود. کلاینت های اجماع باید با پورت کلاینت اجرای در معرض، به عنوان آرگومان پیکربندی اجرا شوند.
+
+کلاینت اجماع همچنین به مسیر `jwt-secret` کلاینت اجرا نیاز دارد تا بتواند ارتباط RPC بین آنها را تأیید کند. مشابه مثالهای اجرایی بالا، هر کلاینت اجماع یک پرچم پیکربندی دارد که مسیر فایل توکن jwt را به عنوان آرگومان میگیرد. این مسیر باید با مسیر `jwtsecret` ارائهشده به کلاینت اجرا مطابقت داشته باشد.
+
+اگر قصد دارید یک اعتبارسنج را اجرا کنید، مطمئن شوید که یک پرچم پیکربندی که آدرس اتریوم گیرنده کارمزد را مشخص میکند، اضافه کنید. اینجاست که پاداشهای اتر برای اعتبارسنج شما جمع میشوند. هر کلاینت اجماع یک گزینه دارد، مثلاً `--suggested-fee-recipient=0xabcd1`، که آدرس اتریوم را به عنوان آرگومان می گیرد.
+
+هنگام راهاندازی یک بیکننود در یک شبکه آزمایشی، میتوانید با استفاده از یک نقطه پایانی عمومی برای [همگامسازی نقطه چک](https://notes.ethereum.org/@launchpad/checkpoint-sync) زمان همگامسازی قابل توجهی صرفهجویی کنید.
+
+#### اجرای یک کلاینت اجماع {#running-a-consensus-client}
+
+##### اجرای Lighthouse
+
+قبل از اجرای Lighthouse، در [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html) درباره نحوه نصب و پیکربندی آن بیشتر بیاموزید.
+
+```sh
+lighthouse beacon_node \
+ --network mainnet \
+ --datadir /data/ethereum \
+ --http \
+ --execution-endpoint http://127.0.0.1:8551 \
+ --execution-jwt /path/to/jwtsecret
+```
+
+##### اجرای Lodestar
+
+نرمافزار Lodestar را با کامپایل یا دانلود تصویر داکر نصب کنید. در [اسناد](https://chainsafe.github.io/lodestar/) و جامع تر در [راهنمای راه اندازی](https://hackmd.io/@philknows/rk5cDvKmK) بیشتر بیاموزید.
+
+```sh
+lodestar beacon \
+ --rootDir="/data/ethereum" \
+ --network=mainnet \
+ --eth1.enabled=true \
+ --execution.urls="http://127.0.0.1:8551" \
+ --jwt-secret="/path/to/jwtsecret"
+```
+
+##### اجرای Nimbus
+
+Nimbus هم با اجماع و هم با کلاینت های اجرا عرضه می شود. این می تواند بر روی دستگاه های مختلف حتی با قدرت محاسباتی بسیار کم اجرا شود. پس از [نصب وابستگی ها و خود Nimbus](https://nimbus.guide/quick-start.html)، می توانید کلاینت اجماع آن را اجرا کنید:
+
+```sh
+nimbus_beacon_node \
+ --network=mainnet \
+ --web3-url=http://127.0.0.1:8551 \
+ --rest \
+ --jwt-secret="/path/to/jwtsecret"
+```
+
+##### اجرای Prysm
+
+Prysm همراه با اسکریپت است که امکان نصب خودکار آسان را فراهم می کند. جزئیات را می توان در [اسناد Prysm](https://docs.prylabs.network/docs/install/install-with-script) پیدا کرد.
+
+```sh
+./prysm.sh beacon-chain \
+ --mainnet \
+ --datadir /data/ethereum \
+ --execution-endpoint=http://localhost:8551 \
+ --jwt-secret=/path/to/jwtsecret
+```
+
+##### اجرای Teku
+
+```sh
+teku --network mainnet \
+ --data-path "/data/ethereum" \
+ --ee-endpoint http://localhost:8551 \
+ --ee-jwt-secret-file "/path/to/jwtsecret"
+```
+
+هنگامی که یک کلاینت اجماع برای خواندن قرارداد سپرده و شناسایی اعتبارسنجها به کلاینت اجرا متصل می شود، به سایر همتایان بیکننود نیز متصل می شود و شروع به همگام سازی اسلات های اجماع از زمان پیدایش می کند. هنگامی که Beacon Node به دوره فعلی رسید، Beacon API برای اعتبارسنج شما قابل استفاده می شود. درباره [API های Beacon Node](https://eth2docs.vercel.app/) بیشتر بیاموزید.
+
+### افزودن اعتبارسنجها {#adding-validators}
+
+یک کلاینت اجماع به عنوان یک Beacon Node برای اعتبارسنجها برای اتصال عمل می کند. هر کلاینت اجماع دارای نرمافزار اعتبارسنج مخصوص به خود است که در مستندات مربوطه به تفصیل شرح داده شده است.
+
+اجرای اعتبارسنج خود اجازهی [سهامگذاری انفرادی](/staking/solo/)، موثرترین و بی اعتمادترین روش برای پشتیبانی از شبکه اتریوم را میدهد. بااینحال، نیاز به سپردهگذاری 32 اتر دارد. برای اجرای یک اعتبارسنج بر روی گره خود با مقدار کمتر، ممکن است یک استخر غیرمتمرکز با عملگرهای گره بدون مجوز، مانند [Rocket Pool](https://rocketpool.net/node-operators) مورد علاقه شما باشد.
+
+سادهترین راه برای شروع کار با تولید کلید سهامگذاری و اعتبارسنج، استفاده از [لانچپد سهامگذاری شبکهی تست Holesky](https://holesky.launchpad.ethereum.org/) است که به شما امکان می دهد تنظیمات خود را با [گره های در حال اجرا در Holesky](https://notes.ethereum.org/@launchpad/holesky) آزمایش کنید. وقتی برای شبکهی اصلی آماده شدید، میتوانید این مراحل را با استفاده از [سکوی پرتاب سهامگذاری شبکهی اصلی](https://launchpad.ethereum.org/) تکرار کنید.
+
+برای مروری بر گزینه های سهامگذاری به [صفحه سهامگذاری](/staking) نگاه کنید.
+
+### استفاده کردن از گره {#using-the-node}
+
+کلاینتهای اجرا [نقاط پایانی RPC API](/developers/docs/apis/json-rpc/) را ارائه میکنند که میتوانید از آنها برای ارسال تراکنشها، تعامل با قراردادهای هوشمند یا استقرار آنها در شبکه اتریوم به روشهای مختلف استفاده کنید:
+
+- فراخوانی دستی آنها با یک پروتکل مناسب (مثلاً با استفاده از `curl`)
+- ضمیمه کردن کنسول ارائهشده (مثلاً `geth attach`)
+- پیادهسازی آنها در برنامه های کاربردی با استفاده از کتابخانه های web3، مثلاً [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)، [ethers](https://github.com/ethers-io/ethers.js/)
+
+کلاینتهای مختلف پیادهسازیهای مختلفی برای نقاط پایانی RPC دارند. اما برای JSON-RPC استانداردی وجود دارد که میتوانید برای هر کلاینتی استفاده نمایید. برای مروری اجمالی، [مستندات JSON-RPC را بخوانید](/developers/docs/apis/json-rpc/). برنامههای کاربردی که نیاز به اطلاعات از شبکهی اتریوم دارند میتوانند از RPC استفاده کنند. به عنوان مثال، کیف پول محبوب متامسک به شما امکان می دهد [به نقطه پایانی RPC خود متصل شوید](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) که دارای مزایای امنیتی و حریم خصوصی قوی است.
+
+کلاینتهای اجماع همگی یک [API بیکن](https://ethereum.github.io/beacon-APIs) را در معرض نمایش میگذارند که میتواند با ارسال درخواست با استفاده از ابزارهایی مانند [Curl](https://curl.se) برای بررسی وضعیت کلاینت اجماع یا بارگیری کردن بلوکها و دادههای اجماع استفاده شود. اطلاعات بیشتر در این مورد را میتوان در اسناد مربوط به هر کلاینت اجماع یافت.
+
+#### دستیابی به RPC {#reaching-rpc}
+
+درگاه پیشفرض برای اجرای برنامه JSON-RPC `8545` است اما میتوانید پورتهای نقاط انتهایی محلی را در پیکربندی تغییر دهید. در حالت پیشفرض، رابط RPC فقط در هاست محلی (localhost) رایانهی شما قابل دسترسی است. برای اینکه بتوانید از راه دور به آن دسترسی داشته باشید، میتوانید با تغییر آدرس به `0.0.0.0` آن را در معرض دید عموم قرار دهید. این باعث می شود که از طریق شبکه محلی و آدرس های IP عمومی قابل دسترسی باشد. در بیشتر موارد، باید روی روتر خود باز ارسالی پورت (port forwarding) را هم تنظیم کنید.
+
+با احتیاط به قرار دادن پورت ها در معرض اینترنت نگاه کنید زیرا این کار به هر کسی در اینترنت اجازه می دهد گره شما را کنترل کند. اگر از کلاینت خود بهعنوان کیف پول استفاده میکنید، افراد خرابکار میتوانند به گره شما دسترسی پیدا کنند تا سیستم شما را خراب کنند یا سرمایههای شما را بدزدند.
+
+راهحل این مشکل، جلوگیری از تغییرپذیری روشهای بالقوه خطرناک RPC است. برای مثال، با Geth، میتوانید روشهای اصلاحپذیر را با یک پرچم اعلام کنید: `--http.api web3,eth,txpool`.
+
+دسترسی به رابط RPC را می توان از طریق توسعه APIهای لایه لبه یا برنامه های کاربردی وب سرور، مانند Nginx، و اتصال آنها به آدرس محلی و پورت کلاینت خود گسترش داد. استفاده از یک لایه میانی همچنین میتواند به توسعهدهندگان این امکان را بدهد که گواهی را برای اتصالات `https` ایمن به رابط RPC تنظیم کنند.
+
+راهاندازی یک وب سرور، یک پروکسی یا Rest API روبه خارج تنها راه برای دسترسی به نقطه پایانی RPC گره شما نیست. یکی دیگر از راههای حفظ حریم خصوصی برای تنظیم یک نقطه پایانی قابل دسترسی عمومی، میزبانی گره در سرویس پیاز [Tor](https://www.torproject.org/) خودتان است. بدین ترتیب میتوانید به RPC خارج از شبکهی محلی خود بدون آدرس آیپی (IP) عمومی ثابت یا پورتهای باز شده دسترسی پیدا کنید. با این حال، استفاده از این پیکربندی ممکن است تنها به نقطه پایانی RPC اجازه دهد که از طریق شبکه Tor که توسط همه برنامهها پشتیبانی نمیشود و ممکن است منجر به مشکلات اتصال شود، قابل دسترسی باشد.
+
+برای انجام این کار، باید [سرویس onion](https://community.torproject.org/onion-services/) خود را ایجاد کنید. [اسناد](https://community.torproject.org/onion-services/setup/) راهاندازی سرویس پیاز را برای هاست خود بررسی کنید. می توانید آن را به یک وب سرور با پروکسی به درگاه RPC یا فقط مستقیماً به RPC اشاره کنید.
+
+در نهایت، و یکی از محبوب ترین راه ها برای دسترسی به شبکه های داخلی از طریق اتصال VPN است. بسته به مورد استفاده شما و تعداد کاربرانی که نیاز به دسترسی به گره شما دارند، یک اتصال VPN ایمن ممکن است یک گزینه باشد. [OpenVPN](https://openvpn.net/) یک SSL VPN با امکانات کامل است که برنامه افزودنی شبکه ایمن لایه دوم یا سوم OSI را با استفاده از پروتکل استاندارد صنعتی SSL/TLS پیادهسازی میکند، از روشهای تأیید اعتبار کلاینت انعطافپذیر بر اساس گواهیها، کارتهای هوشمند و/یا نام کاربری پشتیبانی میکند، نام کاربری/رمز را ارائه می دهد و به سیاست های کنترل دسترسی خاص کاربر یا گروه با استفاده از قوانین فایروال اعمال شده در رابط مجازی VPN اجازه کار می دهد.
+
+### استفاده از گره {#operating-the-node}
+
+شما باید بهطور مرتب گره خود را کنترل کنید تا مطمئن شوید که به درستی کار میکند. ممکن است نیاز به انجام تعمیرات گاهبهگاه داشته باشید.
+
+#### آنلاین نگهداشتن گره {#keeping-node-online}
+
+نیازی نیست که گره شما همیشه آنلاین باشد، اما باید آن را تا حد امکان آنلاین نگه دارید تا با شبکه همگام شود. برای راه اندازی مجدد می توانید آن را خاموش کنید، اما به خاطر داشته باشید که:
+
+- اگر وضعیت اخیر همچنان روی دیسک نوشته می شود، خاموش شدن می تواند چند دقیقه طول بکشد.
+- خاموش شدن اجباری می تواند به دیتابیس آسیب برساند و شما را ملزم به همگام سازی مجدد کل گره کند.
+- کلاینت شما با شبکه همگام نمی شود و با راه اندازی مجدد باید مجدداً همگام شود. در حالی که گره می تواند از زمانی که آخرین خاموش شده بود همگام سازی را آغاز کند، بسته به مدت زمانی که آفلاین بوده است، فرآیند ممکن است زمان ببرد.
+
+_این موضوع روی گرههای اعتبار سنج لایهی اجماع اعمال نمیشود._ آفلاین کردن گرهی شما بر تمام سرویسهای وابسته به آن تأثیر میگذارد. اگر یک گره را برای _سهامگذاری_ اجرا میکنید، باید سعی کنید زمان خاموشی را تا حد امکان پایین آورید.
+
+#### ساختن سرویسهای کلاینت {#creating-client-services}
+
+ساختن سرویسی را برای اجرای خودکار کلاینتهای خود در هنگام راهاندازی در نظر بگیرید. به عنوان مثال، در سرورهای لینوکس، بهترین رویه ایجاد یک سرویس است، به عنوان مثال با `systemd`، که کلاینت را با پیکربندی مناسب، تحت یک کاربر با امتیازات محدود اجرا می کند و به طور خودکار ریستارت می شود.
+
+#### بهروزرسانی کلاینتها {#updating-clients}
+
+شما باید نرمافزار کلاینت خود را با آخرین پچهای امنیتی، ویژگیها و [EIPها](/eips/) بهروز نگهدارید. بهویژه قبل از [فورک سخت](/history/)، مطمئن شوید که نسخههای کلاینت صحیح را اجرا میکنید.
+
+> قبل از بهروزرسانیهای مهم شبکه، EF یک پست را در [وبلاگ](https://blog.ethereum.org) خود منتشر میکند. میتوانید [مشترک این اعلامیهها شوید](https://blog.ethereum.org/category/protocol#subscribe) تا زمانی که گره شما نیاز به بروزرسانی دارد، اعلان را در ایمیل خود دریافت کنید.
+
+بروزرسانی کلاینتها بسیار ساده است. هر کلاینت دستورالعملهای خاصی را در مستندات خود دارد، اما فرآیند معمولاً فقط دانلود آخرین نسخه و راهاندازی مجدد کلاینت با فایل اجرایی جدید است. کلاینت باید از جایی که کارش را متوقف کرد، اما با بهروزرسانیهای اعمال شده، به کار خود ادامه دهد.
+
+هر پیادهسازی کلاینت دارای یک رشته نسخه قابلخواندن توسط انسان است که در پروتکل همتا به همتا استفاده میشود، اما از طریق خط فرمان نیز قابلدسترسی است. این رشته نسخه به کاربران امکان می دهد بررسی کنند که آیا نسخه صحیح را اجرا میکنند یا نه و به جستجوگرهای بلوک و سایر ابزارهای تحلیلی علاقهمند به تعیین کمیت توزیع مشتریان خاص اجازهی دسترسی به شبکه را میدهد. لطفاً جهت کسب اطلاعات بیشتر در مورد رشتههای نسخه به مستندات هر کلاینت مراجعه کنید.
+
+#### اجرای سرویسهای اضافه {#running-additional-services}
+
+اجرای گره خودتان به شما امکان میدهد از خدماتی استفاده کنید که نیاز به دسترسی مستقیم به RPC کلاینت اتریوم دارند. اینها خدماتی هستند که بر روی اتریوم ساخته شده اند مانند [راهکارهای لایه 22](/developers/docs/scaling/#layer-2-scaling)، پشتیبان برای کیف پول، کاوشگرهای بلوک، ابزارهای توسعه دهنده و سایر زیرساخت های اتریوم.
+
+#### نظارت بر گره {#monitoring-the-node}
+
+برای نظارت صحیح بر گره خود، معیارهای تجمعی را در نظر بگیرید. کلاینتها نقاط پایانی معیارها را ارائه میکنند تا بتوانید دادههای جامعی درباره گره خود دریافت کنید. از ابزارهایی مثل [InfluxDB](https://www.influxdata.com/get-influxdb/) یا [Prometheus](https://prometheus.io/) برای ساخت پایگاه دادههایی استفاده کنید که میتوانید با استفاده از نرمافزارهایی مثل [Grafana](https://grafana.com/) آنها را تبدیل به بازنمایی بصری و نمودار کنید. تنظیمات زیادی برای استفاده از این نرمافزار و داشبوردهای مختلف Grafana وجود دارد تا بتوانید گره خود و شبکه را کاملاً به شکل بصری بازنمایی کنید. برای مثال، [آموزش نظارت بر Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/) را بررسی کنید.
+
+بهعنوان بخشی از نظارت خود، مطمئن شوید که عملکرد دستگاه خود را زیر نظر داشته باشید. در طول همگامسازی اولیهی گره شما، ممکن است نرمافزار کلاینت برای پردازنده و رم بسیار سنگین باشد. علاوه بر Grafana میتوانید از ابزارهایی که سیستمعاملتان به شما ارائه میدهد، مثل `htop` یا `uptime`، برای این کار استفاده کنید.
+
+## بیشتر بخوانید {#further-reading}
+
+- [راهنماهای سهام گذاری اتریوم](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat، به روز رسانی مکرر_
+- [راهنما | نحوه ایجاد یک اعتبارسنج برای سس اتریوم در شبکه اصلی](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet)_- CoinCashew مرتباً به روز میشود_
+- [راهنماهای ETHStaker درباره اجرای اعتبارسنج در شبکهی تست](https://github.com/remyroy/ethstaker#guides) – _ETHStaker، مرتباً بهروز میشود_
+- [سوالات متداول ادغام برای اپراتورهای نود](https://notes.ethereum.org/@launchpad/node-faq-merge) - _جولای 2022_
+- [تحلیل نیازمندیهای سختافزاری برای تبدیل شدن به یک گرهی کامل معتبر اتریوم](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– آلبرت پالا، 24 سپتامبر 2018_
+- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جاستین لروکس، 7 نوامبر 2019_
+- [اجرای یک گرهی هایپرلجر Besu روی شبکهی اصلی اتریوم: مزایا، نیازمندیها و راهاندازی](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– فلیپ فراگی، 7 مه 2020_
+- [بهکارگیری کلاینت اتریوم Nethermind با پشتهی نظارت](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _- Nethermind.eth، 8 ژوئیه 2020_
+
+## موضوعات مرتبط {#related-topics}
+
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+- [بلوکها](/developers/docs/blocks/)
+- [شبکهها](/developers/docs/networks/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
new file mode 100644
index 00000000000..47abc6b1f51
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
@@ -0,0 +1,92 @@
+---
+title: مکانیزمهای اجماع
+description: توضیحی درباره پروتکلهای اجماع در سیستمهای توزیعشده و نقشی که در اتریوم ایفا میکنند.
+lang: fa
+---
+
+مفهوم "مکانیسم اجماع" اغلب به صورت محاورهای برای اشاره به پروتکلهای "اثبات سهام"، "اثبات کار" یا "اثبات صلاحیت" استفاده میشود. با این حال، این موارد فقط اجزایی در مکانیزمهای اجماع هستند که از [حملات سیبیل](/glossary/#sybil-attack) محافظت میکنند. مکانیسمهای اجماع مجموعه کاملی از ایدهها، پروتکلها و مشوقها هستند که مجموعهای از گرهها را قادر میسازد تا در مورد وضعیت یک بلاکچین به توافق برسند.
+
+## پیشنیازها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه میشود ابتدا [مقدمهای بر اتریوم](/developers/docs/intro-to-ethereum/) را مطالعه کنید.
+
+## اجماع چیست؟ {#what-is-consensus}
+
+منظور از اجماع، یک توافقنامه کلی است که به آن دست یافتهایم. فرض کنید گروهی از افراد به سینما میروند. اگر در مورد انتخاب پیشنهادی فیلم اختلاف نظر وجود نداشته باشد، اجماع حاصل می شود. اگر اختلاف نظر وجود داشته باشد، گروه باید ابزاری داشته باشد تا تصمیم بگیرد کدام فیلم را ببیند. در موارد اختلاف شدید، گروه در نهایت از هم جدا می شود.
+
+در رابطه با بلاکچین اتریوم، این فرآیند رسمی شده است و رسیدن به اجماع به این معنی است که حداقل 66 درصد از گرههای شبکه در مورد وضعیت جهانی شبکه توافق دارند.
+
+## مکانیزم اجماع چیست؟ {#what-is-a-consensus-mechanism}
+
+اصطلاح مکانیزم اجماع به کل پشته پروتکلها، مشوقها و ایدههایی اشاره دارد که به شبکهای از گرهها اجازه میدهد در مورد وضعیت یک بلاکچین به توافق برسند.
+
+اتریوم از مکانیزم اجماع مبتنی بر اثبات سهام استفاده میکند که امنیت اقتصاد رمزنگاری خود را از مجموعهای از پاداشها و جریمههای اعمال شده برای سرمایه قفل شده توسط سهام گذاران به دست میآورد. این ساختار انگیزشی اشخاص سهام گذاران را تشویق میکند اعتبارسنجهای صادقانه را اجرا کنند، کسانی را که این کار را نمیکنند تنبیه میکند و هزینه بسیار بالایی برای حمله به شبکه ایجاد میکند.
+
+سپس، پروتکلی وجود دارد که نحوه انتخاب اعتبارسنجهای صادق برای پیشنهاد یا اعتبارسنجی بلوکها، پردازش تراکنشها و رای دادن به دیدگاه آنها در مورد رئیس زنجیره را کنترل میکند. در موقعیتهای نادری که چندین بلوک در یک موقعیت در نزدیکی سر زنجیره قرار دارند، یک مکانیسم انتخاب فورک وجود دارد که بلوکهایی را انتخاب میکند که «سنگینترین» زنجیره را تشکیل میدهند، که با تعداد اعتبارسنج که به بلوکهای وزنشده توسط میزان اتر سهام گذاری شده آنها رأی دادهاند، اندازهگیری میشود.
+
+برخی از مفاهیم برای اجماع مهم هستند مانند امنیت اضافی ارائه شده توسط هماهنگی اجتماعی خارج از باند به عنوان آخرین خط دفاع در برابر حملات در شبکه که به صراحت در کد تعریف نشدهاند.
+
+این اجزا با هم مکانیسم اجماع را تشکیل میدهند.
+
+## انواع مکانیزمهای اجماع {#types-of-consensus-mechanisms}
+
+### بر اساس اثبات کار {#proof-of-work}
+
+مانند بیتکوین، اتریوم زمانی از پروتکل اجماع مبتنی بر **اثبات کار (PoW)** استفاده میکرد.
+
+#### ساختن بلوک {#pow-block-creation}
+
+استخراجگر برای ایجاد بلوکهای جدید پر از تراکنشهای پردازش شده با یکدیگر رقابت میکنند. برنده، بلوک جدید را با بقیه شبکه به اشتراک میگذارد و مقداری اتر تازه ضربشده به دست میآورد. این رقابت را کامپیوتری برنده میشود که قادر به حل سریع ترین معمای ریاضی است. این مورد باعث ایجاد پیوند رمزنگاری بین بلوک فعلی و بلوک قبلی میشود. حل این معما همان کار در «اثبات کار» است. سپس زنجیره متعارف توسط یک قانون فورک انتخاب میشود که مجموعهای از بلوکها را انتخاب میکند که بیشترین کار را برای استخراج آنها انجام دادهاند.
+
+#### ایمنی {#pow-security}
+
+شبکه با توجه به این حقیقت که برای فریب دادن زنجیره نیاز به 51% توان پردازش شبکه دارید، ایمن میماند. این کار نیاز به چنان سرمایهگذاری زیادی برای تجهیزات و انرژی دارد که احتمالاً خرج شما از سودی که به دست خواهید آورد بیشتر خواهد بود.
+
+اطلاعات بیشتر درباره [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
+
+### بر اساس اثبات سهام {#proof-of-stake}
+
+اتریوم اکنون از پروتکل اجماع مبتنی بر **اثبات سهام (PoS)** استفاده میکند.
+
+#### ساختن بلوک {#pos-block-creation}
+
+اعتبارسنجها بلوکها را ایجاد میکنند. یک اعتبارسنج به طور تصادفی در هر اسلات انتخاب میشود تا پیشنهاد دهنده بلوک باشد. کاربر اجماعِ آنها، مجموعهای از تراکنشها را به عنوان "بار اجرایی" از مشتری اجرای جفت شده خود درخواست میکند. آنها این مورد را در دادههای اجماع میپیچانند یا به اصطلاح رپ میکنند تا یک بلوک تشکیل دهند که آن را به گرههای دیگر در شبکه اتریوم ارسال کنند. به این تولید بلوک در اتریوم، پاداش داده میشود. در موارد نادری که چندین بلوک ممکن برای یک اسلات وجود دارد، یا گرهها در زمانهای مختلف درباره بلوکها میشنوند، الگوریتم انتخاب فورک بلوکی را انتخاب میکند که زنجیره با بیشترین وزن اعتبارسنجها را تشکیل میدهد (که وزن تعداد اعتبارسنجهایی است که با مقدار اتر آنها مقیاسبندی شده است).
+
+#### ایمنی {#pos-security}
+
+یک سیستم اثبات سهام از نظر اقتصاد رمزنگاری ایمن است زیرا مهاجمی که تلاش میکند کنترل زنجیره را در دست بگیرد باید مقدار زیادی از اتر را از بین ببرد. یک سیستم پاداش، سهام گذاران را تشویق میکند صادقانه رفتار کنند، و جریمهها، سهامداران را از اقدام شرورانه باز میدارد.
+
+اطلاعات بیشتر درباره [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+
+### یک راهنمای تصویری {#types-of-consensus-video}
+
+برای کسب اطلاعات بیشتر درباره مکانیزمهای مختلف اجماع که در اتریوم استفادهشده است، نگاه کنید به:
+
+
+
+### مقاومت سیبیل و انتخاب زنجیره {#sybil-chain}
+
+اثبات کار و اثبات سهام به تنهایی پروتکلهای اجماع نیستند، اما اغلب برای سادگی به آنها اشاره میشود. اینها در واقع مکانیزمهای مقاومت سیبیل و انتخابکننده نویسنده بلوک هستند؛ روشی هستند برای انتخاب این که چه کسی آخرین بلوک را بنویسد. مؤلفه مهم دیگر، الگوریتم انتخاب زنجیره (معروف به انتخاب فورک) است که گرهها را قادر می سازد در سناریوهایی که چندین بلوک در یک موقعیت وجود دارند، یک بلوک صحیح را در سر زنجیره انتخاب کنند.
+
+**مقاومت سیبیل** عملکرد یک پروتکل در مقابل یک حمله سیبیل را میسنجد. مقاومت در برابر چنین حملاتی برای یک زنجیره بلوکی غیرمتمرکز بسیار ضروری است و به استخراجگرها و اعتبارسنجها امکان میدهد بر اساس منابعی که در اختیار گذاشتهاند بهصورت مساوی پاداش دریافت کنند. اثبات سهام و اثبات کار با مجبور کردن کاربر به هزینه کردن انرژی بسیار یا گذاشتن وثیقه زیاد، جلوی این حمله را میگیرند. این تمهیدات محافظتی، مانعی بهصرفه علیه حملات سیبیل هستند.
+
+یک **قانون انتخاب زنجیره** برای تصمیمگیری در این باره که کدام زنجیره، زنجیره «درست» است، استفاده میشود. بیتکوین از قانون «طولانیترین زنجیره» استفاده میکند، به این معنی که بلاکچینی که طولانیترین باشد، همان چیزی است که بقیه گرهها آن را معتبر میپذیرند و با آن کار میکنند. برای زنجیرههای اثبات کار، بلندترین زنجیره بر اساس سختی اثبات کار تجمیعی کل زنجیره مشخص میشود. اتریوم از طولانی ترین قانون زنجیره نیز استفاده میکرد؛ با این حال، اکنون که اتریوم بر روی اثبات سهام اجرا میشود، الگوریتم انتخاب فورک بهروزرسانیشدهای را اتخاذ کرد که «وزن» زنجیره را اندازهگیری میکند. وزن، مجموع آرای جمع شده اعتبارسنج است که توسط موجودیهای اتر سهامگذاری شده اعتبارسنج وزن میشود.
+
+اتریوم از مکانیزم اجماع به نام [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) استفاده می کند که [Casper FFG proof-of-stake](https://arxiv.org/abs/1710.09437) را با [قانون انتخاب فورکGHOST](https://arxiv.org/abs/2003.03052) ترکیب می کند.
+
+## بیشتر بخوانید {#further-reading}
+
+- [الگوریتم اجماع زنجیرهی بلوکی چیست؟](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
+- [اجماع ناکاموتو چیست؟ راهنمای کامل مبتدیها](https://blockonomi.com/nakamoto-consensus/)
+- [Casper چگونه کار میکند؟](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
+- [دربارهی ایمنی و کارایی زنجیرههای بلوکی مبتنی بر اثبات کار](https://eprint.iacr.org/2016/555.pdf)
+- [تحمل خطای بیزانس](https://en.wikipedia.org/wiki/Byzantine_fault)
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
+- [استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
+- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
new file mode 100644
index 00000000000..7dcecc1f3e3
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
@@ -0,0 +1,163 @@
+---
+title: حمله به پذیرش حق مشارکت در بلاکچین اتریوم و مقابله با آن
+description: در مورد راه های شناخته شده حمله به پذیرش حق مشارکت در بلاکچین اتریوم و نحوه مقابله با آنها بیشتر بدانید.
+lang: fa
+---
+
+سارقان و خرابکارها همواره در پی فرصتی هستند تا به نرمافزار دسترسی به شبکه اتریوم حمله کنند. این مقاله به معرفی راه های شناخته شده حمله به لایه اجماع بلاکچین اتریوم و نحوه مقابله با آنها میپردازد. اطلاعات این صفحه از یک [نسخه بلندتر](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) گرفته شده است.
+
+## پیشنیازها {#prerequisites}
+
+مقداری اطلاعات پایه درباره [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) ضروری است. همچنین داشتن دانش پایه درباره [لایه پاداش](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) در اتریوم و الگوریتم انتخاب شاخه های بلاکچین، [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) مفید خواهد بود.
+
+## مهاجمان چه میخواهند؟ {#what-do-attackers-want}
+
+یک تصور غلط رایج این است که یک مهاجم موفق میتواند اتر جدید تولید کند یا اتر را از حسابهای دلخواه تخلیه کند. هیچ یک از اینها امکانپذیر نیست زیرا تمام تراکنشها توسط همه کاربرهای اجرا در شبکه اجرا میشوند. تراکنشها باید شرایط اولیه اعتبار را رعایت کنند (مثلاً تراکنش باید توسط کلید خصوصی فرستنده امضا شده باشد، فرستنده موجودی کافی داشته باشد و غیره) در غیر اینصورت به سادگی برگشت داده میشوند. سه کلاس خروجی اصلی که یک مهاجم میتواند آنها را مورد هدف قرار دهد عبارت است از تنظیم مجدد (reorgs)، قطعیت مضاعف (double finality) یا تاخیر در قطعیت (finality delay).
+
+منظور از **تنظیم مجدد** تغییر شکل بلوکها با یک نظم جدید است که ممکن است با مقداری جمع و تفرق در زنجیره اصلی انجام شود. یک تنظیم مجدد مخرب میتواند از اضافه شدن یا نشدن بلوکهای خاص اطمینان حاصل کند که میتواند منجر به خرج مضاعف یا استخراج ارزش به وسیله پیش دستی با پس دستی در تراکنشها (MEV) شود. تنظیم مجدد همچنین برای جلوگیری از ورود برخی از تراکنشها به زنجیره اصلی قابل استفاده است که نوعی سانسور در شبکه ایجاد میکند. شدیدترین حالت تنظیم مجدد مربوط به «برگشت قطعیت» است که بلوکهایی که قبلا قطعی شدهاند را حذف یا جایگزین میکند. این اتفاق تنها در حالتی رخ میدهد که بیش از یک سوم اترهای سهامگذاری شده توسط مهاجم از بین بروند. این تضمین با عنوان «قطعیت اقتصادی» شناخته میشود که بعدا به آن پرداخته میشود.
+
+**قطعیت مضاعف** شرایط بعید اما شدیدی است که در آن دو فورک از زنجیره به طور همزمان قطعی میشوند که باعث ایجاد یک شکاف دائمی در زنجیره میشود. انجام این کار از نظر تئوری برای مهاجمی که مایل به ریسک 34 درصد از کل اتر سهامگذاری شده است، امکانپذیر است. در این شرایط جامعه مجبور خواهد شد خارج از زنجیره هماهنگ شود و به توافق برسند که کدام زنجیره را دنبال کنند، که این کار مستلزم استحکام در لایه اجتماعی است.
+
+حمله **تاخیر در قطعیت** از رسیدن شبکه به شرایط لازم برای قطعی کردن بخشهای زنجیره جلوگیری میکند. بدون قطعی شدن، به سختی میتوان به برنامههای کاربردی ساخته شده بر روی اتریوم اعتماد کرد. هدف یک حمله تاخیر در قطعیت، به احتمال زیاد صرفاً ایجاد اختلال در اتریوم به جای سود مستقیم است، مگر اینکه مهاجم موقعیت(های) کوتاه استراتژیک داشته باشد.
+
+حمله به لایه اجتماعی ممکن است با هدف تضعیف اعتماد عمومی به اتریوم، کاهش ارزش اتر، کاهش پذیرش یا تضعیف جامعه اتریوم برای دشوارتر کردن هماهنگی خارج از باند باشد.
+
+حالا و پس از مشخص شدن اینکه چرا یک مهاجم ممکن است به اتریوم حمله کند، بخشهای زیر به بررسی _چگونگی_ انجام این حملات میپردازد.
+
+## روشهای حمله {#methods-of-attack}
+
+### حملات لایه 0 {#layer-0}
+
+اول از همه، افرادی که به طور فعال در اتریوم مشارکت نمیکنند (با اجرای نرمافزار کاربر) میتوانند با هدف قرار دادن لایه اجتماعی (لایه 0) اقدام به حمله کنند. لایه 0 پایهای است که اتریوم بر روی آن بنا شده و به این ترتیب سطحی بالقوه برای حملات با عواقبی است که در بقیه پشته گسترش مییابد. برخی از نمونههای احتمالی:
+
+- یک کمپین اطلاعات غلط میتواند اعتماد جامعه به نقشه راه اتریوم، تیمهای توسعهدهندگان، برنامهها، و غیره را از بین ببرد. این امر میتواند تعداد افرادی را که مایل به مشارکت در تامین امنیت شبکه هستند کاهش دهد و هم عدمتمرکز و هم امنیت اقتصادی رمزارز را کاهش دهد.
+- حملات و/یا ارعاب هدفمند به سمت جامعه توسعهدهندگان. این امر میتواند منجر به خروج داوطلبانه توسعهدهندگان و کند شدن پیشروی اتریوم شود.
+
+- قوانین سختگیرانه می تواند حمله به لایه 0 به شمار آید، چرا که می تواند به سرعت در پذیرش و مشارکت تاثیر منفی ایجاد کند.
+- نفوذ طرفهای مطلع ولی بدخواه به جامعه توسعهدهندگان که هدف آنها کاهش سرعت پیشرفت با بحثهای تمامنشدنی، به تاخیر انداختن تصمیمات کلیدی، ایجاد مباحث هرز، و غیره است.
+- رشوههایی به طرفهای کلیدی اکوسیستم اتریوم داده میشود تا بر تصمیمگیری اثر بگذارند.
+
+چیزی که این حملات را به طور ویژه خطرناک میکند این است که در بسیاری از موارد سرمایه یا دانش فنی بسیار کمی مورد نیاز است. یک حمله لایه 0 میتواند تشدیدکننده یک حمله اقتصاد رمزارزی باشد. برای نمونه، اگر سانسور یا برگشت نهایی شدن از سوی یکی از سهامداران عمده بدخواه اگر انجام شود، و به این ترتیب قشر اجتماعی را تضعیف کند، هماهنگی برای تصمیمی گروهی را ممکن است سختتر کند.
+
+در برابر حملات به لایه 0 احتمالا دفاعی سر راست وجود ندارد، اما برخی اصول بنیادی را می توان اینجا مقرر کرد. یکی از آنها دستیابی به نسبت اطلاعات درست به غلط بالا درباره ی اتریوم در سطح دانش عمومی است که از سوی اعضای راستین این انجمن در بلاگ ها و سرورهای دیسکورد و گزارش های تفسیری و کتاب ها و پادکست ها و یوتیوب ایجاد و منتشر می شود. ما در این وبسایت سخت تلاش می کنیم تا اطلاعات دقیق به دست آوریم و آن را تا جای ممکن به زبان های دیگر ترجمه کنیم. محیطی سرشار از اطلاعات نوشتاری و تصویری با کیفیت بالا در برابر داده های غلط دفاعی مؤثر به شمار می آید.
+
+دیگر سنگر مهم در برابر حملات قشر اجتماعی بانفوذ داشتن چشم اندازی روشن و اعمال مجموعه قوانین مرتبط با آن است. اتریوم خود را بهعنوان قهرمان عدمتمرکز و امنیت در میان لایههای قرارداد هوشمند 1 قرار داده است، در حالی که به مقیاسپذیری و پایداری نیز اهمیت زیادی میدهد. هر گونه اختلاف نظر در جامعه اتریوم رخ دهد، این اصول اصلی در کمترین حد به خطر افتاده است. ارزیابی یک روایت در برابر این اصول اصلی، و بررسی آنها از طریق دورهای متوالی بررسی در فرآیند EIP (پیشنهاد بهبود اتریوم)، ممکن است به جامعه کمک کند تا بازیگران خوب را از بد تشخیص دهد و دامنه نفوذ بازیگران مخرب بر مسیر آینده اتریوم را محدود کند.
+
+در نهایت، بسیار مهم است که جامعه اتریوم باز و پذیرای همه شرکتکنندگان باشد. جامعهای همراه با نگهبانان و برونداری، بهطور ویژهای در برابر حملات اجتماعی آسیب پذیر است زیرا ساختن روایت های «ما و آنها» آسان است. قبیله گرایی و اکثریتگرایی سمی به جامعه آسیب می رساند و امنیت لایه0 را از بین می برد. اتربازهایی که به امنیت شبکه علاقه دارند، باید رفتار خود را بهصورت آنلاین و در فضای پوشیده بهعنوان مشارکتکننده مستقیم در امنیت لایه0 اتریوم ببینند.
+
+### حمله به پروتکل {#attacking-the-protocol}
+
+هر کسی می تواند نرمافزار کلاینت اتریوم را اجرا کند. برای افزودن اعتبارسنج به کلاینت، کاربر باید 32 اتر را در قرارداد سپردهگذاری کند. یک اعتبار سنج به کاربر اجازه می دهد تا با پیشنهاد و تأیید بلوک های جدید، فعالانه در امنیت شبکه اتریوم شرکت کند. اعتبارسنج اکنون پیغامی دارد که می تواند از آن برای تأثیرگذاری بر محتویات آینده بلاکچین استفاده کند - آنها می توانند صادقانه این کار را انجام دهند و ذخیره اتر خود را از طریق پاداش افزایش دهند یا می توانند سعی کنند روند را به نفع خود دستکاری کنند و سهام خود را به خطر بیندازند. یکی از راههای انجام حمله، جمعآوری نسبت بیشتری از کل سهام و سپس استفاده از آن برای برتری دادن به اعتبارسنجهای صادق است. هر چه نسبت سهام کنترل شده توسط مهاجم بیشتر باشد، قدرت رای آنها بیشتر می شود، به ویژه در برخی نقاط عطف اقتصادی که بعداً بررسی خواهیم کرد. با این حال، اکثر مهاجمان نمیتوانند اتر کافی برای حمله به این روش جمع کنند، بنابراین در عوض باید از تکنیکهای ظریف برای دستکاری اکثریت صادق استفاده کنند تا به روش خاصی عمل کنند.
+
+اساساً، همه حملات سهام کوچک، تغییرات ظریفی در دو نوع رفتار نادرست اعتبارسنج هستند: فعالیت کم (عدم تأیید/پیشنهاد یا انجام آن با تأخیر) یا فعالیت بیشازحد (پیشنهاد/تثبیت بیشازحد در یک اسلات). در روانترین شکلهایشان، این اقدامات به راحتی توسط الگوریتم انتخاب فورک و لایه انگیزشی انجام میشود، اما راههای هوشمندانهای برای بازی کردن سیستم به نفع مهاجم وجود دارد.
+
+### حملاتی با استفاده از مقادیر کم اتر {#attacks-by-small-stakeholders}
+
+#### دوبارهچینی {#reorgs}
+
+چندین مقاله حملاتی را به اتریوم توضیح دادهاند که تنها با بخش کوچکی از کل اتر سهامگذاریشده، به سازمانهای مجدد یا تاخیر نهایی میرسند. این حملات عموماً متکی بر این است که مهاجم برخی از اطلاعات را از اعتباسنجهای دیگر مخفی میکند و سپس آن را به روشهای ظریف و/یا در لحظهای مناسب منتشر میکند. هدف آنها معمولاً جابجایی برخی بلوک های صادق از زنجیره متعارف است. [نیودر و همکاران، 2020](https://arxiv.org/pdf/2102.02247.pdf) نشان دادند که چگونه یک اعتبارسنج مهاجم می تواند یک بلوک (`B`) برای یک اسلات خاص `n+1` ایجاد کند و تأیید کند، اما از انتشار آن به سایر گرههای شبکه خودداری کند. در عوض، آنها آن بلوک تایید شده را تا اسلات بعدی `n+2` نگه میدارند. یک اعتبارسنج صادق یک بلوک (`C`) برای اسلات `n+2` پیشنهاد میکند. تقریباً همزمان، مهاجم میتواند بلوک پنهانشده خود (`B`) و گواهیهای پنهانشده خود را برای آن آزاد کند، و همچنین با رأیهای خود برای اسلات نشان دهد که `B` رئیس زنجیره است`n+2`، به طور مؤثر وجود بلوک صادق `C` را انکار می کند. وقتی بلوک صادق `D` آزاد می شود، الگوریتم انتخاب فورک می بیند که ساختمان `D` بالای `B` سنگین تر از ساختمان `D` روی `C` است. بنابراین مهاجم موفق شده است بلوک صادق `C` در اسلات `n+2` را با استفاده از یک دوبارهچینی قبلی حذف کند. [یک مهاجم با 34٪](https://www.youtube.com/watch?v=6vzXwwk12ZE) از سهام شانس بسیار خوبی برای موفقیت در این حمله دارد، همانطور که [در این یادداشت](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) توضیح داده شده است. بااینحال، در تئوری، این حمله می تواند با سهام کوچکتر انجام شود. [نیودر و همکاران، 2020](https://arxiv.org/pdf/2102.02247.pdf) توصیف کردند که این حمله با 30٪ سهام کار می کند، اما بعداً نشان داده شد که با [2٪ از کل سهام](https://arxiv.org/pdf/2009.04987.pdf) قابل اجرا است و سپس مجدداً برای یک [اعتبارسنج واحد](https://arxiv.org/abs/2110.10086#) با استفاده از تکنیک های متعادل سازی در بخش بعدی بررسی خواهیم کرد.
+
+![ex-ante re-org](reorg-schematic.png)
+
+یک نمودار مفهومی از حمله دوبارهچینی یک بلوکی که در بالا توضیح داده شد (اقتباس از https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)
+
+یک حمله پیچیدهتر میتواند مجموعه اعتبارسنج صادق را به گروههای مجزا تقسیم کند که دیدگاههای متفاوتی از رئیس زنجیره دارند. این به عنوان **حمله متعادل کننده** شناخته می شود. مهاجم منتظر فرصت خود برای پیشنهاد یک بلوک است، و هنگامی که آن بلوک می رسد، آن دو را به اشتباه می اندازند و پیشنهاد ارائه میدهند. آنها یک بلوک را به نیمی از مجموعه اعتبارسنج صادق و بلوک دیگر را به نیمی دیگر ارسال می کنند. ابهام توسط الگوریتم فورک انتخاب تشخیص داده می شود و پیشنهاد دهنده بلوک جریمه می شود و از شبکه خارج می شود، اما این دو بلوک همچنان وجود دارند و حدود نیمی از مجموعه اعتبارسنج برای هر فورک تایید می شود. در همین حال، اعتبار سنجهای مخرب باقی مانده، تأییدیه های خود را متوقف می کنند. سپس، با رها کردن انتخابی تاییدیههایی که به نفع یک یا آن فورک هستند به اعتبارسنجهای کافی درست همانطور که الگوریتم انتخاب فورک اجرا میشود، وزن انباشته گواهیها را به نفع یک یا آن فورک منحرف میکنند. با تاییدکنندههای مهاجم که تقسیم یکنواختی از اعتبار سنجها را در دو فورک حفظ می کنند، این اتفاق میتواند بهطور نامحدود ادامه یابد. از آنجایی که هیچ یک از دو فورک نمی توانند اکثریت 2/3 را جذب کنند، شبکه نهایی نمی شود.
+
+**حملات برگشتی** هم همینطورند. رایها مجدداً توسط اعتبارسنج مهاجم متوقف میشوند. به جای آزاد کردن آرا برای حفظ تقسیم یکنواخت بین دو فورک، آنها از آرای خود در لحظات مناسب برای توجیه نقاط بازرسی که به طور متناوب بین فورک A و فورک B استفاده می کنند استفاده می کنند. این تلنگر توجیهی بین دو فورک مانع از وجود جفتهای چکپوینتهای منبع و هدف می شود که می توانند در هر زنجیره نهایی شوند که نتیجتاً نهایی شدن را متوقف می کند.
+
+
+
+هر دو حمله برگشتی و متعادل کننده متکی به این هستند که مهاجم کنترل بسیار خوبی بر زمانبندی پیام در سراسر شبکه داشته باشد، که البته بعید است. با این وجود، دفاعها به شکل وزندهی اضافی به پیامهای سریع در مقایسه با پیامهای آهسته در پروتکل تعبیه شدهاند. که به عنوان [افزایش وزن پیشنهاد دهنده](https://github.com/ethereum/consensus-specs/pull/2730) شناخته می شود. برای دفاع در برابر حملات پرش، الگوریتم انتخاب-فورک بهروزرسانی شد تا آخرین چکپوینت توجیهشده فقط بتواند در طول [1/3 اول اسلاتها در هر ایپاک](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) به زنجیره جایگزین سوییچ کند. این شرایط مانع از ذخیره آرای مهاجم برای استقرار بعدی میشود - الگوریتم انتخاب فورک به سادگی به نقطه بازرسی که در 1/3 اول ایپاک انتخاب کرده بود وفادار میماند که طی آن اکثر اعتبارسنجهای صادق رای میدادند.
+
+در مجموع، این اقدامات سناریویی را ایجاد میکنند که در آن یک پیشنهاد دهنده بلوک صادق، بلوک خود را خیلی سریع پس از شروع اسلات منتشر میکند، سپس یک دوره حدود 1/3 از اسلات (4 ثانیه) وجود دارد که در آنجا آن بلوک جدید ممکن است باعث شود که الگوریتم انتخاب فورک به زنجیره دیگری سوییچ کند. پس از همان مهلت، گواهیهایی که از اعتبارسنجهای کُند میآیند در مقایسه با مواردی که زودتر رسیدهاند، کاهش مییابند. این امر به شدت به پیشنهاد دهندگان و تایید کنندگان سریع در تعیین سر زنجیره کمک می کند و به طور قابل توجهی احتمال یک حمله موفقیت آمیز متعادل کننده یا برگشتی را کاهش می دهد.
+
+شایان ذکر است که تقویت پیشنهاد دهنده به تنهایی تنها در برابر «دوبارهچینی ارزان»، یعنی حملاتی که توسط مهاجمی با سهام کوچک انجام می شود، دفاع می کند. در واقع، خود افزایش پیشنهاد دهنده می تواند توسط سهامداران بزرگتر بازی کند. نویسندگان [این پست](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) توضیح میدهند که چگونه یک مهاجم با 7٪ از سهام میتواند آرای خود را به صورت استراتژیک به کار گیرد تا اعتبارسنجهای صادق را فریب دهد تا بر روی فورک خود بلوک بسازند که نتیجتاً یک بلوک صادق را دوبارهچینی کنند. این حمله با فرض شرایط تأخیر ایده آل که بسیار بعید است ابداع شد. شانس برای مهاجم هنوز بسیار کم است و سهام بیشتر به معنای سرمایه بیشتر در معرض خطر و یک بازدارنده اقتصادی قوی تر است.
+
+یک [حمله متعادل کننده که به طور خاص قانون LMD را هدف قرار می دهد](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) نیز ارائه شد که پیشنهاد شد علیرغم افزایش پیشنهاد دهنده قابل اجرا باشد. یک مهاجم دو زنجیره رقیب را با مبهم کردن طرح بلوک خود و انتشار هر بلوک به حدود نیمی از شبکه ایجاد می کند و تعادل تقریبی بین فورک ها را ایجاد می کند. سپس، اعتبار دهندگان تبانی آرای خود را مبهم می کنند و زمانبندی آن را به گونه ای تنظیم می کنند که نیمی از شبکه ابتدا رای خود را برای فورک`A` و نیمی دیگر رای خود را برای فورک `B` دریافت کنند. از آنجایی که قانون LMD تأیید دوم را کنار میگذارد و فقط اولی را برای هر اعتبارسنج نگه میدارد، نیمی از شبکه رایها را برای `A` و هیچ چیز دیگری برای `B` میبیند، نیمی دیگر نیز رایها را برای `B` و هیچ رأیی را برای `A` نمی بینند. نویسندگان قانون LMD را توصیف می کنند که به حریف «قدرت قابل توجهی» می دهد تا یک حمله متعادل کننده را انجام دهد.
+
+این بردار حمله LMD با [بهروزرسانی الگوریتم انتخاب فورک](https://github.com/ethereum/consensus-specs/pull/2845) بسته شد تا اعتبارسنجهای مبهمکننده را بهکلی از بررسی انتخاب فورک دور کند. اعتبارسنجهای مبهمکننده نیز تأثیر آتی خود را با الگوریتم انتخاب فورک کاهش می دهند. این امر از حمله متعادلکننده که در بالا ذکر شد جلوگیری می کند و در عین حال انعطاف پذیری در برابر حملات آوالانچ را نیز حفظ می کند.
+
+دسته دیگری از حملات، به نام [**حملات آوالانچ**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3)، در [مقاله مارس 2022](https://arxiv.org/pdf/2203.01315.pdf) توضیح داده شده است. برای انجام یک حمله آوالانچ، مهاجم باید چندین بلوک پیشنهاد دهنده متوالی را کنترل کند. در هر یک از اسلاتهای پیشنهادی بلوک، مهاجم بلوک خود را نگه میدارد و آنها را جمع میکند تا زمانی که زنجیره صادق به وزن زیر درختی برابر با بلوکهای پنهان شده برسد. سپس، بلوکهای نگهداشتهشده آزاد میشوند تا در حداکثر توان مبهمسازی کنند. نویسندگان گفتند که تقویت پیشنهاد دهنده بلوک - دفاع اولیه در برابر حملات متعادل کننده و برگشتی- در برابر برخی از انواع حملات آوالانچ ناتوان از محافظت است. با این حال، نویسندگان تنها حمله به نسخه بسیار ایده آل الگوریتم انتخاب فورک اتریوم را نشان دادند (آنها از GHOST بدون LMD استفاده کردند).
+
+حمله آوالانچ توسط بخش LMD الگوریتم انتخاب فورک LMD-GHOST کاهش می یابد. LMD به معنای «جدیدترین پیام محور» است و به جدولی اشاره دارد که توسط هر اعتبارسنج نگهداری میشود و حاوی آخرین پیام دریافتی از اعتبارسنجهای دیگر است. این فیلد فقط در صورتی بهروزرسانی میشود که پیام جدید از اسلات دیگری نسبت به آنچه قبلاً در جدول برای اعتبارسنج خاصی وجود دارد، باشد. در عمل، این بدان معنی است که در هر اسلات، اولین پیام دریافت شده همان پیامی است که پذیرفته شده است و هر پیام اضافی مبهمکننده است که باید نادیده گرفته شود. به عبارت دیگر، کلاینتهای اجماع ابهامات را به حساب نمیآورند - آنها از اولین پیام ارسالی از هر اعتبارسنج استفاده میکنند و مبهمکنندهها به سادگی کنار گذاشته میشوند و از حملات آوالانچی جلوگیری میکنند.
+
+چندین ارتقاء بالقوه دیگر در قانون انتخاب فورک وجود دارد که می تواند به امنیت ارائه شده توسط proposer-boost بیفزاید. یکی [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) است، که در آن گواهیدهندهها دیدگاه خود از انتخاب فورک را `n` ثانیه قبل از شروع یک اسلات ثابت میکنند و پیشنهاددهنده بلوک سپس به همگامسازی نمای زنجیره در سراسر شبکه کمک میکند. ارتقای احتمالی دیگر [single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality) است که با نهایی کردن زنجیره تنها پس از یک اسلات در برابر حملات بر اساس زمانبندی پیام محافظت می کند.
+
+#### تاخیر نهاییسازی {#finality-delay}
+
+[همان مقاله](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) که برای اولین بار حمله کم هزینه دوبارهچینی یک بلوک را توصیف کرد، همچنین یک حمله تاخیر نهاییسازی (معروف به "شکست زندگی") را توصیف کرد که متکی به مهاجم است که پیشنهاد دهنده بلوک برای بلوک لبمرز ایپاک است. این موضوع بسیار مهم است زیرا این بلوکهای لبمرز ایپاک تبدیل به نقاط بازرسی می شوند که Casper FFG از آنها برای نهایی کردن بخش هایی از زنجیره استفاده می کند. مهاجم به سادگی از بلوک خود جلوگیری می کند تا زمانی که اعتبارسنجهای صادق کافی از آرای FFG خود به نفع بلوک مرزی ایپاک قبلی به عنوان هدف نهایی سازی فعلی استفاده کنند. سپس بلوک پنهان شده خود را آزاد می کنند. آنها بلوک خود را تأیید می کنند و اعتبارسنجهای صادق باقی مانده نیز فورکهایی با نقاط بازرسی دارای هدف متفاوت ایجاد می کنند. اگر آنها آن را درست زمانبندی کنند، از نهایی شدن جلوگیری می کنند، زیرا 2/3 اکثریت فوقالعاده ای وجود نخواهد داشت که هر دو فورک را تأیید کند. هرچه سهام کوچکتر باشد، زمانبندی باید دقیق تر باشد، زیرا مهاجم گواهی های کمتری را مستقیماً کنترل می کند، و احتمال اینکه مهاجم کنترل کننده اعتبارسنج را برای یک بلوک مرزی ایپاک معین پیشنهاد کند، کمتر می شود.
+
+#### حملات دوربرد {#long-range-attacks}
+
+همچنین دستهای از حملات خاص برای بلاکچینهای اثبات سهام وجود دارد که شامل اعتبارسنجی است که در بلوک جنسیس شرکت کرده و یک فورک جداگانه از بلاکچین را در کنار فورک صادق نگه میدارد، و در نهایت اعتباردهنده صادق را متقاعد می کند که در زمان مناسبی بعداً به آن روی بیاورد. این نوع حمله به اتریوم امکانپذیر نیست، زیرا این ابزار نهایی تضمین می کند که همه اعتبارسنج ها در فواصل زمانی منظم در مورد حالت زنجیره صادق اجماع دارند ("نقاط بازرسی"). این مکانیزم ساده، مهاجمان دوربرد را خنثی می کند، زیرا کلاینتهای اتریوم به سادگی بلوک های نهاییشده را دوبارهچینی نمی کنند. گرههای جدیدی که به شبکه میپیوندند، این کار را با یافتن یک هش حالت اخیر مورد اعتماد (یک «[سوژه ضعیف](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) نقطه بازرسی») و استفاده از آن بهعنوان یک بلوک شبه جنسیس برای ایجاد در بالای آن انجام میدهند. این یک "دروازه اعتماد" برای یک گره جدید که وارد شبکه می شود قبل از اینکه بتواند اطلاعات را برای خود تأیید کند ایجاد می کند.
+
+#### رد خدمات {#denial-of-service}
+
+مکانیسم اثبات سهام اتریوم یک اعتبارسنج را از مجموع اعتبارسنجها انتخاب میکند تا پیشنهاددهنده بلوک در هر اسلات باشد. این را می توان با استفاده از یک تابع شناخته شده عمومی محاسبه کرد و این امکان برای مهاجم وجود دارد که پیشنهاددهنده بلوک بعدی را کمی قبل از پیشنهاد بلوک خود شناسایی کند. سپس، مهاجم می تواند پیشنهاد دهنده بلوک را اسپم کند تا از مبادله اطلاعات با همتایان خود جلوگیری کند. برای بقیه شبکه، به نظر می رسد که پیشنهاد دهنده بلوک آفلاین است و اسلات به سادگی خالی می شود. این می تواند نوعی سانسور علیهاعتبارسنج های خاص باشد و از افزودن اطلاعات به بلاکچین جلوگیری کند. اجرای انتخابات رهبر مخفی منفرد (SSLE) یا انتخابات رهبر مخفی غیر منفرد خطرات DoS را کاهش می دهد زیرا فقط پیشنهاد دهنده بلوک میداند که آنها انتخاب شده اند و انتخاب از قبل قابل اطلاع نیست. این هنوز اجرا نشده است، اما یک حوزه فعال در [تحقیق و توسعه](https://ethresear.ch/t/secret-non-single-leader-election/11789) است.
+
+همه اینها به این واقعیت اشاره دارد که حمله موفقیت آمیز به اتریوم با یک سهم کوچک بسیار دشوار است. حملات قابل اجرا که در اینجا توضیح داده شده اند به یک الگوریتم انتخاب فورک ایده آل، شرایط شبکه نامحتمل نیاز دارند، یا بردارهای حمله قبلاً با پچهای نسبتاً جزئی برای نرمافزار کلاینت منحل شده اند. البته این امر امکان وجود باگهای زیرودی در ماهیت کد را رد نمیکند، اما نشاندهنده استعداد بسیار بالای استعداد فنی، دانش لایههای اجماع و شانس مورد نیاز برای مؤثر بودن یک مهاجم با سهام حداقلی است. از دیدگاه یک مهاجم، بهترین گزینه ممکن است این باشد که تا حد ممکن اتر جمع کنند و با نسبت بیشتری از کل سهام بازگردد.
+
+### مهاجمانی که از کمتر/مساوی 33% از سهام کل استفاده میکنند {#attackers-with-33-stake}
+
+همه حملاتی که قبلاً در این مقاله ذکر شد، زمانی احتمال موفقیت بیشتری پیدا میکنند که مهاجم دارای اتر بیشتری برای رأی دادن باشد، و اعتبارسنجهای بیشتری که ممکن است برای پیشنهاد بلوکها در هر اسلات انتخاب شوند. بنابراین، یک اعتبارسنج خرابکار ممکن است قصد داشته باشد تا حد امکان اتر سهامگذاریشده را کنترل کند.
+
+33 درصد از اتر سهامگذاری شده معیاری برای مهاجمان است زیرا با هر چیزی بیشتر از این، آنها توانایی جلوگیری از نهایی شدن زنجیره را بدون نیاز به کنترل دقیق اقدامات اعتبارسنجهای دیگر دارند. آنها به سادگی می توانند همه با هم ناپدید شوند. اگر یکسوم یا بیشتر از اتر سهامگذاری شده به طور مخربی بلوک را تأیید کند یا نتواند تأیید کند، در این صورت دوسوم اکثریت نمیتواند وجود داشته باشد و زنجیره نمیتواند نهایی شود. نشت عدم فعالیت یک دفاع در برابر این حمله است. نشت عدم فعالیت آن دسته از اعتبارسنجهایی را شناسایی میکند که در تأیید ناکام هستند یا بر خلاف اکثریت دست به تایید می زنند. اتر سهامگذاریشده متعلق به این اعتبارسنجهای غیر تأییدکننده به تدریج از بین میرود تا اینکه در نهایت آنها در مجموع کمتر از 1/3 کل را نشان میدهند تا زنجیره بتواند دوباره نهایی شود.
+
+هدف از نشت عدم فعالیت، نهایی شدن مجدد زنجیره است. با این حال، مهاجم همچنین بخشی از اتر سهامگذاریشدهی خود را از دست می دهد. عدم فعالیت مداوم در اعتبارسنجهایی که 33 درصد از کل اتر سهامگذاری شده را نشان میدهد، بسیار گران است، حتی اگر اعتبارسنجها قطع نشده باشند.
+
+با فرض اینکه شبکه اتریوم ناهمزمان است (یعنی تاخیرهایی بین ارسال و دریافت پیام ها وجود دارد)، مهاجمی که 34 درصد از کل سهام را کنترل می کند می تواند باعث نهایی شدن دو برابره شود. این کار به این دلیل است که مهاجم میتواند زمانی که به عنوان تولیدکننده بلوک انتخاب میشود، ابهامسازی کند، سپس با همه اعتبارسنجهای رای دو برابری بدهد. این اتفاق وضعیتی را ایجاد می کند که در آن یک فورک از بلاکچین وجود دارد که هر کدام 34 درصد از اترهای سهامگذاری شده به آن رای می دهند. هر فورک فقط به 50 درصد اعتبارسنجهای باقیمانده نیاز دارد که به نفع آن رای دهند تا هر دو فورک توسط اکثریت فوقالعاده پشتیبانی شوند، در این صورت هر دو زنجیره میتوانند نهایی شوند (زیرا 34 درصد اعتبارسنج مهاجمان + نیمی از 66 درصد باقیمانده = 67 درصد روی هر فورک). بلوکهای رقیب هر کدام باید توسط حدود 50 درصد اعتبارسنجهای صادق دریافت شوند، بنابراین این حمله تنها زمانی قابل اجرا است که مهاجم تا حدودی بر زمانبندی پیام هایی که در شبکه منتشر می شوند کنترل داشته باشد تا بتواند نیمی از اعتبارسنج های صادق را به هر زنجیره هدایت کند. مهاجم برای دستیابی به این قطعیت مضاعف، لزوماً کل سهام خود را نابود میکند (34 درصد از 10 میلیون اتر با مجموعه اعتبارسنج امروزی) زیرا 34 درصد از تأییدکنندگان آنها به طور همزمان رأی مضاعف میدهند - یعنی یک تخلف قابل کاهش با حداکثر مجازات در همبستگی. دفاع مناسب در برابر این حمله هزینه بسیار زیاد از بین بردن 34 درصد از کل اتر سهامگذاری شده است. بازیابی از این حمله مستلزم آن است که جامعه اتریوم "بیرون از بازی" هماهنگ باشد و موافقت کند که یکی از فورک ها را دنبال کند و دیگری را نادیده بگیرد.
+
+### مهاجمانی که از 50% کل سهام استفاده می کنند {#attackers-with-50-stake}
+
+در 50% اتر سهامگذاری شده، گروهی از اعتبارسنجهای شرور میتوانند از نظر تئوری زنجیره را به دو فورک با اندازه مساوی تقسیم کنند و سپس به سادگی از کل 50% سهام خود استفاده کنند تا بر خلاف مجموعه اعتبارسنج صادق رای دهند، در نتیجه دو فورک را حفظ کرده و از نهایی شدن جلوگیری کنند. نشت عدم فعالیت در هر دو فورک در نهایت منجر به نهایی شدن هر دو زنجیره می شود. در این مرحله، تنها گزینه بازگشت به ریکاوری اجتماعی است.
+
+بسیار بعید است که یک گروه متخاصم از اعتبارسنجها بتوانند دقیقاً 50 درصد از کل سهام را با توجه به درجهای از نوسان در شمار اعتبارسنج صادقانه، تأخیر شبکه و غیره کنترل کنند - به نظر می رسد هزینه هنگفت ایجاد چنین حمله ای همراه با احتمال کم موفقیت، یک بازدارنده قوی برای یک مهاجم منطقی باشد، به خصوص زمانی که یک سرمایهگذاری کوچک اضافی برای به دست آوردن _بیش از_ 50% قدرت بسیار بیشتری را به ارمغان میآورد.
+
+در >50درصد از کل سهام، مهاجم می تواند بر الگوریتم انتخاب فورک تسلط داشته باشد. در این حالت، مهاجم میتواند با اکثریت آرا تأیید کند و به آنها کنترل کافی برای انجام دوبارهچینیهای کوتاه بدون نیاز به فریب دادن کلاینتهای صادق بدهد. اعتبارسنجهای صادق از این روش پیروی میکنند زیرا الگوریتم انتخاب فورک آنها نیز زنجیره مورد علاقه مهاجم را سنگینترین میداند، بنابراین زنجیره میتواند نهایی شود. این امر مهاجم را قادر میسازد تا تراکنشهای خاصی را سانسور کند،دوبارهچینیهای کوتاهبُرد انجام دهد و با مرتب کردن مجدد بلوکها به نفع خود، حداکثر MEV را استخراج کند. دفاع در برابر این هزینه هنگفت همان سهام اکثریت (در حال حاضر کمتر از 19 میلیارد دلار) است که توسط یک مهاجم در معرض خطر قرار میگیرد، زیرا احتمالاً لایه اجتماعی وارد عمل شده و یک فورک اقلیت صادق را اتخاذ میکند و ارزش سهام مهاجم را به شدت کاهش میدهد.
+
+### مهاجمانی که از >=66٪ از کل سهام استفاده می کنند {#attackers-with-66-stake}
+
+مهاجمی با 66% یا بیشتر از کل اتر سهامگذاری شده میتواند زنجیره مورد نظر خود را بدون نیاز به وادار کردن هیچ اعتبارسنج صادقی نهایی کند. مهاجم میتواند به سادگی به فورک مورد نظر خود رای دهد و سپس آن را نهایی کند، صرفاً به این دلیل که می تواند با اکثریت ناصادق رای دهد. به عنوان ذینفع اکثریت، مهاجم همیشه میتواند محتویات بلوک های نهایی را کنترل کند: با قدرتِ خرج کردن، عقب بردن و دوباره خرج کردن، سانسور برخی تراکنش ها و سازماندهی مجدد زنجیره به شکل دلخواهش. با خرید اتر اضافی برای کنترل 66٪ به جای 51٪، مهاجم به طور مؤثر توانایی انجام مجدد دوبارهچینی و بازگشت نهایی (یعنی تغییر گذشته و همچنین کنترل آینده) را کسب می کند. تنها دفاع واقعی در اینجا هزینه هنگفت 66 درصد از کل اتر سهامگذاری شده و گزینه بازگشت به لایه اجتماعی برای هماهنگ کردن پذیرش یک فورک جایگزین است. در بخش بعدی می توانیم این موضوع را با جزئیات بیشتری بررسی کنیم.
+
+## مردم: آخرین خط دفاع {#people-the-last-line-of-defense}
+
+اگر اعتبارسنجهای ناصادق موفق شوند نسخه دلخواه خودشان از زنجیره را نهایی کنند، جامعه اتریوم در شرایط دشواری قرار می گیرد. زنجیره متعارف شامل یک بخش ناصادقانه است که در تاریخ خود گنجانده شده است، در حالی که تأییدکنندگان صادق می توانند به دلیل تأیید یک زنجیره جایگزین (صادق) مجازات شوند. توجه داشته باشید که یک زنجیره نهایی شده اما نادرست نیز می تواند از یک باگ در کلاینت پراستفاده ایجاد شود. در پایان، بازگشت نهایی، تکیه بر لایه اجتماعی - لایه 0 - برای حل وضعیت است.
+
+یکی از نقاط قوت اجماع اثبات سهام اتریوم این است که [تعدادی از استراتژیهای دفاعی](https://youtu.be/1m12zgJ42dI?t=1712) وجود دارد که جامعه میتواند در مواجهه با حمله از آنها استفاده کند. یک پاسخ حداقلی میتواند خروج اجباری اعتبارسنجهای متعلق ببه مهاجم از شبکه بدون جریمه اضافی باشد. برای ورود مجدد به شبکه، مهاجم باید به صف فعالسازی بپیوندد که تضمین میکند مجموعه اعتبارسنجها به تدریج رشد میکند. به عنوان مثال، افزودن اعتبارسنجهای کافی برای دو برابر کردن مقدار اتر سهامگذاری شده، حدود 200 روز طول میکشد، در واقع اعتبارسنجهای صادق را 200 روز قبل از اینکه مهاجم بتواند حمله 51 درصدی دیگری انجام دهد، خریداری میکند. با این حال، جامعه همچنین میتواند تصمیم بگیرد که مهاجم را با لغو پاداشهای گذشته یا سوزاندن بخشی (تا 100٪) از سرمایه سهامگذاریشدهشان، سختتر مجازات کند.
+
+مجازاتی که برای مهاجم اعمال شود هرچه باشد، جامعه همچنین باید با هم تصمیم بگیرد که آیا زنجیره ناصادق، علیرغم اینکه الگوریتم انتخاب فورک کدگذاری شده در کلاینتهای اتریوم مورد علاقه است، در واقع نامعتبر است و به جای آن جامعه باید در بالای زنجیره صادقانه اقدام به ایجاد بلوک کند. اعتبارسنجهای صادق می توانند به طور جمعی توافق کنند که بلوک را در بالای یک فورک پذیرفته شده توسط جامعه بلاکچین اتریوم ایجاد کنند که ممکن است، برای مثال، زنجیره متعارف را قبل از شروع حمله قطع کرده باشد یا اعتبارسنجهای مهاجمان را به زور حذف کنند. اعتبارسنجهای صادق انگیزه خواهند داشت تا بر روی این زنجیره بلوکسازی کنند، زیرا از مجازات های اعمال شده برای آنها برای عدمتأیید زنجیره مهاجم (که کار خوبی است) اجتناب می کنند. صرافیها، ورودیهای جریان، و برنامههای کاربردی ساختهشده بر روی اتریوم احتمالاً ترجیح میدهند در زنجیره صادق باشند و اعتبارسنجهای صادق را تا بلاکچین صادق دنبال کنند.
+
+با این حال، این یک چالش حاکمیتی اساسی خواهد بود. برخی از کاربران و اعتبارسنجها بدون شک در نتیجه بازگشت به زنجیره صادق ضرر خواهند کرد، تراکنشهای موجود در بلوکهای تایید شده پس از حمله به طور بالقوه میتوانند به عقب برگردند و لایه برنامه را مختل کند، و این امر به سادگی اخلاق برخی از کاربران که به "کد همان قانون است" اعتماد دارند را تضعیف میکند. صرافیها و برنامههای کاربردی به احتمال زیاد اقدامات خارج از زنجیره را به تراکنشهای درون زنجیرهای مرتبط میکنند که ممکن است اکنون به عقب بازگردند، که دومینویی از بازپسگیریها و تجدیدنظرهایی که به سختی میتوان آنها را منصفانه انتخاب کرد شروع خواهد کرد، به خصوص اگر سودهای غیرقانونی به دیفای یا سایر مشتقات با اثرات ثانویه برای کاربران صادق واریز شوند میکس شده باشند. بدون شک برخی از کاربران، شاید حتی افراد نهادی، قبلاً از طریق زیرکی یا از روی خوشفکری از این زنجیره ناصادق بهره می بردند و ممکن بود با یک فورک برای حافظت از دستاوردهای خود مخالفت کنند. فراخوانهایی برای تمرین پاسخ جامعه به حملات >51 درصدی انجام شده است تا بتوان به سرعت یک کاهش هماهنگ معقول انجام داد. بحث مفیدی توسط ویتالیک در ethresear.ch [اینجا](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) و [اینجا](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) و در توییتر [اینجا](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw) وجود دارد. هدف از یک پاسخ اجتماعی هماهنگ باید این باشد که در مورد مجازات مهاجم و به حداقل رساندن اثرات برای سایر کاربران بسیار هدفمند و مشخص باشد.
+
+حاکمیت در حال حاضر یک موضوع پیچیده است. مدیریت یک پاسخ اضطراری لایه 0 به یک زنجیره نهایی ناصادق بدون شک برای جامعه اتریوم چالش برانگیز است، اما [این اتفاق](/history/#dao-fork-summary) - [دوبار](/history/#tangerine-whistle) - در تاریخ اتریوم رخ داده است.
+
+با این وجود، چیزی نسبتاً رضایتبخش در نشست نهایی در زندگی واقعی وجود دارد. در نهایت، حتی با وجود این پشته فنآوری فوقالعاده بالای سرمان، اگر بدترین اتفاق میافتاد، مردم واقعی باید راه خود را برای خروج از آن هماهنگ میکردند.
+
+## خلاصه {#summary}
+
+این صفحه برخی از راههایی را که مهاجمان ممکن است برای سوء استفاده از پروتکل اجماع اثبات سهام اتریوم تلاش کنند را بررسی میکند. دوبارهچینیها و تاخیرهای نهایی برای مهاجمان با افزایش نسبت کل اتر سهامگذاری شده بررسی شدند. به طور کلی، مهاجم ثروتمندتر شانس موفقیت بیشتری دارد زیرا سهام آنها به قدرت رای تبدیل می شود که می توانند از آن برای تأثیرگذاری بر محتوای بلوک های آینده استفاده کنند. در مقادیر آستانه مشخصی از اتر سهامگذاری شده، قدرت مهاجم افزایش می یابد:
+
+33 درصد: تاخیر قطعیت
+
+34 درصد: تاخیر قطعیت، قطعیت دو برابر
+
+51 درصد: تاخیر قطعیت، قطعیت دو برابر، سانسور، کنترل آینده بلاکچین
+
+66 درصد: تأخیر قطعیت، قطعیت دو برابر، سانسور، کنترل آینده و گذشته بلاکچین
+
+همچنین طیف وسیعی از حملات پیچیدهتر وجود دارد که به مقادیر کمی از اتر مستقر نیاز دارند، اما متکی به یک مهاجم بسیار پیشرفته است که کنترل خوبی بر زمانبندی پیام دارد تا اعتبارسنج صادق را به نفع خود سوق دهد.
+
+به طور کلی، با وجود این بردارهای حمله بالقوه، خطر یک حمله موفقیت آمیز کم است، مطمئناً کمتر از معادل های اثبات کار. این به دلیل هزینه هنگفتِ اترِ درمعرضِ خطر است که توسط مهاجمی که قصد دارد اعتبارسنج های صادق را با قدرت رای خود تحت تأثیر قرار دهد. لایه تشویقی تعبیه شده "هویج و چوب" در برابر اکثر تخلفات، به ویژه برای مهاجمان کم خطر محافظت می کند. همچنین بعید است که حملات جهشی و تعادلی ظریفتر موفق شوند زیرا شرایط واقعی شبکه کنترل دقیق تحویل پیام به زیرمجموعههای خاصی از اعتبارسنج ها را بسیار دشوار میکند و تیمهای کلاینت به سرعت بردارهای شناخته شده حملات برگشتی، متعادل کننده و آوالانچ را با وصلههای خنثی کردهاند.
+
+حملات 34 درصد، 51 درصد یا 66 درصد احتمالاً برای حل کردن نیاز به هماهنگی اجتماعی در دنیای واقعی دارند. در حالی که این احتمالاً برای جامعه دردناک است، توانایی یک جامعه برای پاسخگویی خارج از زمین بازی یک عامل بازدارنده قوی برای یک مهاجم است. لایه اجتماعی اتریوم پشتیبان نهایی است - یک حمله فنی موفق هنوز میتواند توسط جامعه با پذیرش یک فورک صادق خنثی شود. یک مسابقه بین مهاجم و جامعه اتریوم وجود خواهد داشت - میلیاردها دلار هزینه شده برای یک حمله 66 درصدی احتمالاً با یک حمله هماهنگی اجتماعی موفقیت آمیز در صورتی که به اندازه کافی سریع تحویل داده شود، از بین می رود و مهاجم را با کیسه های سنگین اتر نقد و سهامگذاری شده اما در یک زنجیره ناصادق که توسط جامعه اتریوم نادیده گرفته شده است، باقی می گذارد. احتمال اینکه این کار برای مهاجم سودآور باشد به اندازه کافی کم است که یک بازدارنده مؤثر باشد. به همین دلیل است که سرمایه گذاری در حفظ یک لایه اجتماعی منسجم با ارزش های کاملاً همسو بسیار مهم است.
+
+## اطلاعات بیشتر {#further-reading}
+
+- [نسخه دقیق تر این صفحه](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
+- [ویتالیک درباره قطعیت تسویه](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
+- [مقاله LMD GHOST](https://arxiv.org/abs/2003.03052)
+- [مقاله Casper-FFG](https://arxiv.org/abs/1710.09437)
+- [مقاله Gasper](https://arxiv.org/pdf/2003.03052.pdf)
+- [مشخصات اجماع افزایش وزن پیشنهاددهنده بلوک](https://github.com/ethereum/consensus-specs/pull/2730)
+- [حملات برگشتی در ethresear.ch](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
+- [تحقیقات SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
new file mode 100644
index 00000000000..44027651b38
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
@@ -0,0 +1,92 @@
+---
+title: تصدیقها
+description: توصیفی از تصدیقها در اثبات سهام اتریوم.
+lang: fa
+---
+
+از یک اعتبارسنج انتظار می رود در هر ایپوک یک تصدیق ایجاد، امضا و پخش کند. این صفحه نشان میدهد که این گواهیها چگونه هستند و چگونه پردازش میشوند و بین کاربرهای اجماع اعلام میشوند.
+
+## تصدیق چیست؟ {#what-is-an-attestation}
+
+Every [epoch](/glossary/#epoch) (6.4 minutes) a validator proposes an attestation to the network. The attestation is for a specific slot in the epoch. The purpose of the attestation is to vote in favor of the validator's view of the chain, in particular the most recent justified block and the first block in the current epoch (known as `source` and `target` checkpoints). This information is combined for all participating validators, enabling the network to reach consensus about the state of the blockchain.
+
+The attestation contains the following components:
+
+- `aggregation_bits`: a bitlist of validators where the position maps to the validator index in their committee; the value (0/1) indicates whether the validator signed the `data` (i.e. whether they are active and agree with the block proposer)
+- `data`: details relating to the attestation, as defined below
+- `signature`: a BLS signature that aggregates the signatures of individual validators
+
+The first task for an attesting validator is to build the `data`. The `data` contains the following information:
+
+- `slot`: The slot number that the attestation refers to
+- `index`: A number that identifies which committee the validator belongs to in a given slot
+- `beacon_block_root`: Root hash of the block the validator sees at the head of the chain (the result of applying the fork-choice algorithm)
+- `source`: Part of the finality vote indicating what the validators see as the most recent justified block
+- `target`: Part of the finality vote indicating what the validators see as the first block in the current epoch
+
+Once the `data` is built, the validator can flip the bit in `aggregation_bits` corresponding to their own validator index from 0 to 1 to show that they participated.
+
+Finally, the validator signs the attestation and broadcasts it to the network.
+
+### Aggregated attestation {#aggregated-attestation}
+
+There is a substantial overhead associated with passing this data around the network for every validator. Therefore, the attestations from individual validators are aggregated within subnets before being broadcast more widely. This includes aggregating signatures together so that an attestation that gets broadcast includes the consensus `data` and a single signature formed by combining the signatures of all the validators that agree with that `data`. This can be checked using `aggregation_bits` because this provides the index of each validator in their committee (whose ID is provided in `data`) which can be used to query individual signatures.
+
+In each epoch 16 validators in each subnet are selected to be the `aggregators`. The aggregators collect all the attestations they hear about over the gossip network that have equivalent `data` to their own. The sender of each matching attestation is recorded in the `aggregation_bits`. The aggregators then broadcast the attestation aggregate to the wider network.
+
+When a validator is selected to be a block proposer they package aggregate attestations from the subnets up to the latest slot in the new block.
+
+### Attestation inclusion lifecycle {#attestation-inclusion-lifecycle}
+
+1. Generation
+2. Propagation
+3. گردآوری
+4. Propagation
+5. Inclusion
+
+The attestation lifecycle is outlined in the schematic below:
+
+![attestation lifecycle](./attestation_schematic.png)
+
+## پاداشها {#rewards}
+
+Validators are rewarded for submitting attestations. The attestation reward depends on the participation flags (source, target and head), the base reward and the participation rate.
+
+Each of the participation flags can be either true or false, depending on the submitted attestation and its inclusion delay.
+
+The best scenario occurs when all three flags are true, in which case a validator would earn (per correct flag):
+
+`reward += base reward * flag weight * flag attesting rate / 64`
+
+The flag attesting rate is measured using the sum of effective balances of all attesting validators for the given flag compared the total active effective balance.
+
+### Base reward {#base-reward}
+
+The base reward is calculated according to the number of attesting validators and their effective staked ether balances:
+
+`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)`
+
+#### Inclusion delay {#inclusion-delay}
+
+At the time when the validators voted on the head of the chain (`block n`), `block n+1` was not proposed yet. Therefore attestations naturally get included **one block later** so all attestations who voted on `block n` being the chain head got included in `block n+1` and, the **inclusion delay** is 1. If the inclusion delay doubles to two slots, the attestation reward halves, because to calculate the attestation reward the base reward is multiplied by the reciprocal of the inclusion delay.
+
+### Attestation scenarios {#attestation-scenarios}
+
+#### Missing Voting Validator {#missing-voting-validator}
+
+Validators have a maximum of 1 epoch to submit their attestation. If the attestation was missed in epoch 0, they can submit it with an inclusion delay in epoch 1.
+
+#### Missing Aggregator {#missing-aggregator}
+
+There are 16 Aggregators per epoch in total. In addition, random validators subscribe to **two subnets for 256 epochs** and serve as a backup in case aggregators are missing.
+
+#### Missing block proposer {#missing-block-proposer}
+
+Note that in some cases a lucky aggregator may also become the block proposer. If the attestation was not included because the block proposer has gone missing, the next block proposer would pick the aggregated attestation up and include it into the next block. However, the **inclusion delay** will increase by one.
+
+## بیشتر بخوانید {#further-reading}
+
+- [Attestations in Vitalik's annotated consensus spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
+- [Attestations in eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
+
+_در مورد جامعه منابعی که به شما کمک می کنند بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
new file mode 100644
index 00000000000..6da3896f69a
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
@@ -0,0 +1,69 @@
+---
+title: پیشنهاد بلوک
+description: توضیح نحوه پیشنهاد بلوک ها در اتریوم اثبات سهام.
+lang: fa
+---
+
+بلوک ها واحدهای بنیادین بلاک چین هستند. بلوکها واحدهای مجزای اطلاعاتی هستند که بین گرهها رد و بدل میشوند، مورد توافق قرار میگیرند و به پایگاه داده هر گره اضافه میشوند. در این صفحه نحوه ایجاد آنها توضیح داده میشود.
+
+## پیشنیازها {#prerequisites}
+
+پیشنهاد بلوک بخشی از پروتکل اثبات سهام است. برای کمک به فهمیدن توضیحات این صفحه، توصیه می کنیم در مورد [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) و [معماری بلوک](/developers/docs/blocks/) مطالعه کنید.
+
+## چه کسی بلوک ها را ایجاد می کند؟ {#who-produces-blocks}
+
+حساب های اعتبارسنج بلوک ها را پیشنهاد می کنند. حسابهای اعتبارسنج توسط اپراتورهای گره مدیریت میشوند که نرمافزار اعتبارسنجی را به عنوان بخشی از کاربرهای اجرا و اجماع خود اجرا میکنند و حداقل 32 اتر را در قرارداد سپردهگذاری کردهاند. با این حال، هر اعتبارسنج فقط بعضا مسئول پیشنهاد یک بلوک است. اتریوم زمان را در اسلات ها و ایپوکها اندازه گیری می کند. هر اسلات دوازده ثانیه است و 32 اسلات (6.4 دقیقه) یک ایپوک را تشکیل می دهند. هر اسلات فرصتی برای افزودن یک بلوک جدید به اتریوم است.
+
+### انتخاب تصادفی {#random-selection}
+
+در هر اسلات، به صورت شبهتصادفی یک اعتبارسنج واحد برای پیشنهاد یک بلوک انتخاب میشود. در یک بلاکچین، تصادفی بودن واقعی وجود ندارد، زیرا اگر هر گره اعداد کاملاً تصادفی تولید کند، نمیتوانند به اجماع برسند. به جای آن، هدف این است که فرآیند انتخاب ولیدیتور غیرقابل پیشبینی باشد. تصادفیسازی در اتریوم با استفاده از الگوریتمی به نام RANDAO انجام میشود که یک هش از پیشنهاددهنده بلوک را با یک بذر که در هر بلوک بهروز میشود، ترکیب میکند. این مقدار برای انتخاب یک اعتبارسنج خاص از کل مجموعه ولیدیتورها استفاده میشود. انتخاب اعتبارسنج دو دوره زمانی قبل از آن تعیین میشود تا از انواع خاصی از دستکاری بذر جلوگیری شود.
+
+اگرچه ولیدیتورها در هر اسلات به RANDAO اضافه میکنند، اما مقدار جهانی RANDAO فقط یک بار در هر دوره بهروز میشود. برای محاسبه شاخص پیشنهاددهنده بلوک بعدی، مقدار RANDAO با شماره اسلات ترکیب میشود تا یک مقدار منحصر به فرد در هر اسلات ایجاد شود. احتمال انتخاب یک اعتبارسنج خاص تنها `1/N` نیست (که در آن `N` = مجموع اعتبارسنجهای فعال است). در عوض، این احتمال با توجه به مانده مؤثر ETH هر اعتبارسنج ارزیابی میشود. حداکثر مانده مؤثر 32 ETH است (این بدان معناست که `مانده < 32 ETH` منجر به وزن کمتری نسبت به `balance == 32 ETH` می شود، اما `مانده > >32 ETH می شود. ETH` منجر به وزن بالاتر از `مانده == 32 ETH`) نمی شود.
+
+فقط یک پیشنهاد بلوک در هر اسلات انتخاب می شود. در شرایط عادی، یک تولیدکننده بلوک واحد، یک بلوک واحد را در اسلات اختصاصی خود ایجاد و منتشر میکند. ایجاد دو بلوک برای یک اسلات، تخطی قابل تنبیه است که اغلب به عنوان "تردید" شناخته میشود.
+
+## بلوک چگونه ایجاد می شود؟ {#how-is-a-block-created}
+
+انتظار میرود پیشنهاددهنده بلوک، یک بلوک بیکن امضا شده را منتشر کند که بر اساس آخرین سر بلوک زنجیره طبق نظر الگوریتم انتخاب فورک محلی خود ساخته شده است. الگوریتم انتخاب فورک، هرگونه تصدیق در صف مانده از اسلات قبلی را اعمال میکند، سپس بلوکی را پیدا میکند که بیشترین وزن انباشته تصدیقها را در تاریخچه خود دارد. آن بلوک، والد بلوک جدید ایجاد شده توسط پیشنهاد دهنده است.
+
+پیشنهاددهنده بلوک با جمعآوری دادهها از پایگاه داده محلی و دیدگاه خود از زنجیره، یک بلوک ایجاد میکند. محتویات بلوک در کادر زیر نشان داده شده است:
+
+```rust
+class BeaconBlockBody(Container):
+ randao_reveal: BLSSignature
+ eth1_data: Eth1Data
+ graffiti: Bytes32
+ proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
+ attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
+ attestations: List[Attestation, MAX_ATTESTATIONS]
+ deposits: List[Deposit, MAX_DEPOSITS]
+ voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
+ sync_aggregate: SyncAggregate
+ execution_payload: ExecutionPayload
+```
+
+فیلد `randao_reveal` یک مقدار تصادفی قابل تأیید را می گیرد که پیشنهاد دهنده بلوک، با امضا کردن شماره ایپوک فعلی ایجاد می کند. `eth1_data` رأیی است برای دیدگاه پیشنهاددهنده بلوک در مورد قرارداد سپرده، از جمله ریشه درخت سپرده Merkle و تعداد کل سپردههایی که امکان تأیید سپردههای جدید را فراهم میکنند. `graffiti` یک فیلد اختیاری است که میتوان از آن برای افزودن پیام به بلوک استفاده کرد. `slashings_proposer` و `attester_slashings` فیلدهایی هستند که حاوی اثباتی هستند که نشان میدهد اعتبارسنجهای خاصی طبق دیدگاه پیشنهاددهنده از زنجیره، تخطیهای قابل تنبیه را مرتکب شدهاند. `deposits`لیستی از سپردههای اعتبارسنج جدید است که پیشنهاددهنده بلوک از آن آگاه است، و `voluntary_exits` لیستی از اعتبارسنجهایی است که قصد خروج دارند و پیشنهاددهنده بلوک از طریق شبکه شایعه لایه اجماع از آن مطلع شده است. `sync_aggregate` یک بردار است که نشان میدهد کدام اعتبارسنجها قبلاً به یک کمیته همگامسازی (زیرمجموعهای از اعتبارسنجها که دادههای کاربر سبک را ارائه میدهند) اختصاص داده شدهاند و در امضای دادهها شرکت کردهاند.
+
+`execution_payload` امکان انتقال اطلاعات در مورد تراکنشها بین کاربرهای اجرا و اجماع را فراهم میکند. `execution_payload` بلوکی از دادههای اجرایی است که در داخل یک بلوک بیکن قرار میگیرد. فیلدهای داخل `execution_payload` ساختار بلوک مشخص شده در یلو پیپر اتریوم را منعکس میکنند، با این تفاوت که هیچ Ommer وجود ندارد و `prev_randao` به جای `difficulty` وجود دارد. کاربر اجرا به یک استخر محلی از تراکنشهایی که دربارهاش در شبکه شایعه خود شنیده است، دسترسی دارد. این تراکنشها به صورت محلی اجرا میشوند تا یک درخت حالت بهروز شده به نام پسا-حالت تولید کنند. تراکنشها به عنوان یک لیست به نام `transactions` در `execution_payload` گنجانده شدهاند و پسا-حالت در فیلد `state-root` ارائه شده است.
+
+همه این دادهها در یک بلوک بیکن جمعآوری میشوند، امضا میشوند و برای همتایان پیشنهادکننده بلوک پخش میشوند، که آنها آن را به همتایان خود و غیره منتشر میکنند.
+
+درباره [آناتومی بلوک ها](/developers/docs/blocks) بیشتر بخوانید.
+
+## چه اتفاقی برای بلوک می افتد؟ {#what-happens-to-blocks}
+
+بلوک به پایگاه داده محلی پیشنهاددهنده بلوک اضافه میشود و از طریق شبکه شایعه لایه اجماع به همتایان پخش میشود. هنگامی که یک اعتبارسنج بلوک را دریافت میکند، دادههای داخل آن را تأیید میکند، از جمله بررسی اینکه بلوک والد صحیحی دارد، مربوط به اسلات صحیح است، شاخص پیشنهاددهنده مورد انتظار است، آشکارسازی RANDAO معتبر است و پیشنهاددهنده تنبیه نشده است. `execution_payload` باز میشود و کاربر اجرای اعتبارسنج تراکنشها را در لیست مجدداً اجرا میکند تا تغییر حالت پیشنهادی را بررسی کند. با فرض اینکه بلوک تمام این بررسیها را پاس کند، هر اعتبارسنج بلوک را به زنجیره اصلی خود اضافه میکند. سپس این فرآیند در اسلات بعدی دوباره شروع می شود.
+
+## پاداشهای بلوک {#block-rewards}
+
+پیشنهاددهنده بلوک برای کار خود پاداش دریافت میکند. یک پاداش پایه `base_reward` وجود دارد که به عنوان تابعی از تعداد اعتبارسنجهای فعال و ماندههای مؤثر آنها محاسبه میشود. سپس پیشنهاد دهنده بلوک کسری از `پایه_پاداش` را برای هر تصدیق معتبر موجود در بلوک دریافت می کند. هرچه اعتبارسنجهای بیشتری بلوک را تصدیق کنند، پاداش پیشنهاد دهنده بلوک بیشتر است. همچنین پاداشی برای گزارش اعتبارسنجهایی که باید تنبیه شوند وجود دارد که برابر با `1/512 * مانده مؤثر` برای هر اعتبارسنج تنبیه شده است.
+
+[ اطلاعات بیشتر در مورد پاداشها و مجازاتها](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
+
+## بیشتر بخوانید {#further-reading}
+
+- [مقدمهای بر بلوکها](/developers/docs/blocks/)
+- [مقدمهای بر اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+- [مشخصات اجماع اتریوم](https://github.com/ethereum/consensus-specs)
+- [مقدمهای بر Gasper](/developers/docs/consensus-mechanisms/pos/)
+- [ارتقای اتریوم](https://eth2book.info/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
new file mode 100644
index 00000000000..0153525196d
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
@@ -0,0 +1,172 @@
+---
+title: سوالات متداول
+description: سوالات متداول درباره اثبات سهام اتریوم.
+lang: fa
+---
+
+## اثبات سهام چیست؟ {#what-is-proof-of-stake}
+
+اثبات سهام دسته ای از الگوریتم است که میتواند با اطمینان از اینکه داراییهای با ارزش توسط مهاجمان متخلف از دست میروند، امنیت را برای بلاکچینها فراهم کند. سیستمهای اثبات سهام به مجموعهای از اعتبارسنجها نیاز دارند تا برخی از داراییها را در دسترس قرار دهند که در صورت مشارکت اعتبارسنج در برخی رفتارهای قابل اثبات نادرست، قابل نابودی باشد. اتریوم از مکانیسم اثبات سهام برای ایمنسازی بلاکچین خود استفاده میکند.
+
+## اثبات سهام چگونه با اثبات کار مقایسه می شود؟ {#comparison-to-proof-of-work}
+
+هم اثبات کار و هم اثبات سهام مکانیسمهایی هستند که از نظر اقتصادی مانع از اسپم کردن یا کلاهبرداری در شبکه توسط طرفهای مخرب میشوند. در هر دو مورد، گرههایی که به طور فعال در اجماع شرکت میکنند، برخی از داراییها را "وارد شبکه" میکنند که در صورت رفتار نادرست از دست خواهند داد.
+
+در اثبات کار، این دارایی انرژی است. گره، که به عنوان استخراجگر شناخته میشود، الگوریتمی را اجرا میکند که هدف آن محاسبه یک مقدار به شکل سریعتر از هر گره دیگر است. سریعترین گره حق پیشنهاد یک بلوک به زنجیره را دارد. برای تغییر تاریخچه زنجیره یا تسلط بر پیشنهاد بلوک، یک استخراجگر باید به قدری قدرت محاسباتی داشته باشد که همیشه برنده مسابقه شود. این کار بسیار پرهزینه و اجرای آن دشوار است و از زنجیره در برابر حملات محافظت می کند. انرژی مورد نیاز برای "استخراج" با استفاده از اثبات کار یک دارایی واقعی است که استخراجگرها برای آن هزینه میکنند.
+
+اثبات سهام نیاز دارد گرههایی که به عنوان اعتبارسنج شناخته میشوند، یک دارایی رمزنگاری را به طور صریح به یک قرارداد هوشمند ارسال کنند. اگر یک اعتبارسنج رفتار نادرستی داشته باشد، این ارز رمزنگاری قابل نابودی است زیرا آنها داراییهای خود را به طور مستقیم در زنجیره "سهام گذاری" میکنند نه به طور غیرمستقیم از طریق مصرف انرژی.
+
+اثبات کار بسیار انرژیبرتر است زیرا در فرآیند استخراج برق مصرف میشود. از سوی دیگر، اثبات سهام فقط به مقدار بسیار کم انرژی نیاز دارد - اعتبارسنجهای اتریوم حتی میتوانند روی دستگاه کم مصرفی مانند Raspberry Pi اجرا شوند. مکانیسم اثبات سهام اتریوم در مقایسه با اثبات کار امنتر تلقی میشود زیرا هزینه حمله بیشتر است و عواقب آن برای مهاجم شدیدتر است.
+
+اثبات کار در مقابل اثبات سهام، موضوعی بحث برانگیز است. [وبلاگ ویتالیک بوترین](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) و مناظره بین جاستین دریک و لین آلدن خلاصه خوبی از استدلال ها ارائه می دهد.
+
+
+
+## آیا اثبات سهام انرژی کم مصرف میکند؟ {#is-pos-energy-efficient}
+
+بله. گرههای موجود در یک شبکه اثبات سهام، مقدار بسیار کمی انرژی مصرف میکنند. یک مطالعه طرف ثالث نتیجه گرفت که کل شبکه اتریوم اثبات سهام حدود 0.0026 تروات ساعت در سال مصرف میکند - تقریباً 13000 برابر کمتر از مصرف انرژی بازیهای ویدیویی تنها در ایالات متحده.
+
+[اطلاعات بیشتر در مورد مصرف انرژی اتریوم](/energy-consumption/).
+
+## آیا اثبات سهام امن است؟ {#is-pos-secure}
+
+اثبات سهام اتریوم بسیار امن است. این مکانیسم، قبل از اینکه به مرحله اجرا برسد، به مدت هشت سال به شدت مورد تحقیق، توسعه و آزمایش قرار گرفت. ضمانتهای امنیتی آن، متفاوت از بلاک چینهای اثبات کار است. در اثبات سهام، اعتبارسنجهای مخرب میتوانند به طور فعال مجازات شوند ("اسلش شده") و از مجموعه اعتبارسنجها اخراج شوند که منجر به از دست دادن مقدار قابل توجهی اتریوم میشود. در اثبات کار، یک مهاجم میتواند تا زمانی که قدرت هش کافی دارد، به تکرار حمله خود ادامه دهد. همچنین انجام حملات معادل بر روی اتریوم اثبات سهام نسبت به اثبات کار هزینه بیشتری دارد. برای تأثیرگذاری بر زنده بودن زنجیره، حداقل 33 درصد از کل اتر سهامگذاری شده در شبکه لازم است (به جز در موارد حملات بسیار پیچیده با احتمال موفقیت بسیار کم). برای کنترل محتوای بلوکهای آینده، حداقل 51 درصد از کل اتریوم سهامگذاری شده لازم است، و برای بازنویسی تاریخچه، بیش از 66 درصد از کل اتریوم سهامگذاری شده لازم است. پروتکل اتریوم این داراییها را در سناریوهای حمله 33% یا 51% از بین میبرد و در سناریوی حمله 66% با اجماع اجتماعی نابود میکند.
+
+- [اطلاعات بیشتر در مورد دفاع از اثبات سهام اتریوم در برابر مهاجمان](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
+- [در مورد طراحی اثبات سهام بیشتر بدانیم](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
+
+## آیا اثبات سهام باعث میشود اتریوم ارزانتر شود؟ {#does-pos-make-ethereum-cheaper}
+
+خیر. هزینه ارسال یک تراکنش (کارمزد گس) توسط یک بازار کارمزد پویا تعیین میشود که با افزایش تقاضای شبکه افزایش مییابد. مکانیسم اجماع به طور مستقیم روی این موضوع تأثیر نمیگذارد.
+
+[در مورد گس بیشتر بدانیم](/developers/docs/gas).
+
+## گره ها، کاربرها و اعتبارسنجها چه هستند؟ {#what-are-nodes-clients-and-validators}
+
+گرهها کامپیوترهایی هستند که به شبکه اتریوم متصلاند. کاربرها نرمافزارهایی هستند که روی کامپیوتر اجرا میشوند و آن را به یک گره تبدیل میکنند. دو نوع کلاینت وجود دارد: کاربر اجرایی و کاربر اجماع. هر دو برای ایجاد یک گره ضروری هستند. اعتبارسنج یک افزونه اختیاری برای یک کاربر اجماع است که به گره اجازه میدهد در اجماع اثبات سهام شرکت کند. این به معنای ایجاد و پیشنهاد بلوکها هنگام انتخاب شدن و تصدیق بلوکهایی است که در مورد آنها در شبکه شنیده میشود. برای اجرای یک اعتبارسنج، اپراتور گره باید 32 اتریوم را به قرارداد سپرده واریز کند.
+
+- [اطلاعات بیشتر در مورد گرهها و کاربرها](/developers/docs/nodes-and-clients)
+- [اطلاعات بیشتر درباره سهامگذاری](/staking)
+
+## آیا اثبات سهام ایده جدیدی است؟ {#is-pos-new}
+
+خیر. یک کاربر در بیت کوین تاک در سال 2011 [ایده اصلی اثبات سهام](https://bitcointalk.org/index.php?topic=27787.0) را به عنوان ارتقاء برای بیت کوین پیشنهاد کرد. یازده سال طول کشید تا برای اجرا در شبکه اصلی اتریوم آماده شود. برخی زنجیرههای دیگر، اثبات سهام را زودتر از اتریوم اجرا کردند، اما مکانیسم خاص اتریوم (به نام Gasper) را اجرا نکردند.
+
+## ویژگی خاص اثبات سهام اتریوم چیست؟ {#why-is-ethereum-pos-special}
+
+مکانیسم اثبات سهام اتریوم در طراحی منحصر به فرد است. این اولین مکانیسم اثبات سهام طراحی و اجرا شده نبود، اما قویترین آنها است. مکانیسم اثبات سهام با نام "Casper" شناخته میشود. Casper تعریف میکند که چگونه اعتبارسنجها برای پیشنهاد بلوکها انتخاب میشوند، تصدیقها چگونه و چه زمانی ایجاد میشوند، تصدیقها چگونه شمارش میشوند، پاداشها و جریمههای داده شده به اعتبارسنجها، شرایط تنبیه، مکانیسمهای شکست ایمنی مانند نشت عدم فعالیت و شرایط برای "قطعی بودن" چگونه تعیین میشود. قطعی بودن شرایطی است که برای اینکه یک بلوک به عنوان بخشی دائمی از زنجیره اصلی در نظر گرفته شود، باید توسط حداقل 66 درصد از کل اتریوم سهام گذاری شده در شبکه تأیید شده باشد. محققان Casper را به طور خاص برای اتریوم توسعه دادند و اتریوم اولین و تنها بلاکچینی است که آن را اجرا کرده است.
+
+علاوه بر Casper، اثبات سهام اتریوم از یک الگوریتم انتخاب فورک به نام LMD-GHOST استفاده میکند. این در صورتی لازم است که شرایطی ایجاد شود که دو بلوک برای یک اسلات وجود داشته باشد. این، دو فورک از بلاک چین ایجاد می کند. LMD-GHOST آن بلوکی را انتخاب میکند که بیشترین "وزن" تصدیقها را دارد. وزن تعداد تصدیقهایی است که با مانده مؤثر اعتبارسنجها وزندهی شده است. LMD-GHOST مختص اتریوم است.
+
+ترکیب Casper و LMD_GHOST به عنوان Gasper شناخته میشود.
+
+[اطلاعات بیشتر درمورد Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)
+
+## اسلشینگ (جریمه) چیست؟ {#what-is-slashing}
+
+اسلَشینگ اصطلاحی است که به نابودی بخشی از سهام یک ولیداعتبارسنج و اخراج اعتبارسنج از شبکه اطلاق میشود. مقدار اتریوم از دست رفته در یک اسلَشینگ با تعداد اعتبارسنجهای اسلَش شده مقیاس میشود - این بدان معنی است که اعتبارسنجهای همدست شدیدتر مجازات میشوند.
+
+[اطلاعات بیشتر درباره اسلَشینگ](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing)
+
+## چرا اعتبارسنجها به 32 اتریوم نیاز دارند؟ {#why-32-eth}
+
+اعتبارسنجها باید اتریوم را سهام گذاری کنند تا در صورت رفتار نادرست چیزی برای از دست دادن داشته باشند. دلیل اینکه آنها دقیقاً باید 32 اتریوم استیک کنند این است که به گرهها اجازه میدهد روی سختافزار متوسط اجرا شوند. اگر حداقل اتریوم برای هر اعتبارسنج کمتر بود، تعداد اعتبارسنجها و در نتیجه تعداد پیامهایی که باید در هر اسلات پردازش شوند افزایش مییافت، به این معنی که سختافزار قدرتمندتری برای اجرای یک گره مورد نیاز بود.
+
+## اعتبارسنجها چگونه انتخاب می شوند؟ {#how-are-validators-selected}
+
+یک اعتبارسنج واحد به صورت شبهتصادفی برای پیشنهاد یک بلوک در هر اسلات با استفاده از الگوریتمی به نام RANDAO انتخاب میشود که یک هش از پیشنهاددهنده بلوک را با یک بذر که در هر بلوک بهروز میشود، ترکیب میکند. این مقدار برای انتخاب یک اعتبارسنج خاص از کل مجموعه اعتبارسنجها استفاده میشود. انتخاب اعتبارسنج دو ایپوک پیشتر، تثبیت میشود.
+
+[اطلاعات بیشتر در مورد انتخاب اعتبارسنج](/developers/docs/consensus-mechanisms/pos/block-proposal)
+
+## استیک گرایندینگ چیست؟ {#what-is-stake-grinding}
+
+استیک گرایندینگ نوعی حمله به شبکههای اثبات سهام است که در آن مهاجم تلاش میکند الگوریتم انتخاب اعتبارسنج را به نفع اعتبارسنجهای خود تحت تاثیر قرار دهد. حملات استیک گرایندینگ به RANDAO تقریباً به نصف کل اتریوم سهام گذاری شده نیاز دارند.
+
+[اطلاعات بیشتر درمورد استیک گرایندینگ](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability)
+
+## اسلشینگ اجتماعی چیست؟ {#what-is-social-slashing}
+
+اسلشینگ اجتماعی، توانایی جامعه برای هماهنگی یک فورک بلاک چین در پاسخ به یک حمله است. این امکان را به جامعه میدهد تا از نهایی شدن یک زنجیره نادرست توسط مهاجم بازیابی شود. اسلشینگ اجتماعی همچنین میتواند علیه حملات سانسور به کار رود.
+
+- [اطلاعات بیشتر درباره اسلشینگ اجتماعی](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7)
+- [نظر ویتالیک بوترین در مورد اسلشینگ اجتماعی](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
+
+## آیا من جریمه خواهم شد؟ {#will-i-get-slashed}
+
+به عنوان یک اعتبارسنج، جریمه شدن بسیار دشوار است مگر اینکه عمداً در رفتار مخرب شرکت کنید. جریمه فقط در سناریوهای بسیار خاصی اعمال میشود که در آن اعتبارسنجها چندین بلوک برای یک اسلات پیشنهاد میدهند یا با تصدیقهای خود تناقض دارند - این موارد به ندرت به صورت تصادفی رخ میدهند.
+
+[اطلاعات بیشتر درباره شرایط جریمه شدن](https://eth2book.info/altair/part2/incentives/slashing)
+
+## مشکل هیچ-سهامی چیست؟ {#what-is-nothing-at-stake-problem}
+
+مشکل هیچ-سهامی یک موضوع مفهومی با برخی مکانیسم های اثبات سهام است که در آن فقط پاداش وجود دارد و هیچ مجازاتی وجود ندارد. اگر چیزی در سهام نباشد، یک اعتبارسنج عملگرا به همان اندازه خوشحال است که هر یا حتی چند شاخه از بلاک چین را تأیید کند، زیرا این کار باعث افزایش پاداش او می شود. اتریوم با استفاده از شرایط نهایی و جریمه شدن، برای تضمین یک زنجیره متعارف، این موضوع را دور میزند.
+
+[جزئیات بیشتر درباره هیچ-سهامی](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
+
+## الگوریتم انتخاب فورک چیست؟ {#what-is-a-fork-choice-algorithm}
+
+یک الگوریتم انتخاب فورک قوانینی را اجرا میکند که تعیین میکنند کدام زنجیره، زنجیره اصلی است. در شرایط ایدهآل، نیازی به قانون انتخاب فورک نیست زیرا در هر اسلات فقط یک پیشنهاددهنده بلوک وجود دارد و تنها یک بلوک برای انتخاب وجود دارد. با این حال، گاهی اوقات، بلوکهای چندگانه برای یک اسلات یا اطلاعات دیررس منجر به گزینههای متعدد برای سازماندهی بلوکها نزدیک به سر زنجیره میشود. در این موارد، همه کاربرها باید برخی قوانین را به طور یکسان اجرا کنند تا مطمئن شوند که همه آنها توالی صحیح بلوکها را انتخاب میکنند. الگوریتم انتخاب فورک این قوانین را کدگذاری میکند.
+
+الگوریتم انتخاب فورک اتریوم LMD-GHOST نام دارد. این، فورکی را انتخاب میکند که بیشترین وزن تصدیقها را دارد، به این معنی که اکثر اتریوم سهامگذاری شده برای آن رای داده است.
+
+[اطلاعات بیشتر درباره LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice)
+
+## نهایی شدن در اثبات سهام چیست؟ {#what-is-finality}
+
+نهایی شدن در اثبات سهام تضمینی است که یک بلوک مشخص بخشی دائمی از زنجیره اصلی است و نمیتوان آن را برگرداند، مگر اینکه یک شکست اجماع رخ دهد که در آن یک مهاجم ۳۳ درصد از کل اتریوم سهامگذاری شده را بسوزاند. این نهایی شدن "اقتصاد رمزنگاری" است، در مقابل "نهایی شدن احتمالی" که مربوط به بلاک چین های اثبات کار است. در نهایی شدن احتمالی، هیچ حالت مشخصی برای بلوکهای نهاییشده/غیر نهاییشده وجود ندارد - به سادگی احتمال حذف یک بلوک از زنجیره با قدیمیتر شدن آن کمتر و کمتر میشود و کاربران خودشان تعیین میکنند که چه زمانی به اندازه کافی مطمئن هستند که یک بلوک "امن" است. با نهایی شدن اقتصاد رمزنگاری، جفتهای بلوک نقطه بررسی باید ۶۶ درصد از آرای اتریوم سهامگذاری شده را دریافت کنند. اگر این شرط برآورده شود، بلوکهای بین آن نقاط بررسی به طور صریح "نهایی شده" هستند.
+
+[اطلاعات بیشتر درباره نهایی شدن](/developers/docs/consensus-mechanisms/pos/#finality)
+
+## "سویهگیری ضعیف" چیست؟ {#what-is-weak-subjectivity}
+
+سویهگیری ضعیف ویژگی شبکههای اثبات سهام است که در آن از اطلاعات اجتماعی برای تایید وضعیت فعلی بلاکچین استفاده میشود. گرههای جدید یا گرههایی که پس از مدت طولانی آفلاین بودن به شبکه بازمیگردند میتوانند یک وضعیت اخیر دریافت کنند تا گره بتواند بلافاصله ببیند که آیا روی زنجیره صحیح است یا خیر. این حالتها به عنوان "نقاط بررسی سویهگیری ضعیف" شناخته میشوند و میتوان آنها را از اپراتورهای گره دیگر خارج از باند، یا از کاوشگرهای بلوک یا از چندین نقطه انتهایی عمومی دریافت کرد.
+
+[اطلاعات بیشتر درباره سویهگیری ضعیف](/developers/docs/consensus-mechanisms/pos/weak-subjectivity)
+
+## آیا اثبات سهام در برابر سانسور مقاوم است؟ {#is-pos-censorship-resistant}
+
+در حال حاضر اثبات مقاومت در برابر سانسور سخت است. با این حال، بر خلاف اثبات کار، اثبات سهام گزینه ای را برای هماهنگ کردن جریمهها برای مجازات اعتبارسنجهای سانسورکننده ارائه می دهد. تغییراتی در پروتکل در حال انجام است که سازندههای بلوک را از پیشنهاددهندگان بلوک جدا میکند و لیستی از تراکنشهایی را اجرا میکند که سازندهها باید در هر بلوک بگنجانند. این پیشنهاد با نام جداسازی سازنده مناسب شناخته میشود و به جلوگیری از سانسور تراکنشها توسط اعتبارسنجها کمک میکند.
+
+[اطلاعات بیشتر درباره جداسازی پیشنهاددهنده-سازنده](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
+
+## آیا سیستم اثبات سهام اتریوم میتواند مورد حمله ۵۱ درصدی قرار گیرد؟ {#pos-51-attack}
+
+بله. اثبات سهام مانند اثبات کار در برابر حملات ۵۱ درصدی آسیبپذیر است. به جای اینکه مهاجم به ۵۱ درصد قدرت هش شبکه نیاز داشته باشد، مهاجم به ۵۱ درصد کل اتریوم استیک شده نیاز دارد. مهاجمی که ۵۱ درصد از کل استیک را جمعآوری میکند، میتواند الگوریتم انتخاب فورک را کنترل کند. این به مهاجم اجازه میدهد تا تراکنشهای خاصی را سانسور کند، بازآراییهای کوتاهمدت انجام دهد و با مرتب کردن مجدد بلوکها به نفع خود، MEV را استخراج کند.
+
+[جزئیات بیشتر درباره حملات به اثبات سهام](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
+
+## هماهنگی اجتماعی چیست و چرا به آن نیاز داریم؟ {#what-is-social-coordination}
+
+هماهنگی اجتماعی آخرین خط دفاعی برای اتریوم است که امکان بازیابی یک زنجیره صادقانه از یک حمله که بلوکهای نادرست را نهایی کرده است، فراهم میکند. در این حالت، جامعه اتریوم باید به صورت "خارج از باند" هماهنگ شود و توافق کند که از یک فورک اقلیت صادقانه استفاده کند و در این فرآیند اعتبارسنجهای مهاجم را جریمه کند. برای این کار همچنین لازم است برنامهها و صرافیها نیز فورک صادقانه را تشخیص دهند.
+
+[اطلاعات بیشتر درباره هماهنگی اجتماعی](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
+
+## آیا ثروتمندان در اثبات سهام ثروتمندتر میشوند؟ {#do-rich-get-richer}
+
+یک نفر هر چه اتریوم بیشتری برای سهامگذاری داشته باشد، میتواند اعتبارسنجهای بیشتری اجرا کند و پاداش بیشتری کسب کند. پاداشها به صورت خطی با مقدار اتریوم سهام گذاری شده مقیاسبندی میشوند و همه بازده درصد یکسانی دریافت میکنند. اثبات کار ثروتمندان را بیشتر از اثبات سهام غنی میکند زیرا استخراجگرهای ثروتمندتری که سختافزار را در مقیاس خریداری میکنند از صرفه جویی در مقیاس هم بهرهمند میشوند، به این معنی که رابطه بین ثروت و پاداش غیرخطی است.
+
+## آیا اثبات سهام نسبت به اثبات کار متمرکزتر است؟ {#is-pos-decentralized}
+
+خیر، اثبات کار به سمت تمرکز گرایش دارد زیرا هزینههای استخراج افزایش مییابد و افراد را حذف میکند، سپس شرکتهای کوچک را حذف میکند و به همین ترتیب. مشکل فعلی اثبات سهام تاثیر مشتقات سهام گذاری شناور (LSDها) است. اینها توکنهایی هستند که نشاندهنده اتریوم سهام گذاری شده توسط برخی ارائه دهندگان هستند که هر کس میتواند آنها را بدون باز کردن سهام گذاری اتریوم واقعی در بازارهای ثانویه معامله کند. LSDها به کاربران اجازه میدهند تا با کمتر از ۳۲ اتریوم سهام گذاری کنند، اما آنها همچنین خطر تمرکززدایی را ایجاد میکنند که در آن چند سازمان بزرگ میتوانند در نهایت بخش زیادی از سهام را کنترل کنند. به همین دلیل است که [سهام گذاری انفرادی](/staking/solo) بهترین گزینه برای اتریوم است.
+
+[اطلاعات بیشتر در مورد تمرکز سهام در LSD ها](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
+
+## چرا من فقط میتوانم ETH را سهام گذاری کنم؟ {#why-can-i-only-stake-eth}
+
+ETH ارز مربوط به اتریوم است. ضروری است که یک ارز واحد وجود داشته باشد که همه سهامها بر اساس آن تعیین میشوند، هم برای حسابداری ماندههای مؤثر برای وزندهی آرا و هم برای امنیت. خود ETH یک جزء اساسی اتریوم است نه یک قرارداد هوشمند. درج ارزهای دیگر به طور قابل توجه پیچیدگی را افزایش داده و امنیت سهام گذاری را کاهش میدهد.
+
+## آیا اتریوم تنها بلاک چین اثبات سهام است؟ {#is-ethereum-the-only-pos-blockchain}
+
+خیر، چندین بلاک چین اثبات سهام وجود دارد. هیچ کدام با اتریوم یکسان نیستند؛ مکانیسم اثبات سهام اتریوم منحصر به فرد است.
+
+## ادغام چیست؟ {#what-is-the-merge}
+
+ادغام زمانی بود که اتریوم مکانیسم اجماع مبتنی بر اثبات کار خود را خاموش و مکانیسم اجماع مبتنی بر اثبات سهام خود را روشن کرد. ادغام در ۱۵ سپتامبر ۲۰۲۲ اتفاق افتاد.
+
+[اطلاعات بیشتر دربارهی ادغام](/roadmap/merge)
+
+## زنده بودن و ایمنی چه هستند؟ {#what-are-liveness-and-safety}
+
+زنده بودن و ایمنی دو نگرانی اساسی امنیتی برای یک بلاک چین هستند. زنده بودن به معنای در دسترس بودن یک زنجیره نهایی شده است. اگر زنجیره متوقف شود یا کاربران نتوانند به راحتی به آن دسترسی پیدا کنند، اینها زنده بودنهای ناموفق هستند. هزینه بسیار بالای دسترسی نیز میتواند به عنوان یک عدم موفقیت زنده بودن در نظر گرفته شود. ایمنی به این اشاره دارد که حمله به زنجیره چقدر دشوار است - یعنی نهایی کردن نقاط کنترل متناقض.
+
+[اطلاعات بیشتر را در مقاله Casper مطالعه کنید](https://arxiv.org/pdf/1710.09437.pdf)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
new file mode 100644
index 00000000000..6f4a1654013
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
@@ -0,0 +1,52 @@
+---
+title: گاسپر
+description: توضیح در رابطه با مکانیزم اثبات سهام Gasper.
+lang: fa
+---
+
+Gasper ترکیبی از گجت قطعیت دوستانه (Casper-FFG) و الگوریتم انتخاب فورک LMD-GHOST است. این دو جزء باهم، مکانیزم اجماع را تشکیل می دهند و اثبات سهام اتریوم را امن میکنند. Casper مکانیزمی است که بلوک های مشخص را تا قطعیت ارتقا میدهد تا شرکتکنندگان جدید شبکه بتوانند از همگام بودن با زنجیره اصلی مطمئن شوند. الگوریتم انتخاب فورک از آرای انباشته شده برای مطمئن شدن از انتخاب راحت و درست در زمان به وجود آمدن فورک در زنجیره بلوکی استفاده میکند.
+
+**توجه کنید** که تعریف اصلی Casper-FFG برای ادغام شدن در Gasper مقداری به روز شد. در این صفحه ما تعریف بهروز شده را درنظر میگیریم.
+
+## پیشنیاز ها
+
+برای درک این مطلب، واجب است تا صفحه مقدمه در [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) را بخوانید.
+
+## نقش Gasper {#role-of-gasper}
+
+Gasper در بالای اثبات سهام زنجیره بلوکی، جایی که گرهها Ether را به عنوان سپردهای تهیه میکنند که قابل تخریب یا تنبل یا ناراست در پیشنهاد معتبر ساختن است مینشیند. Gasper مکانیزمی است که تعریف میکند چگونه اعتبارسنج ها مجازات یا پاداش داده خواهند شد، و کدام بلوک ها پذیرفته و کدام رد، و کدام فورک زنجیره بلوکی بر روی آن ساخته میشود.
+
+## قطعیت چسیت؟ {#what-is-finality}
+
+قطعیت بخشی از بلوک ها است که نمیتوانند برگرداننده شوند مگر بخاطر وفاق بحرانی و زمانی که مهاجمی حداقل 1/3 کل اترهای انباشته شده را نابود میکند. قطعیت بلوک ها به معنی بخشی از اطلاعات است که زنجیره بلوکی درباره آن ها مطمئن است. یک بلوک باید از یک روند دو مرحلهای ارتقا عبور کند تا بتواند قطعی شود:
+
+1. دو-سوم اتر سهام گذاری شده باید به نفع آن بلوک برای پیوستن به زنجیره اصلی رای بدهند. این شرط، بلوک را به مرحله "مشروعیت" ارتقا میدهد. احنمال برگردانی بلوک هایی که به مرحله مشروعیت رسیده باشند، کم است، اما تحت شرایط مشخصی امکانپذیر است.
+2. زمانی که بلوک دیگری در بالای بلوکی دیگر مشروع شود، به مرحله قطعی ارتقا پیدا میکند. قطعی کردن یک بلوک به منزله تعهدی برای اضافه کردن بلوک به زنجیره اصلی است. نمیتواند بازگردانی شود مگر اینکه یک مهاجم میلیون ها اتر (میلیاردها $USD) را از بین ببرد.
+
+این ارتقا بلوک ها در هر اسلات اتفاق نمیافتد. در عوض، تنها بلوک های مرزی ایپوک میتوانند مشروع و قطعی بشوند. این بلوک ها به عنوان "نقاط بررسی" شناخته میشوند. ارتقا نیاز به یک جفت تقطه بررسی دارد. یکی "لینک فوق اکثریت" بین دو نقطه بررسی پیاپی (دو سوم کل اتر سهامگزاری شده باید به درست بودن نقطه بررسی B در برابر A رای دهند) باید وجود داشته باشد تا نقطه بررسی های اخیر را به مرحله قطعیت ارتقا دهد و بلوک را مشروع کند.
+
+زیرا قطعیت نیاز به موافقت حداقل دو-سوم بلوک ها در رابطه با مشروعیت آن دارد، یک مهاجم نمیتواند احتمالا یک نسخه اضافه از زنجیر را بدون موارد زیر قطعی کند:
+
+1. مالکیت یا دستکاری دو-سوم اتر سهامگزاری شده.
+2. نابود کردن حداقل یک-سوم اتر سهامگزاری شده.
+
+شرط اول در صورتی رخ میدهد که دو-سوم اتر سهامگزاری شده برای قطعی کردن زنجیر نیاز باشد. شرط دوم در صورتی پیش میآید چون اگر دو-سوم مجموع سهام به نفع هر دو فورک رای دهند، آن وقت یک-سوم حتما به هر دو رای داده است. جفت رای دادن ها شرایط جریمه درست میکند که به شدت با آن برخورد میشود، و یک-سوم کل سهام از بین خواهد رفت. به طور مثال در می 2022، مهاجم لازم است معادل 10 میلیارد دلار آمریکا اتر بسوزاند. الگوریتمی که در Gasper قطعیت و مشرعیت را بر بلوک اعمال میکند کمی متفاوت از [ Casper از نوع گجت قطعیت دوستانه قطعیت (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) است.
+
+### مشوقها و جریمه {#incentives-and-slashing}
+
+اعتبارسنج ها برای معتبر ساختن صادقانه بلوک ها پاداش دریافت میکنند. اتر به عنوان پاداش به سهام آن ها افزوده خواهد شد. از طرفی دیگر، اعتبارسنج هایی که غایب هستند و در زمان فراخوانی موفق به عمل کردن نمیشوند، پاداش را از دست خواهند داد و گاهی اوقات مقدار کمی از سهام خود را از دست میدهند. با این حال، جریمههای آفلاین بودن ناچیز است و در بیشتر موارد به هزینههای فرصت پاداشهای از دست رفته میرسد. با این حال، انجام برخی از اقدامات اعتبارسنجی به طور تصادفی بسیار دشوار است و اثر مخربی به جا میگذراد، مانند پیشنهاد چندین بلوک برای یک اسلات، تایید چندین بلوک برای یک اسلات، یا مخالفت با آراء نقاط بررسی قبلی. اینها رفتارهای «قابل جریمه» هستند که به شدت جریمه میشوند - این رفتار ها منجر به از بین رفتن بخشی از سهام اعتبارسنج و حذف اعتبارسنج از شبکه اعتباردهندهها میشود. این فرایند 36 روز به طول میانجامد. در روز اول، یک مجازات اولیه تا 1 اتر است. سپس اتر اعتبارسنج جریمه شده به آرامی در طول دوره خروج کم میشود، اما در روز 18، آنها یک "جریمه همبستگی" دریافت میکنند، که وقتی اعتباردهندههای بیشتری در همان زمان جریمه میشوند، بزرگتر میشود. بیشترین مجازات، کل سهام است. این جوایز و جریمهها برای تشویق اعتباردهندگان صادق و بی انگیزه کردن حملات در شبکه طراحی شدهاند.
+
+### نشت عدمفعالیت {#inactivity-leak}
+
+Gasper علاوه بر امنیت، "زنده بودن قابل قبول" را نیز فراهم می کند. این در صورتی است که تا زمانی که دو سوم کل اتر سهاکگذاری شده صادقانه و با پیروی از پروتکل رای بدهد، زنجیره میتواند بدون توجه به هر فعالیت دیگری (مانند حملات، مشکلات تأخیر، یا جریمه ها) قطعی شود. به عبارت دیگر، یک سوم کل اتر سهامگذاری شده باید به نحوی در معرض خطر قرار گیرد تا از نهایی شدن زنجیره جلوگیری شود. در Gasper، یک خط دفاعی اضافی در برابر شکست زنده بودن وجود دارد که به "نشت عدم فعالیت" معروف است. این ساز و کار زمانی فعال می شود که زنجیره برای بیش از چهار دوره نتواند نهایی شود. اعتبارسنجهایی که فعالانه زنجیره اکثریت را تصدیق نمی کنند، سهام آنها به تدریج کم میشود تا زمانی که اکثریت دو سوم کل سهام را به دست آورند، و اطمینان حاصل شود که ناکامیهای زنده بودن فقط موقتی هستند.
+
+### انتخاب فورک {#fork-choice}
+
+تعریف اصلی Casper-FFG شامل یک الگوریتم انتخاب فورک بود که این قانون زیر را دیکته میکرد: `زنجیره ای را که حاوی نقاط بررسی با بیشترین طول است ` که در آن، طول به عنوان بیشترین فاصله از بلوک ایجاد تعریف می شود، دنبال کنید. در Gasper، قانون اصلی انتخاب فورک به نفع یک الگوریتم پیچیدهتر به نام LMD-GHOST منسوخ شده است. درک این نکته مهم است که در شرایط عادی، قانون انتخاب فورک غیرضروری است - برای هر اسلات یک پیشنهاد دهنده بلوک وجود دارد، و اعتبارسنج های صادق آن را تأیید می کنند. تنها در موارد عدم همزمانی شبکه بزرگ یا زمانی که یک پیشنهاد دهنده ناصادق بلوک ایجاد ابهام کرده است که الگوریتم انتخاب فورک مورد نیاز است. با این حال، زمانی که این موارد پیش میآیند، الگوریتم انتخاب فورک یک دفاع حیاتی است که انتخاب زنجیر درست را تضمین میکند.
+
+LMD-GHOST مخفف "جدیدترین درخت فرعی مشاهده شده حریص و سنگین ترین پیام-محور" است. این روشی پیچیده برای تعریف الگوریتمی است که فورکی را با بیشترین وزن انباشته گواهیها بهعنوان نمونه متعارف انتخاب میکند (سنگینترین زیردرخت حریصانه) و اگر چندین پیام از یک اعتبارسنج دریافت شود، فقط آخرین مورد در نظر گرفته میشود (آخرین-پیام محور). قبل از افزودن سنگین ترین بلوک به زنجیره درست خود، هر اعتبارسنج هر بلوک را با استفاده از این قانون ارزیابی می کند.
+
+## اطلاعات بیشتر {#further-reading}
+
+- [Gasper: ترکیبی از GHOST و Casper](https://arxiv.org/pdf/2003.03052.pdf)
+- [Casper، گجت قطعیت دوستانه](https://arxiv.org/pdf/1710.09437.pdf)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
new file mode 100644
index 00000000000..3c6f45b175d
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
@@ -0,0 +1,99 @@
+---
+title: اثبات سهام (PoS)
+description: توضیحی دربارهی پروتکل اجماع اثبات سهام و نقش آن در اتریوم.
+lang: fa
+---
+
+اثبات سهام (PoS) زیربنای [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) اتریوم است. اتریوم در سال ۲۰۲۲ به مکانیزم اثبات سهام خود سوییچ کرد؛ زیرا در مقایسه با معماری [اثبات کار](/developers/docs/consensus-mechanisms/pow) قبلی، امن تر، کم مصرف تر و برای پیادهسازی راهکارهای مقیاسپذیری جدید بهتر است.
+
+## پیشنیازها {#prerequisites}
+
+برای درک بهتر این صفحه، ما پیشنهاد میکنیم ابتدا [مکانیزمهای اجماع](/developers/docs/consensus-mechanisms/) را بخوانید.
+
+## اثبات سهام (PoS) چیست؟ {#what-is-pos}
+
+اثبات سهام راهی برای اثبات این موضوع است که اعتبارسنجها چیزی ارزشمند را در شبکه قرار داده اند که اگر غیر صادقانه عمل کنند، می تواند از بین برود. در اثبات سهام اتریوم، اعتبارسنجها به طور مشخص سرمایه خود را به شکل ETH در یک قرارداد هوشمند بر روی اتریوم سهامگذاری میکنند. اعتبارسنج موظف است بررسی کند که بلوکهایی که در شبکه پخش میشوند معتبر هستند و هر از گاهی خود بلوک جدیدی ساخته و در شبکه پخش کند. اگر آن ها سعی کنند از شبکه کلاهبرداری کنند (برای مثال با پیشنهاد چند بلوک در زمانی که باید یک بلوک را بفرستند یا تصدیق های متناقض ارسال کنند)، برخی ETH های سهام گذاری شده آنها یا همه آنها ممکن است از بین بروند.
+
+## اعتبارسنجها {#validators}
+
+برای شرکت بهعنوان اعتبارسنج، کاربر باید 32 اتر را به قرارداد سپرده واریز کند و سه نرمافزار مجزا را اجرا کند: یک کاربر اجرا، یک کاربر اجماع، و یک کاربر اعتبارسنج. هنگام سپردهگذاری ETHها، کاربر به یک صف فعالسازی میپیوندد که نرخ تعداد اعتبارسنجهایی را که به شبکه میپیوندند محدود میکند. زمانی که اعتبارسنج فعال شد، از همتایان درون شبکه اتریوم بلوکهای جدید را دریافت میکند. تراکنشهای تحویل شده در بلوک مجدداً اجرا میشوند تا بررسی شود که تغییرات پیشنهادی در وضعیت اتریوم معتبر هستند و امضای بلوک بررسی میشود. سپس اعتبارسنج یک رای را (که تصدیق نامیده میشود) بر روی شبکه برای آن بلوک ارسال میکند.
+
+در حالی که در اثبات کار، زمان بلوکها توسط سختی استخراج مشخص میشود، در اثبات سهام نرخ ثبت بلوک ثابت است. در اتریوم اثبات سهام، زمان به اسلاتها (۱۲ ثانیه) و ایپوکها (۳۲ اسلات) تقسیم میشود. یک اعتبارسنج به طور تصادفی برای یک پیشنهادکننده بلوک در هر اسلات انتخاب میشود. این اعتبارسنج مسئول ساختن بلوکهای جدید و فرستادن آن به دیگر گرههای شبکه است. همچنین در هر اسلات، یک کمیته از اعتبارسنجها به طور تصادفی انتخاب میشود، که رایهای آن برای معتبر بودن بلوک پیشنهاد شده استفاده میشود. تقسیم کردن اعتبارسنج در کمیته های ایجاد شده برای قابل مدیریت نگه داشتن بار شبکه مهم است. کمیته ها مجموعه اعتبارسنج را به گونه ای تقسیم می کنند که هر اعتبارسنج فعال در هر ایپوک تصدیق می شود، نه در هر اسلات.
+
+## چگونه یک تراکنش در اتریوم PoS اجرا می شود {#transaction-execution-ethereum-pos}
+
+در ادامه، یک توضیح کامل در مورد نحوه اجرای یک تراکنش در اثبات سهام اتریوم ارائه می شود.
+
+1. کاربر یک [تراکنش](/developers/docs/transactions/) را با کلید خصوصی خود ایجاد و امضا می کند. این کار معمولا توسط یک کیف پول یا یک کتابخانه مانند [ether.js](https://docs.ethers.io/v5/) و [web3js](https://docs.web3js.org/) و [web3py](https://web3py.readthedocs.io/en/v5/) و غیره انجام می شود اما کاربر به صورت پنهانی با استفاده از [JSON-RPC API](/developers/docs/apis/json-rpc/) درخواستی را به یک گره می دهد. کاربر میتواند مقدار گازی که تمایل دارد به عنوان انعام به یک اعتبارسنج پرداخت کند را تعریف کند تا او را تشویق کند تراکنش را در یک بلوک قرار دهد. [انعام](/developers/docs/gas/#priority-fee) در حالی به اعتبارسنج پرداخت می شود که [کارمزد پایه](/developers/docs/gas/#base-fee) سوزانده می شود.
+2. تراکنش به یک [کاربر اجرای](/developers/docs/nodes-and-clients/#execution-client) اتریوم ارسال میشود که اعتبار آن را بررسی می کند. این به معنای اطمینان از این است که فرستنده ETH کافی برای انجام تراکنش دارد و آن را با کلید صحیح امضا کرده است.
+3. اگر تراکنش معتبر باشد، کاربر اجرا آن را به استخر حافظه محلی خود (فهرست تراکنشهای معلق) اضافه میکند و همچنین آن را به گرههای دیگر از طریق شبکه شایعه لایه اجرا پخش میکند. هنگامی که گرههای دیگر در مورد تراکنش میشنوند، آن را به استخر حافظه محلی خود نیز اضافه میکنند. کاربران پیشرفته ممکن است از پخش تراکنش خودداری کنند و در عوض آن را به سازندگان بلوک تخصصی مانند [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview) ارسال کنند. این مورد به آنها اجازه میدهد تا تراکنشها را در بلوکهای آینده برای حداکثر سود سازماندهی کنند ([MEV](/developers/docs/mev/#mev-extraction)).
+4. یکی از گرههای اعتبارسنج در شبکه، پیشنهاددهنده بلوک برای اسلات فعلی است که قبلاً به صورت شبه تصادفی با استفاده از RANDAO انتخاب شده است. این گره مسئول ساخت و پخش بلوک بعدی است که به بلاکچین اتریوم اضافه میشود و وضعیت جهانی را به روز میکند. گره از سه بخش تشکیل شده است: یک کاربر اجرا، یک کاربر اجماع و یک کاربر اعتبارسنج. کاربر اجرا تراکنشها را از استخر حافظه محلی به یک "پی لود اجرا" بسته بندی میکند و آنها را به صورت محلی اجرا میکند تا یک تغییر حالت ایجاد کند. این اطلاعات به مشتری اجماع منتقل میشود که در آن پی لود اجرا به عنوان بخشی از یک "بلوک بیکون" رپد میشود که همچنین حاوی اطلاعاتی در مورد پاداشها، جریمهها، اسلشینگها، تصدیق ها و غیره است که شبکه را قادر میسازد بر روی توالی بلوکها در سر زنجیره توافق کند. ارتباط بین کاربران اجرا و اجماع با جزئیات بیشتر در [اتصال کاربران توافق و اجرا](/developers/docs/networking-layer/#connecting-clients) توضیح داده شده است.
+5. گرههای دیگر، بلوک بیکن جدید را در شبکه شایعه لایه اجماع دریافت میکنند. آنها آن را به کاربر اجرای خود ارسال میکنند که در آن تراکنشها به صورت محلی مجدداً اجرا میشوند تا اطمینان حاصل شود که تغییر حالت پیشنهادی معتبر است. سپس کاربر اعتبارسنج تأیید میکند که بلوک معتبر و در دید آنها از زنجیره، بلوک منطقی بعدی است (به این معنی است که بر روی زنجیره ای با بیشترین حجم از تأییدیه ها ساخته میشود که در [قوانین انتخاب فورک](/developers/docs/consensus-mechanisms/pos/#fork-choice) تعریف شده). بلوک مدنظر، در دیتابیس محلی هر گره که آن را تأیید کند اضافه میشود.
+6. اگر تراکنش بین دو نقطه بررسی با "پیوند اکثریت مطلق" بخشی از یک زنجیره شود، می تواند "نهایی شده" در نظر گرفته شود. نقاط بررسی در آغاز هر ایپوک اتفاق میافتد و آنها برای توضیح این واقعیت وجود دارند که فقط یک زیرمجموعه از اعتبارسنجهای فعال در هر اسلات تأییدیه ارائه میدهند، اما تمام اعتبارسنجهای فعال در طول هر ایپوک تأییدیه میدهند. از این رو، تنها بین ایپوکها است که میتوان یک "پیوند اکثریت مطلق" را نشان داد (این جایی است که 66% از همه ETH های استیک شده بر روی شبکه روی دو نقطه بررسی توافق میکنند).
+
+جزئیات بیشتر در مورد قطعیت را در زیر ملاحظه میکنید.
+
+## قطعیت {#finality}
+
+یک تراکنش در شبکه توزیعشده زمانی «قطعیت» دارد که عضوی از بلوکی باشد که نتوان با مصرف کردن میزان قابلتوجهی ETH آن را عوض کرد. در اتریومِ اثبات سهام، این موضوع با استفاده از بلوکهای «نقطه بررسی» مدیریت میشود. اولین بلوک در هر ایپوک یک نقطه بررسی است. اعتبارسنجها به جفت نقطههای بررسی که معتبر میدانند رأی میدهند. اگر یک جفت نقطه بررسی رأی نماینده دستکم دو سوم کل ETH سهامگذاریشده را داشته باشد، نقطههای بررسی ارتقا پیدا میکنند. هر کدام که متأخرتر باشد (هدف) «موجه» در نظر گرفته میشود. آن یکی که قدیمیتر است موجه در نظر گرفته شده است چون «هدف» ایپوک قبلی بوده است. حالا وضعیت آن به «نهاییشده» ارتقا یافته است.
+
+برای برگرداندن یک بلوک نهایی، یک مهاجم متعهد میشود که حداقل یکسوم از کل عرضه ETH سهامگذاریشده را از دست بدهد. دلیل دقیق این موضوع [در این پست وبلاگ بنیاد اتریوم](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) توضیح داده شده است. از آنجا که نهایی شدن نیاز به اکثریت دو سوم دارد، مهاجم میتواند از طریق رأی دادن با یکسوم کل سهام، از نهایی شدن شبکه جلوگیری کند. ساز و کاری برای دفاع در برابر این موضوع وجود دارد: [نشت عدم فعالیت](https://eth2book.info/bellatrix/part2/incentives/inactivity). این ساز و کار هر زمان که زنجیره برای بیش از چهار ایپوک نتواند نهایی شود، فعال میشود. نشت عدم فعالیت، ETH مخاطرهآمیز را از اعتبارسنجهایی که علیه اکثریت رأی میدهند، دور میکند و به اکثریت اجازه میدهد دو سوم اکثریت را دوباره به دست آورند و زنجیره را نهایی کنند.
+
+## امنیت اقتصاد رمزارز {#crypto-economic-security}
+
+اجرای اعتبارسنج یک تعهد است. انتظار میرود اعتبارسنج سختافزار و اتصال کافی به اینترنت را برای مشارکت در اعتبارسنج بلوک و پیشنهاد حفظ کند. در ازای آن، به اعتبارسنج ETH پرداخت میشود (موجودی سهامگذاریشده آن افزایش مییابد). از سوی دیگر، شرکت بهعنوان اعتبارسنج، راههای جدیدی را برای حمله کاربران به شبکه با هدف حصول منافع شخصی یا خرابکاری باز میکند. برای جلوگیری از این امر، اعتبارسنجها در صورت عدم موفقیت در مشارکت هنگام فراخوانی، ETHهای پاداش داده شده را از دست میدهند و در صورت رفتار غیرصادقانه، سهام موجود آنها از بین میرود. دو رفتار اصلی که میتوان آنها را غیرصادقانه در نظر گرفت: پیشنهاد چند بلوک در یک اسلات (مبهمسازی) و ارائه تصدیقهای متناقض.
+
+مقدار ETH که کم میشود به این بستگی دارد که چند اعتبارسنج در آن واحد جریمه می شوند. این را [«جریمه همبستگی»](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) مینامند، و میتواند جزئی باشد (حدود 1% سهام برای یک اعتبارسنج منفرد که مشمول برخورد شدید شود) یا میتواند منجر به از بین رفتن 100% سهام اعتباردهنده شود (جریمه شدید انبوه). برخورد شدید در نیمه راه یک دوره خروج اجباری اعمال میشود که با جریمه فوری (تا 1 اتر) در روز 1، با جریمه همبستگی در روز 18 ادامه مییابد، و در نهایت، با بیرون رانده شدن از شبکه در روز 36 آغاز میشود. آنها هر روز جریمههای جزئی تصدیق دریافت میکنند زیرا در شبکه حضور دارند اما رأی نمیدهند. همهی اینها به این معنی است که یک حمله هماهنگ برای مهاجم بسیار پرهزینه خواهد بود.
+
+## انتخاب فورک {#fork-choice}
+
+هنگامی که شبکه بهطور بهینه و صادقانه عمل میکند، تنها یک بلوک جدید در رأس زنجیره وجود دارد و همه اعتبارسنجها آن را تصدیق میکنند. با این حال، این امکان وجود دارد که اعتبارسنجها به دلیل تأخیر شبکه یا مبهم بودن پیشنهاددهنده بلوک، دیدگاههای متفاوتی نسبت به سر زنجیره داشته باشند. بنابراین، کاربرهای اجماع به یک الگوریتم نیاز دارند تا تصمیم بگیرند کدام یک را ترجیح دهند. الگوریتم مورد استفاده در اثبات سهام اتریوم [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) نام دارد و با شناسایی فورکی که دارای سنگین وزنترین تصدیق در تاریخچه آن است کار میکند.
+
+## اثبات سهام و امنیت {#pos-and-security}
+
+خطر حمله [51%](https://www.investopedia.com/terms/1/51-attack.asp) همچنان در مورد اثبات سهام وجود دارد، همانطور که در اثبات کار وجود دارد، اما برای مهاجمان حتی از این هم خطرناکتر است. یک مهاجم به 51% از ETH سهامگذاریشده نیاز دارد. سپس میتوانستند از تصدیقهای خود استفاده کنند تا اطمینان حاصل کنند که فورک ترجیحی آنها دارای بیشترین تعداد تصدیق است. «وزن» تصدیقهای انباشتهشده همان چیزی است که کاربرهای اجماع برای تعیین زنجیره صحیح استفاده میکنند، بنابراین این مهاجم میتواند فورک خود را به فورک متعارف تبدیل کند. با این حال، نقطه قوت اثبات سهام نسبت به اثبات کار این است که جامعه کاربران آن از امکان تدارک ضدحمله برخوردار است. برای مثال، اعتبارسنجهای صادق میتوانند تصمیم بگیرند که به ساختن زنجیره اقلیت ادامه دهند و فورک مهاجم را نادیده بگیرند و در عین حال برنامهها، صرافیها و استخرها را به انجام همین کار تشویق کنند. آنها همچنین میتوانند تصمیم بگیرند که مهاجم را به زور از شبکه حذف کنند و ETH سهامگذاری شده آن را نابود کنند. اینها دفاعهای اقتصادی قوی در برابر حمله 51% هستند.
+
+علاوه بر حملات 51 درصدی، طرفهای بد ممکن است انواع دیگری از فعالیتهای مخرب را نیز انجام دهند، مانند:
+
+- حملات دوربرد (اگرچه ابزار قطعیت، این بردار حمله را خنثی میکند)
+- "reorgs" کوتاه برد (اگرچه مهلتهای تقویت پیشنهاددهنده و تصدیق این موضوع را کاهش میدهند)
+- حملات برگشتی و متعادل کننده (همچنین با تقویت پیشنهاددهنده کاهش مییابد و این حملات به هر حال فقط در شرایط شبکه ایده آل نشان داده شدهاند)
+- حملات بهمن (خنثیشده توسط قانون الگوریتمهای انتخاب فورک با در نظر گرفتن آخرین پیام)
+
+بهطور کلی، اثبات سهام، به شکلی که در اتریوم پیادهسازی میشود، از نظر اقتصادی امنتر از اثبات کار است.
+
+## مزایا و معایب {#pros-and-cons}
+
+| نقاط مثبت | نقاط منفی |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
+| سهامگذاریْ مشارکت افراد در تأمین امنیت شبکه و افزایش تمرکززدایی را آسانتر میکند. گرهی اعتبارسنج را میتوان روی یک لپتاپ معمولی اجرا کرد. استخرهای سهامگذاری به کاربران امکان میدهند بدون داشتن 32 اتریوم، سهامگذاری کنند. | اثبات سهام در مقایسه با اثبات کار، جوانتر است و کمتر مورد آزمایش قرار گرفته است |
+| سهامگذاری غیرمتمرکزتر است. مزیت مقیاس به شکلی که برای استخراج PoW اعمال میشد، اعمال نمیشود. | اجرای اثبات سهام پیچیدهتر از اثبات کار است |
+| اثبات سهام در مقایسه با اثبات کار، امنیت بیشتری از حیث اقتصاد رمزارز ارائه میدهد | کاربران برای مشارکت در اثبات سهام اتریوم باید سه نرمافزار را اجرا کنند. |
+| برای ایجاد انگیزه در شرکتکنندگان شبکه، کمتر لازم است ETH جدید صادر شود | |
+
+### مقایسه با اثبات کار {#comparison-to-proof-of-work}
+
+اتریوم در ابتدا از اثبات کار استفاده میکرد اما در سپتامبر 2022 به اثبات سهام روی آورد. اثبات سهام چندین مزیت نسبت به اثبات کار دارد، مانند:
+
+- بازده انرژی بهتر - هیچ نیازی به استفاده از انرژی بسیار زیاد محاسبات اثبات کار نیست
+- موانع کمتر برای ورود، سختافزار موردنیاز کمتر – برای برخورداری از شانس ساختن بلوکهای جدید، نیازی به سختافزار عجیب و خاص نیست
+- کاهش ریسک تمرکز - اثبات سهام باید به تعداد گرههای بیشتری در حال برقراری امنیت شبکه بیانجامد
+- به دلیل نیاز به انرژی کمتر، تولید اتر کمتری برای تشویق شرکتکنندهها نیاز است
+- جریمههای اقتصادی برای رفتار اشتباه باعث می شود که حملات مدل 51% برای حملهکننده به نسبت اثبات کار پرهزینه شوند
+- در صورتی که حملهی 51% در شرف فائق آمدن بر دفاعهای رمزارزی-اقتصادی بود، جامعه میتواند به بازیابی اجتماعی یک زنجیرهی صادق متوسل شود.
+
+## بیشتر بخوانید {#further-reading}
+
+- [سؤالات متداول درباره اثبات سهام](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _ویتالیک بوترین_
+- [اثبات سهام چیست؟](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_
+- [اثبات سهام چیست و چرا اهمیت دارد](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _ویتالیک بوترین_
+- [چرا اثبات سهام (نوامبر 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _ویتالیک بوترین_
+- [اثبات سهام: چگونه یاد گرفتم که سویهگیری خفیف را دوست داشته باشم](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _ ویتالیک بوترین_
+- [حمله و دفاع اثبات سهام اتریوم](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
+- [فلسفه طراحی اثبات سهام](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _ویتالیک بوترین_
+- [ویدیو: ویتالیک بوترین اثبات سهام را برای لکس فریدمن توضیح می دهد](https://www.youtube.com/watch?v=3yrqBG-7EVE)
+
+## موضوعات مرتبط {#related-topics}
+
+- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
+- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
new file mode 100644
index 00000000000..a3eeec1ff27
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
@@ -0,0 +1,96 @@
+---
+title: کلید ها در اثبات-سهم اتریوم
+description: توضیحی درباره کلیدهای استفاده شده در مکانیسم اجماع اثبات سهام اتریوم
+lang: fa
+---
+
+اتریوم از داراییهای کاربران با استفاده از رمزنگاری کلید عمومی-خصوصی محافظت میکند. کلید عمومی به عنوان پایه برای یک آدرس اتریوم استفاده میشود - یعنی برای عموم قابل مشاهده است و به عنوان یک شناسه منحصر به فرد استفاده میشود. کلید خصوصی (یا 'سرّی') باید تنها در دسترس مالک حساب باشد. کلید خصوصی برای "امضای" تراکنشها و دادهها استفاده میشود تا رمزنگاری بتواند ثابت کند که دارنده برخی اقدامات یک کلید خصوصی خاص را تایید میکند.
+
+کلیدهای اتریوم با استفاده از [رمزنگاری منحنی بیضی](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) تولید میشوند.
+
+با این حال، زمانی که اتریوم از [اثبات کار](/developers/docs/consensus-mechanisms/pow) به [اثبات سهام](/developers/docs/consensus-mechanisms/pos) تغییر کرد، نوع جدیدی از کلید به اتریوم اضافه شد. کلیدهای اصلی دقیقاً مانند قبل کار میکنند - هیچ تغییری در کلیدهای مبتنی بر منحنی بیضوی که حسابها را ایمن میکنند ایجاد نشده است. با این حال، کاربران به نوع جدیدی از کلید برای شرکت در اثبات سهام با سهام گذاری اتریوم و اجرای اعتبارسنج ها نیاز داشتند. این نیاز از چالشهای مقیاسپذیری مرتبط با تعداد زیادی پیام بین تعداد زیادی اعتبارسنج ایجاد شد که به یک روش رمزنگاری نیاز داشت که بتواند به راحتی برای کاهش مقدار ارتباط مورد نیاز برای رسیدن شبکه به اجماع جمع شود.
+
+این نوع جدید کلید از طرح امضای [**Boneh-Lynn-Sacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature) استفاده می کند. BLS امکان جمعبندی بسیار کارآمد امضاها را فراهم میکند اما همچنین مهندسی معکوس کلیدهای اعتبارسنج فردی جمعشده را امکانپذیر میکند و برای مدیریت اقدامات بین اعتبارسنج ها ایدهآل است.
+
+## دو نوع کلید اعتبارسنج {#two-types-of-keys}
+
+قبل از تغییر به اثبات سهام، کاربران اتریوم فقط یک کلید خصوصی مبتنی بر منحنی بیضوی برای دسترسی به وجوه خود داشتند. با معرفی اثبات سهام، کاربرانی که میخواستند سهامداران انفرادی باشند نیز به یک **کلید اعتبارسنج** و یک **کلید برداشت** نیاز داشتند.
+
+### کلید اعتبارسنج {#validator-key}
+
+کلید امضای اعتبارسنج از دو بخش تشکیل شده است:
+
+- کلید **خصوصی** اعتبارسنج
+- کلید **عمومی** اعتبارسنج
+
+هدف کلید خصوصی اعتبارسنج امضای عملیات روی زنجیره مانند پیشنهاد بلوک و تصدیقها است. به همین دلیل، این کلیدها باید در یک کیف پول داغ نگهداری شوند.
+
+این انعطافپذیری این مزیت را دارد که کلیدهای امضای اعتبارسنج را خیلی سریع از یک دستگاه به دستگاه دیگر منتقل میکند، با این حال، اگر آنها گم یا دزدیده شده باشند، دزد ممکن است به چند روش **به صورت مخرب** عمل کند:
+
+- اعتبارسنج را با موارد زیر جریمه کنید:
+ - یک پیشنهاد دهنده بودن و امضای دو بلوک بیکن متفاوت برای یک اسلات یکسان
+ - یک گواهیدهنده بودن و امضای گواهی که گواهی دیگری را "احاطه" میکند
+ - یک گواهیدهنده بودن و امضای دو گواهی متفاوت با هدف یکسان
+- خروج داوطلبانه را تحمیل کنید که اعتبارسنج را از سهام گذاری کردن متوقف می کند و دسترسی به موجودی ETH آن را به مالک کلید برداشت اعطا می کند
+
+**کلید عمومی اعتبارسنج** زمانی در دادههای تراکنش گنجانده میشود که کاربر ETH را در قرارداد سهام گذاری سپرده گذاری کند. این به _داده های سپرده_ معروف است و به اتریوم اجازه می دهد اعتبارسنج را شناسایی کند.
+
+### اعتبارنامههای برداشت {#withdrawal-credentials}
+
+هر اعتبارسنج دارای خاصیتی است که به نام _اعتبارنامههای برداشت_ شناخته میشود. این فیلد 32 بایتی با یک `0x00` شروع میشود که نمایانگر اعتبارنامههای خروج BLS است، یا با یک `0x01`، که نشاندهنده اعتبارنامههایی است که به یک آدرس اجرا اشاره میکنند.
+
+اعتبارسنجها با کلیدهای `0x00` BLS باید این اعتبارنامه ها را بهروزرسانی کنند تا به یک آدرس اجرا اشاره کنند تا بتوانند پرداختهای مازاد مانده یا برداشت کامل از سهام گذاری را فعال کنند. این کار را میتوان با ارائه یک آدرس اجرا در داده های سپرده در طول تولید کلید اولیه، _OR_ با استفاده از کلید برداشت در زمان دیگری برای امضا و پخش پیام `BLSToExecutionChange` انجام داد.
+
+### کلید برداشت از حساب {#withdrawal-key}
+
+کلید برداشت از حساب برای بهروزرسانی اعتبارنامه های برداشت برای اشاره به یک آدرس اجرا، در صورتی که در هنگام سپرده اولیه تنظیم نشده باشد، مورد نیاز خواهد بود. این امکان را فراهم میکند که پرداختهای مانده شروع به پردازش شوند و همچنین به کاربران اجازه میدهد تا کل اتریوم سهام گذاری شده خود را برداشت کنند.
+
+درست مانند کلیدهای اعتبارسنجی، کلیدهای برداشت نیز از دو جزء تشکیل شده است:
+
+- کلید **خصوصی** برداشت
+- کلید **عمومی** برداشت
+
+از دست دادن این کلید قبل از بهروزرسانی اعتبارنامه های برداشت به نوع `0x01` به معنای از دست دادن دسترسی به موجودی اعتبارسنج است. اعتبارسنج هنوز میتواند گواهیها و بلوکها را امضا کند زیرا این اقدامات به کلید خصوصی اعتبارسنج نیاز دارند، اما اگر کلیدهای برداشت از بین بروند، انگیزه کمی وجود دارد یا اصلاً وجود ندارد.
+
+جداسازی کلیدهای اعتبارسنج از کلیدهای حساب اتریوم امکان اجرای چندین اعتبارسنج توسط یک کاربر را فراهم میکند.
+
+![شماتیک کلید اعتبارسنج](validator-key-schematic.png)
+
+## استخراج کلیدها از عبارت بذر {#deriving-keys-from-seed}
+
+اگر هر ۳۲ اتریوم سهام گذاری شده به یک مجموعه جدید از ۲ کلید کاملا مستقل نیاز داشت، مدیریت کلید به سرعت غیرقابل کنترل میشد، به ویژه برای کاربرانی که چندین اعتبارسنج را اجرا میکنند. در عوض، چندین کلید اعتبارسنج میتوانند از یک کلید خصوصی مشترک استخراج شوند و ذخیره کردن آن کلید خصوصی واحد امکان دسترسی به چندین کلید اعتبارسنج را فراهم میکند.
+
+[عبارتهای بازیابی](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) و مسیرها ویژگی های برجسته ای هستند که کاربران اغلب هنگام [دسترسی به](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) کیف پول خود با آنها مواجه می شوند. عبارات بازیابی یک دنباله از کلمات است که به عنوان بذر اولیه برای یک کلید خصوصی عمل میکند. هنگامی که با دادههای اضافی ترکیب شود، عبارت بازیابی یک هش به نام "کلید اصلی" تولید میکند. این را می توان به عنوان ریشه یک درخت در نظر گرفت. سپس می توان شاخه هایی از این ریشه را با استفاده از یک مسیر سلسله مراتبی استخراج کرد تا گره های فرزند بتوانند به عنوان ترکیبی از هش گره والد خود و شاخص آنها در درخت وجود داشته باشند. درباره استانداردهای [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) و [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) برای تولید کلید مبتنی بر عبارت بازیابی مطالعه کنید.
+
+این مسیرها ساختار زیر را دارند که برای کاربرانی که با کیف پولهای سختافزاری تعامل داشتهاند آشنا خواهد بود:
+
+```
+m/44'/60'/0'/0`
+```
+
+جریمه ها در این مسیر، اجزای کلید خصوصی را به شرح زیر جدا میکنند:
+
+```
+master_key / purpose / coin_type / account / change / address_index
+```
+
+این منطق به کاربران اجازه میدهد تا بیشترین تعداد ممکن اعتبارسنج را به یک **عبارت بازیابی** متصل کنند، زیرا ریشه درخت میتواند مشترک باشد و تمایز در شاخهها اتفاق میافتد. کاربر می تواند **هر تعداد کلید** را از عبارات بازیابی استخراج کند.
+
+```
+ [m / 0]
+ /
+ /
+[m] - [m / 1]
+ \
+ \
+ [m / 2]
+```
+
+هر شاخه با یک `/` از هم جدا می شود، بنابراین `m/2` به معنای شروع با کلید اصلی و دنبال کردن شاخه 2 است. در طرح زیر از یک عبارت بازیابی واحد برای ذخیره سه کلید برداشت استفاده میشود که هر کدام دارای دو اعتبارسنج مرتبط هستند.
+
+![منطق کلید اعتبارسنج](multiple-keys.png)
+
+## بیشتر بخوانید {#further-reading}
+
+- [پست وبلاگ بنیاد اتریوم توسط Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/)
+- [تولید کلید BLS12-381 بر اساس EIP-2333](https://eips.ethereum.org/EIPS/eip-2333)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
new file mode 100644
index 00000000000..e6b2784cf0a
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
@@ -0,0 +1,69 @@
+---
+title: اثبات سهام در برابر اثبات کار
+description: مقایسه مکانیزم های اجماع اثبات سهام و اثبات کار اتریوم
+lang: fa
+---
+
+در زمان راهاندازی اتریوم، مکانیزم اثبات سهام هنوز نیاز به تحقیق و توسعه بیشتری داشت تا بتوان برای ایمنسازی اتریوم به آن اعتماد کرد. اثبات کار، مکانیزم سادهتری بود که کارایی آن قبلاً توسط بیتکوین ثابت شده بود. به این معنی که توسعهدهندگان اصلی میتوانستند از این مکانیزم برای راهاندازی سریع اتریوم استفاده کنند. هشت سال دیگر طول کشید تا مکانیزم اثبات سهام به مرحله ای برسد که بتوان آن را پیادهسازی کرد.
+
+این صفحه دلایل تغییر اتریوم از اثبات کار به اثبات سهام و مبادلات مربوط به آن را توضیح می دهد.
+
+## ایمنی {#security}
+
+محققان اتریوم اثبات سهام را امن تر از اثبات کار میدانند. با این حال، مکانیزم اثبات سهام به تازگی روی شبکه اصلی اتریوم پیادهسازی شده است و هنوز به اندازه مکانیزم اثبات کار فرصت اثبات خود در طول زمان را نداشته است. بخشهای زیر به بررسی مزایا و معایب مدل امنیتی اثبات سهام در مقایسه با اثبات کار میپردازد.
+
+### هزینه حمله کردن {#cost-to-attack}
+
+در اثبات سهام، اعتبارسنج ها باید حداقل 32 عدد ETH را در یک قرارداد هوشمند به امانت بگذارند ("سهام گذاری کنند"). اتریوم می تواند به منظور مجازات اعتبارسنج هایی که رفتار مخرب داشته اند، اترهای سهام گذاری شده را از بین ببرد. برای به اجماع رسیدن، باید حداقل 66٪ از کل اتر سهام گذاری شده به نفع مجموعه خاصی از بلوک ها رای دهند. بلوکهایی که با >=66% سهام به آنها رای داده شده است «نهایی میشوند»، به این معنی که نمیتوان آنها را حذف یا سازماندهی مجدد کرد.
+
+حمله به شبکه می تواند به معنای جلوگیری از نهایی شدن زنجیره یا اطمینان از سازماندهی خاصی از بلوک ها در زنجیره متعارف باشد که به نوعی به نفع مهاجم است. این امر مستلزم این است که مهاجم، مسیر اجماع صادقانه را یا با جمعآوری مقدار زیادی اتر و رای دادن مستقیم با آن و یا از طریق فریب اعتبارسنج های صادق به رأی دادن به روشی خاص منحرف کند. حملات پیچیده و کماحتمالی که میتوانند اعتبارسنج های صادق را فریب دهند به کنار، هزینه حمله به اتریوم هزینه سهامی است که مهاجم برای تأثیرگذاری بر اجماع به نفع خود باید آن را جمع کند.
+
+کمترین هزینه حمله، >33٪ از کل سهام است. مهاجمی که >33% از کل سهام را در اختیار دارد می تواند به سادگی با آفلاین شدن باعث تاخیر در نهایی کردن شود. این یک مشکل نسبتاً جزئی برای شبکه است، زیرا مکانیزمی به نام "نشت عدم فعالیت" وجود دارد که سهام را از اعتبار سنج های آفلاین نشت می دهد تا زمانی که اکثریت آنلاین 66٪ از سهام را شامل شوند و بتوانند دوباره زنجیره را نهایی کنند. همچنین از نظر تئوری ممکن است، یعنی هنگامی که از مهاجمی با کمی بیش از 33 درصد از کل سهام خواسته میشود تولید کننده بلوک باشد، با ایجاد دو بلوک به جای یک بلوک، نهایی شدن مضاعف را ایجاد کند و سپس با همه اعتبارسنج های خود رای مضاعف بدهد. هر فورک فقط به 50 درصد از اعتبارسنج های صادق باقی مانده نیاز دارد که ابتدا هر بلوک را ببینند، بنابراین اگر بتوانند پیامهای خود را درست زمانبندی کنند، ممکن است بتوانند هر دو فورک را نهایی کنند. با اینکه احتمال آن کم است، اما اگر مهاجمی بتواند باعث نهایی شدن دوگانه شود، جامعه اتریوم باید تصمیم بگیرد که یک فورک را دنبال کنند؛ در این صورت اعتبارسنج های مهاجم در دیگری جریمه خواهند شد.
+
+با بیش از 33> درصد از کل سهام، یک مهاجم این شانس را دارد که تأثیر جزئی (تاخیر نهایی) یا شدیدتر (نهاییسازی مضاعف) روی شبکه اتریوم داشته باشد. با بیش از 14,000,000 اتر سهامگذاری شده در شبکه و قیمت ارز 1000 دلار/اتر، حداقل هزینه برای اجرای این حملات `1000 ضرب در 14,000,000 ضربدر 0.33 است که مساوی است با 4,620,000,000 دلار`. مهاجم این پول را از طریق جریمه از دست می دهد و از شبکه خارج می شود. برای حمله مجدد، آنها باید بیشتر از 33> درصد اتر سهامگذاری شده را (مجددا) جمع کرده و آن را (دوباره) بسوزانند. هر تلاش برای حمله به شبکه 4.6 میلیارد دلار هزینه در بر خواهد داشت (با 1000 دلار/ETH و 14 میلیون ETH سهام). مهاجم همچنین هنگام جریمه شدن از شبکه خارج می شود و برای پیوستن مجدد باید به صف فعالسازی بپیوندد. این بدان معناست که نرخ یک حمله تکراری نه تنها به نرخی که مهاجم میتواند >33 درصد کل سهام را جمع کند محدود است، بلکه به مدت زمانی که طول میکشد تا تمام اعتبارسنج های خود را وارد شبکه کند. هر بار که مهاجم حمله می کند، بسیار فقیرتر می شود و بقیه افراد جامعه ثروتمندتر می شوند، به لطف شوک عرضه ناشی از آن.
+
+حملات دیگر، مانند حملات 51 درصدی یا بازگشت نهایی با 66 درصد کل سهام، به میزان قابل توجه ETH بیشتری نیاز دارند و برای مهاجم هزینه بیشتری دارند.
+
+این را با اثبات کار مقایسه کنید. هزینه حمله به اتریوم اثبات کار، هزینه مالکیت مداوم >50٪ از کل نرخ هش شبکه بود. این به هزینههای سختافزار و هزینههای جاری قدرت محاسباتی کافی برای پیشی گرفتن از سایر استخراجگرها برای محاسبه مداوم راهحلهای اثبات کار، اضافه شد. اتریوم بیشتر با استفاده از پردازندههای گرافیکی به جای آسیک ها استخراج میشد، که هزینه را پایین نگه داشت (اگرچه اگر اتریوم روی اثبات کار باقی میماند، دستگاه اسیک ممکن بود محبوبتر شود). یک دشمن برای حمله به شبکه اتریوم اثبات کار باید سختافزار زیادی بخرد و هزینه برق را برای اجرای آن بپردازد، اما کل هزینه کمتر از هزینهای است که برای جمعآوری اتر کافی برای انجام یک حمله لازم است. یک حمله 51٪ در اثبات کار نسبت به اثبات سهام، حدود [20 برابر ارزانتر](https://youtu.be/1m12zgJ42dI?t=1562) است. اگر حمله شناسایی شد و زنجیره برای حذف تغییرات آن هارد فورک شود، مهاجم می تواند مکرراً از همان سختافزار برای حمله به فورک جدید استفاده کند.
+
+### پيچيدگي {#complexity}
+
+اثبات سهام بسیار پیچیده تر از اثبات کار است. این می تواند به نفع اثبات کار باشد زیرا وارد کردن تصادفی باگ ها یا اثرات ناخواسته در پروتکل های سادهتر دشوارتر است. با این حال، پیچیدگی با سالها تحقیق و توسعه، شبیه سازی و پیادهسازی شبکه آزمایشی به دست آمده است. پروتکل اثبات سهام به طور مستقل توسط پنج تیم مجزا (در هر یک از لایههای اجرا و اجماع) در پنج زبان برنامهنویسی پیادهسازی شده است که مقاومت در برابر باگهای کلاینت را فراهم میکند.
+
+برای توسعه ایمن و آزمایش منطق اجماع اثبات سهام، بیکنچین دو سال قبل از اجرای اثبات سهام در شبکه اصلی اتریوم راهاندازی شد. بیکنچین به عنوان یک سندباکس برای آزمایش اثبات سهام عمل کرد، زیرا یک بلاکچین زنده بود که منطق اجماع اثبات سهام را پیادهسازی می کرد، اما بدون دست زدن به تراکنش های واقعی اتریوم - عملاً فقط در مورد خودش به اجماع رسید. هنگامی که برای مدت زمان کافی پایدار و بدون اشکال بود، بیکن چین با شبکه اصلی اتریوم ادغام شد. همه اینها به رام کردن پیچیدگی اثبات سهام کمک کرد تا جایی که خطر عواقب ناخواسته یا باگ های کاربر بسیار کم بود.
+
+### سطح حمله {#attack-surface}
+
+اثبات سهام پیچیدهتر از اثبات کار است، به این معنی که بردارهای حمله بالقوه بیشتری برای رسیدگی وجود دارد. به جای یک شبکه همتا به همتا که کاربرها را به هم متصل می کند، دو کاربر وجود دارد که هر کدام یک پروتکل جداگانه را پیادهسازی می کنند. داشتن یک اعتبارسنج خاص از پیش انتخاب شده برای پیشنهاد یک بلوک در هر شکاف، پتانسیل حمله داس را ایجاد می کند که در آن مقادیر زیادی از ترافیک شبکه، آن اعتبارسنج خاص را آفلاین می کند.
+
+همچنین راههایی وجود دارد که مهاجمان میتوانند با دقت زمان انتشار بلوکها یا تصدیقهای خود را به گونهای زمانبندی کنند که توسط بخش خاصی از شبکه صادق دریافت شوند و آنها را تحت تأثیر قرار دهند تا به روشهای خاصی رأی دهند. در نهایت، یک مهاجم میتواند به سادگی اتر کافی برای سهامگذاری کردن و تسلط بر مکانیسم اجماع جمع کند. هر یک از این [بردارهای حمله دارای دفاع های مرتبط هستند](/developers/docs/consensus-mechanisms/pos/attack-and-defense)، اما تحت اثبات کار چنین حملاتی وجود ندارند که بخواهیم از آنها دفاع کنیم.
+
+## غیرمتمرکزسازی {#decentralization}
+
+اثبات سهام بیش از اثبات کار غیرمتمرکز است، زیرا رقابت تجهیزاتی سختافزار استخراج تمایل دارند افراد و سازمانهای کوچک را قیمتگذاری کنند. در حالی که هر کس میتواند از لحاظ فنی استخراج را با سختافزار متوسط شروع کند، احتمال دریافت هر گونه پاداش در مقایسه با عملیات استخراج سازمانی بسیار ناچیز است. با اثبات سهام، هزینه سهامگذاری و درصد بازده آن سهام برای همه یکسان است. در حال حاضر اجرای یک اعتبارسنج، 32 اتر هزینه دارد.
+
+از سوی دیگر، اختراع مشتقات سهامگذاری نقدی به نگرانیهای تمرکزگرایی منجر شده است، زیرا چند ارائهدهنده بزرگ مقادیر زیادی از اتر سهامگذاری شده را مدیریت میکنند. این اتفاق مشکل ساز است و باید در اسرع وقت اصلاح شود، اما در عین حال جزئی تر از آن چیزی است که به نظر می رسد. ارائه دهندگان سهامگذاری متمرکز لزوماً کنترل متمرکز اعتبارسنج ها را ندارند - اغلب این فقط راهی برای ایجاد یک استخر مرکزی اتریوم است که بسیاری از اپراتورهای گره مستقل می توانند بدون اینکه هر شرکت کننده به 32 اتریوم اختصاصی خود نیاز داشته باشد آن را به اشتراک بگذارد.
+
+بهترین گزینه برای اتریوم این است که اعتبارسنج ها به صورت محلی در کامپیوترهای خانگی اجرا شوند و عدم تمرکز را به حداکثر برسانند. به همین دلیل است که اتریوم در برابر تغییراتی که نیازمندی های سخت افزاری برای اجرای یک گره/ اعتبارسنج را افزایش می دهند، مقاومت می کند.
+
+## پایداری {#sustainability}
+
+اثبات سهام یک راهکار کربن ارزان برای ایمنسازی بلاکچین است. در شرایط اثبات کار، استخراجگرها برای حق استخراج یک بلوک رقابت می کنند. استخراجگرها زمانی موفق تر هستند که بتوانند محاسبات را سریعتر انجام دهند و سرمایه گذاری در سختافزار و مصرف انرژی را تشویق کنند. قبل از اینکه اتریوم به اثبات سهام تبدیل شود، این موضوع برای اتریوم مشاهده شد. اندکی قبل از انتقال به اثبات سهام، اتریوم تقریباً 78 تراوات ساعت در سال مصرف می کرد - به اندازه یک کشور کوچک. بااینحال، تغییر به اثبات سهام این هزینه انرژی را تا حدود 99.98٪ کاهش داد. اثبات سهام، اتریوم را به پلتفرمی کم مصرف و کم کربن تبدیل کرد.
+
+[اطلاعات بیشتر در مورد مصرف انرژی اتریوم](/energy-consumption)
+
+## صدور {#issuance}
+
+اتریوم اثبات سهام می تواند با تولید سکه های بسیار کمتر نسبت به اتریوم اثبات کار، هزینه امنیت خود را بپردازد، زیرا اعتبارسنج ها مجبور نیستند هزینه های برق بالایی را بپردازند. در نتیجه، اتریوم می تواند تورم خود را کاهش دهد یا حتی در صورت سوزاندن مقادیر زیادی از اتر، تورم کاهش یابد. سطوح پایینتر تورم به این معنی است که امنیت اتریوم ارزانتر از زمانی است که در زمان اثبات کار بود.
+
+## با توضیحات تصویری راحتترید؟ {#visual-learner}
+
+توضیحات جاستین دریک درباره مزایای اثبات سهام نسبت به اثبات کار را مشاهده کنید:
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [فلسفه طراحی اثبات سهام ویتالیک](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
+- [پرسشهای متداول اثبات سهام ویتالیک](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
+- [«ویدیو درباره اثبات سهام و اثبات کار» به زبان ساده](https://www.youtube.com/watch?v=M3EFi_POhps)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
new file mode 100644
index 00000000000..9f99ba62677
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
@@ -0,0 +1,90 @@
+---
+title: پاداشها و جریمهها در اثبات-سهام
+description: درباره مشوق های داخل پروتکل در اتریوم اثبات سهام بیشتر بدانید.
+lang: fa
+---
+
+اتریوم با استفاده از رمزارز بومی خود، اتر (ETH) ایمن شده است. اپراتورهای گره که مایل به مشارکت در اعتبارسنجی بلوک ها و شناسایی سر زنجیره هستند، اتر را در [قرارداد سپرده](/staking/deposit-contract/) در اتریوم واریز می کنند. سپس به آنها اتر پرداخت می شود تا نرم افزار اعتبارسنج را اجرا کنند که اعتبار بلوک های جدید دریافت شده از طریق شبکه همتا به همتا را بررسی می کند و الگوریتم انتخاب فورک را برای شناسایی سر زنجیره اعمال می کند.
+
+دو نقش اصلی برای اعتبارسنج وجود دارد: 1) بررسی بلوکهای جدید و "تأیید" آنها در صورت معتبر بودن، 2) پیشنهاد بلوکهای جدید در صورت انتخاب تصادفی از مجموع استخر اعتبارسنجها. اگر اعتبارسنج، وقتی خواسته شد، نتواند هر یک از این وظایف را انجام دهد، دریافت اتر را از دست میدهد. اعتبارسنج ها همچنین گاهی اوقات وظیفه جمع آوری امضا و شرکت در کمیته های همگام سازی را بر عهده دارند.
+
+برخی از اقدامات نیز وجود دارد که انجام آنها به طور تصادفی بسیار دشوار است و نشانهای از قصد مخرب هستند، مانند پیشنهاد چندین بلوک برای یک اسلات یا تأیید چندین بلوک برای یک اسلات. اینها رفتارهای "قابل جریمه شدن" هستند که منجر به سوزاندن مقداری اتر (حداکثر 1 اتر) اعتبارسنج قبل از حذف اعتبارسنج از شبکه می شود که 36 روز طول می کشد. اتر اعتبارسنج جریمه شده به آرامی در طول دوره خروج تخلیه می شود، اما در روز 18 آنها یک "جریمه همبستگی" دریافت می کنند که وقتی اعتبارسنج های بیشتری در همان زمان جریمه می شوند بزرگتر می شود. بنابراین ساختار تشویقیِ مکانیزم اجماع، هزینه صداقت را می پردازد و بازیگران بد را مجازات می کند.
+
+تمام جوایز و مجازات ها، یکبار در هر ایپوک اعمال میشوند.
+
+برای جزئیات بیشتر به مطالعه ادامه دهید...
+
+## پاداش ها و جرایم {#rewards}
+
+### پاداشها {#rewards}
+
+اعتبارسنجها وقتی رایهایی را دریافت میکنند که با اکثریت اعتبارسنج های دیگر مطابقت دارد، وقتی بلوکهایی را پیشنهاد میکنند، و زمانی که در کمیتههای همگامسازی شرکت میکنند، پاداش دریافت میکنند. ارزش پاداش ها در هر ایپوک از یک `base_reward` محاسبه می شود. این واحد پایه ای است که سایر پاداش ها از آن محاسبه می شود. این `base_reward` نشاندهنده میانگین پاداش دریافتی توسط اعتبارسنج در شرایط بهینه در هر ایپوک است. این از تراز مؤثر اعتبارسنج و تعداد کل اعتبارسنج های فعال به شرح زیر محاسبه میشود:
+
+```
+base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))
+```
+
+که در آن `base_reward_factor` عبارت است از 64 و `base_rewards_per_epoch` برابر است با 4 و `sum (موجودی فعال)` کل اتر سهامگذاری شده در تمام اعتبارسنج های فعال است.
+
+این بدین معنی است که پاداش پایه با موجودی مؤثر اعتبارسنج و با تعداد اعتبارسنج ها در شبکه نسبت معکوس دارد. هرچه اعتبارسنج بیشتر باشد، صدور کلی بیشتر است (به عنوان `sqrt(N)` اما `پایه_پاداش` برای هر اعتبارسنج کوچکتر است (به عنوان `1/sqrt(N)`). این عوامل بر APR یک گره سهامگذاری تاثیر می گذارد. دلیل این امر را در [یادداشت های ویتالیک](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards) بخوانید.
+
+سپس پاداش کل به عنوان مجموع پنج جزء محاسبه می شود که هر کدام دارای وزنی هستند که تعیین می کند هر جزء چقدر به پاداش کل اضافه می کند. اجزاء عبارتند از:
+
+```
+1. source vote: the validator has made a timely vote for the correct source checkpoint
+2. target vote: the validator has made a timely vote for the correct target checkpoint
+3. head vote: the validator has made a timely vote for the correct head block
+4. sync committee reward: the validator has participated in a sync committee
+5. proposer reward: the validator has proposed a block in the correct slot
+```
+
+وزن هر جزء به شکل زیر است:
+
+```
+TIMELY_SOURCE_WEIGHT uint64(14)
+TIMELY_TARGET_WEIGHT uint64(26)
+TIMELY_HEAD_WEIGHT uint64(14)
+SYNC_REWARD_WEIGHT uint64(2)
+PROPOSER_WEIGHT uint64(8)
+```
+
+مجموع این وزن ها 64 است. پاداش به صورت مجموع اوزان قابل اعمال تقسیم بر 64 محاسبه می شود. اعتبارسنجی که بهموقع رأیهای منبع، هدف و سر را ایجاد کرده، یک بلوک پیشنهاد کرده و در کمیته همگامسازی شرکت کرده است، میتواند `64/64 * base_reward == base_reward` دریافت کند. با این حال، یک اعتبارسنج معمولاً پیشنهاد دهنده بلوک نیست، بنابراین حداکثر پاداش آنها `64-8 /64 * base_reward == 7/8 * base_reward` است. اعتبار سنج هایی که نه پیشنهاد دهنده بلوک هستند و نه در کمیته همگام سازی، می توانند `64-8-2 / 64 * base_reward == 6.75/8 * base_reward` دریافت کنند.
+
+یک پاداش اضافی برای تشویق تصدیقهای سریع اضافه می شود. این `inclusion_delay_reward` است. این مقدار برابر با `base_reward` ضرب در `1/تأخیر` است که در آن `تاخیر` تعداد اسلاتهایی است که پیشنهاد بلوک و تصدیق را از هم جدا میکنند. به عنوان مثال، اگر تصدیق در یک شکاف از پیشنهاد بلوک ارسال شود، گواهیدهنده `base_reward * 1/1 == base_reward` دریافت میکند. اگر تصدیق در اسلات بعدی برسد، تصدیقکننده `base_reward * 1/2` و غیره دریافت میکند.
+
+پیشنهادکنندگان بلوک `8 / 64 * base_reward` را برای **هر تصدیق معتبر** موجود در بلوک دریافت میکنند، بنابراین ارزش واقعی مقیاسهای پاداش، با تعداد اعتبارسنج های تأییدکننده مقیاسبندی میشود. پیشنهاد دهندگان بلوک همچنین میتوانند پاداش خود را با گنجاندن شواهدی مبنی بر رفتار نادرست سایر اعتبارسنج ها در بلوک پیشنهادی خود افزایش دهند. این پاداشها همان «هویجهایی» هستند که صداقت اعتبارسنج را تشویق میکنند. پیشنهاد دهنده بلوکی که شامل اسلش است با `slashed_validators_effective_balance / 512` پاداش میگیرد.
+
+### مجازات ها {#penalties}
+
+تا اینجا ما اعتبارسنج های کاملاً خوبی را در نظر گرفتهایم، اما در مورد اعتبارسنج هایی که رأیهای سر، منبع و هدف را بهموقع نمیآورند یا آهسته انجام میدهند، چطور؟
+
+جریمههای از دست دادن آرای هدف و منبع برابر با پاداشهایی است که امضاکننده در صورت ارسال آنها دریافت میکرد. این بدان معناست که به جای اضافه شدن پاداش به موجودی شان، ارزش معادلی از موجودی شان حذف می شود. هیچ جریمه ای برای از دست دادن رای سر وجود ندارد (یعنی رای های سر فقط پاداش می گیرند، هرگز جریمه نمی شوند). هیچ جریمه ای در ارتباط با `تاخیر_شمول` وجود ندارد - فقط پاداش به موجودی اعتبارسنج اضافه نمی شود. همچنین هیچ جریمه ای برای عدم پیشنهاد بلوک وجود ندارد.
+
+در [مشخصات اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md) درباره جوایز و مجازاتها بیشتر بخوانید. پاداشها و جریمهها در ارتقاء Bellatrix تنظیم شدند - دنی رایان و ویتالیک را در این [ویدیوی EIP نگاه کنید](https://www.youtube.com/watch?v=iaAEGs1DMgQ) تماشا کنید.
+
+## جریمه کردن (اسلشینگ) {#slashing}
+
+جریمه کردن یک عمل شدیدتر است که منجر به حذف اجباری یک اعتبارسنج از شبکه و از دست دادن اتر سهامگذاری شده اش می شود. سه راه برای جریمه کردن یک اعتبارسنج وجود دارد که همه آنها به منزله پیشنهاد یا تأیید غیرصادقانه بلوک ها هستند:
+
+- با پیشنهاد و امضای دو بلوک مختلف برای یک اسلات
+- با تأیید بلوکی که بلوک دیگری را احاطه کرده است (عملاً تغییر سابقه)
+- با «رای گیری دوباره» از طریق تصدیق دو نامزد برای یک بلوک
+
+اگر این اقدامات شناسایی شوند، اعتبارسنج جریمه می شود. این بدان معنی است که 1/32 اتر سهامگذاری شده آنها (حداکثر 1 اتر) بلافاصله سوزانده می شود، سپس یک دوره حذف 36 روزه آغاز می شود. در طول این دوره حذف، سهام اعتبارسنج به تدریج از بین می رود. در نقطه میانی (روز 18) یک جریمه اضافی اعمال میشود که اندازه آن با کل اتر سهامگذاری شده تمام اعتبارسنج های جریمه شده در 36 روز قبل از رویداد جریمه مقیاسبندی میشود. این بدان معناست که وقتی اعتبارسنج های بیشتری جریمه میشوند، بزرگی جریمه افزایش مییابد. حداکثر جریمه، تراز مؤثر تمام اعتبارسنجهای جریمه شده است (یعنی اگر اعتبارسنج های زیادی جریمه شوند، ممکن است کل سهام خود را از دست بدهند). از سوی دیگر، یک رویداد جریمه مجزا تنها بخش کوچکی از سهام اعتبارسنج را می سوزاند. این جریمه نقطه میانی که با تعداد اعتبارسنجهای جریمه شده مقیاس میشود، «مجازات همبستگی» نامیده میشود.
+
+## نشت عدم فعالیت {#inactivity-leak}
+
+اگر لایه اجماع بیش از چهار ایپوک بدون نهایی شدن طی شده باشد، یک پروتکل اضطراری به نام "نشت عدم فعالیت" فعال می شود. هدف نهایی نشت عدم فعالیت، ایجاد شرایط لازم برای بازیابی نهایی شدن زنجیره است. همانطور که در بالا توضیح داده شد، نهایی شدن نیاز به اکثریت 2/3 از کل اتر سهامگذاری شده برای توافق در مورد نقاط بازرسی منبع و هدف دارد. اگر اعتبارسنج هایی که بیش از 1/3 از مجموع اعتبارسنج ها را نشان میدهند آفلاین شوند یا تصدیقهای صحیح را ارائه نکنند، امکان نهایی کردن پستهای بازرسی برای اکثریت 2/3 وجود ندارد. نشت عدم فعالیت اجازه می دهد تا سهام متعلق به اعتبارسنج های غیرفعال به تدریج از بین برود تا زمانی که آنها کمتر از 1/3 کل سهام را کنترل کنند و به اعتبارسنج های فعال باقی مانده اجازه می دهد زنجیره را نهایی کنند. هر چقدر هم که تعداد اعتبارسنجهای غیرفعال زیاد باشد، اعتبارسنجهای فعال باقی مانده در نهایت بیش از 2/3 سهام را کنترل خواهند کرد. از دست دادن سهام یک انگیزه قوی برای اعتبارسنج های غیرفعال است تا در اسرع وقت دوباره فعال شوند! سناریوی نشت عدم فعالیت در شبکه آزمایشی Medalla زمانی رخ داد که کمتر از 66 درصد از اعتبارسنج های فعال توانستند در مورد سر فعلی بلاکچین به توافق برسند. نشت عدم فعالیت فعال شد و در نهایت نهایی سازی دوباره به دست آمد!
+
+طراحی پاداش، مجازات و جریمه متعلق به مکانیسم اجماع، اعتباسنج های انفرادی را تشویق میکند تا به درستی رفتار کنند. با این حال، از این انتخابهای طراحی، سیستمی پدیدار میشود که به شدت به توزیع برابر اعتبارسنج ها در بین چندین کاربر انگیزه میدهد و باید به شدت از تسلط تک کاربر جلوگیری کند.
+
+## بیشتر بخوانید {#further-reading}
+
+- [بهروز رسانی اتریوم: لایه مشوق](https://eth2book.info/altair/part2/incentives)
+- [مشوقها در پروتکل هیبریدی Casper اتریوم](https://arxiv.org/pdf/1903.04205.pdf)
+- [مشخصات تشریح شده ویتالیک](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
+- [نکات جلوگیری از جریمه شدن Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
+
+_منابع_
+
+- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
new file mode 100644
index 00000000000..519d98ad8c6
--- /dev/null
+++ "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
@@ -0,0 +1,39 @@
+---
+title: فردیت ضعیف
+description: توضیح فردیت ضعیف و نقش آن در اثبات سهام اتریوم.
+lang: fa
+---
+
+فردیت در زنجیره بلوکی با اتکا بر اطلاعات اجتماعی برای موافقت با وضعیت فعلی اشاره دارد. ممکن است چندین فورک معتبر وجود داشته باشد که بر اساس اطلاعات جمعآوریشده از سایر همتایان در شبکه انتخاب میشوند. برعکس آن عینیت است که به زنجیرههایی اشاره دارد که در آن تنها یک زنجیره معتبر ممکن وجود دارد که همه گرهها با اعمال قوانین کدگذاری شدهشان لزوماً با آن موافقت خواهند کرد. حالت سومی نیز وجود دارد که به عنوان فردیت ضعیف شناخته می شود. این به زنجیره ای اشاره دارد که می تواند به طور عینی پس از دریافت بذری اولیه از اطلاعات به صورت اجتماعی پیشرفت کند.
+
+## پیشنیازها {#prerequisites}
+
+برای فهم این صفحه، فهم اساسی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) لازم است.
+
+## فردیت ضعیف چه مشکلاتی را حل میکند؟ {#problems-ws-solves}
+
+فردیت ویژگی ذاتی اثبات سهام زنجیره های بلوکی است زیرا انتخاب زنجیره صحیح از چندین فورک با شمارش آرای گذشته انجام میشود. این امر زنجیره بلوکی را در معرض چندین بردار حمله قرار میدهد، مانند حملات دوربرد که به موجب آن گرههایی که خیلی زود در زنجیره شرکت کردهاند، یک فورک جایگزین را حفظ میکنند که بعداً به نفع خود آزادش کنند. از طرف دیگر، اگر 33٪ از اعتبارسنجها سهام خود را پس بگیرند اما به تأیید و تولید بلوکها ادامه دهند، ممکن است یک فورک جایگزین ایجاد کنند که با زنجیره اصلی تضاد دارد. گرههای جدید یا گرههایی که برای مدت طولانی آفلاین بودهاند ممکن است از این موضوع آگاه نباشند که این اعتبارسنجهای مهاجم وجوه خود را برداشتهاند، بنابراین مهاجمان میتوانند آنها را فریب دهند تا یک زنجیره نادرست را دنبال کنند. اتریوم میتواند این بردارهای حمله را با اعمال محدودیتهایی که جنبههای فردی مکانیسم را کاهش میدهد – و بنابراین به فرضیات اعتماد میکند – به حداقل ممکن برساند.
+
+## نقاط بررسی فردیت ضعیف {#ws-checkpoints}
+
+فردیت ضعیف در اثبات سهام اتریوم با استفاده از "نقاط بررسی فردیت ضعیف" اجرا میشود. اینها ریشه های حالتی هستند که همه گره های شبکه توافق دارند به زنجیره اصلی تعلق دارند. آنها همان هدف «حقیقت جهانی» را برای بلوکهای ایجاد انجام میدهند، با این تفاوت که در موقعیت ایجاد در زنجیره بلوکی قرار ندارند. الگوریتم انتخاب فورک اطمینان دارد که حالت زنجیره بلوکی تعریف شده در آن نقطه بررسی درست است و به طور مستقل و عینی زنجیره را از آن نقطه به بعد تأیید می کند. نقاط بررسی بهعنوان «محدودیتهای برگشتی» عمل میکنند، زیرا بلوکهایی که قبل از نقاط بررسی با فردیت ضعیف قرار دارند، قابل تغییر نیستند. این امر باعث تضعیف حملات دوربرد، صرفاً با تعریف فورک های دوربرد به عنوان بخشی از طراحی مکانیزم نامعتبر میشود. اطمینان حاصل کردن از فاصله کمتر نقاط بررسی فردیت ضعیف نسبت به دوره خروج اعتبارسنج از یکدیگر تضمین می کند که اعتبارسنجی که زنجیره را منحرف می کند، حداقل مقداری از آستانه را کاهش می دهد تا بتوانند سهام خود را پس بگیرند و ورود کنندگان جدید نمی توانند توسط اعتبار سنج ها به داخل فورکهای نادرست فریب بخورند که سهام شان برداشته شده است.
+
+## تفاوت بین نقاط بررسی فردیت ضعیف و بلوک های نهایی {#difference-between-ws-and-finalized-blocks}
+
+بلوکهای قطعی و نقاط بررسی فردیت ضعیف به طور متفاوت از سوی گرههای اتریوم استفاده میشوند. اگر یک گره از رقابت بین دو بلوک برای قطعی شدن باخبر شود، در انتخاب بلوک اصلی به تردید میافتد - هیچ راهی برای تشخیص فورک متعارف نخواهد داشت. این نشانه شکست اجماع است. در مقابل، یک گره هر بلوکی را که با فردیت ضعیف خود در تقابل باشد به سادگی رد میکند. از زاویه دید گرهها، نقاط بررسی فردیت ضعیف از حقیقت محضی پرده برمیدارند که توسط هیچ اطلاعات جدیدی ضعیف نمیشود.
+
+## منظور از ضعیف چقدر ضعیف است؟ {#how-weak-is-weak}
+
+جنبه فردیت اثبات سهام اتریوم، لازمه یک وضعیت اخیر (نقطه بررسی فردیت ضعیف) از یک منبع قابل اعتماد برای همگامسازی است. ریسکِ داشتن یک نقطه بررسی فردیت ضعیف به دلیل قابلیت بررسی توسط منابع مستقل متعدد مانند جستجوگرهای بلوک یا گرههای چندگانه، بسیار کم است. اما، همیشه مقداری آزادی برای راهاندازی هر برنامه نرمافزازی لازم است، به عنوان مثال، اعتماد به ساخت برنامهای صادق توسط برنامه نویسان نرمافزار.
+
+نقطه بررسی فردیت ضعیف ممکن است به عنوان بخشی از نرمافزار کاربر ظاهر شود. مسلماً یک مهاجم می تواند نقطه بررسی را در نرمافزار دستکاری کند و به همین راحتی می تواند خود نرمافزار را خراب کند. هیچ راه عملی اقتصاد رمزارز برای حل این مشکل وجود ندارد، اما تاثیر توسعه دهندگان غیرقابل اعتماد در اتریوم با داشتن چندین تیم کاربر مستقل، که هر کدام نرمافزاری معادل را به زبانهای مختلف میسازند، در اتریوم به حداقل میرسد. جستجوگرهای بلوک همچنین ممکن است نقاط بررسی فردیت ضعیف یا راهی برای ارجاع متقابل نقاط بررسی به دست آمده از جاهای دیگر در برابر یک منبع اضافی ارائه دهند.
+
+در نهایت، نقاط بررسی را میتوان از گره های دیگر درخواست کرد. شاید یکی دیگر از کاربران اتریوم که یک گره کامل را اجرا میکند، بتواند یک نقطه بررسی را ارائه کند که اعتبارسنجها میتوانند آن را در برابر دادههای یک جستجوگر بلوک تأیید کنند. روی هم رفته، اعتماد به نقطه بررسی فردیت ضعیف میتواند به اندازه اعتماد به توسعهدهندگان کاربر مشکلساز باشد. اعتماد کلی مورد نیاز کم است. توجه به این نکته مهم است که این ملاحظات تنها در شرایط بسیار بعید مهم میشوند که اکثریت تاییدکنندگان برای تولید یک فورک جایگزین از زنجیره بلوکی توطئه کنند. تحت هر شرایط، تنها یک زنجیره از اتریوم برای انتخاب وجود دارد.
+
+## اطلاعات بیشتر {#further-reading}
+
+- [فردیت ضعیف در Eth2.0](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
+- [ویتالیک: چگونه یاد گرفتم عاشق فردیت ضعیف باشم](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
+- [فردیت ضعیف (مستندهای تکو)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/)
+- [فاز-0 راهنمای فردیت ضعیف](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md)
+- [تحلیل فردیت ضعیف در Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
new file mode 100644
index 00000000000..fc0777409a0
--- /dev/null
+++ "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
@@ -0,0 +1,79 @@
+---
+title: اثبات صلاحیت (PoA)
+description: توضیح پروتکل اجماع اثبات صلاحیت و نقش آن در اکوسیستم بلاکچین.
+lang: fa
+---
+
+**اثبات صلاحیت (PoA)** یک الگوریتم اجماع مبتنی بر شهرت است که یک نسخه اصلاح شده از [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) است. بیشتر در زنجیرههای خصوصی، تستنتها و شبکههای توسعه محلی مورد استفاده قرار میگیرد. PoA یک الگوریتم اجماع مبتنی بر اعتبار است که به جای یک مکانیسم مبتنی بر سهام در PoS، نیاز به اعتماد به یک مجموعه از امضاکنندگان مجاز برای تولید بلوکها دارد.
+
+## پیش نیازها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/)، و [مکانیسمهای اجماع](/developers/docs/) سازوکارهای اجماع را مطالعه کنید.
+
+## اثبات صلاحیت (PoA) چیست؟ {#what-is-poa}
+
+اثبات صلاحیت یک نسخه اصلاح شده از \*\*[اثبات سهام](/developers/docs/consensus-mechanisms/pos/) (PoS) است که یک الگوریتم اجماع مبتنی بر اعتبار به جای مکانیسم مبتنی بر سهام در PoS است. این اصطلاح برای اولین بار در سال 2017 توسط گاوین وود معرفی شد و این الگوریتم اجماع بیشتر توسط زنجیرههای خصوصی، شبکههای آزمایشی و شبکههای توسعه محلی استفاده شده است، زیرا مانند PoW بر نیاز به منابع با کیفیت بالا غلبه میکند و بر مقیاسپذیری غلبه میکند. با داشتن زیرمجموعه کوچکی از گرهها که بلاکچین را ذخیره میکنند و بلوکها را تولید میکنند، بر مشکلات مقیاسپذیری با PoS غلبه میکند.
+
+اثبات صلاحیت مستلزم اعتماد به مجموعهای از امضاکنندگان مجاز است که در [بلوک پیدایش] (/ واژهنامه/#genesis-block) تنظیم شدهاند. در اکثر اجراهای فعلی، همه امضاکنندگان مجاز هنگام تعیین اجماع زنجیره، از قدرت و امتیازات برابر برخوردار هستند. ایده مبنای سهام گذاری شهرت این است که هر اعتبارسنج مجاز از طریق مواردی مانند شناخت مشتری خود (KYC)، یا داشتن یک سازمان شناخته شده که تنها اعتباردهنده است، برای همه شناخته شده است - به این ترتیب اگر اعتبارسنج کار اشتباهی انجام دهد، هویت او مشخص می شود.
+
+چندین اجرای PoA وجود دارد، اما اجرای استاندارد اتریوم **کلیک** است که [EIP-225] (https://eips.ethereum.org/EIPS/eip-225) را اجرا میکند. کلیک یک استاندارد توسعهدهندهپسند و آسان برای اجرا است که از همه انواع همگامسازیهای کاربر پشتیبانی میکند. اجراهای دیگر عبارتند از [IBFT 2.0](https://besu.hyperledger.org/stable/private-networks/concepts/poa) و [Aura](https://openethereum.github.io/Chain-specification).
+
+## چگونه کار میکند {#how-it-works}
+
+در PoA، مجموعه ای از امضاکنندگان مجاز برای ایجاد بلوک های جدید انتخاب می شوند. امضاکنندگان بر اساس شهرت خود انتخاب می شوند و آنها تنها کسانی هستند که اجازه ایجاد بلوک های جدید را دارند. امضاکنندگان به صورت چرخشی انتخاب می شوند و هر امضاکننده مجاز است در یک بازه زمانی خاص یک بلوک ایجاد کند. زمان ایجاد بلوک ثابت است و امضاکنندگان ملزم به ایجاد بلوک در آن چارچوب زمانی هستند.
+
+اعتبار در این زمینه یک چیز کمّی نیست بلکه اعتبار شرکتهای شناخته شدهای مانند مایکروسافت و گوگل است، از این رو روش انتخاب امضاکنندگان مورد اعتماد الگوریتمی نیست بلکه یک عمل انسانی معمولی اعتماد است که در آن یک نهاد مثلاً مایکروسافت یک شبکه خصوصی PoA را بین صدها یا هزاران استارتاپ ایجاد میکند و نقش خود را به عنوان تنها امضاکننده مورد اعتماد با امکان افزودن سایر امضاکنندگان شناخته شده مانند گوگل در آینده ایفا میکند. استارتاپها بدون شک به مایکروسافت اعتماد میکنند که همیشه صادقانه عمل کند و از شبکه استفاده کند. این امر نیاز به مشارکت در شبکههای کوچک/خصوصی مختلف را که برای اهداف مختلف ساخته شدهاند تا غیرمتمرکز بودن و کارکرد آنها را حفظ کند، همراه با نیاز به استخراجگرها که انرژی و منابع زیادی صرف میکنند، برطرف میکند. برخی از شبکه های خصوصی از استاندارد PoA مانند VeChain استفاده می کنند و برخی آن را تغییر می دهند مانند Binance که از [PoSA] استفاده می کند (https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) که یک نسخه تغییر یافته سفارشی از PoA و PoS است.
+
+فرآیند رای گیری توسط خود امضا کنندگان انجام می شود. هر امضاکننده هنگام ایجاد بلوک جدید به اضافه یا حذف یک امضاکننده در بلوک خود رأی میدهد. آرا توسط گرهها جمعآوری میشوند و امضاکنندگان بر اساس آرایی که به آستانه معین `SIGNER_LIMIT` میرسند، اضافه یا حذف میشوند.
+
+ممکن است موقعیتی وجود داشته باشد که فورک های کوچک رخ دهد. سختی یک بلوک به این بستگی دارد که آیا بلوک به نوبت امضا شده است یا خارج از نوبت. بلوک های "نوبتی" سختی 2 دارند و بلوک های "خارج از نوبت" سختی 1 دارند. در مورد فورکهای کوچک، زنجیرهای که اکثر امضاکنندگان آن بلوکها را "نوبتی" مهر و موم میکنند، بیشترین سختی را جمع میکند و برنده میشود.
+
+## بردارهای حمله {#attack-vectors}
+
+### امضاکنندگان مخرب {#malicious-signers}
+
+ممکن است یک کاربر مخرب به لیست امضاکنندگان اضافه شود، یا ممکن است کلید/ماشین امضا در خطر باشد. در چنین سناریویی، پروتکل باید بتواند از خود در برابر سازماندهی مجدد و ارسال اسپم دفاع کند. راهکار پیشنهادی این است که با توجه به لیستی از N امضاکننده مجاز، هر امضاکننده تنها میتواند 1 بلوک از هر K بلوک را ایجاد کند. این تضمین میکند که خسارت محدود شده و باقی اعتبارسنجها میتوانند کاربر مخرب را اخراج کنند.
+
+### سانسور {#censorship-attack}
+
+یکی دیگر از بردارهای جالب حمله این است که یک امضاکننده (یا گروهی از امضاکنندگان) سعی کند بلوک هایی را که به حذف آنها از لیست مجوز رأی می دهند، سانسور کند. برای حل این مشکل، فرکانس ضرب مجاز امضاکنندگان به 1 از N/2 محدود شده است. این امر تضمین می کند که امضاکنندگان مخرب باید حداقل 51٪ از حساب های امضا را کنترل کنند، در این مرحله آنها به طور مؤثر منبع جدیدی از حقیقت برای زنجیره خواهند بود.
+
+### اسپم {#spam-attack}
+
+یکی دیگر از بردارهای کوچک حمله، امضاکنندگان مخربی است که پیشنهادات رای جدید را در داخل هر بلوکی که ضرب میکنند، تزریق میکنند. از آنجا که گره ها برای ایجاد لیست واقعی امضاکنندگان مجاز باید همه آرا را جمعآوری کنند، باید تمام آرا را در طول زمان ثبت کنند. بدون محدود کردن پنجره رأیگیری، این مقدار میتواند به آرامی اما بدون محدودیت افزایش یابد. راه حل این است که یک پنجره متحرک بلوک های W ایجاد کنیم که پس از آن آرا منسوخ در نظر گرفته میشوند. _یک پنجره معقول ممکن است 1-2 ایپوک باشد._
+
+### بلوک های همزمان {#concurrent-blocks}
+
+در یک شبکه PoA، زمانی که N امضاکننده مجاز وجود دارد، هر امضاکننده مجاز به ایجاد یک بلوک از هر K بلوک است که به این معنی است که N-K+1 اعتبارسنج در هر لحظه مجاز به ایجاد بلوک هستند. برای جلوگیری از رقابت این اعتبارسنجها برای ایجاد بلوک، هر امضاکننده باید یک "جابجایی" تصادفی کوچک به زمان انتشار بلوک جدید خود اضافه کند. اگرچه این فرآیند تضمین می کند که فورکهای کوچک نادر هستند، فورکهای گاه به گاه هنوز هم می توانند اتفاق بیفتند، درست مانند شبکه اصلی. اگر مشخص شود که یک امضاکننده از قدرت خود سوء استفاده کرده و باعث ایجاد آشفتگی شده است، امضاکنندگان دیگر میتوانند او را اخراج کنند.
+
+به عنوان مثال، اگر 10 امضاکننده مجاز وجود داشته باشد و هر امضاکننده مجاز باشد از 20 بلوک، 1 بلوک ایجاد کند، در هر زمان، 11 اعتبارسنج می توانند بلوک ایجاد کنند. برای جلوگیری از رقابت آنها برای ایجاد بلوک، هر امضاکننده یک "جابجایی" تصادفی کوچک به زمانی که یک بلوک جدید را منتشر می کند اضافه می کند. این امر احتمال وقوع فورکهای کوچک را کاهش میدهد اما همچنان به فورکهای گاه به گاه مانند آنچه در شبکه اصلی اتریوم دیده میشود اجازه میدهد. اگر یک امضاکننده از صلاحیت خود سوء استفاده کرده و باعث اختلال شود، ممکن است از شبکه حذف شود.
+
+## مزایا و معایب {#pros-and-cons}
+
+| نقاط مثبت | نقاط منفی |
+| ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| مقیاس پذیرتر از مکانیسم های محبوب دیگر مانند PoS و PoW، زیرا بر اساس تعداد محدودی از امضاکنندگان بلوک است | شبکههای PoA معمولاً تعداد نسبتاً کمی گره اعتبارسنج دارند. این، شبکه PoA را متمرکزتر می کند. |
+| بلاک چین های PoA برای اجرا و نگهداری بسیار ارزان هستند | معمولاً برای یک فرد عادی تبدیل شدن به یک امضاکننده مجاز غیرقابل دسترس است، زیرا بلاک چین به نهادهایی با شهرت اثبات شده نیاز دارد. |
+| تراکنشها خیلی سریع تأیید میشوند، زیرا ممکن است به کمتر از ۱ ثانیه برسد، زیرا فقط تعداد محدودی امضاکننده برای اعتبارسنج بلوکهای جدید لازم است | امضاکنندگان مخرب می توانند دوباره سازماندهی کنند، دو برابر هزینه کنند، و تراکنش ها را در شبکه سانسور کنند. این حملات کاهش می یابد، اما همچنان ممکن است |
+
+## ادامه مطلب {#further-reading}
+
+- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique standard_
+- [مطالعه اثبات صلاحیت](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_
+- [اثبات صلاحیت چیست](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_
+- [شرح اثبات صلاحیت](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_
+- [PoA در بلاک چین](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba)
+- [شرح دسته](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d)
+- [PoA منسوخ شده، مشخصات Aura] (https://openethereum.github.io/Chain-specification)
+- [IBFT 2.0، اجرای دیگر PoA](https://besu.hyperledger.org/stable/private-networks/concepts/poa)
+
+### با توضیحات تصویری راحتترید؟ {#visual-learner}
+
+توضیح تصویری اثبات صلاحیت را تماشا کنید:
+
+
+
+## موضوعات مرتبط {#related-topics}
+
+- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
+- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
new file mode 100644
index 00000000000..f031539aaee
--- /dev/null
+++ "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
@@ -0,0 +1,109 @@
+---
+title: اثبات کار (PoW)
+description: توضیحی دربارهی پروتکل اجماع اثبات کار و نقشش در اتریوم.
+lang: fa
+---
+
+شبکه اتریوم با استفاده از یک مکانیزم اجماعی که شامل **[اثبات کار (PoW)](/developers/docs/consensus-mechanisms/pow)** بود، شروع به کار کرد. این موضوع به گره های شبکه اتریوم اجازه داد روی وضعیت تمام اطلاعات ثبت شده روی زنجیره بلوکی اتریوم به توافق برسند و از انواع خاصی از حملات اقتصادی جلوگیری کنند. با این حال، اتریوم اثبات کار را در سال 2022 خاموش کرد و به جای آن شروع به استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos) کرد.
+
+
+ در حال حاضر اثبات کار منسوخ شده است. اتریوم دیگر از اثبات کار به عنوان بخشی از مکانیزم اجماع خود استفاده نمی کند. در عوض، از اثبات سهام استفاده می کند. در مورد اثبات سهام و سهام گذاری بیشتر بخوانید.
+
+
+## پیشنیازها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/) و [مکانیزمهای اجماع](/developers/docs/consensus-mechanisms/) را مطالعه کنید.
+
+## اثبات کار (PoW) چیست؟ {#what-is-pow}
+
+اجماع ناکاموتو، که از اثبات کار استفاده می کند، مکانیزمی است که زمانی به شبکه غیرمتمرکز اتریوم اجازه می داد در مورد چیزهایی مانند موجودی حساب و ترتیب تراکنش ها به اجماع برسد (یعنی همه گرهها توافق کنند). این کار جلوی «خرج کردن دوباره» کوینهای کاربران را گرفت و باعث حصول اطمینان از این موضوع شد که حمله و خرابکاری در زنجیره اتریوم فوقالعاده سخت است. این ویژگی های امنیتی اکنون به جای استفاده از مکانیزم اجماع معروف به [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)، از اثبات سهام به دست می آیند.
+
+## اثبات کار و استخراج {#pow-and-mining}
+
+اثبات کار الگوریتمی اساسی است که دشواری و قوانین کاری که استخراجگران باید انجام دهند را در زنجیره های بلوکی اثبات کار تعیین می کند. استخراج، خودِ «کار» است. این همان عمل اضافه کردن بلوکهای معتبر به زنجیره است. این موضوع از آن جهت اهمیت دارد که طول زنجیره به شبکه کمک می کند تا از فورک صحیح زنجیره بلوکی پیروی کند. هر چه «کار» بیشتری انجام شود، زنجیره طولانیتر میشود و هر چه شماره بلوک بیشتر شود، شبکه از وضعیت فعلی مطمئنتر میشود.
+
+[اطلاعات بیشتر دربارهی استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
+
+## اثبات کار اتریوم چگونه کار می کرد؟ {#how-it-works}
+
+تراکنشهای اتریوم به بلوکها پردازش میشوند. در اتریوم اثبات کار که اکنون منسوخ شده است، هر بلوک شامل موارد زیر بود:
+
+- سختی بلوک - برای مثال: 3,324,092,183,262,715
+- mixHash - برای مثال: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
+- نانس (Nonce) - برای مثال: `0xd3ee432b4fb3d26b`
+
+این داده بلوکی ارتباط مستقیمی با اثبات کار داشت.
+
+### کار در اثبات کار {#the-work}
+
+پروتکل اثبات کار، Ethash، نیاز داشت که استخراجگران برای پیدا کردن نانس به روش آزمون و خطا به رقابت شدید بپردازند. تنها بلوک های دارای نانس (Nonce) معتبر میتوانستند به زنجیره اضافه شوند.
+
+استخراجگر در هنگام مسابقه برای ساخت بلوک، به طور منظم و تکراری یک مجموعهداده را، که فقط با دانلود و اجرای همه زنجیره به دست میآید (همان طور که استخراجگر هم دانلود و اجرا میکند)، از یک تابع ریاضی عبور میدهد. مجموعه داده ها برای ایجاد mixHash در زیر یک هدف که توسط سختی بلوک دیکته شده است، استفاده شد. بهترین راه برای انجام این کار آزمون و خطاست.
+
+سختی برای هش یک هدف تعیین کرد. هر چه هدف کمتر باشد، مجموعه هشهای معتبر کوچکتر است. وقتی ساخته شد، راستی آزمایی آن برای دیگر استخراجگران و کاربرها بسیار ساده بود. حتی اگر یک تراکش تغییر کند، هش کاملاً متفاوت خواهد بود و سیگنال تقلب خواهد داد.
+
+هش کردن باعث میشود که به آسانی بتوان تقلبها را کشف کرد. اما اثبات کار در مقام یک فرایند، یک بازدارنده مهم حملات به زنجیره هم بود.
+
+### اثبات کار و امنیت {#security}
+
+استخراجگران برای انجام این کار روی شبکه اصلی اتریوم تشویق شدند. مشوق کمی برای زیرمجموعهای از استخراجگران که زنجیره خودشان را بسازند وجود داشت - که سیستم را تضعیف میکند. زنجیرههای بلوکی بر یک وضعیت بهعنوان منبع حقیقت متکی هستند.
+
+هدف اثبات کار افزایش زنجیره بود. بلندترین زنجیره قابل قبولترین زنجیره به عنوان زنجیره معتبر است، چرا که بیشترین میزان کار پردازشی برای تولید آن انجام شده بود. در سیستم اثبات کار اتریوم، ساخت بلوکهای جدیدی که تراکنشها را پاک کند، تراکنشهای جعلی بسازد یا یک زنجیره دوم را نگهداری کند، تقریباً غیرممکن بود. دلیل این موضوع آن است که استخراجگر بداندیش نیاز خواهد داشت که نانس (Nonce) بلوک را همواره زودتر از هر کس دیگر پیدا کند.
+
+استخراجگر بد اندیش برای این که بهطور مداوم بتواند بلوکهای معتبر اما بداندیش بسازد نیاز دارد بیش از 51% توان استخراج شبکه را داشته باشد تا از بقیه جلو بیفتد. این مقدار "کار" به قدرت محاسباتی بسیار گران قیمت نیاز دارد و انرژی صرف شده حتی ممکن است از سود حاصل از یک حمله بیشتر باشد.
+
+### اقتصاد اثبات کار {#economics}
+
+اثبات کار همچنین مسئول صدور ارز جدید به درون سیستم و تشویق استخراجگران به انجام کار بود.
+
+از زمان [ارتقا Constantinopld](/history/#constantinople)، استخراج گرانی که با موفقیت بلوک میساختند پاداشی برابر با دو اتر و بخشی از کارمزد تراکنش ها دریافت میکردند. بابت ساخت بلوک های عمو همچنین ۱٫۷۵ اتر پرداخت میشود. بلوک های عمو، بلوک های معتبری بودند که یک استخراجگر همزمان با اسخراجگر دیگر آن را به موازات زنجیره ابتدایی ساخته است، که در نهایت با این تصمیم که روی کدام بلوک زنجیره ادامه پیدا میکند مشخص میشوند. بلوکهای عمو معمولا به علت تأخیر شبکه رخ میدادند.
+
+## قطعیت {#finality}
+
+یک تراکنش روی اتریوم زمانی «قطعیت» دارد که عضوی از بلوکی باشد که نتواند عوض شود.
+
+از آنجا که استخراجگران به شکل غیر متمرکز کار کرده اند، دو بلوک معتبر میتوانند در یک زمان استخراج شوند. این کار یک فورک موقت ایجاد میکند. در نهایت، یکی از این زنجیرهها، پس از آنکه بلوک های بعدی استخراج شده به آن اضافه شد و در نتیجه بلندتر شد، زنجیره پذیرفتهشده خواهد شد.
+
+برای پیچیدهتر کردن بیشتر موضوع، تراکنشهایی که در فورک موقت رد شدهاند ممکن است در زنجیره پذیرفتهشده وجود نداشته باشند. این به این معنا است که شرایط میتواند معکوس شود. پس قطعیت به زمانی گفته میشود که یک تراکنش غیرقابل معکوس شدن باشد. زمانی که اتریوم از مکانیزم اجماع اثبات-کار استفاده میکرد، هر چه تعداد بلوک بیشتری روی بلوک `N` استخراج می شد، اطمینان بیشتری حاصل میشد که تراکنش های بلوک`N` موفق بوده اند و بازگردانده نمی شوند. حالا، با اثبات سهم، نهایی شدن، یک دارایی صریح بلوک است تا احتمالی.
+
+## استفاده از انرژی اثبات کار {#energy}
+
+یکی از بزرگترین انتقادها به اثبات کار، میزان مصرف انرژی مورد نیاز برای ایمن نگه داشتن شبکه است. برای حفظ امینت و عدم تمرکز شبکه، اتریوم با اثبات کار انرژی زیادی صرف میکرد. پیش از گذار به اثبات سهام، استخراج گران اتریوم رو هم دیگر حدود ۷۰ تراوات ساعت برق سالانه مصرف میکردند (حدودا برابر با مصرف برق جمهوری چک طبق امار[digieconomist](https://digiconomist.net/)در ۱۸ جولای ۲۰۲۲).
+
+## نقاط مثبت و منفی {#pros-and-cons}
+
+| نقاط مثبت | نقاط منفی |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| اثبات کار خنثی است. شما برای شروع و گرفتن پاداش بلوکها و حرکت از 0 اتر به موجودی مثبت، نیازی به اتر ندارید. با [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)، شما برای شروع نیاز به اتر دارید. | اثبات کار به حدی انرژی مصرف میکند که برای محیط زیست بد است. |
+| اثبات کار یک مکانیزم اجماع آزمودهشده است که بیتکوین و اتریوم را برای سالها ایمن و غیرمتمرکز نگه داشته است. | اگر میخواهید استخراج کنید، نیاز به دستگاههای مخصوصی دارید که برای شروع، سرمایهگذاری گرانی است. |
+| در مقایسه با اثبات سهام، پیادهسازی راحتتری دارد. | با توجه به پردازش موردنیاز روزافزون، استخرهای استخراج احتمالاً تبدیل به غولهای بازی استخراج میشوند و این به ریسک متمرکز شدن و عدم امنیت منجر میشود. |
+
+## در مقایسه با اثبات سهام {#compared-to-pos}
+
+در سطح بالا، اثبات سهام همان هدفی را دارد که اثبات کار دارد: کمک به شبکه غیرمتمرکز برای رسیدن به اجماع بهطور امن. اما تفاوتهایی در فرایند و پرسنل دارد:
+
+- اثبات سهام بهجای توان پردازشی به اتر سهامگذاری شده اهمیت میدهد.
+- اثبات سهام استخراجگرها را با اعتبارسنجها جایگزین میکند. اعتبارسنجها اتر خود را سهامگذاری میکنند تا توانایی ساختن بلوک جدید را فعال کنند.
+- اعتبارسنجها برای ساختن بلوک با هم مسابقه ندارند و بهجای آن بهصورت تصادفی توسط یک الگوریتم انتخاب میشوند.
+- قطعیت واضحتر است: در برخی نقاط زمان، اگر 2/3 اعتبارسنجها بر سر وضعیت بلوک به توافق برسند، این بلوک قطعی در نظر گرفته میشود. اعتبارسنجها باید تمام سهام خود را شرطبندی کنند و اگر بخواهند تبانی کنند تمام سهام خود را از دست میدهند.
+
+[اطلاعات بیشتر دربارهی اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+
+## با تصویر راحتتر یاد میگیرید؟ {#visual-learner}
+
+
+
+## اطلاعات بیشتر {#further-reading}
+
+- [حملهی اکثریت](https://en.bitcoin.it/wiki/Majority_attack)
+- [دربارهی قطعیت تسویه](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
+
+### ویدیوها {#videos}
+
+- [توضیح فنی پروتکل اثبات کار](https://youtu.be/9V1bipPkCTU)
+
+## موضوعات مرتبط {#related-topics}
+
+- [استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
+- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
new file mode 100644
index 00000000000..501b8ba675c
--- /dev/null
+++ "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
@@ -0,0 +1,81 @@
+---
+title: استخراج
+description: توضیحی درباره نحوه کار استخراج روی اتریوم.
+lang: fa
+---
+
+
+اثبات-کار دیگر مکانیزم اجماع اتریوم نیست، و در نتیجه استخراج اتریوم متوفف شده است. در عوض، اتریوم توسط اعتبارسنجهایی که اتریوم را سهام گذاری میکنند، ایمن میشود. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. درباره ادغام، اثبات سهام و سهامگذاری بیشتر بخوانید. این صفحه تنها برای علاقمندان به تاریخچه پروژه است.
+
+
+## پیشنیازها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/) و [اثبات کار](/developers/docs/consensus-mechanisms/pow/) را مطالعه کنید.
+
+## استخراج اتریوم چیست؟ {#what-is-ethereum-mining}
+
+استخراج، فرآیند ایجاد بلوکی از تراکنش ها است که در معماری اثبات کار اتریوم که اکنون منسوخ شده است، به زنجیره بلوکی اتریوم اضافه میشود.
+
+کلمه «استخراج» ریشه در قیاس رمزارزها با طلا دارد. طلا یا فلزات گرانبها کمیاب هستند. توکنهای دیجیتال هم چنین هستند، تنها راه افزایش حجم کل در یک سیستم اثبات کار، استخراج است. در اثبات کار اتریوم، تنها روش صدور از طریق استخراج بود. با این حال، بر خلاف طلا یا فلزات گران بها، استخراج اتریوم راهی برای ایمن کردن شبکه از طریق ساختن، تأیید کردن، منتشر کردن و پخش کردن بلوکها در زنجیره بلوکی نیز بود.
+
+استخراج اتر = ایمنسازی شبکه
+
+استخراج رگ حیاتی هر زنجیره بلوکی اثبات کار است. استخراجکنندگان اتریوم - رایانههایی که نرمافزار را اجرا میکنند - از زمان و قدرت محاسباتی خود برای پردازش تراکنشها و تولید بلوکها پیش از انتقال به اثبات سهام استفاده میکردند.
+
+## چرا استخراجکنندگان وجود دارند؟ {#why-do-miners-exist}
+
+در سیستمهای غیرمتمرکز مانند اتریوم، باید اطمینان حاصل کنیم که همه در مورد ترتیب تراکنشها توافق دارند. استخراجکنندگان با حل پازلهای محاسباتی دشوار برای تولید بلوکها به این امر کمک میکردند و شبکه را در مقابل حملات ایمن نگه میداشتند.
+
+[اطلاعات بیشتر در مورد اثبات کار](/developers/docs/consensus-mechanisms/pow/)
+
+هر کس قبلا می توانست با استفاده از کامپیوتر خود در شبکه اتریوم استخراج کند. با این حال، همه نمیتوانستند اتر (ETH) را بهطور سودآور استخراج کنند. در بیشتر موارد، ماینرها مجبور به خرید سختافزار کامپیوتری اختصاصی و دسترسی به منابع انرژی ارزان قیمت بودند. بعید به نظر می رسید که یک کامپیوتر معمولی به اندازه کافی پاداش بلوک دریافت کند تا هزینه های مربوط به استخراج را پوشش دهد.
+
+### هزینهی استخراج {#cost-of-mining}
+
+- هزینههای بالقوهی سختافزاری لازم جهت ساخت و نگهداری ریگ استخراج
+- هزینهی برق لازم برای تأمین انرژی ریگ استخراج
+- اگر در یک استخر استخراج میکردید، این استخرها معمولاً درصدی هزینه ثابت از هر بلوک تولیدشده توسط استخر را دریافت میکردند
+- هزینهی احتمالی تجهیزات برای پشتیبانی از ریگ استخراج (تهویه، نظارت بر انرژی، سیمکشی برق و غیره)
+
+برای بررسی بیشتر سودآوری استخراج، از یک ماشینحساب استخراج مانند آنچه که [Etherscan](https://etherscan.io/ether-mining-calculator) ارائه میدهد، استفاده کنید.
+
+## تراکنشهای اتریوم چگونه استخراج میشدند {#how-ethereum-transactions-were-mined}
+
+در ادامه مروری بر نحوه استخراج تراکنش ها در اثبات کار اتریوم ارائه میشود. توصیف مشابهی از این فرآیند برای اثبات سهام اتریوم را می توانید در [اینجا](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) بیابید.
+
+1. یک کاربر یک درخواست [تراکنش](/developers/docs/transactions/) را با کلید خصوصی یک [حساب](/developers/docs/accounts/) مینویسد و امضا میکند.
+2. کاربر درخواست تراکنش را از یک [گره](/developers/docs/nodes-and-clients/) به کل شبکه اتریوم ارسال میکند.
+3. پس از شنیدن درخواست تراکنش جدید، هر گره در شبکه اتریوم درخواست را به استخر حافظهای محلی خود اضافه میکند. استخر حافظه لیستی است از تمام درخواستهای تراکنش که در مورد آنها شنیده است و هنوز به زنجیرهی بلوکی در یک بلوک وابسته نشده است.
+4. در برخی مواقع، یک گره استخراج چند ده یا صد درخواست تراکنش را در یک [بلوک](/developers/docs/blocks/) بالقوه تجمیع میکند، به گونهای که [کارمزد تراکنش](/developers/docs/gas/) کسبشدهی آنها را به حداکثر میرساند، در حالی که همچنان زیر حد گاز بلوک باقی میمانند. سپس گرهی استخراج:
+ 1. اعتبار هر درخواست تراکنش را تأیید میکند (یعنی هیچکس سعی نمیکند اتر را از حسابی که برای آن امضا تولید نکرده است منتقل کند، درخواست بدفرم نشده است و غیره)، و سپس کد درخواست را اجرا میکند و حالت نسخهی EVM محلی آن را تغییر میدهد. استخراجگر کارمزد تراکنش را برای هر درخواست تراکنش به حساب خود واریز میکند.
+ 2. زمانی که تمام درخواستهای تراکنش در بلوک تأیید شده و در نسخه EVM محلی اجرا شد، فرایند تولید «گواهی مشروعیت» اثبات کار برای بلوک بالقوه را آغاز میکند.
+5. در نهایت، یک استخراجگر تولید یک گواهی را برای بلوکی که شامل درخواست تراکنش خاص ما میشود، به پایان میرساند. سپس استخراجگر بلوک تکمیلشده را که شامل گواهینامه و چک تجمیع وضعیت جدید EVM ادعا شده است ارسال میکند.
+6. سایر گرهها در مورد بلوک جدید میشنوند. آنها گواهی را اعتبارسنجی میکنند، همه تراکنشهای روی بلوک را خودشان اجرا میکنند (از جمله تراکنشی که در ابتدا توسط کاربر ما ارسال شد)، و اعتبارسنجی میکنند که بررسی تجمیع وضعیت جدید ماشین مجازی اتریوم (EVM) بعد از اجرای همه تراکنشها، با بررسی تجمیع وضعیت ادعا شده توسط بلوک استخراجگر مطابقت داشته باشد. تنها در این صورت است که این گرهها این بلوک را به انتهای زنجیرهی بلوک خود اضافه میکنند و حالت جدید ماشین مجازی اتریوم (EVM) را بهعنوان حالت متعارف میپذیرند.
+7. هر گره تمام تراکنشهای موجود در بلوک جدید را از استخر حافظهی محلی درخواستهای تراکنش انجامنشدهی خود حذف میکند.
+8. گرههای جدیدی که به شبکه میپیوندند همه بلوکها را به ترتیب دانلود میکنند، از جمله بلوکی که شامل تراکنش مورد علاقه ما است. آنها یک کپی EVM محلی را راه اندازی می کنند (که به عنوان یک EVM حالت خالی شروع می شود)، و سپس فرآیند اجرای هر تراکنش در هر بلوک را در بالای کپی EVM محلی خود انجام می دهند، و بررسی تجمیع وضعیت را در هر بلوک در طول مسیر تأیید می کنند.
+
+هر تراکنش یک بار استخراج میشود (در یک بلوک جدید گنجانده میشود و برای اولین بار منتشر میشود) اما توسط هر شرکتکننده در فرایند پیشرفت حالت متعارف EVM اجرا و تأیید میشود. این نکته یکی از شعارهای اصلی زنجیره بلوکی را خاطرنشان میکند: **اعتماد نکنید، تأیید کنید**.
+
+## بلوک های (عمو) Ommer {#ommer-blocks}
+
+در استخراج بلوک ها در اثبات-کار احتمال دخیل بود، که یعنی به دلیل تاخیر در شبکه احتمال انتشار دو بلوک معتبر همزمان وجود داشت. در این حالت، پروتکل باید طولانیترین زنجیره (و بنابراین زنجیره «معتبر») را تعیین میکرد و همزمان با اعطای بلوک معتبر اضافه نشده، عدالت را در میان استخراجگرها تضمین میکرد. این امر تمرکززدایی بیشتر شبکه را تشویق کرد زیرا ماینرهای کوچکتر، که ممکن است با تأخیر بیشتری مواجه شوند، همچنان میتوانند از طریق پاداشهای بلوک [ommer](/glossary/#ommer) بازدهی ایجاد کنند.
+
+اصطلاح "ommer" اصطلاح ترجیحی از نظر جنسیتی خنثی برای سیبلینگ و بلوک والد است، اما گاهی اوقات به آن عمو (uncle) نیز گفته میشود. **پس از گذر اتریوم به اثبات-کار،هیچ بلوک عمویی استخراج نشده**زیرا تنها یک پیشنهاد دهنده در هر اسلات انتخاب میشود. شما میتوانید این تغییر را در[چارت تاریخی](https://ycharts.com/indicators/ethereum_uncle_rate) بلوک های عموی استخراج شده مشاهده کنید.
+
+## یک نسخهی آزمایشی تصویری {#a-visual-demo}
+
+آستین را تماشا کنید که شما را در راه استخراج و اثبات کار زنجیره بلوکی راهنمایی میکند.
+
+
+
+## الگوریتم استخراج {#mining-algorithm}
+
+شبکه اصلی اتریوم تنها از یک الگوریتم استخراج، یعنی -['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/) استفاده کرده است. Ethash جانشین یک الگوریتم تحقیق و توسعه اصلی شناخته شده به عنوان ["دگر هاشیموتو (Dagger-Hashimoto)"](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) بود.
+
+[اطلاعات بیشتر در مورد الگوریتم های استخراج](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/).
+
+## موضوعات مرتبط {#related-topics}
+
+- [گاز](/developers/docs/gas/)
+- [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)
+- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
new file mode 100644
index 00000000000..3b3f45e7086
--- /dev/null
+++ "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
@@ -0,0 +1,334 @@
+---
+title: Dagger-Hashamoto
+description: نگاهی دقیق به الگوریتم Dagger-Hashimoto.
+lang: fa
+---
+
+Dagger-Hashimoto زیرساخت و مشخصات اولیه تحقیقاتی برای الگوریتم استخراج اتریوم بود. Dagger-Hashimoto به [Ethash](#ethash) تغییر نام داده شد. استخراج به طور کامل در [ادغام](/roadmap/merge/) در 15 سپتامبر 2022 خاموش شد. از آن زمان، اتریوم با استفاده از مکانیزم [اثبات سهام](/developers/docs/consensus-mechanisms/pos) ایمن شده است. این صفحه برای رجوع تاریخی است - اطلاعات اینجا دیگر مرتبط به اتریوم پس از ادغام نیست.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای فهم بهتر این مقاله، پیشنهاد می کنیم ابتدا [اجماع اثبات کار](/developers/docs/consensus-mechanisms/pow)،[استخراج](/developers/docs/consensus-mechanisms/pow/mining) و [الگوریتم استخراج](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) را مطالعه کنید.
+
+## Dagger-Hashamoto {#dagger-hashimoto}
+
+Dagger-Hashamato دو هدف را برآورده می کند:
+
+1. **مقاومت در برابر اسیک**: مزیت حاصل از ایجاد سخت افزار تخصصی برای الگوریتم باید تا حد امکان کم باشد
+2. **تأیید پذیری کاربر سبک**: یک بلوک باید به طور مؤثر توسط کاربر سبک قابل تأیید باشد.
+
+با یک تغییر اضافی، همچنین مشخص می کنیم که چگونه می توان یک هدف سوم را در صورت تمایل برآورده کرد، هر چند با بهای افزایش پیچیدگی همراه باشد:
+
+**ذخیرهسازی زنجیره کامل**: استخراج باید به ذخیرهسازی حالت بلاک چین کامل نیاز داشته باشد (به دلیل ساختار نامنظم درخت حالت اتریوم، پیشبینی میکنیم برخی هرسها امکانپذیر باشد، به ویژه در بعضی قراردادهای پرمصرف، ولی می خواهیم این را به حداقل برسانیم).
+
+## تولید DAG {#dag-generation}
+
+کد الگوریتم در Python در زیر تعریف خواهد شد. ابتدا، `encode_int` را برای مارشال کردن اینت های بدون علامت با دقت مشخص به سطرها می دهیم. معکوس آن نیز داده می شود:
+
+```python
+NUM_BITS = 512
+
+def encode_int(x):
+ "Encode an integer x as a string of 64 characters using a big-endian scheme"
+ o = ''
+ for _ in range(NUM_BITS / 8):
+ o = chr(x % 256) + o
+ x //= 256
+ return o
+
+def decode_int(s):
+ "Unencode an integer x from a string using a big-endian scheme"
+ x = 0
+ for c in s:
+ x *= 256
+ x += ord(c)
+ return x
+```
+
+در مرحله بعد فرض می کنیم `sha3` تابعی است که یک عدد صحیح می گیرد و یک عدد صحیح را خروجی می دهد و `dbl_sha3` یک تابع double-sha3 است. اگر این کد مرجع را به یک اجرا تبدیل کنید:
+
+```python
+from pyethereum import utils
+def sha3(x):
+ if isinstance(x, (int, long)):
+ x = encode_int(x)
+ return decode_int(utils.sha3(x))
+
+def dbl_sha3(x):
+ if isinstance(x, (int, long)):
+ x = encode_int(x)
+ return decode_int(utils.sha3(utils.sha3(x)))
+```
+
+### پارامترها {#parameters}
+
+پارامتر هایی که برای الگوریتم مورد استفاده قرار می گیرند:
+
+```python
+SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512
+
+params = {
+ "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536
+ "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536
+ # with epochtime=20000 gives 882 MB growth per year
+ "cache_size": 2500, # Size of the light client's cache (can be chosen by light
+ # client; not part of the algo spec)
+ "diff": 2**14, # Difficulty (adjusted during block evaluation)
+ "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated)
+ "k": 1, # Number of parents of a node
+ "w": w, # Used for modular exponentiation hashing
+ "accesses": 200, # Number of dataset accesses during hashimoto
+ "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation
+}
+```
+
+`P` در این حالت یک عدد اول انتخاب شده است، طوری که `log₂(P)` فقط کمی کمتر از 512 است، که متناسب با 512 بیتی است که برای نشان دادن اعدادمان استفاده کردهایم. توجه داشته باشید که تنها نیمه دوم DAG در واقع باید ذخیره شود، بنابراین نیاز واقعی RAM از 1 گیگابایت شروع می شود و 441 مگابایت در سال افزایش می یابد.
+
+### ساختار نمودار Dagger {#dagger-graph-building}
+
+ساختار اولیه نمودار Dagger به صورت زیر تعریف می شود:
+
+```python
+def produce_dag(params, seed, length):
+ P = params["P"]
+ picker = init = pow(sha3(seed), params["w"], P)
+ o = [init]
+ for i in range(1, length):
+ x = picker = (picker * init) % P
+ for _ in range(params["k"]):
+ x ^= o[x % i]
+ o.append(pow(x, params["w"], P))
+ return o
+```
+
+اساساً، از یک نمودار به عنوان یک گره منفرد، `sha3(seed)` شروع می شود، و از آنجا شروع به اضافه کردن متوالی گره های دیگر بر اساس گره های تصادفی قبلی می کند. هنگامی که یک گره جدید ایجاد می شود، یک توان مدولار از بذر محاسبه می شود تا به طور تصادفی برخی از شاخص های کمتر از `i` (با استفاده از `x % i` بالا) انتخاب شود، و مقادیر گرهها در آن شاخصها در یک محاسبه برای ایجاد یک مقدار جدید برای `x` استفاده میشوند، که سپس به یک تابع کوچک اثبات کار (بر اساس XOR) وارد میشود تا در نهایت مقدار نمودار در فهرست `i` را ایجاد کند. منطق پشت این طراحی خاص، اجبار به دسترسی متوالی به DAG است. تا زمانی که مقدار فعلی مشخص نشود، مقدار بعدی DAG قابل دسترسی نیست. در نهایت، توان مدولار نتیجه را بیشتر هش می کند.
+
+این الگوریتم بر چندین نتیجه از نظریه اعداد متکی است. برای ادامه بحث به پیوست زیر مراجعه کنید.
+
+## ارزیابی کاربر سبک {#light-client-evaluation}
+
+ساختار نمودار بالا تمایل دارد به هر گره در نمودار اجازه دهد با محاسبه زیردرختی از تعداد کمی گره و نیاز به مقدار کمی حافظه کمکی، بازسازی شود. توجه داشته باشید که با k=1، زیردرخت فقط زنجیره ای از مقادیر است که تا اولین عنصر در DAG بالا می رود.
+
+تابع محاسبات کاربر سبک برای DAG به صورت زیر عمل می کند:
+
+```python
+def quick_calc(params, seed, p):
+ w, P = params["w"], params["P"]
+ cache = {}
+
+ def quick_calc_cached(p):
+ if p in cache:
+ pass
+ elif p == 0:
+ cache[p] = pow(sha3(seed), w, P)
+ else:
+ x = pow(sha3(seed), (p + 1) * w, P)
+ for _ in range(params["k"]):
+ x ^= quick_calc_cached(x % p)
+ cache[p] = pow(x, w, P)
+ return cache[p]
+
+ return quick_calc_cached(p)
+```
+
+اساساً، این به سادگی بازنویسی الگوریتم فوق است که حلقه محاسبه مقادیر کل DAG را حذف می کند و جستجوی گره قبلی را با یک فراخوان بازگشتی یا جستجوی حافظه پنهان جایگزین می کند. توجه داشته باشید که برای `k=1` حافظه نهان ضروری نیست، اگرچه یک بهینه سازی بیشتر در واقع چند هزار مقدار اول DAG را از قبل محاسبه می کند و آن را به عنوان یک حافظه نهان ثابت برای محاسبات نگه می دارد. برای اجرای کد این مورد به پیوست مراجعه کنید.
+
+## بافر دوگانه DAGها {#double-buffer}
+
+در یک کاربر کامل، یک [_بافر دوگانه_](https://wikipedia.org/wiki/Multiple_buffering) از 2 DAG تولید شده توسط فرمول بالا استفاده می شود. ایده این است که DAG ها در هر تعداد `زمان ایپوک` بلوک، مطابق با پارامترهای بالا تولید می شوند. به جای اینکه مشتری از آخرین DAG تولید شده استفاده کند، از DAG قبلی استفاده می کند. مزیت این کار این است که اجازه می دهد DAG ها در طول زمان بدون نیاز به ترکیب مرحله ای جایگزین شوند که در آن استخراجگرها باید به طور ناگهانی همه داده ها را دوباره محاسبه کنند. در غیر این صورت، پتانسیل کاهش ناگهانی و موقتی در پردازش زنجیره ای در فواصل زمانی منظم و افزایش چشمگیر تمرکز وجود دارد. بنابراین 51 درصد خطر حمله ظرف چند دقیقه قبل از محاسبه مجدد همه داده ها، وجود دارد.
+
+الگوریتم مورد استفاده برای تولید مجموعه ای از DAGهای مورد استفاده برای محاسبه کار برای یک بلوک به شرح زیر است:
+
+```python
+def get_prevhash(n):
+ from pyethereum.blocks import GENESIS_PREVHASH
+ from pyethereum import chain_manager
+ if n <= 0:
+ return hash_to_int(GENESIS_PREVHASH)
+ else:
+ prevhash = chain_manager.index.get_block_by_number(n - 1)
+ return decode_int(prevhash)
+
+def get_seedset(params, block):
+ seedset = {}
+ seedset["back_number"] = block.number - (block.number % params["epochtime"])
+ seedset["back_hash"] = get_prevhash(seedset["back_number"])
+ seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0)
+ seedset["front_hash"] = get_prevhash(seedset["front_number"])
+ return seedset
+
+def get_dagsize(params, block):
+ return params["n"] + (block.number // params["epochtime"]) * params["n_inc"]
+
+def get_daggerset(params, block):
+ dagsz = get_dagsize(params, block)
+ seedset = get_seedset(params, block)
+ if seedset["front_hash"] <= 0:
+ # No back buffer is possible, just make front buffer
+ return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
+ "block_number": 0}}
+ else:
+ return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
+ "block_number": seedset["front_number"]},
+ "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz),
+ "block_number": seedset["back_number"]}}
+```
+
+## هاشیموتو {#hashimoto}
+
+ایده پشت هاشیموتو اصلی استفاده از بلاک چین به عنوان مجموعه داده، انجام محاسباتی است که N شاخص را از زنجیره بلوکی انتخاب میکند، تراکنشها را در آن شاخصها جمعآوری میکند، XOR این دادهها را انجام میدهد و هشِ نتیجه را برمیگرداند. الگوریتم اصلی Thaddeus Dryja که برای سازگاری به Python ترجمه شده است به شرح زیر است:
+
+```python
+def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce):
+ hash_output_A = sha256(prev_hash + merkle_root + nonce)
+ txid_mix = 0
+ for i in range(64):
+ shifted_A = hash_output_A >> i
+ transaction = shifted_A % len(list_of_transactions)
+ txid_mix ^= list_of_transactions[transaction] << i
+ return txid_mix ^ (nonce << 192)
+```
+
+متأسفانه، در حالی که هاشیموتو برای RAM سخت در نظر گرفته می شود، بر محاسبات 256 بیتی متکی است که سربار محاسباتی قابل توجهی دارد. با این حال، Dagger-Hashimoto هنگام نمایه سازی مجموعه داده های خود برای رسیدگی به این مشکل، تنها از حداقل 64 بیت استفاده می کند.
+
+```python
+def hashimoto(dag, dagsize, params, header, nonce):
+ m = dagsize / 2
+ mix = sha3(encode_int(nonce) + header)
+ for _ in range(params["accesses"]):
+ mix ^= dag[m + (mix % 2**64) % m]
+ return dbl_sha3(mix)
+```
+
+استفاده از SHA3 مضاعف امکان پیشآزمایی فوری و بدون داده را فراهم میکند و فقط تأیید میکند که یک مقدار متوسط صحیح ارائه شده است. این لایه بیرونی اثبات کار بسیار ASIC-پسند و نسبتاً ضعیف است، اما وجود دارد تا DDoS را حتی دشوارتر کند زیرا آن مقدار کم کار باید انجام شود تا بلوکی تولید شود که فوراً رد نشود. این نسخه کاربر سبک است:
+
+```python
+def quick_hashimoto(seed, dagsize, params, header, nonce):
+ m = dagsize // 2
+ mix = sha3(nonce + header)
+ for _ in range(params["accesses"]):
+ mix ^= quick_calc(params, seed, m + (mix % 2**64) % m)
+ return dbl_sha3(mix)
+```
+
+## استخراج و راستی آزمایی {#mining-and-verifying}
+
+حال، برای االگوریتم استخراج، همه را در کنار یکدیگر قرار می دهیم:
+
+```python
+def mine(daggerset, params, block):
+ from random import randint
+ nonce = randint(0, 2**64)
+ while 1:
+ result = hashimoto(daggerset, get_dagsize(params, block),
+ params, decode_int(block.prevhash), nonce)
+ if result * params["diff"] < 2**256:
+ break
+ nonce += 1
+ if nonce >= 2**64:
+ nonce = 0
+ return nonce
+```
+
+این الگوریتم تایید است:
+
+```python
+def verify(daggerset, params, block, nonce):
+ result = hashimoto(daggerset, get_dagsize(params, block),
+ params, decode_int(block.prevhash), nonce)
+ return result * params["diff"] < 2**256
+```
+
+راستی آزمایی کاربر سبک:
+
+```python
+def light_verify(params, header, nonce):
+ seedset = get_seedset(params, block)
+ result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block),
+ params, decode_int(block.prevhash), nonce)
+ return result * params["diff"] < 2**256
+```
+
+همچنین، توجه داشته باشید که Dagger-Hashimoto الزامات اضافی را بر روی سر بلوک اعمال می کند:
+
+- برای اینکه تأیید دو لایه کار کند، یک سر بلوک باید هم مقدار نانس و هم مقدار میانی pre-sha3 را داشته باشد
+- در جایی، یک سر بلوک باید sha3 مجموعه seedset فعلی را ذخیره کند
+
+## اطلاعات بیشتر {#further-reading}
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
+
+## پیوست {#appendix}
+
+همانطور که در بالا ذکر شد، RNG مورد استفاده برای تولید DAG به برخی نتایج نظریه اعداد متکی است. اول، ما اطمینان می دهیم که Lehmer RNG که مبنایی برای متغیر `picker` است دارای یک دوره گسترده است. دوم، نشان میدهیم که `pow(x,3,P)` `x` را به `1` یا `P-10 نگاشت نمیکند. > x ∈ [2,P-2]` برای شروع ارائه شده است. در نهایت، نشان میدهیم که `pow(x,3,P)` وقتی به عنوان یک تابع هش در نظر گرفته میشود، نرخ برخورد پایینی دارد.
+
+### مولد اعداد تصادفی Lehmer {#lehmer-random-number}
+
+در حالی که تابع `produce_dag` نیازی به تولید اعداد تصادفی بی طرفانه ندارد، یک تهدید بالقوه این است که `seed**i % P` فقط تعداد انگشت شماری از مقادیر را دریافت کند. این می تواند مزیتی برای استخراجگرها ایجاد کند که الگو را نسبت به کسانی که این کار را نمی شناسند، تشخیص دهند.
+
+برای جلوگیری از این امر، از یک نتیجه نظریه اعداد استفاده می شود. [_Safe Prime_](https://en.wikipedia.org/wiki/Safe_prime) به صورت اول `P` تعریف شده است، طوری که `(P-1)/2` نیز اول باشد. _ترتیب_ یک عضو `x` از [گروه ضربی](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` حداقل `m` تعریف شده است، طوری که xᵐ mod P ≡ 1
+با توجه به این تعاریف داریم:
+
+> مشاهده 1. اجازه دهید `x` عضوی از گروه ضربی `ℤ/Pℤ` برای عدد اول امن `P` باشد. اگر `x mod P ≠ 1 mod P` و `x mod P ≠ P-1 mod P`، آنگاه ترتیب `x` یا ` است P-1` یا `(P-1)/2`.
+
+_اثبات_. از آنجا که `P` یک عدد اول امن است، پس با \[قضیه لاگرانژ\] \[لاگرانژ\] میبینیم که ترتیب `x` یا `1` است یا `2` یا `(P-1)/2` یا `P-1`.
+
+ترتیب `x` نمی تواند `1` باشد، زیرا با قضیه کوچک فرما داریم:
+
+xP-1 mod P ≡ 1
+
+بنابراین `x` باید یک هویت ضربی از `ℤ/nℤ` باشد، که منحصر به فرد است. از آنجا که فرض کردیم `x ≠ 1`، بر اساس فرض، این امکان پذیر نیست.
+
+ترتیب `x` نمی تواند `2` باشد مگر اینکه `x = P-1` باشد، زیرا این امر ناقض اصلی بودن `P` است.
+
+از گزاره بالا، می توانیم تشخیص دهیم که تکرار `( picker * init) % P` دارای طول چرخه حداقل `(P-1)/2` خواهد بود. این به این دلیل است که ما `P` را به عنوان یک عدد اول امن تقریباً برابر با توان بالاتر از دو انتخاب کردیم و `init` در بازه `[2,2**256+1]` است. با توجه به بزرگی `P`، هرگز نباید انتظار چرخه ای از توان مدولار داشته باشیم.
+
+هنگامی که اولین سلول را در DAG اختصاص می دهیم (متغیر با برچسب `init`)، `pow(sha3(seed) + 2, 3, P)` را محاسبه می کنیم. در نگاه اول، این تضمین نمی کند که نتیجه نه `1` و نه `P-1` باشد. با این حال، از آنجا که `P-1` یک عدد اول امن است، ما تضمین اضافی زیر را داریم که نتیجه مشاهده 1 است:
+
+> مشاهده 2. اجازه دهید `x` عضوی از گروه ضربی `ℤ/Pℤ` برای عدد اول امن `P` باشد، و اجازه دهید `w` یک عدد طبیعی باشد. اگر `x mod P ≠ 1 mod P` و `x mod P ≠ P-1 mod P`، و همچنین `w mod P ≠ P-1 mod P 0> و w mod P ≠ 0 mod P`، سپس `xʷ mod P ≠ 1 mod P` و `xʷ mod P ≠ P-1 mod P`
+
+### توان مدولار به عنوان یک تابع هش {#modular-exponentiation}
+
+برای مقادیر معینی از `P` و `w`، تابع `pow(x، w، P)` ممکن است برخوردهای زیادی داشته باشد. برای مثال، `pow(x,9,19)` فقط مقادیر `{1,18}` را می گیرد.
+
+با توجه به اینکه `P` اول است، میتوان با استفاده از نتیجه زیر، یک `w` مناسب برای یک تابع درهمسازی توان مدولار انتخاب کرد:
+
+> مشاهده 3. بگذارید `P` عدد اول باشد. `w` و `P-1` نسبتاً اول هستند اگر و فقط اگر برای همه `a` و `b` در `ℤ /Pℤ`:
+>
+>
+> «aʷ mod P ≡ bʷ mod P» اگر و فقط اگر «a mod P ≡ b mod P»
+>
+
+بنابراین، با توجه به اینکه `P` اول است و `w` نسبتاً اول نسبت به `P-1`، داریم که `|{pow(x, w, P) : x ∈ ℤ}| = P`، به این معنی است که تابع هش حداقل نرخ برخورد ممکن را دارد.
+
+در حالت خاصی که `P` همانطور که انتخاب کردهایم یک عدد اول امن است، پس `P-1` فقط فاکتورهای 1، 2، `(P-1)/2` و `P-1` را دارد. از آنجا که `P` > 7، می دانیم که 3 نسبتاً اول نسبت به `P-1` است، بنابراین `w=3` گزاره فوق را برآورده می کند.
+
+## الگوریتم کارآمدتر ارزیابی مبتنی بر حافظه پنهان {#cache-based-evaluation}
+
+```python
+def quick_calc(params, seed, p):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_calc_cached(cache, params, p)
+
+def quick_calc_cached(cache, params, p):
+ P = params["P"]
+ if p < len(cache):
+ return cache[p]
+ else:
+ x = pow(cache[0], p + 1, P)
+ for _ in range(params["k"]):
+ x ^= quick_calc_cached(cache, params, x % p)
+ return pow(x, params["w"], P)
+
+def quick_hashimoto(seed, dagsize, params, header, nonce):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_hashimoto_cached(cache, dagsize, params, header, nonce)
+
+def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
+ m = dagsize // 2
+ mask = 2**64 - 1
+ mix = sha3(encode_int(nonce) + header)
+ for _ in range(params["accesses"]):
+ mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
+ return dbl_sha3(mix)
+```
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
new file mode 100644
index 00000000000..1f40853bfd7
--- /dev/null
+++ "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
@@ -0,0 +1,1014 @@
+---
+title: یک الگوریتم اثبات انجام کار برای اتریوم ۱. ۰
+description: نگاهی دقیق به الگوریتم Ethash.
+lang: fa
+---
+
+
+ Ethash الگوریتم استخراج اثبات کار اتریوم بود. اثبات کار اکنون **به طور کامل خاموش شده** و اتریوم اکنون با استفاده از اثبات سهام امن شده است. درباره ادغام و اثبات سهام و سهام گذاری بیشتر بخوانید. این صفحه صرفاً برای علاقهمندان به تاریخ است!
+
+
+[Ethash](https://github.com/ethereum/wiki/wiki/Ethash) نسخه اصلاح شده الگوریتم [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) است. اثبات کار Ethash نیازمند [حافظه سخت](https://wikipedia.org/wiki/Memory-hard_function) است که تصور میشد این الگوریتم را در برابر دستگاههای ASIC مقاوم میکند. در نهایت، دستگاههای Ethash ASIC توسعه یافتند، اما تا زمانی که اثبات کار خاموش شد، استخراج با GPU همچنان یک گزینه قابل اجرا بود. Ethash هنوز برای استخراج سکه های دیگر در سایر شبکه های اثبات کار غیر اتریوم استفاده می شود.
+
+## Ethash چگونه کار می کند؟ {#how-does-ethash-work}
+
+سختی حافظه با الگوریتم اثبات کار به دست می آید که مستلزم انتخاب زیر مجموعه های یک منبع ثابت وابسته به سر نانس و بلوک است. این منبع (به اندازه چند گیگابایت) DAG نامیده می شود. DAG هر 30000 بلوک تغییر می کند، یعنی یک پنجره حدودا 125 ساعته به نام ایپوک (تقریباً 5.2 روز) و مدتی طول می کشد تا تولید شود. از آنجا که DAG فقط به ارتفاع بلوک بستگی دارد، میتوان آن را از پیش تولید کرد، اما اگر تولید نشده باشد، کاربر باید تا پایان این فرآیند منتظر بماند تا بتواند بلوک تولید کند. اگر کاربرها DAGها را از قبل تولید و ذخیره نکنند، ممکن است شبکه در هر انتقال دوره با تأخیر عظیم در بلوک مواجه شود. توجه داشته باشید که برای تأیید اثبات کار نیازی به تولید DAG نیست و این امکان را میدهد که تأیید با پردازنده کم مصرف و حافظه کم انجام شود.
+
+مسیر کلی که الگوریتم طی می کند به شرح زیر است:
+
+1. برای هر بلوک یک **بذر** وجود دارد که با اسکن کردن سرهای بلوک تا آن نقطه قابل محاسبه است.
+2. از روی این بذر، میتوان یک **حافظه پنهان شبهتصادفی ۱۶ مگابایتی** محاسبه کرد. کاربرهای سبک، حافظه پنهان را ذخیره میکنند.
+3. از حافظه پنهان، میتوانیم یک مجموعه داده **یک گیگابایتی** تولید کنیم، طوری که هر آیتم در این مجموعه داده فقط به تعداد کمی از آیتمهای حافظه پنهان وابسته است. کاربرهای کامل و استخراجگرها مجموعه داده را ذخیره میکنند. مجموعه داده به صورت خطی با زمان رشد می کند.
+4. استخراج شامل گرفتن برشهای تصادفی از مجموعه داده و هش کردن آنها با هم است. تأیید را میتوان با استفاده از حافظه پنهان برای بازسازی قطعات خاص مجموعه داده مورد نیاز با حافظه کم انجام داد، بنابراین فقط نیاز به ذخیره حافظه پنهان دارید.
+
+مجموعه داده بزرگ هر 30000 بلوک یک بار بهروزرسانی میشود، بنابراین اکثر تلاشهای یک استخراجگر صرف خواندن مجموعه داده میشود، نه ایجاد تغییر در آن.
+
+## تعاریف {#definitions}
+
+ما از تعاریف زیر استفاده می کنیم:
+
+```
+WORD_BYTES = 4 # bytes in word
+DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis
+DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch
+CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis
+CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch
+CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache
+EPOCH_LENGTH = 30000 # blocks per epoch
+MIX_BYTES = 128 # width of mix
+HASH_BYTES = 64 # hash length in bytes
+DATASET_PARENTS = 256 # number of parents of each dataset element
+CACHE_ROUNDS = 3 # number of rounds in cache production
+ACCESSES = 64 # number of accesses in hashimoto loop
+```
+
+### استفاده از 'SHA3' {#sha3}
+
+توسعه اتریوم همزمان با توسعه استاندارد SHA3 انجام شد و فرآیند استانداردسازی تغییری دیرهنگام در پرکردن الگوریتم هش نهایی ایجاد کرد، طوری که هشهای "sha3_256" و "sha3_512" اتریوم هشهای استاندارد sha3 نیستند، بلکه نوعی متفاوت هستند که اغلب در زمینههای دیگر به عنوان "Keccak-256" و "Keccak-512" شناخته میشوند. برای اطلاعات بیشتر، به بحثهای انجام شده در [اینجا](https://eips.ethereum.org/EIPS/eip-1803)، [اینجا](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)، یا [اینجا](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057) مراجعه کنید.
+
+لطفا این نکته را در نظر داشته باشید که در توضیحات الگوریتم زیر به هشهای "sha3" اشاره شده است.
+
+## پارامترها {#parameters}
+
+پارامترهای حافظه پنهان و مجموعه داده Ethash وابسته به شماره بلوک هستند. اندازه حافظه پنهان و اندازه مجموعه داده هر دو به صورت خطی رشد میکنند؛ با این حال، برای کاهش خطر ایجاد الگوهای تکراری منجر به رفتار چرخهای، همیشه بزرگترین عدد اول کمتر از آستانه رشد خطی را انتخاب میکنیم.
+
+```python
+def get_cache_size(block_number):
+ sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= HASH_BYTES
+ while not isprime(sz / HASH_BYTES):
+ sz -= 2 * HASH_BYTES
+ return sz
+
+def get_full_size(block_number):
+ sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= MIX_BYTES
+ while not isprime(sz / MIX_BYTES):
+ sz -= 2 * MIX_BYTES
+ return sz
+```
+
+جدولهای مقادیر اندازه حافظه پنهان و مجموعه داده در ضمیمه ارائه شده است.
+
+## تولید حافظه پنهان {#cache-generation}
+
+اکنون تابع تولید حافظه پنهان را مشخص می کنیم:
+
+```python
+def mkcache(cache_size, seed):
+ n = cache_size // HASH_BYTES
+
+ # Sequentially produce the initial dataset
+ o = [sha3_512(seed)]
+ for i in range(1, n):
+ o.append(sha3_512(o[-1]))
+
+ # Use a low-round version of randmemohash
+ for _ in range(CACHE_ROUNDS):
+ for i in range(n):
+ v = o[i][0] % n
+ o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v]))
+
+ return o
+```
+
+فرآیند تولید حافظه پنهان شامل پر کردن متوالی 32 مگابایت حافظه میشود، سپس دو پاس از الگوریتم _RandMemoHash_ سرجیو دمیان لرنر از [_Strict Memory Hard Hashing Functions_ (2014) انجام میشود](http://www.hashcash.org/papers/memohash.pdf). خروجی، یک مجموعه شامل ۵۲۴۲۸۸ مقدار ۶۴ بایتی است.
+
+## تابع تجمیع داده ها {#date-aggregation-function}
+
+در برخی موارد از یک الگوریتم الهام گرفته از [هش FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) به عنوان جایگزینی غیر تداعی برای XOR استفاده میکنیم. توجه داشته باشید که ما عدد اول را در کل ورودی ۳۲ بیتی ضرب میکنیم، برخلاف مشخصات FNV-1 که عدد اول را با هر بایت (octet) به نوبت ضرب میکند.
+
+```python
+FNV_PRIME = 0x01000193
+
+def fnv(v1, v2):
+ return ((v1 * FNV_PRIME) ^ v2) % 2**32
+```
+
+لطفا توجه داشته باشید که حتی وایتپیپر نیز fnv را به عنوان v1*(FNV_PRIME ^ v2) مشخص میکند، اما تمام اجراهای فعلی به طور مداوم از تعریف بالا استفاده میکنند.
+
+## محاسبه کامل مجموعه داده {#full-dataset-calculation}
+
+هر آیتم ۶۴ بایتی در کل مجموعه داده ۱ گیگابایتی به شرح زیر محاسبه میشود:
+
+```python
+def calc_dataset_item(cache, i):
+ n = len(cache)
+ r = HASH_BYTES // WORD_BYTES
+ # initialize the mix
+ mix = copy.copy(cache[i % n])
+ mix[0] ^= i
+ mix = sha3_512(mix)
+ # fnv it with a lot of random cache nodes based on i
+ for j in range(DATASET_PARENTS):
+ cache_index = fnv(i ^ j, mix[j % r])
+ mix = map(fnv, mix, cache[cache_index % n])
+ return sha3_512(mix)
+```
+
+در اصل، ما دادهها را از ۲۵۶ گره حافظه پنهان انتخاب شده به صورت شبهتصادفی ترکیب میکنیم و آن را هش میکنیم تا گره مجموعه داده را محاسبه کنیم. کل مجموعه داده سپس با استفاده از روش زیر تولید میشود:
+
+```python
+def calc_dataset(full_size, cache):
+ return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
+```
+
+## حلقه اصلی {#main-loop}
+
+حالا حلقه اصلی شبیه به "hashimoto" را مشخص میکنیم که در آن دادهها را از کل مجموعه داده جمعآوری میکنیم تا مقدار نهایی خود را برای یک سر و نانسِ خاص تولید کنیم. در کد زیر، `header` نشان دهنده _هش SHA3-256_ از نمایش RLP یک سر بلوک _بریده شده_ است، یعنی سر بدون فیلدهای **mixHash** و **nonce**. `نانس` هشت بایت از یک عدد صحیح بدون علامت ۶۴ بیتی با ترتیب بزرگ به کوچک است. پس `nonce[::-1]` نمایش هشت بایتی با ترتیب کوچک به بزرگ little-endian از آن مقدار است:
+
+```python
+def hashimoto(header, nonce, full_size, dataset_lookup):
+ n = full_size / HASH_BYTES
+ w = MIX_BYTES // WORD_BYTES
+ mixhashes = MIX_BYTES / HASH_BYTES
+ # combine header+nonce into a 64 byte seed
+ s = sha3_512(header + nonce[::-1])
+ # start the mix with replicated s
+ mix = []
+ for _ in range(MIX_BYTES / HASH_BYTES):
+ mix.extend(s)
+ # mix in random dataset nodes
+ for i in range(ACCESSES):
+ p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
+ newdata = []
+ for j in range(MIX_BYTES / HASH_BYTES):
+ newdata.extend(dataset_lookup(p + j))
+ mix = map(fnv, mix, newdata)
+ # compress mix
+ cmix = []
+ for i in range(0, len(mix), 4):
+ cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
+ return {
+ "mix digest": serialize_hash(cmix),
+ "result": serialize_hash(sha3_256(s+cmix))
+ }
+
+def hashimoto_light(full_size, cache, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))
+
+def hashimoto_full(full_size, dataset, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: dataset[x])
+```
+
+در اصل، ما یک "میکس" ۱۲۸ بایتی را حفظ میکنیم و به طور متوالی ۱۲۸ بایت را از کل مجموعه داده دریافت کرده و از تابع `fnv` برای ترکیب آن با میکس استفاده میکنیم. از ۱۲۸ بایت دسترسی متوالی استفاده میشود تا هر دور از الگوریتم همیشه یک صفحه کامل را از رم دریافت کند و خطای حافظه پنهان ترجمه را به حداقل برساند که از نظر تئوری ASICها میتوانند از آن جلوگیری کنند.
+
+اگر خروجی این الگوریتم کمتر از هدف مورد نظر باشد، پس نانس معتبر است. توجه داشته باشید که اعمال اضافی `sha3_256` در انتها تضمین میکند که یک نانس میانی وجود دارد که میتواند برای اثبات انجام حداقل مقدار کار ارائه شود؛ این تأیید سریع PoW خارجی میتواند برای اهداف ضد DDoS استفاده شود. همچنین برای ارائه اطمینان آماری از اینکه نتیجه یک عدد ۲۵۶ بیتی بدون سوگیری است، عمل میکند.
+
+## استخراج {#mining}
+
+الگوریتم استخراج به صورت زیر تعریف شده است:
+
+```python
+def mine(full_size, dataset, header, difficulty):
+ # zero-pad target to compare with hash on the same digit
+ target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
+ from random import randint
+ nonce = randint(0, 2**64)
+ while hashimoto_full(full_size, dataset, header, nonce) > target:
+ nonce = (nonce + 1) % 2**64
+ return nonce
+```
+
+## تعریف هش بذر {#seed-hash}
+
+برای محاسبه هش بذر که برای استخراج در بالای یک بلوک مورد استفاده قرار می گیرد، از الگوریتم زیر استفاده می کنیم:
+
+```python
+ def get_seedhash(block):
+ s = '\x00' * 32
+ for i in range(block.number // EPOCH_LENGTH):
+ s = serialize_hash(sha3_256(s))
+ return s
+```
+
+توجه داشته باشید که برای استخراج و تأیید روان، توصیه میشود که seedhashها و مجموعه دادههای آینده را در یک رشته جداگانه از قبل محاسبه کنید.
+
+## بیشتر بخوانید {#further-reading}
+
+_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
+
+## پیوست {#appendix}
+
+در صورتی که علاقهمند به اجرای مشخصات پایتون بالا به عنوان کد هستید، باید کد زیر را در ابتدای آن قرار دهید.
+
+```python
+import sha3, copy
+
+# Assumes little endian bit ordering (same as Intel architectures)
+def decode_int(s):
+ return int(s[::-1].encode('hex'), 16) if s else 0
+
+def encode_int(s):
+ a = "%x" % s
+ return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1]
+
+def zpad(s, length):
+ return s + '\x00' * max(0, length - len(s))
+
+def serialize_hash(h):
+ return ''.join([zpad(encode_int(x), 4) for x in h])
+
+def deserialize_hash(h):
+ return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)]
+
+def hash_words(h, sz, x):
+ if isinstance(x, list):
+ x = serialize_hash(x)
+ y = h(x)
+ return deserialize_hash(y)
+
+def serialize_cache(ds):
+ return ''.join([serialize_hash(h) for h in ds])
+
+serialize_dataset = serialize_cache
+
+# sha3 hash function, outputs 64 bytes
+def sha3_512(x):
+ return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
+
+def sha3_256(x):
+ return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x)
+
+def xor(a, b):
+ return a ^ b
+
+def isprime(x):
+ for i in range(2, int(x**0.5)):
+ if x % i == 0:
+ return False
+ return True
+```
+
+### اندازه داده ها {#data-sizes}
+
+جدولهای جستجوی زیر تقریباً ۲۰۴۸ دوره محاسباتی جدولبندی شده از اندازههای دادهها و اندازههای کش را ارائه میدهند.
+
+```python
+def get_datasize(block_number):
+ return data_sizes[block_number // EPOCH_LENGTH]
+
+def get_cachesize(block_number):
+ return cache_sizes[block_number // EPOCH_LENGTH]
+
+data_sizes = [
+1073739904, 1082130304, 1090514816, 1098906752, 1107293056,
+1115684224, 1124070016, 1132461952, 1140849536, 1149232768,
+1157627776, 1166013824, 1174404736, 1182786944, 1191180416,
+1199568512, 1207958912, 1216345216, 1224732032, 1233124736,
+1241513344, 1249902464, 1258290304, 1266673792, 1275067264,
+1283453312, 1291844992, 1300234112, 1308619904, 1317010048,
+1325397376, 1333787776, 1342176128, 1350561664, 1358954368,
+1367339392, 1375731584, 1384118144, 1392507008, 1400897408,
+1409284736, 1417673344, 1426062464, 1434451072, 1442839168,
+1451229056, 1459615616, 1468006016, 1476394112, 1484782976,
+1493171584, 1501559168, 1509948032, 1518337664, 1526726528,
+1535114624, 1543503488, 1551892096, 1560278656, 1568669056,
+1577056384, 1585446272, 1593831296, 1602219392, 1610610304,
+1619000192, 1627386752, 1635773824, 1644164224, 1652555648,
+1660943488, 1669332608, 1677721216, 1686109312, 1694497664,
+1702886272, 1711274624, 1719661184, 1728047744, 1736434816,
+1744829056, 1753218944, 1761606272, 1769995904, 1778382464,
+1786772864, 1795157888, 1803550592, 1811937664, 1820327552,
+1828711552, 1837102976, 1845488768, 1853879936, 1862269312,
+1870656896, 1879048064, 1887431552, 1895825024, 1904212096,
+1912601216, 1920988544, 1929379456, 1937765504, 1946156672,
+1954543232, 1962932096, 1971321728, 1979707264, 1988093056,
+1996487552, 2004874624, 2013262208, 2021653888, 2030039936,
+2038430848, 2046819968, 2055208576, 2063596672, 2071981952,
+2080373632, 2088762752, 2097149056, 2105539712, 2113928576,
+2122315136, 2130700672, 2139092608, 2147483264, 2155872128,
+2164257664, 2172642176, 2181035392, 2189426048, 2197814912,
+2206203008, 2214587264, 2222979712, 2231367808, 2239758208,
+2248145024, 2256527744, 2264922752, 2273312128, 2281701248,
+2290086272, 2298476672, 2306867072, 2315251072, 2323639168,
+2332032128, 2340420224, 2348808064, 2357196416, 2365580416,
+2373966976, 2382363008, 2390748544, 2399139968, 2407530368,
+2415918976, 2424307328, 2432695424, 2441084288, 2449472384,
+2457861248, 2466247808, 2474637184, 2483026816, 2491414144,
+2499803776, 2508191872, 2516582272, 2524970368, 2533359232,
+2541743488, 2550134144, 2558525056, 2566913408, 2575301504,
+2583686528, 2592073856, 2600467328, 2608856192, 2617240448,
+2625631616, 2634022016, 2642407552, 2650796416, 2659188352,
+2667574912, 2675965312, 2684352896, 2692738688, 2701130624,
+2709518464, 2717907328, 2726293376, 2734685056, 2743073152,
+2751462016, 2759851648, 2768232832, 2776625536, 2785017728,
+2793401984, 2801794432, 2810182016, 2818571648, 2826959488,
+2835349376, 2843734144, 2852121472, 2860514432, 2868900992,
+2877286784, 2885676928, 2894069632, 2902451584, 2910843008,
+2919234688, 2927622784, 2936011648, 2944400768, 2952789376,
+2961177728, 2969565568, 2977951616, 2986338944, 2994731392,
+3003120256, 3011508352, 3019895936, 3028287104, 3036675968,
+3045063808, 3053452928, 3061837696, 3070228352, 3078615424,
+3087003776, 3095394944, 3103782272, 3112173184, 3120562048,
+3128944768, 3137339264, 3145725056, 3154109312, 3162505088,
+3170893184, 3179280256, 3187669376, 3196056704, 3204445568,
+3212836736, 3221224064, 3229612928, 3238002304, 3246391168,
+3254778496, 3263165824, 3271556224, 3279944576, 3288332416,
+3296719232, 3305110912, 3313500032, 3321887104, 3330273152,
+3338658944, 3347053184, 3355440512, 3363827072, 3372220288,
+3380608384, 3388997504, 3397384576, 3405774208, 3414163072,
+3422551936, 3430937984, 3439328384, 3447714176, 3456104576,
+3464493952, 3472883584, 3481268864, 3489655168, 3498048896,
+3506434432, 3514826368, 3523213952, 3531603584, 3539987072,
+3548380288, 3556763264, 3565157248, 3573545344, 3581934464,
+3590324096, 3598712704, 3607098752, 3615488384, 3623877248,
+3632265856, 3640646528, 3649043584, 3657430144, 3665821568,
+3674207872, 3682597504, 3690984832, 3699367808, 3707764352,
+3716152448, 3724541056, 3732925568, 3741318016, 3749706368,
+3758091136, 3766481536, 3774872704, 3783260032, 3791650432,
+3800036224, 3808427648, 3816815488, 3825204608, 3833592704,
+3841981568, 3850370432, 3858755968, 3867147904, 3875536256,
+3883920512, 3892313728, 3900702592, 3909087872, 3917478784,
+3925868416, 3934256512, 3942645376, 3951032192, 3959422336,
+3967809152, 3976200064, 3984588416, 3992974976, 4001363584,
+4009751168, 4018141312, 4026530432, 4034911616, 4043308928,
+4051695488, 4060084352, 4068472448, 4076862848, 4085249408,
+4093640576, 4102028416, 4110413696, 4118805632, 4127194496,
+4135583104, 4143971968, 4152360832, 4160746112, 4169135744,
+4177525888, 4185912704, 4194303616, 4202691968, 4211076736,
+4219463552, 4227855488, 4236246656, 4244633728, 4253022848,
+4261412224, 4269799808, 4278184832, 4286578048, 4294962304,
+4303349632, 4311743104, 4320130432, 4328521088, 4336909184,
+4345295488, 4353687424, 4362073472, 4370458496, 4378852736,
+4387238528, 4395630208, 4404019072, 4412407424, 4420790656,
+4429182848, 4437571456, 4445962112, 4454344064, 4462738048,
+4471119232, 4479516544, 4487904128, 4496289664, 4504682368,
+4513068416, 4521459584, 4529846144, 4538232704, 4546619776,
+4555010176, 4563402112, 4571790208, 4580174464, 4588567936,
+4596957056, 4605344896, 4613734016, 4622119808, 4630511488,
+4638898816, 4647287936, 4655675264, 4664065664, 4672451968,
+4680842624, 4689231488, 4697620352, 4706007424, 4714397056,
+4722786176, 4731173248, 4739562368, 4747951744, 4756340608,
+4764727936, 4773114496, 4781504384, 4789894784, 4798283648,
+4806667648, 4815059584, 4823449472, 4831835776, 4840226176,
+4848612224, 4857003392, 4865391488, 4873780096, 4882169728,
+4890557312, 4898946944, 4907333248, 4915722368, 4924110976,
+4932499328, 4940889728, 4949276032, 4957666432, 4966054784,
+4974438016, 4982831488, 4991221376, 4999607168, 5007998848,
+5016386432, 5024763776, 5033164672, 5041544576, 5049941888,
+5058329728, 5066717056, 5075107456, 5083494272, 5091883904,
+5100273536, 5108662144, 5117048192, 5125436032, 5133827456,
+5142215296, 5150605184, 5158993024, 5167382144, 5175769472,
+5184157568, 5192543872, 5200936064, 5209324928, 5217711232,
+5226102656, 5234490496, 5242877312, 5251263872, 5259654016,
+5268040832, 5276434304, 5284819328, 5293209728, 5301598592,
+5309986688, 5318374784, 5326764416, 5335151488, 5343542144,
+5351929472, 5360319872, 5368706944, 5377096576, 5385484928,
+5393871232, 5402263424, 5410650496, 5419040384, 5427426944,
+5435816576, 5444205952, 5452594816, 5460981376, 5469367936,
+5477760896, 5486148736, 5494536832, 5502925952, 5511315328,
+5519703424, 5528089984, 5536481152, 5544869504, 5553256064,
+5561645696, 5570032768, 5578423936, 5586811264, 5595193216,
+5603585408, 5611972736, 5620366208, 5628750464, 5637143936,
+5645528192, 5653921408, 5662310272, 5670694784, 5679082624,
+5687474048, 5695864448, 5704251008, 5712641408, 5721030272,
+5729416832, 5737806208, 5746194304, 5754583936, 5762969984,
+5771358592, 5779748224, 5788137856, 5796527488, 5804911232,
+5813300608, 5821692544, 5830082176, 5838468992, 5846855552,
+5855247488, 5863636096, 5872024448, 5880411008, 5888799872,
+5897186432, 5905576832, 5913966976, 5922352768, 5930744704,
+5939132288, 5947522432, 5955911296, 5964299392, 5972688256,
+5981074304, 5989465472, 5997851008, 6006241408, 6014627968,
+6023015552, 6031408256, 6039796096, 6048185216, 6056574848,
+6064963456, 6073351808, 6081736064, 6090128768, 6098517632,
+6106906496, 6115289216, 6123680896, 6132070016, 6140459648,
+6148849024, 6157237376, 6165624704, 6174009728, 6182403712,
+6190792064, 6199176064, 6207569792, 6215952256, 6224345216,
+6232732544, 6241124224, 6249510272, 6257899136, 6266287744,
+6274676864, 6283065728, 6291454336, 6299843456, 6308232064,
+6316620928, 6325006208, 6333395584, 6341784704, 6350174848,
+6358562176, 6366951296, 6375337856, 6383729536, 6392119168,
+6400504192, 6408895616, 6417283456, 6425673344, 6434059136,
+6442444672, 6450837376, 6459223424, 6467613056, 6476004224,
+6484393088, 6492781952, 6501170048, 6509555072, 6517947008,
+6526336384, 6534725504, 6543112832, 6551500672, 6559888768,
+6568278656, 6576662912, 6585055616, 6593443456, 6601834112,
+6610219648, 6618610304, 6626999168, 6635385472, 6643777408,
+6652164224, 6660552832, 6668941952, 6677330048, 6685719424,
+6694107776, 6702493568, 6710882176, 6719274112, 6727662976,
+6736052096, 6744437632, 6752825984, 6761213824, 6769604224,
+6777993856, 6786383488, 6794770816, 6803158144, 6811549312,
+6819937664, 6828326528, 6836706176, 6845101696, 6853491328,
+6861880448, 6870269312, 6878655104, 6887046272, 6895433344,
+6903822208, 6912212864, 6920596864, 6928988288, 6937377152,
+6945764992, 6954149248, 6962544256, 6970928768, 6979317376,
+6987709312, 6996093824, 7004487296, 7012875392, 7021258624,
+7029652352, 7038038912, 7046427776, 7054818944, 7063207808,
+7071595136, 7079980928, 7088372608, 7096759424, 7105149824,
+7113536896, 7121928064, 7130315392, 7138699648, 7147092352,
+7155479168, 7163865728, 7172249984, 7180648064, 7189036672,
+7197424768, 7205810816, 7214196608, 7222589824, 7230975104,
+7239367552, 7247755904, 7256145536, 7264533376, 7272921472,
+7281308032, 7289694848, 7298088832, 7306471808, 7314864512,
+7323253888, 7331643008, 7340029568, 7348419712, 7356808832,
+7365196672, 7373585792, 7381973888, 7390362752, 7398750592,
+7407138944, 7415528576, 7423915648, 7432302208, 7440690304,
+7449080192, 7457472128, 7465860992, 7474249088, 7482635648,
+7491023744, 7499412608, 7507803008, 7516192384, 7524579968,
+7532967296, 7541358464, 7549745792, 7558134656, 7566524032,
+7574912896, 7583300992, 7591690112, 7600075136, 7608466816,
+7616854912, 7625244544, 7633629824, 7642020992, 7650410368,
+7658794112, 7667187328, 7675574912, 7683961984, 7692349568,
+7700739712, 7709130368, 7717519232, 7725905536, 7734295424,
+7742683264, 7751069056, 7759457408, 7767849088, 7776238208,
+7784626816, 7793014912, 7801405312, 7809792128, 7818179968,
+7826571136, 7834957184, 7843347328, 7851732352, 7860124544,
+7868512384, 7876902016, 7885287808, 7893679744, 7902067072,
+7910455936, 7918844288, 7927230848, 7935622784, 7944009344,
+7952400256, 7960786048, 7969176704, 7977565312, 7985953408,
+7994339968, 8002730368, 8011119488, 8019508096, 8027896192,
+8036285056, 8044674688, 8053062272, 8061448832, 8069838464,
+8078227328, 8086616704, 8095006592, 8103393664, 8111783552,
+8120171392, 8128560256, 8136949376, 8145336704, 8153726848,
+8162114944, 8170503296, 8178891904, 8187280768, 8195669632,
+8204058496, 8212444544, 8220834176, 8229222272, 8237612672,
+8246000768, 8254389376, 8262775168, 8271167104, 8279553664,
+8287944064, 8296333184, 8304715136, 8313108352, 8321497984,
+8329885568, 8338274432, 8346663296, 8355052928, 8363441536,
+8371828352, 8380217984, 8388606592, 8396996224, 8405384576,
+8413772672, 8422161536, 8430549376, 8438939008, 8447326592,
+8455715456, 8464104832, 8472492928, 8480882048, 8489270656,
+8497659776, 8506045312, 8514434944, 8522823808, 8531208832,
+8539602304, 8547990656, 8556378752, 8564768384, 8573154176,
+8581542784, 8589933952, 8598322816, 8606705024, 8615099264,
+8623487872, 8631876992, 8640264064, 8648653952, 8657040256,
+8665430656, 8673820544, 8682209152, 8690592128, 8698977152,
+8707374464, 8715763328, 8724151424, 8732540032, 8740928384,
+8749315712, 8757704576, 8766089344, 8774480768, 8782871936,
+8791260032, 8799645824, 8808034432, 8816426368, 8824812928,
+8833199488, 8841591424, 8849976448, 8858366336, 8866757248,
+8875147136, 8883532928, 8891923328, 8900306816, 8908700288,
+8917088384, 8925478784, 8933867392, 8942250368, 8950644608,
+8959032704, 8967420544, 8975809664, 8984197504, 8992584064,
+9000976256, 9009362048, 9017752448, 9026141312, 9034530688,
+9042917504, 9051307904, 9059694208, 9068084864, 9076471424,
+9084861824, 9093250688, 9101638528, 9110027648, 9118416512,
+9126803584, 9135188096, 9143581312, 9151969664, 9160356224,
+9168747136, 9177134464, 9185525632, 9193910144, 9202302848,
+9210690688, 9219079552, 9227465344, 9235854464, 9244244864,
+9252633472, 9261021824, 9269411456, 9277799296, 9286188928,
+9294574208, 9302965888, 9311351936, 9319740032, 9328131968,
+9336516736, 9344907392, 9353296768, 9361685888, 9370074752,
+9378463616, 9386849408, 9395239808, 9403629184, 9412016512,
+9420405376, 9428795008, 9437181568, 9445570688, 9453960832,
+9462346624, 9470738048, 9479121536, 9487515008, 9495903616,
+9504289664, 9512678528, 9521067904, 9529456256, 9537843584,
+9546233728, 9554621312, 9563011456, 9571398784, 9579788672,
+9588178304, 9596567168, 9604954496, 9613343104, 9621732992,
+9630121856, 9638508416, 9646898816, 9655283584, 9663675776,
+9672061312, 9680449664, 9688840064, 9697230464, 9705617536,
+9714003584, 9722393984, 9730772608, 9739172224, 9747561088,
+9755945344, 9764338816, 9772726144, 9781116544, 9789503872,
+9797892992, 9806282624, 9814670464, 9823056512, 9831439232,
+9839833984, 9848224384, 9856613504, 9865000576, 9873391232,
+9881772416, 9890162816, 9898556288, 9906940544, 9915333248,
+9923721088, 9932108672, 9940496512, 9948888448, 9957276544,
+9965666176, 9974048384, 9982441088, 9990830464, 9999219584,
+10007602816, 10015996544, 10024385152, 10032774016, 10041163648,
+10049548928, 10057940096, 10066329472, 10074717824, 10083105152,
+10091495296, 10099878784, 10108272256, 10116660608, 10125049216,
+10133437312, 10141825664, 10150213504, 10158601088, 10166991232,
+10175378816, 10183766144, 10192157312, 10200545408, 10208935552,
+10217322112, 10225712768, 10234099328, 10242489472, 10250876032,
+10259264896, 10267656064, 10276042624, 10284429184, 10292820352,
+10301209472, 10309598848, 10317987712, 10326375296, 10334763392,
+10343153536, 10351541632, 10359930752, 10368318592, 10376707456,
+10385096576, 10393484672, 10401867136, 10410262144, 10418647424,
+10427039104, 10435425664, 10443810176, 10452203648, 10460589952,
+10468982144, 10477369472, 10485759104, 10494147712, 10502533504,
+10510923392, 10519313536, 10527702656, 10536091264, 10544478592,
+10552867712, 10561255808, 10569642368, 10578032768, 10586423168,
+10594805632, 10603200128, 10611588992, 10619976064, 10628361344,
+10636754048, 10645143424, 10653531776, 10661920384, 10670307968,
+10678696832, 10687086464, 10695475072, 10703863168, 10712246144,
+10720639616, 10729026688, 10737414784, 10745806208, 10754190976,
+10762581376, 10770971264, 10779356288, 10787747456, 10796135552,
+10804525184, 10812915584, 10821301888, 10829692288, 10838078336,
+10846469248, 10854858368, 10863247232, 10871631488, 10880023424,
+10888412032, 10896799616, 10905188992, 10913574016, 10921964672,
+10930352768, 10938742912, 10947132544, 10955518592, 10963909504,
+10972298368, 10980687488, 10989074816, 10997462912, 11005851776,
+11014241152, 11022627712, 11031017344, 11039403904, 11047793024,
+11056184704, 11064570752, 11072960896, 11081343872, 11089737856,
+11098128256, 11106514816, 11114904448, 11123293568, 11131680128,
+11140065152, 11148458368, 11156845696, 11165236864, 11173624192,
+11182013824, 11190402688, 11198790784, 11207179136, 11215568768,
+11223957376, 11232345728, 11240734592, 11249122688, 11257511296,
+11265899648, 11274285952, 11282675584, 11291065472, 11299452544,
+11307842432, 11316231296, 11324616832, 11333009024, 11341395584,
+11349782656, 11358172288, 11366560384, 11374950016, 11383339648,
+11391721856, 11400117376, 11408504192, 11416893568, 11425283456,
+11433671552, 11442061184, 11450444672, 11458837888, 11467226752,
+11475611776, 11484003968, 11492392064, 11500780672, 11509169024,
+11517550976, 11525944448, 11534335616, 11542724224, 11551111808,
+11559500672, 11567890304, 11576277376, 11584667008, 11593056128,
+11601443456, 11609830016, 11618221952, 11626607488, 11634995072,
+11643387776, 11651775104, 11660161664, 11668552576, 11676940928,
+11685330304, 11693718656, 11702106496, 11710496128, 11718882688,
+11727273088, 11735660416, 11744050048, 11752437376, 11760824704,
+11769216128, 11777604736, 11785991296, 11794381952, 11802770048,
+11811157888, 11819548544, 11827932544, 11836324736, 11844713344,
+11853100928, 11861486464, 11869879936, 11878268032, 11886656896,
+11895044992, 11903433088, 11911822976, 11920210816, 11928600448,
+11936987264, 11945375872, 11953761152, 11962151296, 11970543488,
+11978928512, 11987320448, 11995708288, 12004095104, 12012486272,
+12020875136, 12029255552, 12037652096, 12046039168, 12054429568,
+12062813824, 12071206528, 12079594624, 12087983744, 12096371072,
+12104759936, 12113147264, 12121534592, 12129924992, 12138314624,
+12146703232, 12155091584, 12163481216, 12171864704, 12180255872,
+12188643968, 12197034112, 12205424512, 12213811328, 12222199424,
+12230590336, 12238977664, 12247365248, 12255755392, 12264143488,
+12272531584, 12280920448, 12289309568, 12297694592, 12306086528,
+12314475392, 12322865024, 12331253632, 12339640448, 12348029312,
+12356418944, 12364805248, 12373196672, 12381580928, 12389969024,
+12398357632, 12406750592, 12415138432, 12423527552, 12431916416,
+12440304512, 12448692352, 12457081216, 12465467776, 12473859968,
+12482245504, 12490636672, 12499025536, 12507411584, 12515801728,
+12524190592, 12532577152, 12540966272, 12549354368, 12557743232,
+12566129536, 12574523264, 12582911872, 12591299456, 12599688064,
+12608074624, 12616463488, 12624845696, 12633239936, 12641631616,
+12650019968, 12658407296, 12666795136, 12675183232, 12683574656,
+12691960192, 12700350592, 12708740224, 12717128576, 12725515904,
+12733906816, 12742295168, 12750680192, 12759071872, 12767460736,
+12775848832, 12784236928, 12792626816, 12801014656, 12809404288,
+12817789312, 12826181504, 12834568832, 12842954624, 12851345792,
+12859732352, 12868122496, 12876512128, 12884901248, 12893289088,
+12901672832, 12910067584, 12918455168, 12926842496, 12935232896,
+12943620736, 12952009856, 12960396928, 12968786816, 12977176192,
+12985563776, 12993951104, 13002341504, 13010730368, 13019115392,
+13027506304, 13035895168, 13044272512, 13052673152, 13061062528,
+13069446272, 13077838976, 13086227072, 13094613632, 13103000192,
+13111393664, 13119782528, 13128157568, 13136559232, 13144945024,
+13153329536, 13161724288, 13170111872, 13178502784, 13186884736,
+13195279744, 13203667072, 13212057472, 13220445824, 13228832128,
+13237221248, 13245610624, 13254000512, 13262388352, 13270777472,
+13279166336, 13287553408, 13295943296, 13304331904, 13312719488,
+13321108096, 13329494656, 13337885824, 13346274944, 13354663808,
+13363051136, 13371439232, 13379825024, 13388210816, 13396605056,
+13404995456, 13413380224, 13421771392, 13430159744, 13438546048,
+13446937216, 13455326848, 13463708288, 13472103808, 13480492672,
+13488875648, 13497269888, 13505657728, 13514045312, 13522435712,
+13530824576, 13539210112, 13547599232, 13555989376, 13564379008,
+13572766336, 13581154432, 13589544832, 13597932928, 13606320512,
+13614710656, 13623097472, 13631477632, 13639874944, 13648264064,
+13656652928, 13665041792, 13673430656, 13681818496, 13690207616,
+13698595712, 13706982272, 13715373184, 13723762048, 13732150144,
+13740536704, 13748926592, 13757316224, 13765700992, 13774090112,
+13782477952, 13790869376, 13799259008, 13807647872, 13816036736,
+13824425344, 13832814208, 13841202304, 13849591424, 13857978752,
+13866368896, 13874754688, 13883145344, 13891533184, 13899919232,
+13908311168, 13916692096, 13925085056, 13933473152, 13941866368,
+13950253696, 13958643584, 13967032192, 13975417216, 13983807616,
+13992197504, 14000582272, 14008973696, 14017363072, 14025752192,
+14034137984, 14042528384, 14050918016, 14059301504, 14067691648,
+14076083584, 14084470144, 14092852352, 14101249664, 14109635968,
+14118024832, 14126407552, 14134804352, 14143188608, 14151577984,
+14159968384, 14168357248, 14176741504, 14185127296, 14193521024,
+14201911424, 14210301824, 14218685056, 14227067264, 14235467392,
+14243855488, 14252243072, 14260630144, 14269021568, 14277409408,
+14285799296, 14294187904, 14302571392, 14310961792, 14319353728,
+14327738752, 14336130944, 14344518784, 14352906368, 14361296512,
+14369685376, 14378071424, 14386462592, 14394848128, 14403230848,
+14411627392, 14420013952, 14428402304, 14436793472, 14445181568,
+14453569664, 14461959808, 14470347904, 14478737024, 14487122816,
+14495511424, 14503901824, 14512291712, 14520677504, 14529064832,
+14537456768, 14545845632, 14554234496, 14562618496, 14571011456,
+14579398784, 14587789184, 14596172672, 14604564608, 14612953984,
+14621341312, 14629724288, 14638120832, 14646503296, 14654897536,
+14663284864, 14671675264, 14680061056, 14688447616, 14696835968,
+14705228416, 14713616768, 14722003328, 14730392192, 14738784128,
+14747172736, 14755561088, 14763947648, 14772336512, 14780725376,
+14789110144, 14797499776, 14805892736, 14814276992, 14822670208,
+14831056256, 14839444352, 14847836032, 14856222848, 14864612992,
+14872997504, 14881388672, 14889775744, 14898165376, 14906553472,
+14914944896, 14923329664, 14931721856, 14940109696, 14948497024,
+14956887424, 14965276544, 14973663616, 14982053248, 14990439808,
+14998830976, 15007216768, 15015605888, 15023995264, 15032385152,
+15040768384, 15049154944, 15057549184, 15065939072, 15074328448,
+15082715008, 15091104128, 15099493504, 15107879296, 15116269184,
+15124659584, 15133042304, 15141431936, 15149824384, 15158214272,
+15166602368, 15174991232, 15183378304, 15191760512, 15200154496,
+15208542592, 15216931712, 15225323392, 15233708416, 15242098048,
+15250489216, 15258875264, 15267265408, 15275654528, 15284043136,
+15292431488, 15300819584, 15309208192, 15317596544, 15325986176,
+15334374784, 15342763648, 15351151744, 15359540608, 15367929728,
+15376318336, 15384706432, 15393092992, 15401481856, 15409869952,
+15418258816, 15426649984, 15435037568, 15443425664, 15451815296,
+15460203392, 15468589184, 15476979328, 15485369216, 15493755776,
+15502146944, 15510534272, 15518924416, 15527311232, 15535699072,
+15544089472, 15552478336, 15560866688, 15569254528, 15577642624,
+15586031488, 15594419072, 15602809472, 15611199104, 15619586432,
+15627975296, 15636364928, 15644753792, 15653141888, 15661529216,
+15669918848, 15678305152, 15686696576, 15695083136, 15703474048,
+15711861632, 15720251264, 15728636288, 15737027456, 15745417088,
+15753804928, 15762194048, 15770582656, 15778971008, 15787358336,
+15795747712, 15804132224, 15812523392, 15820909696, 15829300096,
+15837691264, 15846071936, 15854466944, 15862855808, 15871244672,
+15879634816, 15888020608, 15896409728, 15904799104, 15913185152,
+15921577088, 15929966464, 15938354816, 15946743424, 15955129472,
+15963519872, 15971907968, 15980296064, 15988684928, 15997073024,
+16005460864, 16013851264, 16022241152, 16030629248, 16039012736,
+16047406976, 16055794816, 16064181376, 16072571264, 16080957824,
+16089346688, 16097737856, 16106125184, 16114514816, 16122904192,
+16131292544, 16139678848, 16148066944, 16156453504, 16164839552,
+16173236096, 16181623424, 16190012032, 16198401152, 16206790528,
+16215177344, 16223567744, 16231956352, 16240344704, 16248731008,
+16257117824, 16265504384, 16273898624, 16282281856, 16290668672,
+16299064192, 16307449216, 16315842176, 16324230016, 16332613504,
+16341006464, 16349394304, 16357783168, 16366172288, 16374561664,
+16382951296, 16391337856, 16399726208, 16408116352, 16416505472,
+16424892032, 16433282176, 16441668224, 16450058624, 16458448768,
+16466836864, 16475224448, 16483613056, 16492001408, 16500391808,
+16508779648, 16517166976, 16525555328, 16533944192, 16542330752,
+16550719616, 16559110528, 16567497088, 16575888512, 16584274816,
+16592665472, 16601051008, 16609442944, 16617832064, 16626218624,
+16634607488, 16642996096, 16651385728, 16659773824, 16668163712,
+16676552576, 16684938112, 16693328768, 16701718144, 16710095488,
+16718492288, 16726883968, 16735272832, 16743661184, 16752049792,
+16760436608, 16768827008, 16777214336, 16785599104, 16793992832,
+16802381696, 16810768768, 16819151744, 16827542656, 16835934848,
+16844323712, 16852711552, 16861101952, 16869489536, 16877876864,
+16886265728, 16894653056, 16903044736, 16911431296, 16919821696,
+16928207488, 16936592768, 16944987776, 16953375616, 16961763968,
+16970152832, 16978540928, 16986929536, 16995319168, 17003704448,
+17012096896, 17020481152, 17028870784, 17037262208, 17045649536,
+17054039936, 17062426496, 17070814336, 17079205504, 17087592064,
+17095978112, 17104369024, 17112759424, 17121147776, 17129536384,
+17137926016, 17146314368, 17154700928, 17163089792, 17171480192,
+17179864192, 17188256896, 17196644992, 17205033856, 17213423488,
+17221811072, 17230198912, 17238588032, 17246976896, 17255360384,
+17263754624, 17272143232, 17280530048, 17288918912, 17297309312,
+17305696384, 17314085504, 17322475136, 17330863744, 17339252096,
+17347640192, 17356026496, 17364413824, 17372796544, 17381190016,
+17389583488, 17397972608, 17406360704, 17414748544, 17423135872,
+17431527296, 17439915904, 17448303232, 17456691584, 17465081728,
+17473468288, 17481857408, 17490247552, 17498635904, 17507022464,
+17515409024, 17523801728, 17532189824, 17540577664, 17548966016,
+17557353344, 17565741184, 17574131584, 17582519168, 17590907008,
+17599296128, 17607687808, 17616076672, 17624455808, 17632852352,
+17641238656, 17649630848, 17658018944, 17666403968, 17674794112,
+17683178368, 17691573376, 17699962496, 17708350592, 17716739968,
+17725126528, 17733517184, 17741898112, 17750293888, 17758673024,
+17767070336, 17775458432, 17783848832, 17792236928, 17800625536,
+17809012352, 17817402752, 17825785984, 17834178944, 17842563968,
+17850955648, 17859344512, 17867732864, 17876119424, 17884511872,
+17892900224, 17901287296, 17909677696, 17918058112, 17926451072,
+17934843776, 17943230848, 17951609216, 17960008576, 17968397696,
+17976784256, 17985175424, 17993564032, 18001952128, 18010339712,
+18018728576, 18027116672, 18035503232, 18043894144, 18052283264,
+18060672128, 18069056384, 18077449856, 18085837184, 18094225792,
+18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
+18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
+18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
+18228444544, 18236833408, 18245220736]
+
+cache_sizes = [
+16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
+17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088,
+18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208,
+19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968,
+20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216,
+21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104,
+22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096,
+23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112,
+24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488,
+25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096,
+25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472,
+26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744,
+27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504,
+28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752,
+29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976,
+30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248,
+31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392,
+32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768,
+33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992,
+34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984,
+35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976,
+36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656,
+36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904,
+37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672,
+38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632,
+39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032,
+40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304,
+41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912,
+42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696,
+43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432,
+44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448,
+45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208,
+46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328,
+47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936,
+47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312,
+48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712,
+49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472,
+50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848,
+51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968,
+52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576,
+53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744,
+54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248,
+55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856,
+56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488,
+57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632,
+58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984,
+58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512,
+59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968,
+60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752,
+61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512,
+62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656,
+63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392,
+64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792,
+65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296,
+66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672,
+67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304,
+68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912,
+69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184,
+69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816,
+70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168,
+71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568,
+72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944,
+73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832,
+74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544,
+75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072,
+76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832,
+77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336,
+78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664,
+79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472,
+80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848,
+81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304,
+81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984,
+82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464,
+83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608,
+84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496,
+85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112,
+86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632,
+87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264,
+88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384,
+89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376,
+90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776,
+91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384,
+92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912,
+92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136,
+93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896,
+94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016,
+95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544,
+96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536,
+97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168,
+98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928,
+99352384, 99482816, 99614272, 99745472, 99876416, 100007104,
+100138048, 100267072, 100401088, 100529984, 100662592, 100791872,
+100925248, 101056064, 101187392, 101317952, 101449408, 101580608,
+101711296, 101841728, 101973824, 102104896, 102235712, 102366016,
+102498112, 102628672, 102760384, 102890432, 103021888, 103153472,
+103284032, 103415744, 103545152, 103677248, 103808576, 103939648,
+104070976, 104201792, 104332736, 104462528, 104594752, 104725952,
+104854592, 104988608, 105118912, 105247808, 105381184, 105511232,
+105643072, 105774784, 105903296, 106037056, 106167872, 106298944,
+106429504, 106561472, 106691392, 106822592, 106954304, 107085376,
+107216576, 107346368, 107478464, 107609792, 107739712, 107872192,
+108003136, 108131392, 108265408, 108396224, 108527168, 108657344,
+108789568, 108920384, 109049792, 109182272, 109312576, 109444928,
+109572928, 109706944, 109837888, 109969088, 110099648, 110230976,
+110362432, 110492992, 110624704, 110755264, 110886208, 111017408,
+111148864, 111279296, 111410752, 111541952, 111673024, 111803456,
+111933632, 112066496, 112196416, 112328512, 112457792, 112590784,
+112715968, 112852672, 112983616, 113114944, 113244224, 113376448,
+113505472, 113639104, 113770304, 113901376, 114031552, 114163264,
+114294592, 114425536, 114556864, 114687424, 114818624, 114948544,
+115080512, 115212224, 115343296, 115473472, 115605184, 115736128,
+115867072, 115997248, 116128576, 116260288, 116391488, 116522944,
+116652992, 116784704, 116915648, 117046208, 117178304, 117308608,
+117440192, 117569728, 117701824, 117833024, 117964096, 118094656,
+118225984, 118357312, 118489024, 118617536, 118749632, 118882112,
+119012416, 119144384, 119275328, 119406016, 119537344, 119668672,
+119798464, 119928896, 120061376, 120192832, 120321728, 120454336,
+120584512, 120716608, 120848192, 120979136, 121109056, 121241408,
+121372352, 121502912, 121634752, 121764416, 121895744, 122027072,
+122157632, 122289088, 122421184, 122550592, 122682944, 122813888,
+122945344, 123075776, 123207488, 123338048, 123468736, 123600704,
+123731264, 123861952, 123993664, 124124608, 124256192, 124386368,
+124518208, 124649024, 124778048, 124911296, 125041088, 125173696,
+125303744, 125432896, 125566912, 125696576, 125829056, 125958592,
+126090304, 126221248, 126352832, 126483776, 126615232, 126746432,
+126876608, 127008704, 127139392, 127270336, 127401152, 127532224,
+127663552, 127794752, 127925696, 128055232, 128188096, 128319424,
+128449856, 128581312, 128712256, 128843584, 128973632, 129103808,
+129236288, 129365696, 129498944, 129629888, 129760832, 129892288,
+130023104, 130154048, 130283968, 130416448, 130547008, 130678336,
+130807616, 130939456, 131071552, 131202112, 131331776, 131464384,
+131594048, 131727296, 131858368, 131987392, 132120256, 132250816,
+132382528, 132513728, 132644672, 132774976, 132905792, 133038016,
+133168832, 133299392, 133429312, 133562048, 133692992, 133823296,
+133954624, 134086336, 134217152, 134348608, 134479808, 134607296,
+134741056, 134872384, 135002944, 135134144, 135265472, 135396544,
+135527872, 135659072, 135787712, 135921472, 136052416, 136182848,
+136313792, 136444864, 136576448, 136707904, 136837952, 136970048,
+137099584, 137232064, 137363392, 137494208, 137625536, 137755712,
+137887424, 138018368, 138149824, 138280256, 138411584, 138539584,
+138672832, 138804928, 138936128, 139066688, 139196864, 139328704,
+139460032, 139590208, 139721024, 139852864, 139984576, 140115776,
+140245696, 140376512, 140508352, 140640064, 140769856, 140902336,
+141032768, 141162688, 141294016, 141426496, 141556544, 141687488,
+141819584, 141949888, 142080448, 142212544, 142342336, 142474432,
+142606144, 142736192, 142868288, 142997824, 143129408, 143258944,
+143392448, 143523136, 143653696, 143785024, 143916992, 144045632,
+144177856, 144309184, 144440768, 144570688, 144701888, 144832448,
+144965056, 145096384, 145227584, 145358656, 145489856, 145620928,
+145751488, 145883072, 146011456, 146144704, 146275264, 146407232,
+146538176, 146668736, 146800448, 146931392, 147062336, 147193664,
+147324224, 147455936, 147586624, 147717056, 147848768, 147979456,
+148110784, 148242368, 148373312, 148503232, 148635584, 148766144,
+148897088, 149028416, 149159488, 149290688, 149420224, 149551552,
+149683136, 149814976, 149943616, 150076352, 150208064, 150338624,
+150470464, 150600256, 150732224, 150862784, 150993088, 151125952,
+151254976, 151388096, 151519168, 151649728, 151778752, 151911104,
+152042944, 152174144, 152304704, 152435648, 152567488, 152698816,
+152828992, 152960576, 153091648, 153222976, 153353792, 153484096,
+153616192, 153747008, 153878336, 154008256, 154139968, 154270912,
+154402624, 154533824, 154663616, 154795712, 154926272, 155057984,
+155188928, 155319872, 155450816, 155580608, 155712064, 155843392,
+155971136, 156106688, 156237376, 156367424, 156499264, 156630976,
+156761536, 156892352, 157024064, 157155008, 157284416, 157415872,
+157545536, 157677248, 157810496, 157938112, 158071744, 158203328,
+158334656, 158464832, 158596288, 158727616, 158858048, 158988992,
+159121216, 159252416, 159381568, 159513152, 159645632, 159776192,
+159906496, 160038464, 160169536, 160300352, 160430656, 160563008,
+160693952, 160822208, 160956352, 161086784, 161217344, 161349184,
+161480512, 161611456, 161742272, 161873216, 162002752, 162135872,
+162266432, 162397888, 162529216, 162660032, 162790976, 162922048,
+163052096, 163184576, 163314752, 163446592, 163577408, 163707968,
+163839296, 163969984, 164100928, 164233024, 164364224, 164494912,
+164625856, 164756672, 164887616, 165019072, 165150016, 165280064,
+165412672, 165543104, 165674944, 165805888, 165936832, 166067648,
+166198336, 166330048, 166461248, 166591552, 166722496, 166854208,
+166985408, 167116736, 167246656, 167378368, 167508416, 167641024,
+167771584, 167903168, 168034112, 168164032, 168295744, 168427456,
+168557632, 168688448, 168819136, 168951616, 169082176, 169213504,
+169344832, 169475648, 169605952, 169738048, 169866304, 169999552,
+170131264, 170262464, 170393536, 170524352, 170655424, 170782016,
+170917696, 171048896, 171179072, 171310784, 171439936, 171573184,
+171702976, 171835072, 171966272, 172097216, 172228288, 172359232,
+172489664, 172621376, 172747712, 172883264, 173014208, 173144512,
+173275072, 173407424, 173539136, 173669696, 173800768, 173931712,
+174063424, 174193472, 174325696, 174455744, 174586816, 174718912,
+174849728, 174977728, 175109696, 175242688, 175374272, 175504832,
+175636288, 175765696, 175898432, 176028992, 176159936, 176291264,
+176422592, 176552512, 176684864, 176815424, 176946496, 177076544,
+177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
+177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
+178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
+179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
+180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
+181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
+181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
+182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
+183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
+184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
+185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
+185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
+186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
+187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
+188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
+189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
+189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
+190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
+191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
+192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
+192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
+193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
+194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
+195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
+196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
+196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
+197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
+198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
+199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
+200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
+200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
+201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
+202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
+203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
+203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
+204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
+205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
+206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
+207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
+207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
+208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
+209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
+210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
+211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
+211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
+212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
+213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
+214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
+214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
+215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
+216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
+217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
+218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
+218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
+219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
+220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
+221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
+222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
+222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
+223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
+224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
+225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
+225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
+226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
+227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
+228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
+229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
+229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
+230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
+231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
+232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
+233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
+233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
+234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
+235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
+236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
+236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
+237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
+238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
+239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
+240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
+240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
+241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
+242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
+243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
+244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
+244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
+245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
+246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
+247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
+247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
+248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
+249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
+250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
+251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
+251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
+252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
+253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
+254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
+255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
+255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
+256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
+257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
+258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
+258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
+259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
+260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
+261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
+262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
+262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
+263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
+264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
+265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
+266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
+266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
+267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
+268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
+269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
+270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
+270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
+271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
+272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
+273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
+273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
+274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
+275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
+276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
+277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
+277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
+278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
+279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
+280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
+281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
+281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
+282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
+283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
+284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
+284950208, 285081536]
+```
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
new file mode 100644
index 00000000000..0d659e167c5
--- /dev/null
+++ "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
@@ -0,0 +1,37 @@
+---
+title: الگوریتم های استخراج
+description: نگاه دقیق تر به الگوریتمهای استفاده شده برای استخراج اتریوم.
+lang: fa
+---
+
+
+اثبات-کار دیگر مکانیزم اجماع اتریوم نیست، و در نتیجه استخراج اتریوم متوفف شده است. در عوض، اتریوم توسط اعتبارسنجهایی که اتریوم را سهام گذاری میکنند، ایمن میشود. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. درباره ادغام، اثبات سهام و سهامگذاری بیشتر بخوانید. این صفحه تنها برای علاقمندان به تاریخچه پروژه است.
+
+
+استخراج اتریوم با استفاده از الگوریتمی به نام Ethash انجام میشد. ایده بنیادی این الگوریتم این است که ماینر تلاش میکند با محاسبات جستجوی فراگیر (brute force)، عدد منحصربفرد (nonce) ورودی را پیدا کند که نتیجه استفاده از آن، تولید هش کوچکتر از حد آستانه تعیین شده توسط سختی محاسبه شده است. سطح سختی به طور دینامیک قابل تنظیم است تا بدین وسیله ساخت بلوک در بازههای زمانی منظم اتفاق بیفتد.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای درک بهتر این قسمت پیشنهاد میکنیم ابتدا مقالات [الگوریتم اجماع اثبات کار](/developers/docs/consensus-mechanisms/pow) و [استخراج](/developers/docs/consensus-mechanisms/pow/mining) را مطالعه کنید.
+
+## الگوریتم دگر هشیموتو (Dagger Hashimoto) {#dagger-hashimoto}
+
+Dagger Hashimoto یک الگوریتم تحقیقاتی پیشرو برای استخراج اتریوم بود که الگوریتم Ethhash جایگزین آن شد. این الگوریتم از ادغام دو الگوریتم Dagger و Hashimoto ایجاد شده بود. این الگوریتم تنها یک پیادهسازی تحقیقاتی بود و در زمان راهاندازی شبکه اصلی اتریوم توسط Ethash جایگزین شد.
+
+[Dagger](http://www.hashcash.org/papers/dagger.html) شامل تولید یک [گراف جهتدار غیرمدور](https://en.wikipedia.org/wiki/Directed_acyclic_graph) است که برش های تصادفی آن باهم هش شدهاند. مولفه اصلی این است که هر نانس فقط به بخش کوچکی از درخت داده کل بزرگ نیاز دارد. محاسبه مجدد زیردرخت برای هر نانس در استخراج ممنوع است - و بنابراین نیاز به ذخیره درخت - اما برای تایید ارزش یک نانس مشکلی وجود ندارد. Dagger طراحی شده بود تا یک جایگزین برای الگوریتمهای موجود مثل Scrypt باشد، الگوریتمهایی که حافظه سختی دارند اما زمانی که سختی حافظه آنها به سطوح ایمن اصل افزایش مییابد، تأیید آن دشوار است. با این حال، Dagger در برابر شتاب سختافزار حافظه مشترک آسیبپذیر بود و به نفع سایر روشهای تحقیق کنار گذاشته شد.
+
+[هشیموتو](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) الگوریتمی است که با محدود بودن به I/O، ویژگی مقاوم بودن در برابر ASIC را به الگوریتم اضافه میکند (یعنی خواندن حافظه، عامل محدود کننده در فرآیند استخراج است). تئوری این است که RAM بیشتر از محاسبات در دسترس است؛ میلیاردها دلار تحقیق در حال حاضر بهینهسازی RAM را برای موارد استفاده مختلف بررسی کردهاند، که اغلب شامل الگوهای دسترسی تقریبا تصادفی است (از این رو به آن حافظه دسترسی تصادفی گفته میشود). در نتیجه، RAM موجود احتمالاً برای ارزیابی الگوریتم نسبتاً نزدیک به حالت بهینه است. هاشیموتو بلاک چین را به عنوان منبع داده استفاده کرده و همزمان مورد 1 و 3 در بالا را برآورده میکند.
+
+Dagger-Hashimoto از نسخههای اصلاح یافته الگوریتمهای Dagger و Hashimoto استفاده کرد. تفاوت بین Dagger Hashimoto و Hashimoto این است که به جای استفاده از بلاک چین به عنوان منبع داده Dagger Hashimoto از یک مجموعه داده سفارشی تولید شده استفاده میکند که این مچموعه داده بر اساس دادههای موجود در بلوکها در هر N بلوک به روز میشود. این مجموعه دادهها با استفاده از الگوریتم Dagger تولید میشود، که امکان محاسبه مؤثر زیرمجموعهای خاص برای هر نانس را برای الگوریتم تأیید کاربر سبک فراهم میکند. تفاوت بین Dagger Hashimoto و Dagger این است که برخلاف Dagger اصلی، مجموعه داده استفاده شده برای استعلام از بلوک نیمه دائمی است و فقط در فواصل زمانی گاه به گاه (به عنوان مثال یک بار در هفته) به روز میشود. این بدان معناست که بخشی از تلاش برای تولید مجموعه داده نزدیک به صفر است، بنابراین استدلالهای سرجیو لرنر در مورد افزایش سرعت حافظه مشترک قابل چشمپوشی میشود.
+
+اطلاعات بیشتر درباره [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto).
+
+## یک الگوریتم اثبات انجام کار برای اتریوم ۱. ۰ {#ethash}
+
+Ethash در واقع همان الگوریتم استخراج بود که در الگوریتم اثبات کار استخراج شبکه اصلی اتریوم که اکنون منسوخ شده، استفاده شده بود. Ethash در واقع نام جدیدی بود که به نسخه خاصی از الگوریتم Dagger-Hashimoto و پس از به روز رسانی قابل توجه آن داده شد، در حالی که هنوز اصول اساسی نسخه قبلی خود را به ارث میبرد. شبکه اصلی اتریوم تاکنون تنها از Ethash استفاده کرده است - Dagger Hashimoto یک نسخه در حال &توسعه از الگوریتم استخراج بود که قبل از شروع استخراج در شبکه اصلی اتریوم، جایگزین شد.
+
+[مطالب بیشتر درباره Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
+
+## بیشتر بخوانید {#further-reading}
+
+_در مورد جامعه منابعی که به شما کمک می کنند بدانید? این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
new file mode 100644
index 00000000000..b280a885915
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
@@ -0,0 +1,207 @@
+---
+title: کتابخانههای وب سرویس بک اند
+description: معرفی وب سرویس کاربرهای اتریوم که به شما اجازه میدهند از برنامه های کاربردی خود با زنجیره بلوکی تعامل داشته باشید.
+lang: fa
+---
+
+برای اینکه برنامه با زنجیره بلوکی اتریوم کار کند (مثال: زنجیره بلوکی را بخواند و به شبکه تراکنش بفرستد)، باید به یک گره اتریوم متصل شود.
+
+برای این منظور، هر کاربر اتریوم مشخصات [JSON-RPC](/developers/docs/apis/json-rpc/) را پیادهسازی میکند، بنابراین مجموعه یکنواختی از [روشها](/developers/docs/apis/json-rpc/#json-rpc-methods) وجود دارد که برنامهها میتوانند به آن تکیه کنند.
+
+اگر میخواهید از یک زبان برنامه نویسی خاص برای اتصال به گره اتریوم استفاده کنید، راهحل خود را انجام دهید اما کتابخانه ها و محیط های متعددی وجود دارند که میتوانند آن را برای شما بسیار ساده کنند. با استفاده از این کتابخانه ها توسعهدهندگان میتوانند بدون دانستن برنامه نویسی پپشرفته و با استفاده از کد یک خطی درخواست های JSON-RPC بدهند که با اتریوم تعامل داشته باشد.
+
+## پیشنیازها {#prerequisites}
+
+[پشته اتریوم](/developers/docs/ethereum-stack/) و [کاربر اتریوم](/developers/docs/nodes-and-clients/) میتوانند مطالب مفیدی باشند.
+
+## چرا از کتابخانه استفاده کنیم؟ {#why-use-a-library}
+
+این کتابخانه ها بسیاری از سختی های ازتباط مستقیم با گره اتریوم را از بین میبرند. همچنین توابع کاربردی فراهم میکنند (مثلا تبدیل اتر به GWEI) بنابراین به عنوان یک توسعه دهنده شما زمان کمتری صرف کارکردن با پیچیدگی های کاربر اتریوم، و زمان بیشتری صرف عملکرد برنامه خود میکنید.
+
+## کتابخانههای در دسترس {#available-libraries}
+
+### زیرساحت و خدمات گره {#infrastructure-and-node-services}
+
+**Alchemy** **_پلتفرم توسعه اتریوم_**
+
+- [alchemy.com](https://www.alchemy.com/)
+- [اسناد](https://docs.alchemy.com/)
+- [گیتهاب](https://github.com/alchemyplatform)
+- [دیسکورد](https://discord.com/invite/alchemyplatform)
+
+**All That Node -** **_Node-as-a-Service._**
+
+- [AllThatNode.com](https://www.allthatnode.com/)
+- [اسناد](https://docs.allthatnode.com)
+- [دیسکورد](https://discord.gg/GmcdVEUbJM)
+
+**Blast by Bware Labs -** **_ سرویس APIهای غیرمتمرکز برای شبکه اصلی اتریوم و شبکه های آزمایشی._**
+
+- [blastapi.io](https://blastapi.io/)
+- [اسناد](https://docs.blastapi.io)
+- [دیسکورد](https://discord.gg/bwarelabs)
+
+**BlockPi -** **_ ارائه خدمات RPC کارآمدتر و سریعتر_**
+
+- [blockpi.io](https://blockpi.io/)
+- [مستندات](https://docs.blockpi.io/)
+- [گیت هاب](https://github.com/BlockPILabs)
+- [دیسکورد](https://discord.com/invite/xTvGVrGVZv)
+
+**دروازه اتریوم Cloudflare.**
+
+- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
+
+**اتراسکن - کاوشگر بلوک و APIهای تراکنش**
+- [اسناد](https://docs.etherscan.io/)
+
+**GetBlock-** **_بلاکچین به عنوان سرویس برای توسعه Web3 _ **
+
+- [GetBlock.io](https://getblock.io/)
+- [مستندات](https://getblock.io/docs/)
+
+**Infura -** **_وب سرویس اتریوم به عنوان سرویس._**
+
+- [infura.io](https://infura.io)
+- [اسناد](https://docs.infura.io/api)
+- [گیتهاب](https://github.com/INFURA)
+
+**Node RPC - _ارائه دهنده مقرون به صرفه ماشین مجازی اتریوم JSON-RPC_**
+
+- [noderpc.xyz](https://www.noderpc.xyz/)
+- [مستندات](https://docs.noderpc.xyz/node-rpc)
+
+**NOWNodes - _گرههای کامل و کاوشگرهای بلوک._**
+
+- [NOWNodes.io](https://nownodes.io/)
+- [اسناد](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro)
+
+**QuickNode -** **_زیرساخت بلاکچین به عنوان سرویس._**
+
+- [quicknode.com](https://quicknode.com)
+- [مستندات](https://www.quicknode.com/docs/welcome)
+- [دیسکورد](https://discord.gg/quicknode)
+
+**Rivet****_ وب سرویسهای اتریوم و اتریوم کلاسیک به عنوان یک خدمت قدرت گرفته از نرمافزار متن باز._**
+
+- [rivet.cloud](https://rivet.cloud)
+- [Documentation](https://rivet.cloud/docs/)
+- [گیتهاب](https://github.com/openrelayxyz/ethercattle-deployment)
+
+**Zmok -** **_گره های اتریوم سرعت گرا به عنوان رابط برنامهنویسی کاربردی JSON-RPC/WebSockets _**
+
+- [zmok.io](https://zmok.io/)
+- [گیتهاب](https://github.com/zmok-io)
+- [مستندات](https://docs.zmok.io/)
+- [دیسکورد](https://discord.gg/fAHeh3ka6s)
+
+### ابزارهای توسعه {#development-tools}
+
+**ethers-kt -** **_Async، کتابخانه کاتلین/جاوا/اندروید با عملکرد بالا برای بلاک چینهای مبتنی بر ماشین مجازی اتریوم_**
+
+- [گیتهاب](https://github.com/Kr1ptal/ethers-kt)
+- [مثالها](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
+- [دیسکورد](https://discord.gg/rx35NzQGSb)
+
+**نتریوم****یک کتابخانه متن باز متحد با زنجیره بلوکی**
+
+- [گیتهاب](https://github.com/Nethereum/Nethereum)
+- [مستندات](http://docs.nethereum.com/en/latest/)
+- [دیسکورد](https://discord.com/invite/jQPrR58FxX)
+
+**ابزارسازی پایتون****_کتابخانه های متعدد برای تعامل با اتریوم به وسیله پایتون._**
+
+- [py.ethereum.org](https://python.ethereum.org/)
+- [گیتهاب web3.py](https://github.com/ethereum/web3.py)
+- [چت web3.py](https://gitter.im/ethereum/web3.py)
+
+**Tatum -** **_پلتفرم نهایی توسعه زنجیره بلوکی._**
+
+- [Tatum](https://tatum.io/)
+- [گیت هاب](https://github.com/tatumio/)
+- [مستندات](https://docs.tatum.io/)
+- [دیسکورد](https://discord.gg/EDmW3kjTC9)
+
+**web3j****_یک کتابخانه متحد جاوا/اندروید/کاتلین/اسکالا برای اتریوم_**
+
+- [گیتهاب](https://github.com/web3j/web3j)
+- [مستندات](https://docs.web3j.io/)
+- [گیتر](https://gitter.im/web3j/web3j)
+
+### خدمات بلاک چین {#blockchain-services}
+
+**BlockCypher -** **_APIهای وب اتریوم._**
+
+- [blockcypher.com](https://www.blockcypher.com/)
+- [اسناد](https://www.blockcypher.com/dev/ethereum/)
+
+** -Chainbase** **_زیرساخت داده Web3 همه در یک مورد برای اتریوم.
+
+- [chainbase.com](https://chainbase.com/)
+- [اسناد](https://docs.chainbase.com/)
+- [دیسکورد](https://discord.gg/Wx6qpqz4AF)
+
+**چِین استک****_گره مشترک و اختصاصی اتریوم به عنوان یک سرویس._**
+
+- [chainstack.com](https://chainstack.com)
+- [مستندات](https://docs.chainbase.com/docs)
+- [مرجع API اتریوم](https://docs.chainstack.com/reference/ethereum-getting-started)
+
+**Coinbase Cloud Node -** **_زیرساخت ایپیآی بلاکچین._**
+
+- [گره ابری کوین بیس](https://www.coinbase.com/cloud)
+- [مستندات](https://docs.cloud.coinbase.com/)
+
+**DataHub توسط Figment -** **_سرویسهای مبتنی بر وب سرویس Web3 با شبکه اصلی و شبکههای تستی اتریوم._**
+
+- [DataHub](https://www.figment.io/)
+- [اسناد](https://docs.figment.io/)
+
+**مورالیس-** **_ارائهدهنده API EVM گرید سازمانی._**
+
+- [moralis.io](https://moralis.io)
+- [اسناد](https://docs.moralis.io/)
+- [گیت هاب](https://github.com/MoralisWeb3)
+- [دیسکورد](https://moralis.io/joindiscord/)
+- [تالار گفتگو](https://forum.moralis.io/)
+
+**NFTPport -** **_API دادههای اتریوم و ضرب._**
+
+- [nftport.xyz](https://www.nftport.xyz/)
+- [اسناد](https://docs.nftport.xyz/)
+- [گیت هاب](https://github.com/nftport/)
+- [دیسکورد](https://discord.com/invite/K8nNrEgqhE)
+
+**توکن ویو-** **_پلتفرم عمومی APIهای رمزنگاری چندگانه بلاک چین._
+
+- [services.tokenview.io](https://services.tokenview.io/)
+- [اسناد](https://services.tokenview.io/docs?type=api)
+- [گیت هاب](https://github.com/Tokenview)
+
+**Watchdata -** **_دسترسی آسان و قابل اتکای وبسرویس به زنجیره بلوکی اتریوم._**
+
+- [Watchdata](https://watchdata.io/)
+- [اسناد](https://docs.watchdata.io/)
+- [دیسکورد](https://discord.com/invite/TZRJbZ6bdn)
+
+**Covalent-** **_APIهای بلاک چین غنی شده برای بیش از 200 زنجیره._**
+
+- [covalenthq.com](https://www.covalenthq.com/)
+- [اسناد](https://www.covalenthq.com/docs/api/)
+- [گیت هاب](https://github.com/covalenthq)
+- [دیسکورد](https://www.covalenthq.com/discord/)
+
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+- [چارچوبهای توسعه](/developers/docs/frameworks/)
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [Web3js را برای استفاده از بلاک چین اتریوم در جاوا اسکریپت راه اندازی کنید](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) *– دستورالعمل هایی برای راه اندازی web3.js در پروژه شما.*
+- [فراخوانی قرارداد هوشمند در جاوا اسکریپت](/developers/tutorials/calling-a-smart-contract-from-javascript/)_- با استفاده از توکن Dai، ببینید چگونه میشود با استفاده از توابع قراردادها را فراخوانی کرد._
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
new file mode 100644
index 00000000000..47c47b754e2
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
@@ -0,0 +1,235 @@
+---
+title: کتابخانه های API جاوا اسکریپت
+description: مقدمه ای بر کتابخانه های کاربرهای جاوا اسکریپت که به شما اجازه تعامل با زنجیره بلوکی را از سوی نرمافزارتان میدهد.
+lang: fa
+---
+
+جهت تعامل یک نرم افزار اینترنتی با زنجیره بلوکی اتریوم (مثلا خواندن داده زنجیره بلوکی و یا فرستادن تراکنش به شبکه)، باید به یک گره اتریوم متصل شد.
+
+برای این منظور، هر مشتری اتریوم مشخصات [JSON-RPC](/developers/docs/apis/json-rpc/) را پیادهسازی میکند، بنابراین مجموعهای یکسان از [روشها](/developers/docs/apis/json-rpc/#json-rpc-methods) وجود دارد که برنامهها میتوانند به آنها تکیه کنند.
+
+اگر میخواهید برای اتصال به یک گره اتریوم از جاوا اسکریپت استفاده کنید، این امکان وجود دارد که از جاوا اسکریپت خالص استفاده کنید اما چندین کتابخانه مناسب درون اکوسیستم وجود دارند که این کار را بسیار سادهتر میسازند. با استفاده از این کتابخانه ها توسعهدهندگان میتوانند بدون دانستن برنامه نویسی پپشرفته و با استفاده از کد یک خطی درخواست های JSON-RPC بدهند که با اتریوم تعامل داشته باشد.
+
+لطفاً توجه داشته باشید که از زمان [ادغام](/roadmap/merge/)، دو قطعه متصل نرم افزار اتریوم - یک کاربر اجرا و یک کاربر توافقی - برای اجرای یک گره مورد نیاز است. لطفاً مطمئن شوید که گره شما شامل یک کاربر اجرایی و توافقی است. اگر گره شما در دستگاه محلی شما نیست (به عنوان مثال، گره شما در یک نمونه AWS در حال اجرا است) آدرس های IP را در آموزش به روز رسانی کنید. برای اطلاعات بیشتر لطفاً به صفحه ما در [اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/) مراجعه کنید.
+
+## پیشنیازها {#prerequisites}
+
+علاوه بر درک جاوا اسکریپت، فهمیدن [پشته اتریوم](/developers/docs/ethereum-stack/) و [کاربرهای اتریوم](/developers/docs/nodes-and-clients/) نیز احتمالا کمک کننده باشد.
+
+## چرا از کتابخانه ها استفاده کنیم؟ {#why-use-a-library}
+
+این کتابخانه ها بسیاری از سختی های ازتباط مستقیم با گره اتریوم را از بین میبرند. همچنین توابع کاربردی فراهم میکنند (مثال: تبدیل اتر به GWEI) بنابراین به عنوان یک توسعه دهنده شما زمان کمتری صرف کارکردن با پیچیدگی های کاربر اتریوم، و زمان بیشتری صرف عملکرد برنامه خود میکنید.
+
+## ویژگی های کتابخانه {#library-features}
+
+### اتصال به گره های اتریوم {#connect-to-ethereum-nodes}
+
+با استفاده از ارائه کنندگان، این کتابخانه ها به شما اجازه اتصال به اتریوم و خواندن داده های آن را میدهند، چه روی JASON-RPC، INFURA، Etherscan، Alchemy یا MetaMask.
+
+**مثال های اتر**
+
+```js
+// یک BrowserProvider یک ارائه دهنده استاندارد Web3 را میپوشاند که این است
+// آنچه MetaMask به عنوان window.ethereum به هر صفحه وارد میکند
+ارائه دهنده const = new ethers.BrowserProvider(window.ethereum)
+
+// پلاگین MetaMask همچنین امکان امضای تراکنشها را فراهم میکند
+// برای تغییر حالت در بلاک چین اتر ارسال و پرداخت کنید.
+// برای این امر، نیاز به امضا کننده حساب داریم...
+const singer = provider.getSinger()
+```
+
+**مثال Web3js**
+
+```js
+var web3 = new Web3("http://localhost:8545")
+// یا
+var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"))
+
+// تغییر فراهم آورنده
+web3.setProvider("ws://localhost:8546")
+// یا
+web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546"))
+
+// استفاده از فراهم آورنده IPC در نود جیاس
+var net = require("net")
+var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // مسیر mac os
+// یا
+var web3 = new Web3(
+ new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net)
+) // مسیر mac os
+// در ویندوز مسیر "\\\\.\\pipe\\geth.ipc" است
+// در لینوکس مسیر "/users/myuser/.ethereum/geth.ipc" است
+```
+
+زمانی که راهاندازی شود، میتوانید موارد زیر را از زنجیره بلوکی ببیند:
+
+- شماره بلوک ها
+- تخمین گاز
+- رویداد های قرارداد های هوشمند
+- شناسه شبکه
+- و موارد دیگر...
+
+### عملکرد کیف پول {#wallet-functionality}
+
+این کتابخانه ها، برای ساخت کیف پول، مدیریت کلید ها و امضای تراکنش، به شما امکان عملکرد میدهند.
+
+در اینجا مثالی از Ethers را داریم
+
+```js
+// ساخت یک کیف پول نمونه از یک یادواره...
+// ارسال اتر
+wallet.sendTransaction(tx)
+```
+
+[همه اسناد را بخوانید](https://docs.ethers.io/v5/api/signer/#Wallet)
+
+زمانی که راهاندازی شد، میتوانید:
+
+- حساب درست کنید
+- تراکنش بفرستید
+- تراکنشها را امضا کنید
+- و موارد دیگر...
+
+### با توابع قرارداد هوشمند تعامل کنید {#interact-with-smart-contract-functions}
+
+کتابخانه های کاربر در جاوا اسکریپت به شما اجازه میدهند توابع قرارداد هوشمند را با خواندن اینترفیس باینری (ABI) از قرارداد کامپایل شده فراخوانی کنید.
+
+ABI به شما توابع قراردادها را در فرمت JSON توضیح میدهد و به شما امکان آن را میدهد که به عنوان یک شئ در جاواسکریپت استفاده کنید.
+
+بنابراین قرارداد solidity در زیر:
+
+```solidity
+contract Test {
+ uint a;
+ address d = 0x12345678901234567890123456789012;
+
+ function Test(uint testInt) { a = testInt;}
+
+ event Event(uint indexed b, bytes32 c);
+
+ event Event2(uint indexed b, bytes32 c);
+
+ function foo(uint b, bytes32 c) returns(address) {
+ Event(b, c);
+ return d;
+ }
+}
+```
+
+باعث انجام این کد جاواسکریپت میشود:
+
+```json
+[{
+ "type":"constructor",
+ "payable":false,
+ "stateMutability":"nonpayable"
+ "inputs":[{"name":"testInt","type":"uint256"}],
+ },{
+ "type":"function",
+ "name":"foo",
+ "constant":false,
+ "payable":false,
+ "stateMutability":"nonpayable",
+ "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}],
+ "outputs":[{"name":"","type":"address"}]
+ },{
+ "type":"event",
+ "name":"Event",
+ "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}],
+ "anonymous":false
+ },{
+ "type":"event",
+ "name":"Event2",
+ "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}],
+ "anonymous":false
+}]
+```
+
+این به آن معنیست که شما میتوانید:
+
+- یک تراکنش برای قرارداد هوشمند بفرستید و روش آن را اجرا کنید
+- فراخوانی برای تخمین میزان گازی که یک اجرای روش، زمانی که در ماشین مجازی اتریوم اجرا شده، میگیرد
+- قرارداد را مستقر کنید
+- و موارد دیگر...
+
+### توابع کاربردی {#utility-functions}
+
+توابع کاربردی به شما میانبرهای آسانی میدهند تا به وسیله آن ها ساختن با اتریوم را برای شما راحت کنند.
+
+مقادیر ETH به طور پیش فرض در Wei هستند. 1ETH = 1,000,000,000,000,000,000 WEI - این بدان معناست که شما با اعداد زیادی سر و کار دارید! `web3.utils.toWei` اتر را برای شما به Wei تبدیل می کند.
+
+و در اترها به صورت زیر است:
+
+```js
+// Get the balance of an account (by address or ENS name)
+balance = await provider.getBalance("ethers.eth")
+// { BigNumber: "2337132817842795605" }
+
+// Often you will need to format the output for the user
+// which prefer to see values in ether (instead of wei)
+ethers.utils.formatEther(balance)
+// '2.337132817842795605'
+```
+
+- [توابع کاربردی Web3js](https://docs.web3js.org/api/web3-utils)
+- [توابع کاربردی اترها](https://docs.ethers.io/v5/api/utils/)
+
+## کتابخانه های موجود {#available-libraries}
+
+**Web3.js -** **_API اتریوم جاوا اسکریپت._**
+
+- [مستندات](https://docs.web3js.org/)
+- [گیتهاب](https://github.com/ethereum/web3.js/)
+
+**Ethers.js -** **_اجرای کامل کیف پول اتریوم و ابزارهای کاربردی در جاوا اسکریپت و تایپ اسکریپت._**
+
+- [مستندات](https://docs.ethers.io/)
+- [گیت هاب](https://github.com/ethers-io/ethers.js/)
+
+**The Graph-** **_پروتکلی برای نمایه سازی داده های اتریوم و IPFS و جستجو در آن با استفاده از GraphQL._**
+
+- [The Graph](https://thegraph.com/)
+- [Graph Explorer](https://thegraph.com/explorer/)
+- [اسناد](https://thegraph.com/docs/)
+- [گیتهاب](https://github.com/graphprotocol/)
+- [ديسكورد](https://thegraph.com/discord)
+
+**light.js -** **_یک کتابخانه JS واکنشپذیر سطح بالا که برای کاربرهای سبک بهینهسازی شده است._**
+
+- [گیتهاب](https://github.com/openethereum/js-libs/tree/master/packages/light.js)
+
+**Web3-wrapper -** **_جایگزین تایپ اسکریپ برای Web3.js_**
+
+- [اسناد](https://0x.org/docs/web3-wrapper#introduction)
+- [گیتهاب](https://github.com/0xProject/0x-monorepo/tree/development/packages/web3-wrapper)
+
+**Alchemyweb3 -** **_یک رپر روی Web3.js با تکرارهای خودکار و apiهای بهبودیافته._**
+
+- [اسناد](https://docs.alchemy.com/reference/api-overview)
+- [گیتهاب](https://github.com/alchemyplatform/alchemy-web3)
+
+**Alchemy NFT API -** **_API برای واکشی داده های NFT، از جمله مالکیت، ویژگی های فراداده و غیره._**
+
+- [مستندات](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
+- [گیتهاب](https://github.com/alchemyplatform/alchemy-web3)
+
+**viem -** **_واسط تایپ اسکریپت برای اتریوم._**
+
+- [اسناد](https://viem.sh)
+- [گیت هاب](https://github.com/wagmi-dev/viem)
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+- [چارچوبهای توسعه](/developers/docs/frameworks/)
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [Web3js را برای استفاده از بلاک چین اتریوم در جاوا اسکریپت راه اندازی کنید](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) *– دستورالعمل هایی برای راه اندازی web3.js در پروژه شما.*
+- [فراخوانی قرارداد هوشمند در جاوا اسکریپت](/developers/tutorials/calling-a-smart-contract-from-javascript/)_- با استفاده از توکن Dai، ببینید چگونه میشود با استفاده از توابع قراردادها را فراخوانی کرد._
+- [ارسال تراکنشها با استفاده از web3 و Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– راهنمای گام به گام برای ارسال تراکنشها از بک اند._
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
new file mode 100644
index 00000000000..026b864b161
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
@@ -0,0 +1,1770 @@
+---
+title: وب سرویس JSON-RPC
+description: یک پروتکل فراخوانی روش از راه دور (RPC) بدون حالت و سبک وزن برای کلاینت های اتریوم.
+lang: fa
+---
+
+برای اینکه یک برنامه نرم افزاری با زنجیره بلوکی اتریوم تعامل داشته باشد (با خواندن داده های زنجیره بلوکی و/یا ارسال تراکنش ها به شبکه)، باید به یک گره (نود) اتریوم متصل شود.
+
+برای این منظور، هر [کلاینت اتریوم](/developers/docs/nodes-and-clients/#execution-clients) یک [مشخصات JSON-RPC](https://github.com/ethereum/execution-apis) را پیادهسازی میکند، بنابراین مجموعه یکنواختی از روشها وجود دارد که برنامهها میتوانند بدون توجه به اجرای گره یا کلاینت خاص به آن تکیه کنند.
+
+JSON-RPC یک پروتکل فراخوانی روش راه دور (RPC) سبک وزن و بدون حالت است. در درجه اول مشخصات، چندین ساختار داده و قوانین پیرامون پردازش آنها را تعریف می کند. در این مبحث مهم نیسب که با چه روشی دادهها را انتقال داد، از طریق همان فرایند، ار طریق سوکتها، بر روی HTTP یا در بسیاری از محیطهای مختلف ارسال پیام. از JSON (RFC 4627) به عنوان فرمت داده استفاده می کند.
+
+## پیادهسازی کلاینت {#client-implementations}
+
+کلاینت های اتریوم هر کدام ممکن است از زبان های برنامه نویسی متفاوتی در هنگام اجرای مشخصات JSON-RPC استفاده کنند. برای جزئیات بیشتر مربوط به زبان های برنامه نویسی خاص، [مستندات کلاینت](/developers/docs/nodes-and-clients/#execution-clients) را مشاهده کنید. توصیه میکنیم اسناد مربوط به هر کلاینت را برای آخرین اطلاعات پشتیبانی وب سرویس بررسی کنید.
+
+## کتابخانه های تسهیل کننده {#convenience-libraries}
+
+در حالی که میتوانید مستقیماً از طریق JSON-RPC API با کلاینت اتریوم تعامل داشته باشید، اغلب گزینههای سادهتری برای توسعهدهندگان dapp وجود دارد. [جاوا اسکریپت](/developers/docs/apis/javascript/#available-libraries) و کتابخانه های [وب سرویس بک اند](/developers/docs/apis/backend/#available-libraries) بسیاری به منظور ارائه wrapper هایی بر روی وب سرویس JSON-RPC وجود دارد. با استفاده از این کتابخانهها، توسعهدهندگان میتوانند روشهای بصری و تک خطی را در زبان برنامهنویسی انتخابی خود بنویسند تا درخواستهای JSON-RPC (تحت سرپوش) را که با اتریوم تعامل دارند، تنظیم کنند.
+
+## APIهای لایه اجماع {#consensus-clients}
+
+این صفحه عمدتاً با JSON-RPC API مورد استفاده توسط کلاینت های اجرا در اتریوم سروکار دارد. با این حال، کلاینت های اجماع یک API RPC نیز دارند که به کاربران اجازه میدهد اطلاعات مربوط به گره، بلوکهای بیکن، حالت بیکن و سایر اطلاعات مربوط به اجماع را مستقیماً از یک گره جستجو کنند. این API در [صفحه وب بیکن API](https://ethereum.github.io/beacon-APIs/#/) مستند شده است.
+
+یک API داخلی نیز برای ارتباط بین کلاینت در یک گره استفاده میشود - یعنی کلاینت اجماع و کلاینت اجرا را قادر میسازد تا دادهها را مبادله کنند. این "Engine API" نامیده می شود و مشخصات آن در [گیتهاب](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) موجود است.
+
+## مشخصات کلاینت اجرا {#spec}
+
+[مشخصات کامل JSON-RPC API را در گیتهاب بخوانید](https://github.com/ethereum/execution-apis). این API در [صفحه وب Execution API](https://ethereum.github.io/execution-apis/api-documentation/) مستند شده است و شامل یک بازرس برای آزمایش همه روشهای موجود است.
+
+## کنوانسیونها {#conventions}
+
+### رمزگذاری مقدار هگز {#hex-encoding}
+
+دو نوع داده کلیدی از JSON منتقل می شوند: آرایه های بایت فرمت نشده و مقادیر. هر دو با یک رمزگذاری هگز ارسال می شوند اما با الزامات مختلف برای قالب بندی.
+
+#### مقادیر {#quantities-encoding}
+
+هنگام رمزگذاری مقادیر (اعداد صحیح، اعداد): رمزگذاری به صورت هگز، پیشوند با "0x"، فشرده ترین نمایش (استثنای جزئی: صفر باید به عنوان "0x0" نمایش داده شود).
+
+در اینجا چند نمونه آورده شده است:
+
+- 0x41 (65 در اعشار)
+- 0x400 (1024 در اعشار)
+- اشتباه: 0x (همیشه باید حداقل یک رقم داشته باشد - صفر همان "0x0" است)
+- اشتباه: 0x0400 (صفرهای ابتدایی مجاز نیستند)
+- اشتباه: ff (باید دارای پیشوند 0x باشد)
+
+### دیتای فرمت نشده {#unformatted-data-encoding}
+
+هنگام رمزگذاری داده های فرمت نشده (آرایه های بایت، آدرس های حساب، هش ها، آرایه های بایت کد): کدگذاری به صورت هگز، پیشوند با "0x"، دو رقم هگز در هر بایت.
+
+در اینجا چند نمونه آورده شده است:
+
+- 0x41 (اندازه 1، "A")
+- 0x004200 (اندازه 3، "0B0")
+- 0x (اندازه 0، "")
+- اشتباه: 0xf0f0f (باید تعداد ارقام زوج باشد)
+- اشتباه: 004200 (باید پیشوند 0x باشد)
+
+### پارامتر بلوک پیش فرض {#default-block}
+
+روش های زیر یک پارامتر بلوک پیش فرض اضافی دارند:
+
+- [eth_getBalance](#eth_getbalance)
+- [eth_getCode](#eth_getcode)
+- [eth_getTransactionCount](#eth_gettransactioncount)
+- [eth_getStorageAt](#eth_getstorageat)
+- [eth_call](#eth_call)
+
+هنگامی که درخواست هایی انجام می شود که بر روی وضعیت اتریوم عمل می کنند، آخرین پارامتر بلوک پیش فرض ارتفاع بلوک را تعیین می کند.
+
+گزینه های زیر برای پارامتر defaultBlock امکان پذیر است:
+
+- `رشته HEX` - یک عدد بلوک عدد صحیح
+- `رشته "Earliest"` برای Earliest/Genesis block
+- `رشته "آخرین"` - برای آخرین بلوک پیشنهادی
+- `رشته "ایمن"` - برای آخرین بلوک سر امن
+- `رشته "نهایی شده"` - برای آخرین بلوک نهایی شده
+- `رشته "در انتظار"` - برای وضعیت/معاملات در انتظار
+
+## مثال ها
+
+در این صفحه نمونههایی از نحوه استفاده از نقاط انتهایی API منفرد JSON_RPC با استفاده از ابزار خط فرمان، [curl](https://curl.se) ارائه میدهیم. این نمونههای نقطه پایان جداگانه در زیر در بخش [نمونههای Curl](#curl-examples) یافت میشوند. در پایین صفحه، ما همچنین یک [نمونه سرتاسری](#usage-example) برای کامپایل و استقرار یک قرارداد هوشمند با استفاده از گره Geth، JSON_RPC API و curl ارائه میدهیم.
+
+## نمونه های Curl {#curl-examples}
+
+نمونه هایی از استفاده از JSON_RPC API با درخواست [curl](https://curl.se) به یک گره اتریوم در زیر ارائه شده است. هر نمونه شامل شرحی از نقطه پایانی خاص، پارامترهای آن، نوع بازگشت، و یک مثال کار شده از نحوه استفاده از آن است.
+
+درخواستهای curl ممکن است پیام خطای مربوط به نوع محتوا را برگردانند. دلیل این امر این است که گزینه `--data` نوع محتوا را روی `application/x-www-form-urlencoded` تنظیم می کند. اگر گره شما از این موضوع شکایت دارد، با قرار دادن `-H "Content-Type: application/json"` در شروع تماس، هدر را به صورت دستی تنظیم کنید. نمونه ها همچنین شامل URL/IP و & ترکیب پورت که باید آخرین آرگومان داده شده به curl باشد (به عنوان مثال `127.0.0.1:8545`). یک درخواست کرل کامل شامل این داده های اضافی به شکل زیر است:
+
+```shell
+curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
+```
+
+## شایعات، حالت، تاریخ {#gossip-state-history}
+
+تعداد انگشت شماری از روشهای هستهای JSON-RPC به دادههایی از شبکه اتریوم نیاز دارند و به طور منظم در سه دسته اصلی قرار میگیرند: _Gossip، State و History_. از پیوندهای موجود در این بخش ها برای رفتن به هر روش استفاده کنید، یا از فهرست مطالب برای بررسی کل لیست روش ها استفاده کنید.
+
+### روش های شایعه پراکنی {#gossip-methods}
+
+> این روش ها سر زنجیره را دنبال می کنند. اینگونه است که تراکنش ها در شبکه راه می یابند، به بلوک ها راه پیدا می کنند و مشتریان چگونه از بلوک های جدید مطلع می شوند.
+
+- [eth_blockNumber](#eth_blocknumber)
+- [eth_sendRawTransaction](#eth_sendrawtransaction)
+
+### روش های حالت {#state_methods}
+
+> روش هایی که وضعیت فعلی تمام داده های ذخیره شده را گزارش می کنند. "وضعیت" مانند یک قطعه RAM مشترک بزرگ است و شامل مانده حساب ها، داده های قرارداد و تخمین گاز است.
+
+- [eth_getBalance](#eth_getbalance)
+- [eth_getStorageAt](#eth_getstorageat)
+- [eth_getTransactionCount](#eth_gettransactioncount)
+- [eth_getCode](#eth_getcode)
+- [eth_call](#eth_call)
+- [eth_estimateGas](#eth_estimategas)
+
+### روش های تاریخ {#history_methods}
+
+> سوابق تاریخی هر بلوک را به زمان پیدایش بازمی گرداند. این مانند یک فایل بزرگ است که فقط ضمیمه می شود و شامل تمام سرصفحه های بلوک، بدنه های بلوک، بلوک های عمو و رسیدهای تراکنش است.
+
+- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash)
+- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber)
+- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash)
+- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber)
+- [eth_getBlockByHash](#eth_getblockbyhash)
+- [eth_getBlockByNumber](#eth_getblockbynumber)
+- [eth_getTransactionByHash](#eth_gettransactionbyhash)
+- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex)
+- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex)
+- [eth_getTransactionReceipt](#eth_gettransactionreceipt)
+- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex)
+- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex)
+
+## JSON-RPC API Playground
+
+میتوانید از [ابزار زمین بازی](https://ethereum-json-rpc.com) برای کشف و آزمایش روشهای API استفاده کنید. همچنین به شما نشان می دهد که کدام روش ها و شبکه ها توسط ارائه دهندگان مختلف گره پشتیبانی می شوند.
+
+## روش های JSON-RPC API {#json-rpc-methods}
+
+### web3_clientVersion {#web3_clientversion}
+
+نسخه کلاینت فعلی را برمی گرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`رشته` - نسخه کلاینت فعلی
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
+// Result
+{
+ "id":67,
+ "jsonrpc":"2.0",
+ "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1"
+}
+```
+
+### web3_sha3 {#web3_sha3}
+
+Keccak-256 (_نه_ استاندارد SHA3-256) دادههای داده شده را برمیگرداند.
+
+**پارامترها**
+
+1. `DATA` - داده هایی که باید به هش SHA3 تبدیل شوند
+
+```js
+params: ["0x68656c6c6f20776f726c64"]
+```
+
+**برمی گرداند**
+
+`DATA` - نتیجه SHA3 رشته داده شده.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
+// Result
+{
+ "id":64,
+ "jsonrpc": "2.0",
+ "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad"
+}
+```
+
+### net_version {#net_version}
+
+شناسه شبکه فعلی را برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`رشته` - شناسه شبکه فعلی.
+
+فهرست کامل شناسههای شبکه فعلی در [chainlist.org](https://chainlist.org) موجود است. برخی از موارد رایج عبارتند از:
+
+- `1`:以太坊主网
+- `5`: شبکه آزمایشی گورلی
+- `11155111`: شبکه آزمایشی Sepolia
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
+// Result
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "3"
+}
+```
+
+### net_listening {#net_listening}
+
+اگر کلاینت فعالانه به اتصالات شبکه گوش دهد، `true` را برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`Boolean` - `درست` هنگام گوش دادن، در غیر این صورت `نادرست`.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
+// Result
+{
+ "id":67,
+ "jsonrpc":"2.0",
+ "result":true
+}
+```
+
+### net_peerCount {#net_peercount}
+
+تعداد همتاهایی که در حال حاضر به مشتری متصل هستند را برمی گرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح از تعداد همتاهای متصل.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
+// Result
+{
+ "id":74,
+ "jsonrpc": "2.0",
+ "result": "0x2" // 2
+}
+```
+
+### eth_protocolVersion {#eth_protocolversion}
+
+نسخه فعلی پروتکل اتریوم را برمی گرداند. توجه داشته باشید که این روش [در Geth موجود نیست](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924).
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`رشته` - نسخه فعلی پروتکل اتریوم
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
+// Result
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "54"
+}
+```
+
+### eth_syncing {#eth_syncing}
+
+یک شی را با دادههای مربوط به وضعیت همگامسازی یا `نادرست` برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+داده های برگشتی دقیق بین پیاده سازی های مشتری متفاوت است. وقتی گره همگامسازی نمیشود، همه کلاینتها `False` را برمیگردانند و همه کلاینتها فیلدهای زیر را برمیگردانند.
+
+`Object|Boolean`، یک شی با دادههای وضعیت همگامسازی یا `FALSE`، در صورت عدم همگامسازی:
+
+- `startingBlock`: `QUANTITY` - بلوکی که در آن واردات شروع شد (فقط پس از اینکه همگامسازی به سرش رسید بازنشانی میشود)
+- `currentBlock`: `QUANTITY` - بلوک فعلی، مانند eth_blockNumber
+- `highestBlock`: `QUANTITY` - تخمین زده شده بالاترین بلوک
+
+با این حال، کلاینت های منفرد ممکن است داده های اضافی را نیز ارائه دهند. به عنوان مثال Geth موارد زیر را برمی گرداند:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "currentBlock": "0x3cf522",
+ "healedBytecodeBytes": "0x0",
+ "healedBytecodes": "0x0",
+ "healedTrienodes": "0x0",
+ "healingBytecode": "0x0",
+ "healingTrienodes": "0x0",
+ "highestBlock": "0x3e0e41",
+ "startingBlock": "0x3cbed5",
+ "syncedAccountBytes": "0x0",
+ "syncedAccounts": "0x0",
+ "syncedBytecodeBytes": "0x0",
+ "syncedBytecodes": "0x0",
+ "syncedStorage": "0x0",
+ "syncedStorageBytes": "0x0"
+ }
+}
+```
+
+در حالی که Besu اینها را برمیگرداند:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 51,
+ "result": {
+ "startingBlock": "0x0",
+ "currentBlock": "0x1518",
+ "highestBlock": "0x9567a3",
+ "pulledStates": "0x203ca",
+ "knownStates": "0x200636"
+ }
+}
+```
+
+برای جزئیات بیشتر به اسناد کلاینت خاص خود مراجعه کنید.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": {
+ startingBlock: '0x384',
+ currentBlock: '0x386',
+ highestBlock: '0x454'
+ }
+}
+// Or when not syncing
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": false
+}
+```
+
+### eth_coinbase {#eth_coinbase}
+
+آدرس کوین بیس مشتری را برمی گرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`DATA`، 20 بایت - آدرس کوین بیس فعلی.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
+// Result
+{
+ "id":64,
+ "jsonrpc": "2.0",
+ "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1"
+}
+```
+
+### eth_chainId {#eth_chainId}
+
+چین آیدی مورد استفاده برای امضای تراکنشهای محافظت شده با پخش مجدد را برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`chainId`، مقدار هگزادسیمال به عنوان رشتهای که عدد صحیح شناسه زنجیره فعلی را نشان میدهد.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
+// Result
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "0x1"
+}
+```
+
+### eth_mining {#eth_mining}
+
+اگر مشتری فعالانه بلوکهای جدید را استخراج کند، `true` را برمیگرداند. این فقط میتواند `true` را برای شبکههای اثبات کار برگرداند و ممکن است از زمان [ادغام](/roadmap/merge/) در برخی از مشتریان موجود نباشد.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`بولین` - `true` را برمیگرداند که مشتری در حال استخراج است، در غیر این صورت `false` برمیگرداند.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
+//
+{
+ "id":71,
+ "jsonrpc": "2.0",
+ "result": true
+}
+```
+
+### eth_hashrate {#eth_hashrate}
+
+تعداد هشهایی را که گره با آن استخراج میکند، برمیگرداند. این فقط میتواند `true` را برای شبکههای اثبات کار برگرداند و ممکن است از زمان [ادغام](/roadmap/merge/) در برخی از مشتریان موجود نباشد.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`QUANTITY` - تعداد هش در ثانیه.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
+// Result
+{
+ "id":71,
+ "jsonrpc": "2.0",
+ "result": "0x38a"
+}
+```
+
+### eth_gasPrice {#eth_gasprice}
+
+تخمینی از قیمت فعلی هر گس را بر حسب wei برمیگرداند. به عنوان مثال، مشتری Besu 100 بلوک آخر را بررسی میکند و میانگین قیمت واحد گس را به طور پیش فرض برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح قیمت فعلی گس در wei.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
+// Result
+{
+ "id":73,
+ "jsonrpc": "2.0",
+ "result": "0x1dfd14000" // 8049999872 Wei
+}
+```
+
+### eth_accounts {#eth_accounts}
+
+فهرستی از آدرسهای متعلق به مشتری را برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`آرایه داده`، 20 بایت - آدرسهای متعلق به مشتری.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"]
+}
+```
+
+### eth_blockNumber {#eth_blocknumber}
+
+تعداد بلوک اخیر را برمیگرداند.
+
+**پارامترها**
+
+هیچکدام
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح از شماره بلوک فعلی که مشتری روی آن قرار دارد.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
+// Result
+{
+ "id":83,
+ "jsonrpc": "2.0",
+ "result": "0x4b7" // 1207
+}
+```
+
+### eth_getBalance {#eth_getbalance}
+
+موجودی حساب آدرس داده شده را برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، 20 بایت - آدرس برای بررسی مقدار حساب (موجودی).
+2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولینترین"`، `"در انتظار"` ، `"ایمن"` یا `"نهایی"`، به [بلوک پیشفرض پارامتر مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
+
+```js
+params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
+```
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح موجودی فعلی در wei.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x0234c8a3397aab58" // 158972490234375000
+}
+```
+
+### eth_getStorageAt {#eth_getstorageat}
+
+مقدار را از یک موقعیت ذخیرهسازی در یک آدرس معین برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، 20 بایت - آدرس محل ذخیره.
+2. `QUANTITY` - عدد صحیح موقعیت در حافظه.
+3. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"`, `"safe"`، `"نهایی شده"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
+
+**برمی گرداند**
+
+`DATA` - مقدار در این موقعیت ذخیرهسازی.
+
+**مثال** محاسبه موقعیت صحیح بستگی به فضای ذخیرهسازی برای بازیابی دارد. قرارداد زیر را که در `0x295a70b2de5e3953354a6a8344e616ed314d7251` با آدرس `0x391694e7e0b0cce554cb130d723a9d29> مستقر شده است در نظر بگیرید.
+
+contract Storage {
+ uint pos0;
+ mapping(address => uint) pos1;
+ function Storage() {
+ pos0 = 1234;
+ pos1[msg.sender] = 5678;
+ }
+}
+`
+
+بازیابی مقدار pos0 مستقیم است:
+
+```js
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
+{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
+```
+
+بازیابی یک عنصر از مپ سختتر است. موقعیت یک عنصر در مپ با موارد زیر محاسبه میشود:
+
+```js
+keccak(LeftPad32(key, 0), LeftPad32(map position, 0))
+```
+
+این بدان معناست که برای بازیابی فضای ذخیرهسازی در pos1 ["0x391694e7e0b0cce554cb130d723a9d27458f9298"] باید موقعیت را با این موارد محاسبه کنیم:
+
+```js
+keccak(
+ decodeHex(
+ "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" +
+ "0000000000000000000000000000000000000000000000000000000000000001"
+ )
+)
+```
+
+کنسول geth همراه با کتابخانه web3 میتواند برای محاسبه استفاده شود:
+
+```js
+> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
+undefined
+> web3.sha3(key, {"encoding": "hex"})
+"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
+```
+
+اکنون برای فچ کردن فضای ذخیرهسازی:
+
+```js
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
+{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
+```
+
+### eth_getTransactionCount {#eth_gettransactioncount}
+
+تعداد تراکنشهای _ارسال شده_ از یک آدرس را برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، بیست بایت - آدرس.
+2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` ، `"ایمن"` یا `"finalized"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
+
+```js
+params: [
+ "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
+ "latest", // state at the latest block
+]
+```
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح تعداد تراکنشهای ارسال شده از این آدرس.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash}
+
+تعداد تراکنشهای یک بلوک را از یک بلوک منطبق با هش بلوک داده شده برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، سی و دو بایت - هش یک بلوک
+
+```js
+پارامترها: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
+```
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح تعداد تراکنشهای این بلوک.
+
+**مثال**
+
+```js
+// درخواست
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}'
+// نتیجه
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x8b" // 139
+}
+```
+
+### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber}
+
+تعداد تراکنشهای یک بلوک مطابق با شماره بلوک داده شده را برمیگرداند.
+
+**پارامترها**
+
+1. `QUANTITY|TAG` - عدد صحیح یک شماره بلوک، یا رشته `"زودترین"`، `"آخرین"`، `"در انتظار"` code>، `"ایمن"` یا `"نهایی"`، مانند [ پارامتر بلوک پیش فرض](/developers/docs/apis/json-rpc/#default-block).
+
+```js
+پارامترها: [
+ "0x13738ca", // 20396234
+]
+```
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح تعداد تراکنشهای این بلوک.
+
+**مثال**
+
+```js
+// درخواست
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}'
+// نتیجه
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x8b" // 139
+}
+```
+
+### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash}
+
+تعداد بلاکهای عمو موجود در یک بلوک را از یک بلوک مطابق با هش بلوک داده شده برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، سی و دو بایت - هش یک بلوک
+
+```js
+پارامترها: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
+```
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح تعداد عموهای این بلوک (یک اصطلاح است).
+
+**مثال**
+
+```js
+// درخواست
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}'
+// نتیجه
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber}
+
+تعداد عموهای موجود در یک بلوک را از یک بلوک مطابق با شماره بلوک داده شده برمیگرداند.
+
+**پارامترها**
+
+1. `QUANTITY|TAG` - عدد صحیح یک عدد بلوک، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` code>، `"ایمن"` یا `"نهایی شده"`، به [پیشفرض مراجعه کنید پارامتر بلوک](/developers/docs/apis/json-rpc/#default-block)
+
+```js
+params: [
+ "0xe8", // 232
+]
+```
+
+**برمی گرداند**
+
+`QUANTITY` - عدد صحیح تعداد عموهای این بلوک (یک اصطلاح است).
+
+**مثال**
+
+```js
+// درخواست
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'
+// نتیجه
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x0" // 0
+}
+```
+
+### eth_getCode {#eth_getcode}
+
+کد را در یک آدرس داده شده برمی گرداند.
+
+**پارامترها**
+
+1. `DATA`، بیست بایت - آدرس
+2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` ، `"ایمن"` یا `"finalized"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
+
+```js
+پارامترها: [
+ "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
+ "0x5daf3b", // 6139707
+]
+```
+
+**برمی گرداند**
+
+`DATA` - کد از آدرس داده شده.
+
+**مثال**
+
+```js
+// درخواست
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}'
+// نتیجه
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029"
+}
+```
+
+### eth_sign {#eth_sign}
+
+روش امضا، یک امضای خاص اتریوم را با این موارد محاسبه میکند: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(پیام) + پیام)))`.
+
+با افزودن یک پیشوند به پیام، امضای محاسبه شده به عنوان یک امضای خاص اتریوم قابل تشخیص است. این از سوء استفاده در جایی که یک برنامه مخرب میتواند دادههای دلخواه (مانند تراکنش) را امضا و از امضا برای جعل هویت قربانی استفاده کند، جلوگیری میکند.
+
+توجه: آدرسی که باید با آن امضا کنید باید قفل باشد.
+
+**پارامترها**
+
+1. `DATA`، بیست بایت - آدرس
+2. `DATA`، N بایت - پیام برای امضا
+
+**برمی گرداند**
+
+`DATA`: امضا
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
+}
+```
+
+### eth_signTransaction {#eth_signtransaction}
+
+تراکنشی را امضا میکند که میتواند بعداً با استفاده از [eth_sendRawTransaction](#eth_sendrawtransaction) به شبکه ارسال شود.
+
+**پارامترها**
+
+1. `Object` - شیء معامله
+
+- `نوع`:
+- `از`: `DATA`، 20 بایت - آدرسی که تراکنش از آن ارسال میشود.
+- `به`: `DATA`، 20 بایت - (اختیاری هنگام ایجاد قرارداد جدید) آدرسی که تراکنش به آن هدایت میشود.
+- `گس`: `QUANTITY` - (اختیاری، پیشفرض: 90000) عدد صحیح گس ارائه شده برای اجرای تراکنش. گس استفاده نشده را برمیگرداند.
+- `gasPrice`: `QUANTITY` - (اختیاری، پیشفرض: باید تعیین شود) عدد صحیح گس قیمت مورد استفاده برای هر گس پرداختی، بر حسب Wei.
+- `مقدار`: `QUANTITY` - (اختیاری) عدد صحیح از مقدار ارسال شده با این تراکنش، بر حسب Wei.
+- `data`: `DATA` - کد کامپایل شده یک قرارداد یا هش امضای متد فراخوانی شده و پارامترهای کدگذاری شده.
+- `نانس`: `QUANTITY` - (اختیاری) عدد صحیح یک نانس. این مورد اجازه میدهد تا تراکنشهای در انتظار خود را که از همان نانس استفاده میکنند، بازنویسی کند.
+
+**برمی گرداند**
+
+`DATA`، شی تراکنش رمزگذاری شده با RLP که توسط حساب مشخص شده امضا شده است.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
+// Result
+{
+ "id": 1,
+ "jsonrpc": "2.0",
+ "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
+}
+```
+
+### eth_sendTransaction {#eth_sendtransaction}
+
+اگر فیلد داده حاوی کد باشد، تراکنش تماس یا فراخوانی پیام جدید یا ایجاد قرارداد ایجاد میکند و آن را با استفاده از حساب مشخص شده در `from` امضا میکند.
+
+**پارامترها**
+
+1. `Object` - شیء معامله
+
+- `از`: `DATA`، 20 بایت - آدرسی که تراکنش از آن ارسال میشود.
+- `به`: `DATA`، 20 بایت - (اختیاری هنگام ایجاد قرارداد جدید) آدرسی که تراکنش به آن هدایت میشود.
+- `گس`: `QUANTITY` - (اختیاری، پیشفرض: 90000) عدد صحیح گس ارائه شده برای اجرای تراکنش. گس استفاده نشده را برمیگرداند.
+- `gasPrice`: `QUANTITY` - (اختیاری، پیشفرض: باید تعیین شود) عدد صحیح gasPrice استفاده شده برای هر گس پرداختی.
+- `مقدار`: `QUANTITY` - (اختیاری) عدد صحیح مقدار ارسال شده با این تراکنش.
+- `ورودی`: `DATA` - کد کامپایل شده یک قرارداد یا هش امضای متد فراخوانی شده و پارامترهای کدگذاری شده.
+- `نانس`: `QUANTITY` - (اختیاری) عدد صحیح یک نانس. این مورد اجازه میدهد تا تراکنشهای در انتظار خود را که از همان نانس استفاده میکنند، بازنویسی کند.
+
+```js
+params: [
+ {
+ from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155",
+ to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
+ gas: "0x76c0", // 30400
+ gasPrice: "0x9184e72a000", // 10000000000000
+ value: "0x9184e72a", // 2441406250
+ input:
+ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
+ },
+]
+```
+
+**برمی گرداند**
+
+`DATA`، 32 بایت - هش تراکنش، یا هش صفر اگر تراکنش هنوز در دسترس نباشد.
+
+از [eth_getTransactionReceipt](#eth_gettransactionreceipt) برای دریافت آدرس قرارداد، پس از پیشنهاد تراکنش در یک بلوک، هنگام ایجاد قرارداد استفاده کنید.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
+}
+```
+
+### eth_sendRawTransaction {#eth_sendrawtransaction}
+
+تراکنش تماس یا فراخوانی پیام جدید یا ایجاد قرارداد برای تراکنشهای امضا شده ایجاد میکند.
+
+**پارامترها**
+
+1. `DATA`، دادههای تراکنش امضا شده.
+
+```js
+params: [
+ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
+]
+```
+
+**برمی گرداند**
+
+`DATA`، 32 بایت - هش تراکنش، یا هش صفر اگر تراکنش هنوز در دسترس نباشد.
+
+از [eth_getTransactionReceipt](#eth_gettransactionreceipt) برای دریافت آدرس قرارداد، پس از پیشنهاد تراکنش در یک بلوک، هنگام ایجاد قرارداد استفاده کنید.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
+}
+```
+
+### eth_call {#eth_call}
+
+بدون ایجاد تراکنش در زنجیره بلوک، یک تماس پیام جدید را بلافاصله اجرا میکند. اغلب برای اجرای توابع قرارداد هوشمند فقط خواندنی، به عنوان مثال `balanceOf` برای قرارداد ERC-20 استفاده میشود.
+
+**پارامترها**
+
+1. `Object` - شیء فراخوانی تراکنش
+
+- `از`: `DATA`, 20 بایت - آدرسی که تراکنش از آن فرستاده میشود (اختیاری).
+- `به`: `DATA`، 20 بایت - آدرسی که تراکنش به آن هدایت میشود.
+- `گس`: `QUANTITY` - (اختیاری) عدد صحیح گس ارائه شده برای اجرای تراکنش. eth_call گس صفر مصرف میکند، اما این پارامتر ممکن است برای برخی از اجراها مورد نیاز باشد.
+- `gasPrice`: `QUANTITY` - (اختیاری) عدد صحیح gasPrice استفاده شده برای هر گس پرداختی
+- `مقدار`: `QUANTITY` - (اختیاری) عدد صحیح مقدار ارسال شده با این تراکنش
+- `ورودی`: `DATA` - (اختیاری) هش امضای روش و پارامترهای کدگذاری شده. برای جزئیات به [ABI قرارداد اتریوم در مستندات یا داکیومنت سالیدیتی](https://docs.soliditylang.org/en/latest/abi-spec.html) مراجعه کنید.
+
+2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` ، `"ایمن"` یا `"finalized"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
+
+**برمی گرداند**
+
+`DATA` - مقدار بازگشتی قرارداد اجرا شده.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x"
+}
+```
+
+### eth_estimateGas {#eth_estimategas}
+
+تخمینی از میزان گس لازم برای تکمیل تراکنش را ایجاد و برمیگرداند. تراکنش به بلاک چین اضافه نخواهد شد. توجه داشته باشید که به دلایل مختلفی از جمله مکانیک ماشین مجازی اتریوم و عملکرد گره، تخمین ممکن است به طور قابل توجهی بیشتر از مقدار گس مورد استفاده در معامله باشد.
+
+**پارامترها**
+
+به پارامترهای [eth_call](#eth_call) مراجعه کنید، با این تفاوت که همه ویژگیها اختیاری هستند. اگر محدودیت گس مشخص نشده باشد، گس از حد گس بلوک از بلوک در حال انتظار به عنوان کران بالایی استفاده میکند. در نتیجه برآورد برگشتی ممکن است برای اجرای تماس/معامله زمانی که مقدار گس بیشتر از حد گس بلوک در انتظار باشد کافی نباشد.
+
+**برمی گرداند**
+
+`QUANTITY` - مقدار گس مصرفی.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x5208" // 21000
+}
+```
+
+### eth_getBlockByHash {#eth_getblockbyhash}
+
+اطلاعات مربوط به یک بلوک را با هش برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، 32 بایت - هش یک بلوک.
+2. `بولین` - اگر `true` اشیاء تراکنش کامل را برمیگرداند، اگر `false` فقط هشهای تراکنشها را برمیگرداند.
+
+```js
+params: [
+ "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
+ false,
+]
+```
+
+**برمی گرداند**
+
+`آبجکت` - یک شیء بلوک، یا `null` هنگامی که هیچ بلوکی پیدا نشد:
+
+- `شماره`: `QUANTITY` - شماره بلوک. `null` زمانی که بلوک در حال انتظار است.
+- `هش`: `DATA`، 32 بایت - هش بلوک. `null` زمانی که بلوک در حال انتظار است.
+- `parentHash`: `DATA`، 32 بایت - هش بلوک والد.
+- `nonce`: `DATA`، 8 بایت - هش اثبات کار ایجاد شده. `null` زمانی که بلوک در حال انتظار است.
+- `sha3Uncles`: `DATA`، 32 بایت - SHA3 از دادههای عمو یا آنکل در بلوک.
+- `logsBloom`: `DATA`، 256 بایت - فیلتر بلوم گزارشهای بلوک. `null` زمانی که بلوک در حال انتظار است.
+- `transactionsRoot`: `DATA`، 32 بایت - ریشه آزمایش تراکنش بلوک.
+- `stateRoot`: `DATA`، 32 بایت - ریشه آزمایش وضعیت نهایی بلوک.
+- `receiptsRoot`: `DATA`، 32 بایت - ریشه آزمایشی رسیدهای بلوک.
+- `miner`: `DATA`، 20 بایت - آدرس ذینفعی که پاداش استخراج به او داده شده است.
+- `سختی`: `QUANTITY` - عدد صحیح دشواری این بلوک.
+- `totalDifficulty`: `QUANTITY` - عدد صحیح کل سختی زنجیره تا این بلوک.
+- `extraData`: `DATA` - قسمت "داده اضافی" این بلوک.
+- `size`: `QUANTITY` - عدد صحیح اندازه این بلوک بر حسب بایت.
+- `gasLimit`: `QUANTITY` - حداکثر گس مجاز در این بلوک.
+- `gasUsed`: `QUANTITY` - کل گس مصرف شده توسط همه تراکنشهای این بلوک.
+- `مهر زمانی یا تایم استمپ`: `QUANTITY` - مهر زمانی یونیکس برای زمانی که بلوک جمعآوری شده است.
+- `معاملات`: `آرایه` - آرایهای از اشیاء تراکنش، یا هش تراکنشهای 32 بایتی بسته به آخرین پارامتر داده شده.
+- `عموها`: `آرایه` - آرایه هشهای عمو.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
+// Result
+{
+{
+"jsonrpc": "2.0",
+"id": 1,
+"result": {
+ "difficulty": "0x4ea3f27bc",
+ "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
+ "gasLimit": "0x1388",
+ "gasUsed": "0x0",
+ "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
+ "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
+ "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171",
+ "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843",
+ "nonce": "0x689056015818adbe",
+ "number": "0x1b4",
+ "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54",
+ "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
+ "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
+ "size": "0x220",
+ "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d",
+ "timestamp": "0x55ba467c",
+ "totalDifficulty": "0x78ed983323d",
+ "transactions": [
+ ],
+ "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
+ "uncles": [
+ ]
+}
+}
+```
+
+### eth_getBlockByNumber {#eth_getblockbynumber}
+
+اطلاعات مربوط به یک بلوک را با شماره بلوک برمیگرداند.
+
+**پارامترها**
+
+1. `QUANTITY|TAG` - عدد صحیح یک شماره بلوک، یا رشته `"زودترین"`، `"آخرین"`، `"در انتظار"` code>، `"ایمن"` یا `"نهایی"`، مانند [ پارامتر بلوک پیش فرض](/developers/docs/apis/json-rpc/#default-block).
+2. `بولین` - اگر `true` اشیاء تراکنش کامل را برمیگرداند، اگر `false` فقط هشهای تراکنشها را برمیگرداند.
+
+```js
+params: [
+ "0x1b4", // 436
+ true,
+]
+```
+
+**برمیگرداند** به [eth_getBlockByHash](#eth_getblockbyhash) مراجعه کنید
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
+```
+
+نتیجه را ببینید [eth_getBlockByHash](#eth_getblockbyhash)
+
+### eth_getTransactionByHash {#eth_gettransactionbyhash}
+
+اطلاعات مربوط به تراکنش درخواست شده توسط هش تراکنش را برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، 32 بایت - هش تراکنش
+
+```js
+params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
+```
+
+**برمی گرداند**
+
+`آبجکت` - یک شیء تراکنش یا `null` هنگامی که هیچ تراکنشی پیدا نشد:
+
+- `blockHash`: `DATA`، 32 بایت - هش بلوکی که این تراکنش در آن بوده است. `null` زمانی که در حال تعلیق یا سپری شدن است.
+- `blockNumber`: `QUANTITY` - شماره بلوکی که این تراکنش در آن بوده است. `null` زمانی که در حال تعلیق یا سپری شدن است.
+- `از`: `DATA`، 20 بایت - آدرس فرستنده.
+- `گاز`: `QUANTITY` - گس ارائه شده توسط فرستنده.
+- `gasPrice`: `QUANTITY` - قیمت گس ارائه شده توسط فرستنده بر حسب Wei.
+- `هش`: `DATA`، 32 بایت - هش تراکنش.
+- `ورودی`: `DATA` - دادهها همراه با تراکنش ارسال میشوند.
+- `nonce`: `QUANTITY` - تعداد تراکنشهایی که فرستنده قبل از این تراکنش انجام داده است.
+- `به`: `DATA`، 20 بایت - آدرس گیرنده. `null` زمانی که یک معامله ایجاد قرارداد باشد.
+- `transactionIndex`: `QUANTITY` - عدد صحیح موقعیت شاخص تراکنشها در بلوک. `null` زمانی که در حال تعلیق یا سپری شدن است.
+- `مقدار`: `QUANTITY` - مقدار منتقل شده بر حسب Wei.
+- `v`: `QUANTITY` - شناسه بازیابی ECDSA
+- `r`: `QUANTITY` - امضای ECDSA r
+- `s`: `QUANTITY` - امضای ECDSA
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
+// Result
+{
+ "jsonrpc":"2.0",
+ "id":1,
+ "result":{
+ "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "blockNumber":"0x5daf3b", // 6139707
+ "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d",
+ "gas":"0xc350", // 50000
+ "gasPrice":"0x4a817c800", // 20000000000
+ "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b",
+ "input":"0x68656c6c6f21",
+ "nonce":"0x15", // 21
+ "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb",
+ "transactionIndex":"0x41", // 65
+ "value":"0xf3dbb76162000", // 4290000000000000
+ "v":"0x25", // 37
+ "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea",
+ "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c"
+ }
+}
+```
+
+### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex}
+
+اطلاعات مربوط به تراکنش را بر اساس هش بلوک و موقعیت شاخص تراکنش برمیگرداند.
+
+**پارامترها**
+
+1. `DATA`، 32 بایت - هش یک بلوک.
+2. `QUANTITY` - عدد صحیح موقعیت شاخص یا ایندکس تراکنش.
+
+```js
+پارامترها: [
+ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "0x0", // 0
+]
+```
+
+**برمیگرداند** ببینید[eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+**مثال**
+
+```js
+// درخواست
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
+```
+
+نتیجه را ببینید [eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
+
+اطلاعات مربوط به یک تراکنش را بر اساس شماره بلوک و موقعیت شاخص تراکنش برمیگرداند.
+
+**پارامترها**
+
+1. `QUANTITY|TAG` - یک شماره بلوک، یا رشته `"زودترین"`، `"آخرین"`، `"در انتظار"` مانند [بلوک پیشفرض، `"ایمن"` یا `"نهایی"` پارامتر](/developers/docs/apis/json-rpc/#default-block).
+2. `QUANTITY` - موقعیت شاخص تراکنش.
+
+```js
+params: [
+ "0x9c47cf", // 10241999
+ "0x24", // 36
+]
+```
+
+**برمیگرداند** ببینید[eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
+```
+
+نتیجه را ببینید [eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+### eth_getTransactionReceipt {#eth_gettransactionreceipt}
+
+رسید یک تراکنش را با هش تراکنش برمیگرداند.
+
+**توجه داشته باشید** که رسید برای تراکنشهای در انتظار موجود نیست.
+
+**پارامترها**
+
+1. `DATA`، 32 بایت - هش تراکنش
+
+```js
+params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
+```
+
+`آبجکت` - یک شیء رسید تراکنش، یا `null` زمانی که هیچ رسیدی پیدا نشد:
+
+- `transactionHash`: `DATA`، 32 بایت - هش تراکنش.
+- `transactionIndex`: `QUANTITY` - عدد صحیح موقعیت شاخص تراکنشها در بلوک.
+- `blockHash`: `DATA`، 32 بایت - هش بلوکی که این تراکنش در آن بوده است.
+- `blockNumber`: `QUANTITY` - شماره بلوکی که این تراکنش در آن بوده است.
+- `از`: `DATA`، 20 بایت - آدرس فرستنده.
+- `به`: `DATA`، 20 بایت - آدرس گیرنده. زمانی که یک معامله ایجاد قرارداد باشد، null است.
+- `cumulativeGasUsed` : `QUANTITY` - کل مقدار گسی که هنگام انجام این تراکنش در بلوک استفاده شده است.
+- `effectiveGasPrice` : `QUANTITY` - مجموع هزینه پایه و انعام پرداخت شده به ازای هر واحد گس.
+- `gasUsed`: `QUANTITY` - مقدار گس مصرفی تنها توسط این تراکنش خاص.
+- `contractAddress`: `DATA`, 20 بایت - آدرس قرارداد ایجاد شد، اگر تراکنش یک ایجاد قرارداد بود، در غیر اینصورت `صفر`.
+-
+- `logsBloom`: `DATA`, 256 Bytes - Bloom filter for light clients to quickly retrieve related logs.
+- `type`: `QUANTITY` - integer of the transaction type, `0x0` for legacy transactions, `0x1` for access list types, `0x2` for dynamic fees.
+
+It also returns _either_ :
+
+- `root` : `DATA` 32 bytes of post-transaction stateroot (pre Byzantium)
+- `status`: `QUANTITY` either `1` (success) or `0` (failure)
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
+// Result
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "blockHash":
+ "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
+ "blockNumber": "0xeff35f",
+ "contractAddress": null, // string of the address if it was created
+ "cumulativeGasUsed": "0xa12515",
+ "effectiveGasPrice": "0x5a9c688d4",
+ "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
+ "gasUsed": "0xb4c8",
+ "logs": [{
+ // logs as returned by getFilterLogs, etc.
+ }],
+ "logsBloom": "0x00...0", // 256 byte bloom filter
+ "status": "0x1",
+ "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
+ "transactionHash":
+ "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5",
+ "transactionIndex": "0x66",
+ "type": "0x2"
+ }
+}
+```
+
+### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
+
+Returns information about a uncle of a block by hash and uncle index position.
+
+**پارامترها**
+
+1. `DATA`, 32 Bytes - The hash of a block.
+2. `QUANTITY` - The uncle's index position.
+
+```js
+پارامترها: [
+ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "0x0", // 0
+]
+```
+
+**برمیگرداند** به [eth_getBlockByHash](#eth_getblockbyhash) مراجعه کنید
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
+```
+
+نتیجه را ببینید [eth_getBlockByHash](#eth_getblockbyhash)
+
+**Note**: An uncle doesn't contain individual transactions.
+
+### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
+
+Returns information about a uncle of a block by number and uncle index position.
+
+**پارامترها**
+
+1. `QUANTITY|TAG` - a block number, or the string `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, as in the [default block parameter](/developers/docs/apis/json-rpc/#default-block).
+2. `QUANTITY` - the uncle's index position.
+
+```js
+params: [
+ "0x29c", // 668
+ "0x0", // 0
+]
+```
+
+**برمیگرداند** به [eth_getBlockByHash](#eth_getblockbyhash) مراجعه کنید
+
+**Note**: An uncle doesn't contain individual transactions.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
+```
+
+نتیجه را ببینید [eth_getBlockByHash](#eth_getblockbyhash)
+
+### eth_newFilter {#eth_newfilter}
+
+Creates a filter object, based on filter options, to notify when the state changes (logs). To check if the state has changed, call [eth_getFilterChanges](#eth_getfilterchanges).
+
+**A note on specifying topic filters:** Topics are order-dependent. A transaction with a log with topics [A, B] will be matched by the following topic filters:
+
+- `[]` "anything"
+- `[A]` "A in first position (and anything after)"
+- `[null, B]` "anything in first position AND B in second position (and anything after)"
+- `[A, B]` "A in first position AND B in second position (and anything after)"
+- `[[A, B], [A, B]]` "(A OR B) in first position AND (A OR B) in second position (and anything after)"
+- **پارامترها**
+
+1. `Object` - The filter options:
+
+- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
+- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
+- `address`: `DATA|Array`, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
+- `topics`: `Array of DATA`, - (optional) Array of 32 Bytes `DATA` topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.
+
+```js
+params: [
+ {
+ fromBlock: "0x1",
+ toBlock: "0x2",
+ address: "0x8888f1f195afa192cfee860698584c030f4c9db1",
+ topics: [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ null,
+ [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc",
+ ],
+ ],
+ },
+]
+```
+
+**Returns** `QUANTITY` - A filter id.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_newBlockFilter {#eth_newblockfilter}
+
+Creates a filter in the node, to notify when a new block arrives. To check if the state has changed, call [eth_getFilterChanges](#eth_getfilterchanges).
+
+**Parameters** None
+
+**Returns** `QUANTITY` - A filter id.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
+
+Creates a filter in the node, to notify when new pending transactions arrive. To check if the state has changed, call [eth_getFilterChanges](#eth_getfilterchanges).
+
+**Parameters** None
+
+**Returns** `QUANTITY` - A filter id.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_uninstallFilter {#eth_uninstallfilter}
+
+Uninstalls a filter with given id. Should always be called when watch is no longer needed. Additionally Filters timeout when they aren't requested with [eth_getFilterChanges](#eth_getfilterchanges) for a period of time.
+
+**پارامترها**
+
+1. `QUANTITY` - The filter id.
+
+```js
+params: [
+ "0xb", // 11
+]
+```
+
+**Returns** `Boolean` - `true` if the filter was successfully uninstalled, otherwise `false`.
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": true
+}
+```
+
+### eth_getFilterChanges {#eth_getfilterchanges}
+
+Polling method for a filter, which returns an array of logs which occurred since last poll.
+
+**پارامترها**
+
+1. `QUANTITY` - the filter id.
+
+```js
+params: [
+ "0x16", // 22
+]
+```
+
+**Returns** `Array` - Array of log objects, or an empty array if nothing has changed since last poll.
+
+- For filters created with `eth_newBlockFilter` the return are block hashes (`DATA`, 32 Bytes), e.g. `["0x3454645634534..."]`.
+- For filters created with `eth_newPendingTransactionFilter` the return are transaction hashes (`DATA`, 32 Bytes), e.g. `["0x6345343454645..."]`.
+- For filters created with `eth_newFilter` logs are objects with following params:
+ - `removed`: `TAG` - `true` when the log was removed, due to a chain reorganization. `false` if its a valid log.
+ - `logIndex`: `QUANTITY` - عدد صحیح موقعیت فهرست گزارش در بلوک. `null` زمانی که گزارش در حال انتظار است.
+ - `transactionIndex`: `QUANTITY` - integer of the transactions index position log was created from. `null` زمانی که گزارش در حال انتظار است.
+ - `transactionHash`: `DATA`, 32 Bytes - hash of the transactions this log was created from. `null` زمانی که گزارش در حال انتظار است.
+ - `blockHash`: `DATA`, 32 Bytes - hash of the block where this log was in. `null` زمانی که در حال تعلیق یا سپری شدن است. `null` زمانی که گزارش در حال انتظار است.
+ - `blockNumber`: `QUANTITY` - the block number where this log was in. `null` زمانی که در حال تعلیق یا سپری شدن است. `null` زمانی که گزارش در حال انتظار است.
+ - `address`: `DATA`, 20 Bytes - address from which this log originated.
+ - `data`: `DATA` - contains zero or more 32 Bytes non-indexed arguments of the log.
+ - `topics`: `Array of DATA` - Array of 0 to 4 32 Bytes `DATA` of indexed log arguments. (In _solidity_: The first topic is the _hash_ of the signature of the event (e.g. `Deposit(address,bytes32,uint256)`), except you declared the event with the `anonymous` specifier.)
+- **مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc":"2.0",
+ "result": [{
+ "logIndex": "0x1", // 1
+ "blockNumber":"0x1b4", // 436
+ "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
+ "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
+ "transactionIndex": "0x0", // 0
+ "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
+ "data":"0x0000000000000000000000000000000000000000000000000000000000000000",
+ "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
+ },{
+ ...
+ }]
+}
+```
+
+### eth_getFilterLogs {#eth_getfilterlogs}
+
+Returns an array of all logs matching filter with given id.
+
+**پارامترها**
+
+1. `QUANTITY` - The filter id.
+
+```js
+params: [
+ "0x16", // 22
+]
+```
+
+**Returns** See [eth_getFilterChanges](#eth_getfilterchanges)
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
+```
+
+Result see [eth_getFilterChanges](#eth_getfilterchanges)
+
+### eth_getLogs {#eth_getlogs}
+
+Returns an array of all logs matching a given filter object.
+
+**پارامترها**
+
+1. `Object` - The filter options:
+
+- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
+- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
+- `address`: `DATA|Array`, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
+- `topics`: `Array of DATA`, - (optional) Array of 32 Bytes `DATA` topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.
+- `blockhash`: `DATA`, 32 Bytes - (optional, **future**) With the addition of EIP-234, `blockHash` will be a new filter option which restricts the logs returned to the single block with the 32-byte hash `blockHash`. Using `blockHash` is equivalent to `fromBlock` = `toBlock` = the block number with hash `blockHash`. If `blockHash` is present in the filter criteria, then neither `fromBlock` nor `toBlock` are allowed.
+
+```js
+params: [
+ {
+ topics: [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ ],
+ },
+]
+```
+
+**Returns** See [eth_getFilterChanges](#eth_getfilterchanges)
+
+**مثال**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
+```
+
+Result see [eth_getFilterChanges](#eth_getfilterchanges)
+
+## Usage Example {#usage-example}
+
+### Deploying a contract using JSON_RPC {#deploying-contract}
+
+This section includes a demonstration of how to deploy a contract using only the RPC interface. There are alternative routes to deploying contracts where this complexity is abstracted away—for example, using libraries built on top of the RPC interface such as [web3.js](https://web3js.readthedocs.io/) and [web3.py](https://github.com/ethereum/web3.py). These abstractions are generally easier to understand and less error-prone, but it is still helpful to understand what is happening under the hood.
+
+The following is a straightforward smart contract called `Multiply7` that will be deployed using the JSON-RPC interface to an Ethereum node. This tutorial assumes the reader is already running a Geth node. More information on nodes and clients is available [here](/developers/docs/nodes-and-clients/run-a-node). Please refer to individual [client](/developers/docs/nodes-and-clients/) documentation to see how to start the HTTP JSON-RPC for non-Geth clients. Most clients default to serving on `localhost:8545`.
+
+```javascript
+contract Multiply7 {
+ event Print(uint);
+ function multiply(uint input) returns (uint) {
+ Print(input * 7);
+ return input * 7;
+ }
+}
+```
+
+The first thing to do is make sure the HTTP RPC interface is enabled. This means we supply Geth with the `--http` flag on startup. In this example we use the Geth node on a private development chain. Using this approach we don't need ether on the real network.
+
+```bash
+geth --http --dev console 2>>geth.log
+```
+
+This will start the HTTP RPC interface on `http://localhost:8545`.
+
+We can verify that the interface is running by retrieving the Coinbase address and balance using [curl](https://curl.se). Please note that data in these examples will differ on your local node. If you want to try these commands, replace the request params in the second curl request with the result returned from the first.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method":"eth_coinbase", "id":1}' -H "Content-Type: application/json" localhost:8545
+{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
+
+curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
+{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"}
+```
+
+Because numbers are hex encoded, the balance is returned in wei as a hex string. If we want to have the balance in ether as a number we can use web3 from the Geth console.
+
+```javascript
+web3.fromWei("0x1639e49bba16280000", "ether")
+// "410"
+```
+
+Now that there is some ether on our private development chain, we can deploy the contract. The first step is to compile the Multiply7 contract to byte code that can be sent to the EVM. To install solc, the Solidity compiler, follow the [Solidity documentation](https://docs.soliditylang.org/en/latest/installing-solidity.html). (You might want to use an older `solc` release to match [the version of compiler used for our example](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
+
+The next step is to compile the Multiply7 contract to byte code that can be send to the EVM.
+
+```bash
+echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
+
+======= :Multiply7 =======
+Binary:
+6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
+```
+
+Now that we have the compiled code we need to determine how much gas it costs to deploy it. The RPC interface has an `eth_estimateGas` method that will give us an estimate.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
+{"jsonrpc":"2.0","id":5,"result":"0x1c31e"}
+```
+
+And finally deploy the contract.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545
+{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
+```
+
+The transaction is accepted by the node and a transaction hash is returned. This hash can be used to track the transaction. The next step is to determine the address where our contract is deployed. Each executed transaction will create a receipt. This receipt contains various information about the transaction such as in which block the transaction was included and how much gas was used by the EVM. If a transaction creates a contract it will also contain the contract address. We can retrieve the receipt with the `eth_getTransactionReceipt` RPC method.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
+{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
+```
+
+قرارداد ما در `0x4d03d617d700cf81935d7f797f4e2ae719648262` ایجاد شد. نتیجه صفر به جای رسید به این معنی است که تراکنش هنوز در یک بلوک گنجانده نشده است. یک لحظه صبر و بررسی کنید که آیا کلاینت اجماع شما در حال اجرا است یا خیر و دوباره آن را امتحان کنید.
+
+#### تعامل با قراردادهای هوشمند {#interacting-with-smart-contract}
+
+در این مثال، ما یک تراکنش را با استفاده از `eth_sendTransaction` به روش `multiply` قرارداد ارسال خواهیم کرد.
+
+`eth_sendTransaction` به چندین آرگومان نیاز دارد، به ویژه `از`، `به` و `داده`. `From` آدرس عمومی حساب ما است و `to` آدرس قرارداد است. آرگومان `data` حاوی باری است که مشخص میکند کدام متد و با کدام آرگومان باید فراخوانی شود. This is where the [ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html) comes into play. The ABI is a JSON file that defines how to define and encode data for the EVM.
+
+The bytes of the payload defines which method in the contract is called. This is the first 4 bytes from the Keccak hash over the function name and its argument types, hex encoded. The multiply function accepts an uint which is an alias for uint256. This leaves us with:
+
+```javascript
+web3.sha3("multiply(uint256)").substring(0, 10)
+// "0xc6888fa1"
+```
+
+The next step is to encode the arguments. There is only one uint256, say, the value 6. The ABI has a section which specifies how to encode uint256 types.
+
+`int: enc(X)` is the big-endian two’s complement encoding of X, padded on the higher-order (left) side with 0xff for negative X and with zero > bytes for positive X such that the length is a multiple of 32 bytes.
+
+This encodes to `0000000000000000000000000000000000000000000000000000000000000006`.
+
+Combining the function selector and the encoded argument our data will be `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
+
+This can now be sent to the node:
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545
+{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"}
+```
+
+Since a transaction was sent, a transaction hash was returned. Retrieving the receipt gives:
+
+```javascript
+{
+ blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
+ blockNumber: 268,
+ contractAddress: null,
+ cumulativeGasUsed: 22631,
+ gasUsed: 22631,
+ logs: [{
+ address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d",
+ blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
+ blockNumber: 268,
+ data: "0x000000000000000000000000000000000000000000000000000000000000002a",
+ logIndex: 0,
+ topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"],
+ transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
+ transactionIndex: 0
+ }],
+ transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
+ transactionIndex: 0
+}
+```
+
+The receipt contains a log. This log was generated by the EVM on transaction execution and included in the receipt. The `multiply` function shows that the `Print` event was raised with the input times 7. Since the argument for the `Print` event was a uint256 we can decode it according to the ABI rules which will leave us with the expected decimal 42. Apart from the data it is worth noting that topics can be used to determine which event created the log:
+
+```javascript
+web3.sha3("Print(uint256)")
+// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"
+```
+
+This was just a brief introduction into some of the most common tasks, demonstrating direct usage of the JSON-RPC.
+
+## موضوعات مرتبط {#related-topics}
+
+- [JSON-RPC specification](http://www.jsonrpc.org/specification)
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+- [رابط کاربری جاوا اسکریپت](/developers/docs/apis/javascript/)
+- [وب سرویسهای بکاند](/developers/docs/apis/backend/)
+- [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
new file mode 100644
index 00000000000..20d205fb783
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
@@ -0,0 +1,257 @@
+---
+title: جستجوگرهای بلوک
+description: یک معرفی دربارهی جستجوگرهای بلوک، پورتال شما یه جهان دادههای زنجیره بلوکی، که در آن میتوانید اطلاعاتی دربارهی تراکنشها، حسابها، قراردادها و بیشتر را درخواست کنید.
+lang: fa
+sidebarDepth: 3
+---
+
+جستجوگرهای بلوک پورتال شما به دادههای اتریوم هستند. میتوانید از آنها برای مشاهده دادههای واقعی در مورد بلوکها، تراکنشها، اعتبارسنجیها، حسابها و سایر فعالیتهای زنجیرهای استفاده کنید.
+
+## پیشنیازها {#prerequisites}
+
+شما باید مفاهیم اساسی اتریوم را درک کنید تا بتوانید داده هایی را که یک جستجوگر بلوک به شما می دهد، درک کنید. با [کعرفی اتریوم](/developers/docs/intro-to-ethereum/) آغاز کنید.
+
+## سرویسها {#services}
+
+- [Etherscan](https://etherscan.io/) - _به زبانهای چینی، کرهای، روسی و ژاپنی هم در دسترس است_
+- [3xpl](https://3xpl.com/ethereum)
+- [Beaconcha.in](https://beaconcha.in/)
+- [Blockchair](https://blockchair.com/ethereum) - _همچنین به زبانهای اسپانیایی، فرانسوی، ایتالیایی، آلمانی، پرتغالی، روسی، چینی و فارسی در دسترس است_
+- [Blockscout](https://eth.blockscout.com/)
+- [Chainlens یا چین لنز](https://www.chainlens.com/)
+- [مرورگر بلوک DexGuru](https://ethereum.dex.guru/)
+- [Etherchain](https://www.etherchain.org/)
+- [Ethernow یا اترنو](https://www.ethernow.xyz/)
+- [Ethplorer](https://ethplorer.io/) - _به زبانهای چینی، اسپانیایی، فرانسوی، ترکیهای، روسی، کرهای و ویتنامی در دسترسی است_
+- [EthVM](https://www.ethvm.com/)
+- [OKLink](https://www.oklink.com/eth)
+- [Rantom](https://rantom.app/)
+
+## ابزارهای متن باز {#open-source-tools}
+
+- [Otterscan](https://otterscan.io/)
+- [اتراسکن-کند](https://github.com/woxjro/lazy-etherscan)
+
+## دادهها {#data}
+
+اتریوم از نظر طراحی شفاف است، بنابراین همه چیز قابل تأیید است. جسنجوگران بلوک یک رابط برای دریافت این اطلاعات ارائه می دهند. و این هم برای شبکه اصلی اتریوم و هم برای شبکه های آزمایشی است در صورتی که به آن داده نیاز داشته باشید. داده ها در اتریوم به داده های اجرا و اجماع دسته بندی میشوند. داده اجرا به داده ای که در یک بلوک مشخص اجرا شده است اشاره میکند. داده اجماع به بلوک ها و اعتبارسنجانی که آن ها را پیشنهاد داده اند اشاره میکند.
+
+در اینجا خلاصه ای از انواع داده هایی است که می توانید از جستجوگر بلوک دریافت کنید.
+
+### دادههای اجرا {#execution-data}
+
+بلوکهای جدید تقریبا هر 12 ثانیه به اتریوم اضافه میشوند (مگر اینکه یک پیشنهاد دهنده نوبتش را از دست بدهد)، بنابراین یک جریان تقریباً ثابت از دادهها وجود دارد که به مرورگر های بلوک اضافه میشود. بلوک ها حاوی بسیاری از داده های مهم هستند که ممکن است برای شما مفید باشد:
+
+**دادههای استاندارد**
+
+- Block height - شماره بلوک و طول زنجیره بلوکی (بر حسب بلوک) هنگام ایجاد بلوک فعلی
+- Timestamp - زمانی که بلوک جدید پیشنهاد شد
+- Transactions- تعداد تراکنشهایی که درون بلوک هستند
+- Fee recipient - آدرسی که انعام تراکنش های بلوک به آن منتقل میشود
+- Block Reward - مقدار اتری که به اعتبارسنج پیشنهاد دهنده ی بلوک داده میشود
+- Size- اندازه داده های داخل بلوک (اندازه گیری شده به واحد بایت)
+- Gas used - کل واحدهای اتر مصرف شده توسط تراکنشها در بلوک
+- Gas limit - مجموع حد گس تعیین شده توسط تراکنش هات در بلوک
+- Base fee per gas - کمترین گازبها لازم برای هر تراکنش برای قرار گیری در این بلوک
+- Burnt fees - مقدار اتر سوزانده شده در این بلوک
+- داده اضافی - هر داده اضافی که سازنده در بلوک گنجانده است
+
+**دادههای پیشرفته**
+
+- Hash - هش رمزنگاری که نشان دهنده سربرگ بلوک (شناسه منحصر به فرد بلوک) است
+- Parent hash - هش بلوکی که قبل از بلوک فعلی آمده است
+- StateRoot - هش ریشهی درخت مرکل که کل وضعیت سیستم را ذخیره می کند
+
+### گاز {#gas}
+
+نه تنها جستجوگران بلوک اطلاعاتی در مورد مصرف گاز در تراکنشها و بلوکها به شما میدهند، بلکه برخی اطلاعاتی درباره قیمتهای فعلی گاز شبکه به شما میدهند. این به شما کمک میکند تا استفاده از شبکه را درک کنید، تراکنشهای ایمن را ارسال کنید و بیش از حد برای گاز خرج نکنید. به دنبال رابطهای نرمافزاری باشید که می توانند به شما کمک کنند این اطلاعات را در رابط محصول خود دریافت کنید. داده های مخصوص گاز شامل موارد زیر است:
+
+- واحدهای تخمینی گاز مورد نیاز برای یک تراکنش ایمن اما کند (+ قیمت و مدت تخمینی)
+- واحدهای تخمینی گاز مورد نیاز برای یک تراکنش میانگین (+ قیمت و مدت تخمینی)
+- واحدهای تخمینی گاز مورد نیاز برای یک تراکنش سریع (+ قیمت و مدت تخمینی)
+- میانگین زمان تایید بر اساس قیمت گاز
+- قراردادهایی که گاز مصرف می کنند - به عبارت دیگر، محصولات محبوبی که در شبکه به زیادی استفاده می شوند
+- حسابهایی که گاز مصرف میکنند - به عبارت دیگر، کاربران همیشگی و فعال شبکه
+
+### تراکنشها {#transactions}
+
+جستجوگران بلوک به مکانی رایج برای پیگیری روند تراکنش های افراد تبدیل شده اند. این به این دلیل است که سطح جزئیاتی که می توانید به دست آورید اطمینان بیشتری را ارائه می دهد. دادههای تراکنش شامل موارد زیر است:
+
+**دادههای استاندارد**
+
+- هش تراکنش - هشی که هنگامی تراکنش ثبت میشود ایجاد میشود
+- وضعیت - نشان دهنده این است که آیا تراکنش در حال انتظار است، شکست خورده یا موفقیت بوده است
+- بلوک - بلوکی که تراکنش در آن گنجانده شده است
+- مهر زمانی یا تایم استمپ - زمانی که یک تراکنش در یک بلوک پیشنهاد شده توسط اعتبارسنج گنجانده شد
+- From - آدرس حسابی که تراکنش را ارسال کرده است
+- To - آدرس گیرنده یا قرارداد هوشمندی که تراکنش با آن تعامل دارد
+- توکن های منتقل شده - لیستی از توکنهایی که به عنوان بخشی از تراکنش منتقل شده اند
+- ارزش- مقدار کل اتری که منتقل می شود
+- کارمزد تراکنش - مبلغ پرداختی به اعتبارسنج برای پردازش تراکنش (محاسبه بر اساس قیمت گس\*گس مصرف شده)
+
+**دادههای پیشرفته**
+
+- حد گاز – حداکثر تعداد واحدهای گازی که این تراکنش می تواند مصرف کند
+- گاز مصرفی - مقدار واقعی واحدهای گاز مصرف شده در تراکنش
+- قیمت گاز - قیمت تعیین شده برای هر واحد گاز
+- نانس - شمارهی تراکنش برای آدرس `from` (در ذهن داشته باشید که با 0 شروع میشود در نتیجه نانس شمارهی `۱۰۰` در واقع ۱۰۱امین تراکنشی است که توسط این حساب ثبت شدهاست)
+- داده های ورودی - هر گونه اطلاعات اضافی مورد نیاز تراکنش
+
+### حساب ها {#accounts}
+
+اطلاعات زیادی در مورد یک حساب وجود دارد که می توانید به آنها دسترسی داشته باشید. به همین دلیل است که اغلب توصیه می شود از چندین حساب استفاده کنید تا دارایی ها و ارزش شما به راحتی قابل ردیابی نباشد. همچنین راهحلهایی برای خصوصیتر کردن تراکنشها و فعالیت حسابها در حال توسعه است. اما در اینجا دادههایی وجود دارد که برای حسابها در دسترس است:
+
+**حسابهای کاربری**
+
+- آدرس حساب - آدرس عمومی که می توانید برای ارسال وجوه به آن استفاده کنید
+- موجودی اتر - مقدار اتر مرتبط با آن حساب
+- مقدار کل اتر - ارزش اتر
+- توکن ها – توکن های مرتبط با حساب و ارزش آنها
+- تاریخچه تراکنش - فهرستی از تمام تراکنش هایی که این حساب فرستنده یا گیرنده آن بوده است
+
+**قراردادهای هوشمند**
+
+حسابهای قرارداد هوشمند دارای تمام دادههایی هستند که یک حساب کاربری خواهد داشت، اما برخی از جستجوگران بلوک حتی برخی از اطلاعات کد را نیز نمایش میدهند. مثالهایی شامل:
+
+- سازنده قرارداد - آدرسی که قرارداد را در شبکهی اصلی پیاده کرده است
+- تراکنش ایجاد - تراکنشی که شامل پیادهسازی قرارداد در شبکهی اصلی می شود
+- کد منبع - کد solidity یا vyper قرارداد هوشمند
+- ABI قرارداد - رابط باینری برنامه ی قرارداد -فراخوانی هایی که قرارداد انجام می دهد و داده های دریافت شده
+- کد ایجاد قرارداد - بایت کد کامپایل شده قرارداد هوشمند - زمانی ایجاد می شود که یک قرارداد هوشمند نوشته شده در Solidity یا Vyper و غیره را کامپایل می کنید.
+- رویدادهای قرارداد- تاریخچه ای از توابع فراخوانده شدن در قرارداد هوشمند-به زبان ساده روشی که نشان میدهد قرارد داد چگونه و چقدر استفاده شده
+
+### توکن ها {#tokens}
+
+توکنها نوعی قرارداد هستند، بنابراین دادههایی مشابه قرارداد هوشمند خواهند داشت. اما از آنجایی که ارزش دارند و قابل معامله هستند، نقاط داده اضافی دارند:
+
+- نوع - خواه ERC-20، ERC-721 یا استاندارد توکن دیگری باشند
+- قیمت - اگر ERC-20 باشند، ارزش بازار فعلی آن ها نمایش داده میشود
+- ارزش بازار - اگر ERC-20 باشند، ارزش بازار کلی دارند (محاسبه شده با قیمت*کل عرضه)
+- عرضه کل - تعداد توکن های در گردش
+- مالکان- تعداد آدرس هایی که توکن را در خود نگه می دارند
+- Transfers - تعداد دفعاتی که توکن بین حساب ها منتقل شده است
+- تاریخچه تراکنش - تاریخچه تمام تراکنش های یک توکن
+- آدرس قرارداد - آدرس توکنی که در شبکهی اصلی مستقر شده است
+- اعشار - توکن های ERC-20 قابل تقسیم هستند و دارای اعداد اعشاری هستند
+
+### شبکه {#network}
+
+بعضی از داده های بلوک ها مربوط به سلامتی کلی اتریوم است.
+
+- کل تراکنش ها – تعداد تراکنش ها از زمان ایجاد اتریوم
+- تراکنش در ثانیه - تعداد تراکنش های قابل پردازش در یک ثانیه
+- قیمت اتر - ارزش فعلی 1 اتر
+- کل عرضه اتر - تعداد اتر در گردش - به یاد داشته باشید که اتر جدید با ایجاد هر بلوک به شکل پاداش بلوک ایجاد می شود
+- ارزش بازار - محاسبه قیمت*عرضه کل
+
+## دادههای لایهی اجماع {#consensus-layer-data}
+
+### ایپاک {#epoch}
+
+به دلایل امنیتی، در انتهای هر ایپاک یک کمیته تصادفی از اعتبارسنجان انتخاب میشود ( هر 6.4 دقیقه). دادههای ایپاک شامل موارد زیر است:
+
+- شمارهی ایپاک
+- وضعیت قطعی - آیا ایپاک قطعی شده یا خیر (آری/نه)
+- زمان - زمانی که ایپاک به پایان رسیده است
+- تصدیق ها - تعداد تصدیقها در ایپاک(رای به بلوک های درون اسلات)
+- سپرده ها - تعداد سپرده های اتر که در ایپاک گنجانده شده است (اعتبارسنجان باید اتر را برای اعتبار سنجی سهامگذاری کنند)
+- Slashings - تعداد جریمه هایی که به پیشنهاد دهندگان بلوک ها یا تصدیق کنندگان داده می شود
+- مشارکت در رای گیری - مقدار اتر سهام گذاری شده که برای تصدیق بلوک ها استفاده می شود
+- اعتبارسنجان - تعداد اعتبارسنجان فعال در ایپاک
+- میانگین موجودی اعتبارسنجان - میانگین موجودی اعتبارسنجان فعال
+- اسلاتها - تعداد اسلاتهای درون ایپاک (اسلات شامل یک بلوک معتبر است)
+
+### اسلات {#slot}
+
+اسلاتها فرصتهایی برای ساخت بلوک هستند، دادههای در دسترس برای هر اسلات شامل موارد زیر است:
+
+- ایپاک - ایپاکی که اسلات در آن معتبر است
+- شمارهی اسلات
+- وضعیت - وضعیت اسلات (پیشنهاد شده/ از دست رفته)
+- زمان - برچسب زمان اسلات
+- پیشنهاد دهنده - اعتبارسنجی که بلوک را برای اسلات پیشنهاد کرده است
+- ریشهی بلوک - هش ریشهی درخت از بلوک بیکن
+- ریشهی پدر - هش بلوکی که پیش از این آمده است
+- ریشهی وضعیت - هش ریشهی درخت از وضعیت بیکن
+- امضا
+- آشکارسازی RanDAO
+- Graffiti - یک پیشنهاد دهنده بلوک می تواند پیامی به طول 32 بایت به پیشنهاد بلوک خود اضافه کند
+- دادههای اجرا
+ - هش بلوک
+ - میزان سپرده
+ - ریشهی سپرده
+- تصدیق - تعداد تصدیقها برای بلوک درون این اسلات
+- سپردهها - تعداد سپردهها در طول این اسلات
+- خروج داوطلبانه - تعداد اعتبار سنج هایی که در طول اسلات خارج شدند
+- Slashings - تعداد جریمه هایی که به پیشنهاد دهندگان بلوک ها یا تصدیق کنندگان داده می شود
+- آرا - اعتبارسنجانی که برای این بلوک در این اسلات رای دادهاند
+
+### بلوکها {#blocks-1}
+
+اثبات-سهام زمان را به دوره اسلات و ایپاک تبدیل میکند. پس این معنی دادههای جدید است!
+
+- پیشنهاددهنده - اعتبارسنجی که به صورت الگوریتمی برای پیشنهاد بلوک جدید انتخاب شده است
+- ایپاک - ایپاکی که بلوک در آن پیشنهاد شده است
+- اسلات - اسلاتی که بلوک در آن پیشنهاد شده است
+- تصدیق ها- تعداد تصدیف های گنجانده شده در اسلات-تصدیق ها مانند رای هایی هستند که نشان میدهند بلوک آماده ثبت در زنجیره بیکن است
+
+### اعتبارسنج ها {#validators}
+
+اعتبار سنج ها مسئول پیشنهاد بلوک ها و تایید آنها در اسلات ها هستند.
+
+- شمارهی اعتبار سنج - شمارهی یکتایی که نشان یک اعتبارسنج است
+- موجودی فعلی - موجودی اعتبارسنج که شامل پاداشها است
+- موجودی موثر - موجودی اعتبارسنج که برای سهام گذاری استفاده میشود
+- درآمد - پاداشها و جریمههایی که اعتبارسنج دریافت کرده
+- وضعیت - آنلاین و فعال بودن یا نبودن اعتبار سنج در حال حاضر
+- اثربخشی تصدیق - میانگین زمانی که طول می کشد تا تصدیق های اعتبارسنج در زنجیره گنجانده شود
+- واجد شرایط بودن برای فعال سازی - تاریخ (و ایپاک) زمانی که اعتبارسنج برای اعتبارسنجی در دسترس قرار گرفت
+- فعال از – تاریخ (و ایپاک) که اعتبارسنج فعال شد
+- بلوک های پیشنهادی – بلوکی که اعتبارسنج پیشنهاد کرده است
+- تصدیق ها - تصدیق هایی که اعتبارسنج ارائه کرده است
+- سپرده ها - آدرس از، هش تراکنش، شماره بلوک، برچسب زمان، مبلغ و وضعیت سپرده گذاری که توسط اعتبارسنج انجام شده است
+
+### تصدیق {#attestations}
+
+تصدیق ها رای "بله" برای گنجاندن بلوک ها در زنجیره هستند. دادههای آنها مربوط به سوابق تصدیق و اعتبارسنج هایی است که تصدیق کردهاند
+
+- اسلات - اسلاتی که تصدیق در آن شکل گرفته است
+- شاخص کمیته - شاخص کمیته در اسلات مشخص شده
+- بیت های تجمیع شده - نشان دهنده جمع تصدیق همه اعتبار سنج های شرکت کننده در تصدیق است
+- اعتبار سنجان- اعتبار سنج هایی که تصدیق ارائه کردند
+- ریشه بلوک بیکن - به بلوکی اشاره می کند که اعتبار سنج ها آن را تصدیق می کنند
+- منبع - به آخرین ایپاک توجیه شده اشاره می کند
+- هدف - به مرز آخرین ایپاک اشاره می کند
+- امضا
+
+### شبکه {#network-1}
+
+داده های سطح بالای لایه اجماع شامل موارد زیر است:
+
+- ایپاک فعلی
+- اسلات فعلی
+- اعتبارسنجان فعال - تعداد اعتبارسنجان فعال
+- اعتبار سنجهای در انتظار - تعداد اعتبارسنج هایی که منتظر فعال شدن هستند
+- اتر سهامگذاری شده - میزان اتر سهامگذاریشده در شبکه
+- موجودی میانگین - میانگین موجودی اتر اعتبار سنجان
+
+## جستجوگرهای بلوک {#block-explorers}
+
+- [Etherscan](https://etherscan.io/) - یک مرورگر بلوک که میتوانید برای دریافت داده از شبکهی اصلی اتریوم و شبکهی آزمایشی Goerli از آن استفاده کنید
+- [3xpl](https://3xpl.com/ethereum) - یک اکسپلورر منبع باز اتریوم بدون آگهی که امکان دانلود مجموعه دادههای آن را فراهم میکند
+- [Beaconcha.in](https://beaconcha.in/) - یک مرورگر بلوک متن باز که میتوانید برای دریافت داده از شبکهی اصلی اتریوم از آن استفاده کنید
+- [Blockchair](https://blockchair.com/ethereum) - خصوصیترین جستجوگر اتریوم. همچنین برای مرتب کردن و فیلتر کردن دادهها (استخر حافظه)
+- [Etherchain](https://www.etherchain.org/) - یک مرورگر بلوک برای شبکهی اصلی اتریوم
+- [Ethplorer](https://ethplorer.io/) - یک مرورگر بلوک با تمرکز بر روی توکنها برای شبکهی اصلی اتریوم و شبکهی آزمایشی Kovan
+- [Rantom](https://rantom.app/)-یک مرورگر تراکنش متن باز که برای مرور جزئیات تراکنش های DeFi&NFT استفاده میشود
+- [Ethernow](https://www.ethernow.xyz/) - یک کاوشگر تراکنش در زمان واقعی که به شما امکان میدهد لایه پیش زنجیره اتریوم شبکه اصلی را ببینید
+
+## بیشتر بخوانید {#further-reading}
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [تراکنشها](/developers/docs/transactions/)
+- [حساب](/developers/docs/accounts/)
+- [شبکهها](/developers/docs/networks/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
new file mode 100644
index 00000000000..1a4363d4f9f
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
@@ -0,0 +1,55 @@
+---
+title: داده ها و تحلیل ها
+description: چگونه می توانید تجزیه و تحلیل و داده های زنجیره ای را برای استفاده در برنامه های غیرمتمرکز خود دریافت کنید
+lang: fa
+---
+
+## مقدمه {#Introduction}
+
+از آنجا که استفاده از شبکه همچنان در حال رشد است، مقدار فزاینده ای از اطلاعات ارزشمند در داده های زنجیره ای وجود خواهد داشت. از آنجا که حجم داده ها به سرعت افزایش می یابد، محاسبه و جمعآوری این اطلاعات برای گزارش یا هدایت یک برنامه غیرمتمرکز می تواند به فرآیندی زمانبر و تلاش سنگینی تبدیل شود.
+
+استفاده از ارائه دهندگان داده های موجود می تواند توسعه را تسریع کند، نتایج دقیق تری تولید کند و کارهای مداوم نگهداری را کاهش دهد. این امر یک تیم را قادر میسازد تا بر روی عملکرد اصلی پروژه خود تمرکز کند.
+
+## پیش نیاز ها {#prerequisites}
+
+شما باید مفهوم اصلی [جستجوگران بلوک](/developers/docs/data-and-analytics/block-explorers/) را درک کنید تا استفاده از آنها در زمینه تجزیه و تحلیل داده را بهتر درک کنید. علاوه بر این، با مفهوم [اندیس](/glossary/#index) آشنا شوید تا مزایایی که به طراحی سیستم اضافه میکنند را درک کنید.
+
+از نظر مبانی معماری، درک [رابط برنامهنویسی کاربردی](https://www.wikipedia.org/wiki/API) و [REST](https://www.wikipedia.org/ wiki/Representational_state_transfer)، حتی در تئوری نیز وجود دارد.
+
+## جستجوگرهای بلوک {#block-explorers}
+
+بسیاری از [کاوشگرهای بلوک](/developers/docs/data-and-analytics/block-explorers/) درگاههای [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) را پیشنهاد میکنند که به توسعهدهندگان امکان مشاهده دادهها در بلوکها، تراکنشها، اعتبارسنجها، حسابها و سایر فعالیتهای زنجیرهای را فراهم میکند.
+
+در این صورت توسعه دهندگان میتوانند این دادهها را پردازش و تبدیل کنند تا به کاربران خود بینش و تعاملات منحصر به فرد با [زنجیره بلوکی](/glossary/#blockchain) را بدهند. برای مثال،[Etherscan](https://etherscan.io) داده های اجرا و اجماع بلوک ها را هر 12 ثانیه ارائه میکند.
+
+## The Graph {#the-graph}
+
+[Graph Network](https://thegraph.com/) یک پروتکل شاخص ساز غیرمتمرکز برای سازماندهی داده های زنجیره بلوکی است. توسعه دهندگان می توانند به جای ساختن و مدیریت فروشگاه های داده غیر زنجیره ای و متمرکز برای جمعآوری داده های درون زنجیره ای، با The Graph برنامه های بدون سرور بسازند که به طور کامل بر روی زیرساخت های عمومی اجرا می شوند.
+
+با استفاده از [GraphQL](https://graphql.org/)، توسعهدهندگان میتوانند از هر یک از APIهای باز انتخابشده، که به عنوان sub-graph شناخته میشوند، پرس و جو کنند تا اطلاعات لازم را که برای راهاندازی برنامهی غیرمتمرکز خود نیاز دارند، به دست آورند. با پرس و جو از این نمودارهای فرعی نمایهشده، گزارشها و دادهها نه تنها مزایای عملکرد و مقیاسپذیری را دریافت میکنند، بلکه دقت ایجاد شده توسط اجماع شبکه را نیز دریافت میکنند. با اضافه شدن پیشرفتها و/یا زیر-گراف های جدید به شبکه، پروژههای شما میتوانند به سرعت برای استفاده از این پیشرفتها تکرار شوند.
+
+## تنوع کلاینتها
+
+[تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) برای سلامت کلی شبکه اتریوم مهم است زیرا در برابر اشکالات و سوء استفادهها انعطاف پذیری میکند. اکنون چندین داشبورد تنوع مشتری از جمله [clientdiversity.org](https://clientdiversity.org/)، [rated.network وجود دارد. ](https://www.rated.network)، [supermajority.info](https://supermajority.info//) و [Ethernodes](https://ethernodes.org/).
+
+## Dune Analytics {#dune-analytics}
+
+[Dune Analytics](https://dune.com/) دادههای بلاک چین را در جداول پایگاه داده رابطهای (PostgreSQL و DatabricksSQL) پیش پردازش میکند، به کاربران امکان میدهد با استفاده از SQL دادههای بلاک چین را جستجو کنند و داشبوردهایی بر اساس نتایج جستجو بسازند. دادههای زنجیرهای در ۴ جدول خام سازماندهی میشوند: `بلوکها`، `تراکنشها`، (رویداد) `گزارشها` و (تماس) `ردیابی`. قراردادها و پروتکلهای محبوب رمزگشایی شدهاند و هر کدام مجموعهای از جداول رویداد و فراخوانی خاص خود را دارند. این جداول با رویداد و فراخوان بیشتر پردازش میشوند و بر اساس نوع پروتکلها به جداول انتزاعی سازماندهی میشوند، به عنوان مثال دکس (dex)، وام، استیبل کوینها و غیره.
+
+## شبکه SubQuery {#subquery-network}
+
+[SubQuery](https://subquery.network/) پیشتاز در فهرستکردن دیتا است که به توسعهدهندگان APIهای سریع، قابل اعتماد، غیرمتمرکز و سفارشیشده برای پروژههای Web3 خود میدهد. SubQuery به توسعه دهندگان بیش از 165 اکوسیستم (از جمله اتریوم) با داده های فهرست شده غنی این توانایی را می دهد تا تجربیاتی ملموس و همه جانبه برای کاربران خود ایجاد کنند. شبکه SubQuery برنامه های غیرقابل توقف شما را با یک شبکه زیرساخت انعطاف پذیر و غیرمتمرکز توانمند می سازد. از جعبه ابزار توسعهدهنده بلاکچین SubQuery برای ساخت برنامههای Web3 در آینده، بدون صرف زمان برای ساختن یک Backend سفارشی برای فعالیتهای پردازش داده استفاده کنید.
+
+برای شروع، از [راهنمای شروع سریع اتریوم](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) دیدن کنید تا در عرض چند دقیقه در یک محیط داکر محلی برای آزمایش قبل از شروع کار در [سرویس مدیریت شده SubQuery](https://managedservice.subquery.network/) یا در [شبکه غیرمتمرکز SubQuery](https://app.subquery.network/dashboard) ایندکسینگ انجام شود.
+
+## Ethernow - برنامه دیتای استخر حافظه {#ethernow}
+[Blocknative](https://www.blocknative.com/) دسترسی آزاد به [آرشیو دیتای استخر حافظه](https://www.ethernow.xyz/mempool-data-archive) تاریخی اتریوم خود را فراهم میکند. این به محققان و پروژههای خوب جامعه امکان میدهد تا لایه پیش زنجیره اتریوم شبکه اصلی (Mainnet) را کشف کنند. مجموعه داده به طور فعال نگهداری میشود و جامعترین سابقه تاریخی رویدادهای تراکنش استخر حافظه در اکوسیستم اتریوم را نشان میدهد. جزئیات بیشتر در [Ethernow](https://www.ethernow.xyz/).
+
+## اطلاعات بیشتر {#further-reading}
+
+- [نمای کلی Graph Network](https://thegraph.com/docs/en/about/network/)
+- [زمین بازی درخواستهای Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current)
+- [نمونه کدهای رابط برنامه نویسی کاربردی در EtherScan](https://etherscan.io/apis#contracts)
+- [Beaconcha.in مرورگر زنجیره بیکن](https://beaconcha.in)
+- [مقدمات Dune](https://docs.dune.com/#dune-basics)
+- [راهنمای شروع کار SubQuery](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
new file mode 100644
index 00000000000..65a9fa6ab1e
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
@@ -0,0 +1,83 @@
+---
+title: شبکه های توسعه
+description: مروری بر شبکه های توسعه و ابزارهای موجود برای کمک به ساخت برنامه های اتریومی.
+lang: fa
+---
+
+هنگام ساختن یک برنامه اتریوم با قرارداد هوشمند، باید آن را در یک شبکه محلی اجرا کنید تا قبل از استقرار آن، نحوه عملکرد آن را ببینید.
+
+همانگونه که ممکن است برای توسعه وب یک سرور محلی را بر روی رایانه خود اجرا کنید، می توانید از یک شبکه توسعه نیز برای ایجاد یک نمونه زنجیره بلوکی محلی برای آزمایش برنامهی غیرمتمرکز خود استفاده کنید. این شبکههای توسعه اتریومی ویژگیهایی را ارائه میکنند که امکان تکرار اجرای بسیار سریعتری را نسبت به اجرا روی یک شبکهی تست عمومی فراهم میکنند (مثلاً برای دریافت اتر نیازی نیست با یک شبکهی تست سر و کار داشته باشید).
+
+## پیشنیازها {#prerequisites}
+
+شما می بایست پیش از فرو رفتن در شبکه های توسعه با مفهوم [اصول پشته اتریوم](/developers/docs/ethereum-stack/) و [شبکههای اتریوم](/developers/docs/networks/) آشنا باشید.
+
+## شبکه توسعه چیست؟ {#what-is-a-development-network}
+
+شبکه های توسعه اساساً کلاینت های اتریومی (پیادهسازی اتریوم) هستند که به طور خاص برای توسعه محلی طراحی شده اند.
+
+**چرا فقط یک گره استاندارد اتریومی را به صورت محلی اجرا نمی کنید؟**
+
+شما _میتوانید_ [یک گره را اجرا کنید](/developers/docs/nodes-and-clients/#running-your-own-node) اما از آنجایی که شبکههای توسعه بهمنظور توسعه ساخته شدهاند، اغلب دارای ویژگیهای مناسبی هستند مانند:
+
+- بهکارگیری قطعی زنجیره بلوکی محلی تان با داده ها (مانند حساب های دارای موجودی اتر)
+- تولید فوری بلوک با هر تراکنشی که دریافت میکند، به ترتیب و بدون تاخیر است
+- قابلیت گزارش دهی و اشکال زدایی بهبودیافته
+
+## ابزارهای موجود {#available-projects}
+
+**توجه**: اکثر [چارچوبهای توسعه](/developers/docs/frameworks/) دارای یک شبکه توسعه داخلی هستند. توصیه می کنیم با یک چارچوب برای [تنظیم محیط توسعه محلی خود](/developers/local-environment/) شروع کنید.
+
+### Ganache {#ganache}
+
+به سرعت یک زنجیره بلوکی شخصی اتریومی را راهاندازی کنید که میتوان از آن برای اجرای آزمایشها، اجرای دستورها، و بررسی وضعیت در هنگام کنترل نحوه عملکرد زنجیره استفاده کنید.
+
+Ganache هم یک برنامه دسکتاپ (Ganache UI) و هم یک ابزار خط فرمان (`ganache-cli`) ارائه می دهد. آن بخشی از مجموعه ابزار Truffle است.
+
+- [وب سایت](https://www.trufflesuite.com/ganache)
+- [گیت هاب](https://github.com/trufflesuite/ganache)
+- [مستندات](https://www.trufflesuite.com/docs/ganache/overview)
+
+### شبکه Hardhat {#hardhat-network}
+
+یک شبکه محلی اتریومی است که برای توسعه طراحی شده است. این به شما امکان می دهد قرارداد های خود را مستقر کنید، آزمایش های خود را اجرا کنید و کد خود را اشکال زدایی کنید.
+
+شبکه Hardhat که در بطن Hardhat است، یک محیط توسعه اتریوم برای حرفه ای هاست.
+
+- [وب سایت](https://hardhat.org/)
+- [گیت هاب](https://github.com/nomiclabs/hardhat)
+
+### بیکنچینهای محلی {#local-beacon-chains}
+
+برخی از کلاینت های اجماع، دارای ابزارهای داخلی برای چرخاندن بیکنچینهای محلی جهت اهداف آزمایشی هستند. دستورالعمل Lighthouse، Nimbus و Lodestar در دسترس است:
+
+- [شبکهی تست محلی برای Lodestar](https://chainsafe.github.io/lodestar/usage/local/)
+- [شبکهی تست محلی برای Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
+- [شبکهی تست محلی برای Nimbus](https://github.com/status-im/nimbus-eth1/blob/master/fluffy/docs/local_testnet.md)
+
+### زنجیره های آزمایش عمومی اتریوم {#public-beacon-testchains}
+
+همچنین دو زیرساخت آزمایش عمومی در اتریوم وجود دارند: Goerli و Sepolia. شبکه تستی توصیه شده با پشتیبانی طولانی مدت گورلی (Goerli) است که هرکسی میتواند آن را تأیید کند. سپولیا (Sepolia) یک زنجیره جدیدتر و کوچکتر است که همچنین انتظار میرود برای آینده قابل پیش بینی حفظ شود، با یک مجموعه اعتبار سنج مجاز (به این معنی که دسترسی عمومی به اعتبارسنجهای جدید در این شبکه آزمایشی وجود ندارد). انتظار می رود زنجیره روپستن (Ropsten) در سهماهه چهارم 2022 منسوخ شود و زنجیره رینکبی (Rinkeby) در Q2/Q3 2023 منسوخ شود.
+
+- [لانچپد سهامگذاری Goerli](https://goerli.launchpad.ethereum.org/)
+- [Ropsten, Rinkeby & Kiln Deprecation Announcement](https://blog.ethereum.org/2022/06/21/testnet-deprecation)
+
+### بسته کورتوسیس اتریوم {#kurtosis}
+
+کورتوسیس (Kurtosis) یک سیستم توسعهدهی برای محیطهای آزمایشی چندکانتینری است که به توسعهدهندگان این امکان را میدهد تا نمونههای تکرارپذیر شبکههای بلاکچین را به صورت محلی بچرخانند.
+
+بسته کورتوسیس اتریوم را می توان برای نمونه سازی سریع یک شبکه آزمایشی پارامتر پذیر، بسیار مقیاس پذیر، و شبکهی تست خصوصی اتریوم روی Docker یا Kubernetes استفاده کرد. این بسته از کلیه کلاینت های اصلی لایه اجرا (EL) و لایه اجماع (CL) پشتیبانی می کند. کوتسیس (Kurtosis) با ظرافت تمام نقشهبرداریهای پورت محلی و اتصالات خدماتی را برای یک شبکه نماینده انجام میدهد تا در فرآیندهای اعتبارسنجی و تست مربوط به زیرساخت هسته اتریوم استفاده شود.
+
+- [بسته شبکه اتریوم](https://github.com/kurtosis-tech/ethereum-package)
+- [وب سایت](https://www.kurtosis.com/)
+- [گیت هاب](https://github.com/kurtosis-tech/kurtosis)
+- [اسناد](https://docs.kurtosis.com/)
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [چارچوبهای توسعه](/developers/docs/frameworks/)
+- [یک محیط توسعه محلی راهاندازی کنید](/developers/local-environment/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
new file mode 100644
index 00000000000..d544718e481
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
@@ -0,0 +1,61 @@
+---
+title: مقدمه ای بر پشته اتریوم
+description: مروری بر لایه های مختلف توده اتریوم و نحوه تطبیق آنها با یکدیگر.
+lang: fa
+---
+
+مانند هر پشته نرم افزاری، مجموعه کامل "پشته اتریوم" بسته به اهداف شما از پروژه ای به پروژه دیگر متفاوت خواهد بود.
+
+با این حال، در اتریوم مؤلفههای اصلی وجود دارند که به ارائه یک مدل ذهنی برای نحوه تعامل نرم افزارهای کاربردی با زنجیره ی بلوکی اتریوم کمک می کند. درک لایه های پشته به شما کمک می کند تا راه های مختلف ادغام اتریوم در پروژه های نرم افزاری را درک کنید.
+
+## سطح ۱: ماشین مجازی اتریوم {#ethereum-virtual-machine}
+
+[ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) محیط اجرای قراردادهای هوشمند در اتریوم است. همه قراردادهای هوشمند و تغییرات وضعیت در زنجیره بلوکی اتریوم توسط [تراکنشها](/developers/docs/transactions/) اجرا میشوند. EVM تمام پردازش تراکنشهای شبکه اتریوم را انجام میدهد.
+
+مانند هر ماشین مجازی، EVM سطحی از انتزاع را بین کد در حال اجرا و ماشین اجرا کننده (گره اتریوم) ایجاد می کند. در حال حاضر EVM بر روی هزاران گره توزیع شده در سرتاسر جهان در حال اجرا است.
+
+در زیر روکش خود، EVM از مجموعه ای از دستورالعمل های کدگذاری برای اجرای وظایف خاص استفاده می کند. این کدگذاری ها (140 منحصربهفرد) به EVM اجازه میدهند [تورین کامل](https://en.wikipedia.org/wiki/Turing_completeness) باشد، به این معنی که EVM میتواند تقریباً هر چیزی را با توجه به منابع کافی محاسبه کند.
+
+بهعنوان یک توسعهدهنده dapp، نیازی به دانستن چیزهای زیادی در مورد EVM ندارید، به غیر از وجود آن و اینکه بهطور قابلاطمینانی تمام برنامههای کاربردی موجود در اتریوم را بدون فوت وقت تأمین میکند.
+
+## سطح ۲: قراردادهای هوشمند {#smart-contracts}
+
+[قراردادهای هوشمند](/developers/docs/smart-contracts/) برنامههای اجرایی هستند که بر روی زنجیره بلوکی اتریوم اجرا میشوند.
+
+قراردادهای هوشمند با استفاده از [زبانهای برنامهنویسی](/developers/docs/smart-contracts/languages/) خاص نوشته میشوند که در بایت کد EVM (دستورالعملهای ماشینی سطح پایین به نام کدهای عملیاتی) کامپایل میشوند.
+
+قراردادهای هوشمند نه تنها به عنوان کتابخانههای منبع باز عمل میکنند، بلکه اساساً سرویسهای API باز هستند که همیشه در حال اجرا هستند و نمیتوان آنها را حذف کرد. قراردادهای هوشمند عملکردهای عمومی را ارائه می دهند که کاربران و برنامه های کاربردی ([dapps](/developers/docs/dapps/)) ممکن است بدون نیاز به مجوز با آنها تعامل داشته باشند. هر برنامه کاربردی ممکن است با قراردادهای هوشمند مستقر شده برای ساختن عملکردی، مانند افزودن [فیدهای داده](/developers/docs/oracles/) یا برای پشتیبانی از مبادله توکن، ادغام شود. علاوه بر این، هر کسی میتواند قراردادهای هوشمند جدیدی را برای اتریوم به منظور افزودن قابلیتهای سفارشی برای رفع نیازهای برنامه خود مستقر کند.
+
+بهعنوان یک توسعهدهنده dapp، تنها در صورتی باید قراردادهای هوشمند بنویسید که میخواهید قابلیتهای سفارشی را در زنجیره بلوکی اتریوم اضافه کنید. ممکن است متوجه شوید که میتوانید تنها با ادغام با قراردادهای هوشمند موجود، به اکثر یا تمام نیازهای پروژه خود دست یابید، به عنوان مثال اگر میخواهید از پرداختهای پایدار ارزها پشتیبانی کنید یا تبادل غیرمتمرکز توکنها را فعال کنید.
+
+## سطح 3: گرههای اتریوم {#ethereum-nodes}
+
+برای اینکه برنامه بتواند با زنجیره بلوکی اتریوم تعامل داشته باشد، باید به یک [گره اتریوم](/developers/docs/nodes-and-clients/) متصل شود. اتصال به یک گره به شما امکان می دهد داده های زنجیره بلوکی را بخوانید و/یا تراکنش ها را به شبکه ارسال کنید.
+
+گرههای اتریوم رایانههایی هستند که نرمافزار اجرا میکنند - یک کلاینت اتریوم. یک کلاینت اجرایی از اتریوم است که تمام تراکنشهای هر بلوک را تأیید میکند و شبکه را ایمن نگه میدارد و دادهها را دقیق نگه میدارد. **گرههای اتریوم، زنجیره بلوکی اتریوم هستند**. آنها به طور جمعی وضعیت زنجیره بلوکی اتریوم را ذخیره می کنند و در مورد تراکنش ها برای تغییر وضعیت زنجیره بلوکی به توافق می رسند.
+
+با اتصال برنامه خود به یک گره اتریوم (از طریق [JSON-RPC API](/developers/docs/apis/json-rpc/))، برنامه شما می تواند داده ها را از زنجیره بلوکی بخواند (مانند موجودی حساب کاربر) و همچنین تراکنش های جدید را به شبکه پخش کند (مانند انتقال اتر مابین حساب های کاربری یا اجرای عملکرد قراردادهای هوشمند).
+
+## سطح 4: APIهای کلاینت اتریوم {#ethereum-client-apis}
+
+بسیاری از کتابخانه های راحتی (ساخته شده و نگهداری شده توسط جامعه متن باز اتریوم) به برنامه های کاربردی شما اجازه می دهند به زنجیره بلوکی اتریوم متصل شده و با آن ارتباط برقرار کنند.
+
+اگر برنامه رو به روی کاربر شما یک برنامه وب است، میتوانید با `نصب npm` یک [API جاوا اسکریپت](/developers/docs/apis/javascript/) را مستقیماً در فرانت اند خود داشته باشید. یا شاید شما در نظر دارید که این قابلیت را در سمت سرور، با استفاده از [Python](/developers/docs/programming-languages/python/) یا [جاوا](/developers/docs/ programming-languages/java/) API پیادهسازی کنید.
+
+در حالی که این APIها بخش ضروری پشته نیستند، اما پیچیدگی تعامل مستقیم با گره اتریوم را از بین می برند. همچنین توابع کاربردی فراهم میکنند (مثال: تبدیل اتر به GWEI) بنابراین به عنوان یک توسعه دهنده شما زمان کمتری صرف کارکردن با پیچیدگی های کاربر اتریوم، و زمان بیشتری صرف عملکرد برنامه خود میکنید.
+
+## سطح 5: برنامه های کاربر نهایی {#end-user-applications}
+
+در بالاترین سطح پشته، برنامه های کاربردی رو به روی کاربر قرار دارند. اینها برنامه های استانداردی هستند که امروزه به طور مرتب استفاده می کنید و می سازید: در درجه اول برنامه های وب و موبایل.
+
+روشی که شما این رابط های کاربری را توسعه می دهید اساساً بدون تغییر باقی می ماند. اغلب کاربران نیازی به دانستن اینکه برنامه ای که استفاده می کنند با استفاده از زنجیره بلوکی ساخته شده است، ندارند.
+
+## آماده انتخاب پشته خود هستید؟ {#ready-to-choose-your-stack}
+
+راهنمای ما را برای [تنظیم محیط توسعه محلی](/developers/local-environment/) برای برنامه اتریوم خود بررسی کنید.
+
+## بیشتر بخوانید {#further-reading}
+
+- [معماری یک برنامه Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - از _Preethi Kasireddy_
+
+_در مورد جامعه منابعی که به شما کمک می کنند بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
new file mode 100644
index 00000000000..a6aa8987b23
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
@@ -0,0 +1,147 @@
+---
+title: چارچوب های توسعه Dapp
+description: مزایای چارچوب ها را بررسی کنید و گزینه های موجود را مقایسه کنید.
+lang: fa
+---
+
+## مقدمه ای بر چارچوب ها {#introduction-to-frameworks}
+
+ساختن یک dapp تمام عیار نیازمند بخش های مختلفی از تکنولوژی است. چارچوبهای نرمافزار بسیاری از ویژگیهای مورد نیاز را در بر دارند و یا سیستمهای افزونه آسانی را برای انتخاب ابزار مورد نظر شما ارائه میدهند.
+
+این چارچوب ها با قابلیت های بسیار گسترده در دسترس اند، قابلیت هایی چون:
+
+- ویژگی هایی برای ایجاد یک نمونه زنجیره بلوکی محلی.
+- قراردادهای هوشمند خود را نهایی کرده و تست کنید.
+- افزونههای توسعه کلاینت برای اینکه برنامه رو در روی کاربرتان را در همان پروژه/مخزن بسازید.
+- پیکربندی برای اتصال به شبکههای اتریوم و استقرار قراردادها، چه در یک نمونه در حال اجرا محلی یا یکی از شبکههای عمومی اتریوم.
+- توزیع غیرمتمرکز برنامه - ادغام با گزینه های ذخیرهسازی مانند IPFS.
+
+## پیشنیازها {#prerequisites}
+
+قبل از فرو رفتن در مباحث چارچوبها، توصیه میکنیم ابتدا مقدمه ما در مورد [دپها](/developers/docs/dapps/) و [پشته اتریوم](/developers/docs/ethereum-stack/) را مطالعه کنید.
+
+## چارچوب های موجود {#available-frameworks}
+
+**Foundry** - **_ابزار Foundry یک جعبه ابزار سریع، قابل حمل و ماژولار برای توسعه برنامه اتریوم است_**
+
+- [نصب Foundry](https://book.getfoundry.sh/)
+- [کتاب Foundry](https://book.getfoundry.sh/)
+- [گروه چت کامیونیتی Foundry در تلگرام](https://t.me/foundry_support)
+- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry)
+
+**Hardhat -** **_محیط توسعه اتریوم برای حرفه ای ها_**
+
+- [hardhat.org](https://hardhat.org)
+- [گیت هاب](https://github.com/nomiclabs/hardhat)
+
+**Ape -** **_ابزار توسعه قرارداد هوشمند برای Pythonistas، دانشمندان داده، و حرفه ای های امنیتی._**
+
+- [مستندات](https://docs.apeworx.io/ape/stable/)
+- [گیت هاب](https://github.com/ApeWorX/ape)
+
+**Web3j -** **_پلتفرمی برای توسعه برنامههای بلاک چین در JVM_**
+
+- [صفحه اصلی](https://www.web3labs.com/web3j-sdk)
+- [اسناد](https://docs.web3j.io)
+- [گیت هاب](https://github.com/web3j/web3j)
+
+**ethers-kt -** **_Async، کتابخانه کاتلین/جاوا/اندروید با عملکرد بالا برای بلاک چینهای مبتنی بر ماشین مجازی اتریوم_**
+
+- [گیت هاب](https://github.com/Kr1ptal/ethers-kt)
+- [مثالها](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
+- [دیسکورد](https://discord.gg/rx35NzQGSb)
+
+**ایجاد برنامه Eth -** **_برنامه های مجهز به اتریوم را با یک دستور ایجاد کنید. با ارائه طیف گسترده ای از چارچوب های رابط کاربری و قالب های DeFi برای انتخاب ارائه می شود._**
+
+- [گیت هاب](https://github.com/paulrberg/create-eth-app)
+- [قالب ها](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
+
+**Scaffold-Eth -** **_Ethers.js + Hardhat + React کامپوننتها و قلابها برای web3: همه چیزهایی که برای شروع به منظور ساختن برنامههای غیرمتمرکز با هوش پیمانها نیاز دارید_**
+
+- [گیت هاب](https://github.com/scaffold-eth/scaffold-eth-2)
+
+**Tenderly -** **_پلتفرم توسعه Web3 که به توسعه دهندگان بلاکچین امکان می دهد قراردادهای هوشمند را بسازند، آزمایش کنند، رفع باگ کنند، نظارت کنند و اجرا کنند و dapp UX را بهبود بخشند._**
+
+- [وب سایت](https://tenderly.co/)
+- [اسناد](https://docs.tenderly.co/ethereum-development-practices)
+
+**The Graph -** **_گرافی برای جستجوی موثر دادههای بلاک چین_**
+
+- [وب سایت](https://thegraph.com/)
+- [آموزش](/developers/tutorials/the-graph-fixing-web3-data-querying/)
+
+**Alchemy** **_پلتفرم توسعه اتریوم_**
+
+- [alchemy.com](https://www.alchemy.com/)
+- [گیت هاب](https://github.com/alchemyplatform)
+- [دیسکورد](https://discord.com/invite/alchemyplatform)
+
+**NodeReal -** **_پلتفرم توسعه اتریوم._**
+
+- [Nodereal.io](https://nodereal.io/)
+- [گیت هاب](https://github.com/node-real)
+- [دیسکورد](https://discord.gg/V5k5gsuE)
+
+**Thirdweb SDK -** **_برنامههای Web3 بسازید که میتوانند با قراردادهای هوشمند شما با استفاده از SDK و CLI قدرتمند ما تعامل داشته باشند._**
+
+- [اسناد](https://portal.thirdweb.com/sdk/)
+- [گیت هاب](https://github.com/thirdweb-dev/)
+
+**Chainstack -** **_پلتفرم توسعه Web3 (اتریوم و سایرین)_**
+
+- [chainstack.com](https://www.chainstack.com/)
+- [گیتهاب](https://github.com/chainstack)
+- [دیسکورد](https://discord.gg/BSb5zfp9AT)
+
+**Crossmint -** **_پلتفرم توسعه Web3 سطح سازمانی، که به شما امکان میدهد برنامههای NFT را بر روی تمام زنجیرههای اصلی EVM Chains (و سایرین) بسازید._**
+
+- [وب سایت](https://www.crossmint.com)
+- [اسناد](https://docs.crossmint.com)
+- [دیسکورد](https://discord.com/invite/crossmint)
+
+**Brownie -** **_محیط توسعه مبتنی بر پایتون و چارچوب آزمایشی._**
+
+- [اسناد](https://eth-brownie.readthedocs.io/en/latest/)
+- [گیت هاب](https://github.com/eth-brownie/brownie)
+- **براونی در حال حاضر نگهداری نمی شود**
+
+**Truffle -** **_یک محیط توسعه، چارچوب آزمایش، خط لوله ساخت و ابزارهای دیگر. _**
+
+- [trufflesuite.com](https://www.trufflesuite.com/)
+- [گیت هاب](https://github.com/trufflesuite/truffle)
+- **توسعه Truffle به پایان رسیده است** - [بیشتر بخوانید](https://twitter.com/trufflesuite/status/1704946902393860589?t=NlIWeLTbBSAaJmS5uUAhSA&s=19)
+
+**OpenZeppelin SDK -** **_ابزارهای نهایی برای قرارداد هوشمند: مجموعه ای از ابزارهایی که به شما در توسعه، کامپایل، ارتقاء، استقرار و تعامل با قرارداد هوشمند کمک می کند._**
+
+- [OpenZeppelin SDK](https://openzeppelin.com/sdk/)
+- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-sdk)
+- [تالار گفتگو](https://forum.openzeppelin.com/c/support/17)
+- **توسعه OpenZeppelin SDK به پایان رسیده است**
+
+**Catapulta -** **_ابزار استقرار قراردادهای هوشمند چند زنجیرهای، تأیید خودکار در کاوشگرهای بلوک، پیگیری قراردادهای هوشمند مستقر شده و اشتراکگذاری گزارشهای استقرار، استفاده آسان برای پروژههای Foundry و Hardhat. _**
+
+- [وب سایت](https://catapulta.sh/)
+- [اسناد](https://catapulta.sh/docs)
+- [Github](https://github.com/catapulta-sh)
+
+**Covalent-** **_APIهای بلاک چین غنی شده برای بیش از 200 زنجیره._**
+
+- [covalenthq.com](https://www.covalenthq.com/)
+- [اسناد](https://www.covalenthq.com/docs/api/)
+- [گیت هاب](https://github.com/covalenthq)
+- [دیسکورد](https://www.covalenthq.com/discord/)
+
+**Wake -** **_چارچوب همهکاره پایتون برای آزمایش قراردادها، فازینگ، پیادهسازی، اسکن آسیبپذیری و پیمایش کد._**
+
+- [صفحه اصلی](https://getwake.io/)
+- [اسناد](https://ackeeblockchain.com/wake/docs/latest/)
+- [گیت هاب](https://github.com/Ackee-Blockchain/wake)
+- [افزونه VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [یک محیط توسعه محلی راهاندازی کنید](/developers/local-environment/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
new file mode 100644
index 00000000000..b0aa291f7f6
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
@@ -0,0 +1,71 @@
+---
+title: محیطهای توسعه جامع (IDEs)
+description:
+lang: fa
+---
+
+وقتی نوبت به راهاندازی [محیط توسعه یکپارچه (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) می رسد، برنامه نویسی برنامه های کاربردی در اتریوم مشابه برنامه نویسی هر پروژه نرم افزاری دیگری است. گزینه های زیادی برای انتخاب وجود دارد، بنابراین در نهایت، IDE یا ویرایشگر کد را انتخاب کنید که به بهترین وجه مطابق با ترجیحات شما باشد. به احتمال زیاد بهترین انتخاب IDE برای توسعه اتریوم، IDE است که قبلاً برای توسعه نرمافزار سنتی استفاده می کردید.
+
+## IDE های مبتنی بر وب {#web-based-ides}
+
+اگر می خواهید قبل از اینکه [محیط توسعه محلی را راهاندازی کنید](/developers/local-environment/) با کد کار کنید، این برنامههای وب برای توسعه قراردادهای هوشمند اتریوم سفارشی سازی شدهاند.
+
+**[ریمیکس](https://remix.ethereum.org/)** - **_IDE مبتنی بر وب با تجزیه و تحلیل استاتیک داخلی و یک ماشین مجازی آزمایشی بلاک چین است_**
+
+- [مستندات](https://remix-ide.readthedocs.io/en/latest/#)
+- [گیتر](https://gitter.im/ethereum/remix)
+
+**[ChainIDE](https://chainide.com/)** - **_یک IDE چند زنجیرهای مبتنی بر ابر_**
+
+- [مستندات](https://chainide.gitbook.io/chainide-english-1/)
+- [تالار راهنما](https://forum.chainide.com/)
+
+**[رپلیت (Replit)(Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - < strong x-id="1">_یک محیط توسعه قابل تنظیم برای اتریوم با بارگذاری مجدد، بررسی خطا و پشتیبانی درجه یک شبکه آزمایشی است_
+
+- [مستندات](https://docs.replit.com/)
+
+**[سندباکس تندرلی](https://sandbox.tenderly.co/)** - **_یک محیط نمونهسازی سریع که در آن میتوانید قراردادهای هوشمند را در مرورگر با استفاده از سالیدیتی و جاوا اسکریپت بنویسید، اجرا و اشکال زدایی کنید_**
+
+**[EthFiddle](https://ethfiddle.com/)** - **_IDE مبتنی بر وب که به شما امکان میدهد قرارداد هوشمند خود را بنویسید، کامپایل و اشکالزدایی کنید_**
+
+- [گیتر](https://gitter.im/loomnetwork/ethfiddle)
+
+## IDEهای Desktop {#desktop-ides}
+
+اکثر IDE های بهوجود آمده افزونه هایی هستند که برای بهبود تجربه توسعه اتریوم ساخته اند. حداقل، آنها برجسته سازی ترکیبی را برای [زبان های قراردادهای هوشمند](/developers/docs/smart-contracts/languages/) ارائه می دهند.
+
+**ویژوال استودیو کد -****_یک میان پلتفرم حرفهای با پشتیبانی رسمی اتریوم_**
+
+- [Visual Studio Code](https://code.visualstudio.com/)
+- [کارگاه زنجیره بلوکی Azure](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-azure-blockchain.azure-blockchain-workbench?tab=Overview)
+- [نمونه کدها](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
+- [گیتهاب](https://github.com/microsoft/vscode)
+
+**Atom -** **_یک ویرایشگر متن قابل هک برای قرن بیست و یکم_**
+
+- [Atom](https://atom.io/)
+- [گیتهاب](https://github.com/atom)
+- [بستههای اتریوم](https://atom.io/packages/search?utf8=%E2%9C%93&q=keyword%3Aethereum&commit=Search)
+
+**IDEهای JetBrains (IntelliJ IDEA, etc.) -** **_ابزارهای ضروری برای توسعه دهندگان و تیم های نرم افزار_**
+
+- [JetBrains](https://www.jetbrains.com/)
+- [گیتهاب](https://github.com/JetBrains)
+- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
+
+**Remix Desktop -** **_Remix IDE را بر روی کامپیوتر خود تجربه کنید_**
+
+- [دانلود](https://github.com/ethereum/remix-desktop/releases)
+- [گیتهاب](https://github.com/ethereum/remix-desktop)
+
+## پلاگین ها و افزونه ها {#plugins-extensions}
+
+- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - زبان اتریوم Solidity برای Visual Studio Code
+- [سالیدیتی+ هاردهت برای ویاس کد](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) -پشتیبانی سالیدیتی و هاردهت توسط تیم هاردهت
+- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - فرمت دهنده کد با استفاده از Prettier
+
+## بیشتر بخوانید {#further-reading}
+
+- [IDE های اتریوم](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- لیست IDEهای اتریوم آلکمی_
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
new file mode 100644
index 00000000000..43e1e077fd6
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
@@ -0,0 +1,30 @@
+---
+title: اتریوم برای توسعه دهندگان Dart
+description: نحوه توسعه اتریوم با استفاده از زبان برنامه نویسی Dart را بیاموزید
+lang: fa
+incomplete: true
+---
+
+## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+## آموزشها {#tutorials}
+
+- [Flutter و زنجیره بلوکی - برنامهی غیرمتمرکز سلام دنیا!](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) شما را از تمام مراحل شروع عبور میدهد تا کار را آغاز کنید:
+ 1. نصب [مجموعه توسعه Truffle](https://www.trufflesuite.com/)
+ 2. نوشتن یک قرارداد هوشمند در [Solidity](https://soliditylang.org/)
+ 3. نوشتن یک رابط کاربری در Dart
+- [ساخت دپ موبایل با Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) بسیار کوتاهتر است، که ممکن است بهتر باشد، اگر از قبل اصول اولیه را بدانید
+- اگر ترجیح میدهید با تماشای یک ویدیو چیزی را یاد بگیرید، میتوانید ویدیوی [ساخت اولین اپ فلاتر بلاکچین](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) را تماشا کنید که حدود یک ساعت طول میکشد
+- اگر حوصله ندارید، ممکن است [ساخت یک برنامه غیرمتمرکز زنجیره بلوکی با Flutter و Dart در اتریوم](https://www.youtube.com/watch?v=jaMFEOCq_1s) را ترجیح دهید، که فقط حدود بیست دقیقه است
+- [ادغام متامسک در اپ فلاتر با Web3Modal توسط WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - این ویدیوی کوتاه شما را با مراحل ادغام متامسک در اپ های فلاتر خود با کتابخانه [Web3Modal](https://pub.dev/packages/web3modal_flutter) توسط WalletConnect آشنا می کند
+- [Flutter Dapp Simple Wallet](https://youtu.be/JMfIBpuAhKA) و [First Flutter DApp - Solidity, Truffle, Ganache](https://youtu.be/bHw2gQZxJ_s) - این ویدیوها نحوه ساخت دپ های ساده در Flutter با استفاده از Truffle و Ganache را نشان می دهند
+- [Mobile Blockchain Developer Bootcamp Course With Solidity & Flutte](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - لیست پخش دورههای کامل توسعهدهنده بلاکچین تلفن همراه
+
+## کار با کلاینت های اتریوم {#working-with-ethereum-clients}
+
+از اتریوم می توانید برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapp) که از مزایای فناوری مبتنی بر رمزارز و زنجیره بلوکی استفاده می کنند، استفاده کنید. حداقل دو کتابخانه در حال حاضر برای Dart جهت استفاده از [JSON-RPC API](/developers/docs/apis/json-rpc/) برای اتریوم وجود دارد.
+
+1. [Web3dart از simonbutler.eu](https://pub.dev/packages/web3dart)
+1. [Ethereum 5.0.0 از darticulate.com](https://pub.dev/packages/ethereum)
+
+همچنین کتابخانههای دیگری وجود دارند که به شما امکان میدهند آدرسهای خاص اتریوم را دستکاری کنید یا به شما امکان میدهند قیمت ارزهای دیجیتال مختلف را بازیابی کنید. [میتوانید فهرست کامل را اینجا ببینید](https://pub.dev/dart/packages?q=ethereum).
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
new file mode 100644
index 00000000000..6ee6efd4174
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
@@ -0,0 +1,56 @@
+---
+title: اتریوم برای توسعه دهندگان Delphi
+description: نحوه توسعه اتریوم با استفاده از زبان برنامه نویسی Delphi را بیاموزید
+lang: fa
+incomplete: true
+---
+
+
+
+نحوه توسعه اتریوم با استفاده از زبان برنامه نویسی Delphi را بیاموزید
+
+
+
+از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در Ethereum مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
+
+برنامههای غیر متمرکز را بر روی اتریوم ایجاد کنید و با استفاده از زبان برنامه نویسی Delphi با قراردادهای هوشمند تعامل کنید!
+
+## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
+
+**اولین قدم های خود را برای ادغام Delphi با اتریوم بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [بیاموزید که چگونه رویه را گردآوری و استفاده کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## مراجع و پیوندهای سطح مبتدی {#beginner-references-and-links}
+
+**معرفی کتابخانه Delphereum**
+
+- [Delphereum چیست؟](https://github.com/svanas/delphereum/blob/master/README.md)
+- [اتصال Delphi به یک زنجیره بلوکی محلی (در حافظه)](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
+- [اتصال Delphi به شبکه اصلی اتریوم](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
+- [اتصال Delphi به قراردادهای هوشمند](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
+
+**آیا میخواهید فعلاً از تنظیمات رد شوید و مستقیماً به سراغ مثالها بروید؟**
+
+- [یک قرارداد هوشمند 3-دقیقه ای و Delphi - قسمت 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
+- [یک قرارداد هوشمند 3-دقیقه ای و Delphi - قسمت 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
+
+## مقالات سطح متوسط {#intermediate-articles}
+
+- [ایجاد یک امضای پیام امضا شده توسط اتریوم در Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
+- [انتقال اتر با Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
+- [انتقال توکن های ERC-20 با Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
+
+## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
+
+- [Delphi و Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
+- [QuikNode و Ethereum و Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
+- [Delphi و Ethereum Dark Forest](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
+- [در Delphi یک توکن را با نشانه دیگر عوض کنید](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
+
+به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/).
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
new file mode 100644
index 00000000000..09e8a7c9919
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
@@ -0,0 +1,86 @@
+---
+title: اتریوم برای توسعه دهندگان NET.
+description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر NET. توسعه دهید
+lang: fa
+incomplete: true
+---
+
+یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر NET. توسعه دهید
+
+از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و بلاکچین استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در Ethereum مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
+
+برنامه های غیرمتمرکز را بر روی اتریوم بسازید و با قراردادهای هوشمند با استفاده از ابزارها و زبان های پشته فناور مایکروسافت، در تعامل باشید - پشتیبانی از #F# ،#Visual Basic .Net، C بر روی ابزارهایی مانند VSCode و Visual Studio، در سراسر NET Framework/.NET Core/.NET Standard. در عرض چند دقیقه یک زنجیره بلوکی اتریومی را با استفاده از زنجیره بلوکی Azure مایکروسافت بر روی Azure مستقر کنید. عشق NET. را به اتریوم بیاورید!
+
+## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
+
+**اولین قدم های خود را برای ادغام NET. با اتریوم بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [بیاموزید که چگونه Solidity را کامپایل و به کار گیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## مراجع و پیوندهای سطح مبتدی {#beginner-references-and-links}
+
+**معرفی کتابخانه Nethereum و VS Code Solidity**
+
+- [Nethereum، شروع به کار](https://docs.nethereum.com/en/latest/getting-started/)
+- [نصب VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
+- [گردش کار یک برنامه نویس NET. برای ایجاد و فراخوانی قراردادهای هوشمند اتریوم](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
+- [یکپارچه سازی قراردادهای هوشمند با Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
+- [ارتباط با NET. و زنجیره بلوکی اتریوم قراردادهای هوشمند با Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933)، همچنین در [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80 %A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F %88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
+- [Nethereum - یک کتابخانه منبع باز یکپارچه سازی NET. برای زنجیره بلوکی](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
+- [نوشتن تراکنش های اتریوم در پایگاه داده SQL با استفاده از Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
+- [ببینید چگونه می توان به راحتی قراردادهای هوشمند اتریوم را با استفاده از #C و VisualStudio پیادهسازی کرد](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
+
+**آیا میخواهید فعلاً از تنظیمات رد شوید و مستقیماً به سراغ مثالها بروید؟**
+
+- [Playground](http://playground.nethereum.com/) - با اتریوم تعامل داشته باشید و نحوه استفاده از Nethereum را از طریق مرورگر یاد بگیرید.
+ - استعلام موجودی حساب [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
+ - موجودی قرارداد هوشمند ERC20 را جستجو کنید [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id /2004)
+ - انتقال اتر به یک حساب [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id /2003)
+ - ... و موارد دیگر!
+
+## مقالات سطح متوسط {#intermediate-articles}
+
+- [کتاب کار/ فهرست مثال های Nethereum](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
+- [زنجیره های آزمایشی توسعه خود را مستقر کنید](https://github.com/Nethereum/Testchains)
+- [VSCode Codegen افزونه ای برای Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
+- [یونیتی و اتریوم: چرا و چگونه](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
+- [ASP.NET Core Web API را برای dappهای اتریوم ایجاد کنید](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
+- [استفاده از Nethereum Web3 برای پیاده سازی یک سیستم ردیابی زنجیره تامین](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
+- [پردازش بلوک Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/)، با [نمونه زمین بازی C#](http://playground.nethereum.com/csharp/id/1025)
+- [جریان وب سوکت Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
+- [Kaleido و Nethereum](https://kaleido.io/kaleido-and-nethereum/)
+- [Quorum و Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
+
+## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
+
+- [Azure Key Vault و Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
+- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
+- [معماری مرجع Ujo Nethereum Backend](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
+
+## پروژه های NET.، ابزارها و سایر موارد سرگرمکننده {#dot-net-projects-tools-and-other-fun-stuff}
+
+- [Nethereum Playground](http://playground.nethereum.com/) - _قطعه کدهای Nethereum را در مرورگر کامپایل، ایجاد و اجرا کنید_
+- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _تولید کد Nethereum با رابط کاربری در Blazor_
+- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _کاوشگر سبک زنجیره بلوکی Wasm SPA و یک کیف پول ساده_
+- [موتور قوانین تجاری Wonka](https://docs.nethereum.com/en/latest/wonka/) - _یک موتور قوانین تجاری (برای هر دو پلتفرم NET. و پلتفرم اتریوم) که ذاتاً مبتنی بر ابر داده_ است
+- [Nethermind](https://github.com/NethermindEth/nethermind) - _یک کلاینت NET. Core اتریومی برای Linux، Windows، MacOs_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _توابعی برای کار با پایگاههای کد مرتبط با اتریوم_
+- [TestChains](https://github.com/Nethereum/TestChains) - _شبکههای توسعهدهنده NET. از پیش تنظیم شده برای پاسخ سریع (PoA)_
+
+به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/).
+
+## مشارکت کنندگان انجمن NET. {#dot-net-community-contributors}
+
+در Nethereum، ما بیشتر در [Gitter](https://gitter.im/Nethereum/Nethereum) وقت می گذرانیم، جایی که همه می توانند سؤال بپرسند/پاسخ دهند، کمک دریافت کنند یا فقط آرام باشند. با خیال راحت در [مخزن Nethereum GitHub](https://github.com/Nethereum) یک گفتگو انجام دهید یا مشکلی را باز کنید، یا فقط پروژههای جانبی/نمونهای که داریم را مرور کنید. همچنین میتوانید ما را در [Discord](https://discord.gg/jQPrR58FxX) پیدا کنید!
+
+اگر تازهوارد Nethermind هستید و برای شروع به کمک نیاز دارید، به [Discord](http://discord.gg/PaCMRFdvWT) ما بپیوندید. توسعه دهندگان ما آماده پاسخگویی به سوالات شما هستند. از باز کردن روابط عمومی یا طرح هر گونه مشکلی دریغ نکنید[مخزن Nethermind GitHub](https://github.com/NethermindEth/nethermind) را بررسی کنید.
+
+## سایر لیست های گردآوری شده {#other-aggregated-lists}
+
+[سایت رسمی Nethereum](https://nethereum.com/)
+[سایت رسمی Nethermind](https://nethermind.io/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
new file mode 100644
index 00000000000..d4842051cfa
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
@@ -0,0 +1,85 @@
+---
+title: اتریوم برای توسعه دهندگان Go
+description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر Go توسعه دهید
+lang: fa
+incomplete: true
+---
+
+یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر Go توسعه دهید
+
+از اتریوم برای ایجاد برنامه های غیرمتمرکز (یا "dapps") استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در اتریوم مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها غیرمتمرکز هستند، به این معنی که آنها در یک شبکه همتا به همتا اجرا می شوند و هیچ نقطه شکست واحدی در آنها وجود ندارد. هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریبا غیرممکن است. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود.
+
+## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**اولین قدم های خود را برای ادغام Go با اتریوم بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [بیاموزید که چگونه Solidity را کامپایل و بهکارگیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [آموزش قرارداد](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
+
+## مقاله ها و کتاب های مبتدی {#beginner-articles-and-books}
+
+- [انتخاب یک کلاینت اتریومی](https://www.trufflesuite.com/docs/truffle/reference/choosing-an-ethereum-client)
+- [شروع به کار با Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
+- [از Golang برای اتصال به اتریوم استفاده کنید](https://www.youtube.com/watch?v=-7uChuO_VzM)
+- [قراردادهای هوشمند اتریوم را با استفاده از Golang مستقر کنید](https://www.youtube.com/watch?v=pytGqQmDslE)
+- [راهنمای گام به گام تست و استقرار قراردادهای هوشمند اتریوم در Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
+- [eBook: توسعه اتریوم با Go](https://goethereumbook.org/) - _برنامههای اتریوم را با Go توسعه دهید_
+
+## مقالات و مستندات سطح متوسط {#intermediate-articles-and-docs}
+
+- [مستندات اتریومی Go](https://geth.ethereum.org/docs/) - _اسناد رسمی مربوط به اتریوم Golang _
+- [راهنمای برنامه نویس اریگون](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _راهنمای مصور از جمله درخت حالت، چند اثبات و پردازش تراکنش_
+- [Erigon و اتریوم بدون حالت](https://youtu.be/3-Mn7OckSus?t=394) - _کنفرانس انجمن اتریوم 2020 (EthCC 3)_
+- [Erigon: بهینه سازی مشتریان اتریوم](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_
+- [Go اتریوم GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
+- [ایجاد Dapp در Go با Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
+- [با Golang و Geth با شبکه خصوصی اتریوم کار کنید](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
+- [واحد تستی قراردادهای Solidity در اتریوم با Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
+- [مرجعی سریع برای استفاده از Geth به عنوان یک کتابخانه](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
+
+## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
+
+- [بک اند شبیه سازی شده GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
+- [برنامه های زنجیره ی بلوکی به عنوان یک سرویس با استفاده از اتریوم و Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
+- [ذخیرهسازی توزیع شده IPFS و Swarm در برنامه های زنجیره بلوکی اتریومی](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
+- [مشتریان موبایل: کتابخانه ها و گره های اتریوم Inproc](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
+- [Dapps بومی: به قراردادهای اتریوم متصل شوید](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
+
+## پروژه ها و ابزارهای Go {#go-projects-and-tools}
+
+- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _پیادهسازی رسمی پروتکل اتریوم با Go _
+- [تجزیه و تحلیل کد اتریوم Go](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _بررسی و تجزیه و تحلیل منبع کد اتریومی Go _
+- [Erigon](https://github.com/ledgerwatch/erigon) - _مشتق سریعتر Go Ethereum، با تمرکز بر گرههای بایگانی_
+- [Golem](https://github.com/golemfactory/golem) - _Golem در حال ایجاد یک بازار جهانی برای قدرت محاسباتی است_
+- [Quorum](https://github.com/jpmorganchase/quorum) - _اجازه اجرای اتریوم با پشتیبانی از حریم خصوصی داده_
+- [Prysm](https://github.com/prysmaticlabs/prysm) - _اجرای اتریوم 'Serenity' 2.0 Go_
+- [Eth Tweet](https://github.com/yep/eth-tweet) - _ توئیتر غیرمتمرکز: یک سرویس میکروبلاگینگ در حال اجرا بر روی زنجیره بلوکی اتریوم_
+- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _اجرای Golang و گسترش حداقل مشخصات پلاسمای قابل دوام_
+- [استخر استخراج اتریوم باز](https://github.com/sammy007/open-ethereum-pool) - _یک استخر استخراج اتریوم منبع باز_
+- [کیف پول اتریوم HD](https://github.com/miguelmota/go-ethereum-hdwallet) - _مشتقات کیف پول اتریوم HD در Go_
+- [Multi Geth](https://github.com/multi-geth/multi-geth) - _پشتیبانی از بسیاری از گونههای شبکههای اتریوم_
+- [Geth Light Client](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _پیادهسازی پروتکل فرعی Light Ethereum Geth _
+- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _اجرای کیف پول اتریوم و ابزارهای کاربردی ساده در Golang_
+- [کووالنت گولنگ SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _دسترسی کارآمد به دادههای بلاک چین از طریق Go SDK برای بیش از 200 بلاک چین امکانپذیر است_
+
+به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/)
+
+## مشارکت کنندگان انجمن Go {#go-community-contributors}
+
+- [Geth Discord](https://discordapp.com/invite/nthXNEv)
+- [Geth Gist](https://gitter.im/ethereum/go-ethereum)
+- [Gophers Slack](https://invite.slack.golangbridge.org/) - [کانال ethereum#](https://gophers.slack.com/messages/C9HP1S9V2)
+- [StackExchange - اتریوم](https://ethereum.stackexchange.com/)
+- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
+- [Ethereum Gitter](https://gitter.im/ethereum/home)
+- [Geth light Client Gitter](https://gitter.im/ethereum/light-client)
+
+## سایر لیست های گردآوری شده {#other-aggregated-lists}
+
+- [اتریوم فوقالعاده](https://github.com/btomashvili/awesome-ethereum)
+- [Consensys: فهرستی قطعی از ابزارهای توسعه دهنده اتریوم](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [منبع GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
new file mode 100644
index 00000000000..7ebca2d9c5f
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
@@ -0,0 +1,29 @@
+---
+title: زبان های برنامه نویسی
+description:
+lang: fa
+---
+
+یک تصور غلط رایج این است که توسعه دهندگان باید [قراردادهای هوشمند](/developers/docs/smart-contracts/) بنویسند تا بتوانند بر روی اتریوم بسازند. این نادرست است. یکی از زیباییهای شبکه و انجمن اتریوم این است که شما میتوانید تقریباً در هر زبان برنامهنویسی [شرکت](/community/) داشته باشید.
+
+اتریوم و جامعه آن از منبع باز استقبال می کنند. شما میتوانید پروژههای اجتماعی - پیادهسازی کلاینت، APIها، چارچوبهای توسعه، ابزارهای آزمایشی - را به زبانهای مختلف پیدا کنید.
+
+## زبان خود را انتخاب کنید {#data}
+
+زبان برنامه نویسی منتخب را برای پیدا کردن پروژه ها، منابع و جوامع مجازی انتخاب کنید:
+
+- [اتریوم برای توسعه دهندگان Dart](/developers/docs/programming-languages/dart/)
+- [اتریوم برای توسعه دهندگان Delphi](/developers/docs/programming-languages/delphi/)
+- [اتریوم برای توسعه دهندگان .NET](/developers/docs/programming-languages/dot-net/)
+- [اتریوم برای توسعه دهندگان Go](/developers/docs/programming-languages/golang/)
+- [اتریوم برای توسعه دهندگان جاوا](/developers/docs/programming-languages/java/)
+- [اتریوم برای توسعه دهندگان JavaScript](/developers/docs/programming-languages/javascript/)
+- [اتریوم برای توسعه دهندگان Python](/developers/docs/programming-languages/python/)
+- [اتریوم برای توسعه دهندگان رابی](/developers/docs/programming-languages/ruby/)
+- [اتریوم برای توسعه دهندگان Rust](/developers/docs/programming-languages/rust/)
+
+### اگر زبان من پشتیبانی نشود چه؟ {#other-lang}
+
+اگر میخواهید برای یک زبان برنامهنویسی اضافی به منابع پیوند دهید یا به یک جامعه مجازی اشاره کنید، میتوانید با [باز کردن یک مساله](https://github.com/ethereum/ethereum-org-website/issues/new/ select) صفحه جدیدی را درخواست کنید.
+
+اگر فقط می خواهید با استفاده از زبانی که در حال حاضر پشتیبانی نمی شود، کد بنویسید تا با زنجیره بلوکی ارتباط برقرار کنید می توانید از [رابط JSON-RPC](/developers/docs/apis/json-rpc/) برای اتصال به شبکه اتریوم استفاده کنید. هر زبان برنامه نویسی که بتواند از TCP/IP استفاده کند می تواند از این رابط استفاده کند.
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
new file mode 100644
index 00000000000..a613deab1d2
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
@@ -0,0 +1,65 @@
+---
+title: اتریوم برای توسعه دهندگان جاوا
+description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر جاوا توسعه دهید
+lang: fa
+incomplete: true
+---
+
+یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر جاوا توسعه دهید
+
+از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در اتریوم مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
+
+## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**اولین قدم های خود را برای ادغام جاوا با اتریوم بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرسهای زیر را بررسی کنید [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/)
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین هوش پیمان خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [نحوه کامپایل و استقرار Solidity را بیاموزید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## کار با کلاینت های اتریوم {#working-with-ethereum-clients}
+
+نحوه استفاده از [Web3J](https://github.com/web3j/web3j) و Hyperledger Besu، دو کلاینت پیشرو جاوا اتریوم را بیاموزید
+
+- [اتصال به کلاینت اتریوم با Java، Eclipse و Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
+- [یک حساب اتریوم را با Java و Web3j مدیریت کنید](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
+- [از قرارداد هوشمند خود یک Java Wrapper ایجاد کنید](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
+- [تعامل با یک قرارداد هوشمند اتریومی](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
+- [گوش دادن به رویدادهای قرارداد هوشمند اتریومی](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
+- [استفاده از Besu (Pantheon)، کلاینت Java اتریوم با لینوکس](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
+- [اجرای یک گره Hyperledger (Pantheon) در آزمونهای ادغام Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
+- [برگه Cheat Web3j](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c)
+
+نحوه استفاده از [ethers-kt](https://github.com/Kr1ptal/ethers-kt) را بیاموزید که یک کتابخانه همگام و با کارایی بالا کاتلین برای تعامل با بلاکچینهای مبتنی بر ماشین مجازی اتریوم است. هدف قرار دادن پلتفرمهای JVM و اندروید.
+- [انتقال توکنهای ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
+- [سواپ Uniswap ورژن 2 با گوش دادن به رویداد (event listening)](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
+- [ردیاب تعادل ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
+
+## مقالات سطح متوسط {#intermediate-articles}
+
+- [مدیریت فضای ذخیره سازی در برنامه Java با IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
+- [مدیریت توکن های ERC20 در Java با Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
+- [مدیران تراکنش Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
+
+## الگوهای استفاده پیشرفته {#advanced-use-patterns}
+
+- [استفاده از اتریوم برای ساخت داده حافظه پنهان از یک قرارداد هوشمند جاوایی](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
+
+## پروژه ها و ابزارهای جاوا {#java-projects-and-tools}
+
+- [Hyperledger Besu (Pantheon) (کلاینت اتریوم)](https://docs.pantheon.pegasys.tech/en/stable/)
+- [Web3J (کتابخانه ای برای تعامل با کلاینت های اتریوم)](https://github.com/web3j/web3j)
+- [ethers-kt (Async، کتابخانه کاتلین/جاوا/اندروید با کارایی بالا برای بلاک چینهای مبتنی بر ماشین مجازی اتریوم.)](https://github.com/Kr1ptal/ethers-kt)
+- [Eventeum (شنونده رویداد)](https://github.com/ConsenSys/eventeum)
+- [Mahuta (ابزار توسعه دهنده IPFS)](https://github.com/ConsenSys/mahuta)
+
+به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/)
+
+## مشارکت کنندگان انجمن جاوا {#java-community-contributors}
+
+- [IO Builders](https://io.builders)
+- [Kauri](https://kauri.io)
+- [Besu HL chat](https://chat.hyperledger.org/channel/besu)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
new file mode 100644
index 00000000000..1d68fc64734
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
@@ -0,0 +1,73 @@
+---
+title: اتریوم برای توسعه دهندگان جاوا اسکریپت
+description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر جاوا اسکریپت توسعه دهید.
+lang: fa
+---
+
+جاوا اسکریپت از محبوب ترین زبان ها در اکوسیستم اتریوم است. در واقع، یک [تیم](https://github.com/ethereumjs) وجود دارد که تا حد ممکن اتریوم را به جاوا اسکریپت بیاورند.
+
+در [همه سطوح پشته](/developers/docs/ethereum-stack/) فرصتهایی برای نوشتن جاوا اسکریپت (یا چیزی نزدیک به آن) وجود دارد.
+
+## تعامل با اتریوم {#interact-with-ethereum}
+
+### کتابخانه های API جاوا اسکریپت {#javascript-api-libraries}
+
+اگر میخواهید جاوا اسکریپت بنویسید تا زنجیره بلوکی را پرس و جو کنید، تراکنشها را ارسال کنید، راحتترین راه برای انجام این کار استفاده از [کتابخانه API جاوا اسکریپت](/developers/docs/apis/javascript/) است. این APIها به توسعه دهندگان این امکان را می دهند تا به راحتی با [گره های شبکه اتریوم](/developers/docs/nodes-and-clients/) تعامل داشته باشند.
+
+میتوانید از این کتابخانهها برای تعامل با قراردادهای هوشمند در اتریوم استفاده کنید، بنابراین میتوانید یک dapp بسازید که در آن از جاوا اسکریپت تنها برای تعامل با قراردادهای قبلی استفاده کنید.
+
+**بررسی**
+
+- [Web3.js](https://web3js.readthedocs.io/)
+- [Ethers.js](https://docs.ethers.io/) _– شامل پیادهسازی کیف پول اتریوم و ابزارهای کاربردی در جاوا اسکریپت و تایپ اسکریپت میشود._
+- [viem](https://viem.sh) – یک واسط تایپ اسکریپت برای اتریوم که موارد اولیه بدون حالت سطح پایین را برای تعامل با اتریوم فراهم میکند.
+
+### قراردادهای هوشمند {#smart-contracts}
+
+اگر یک توسعهدهنده جاوا اسکریپت هستید و میخواهید قرارداد هوشمند خود را بنویسید، بهتر است با [Solidity](https://solidity.readthedocs.io) آشنا شوید. این محبوب ترین زبان قرارداد هوشمند است و از نظر ترکیبی شبیه به جاوا اسکریپت است که ممکن است یادگیری آن را آسان تر کند.
+
+اطلاعات بیشتر در مورد [قراردادهای هوشمند](/developers/docs/smart-contracts/).
+
+## پروتکل را درک کنید {#understand-the-protocol}
+
+### ماشین مجازی اتریوم {#the-ethereum-virtual-machine}
+
+یک پیادهسازی جاوا اسکریپتی از [ماشین مجازی اتریوم](/developers/docs/evm/) وجود دارد. که از آخرین قوانین فورک پشتیبانی می کند. قوانین فورک به تغییراتی اشاره دارد که در نتیجه ارتقاهای برنامه ریزی شده در EVM ایجاد شده است.
+
+این به بسته های مختلف جاوا اسکریپت تقسیم می شود که می توانید برای درک بهتر آن ها را بررسی کنید:
+
+- حساب ها
+- بلوکها
+- خود زنجیره بلوکی
+- تراکنشها
+- و موارد دیگر...
+
+این به شما کمک می کند مواردی مانند "ساختار داده یک حساب" را درک کنید.
+
+اگر ترجیح می دهید کد بخوانید، این جاوا اسکریپت می تواند جایگزین خوبی برای خواندن از طریق اسناد ما باشد.
+
+** monorepo را بررسی کنید**
+[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm)
+
+### گرهها و کاربرها {#nodes-and-clients}
+
+یک کلاینت Ethereumjs در حال توسعه فعال است که به شما امکان میدهد نحوه کار مشتریان اتریوم را به زبانی که بهتر میفهمید بررسی کنید و آن جاوا اسکریپت است!
+
+قبلاً در یک [`مخزن`](https://github.com/ethereumjs/ethereumjs-client) مستقل قرار داشت، اما بعداً به عنوان یک بسته در مونورپو اتریوم ویام ادغام شد.
+
+** کلاینت را بررسی کنید**
+[`ethereumjs-client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
+
+## پروژه های دیگر {#other-projects}
+
+همچنین چیزهای بسیار دیگر در سرزمین جاوا اسکریپت اتریوم در حال انجام است، از جمله:
+
+- کتابخانه های خدمات کیف پول.
+- ابزارهایی برای تولید، وارد کردن، و صدور کلیدهای اتریوم.
+- پیادهسازی `merkle-patricia-tree` - ساختار داده ای که در مقاله زرد اتریوم مشخص شده است.
+
+در [ مخزن EthereumJS](https://github.com/ethereumjs) هر چیزی را که بیشتر به آن علاقه دارید جستجو کنید
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
new file mode 100644
index 00000000000..71c206cf840
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
@@ -0,0 +1,90 @@
+---
+title: اتریوم برای توسعه دهندگان پایتون
+description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر پایتون توسعه دهید
+lang: fa
+incomplete: true
+---
+
+یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر پایتون توسعه دهید
+
+از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در اتریوم مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
+
+## شروع به کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**اولین قدم های خود را برای ادغام پایتون با Ethereum بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [بیاموزید که چگونه Solidity را کامپایل و بهکارگیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## مقالات مبتدی {#beginner-articles}
+
+- [راهنمای توسعهدهنده (Python) برای اتریوم](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
+- [گزارش وضعیت پایتون در بلاک چین 2023](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
+- [مقدمه ای بر قراردادهای هوشمند با Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
+- [توکن ERC20 خود را با Python و Brownie مستقر کنید](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
+- [چطور می توان قرارداد اتریوم را با استفاده از Python Flask توسعه داد؟](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
+- [معرفی Web3.py · اتریوم برای توسعه دهندگان Python](https://www.dappuniversity.com/articles/web3-py-intro)
+- [چگونه یک تابع قرارداد هوشمند را با استفاده از پایتون وweb3.py فراخوانی کنیم](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
+
+## مقالات سطح متوسط {#intermediate-articles}
+
+- [توسعه ی برنامه های غیرمتمرکز برای برنامه نویسان پایتون](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
+- [ساخت یک رابط پایتون اتریوم: قسمت 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
+- [قراردادهای هوشمند اتریوم در پایتون: یک راهنمای جامع](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
+- [استفاده از Brownie و Python برای استقرار قراردادهای هوشمند](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
+- [ایجاد NFT ها در OpenSea با Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
+
+## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
+
+- [کامپایل، توسعه و فراخوانی قرارداد هوشمند اتریوم با استفاده از پایتون](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
+- [قراردادهای هوشمند رویه ای را با لغزش گر تجزیه و تحلیل کنید](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
+- [آموزش Fintech زنجیره بلوکی: وام دادن و قرض گرفتن با Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+
+## پروژه ها و ابزارهای Python {#python-projects-and-tools}
+
+### فعال: {#active}
+
+- [Web3.py](https://github.com/ethereum/web3.py) - _کتابخانه Python برای تعامل با اتریوم_
+- [Vyper](https://github.com/ethereum/vyper/) - _زبان قرارداد هوشمند Pythonic برای EVM_
+- [Ape - __ابزار توسعه قرارداد هوشمند برای Pythonistas، دانشمندان داده، و حرفه ای های امنیتی.](https://github.com/ApeWorX/ape)
+- [py-evm](https://github.com/ethereum/py-evm) - _پیادهسازی ماشین مجازی اتریوم_
+- [eth-tester](https://github.com/ethereum/eth-tester) - _ابزارهایی برای تست برنامههای مبتنی بر اتریوم_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _utility _ توابعی برای کار با پایگاه های کد مرتبط با اتریوم
+- [py-solc-x](https://pypi.org/project/py-solc-x/) - _Python wrapper در اطراف کامپایلر solc solidity با پشتیبانی 0.5.x_
+- [pymaker](https://github.com/makerdao/pymaker) - _Python API برای قراردادهای سازنده_
+- [siwe](https://github.com/spruceid/siwe-py) - _برای پایتون با اتریوم وارد شوید (siwe)_
+- [Web3 DeFi برای ادغامهای اتریوم](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _یک بسته پایتون با ادغامهای آماده برای ERC-20، Uniswap و سایر پروژه های محبوب_
+- [Wake](https://getwake.io) - _چارچوب یکپارچه پایتون برای آزمایش قراردادها، فازبندی، استقرار، اسکن آسیبپذیری و پیمایش کد (سرور زبان - [ابزارهای سالیدیتی](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
+
+### بایگانی شده / دیگر نگهداری نمی شود: {#archived--no-longer-maintained}
+
+- [Trinity](https://github.com/ethereum/trinity) - _کاربر Python اتریوم_
+- [Mamba](https://github.com/arjunaskykok/mamba) - _چارچوبی برای نوشتن، کامپایل و استقرار قراردادهای هوشمند نوشته شده به زبان Vyper_
+- [Brownie](https://github.com/eth-brownie/brownie) - _Python چارچوبی برای توسعه، تست و تعامل با قراردادهای هوشمند اتریوم_
+- [pydevp2p](https://github.com/ethereum/pydevp2p) - _پیاده سازی پشته P2P اتریوم_
+- [py-wasm](https://github.com/ethereum/py-wasm) - _پیاده سازی مفسر اسمبلی وب توسط پایتون_
+
+به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/).
+
+## پروژه هایی که از ابزار Python استفاده می کنند {#projects-using-python-tooling}
+
+پروژههای مبتنی بر اتریوم زیر از ابزارهایی استفاده میکنند که در این صفحه ذکر شده است. مخازن منبع باز مرتبط، به عنوان یک مرجع خوب برای نمونه کد و بهترین شیوه ها عمل می کنند.
+
+- [Yearn Finance](https://yearn.finance/) و [مخزن قراردادهای Yearn Vault](https://github.com/yearn/yearn-vaults)
+- [Curve](https://curve.fi/) و [مخزن قراردادهای هوشمند Curve](https://github.com/curvefi/curve-contract)
+- [BadgerDAO](https://badger.com/) و [قراردادهای هوشمندی که از زنجیره ابزار Brownie استفاده می کنند](https://github.com/Badger-Finance/badger-system)
+- [Sushi](https://sushi.com/) از [Python در مدیریت و استقرار قراردادهای خود استفاده می کند](https://github.com/sushiswap/sushi-vesting-protocols)
+- [Alpha Finance](https://alphafinance.io/)، معروف به Alpha Homora، از [ Brownie برای آزمایش و استقرار قراردادهای هوشمند استفاده میکند](https://github.com/AlphaFinanceLab/alpha-staking-contract)
+
+## بحث جامعه پایتون {#python-community-contributors}
+
+- [Ethereum Python Community Discord](https://discord.gg/9zk7snTfWe) برای Web3.py و سایر بحثهای چارچوب پایتون
+- [دیسکورد وایپر](https://discord.gg/SdvKC79cJk) برای بحث برنامهنویسی قرارداد هوشمند وایپر
+
+## سایر لیست های گردآوری شده {#other-aggregated-lists}
+
+ویکی Vyper یک [فهرست باورنکردنی از منابع برای Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) دارد
\ No newline at end of file
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
new file mode 100644
index 00000000000..b872efead18
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
@@ -0,0 +1,61 @@
+---
+title: اتریوم برای توسعه دهندگان رابی
+description: یاد بگیرید چگونه برای اتریوم با استفاده از پروژه ها و ابزارهای مبتنی بر رابی توسعه دهید.
+lang: fa
+incomplete: false
+---
+
+یاد بگیرید چگونه برای اتریوم با استفاده از پروژه ها و ابزارهای مبتنی بر رابی توسعه دهید.
+
+از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند، به این معنا که وقتی در Ethereum مستقر شوند، همیشه طبق برنامه اجرا می شوند. آنها می توانند دارایی های دیجیتال را برای ایجاد انواع جدیدی از برنامه های کاربردی مالی کنترل کنند. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
+
+## شروع به کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**اولین قدم های خود را برای ادغام رابی با اتریوم بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [بیاموزید که چگونه Solidity را کامپایل و به کار گیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## مقالات مبتدی {#beginner-articles}
+
+- [در نهایت درک حساب های اتریوم](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [در نهایت احراز هویت کاربران Rails با MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
+- [ورود به سیستم با اتریوم - انتشار نمونههای کتابخانه رابی و ریل](https://blog.spruceid.com/sign-in-with-ethereum-ruby-library-release-and-rails-examples/)
+- [نحوه اتصال به شبکه اتریوم با استفاده از رابی](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
+- [نحوه ایجاد یک آدرس جدید اتریوم در رابی](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
+
+## مقالات سطح متوسط {#intermediate-articles}
+
+- [اپلیکیشن بلاک چین با رابی](https://www.nopio.com/blog/blockchain-app-ruby/)
+- [از رابی متصل به اتریوم برای اجرای قرارداد هوشمند استفاده کنید](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
+
+## پروژه ها و ابزارهای رابی {#ruby-projects-and-tools}
+
+### فعال {#active}
+
+- [eth.rb](https://github.com/q9f/eth.rb) - _کتابخانه Ruby و RPC-client برای مدیریت حسابهای اتریوم، پیامها و معاملات_
+- [keccak.rb](https://github.com/q9f/keccak.rb) - _هش Keccak (SHA3) مورد استفاده اتریوم_
+- [siwe-ruby](https://github.com/spruceid/siwe-ruby) - _اجرای رابی ورود به سیستم با اتریوم_
+- [siwe_rails](https://github.com/spruceid/siwe_rails) - _نگین Rails که مسیرهای ورود به سیستم محلی SIWE را اضافه میکند_
+- [siwe-rails-examples](https://github.com/spruceid/siwe-rails-examples) - _نمونه SIWE با استفاده از Ruby on Rails با کنترل کننده سفارشی_
+- [omniauth-siwe](https://github.com/spruceid/omniauth-siwe) - _استراتژی OmniAuth برای ورود با اتریوم (SIWE)_
+- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _استراتژی OmniAuth برای احراز هویت از طریق مالکیت NFT_
+- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _الگوی Ethereum on Rails که امکان اتصال MetaMask به Ruby on Rails را فراهم میکند_
+
+### بایگانی شده / دیگر نگهداری نمی شود {#archived--no-longer-maintained}
+
+- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _ فراخوانی روشهای RPC گره اتریوم با رابی_
+- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _کتابخانه Ruby برای تولید آدرسهای ETH از کیف پول قطعی سلسله مراتبی طبق استاندارد BIP32 _
+- [etherlite](https://github.com/budacom/etherlite) - _ادغام اتریوم برای Ruby on Rails_
+- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _کلاینت Ruby Ethereum با استفاده از رابط JSON-RPC برای ارسال تراکنش ها ، ایجاد و تعامل با قراردادها و همچنین جعبه ابزار مفید برای کار با Ethereum node_
+- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _استراتژی ارائهدهنده اتریوم را برای OmniAuth اجرا میکند_
+
+به دنبال منابع بیشتری هستید؟ [خانه برنامهنویس ما](/developers/) را بررسی کنید.
+
+## مشارکت کنندگان جامعه رابی {#ruby-community-contributors}
+
+[گروه تلگرام اتریوم روبی](https://t.me/ruby_eth) میزبان جامعهای است که به سرعت در حال رشد است و منبع اختصاصی برای بحث در مورد هر یک از پروژههای فوق و موضوعات مرتبط است.
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
new file mode 100644
index 00000000000..856874774fe
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
@@ -0,0 +1,64 @@
+---
+title: اتریوم برای توسعه دهندگان Rust
+description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر rust توسعه دهید
+lang: fa
+incomplete: true
+---
+
+یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر Rust توسعه دهید
+
+از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در Ethereum مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
+
+## شروع به کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**اولین قدم های خود را برای ادغام Rust با اتریوم بردارید**
+
+آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرسهای زیر را بررسی کنید [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/).
+
+- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [بیاموزید که چگونه رویه را گردآوری و استفاده کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## مقالات مبتدی {#beginner-articles}
+
+- [انتخاب یک کلاینت اتریومی](https://www.trufflesuite.com/docs/truffle/reference/choosing-an-ethereum-client)
+- [کلاینت Rust Ethereum](https://openethereum.github.io/) \* **توجه داشته باشید که OpenEthereum [منسوخ شده است](https://medium.com/openethereum/gnosis-joins-erigon-forerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) و دیگر نگهداری نمی شود.** از آن با احتیاط استفاده کنید و ترجیحاً به پیاده سازی کلاینت دیگری بروید.
+- [ارسال تراکنش به اتریوم با استفاده از Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
+- [آموزش گام به گام نحوه نوشتن قراردادها در Rust Wasm برای Kovan](https://github.com/paritytech/pwasm-tutorial)
+
+## مقالات سطح متوسط {#intermediate-articles}
+
+## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
+
+- [pwasm_ethereum کتابخانه خارجی برای تعامل با شبکه شبیه اتریوم](https://github.com/openethereum/pwasm-ethereum)
+- [ایجاد یک چت غیرمتمرکز با استفاده از JavaScript و Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
+- [با استفاده از Vue.js & Rust یک برنامه غیرمتمرکز Todo بسازید](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
+
+- [یک بلاک چین در Rust بسازید](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
+
+## پروژه ها و ابزارهای Rust {#rust-projects-and-tools}
+
+- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _مجموعهای از بخشهای خارجی برای تعامل با شبکههای شبه اتریوم em>
+- [Lighthouse](https://github.com/sigp/lighthouse) - _کلاینت لایهی اجماع سریع اتریوم_
+- [اتریوم وب اسمبلی](https://ewasm.readthedocs.io/en/mkdocs/) - _طراحی مجدد لایه اجرای قرارداد هوشمند اتریوم با استفاده از بخش قطعی زیر مجموعه را ارائه میدهد. WebAssembly_
+- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _مرجع API OASIS_
+- [سولاریس](https://github.com/paritytech/sol-rs) - _دستگاه تست واحد قراردادهای هوشمند سالیدیتی با استفاده از Parity Client EVM اصلی.< /em>
+- [SputnikVM](https://github.com/rust-blockchain/evm) - _پیاده سازی ماشین مجازی Rust Ethereum_
+- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _قرارداد هوشمند Wavelet در Rust_
+- [فوندری](https://github.com/foundry-rs/foundry) - _ابزار توسعه برنامه اتریوم_
+- [آلوی](https://alloy.rs) - _با عملکرد بالا، به خوبی آزمایش شده و amp; کتابخانههای مستند شده برای تعامل با اتریوم و سایر زنجیرههای مبتنی بر ماشین مجازی اتریوم_
+- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _اجرای کیف پول و کتابخانه اتریوم_
+- [SewUp](https://github.com/second-state/SewUp) - _کتابخانه ای که به شما کمک می کند قرارداد وب اسمبلی اتریوم خود را با Rust بسازید و درست مانند توسعه در یک بکاند مشترک_
+- [جریانهای فرعی](https://github.com/streamingfast/substreams) - _فناوری نمایهسازی دادههای بلاکچین موازی_
+- [Reth](https://github.com/paradigmxyz/reth) Reth (مخفف راست اتریوم Rust) یک پیادهسازی تمام نود یا گره جدید اتریوم است
+- [اتریوم Rust عالی](https://github.com/Vid201/awesome-ethereum-rust) - _مجموعه سرپرستی شده از پروژهها در اکوسیستم اتریوم است. Rust_
+
+به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/)
+
+## مشارکت کنندگان انجمن Rust {#rust-community-contributors}
+
+- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby)
+- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby)
+- [Parity Gitter](https://gitter.im/paritytech/parity)
+- [Enigma](https://discord.gg/SJK32GY)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
new file mode 100644
index 00000000000..8e12ae8a172
--- /dev/null
+++ "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
@@ -0,0 +1,217 @@
+---
+title: ذخیرهسازی غیرمتمرکز
+description: مروری بر ذخیرهسازی غیرمتمرکز و ابزارهای موجود برای ادغام آن در یک برنامهی غیرمتمرکز.
+lang: fa
+---
+
+برخلاف یک سرور متمرکز که توسط یک شرکت یا سازمان اداره میشود، سیستمهای ذخیرهسازی غیرمتمرکز متشکل از یک شبکه همتا به همتا از اپراتورهای کاربر هستند که بخشی از دادههای کلی را نگه میدارند و یک سیستم اشتراکگذاری ذخیرهسازی فایل انعطافپذیر را ایجاد میکنند. اینها می توانند در یک برنامه مبتنی بر زنجیرهی بلوکی یا هر شبکه مبتنی بر همتا به همتا باشند.
+
+خود اتریوم می تواند به عنوان یک سیستم ذخیرهسازی غیرمتمرکز مورد استفاده قرار گیرد و این برای زمانی است که صحبت از ذخیرهسازی کد در تمام قراردادهای هوشمند می شود. با این حال، وقتی صحبت از حجم زیاد داده می شود، اتریوم برای آن طراحی نشده است. این زنجیره به طور پیوسته در حال رشد است، اما در زمان نگارش مقاله، زنجیره اتریوم حدود 500 گیگابایت - 1 ترابایت است ([بسته به کلاینت](https://etherscan.io/chartsync/chaindefault))، و هر گره در شبکه باید بتواند تمام داده ها را ذخیره کند. اگر زنجیره به حجم زیادی از داده ها (مثلاً 5 ترابایت) گسترش یابد، ادامه کار برای همه گره ها امکانپذیر نخواهد بود. همچنین، هزینه استقرار این مقدار داده در شبکهی اصلی به دلیل هزینههای [گاز](/developers/docs/gas) بسیار گران خواهد بود.
+
+با توجه به این محدودیت ها، ما به یک زنجیره یا روش متفاوت برای ذخیره مقادیر زیادی از داده ها به صورت غیرمتمرکز نیاز داریم.
+
+هنگامی که به گزینه های ذخیرهسازی غیرمتمرکز (dStorage) نگاه می کنید، چند نکته وجود دارد که کاربر باید در نظر داشته باشد.
+
+- مکانیسم پایداری / ساختار انگیزه
+- تقویت حفظ داده ها
+- عدم تمرکز
+- اجماع
+
+## مکانیسم پایداری / ساختار انگیزه {#persistence-mechanism}
+
+### بر پایهی زنجیرهی بلوکی {#blockchain-based}
+
+برای اینکه یک داده برای همیشه باقی بماند، باید از مکانیزم پایداری استفاده کنیم. به عنوان مثال، در اتریوم، مکانیسم پایداری این است که کل زنجیره هنگام اجرای یک گره باید در نظر گرفته شود. قطعات جدید داده در انتهای زنجیره قرار میگیرند و به رشد خود ادامه میدهند - که هر گره باید تمام دادههای تعبیهشده را تکرار کند.
+
+این به عنوان پایداری **بر پایهی زنجیرهی بلوکی** شناخته میشود.
+
+مشکل پایداری مبتنی بر زنجیرهی بلوکی این است که این زنجیره میتواند بسیار بزرگتر از آن باشد که تمام دادهها را به طور عملی نگهداری و ذخیره کند (به عنوان مثال [بسیاری از منابع](https://healthit.com.au/how-big-is-the-internet -and-how-do-we-measure-it/) تخمین می زنند که اینترنت به بیش از 40 زتابایت ظرفیت ذخیره سازی نیاز دارد).
+
+زنجیره بلوکی همچنین باید دارای نوعی ساختار انگیزشی باشد. برای پایداری بر پایهی زنجیرهی بلوکی، یک پرداخت به استخراجگر وجود دارد. هنگامی که داده ها به زنجیره اضافه می شوند، اعتباردهنده ها برای اضافه کردن داده ها به آن پول پرداخت می کنند.
+
+پلتفرمهایی با پایداری مبتنی بر زنجیرهی بلوکی:
+
+- اتریوم
+- [Arweave](https://www.arweave.org/)
+
+### بر پایهی قرارداد {#contract-based}
+
+پایداری **مبتنی بر قرارداد** این شهود را دارد که دادهها را نمیتوان توسط هر گره تکرار کرد و برای همیشه ذخیره کرد، و در عوض باید با توافقات قراردادی نگهداری شوند. اینها توافقاتی هستند که با گره های متعددی که قول داده اند یک قطعه داده را برای مدتی نگهداری کنند، انجام شده است. آنها باید هر زمان که تمام می شوند بازپرداخت یا تمدید شوند تا داده ها باقی بمانند.
+
+در بیشتر موارد، به جای ذخیره همه داده ها در زنجیره، هش محل قرارگیری داده ها در زنجیره ذخیره می شود. به این ترتیب، کل زنجیره برای حفظ تمام داده ها نیازی به مقیاس پذیری ندارد.
+
+پلتفرمهایی با پایداری مبتنی بر قرارداد:
+
+- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/)
+- [Skynet](https://siasky.net/)
+- [Storj](https://storj.io/)
+- [0Chain](https://0chain.net/)
+- [شبکه پوسته](https://crust.network)
+- [Swarm](https://www.ethswarm.org/)
+- [4EVERLAND](https://www.4everland.org/)
+
+### ملاحظات دیگر {#additional-consideration}
+
+IPFS یک سیستم توزیع شده برای ذخیره و دسترسی به فایل ها، وب سایت ها، برنامه ها و داده ها است. این یک طرح تشویقی داخلی ندارد، اما در عوض میتواند با هر یک از راهحلهای تشویقی مبتنی بر قرارداد بالا برای پایداری طولانیمدت استفاده شود. راه دیگر برای ماندگاری داده ها در IPFS کار با یک سرویس پین است که داده های شما را برای شما "پین" می کند. شما حتی می توانید گره IPFS خود را اجرا کنید و به شبکه کمک کنید تا داده های خود و/یا دیگران را به صورت رایگان حفظ کنید!
+
+- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/)
+- [Pinata](https://www.pinata.cloud/) _(سرویس پین کردن IPFS)_
+- [web3.storage](https://web3.storage/) _(سرویس پین کردن IPFS/Filecoin)_
+- [Infura](https://infura.io/product/ipfs) _(سرویس پین کردن IPFS)_
+- [اسکن IPFS](https://ipfs-scan.io) _(کاوشگر پین کردن IPFS)_
+- [4اورلند](https://www.4everland.org/)_(سرویس پینکردن IPFS)
+- [فایل بیس (Filebase)](https://filebase.com) _(سرویس پین کردن IPFS)_
+- [شبکه اسفرن](https://spheron.network/) _(سرویس پین کردن IPFS/فایل کوین)_
+
+سوارم (SWARM) یک فناوری ذخیرهسازی و توزیع داده غیرمتمرکز با سیستم انگیزشی ذخیرهسازی و اوراکل قیمت اجاره ذخیرهسازی است.
+
+## حفظ دادهها {#data-retention}
+
+برای حفظ دادهها، سیستمها باید مکانیزمی برای اطمینان از حفظ دادهها داشته باشند.
+
+### مکانیسم چالش {#challenge-mechanism}
+
+یکی از محبوبترین راهها برای اطمینان از حفظ دادهها، استفاده از نوعی چالش رمزنگاری است که برای گرهها صادر میشود تا مطمئن شوید که هنوز دادهها را دارند. یک مورد ساده به اثبات دسترسی Arweave نگاه می کند. آنها یک چالش برای گره ها صادر می کنند تا ببینند آیا آنها داده ها را در آخرین بلوک و بلوک تصادفی در گذشته دارند یا خیر. اگر گره نتواند به پاسخ برسد، جریمه می شود.
+
+انواع dStorage با مکانیزم چالش:
+
+- 0Chain
+- Skynet
+- Arweave
+- Filecoin
+- شبکه پوسته
+- 4EVERLAND
+
+### عدم تمرکز {#decentrality}
+
+ابزارهای خوبی برای اندازهگیری سطح تمرکززدایی پلتفرمها وجود ندارد، اما به طور کلی، شما میخواهید از ابزارهایی استفاده کنید که نوعی KYC ندارند تا مدرکی ارائه دهید که متمرکز نیستند.
+
+ابزارهای غیرمتمرکز بدون KYC:
+
+- 0Chain (اجرای یک نسخه غیر KYC)
+- Skynet
+- Arweave
+- Filecoin
+- IPFS
+- اتریوم
+- شبکه پوسته
+- 4EVERLAND
+
+### اجماع {#consensus}
+
+اکثر این ابزارها نسخه خود از [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) را دارند اما عموما بر اساس [**اثبات کار (PoW)**](/developers/docs/consensus-mechanisms/pow/) یا [**اثبات سهام (PoS)**](/developers/docs/consensus-mechanisms/pos/) بنا نهاده شده اند.
+
+بر اساس اثبات کار:
+
+- Skynet
+- Arweave
+
+بر اساس اثبات سهام:
+
+- اتریوم
+- Filecoin
+- 0Chain
+- شبکه پوسته
+
+## ابزارهای مرتبط {#related-tools}
+
+**IPFS - _InterPlanetary File System یک ذخیرهسازی غیرمتمرکز و سیستم مرجع فایل برای اتریوم است._**
+
+- [Ipfs.io](https://ipfs.io/)
+- [مستندات](https://docs.ipfs.io/)
+- [گیتهاب](https://github.com/ipfs/ipfs)
+
+**Storj DCS -_ذخیره سازی غیرمتمرکز اشیاء ابری ایمن، خصوصی و سازگار با S3 برای توسعه دهندگان._**
+
+- [Storj.io](https://storj.io/)
+- [اسناد](https://docs.storj.io/)
+- [گیتهاب](https://github.com/storj/storj)
+
+**Skynet -_Skynet یک زنجیرهی اثبات کار غیرمتمرکز است که به اینترنت غیرمتمرکز اختصاص دارد_**
+
+- [Skynet.net](https://siasky.net/)
+- [مستندات](https://siasky.net/docs/)
+- [گیتهاب](https://github.com/SkynetLabs/)
+
+**Filecoin -_Filecoin از همان تیم پشتیبان IPFS ایجاد شد. یک لایه انگیزشی در بالای ایده آل های IPFS است._**
+
+- [Filecoin.io](https://filecoin.io/)
+- [مستندات](https://docs.filecoin.io/)
+- [گیتهاب](https://github.com/filecoin-project/)
+
+**Arweave - _Arweave یک پلتفرم dStorage برای ذخیره داده است._**
+
+- [Arweave.org](https://www.arweave.org/)
+- [مستندات](https://docs.arweave.org/info/)
+- [Arweave](https://github.com/ArweaveTeam/arweave/)
+
+**0chain - _0Chain یک پلتفرم dStorage اثبات سهام با خرده زنجیرهها و حباب است._**
+
+- [0Chain.net](https://0chain.net/)
+- [مستندات](https://docs.0chain.net/0chain/)
+- [گیتهاب](https://github.com/0chain/)
+
+**Crust Network - _Crust یک پلت فرم dStorage در بالای IPFS است._**
+
+- [شبکه پوسته](https://crust.network)
+- [مستندات](https://wiki.crust.network)
+- [گیت هاب](https://github.com/crustio)
+
+**Swarm - _یک پلتفرم ذخیرهسازی توزیع شده و سرویس توزیع محتوا برای پشته اتریوم web3._**
+
+- [EthSwarm.org](https://www.ethswarm.org/)
+- [مستندات](https://docs.ethswarm.org/docs/)
+- [گیتهاب](https://github.com/ethersphere/)
+
+**OrbitDB - _ پایگاه داده همتا به همتا غیرمتمرکز بر روی IPFS._**
+
+- [OrbitDB.org](https://orbitdb.org/)
+- [مستندات](https://github.com/orbitdb/field-manual/)
+- [گیتهاب](https://github.com/orbitdb/orbit-db/)
+
+**Aleph.im - _پروژه ابری غیرمتمرکز (پایگاه داده، ذخیرهسازی فایل، محاسبات و DID). ترکیبی منحصربهفرد از فناوری همتا به همتای روی زنجیرهای و خارج زنجیرهای. IPFS و سازگاری چند زنجیره ای._**
+
+- [Aleph.im](https://aleph.im/)
+- [مستندات](https://aleph.im/#/developers/)
+- [گیتهاب](https://github.com/aleph-im/)
+
+**Ceramic - _ذخیرهسازی پایگاه داده IPFS کنترلشده توسط کاربر برای برنامههای کاربردی غنی از داده و جذاب._**
+
+- [Ceramic.network](https://ceramic.network/)
+- [Documentation](https://developers.ceramic.network/learn/welcome/)
+- [گیتهاب](https://github.com/ceramicnetwork/js-ceramic/)
+
+**فایل بیس- _ ذخیرهسازی غیرمتمرکز سازگار با S3 و سرویس پین کردن IPFS اضافی. همه فایلهایی که از طریق فایل بیس به IPFS آپلود میشوند، بهطور خودکار به زیرساخت فایل بیس با 3 بار تکرار به صورت سراسری پین میشوند._**
+
+- [Filebase.com](https://filebase.com/)
+- [Documentation](https://docs.filebase.com/)
+- [گیتهاب](https://github.com/filebase)
+
+**4EVERLAND- _یک پلتفرم محاسبات ابری Web 3.0 که قابلیتهای هسته ذخیرهسازی، محاسباتی و شبکه را ادغام میکند، با S3 سازگار است و ذخیرهسازی دادههای همزمان را در شبکههای ذخیرهسازی غیرمتمرکز مانند IPFS و Arweave فراهم میکند._**
+
+- [4everland.org](https://www.4everland.org/)
+- [مستندات](https://docs.4everland.org/)
+- [گیتهاب](https://github.com/4everland)
+
+**کالیدو (Kaleido)- _یک پلتفرم بلاک چین به عنوان سرویس با گرههای IPFS دکمه کلیکی_**
+
+- [Kaleido](https://kaleido.io/)
+- [مستندات](https://docs.kaleido.io/kaleido-services/ipfs/)
+- [گیتهاب](https://github.com/kaleido-io)
+
+**Spheron Network - _اسفرن یک پلتفرم بهعنوان سرویس (PaaS) است که برای dAppهایی طراحی شده است که به دنبال راهاندازی برنامههای خود بر روی زیرساخت غیرمتمرکز با بهترین عملکرد هستند. محاسبات، ذخیرهسازی غیرمتمرکز، CDN&. میزبانی وب خارج از بخش اصلی را ارائه میکند._**
+
+- [spheron.network](https://spheron.network/)
+- [اسناد](https://docs.spheron.network/)
+- [گیت هاب](https://github.com/spheronFdn)
+
+## بیشتر بخوانید {#further-reading}
+
+- [ذخیرهسازی غیرمتمرکز چیست؟](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
+- [شکستن پنج افسانه رایج در مورد ذخیرهسازی غیرمتمرکز](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [چارچوبهای توسعه](/developers/docs/frameworks/)
diff --git a/public/content/translations/fa/19) Learn Pages 2/glossary/index.md b/public/content/translations/fa/19) Learn Pages 2/glossary/index.md
new file mode 100644
index 00000000000..530219c0dab
--- /dev/null
+++ b/public/content/translations/fa/19) Learn Pages 2/glossary/index.md
@@ -0,0 +1,499 @@
+---
+title: واژهنامه اتریوم
+description: یک واژه نامه ناکامل از واژگان فنی و غیر فنی مربوط به اتریوم
+lang: fa
+---
+
+# واژه نامه {#ethereum-glossary}
+
+## \# {#section-numbers}
+
+
+
+
+
+## A {#section-a}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## B {#section-b}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## C {#section-c}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## D {#section-d}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## E {#section-e}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## F {#section-f}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## G {#section-g}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## H {#section-h}
+
+
+
+
+
+
+
+
+
+
+
+
+
+## I {#section-i}
+
+
+
+
+
+
+
+
+
+
+
+
+
+## K {#section-k}
+
+
+
+
+
+
+
+
+
+
+
+## L {#section-l}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## M {#section-m}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## N {#section-n}
+
+
+
+
+
+
+
+
+
+
+
+
+
+## O {#section-o}
+
+
+
+
+
+
+
+
+
+
+
+
+
+## P {#section-p}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## R {#section-r}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## S {#section-s}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## T {#section-t}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## V {#section-v}
+
+
+
+
+
+
+
+
+
+
+
+
+
+## W {#section-w}
+
+
+
+
+
+
+
+
+
+## Z {#section-z}
+
+
+
+
+
+
+
+
+
+## منابع {#sources}
+
+_ارائه شده با استفاده از [تسلط بر اتریوم](https://github.com/ethereumbook/ethereumbook) نوشته [ آندراس م.انتوپولوس،گوین وود](https://ethereumbook.info) تحت لایسنس CC-BY-SA_
+
+
+
+## در بهبود این صفحه مشارکت کنید {#contribute-to-this-page}
+
+چیزی را از قلم انداخته ایم؟ چیزی اشتباه است؟ به ما از طریق مشارکت در گیتهاب برای بهبود واژه نامه کمک کنید!
+
+[درباره مشارکت کردن بیشتر بدانید](/contributing/adding-glossary-terms)
diff --git a/public/content/translations/fa/19) Learn Pages 2/history/index.md b/public/content/translations/fa/19) Learn Pages 2/history/index.md
new file mode 100644
index 00000000000..bb4743eed55
--- /dev/null
+++ b/public/content/translations/fa/19) Learn Pages 2/history/index.md
@@ -0,0 +1,738 @@
+---
+title: تاریخچه فورک های اتریوم
+description: تاریخچه بلاک چین اتریوم و نقطه عطف ها، انتشارها و فورک های عمده.
+lang: fa
+sidebarDepth: 1
+---
+
+# تاریخچه اتریوم {#the-history-of-ethereum}
+
+تایم لاین همه اتفاقات، فورک ها و به روزرسانی های بلاک چین اتریوم.
+
+
+
+فورکها زمانی هستند که باید ارتقاء یا تغییرات فنی عمده در شبکه انجام شود - آنها معمولاً از پیشنهادهای بهبود اتریوم (EIP) سرچشمه میگیرند و "قوانین" پروتکل را تغییر میدهند.
+
+زمانی که در نرم افزار قدیمی و با کنترل مرکزی به ارتقاء نیاز است،این شرکت فقط یک نسخه جدید را برای کاربر نهایی منتشر خواهد کرد. بلاک چین ها متفاوت عمل می کنند زیرا مالکیت مرکزی وجود ندارد. کلاینتهای اتریوم باید نرمافزارشان را بهروزرسانی کنند تا قوانین فورک جدید را پیادهسازی کنند. سازندگان بلاک بعلاوه (استخداج کننده ها در دنیای اثبات کار، اعتبار سنجیها در دنیای اثبات سهام) و مشتری نرم افزار روی شبکه باید بلاکها را ایجاد کرده و در برابر قوانین جدید اعتبارسنجی کنند. اطلاعات بیشتر در مورد مکانیسمهای اجماع
+
+این تغییرات قوانین ممکن است یک تقسیم موقت در شبکه ایجاد کند. بلوک های جدید را می توان بر اساس قوانین جدید یا قوانین قدیمی تولید کرد. 0x65B2EeA31601D5477AF8E643EDe26348D83d0dB0. با این حال، در موارد نادر، اختلاف نظر در مورد فورکها میتواند باعث شود که شبکه بهطور دائمی تقسیم شود – مثل اتریوم کلاسیک با دائو فورک.
+
+
+
+
+
+نرمافزاری که زیربنای اتریوم است از دو نیمه تشکیل شده است که به نامهای [لایه اجرا](/واژهنامه/#لایه-اجرا) و [لایه اجماع] (/واژهنامه/#لایه اجماع) شناخته میشوند.
+
+**نامگذاری ارتقاء اجرایی**
+
+از سال 2021، ارتقاء به **لایه اجرا** بر اساس نام شهرهای [مکانهای دوکان (Devcon) قبلی] (https://devcon.org/en/past-events/) به ترتیب زمانی نامگذاری میشوند:
+
+| ارتقا نام | دوکان سال | شماره دوکان| تاریخ ارتقا |
+| ------------ | ----------- | ------------- | ------------ |
+| برلین | 2015 | 0 | Apr 15, 2021 |
+| بندن | 2016 | I | Aug 5, 2021 |
+| شانگهای | 2017 | II | Apr 12, 2023 |
+| **کنکان | 2018 | III | Mar 13, 2024 |
+| پراگ | 2019 | IV | بعدا مشخص می شود
+|
+| اوساکا | 2020 | V | بعدا مشخص می شود
+|
+| بوگوتو | 2022 | VI | بعدا مشخص می شود
+|
+| بنکوک | 2024 | VII | بعدا مشخص می شود
+|
+
+
+
+**نامگذاری ارتقای اجماع**
+
+از زمان راه اندازی [بیکون چین](/واژه نامه/#beacon-chain)، ارتقاها به **لایه اجماع** به نام ستاره های آسمانی نامگذاری شدهاند که با حروف شروع میشوند و به ترتیب حروف الفبا ادامه مییابند:
+| نام ارتقاء | تاریخ ارتقاء |
+| ----------------------------------------------------------- | ------------ |
+| منشا بیکون چین | Dec 1, 2020 |
+| [Altair](https://en.wikipedia.org/wiki/Altair) | Oct 27, 2021 |
+| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix) | Sep 6, 2022 |
+| [Capella](https://en.wikipedia.org/wiki/Capella) | Apr 12, 2023 |
+| [**Deneb**](https://en.wikipedia.org/wiki/Deneb) | Mar 13, 2024 |
+| [_Electra_]() | بعدا مشخص میشود|
+
+**نامگذاری ترکیبی**
+
+بهروزرسانیهای اجرایی و توافقی ابتدا در زمانهای مختلف انجام شد، اما پس از [ارتقاء مرج](/roadmap/merge/) در سال 2022، این موارد به طور همزمان اجرا شدند. به این ترتیب، اصطلاحات محاورهای برای ساده کردن منابع به این ارتقاها با استفاده از یک اصطلاح به هم پیوسته پدید آمدهاند. این کار با ارتقای _Shanghai-Capella_ که معمولاً به عنوان "**Shapella**" نامیده میشود، آغاز شد و با ارتقای _Cancun-Deneb_ که ممکن است به عنوان "**Dencun**" نامیده شود، ادامه یافت
+
+| ارتقاء اجرا | ارتقاء اجماع | نام کوتاه |
+| ----------------- | ----------------- | ---------- |
+| شانگهای | کاپلا | "شاپلا" |
+| کانکان | دنب | "دنکان" |
+
+
+
+مستقیماً به اطلاعات مربوط به برخی از بهروزرسانیهای مهم گذشته بروید: [زنجیرهی Beacon](/roadmap/beacon-chain/)؛ [ادغام یا همان مرج](/roadmap/merge/)؛ و [EIP-1559](#london)
+
+به دنبال ارتقاهای آینده پروتکل هستید؟ [درباره ارتقاهای آینده نقشه راه اتریوم بیاموزید](/roadmap/).
+
+
+
+## 2024 {#2024}
+
+### کانکان-دنب ("دنکان") {#dencun}
+
+
+
+#### خلاصه کنکان {#cancun-summary}
+
+ارتقای کانکان شامل مجموعهای از پیشرفتها در _اجرای اتریوم_ با هدف بهبود مقیاسپذیری، همراه با ارتقاء اجماع دنب است.
+
+به طور قابلتوجهی این مورد شامل EIP-4844، معروف به **Proto-دنک شاردینگ** میشود که هزینه ذخیرهسازی دادهها را برای مجموعههای لایه 2 بهطور قابلتوجهی کاهش میدهد. این امر از طریق معرفی "بلاب (blobs)" داده به دست میآید که به رولآپها امکان میدهد دادهها را برای مدت کوتاهی به شبکه اصلی یا همان مین نت ارسال کنند. این مورد منجر به کاهش بسیاری از کارمزد تراکنش برای کاربران لایه 2 رولآپها میشود.
+
+
+
+
+
+
+
+- [رولآپهای لایه 2](/layer-2/)
+- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding)
+- [دانکشاردینگ](/roadmap/danksharding/)
+- [مشخصات ارتقاء کانکان را بخوانید](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
+
+#### خلاصه دنب {#deneb-summary}
+
+ارتقاء دنب شامل مجموعهای از پیشرفتها برای _اجماع_ اتریوم است که هدف آن بهبود مقیاسپذیری است. این ارتقاء همراه با بهروزرسانیهای اجرای کنکان برای فعال کردن پروتو-دنک شاردینگ (EIP-4844)، همراه با سایر پیشرفتها در بیکون چین ارائه میشود.
+
+«پیامهای خروج داوطلبانه» امضا شده از پیش تولید شده دیگر منقضی نمیشوند، بنابراین کنترل بیشتری به کاربرانی میدهد که وجوه خود را با یک اپراتور گره یا نود شخص ثالث به اشتراک میگذارند. با این پیام خروج امضا شده، استیککنندگان میتوانند عملیات گره را در حالی که توانایی خروج ایمن و برداشت وجوه خود را در هر زمان، بدون نیاز به درخواست اجازه، حفظ و واگذار کنند.
+
+EIP-7514 با محدود کردن نرخ "چرخش (churn)" که اعتبارسنجها میتوانند در شبکه به هشت (8) مورد در هر دوره بپیوندند، صدور اتر را سختتر میکند. از آنجایی که صدور اتر متناسب با کل اترها است، تعداد اعتبارسنجهایی که به _نرخ رشد_ اتریوم جدید صادر شده محدود میشوند، در عین حال الزامات سختافزاری را برای اپراتورهای گره کاهش میدهد و به تمرکززدایی کمک میکند.
+
+
+
+
+
+
+
+- [مشخصات ارتقاء دنب را بخوانید](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
+- [سوالات متداول کنکان-دنب ("دنکان")](/roadmap/dencun/)
+
+
+
+## 2023 {#2023}
+
+### شانگهای-کاپلا ("شاپلا") {#shapella}
+
+
+
+#### خلاصه شانگهای {#shanghai-summary}
+
+ارتقای شانگهای، برداشتهای استیکینگ را به لایه اجرا آورد. همزمان با ارتقاء کاپلا (Capella)، این بلوکها را قادر میسازد تا عملیات برداشت را بپذیرند، که به سهامداران یا همان استیک کنندگان اجازه میدهد اتر خود را از زنجیره بیکون به لایه اجرا خارج کنند.
+
+
+
+
+
+
+
+- [مشخصات ارتقا شانگهای را بخوانید](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
+
+#### خلاصه کاپلا {#capella-summary}
+
+ارتقاء کاپلا سومین ارتقاء عمده به لایه اجماع (Beacon Chain) بود و امکان برداشت استیک را فراهم کرد. کاپلا همزمان با ارتقاء لایه اجرا، شانگهای رخ داد و قابلیت برداشت استیک را فعال کرد.
+
+این ارتقاء لایه توافقی این توانایی را برای سهامدارانی که اعتبار برداشت را با سپرده اولیه خود ارائه نکرده بودند، به ارمغان آورد و در نتیجه امکان برداشت را فراهم کرد.
+
+این ارتقا همچنین قابلیت سوییپ کردن خودکار حساب را ارائه میکند که به طور مداوم حسابهای اعتبارسنجی یا ولیدیتور را برای هرگونه پرداخت پاداش یا برداشت کامل پردازش میکند.
+
+- [اطلاعات بیشتر در مورد برداشتهای استیکینگ](/staking/withdrawals/).
+- [مشخصات ارتقاء کاپلا را بخوانید](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/)
+
+
+
+## ۲۰۲۲ {#2022}
+
+### پاریس (مرج) {#paris}
+
+
+
+#### خلاصه {#paris-summary}
+
+ارتقای پاریس برای هدف خود در بلاکچین اثبات کار[ با سختی کل 58750000000000000000000 ](/glossary/#terminal-total-difficulty) انجام پذیرفت. این اتفاق در بلوک 15537393 در 15 سپتامبر 2022 رخ داد و باعث ارتقای بلوک بعدی پاریس شد. پاریس انتقال [مرج](/roadmap/merge/) بود - ویژگی اصلی آن خاموش کردن [اثبات الگوریتم استخراج](/developers/docs/consensus-mechanisms/pow) و منطق اجماع مرتبط و روشن کردن [اثبات سهام](/developers/docs/consensus-mechanisms/pos) به جای آن بود. پاریس خود ارتقاء یافته به [مشتری های اجرایی](/developers/docs/nodes-and-clients/#execution-clients) (معادل بلاتریکس در لایه توافق) بود که به آنها امکان میداد دستورالعملها را مشتریان توافقی متصل آنها دریافت کنند. از
+
+. این به مجموعه جدیدی از روشهای API داخلی نیاز داشت که در مجموع به عنوان API موتور API فعال شود. مسلماً این مهمترین ارتقا در تاریخ اتریوم از زمان [هوم استد ](#homestead) بوده است!
+
+- [مشخصات ارتقاء پاریس را بخوانید](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md)
+
+
+
+
+
+
+
+---
+
+
+
+### بلاتریکس {#bellatrix}
+
+
+
+
+
+#### خلاصه {#bellatrix-summary}
+
+ارتقاء بلاتریکس دومین ارتقاء برنامه ریزی شده برای [زنجیره بیکون](/roadmap/beacon-chain) بود که زنجیره را برای [مرج](/roadmap/merge/) آماده میکرد. a>. جریمههای اعتبارسنجی را برای عدم فعالیت و جرایم قابل کاهش به ارزش کامل خود میرساند. همچنین بلاتریکس شامل بروزرسانی قوانین انتخاب فورک برای آماده سازی زنجیره برای مرج و انتقال از آخرین بلوک اثبات کار به اولین بلوک اثبات سهام است. این مورد شامل آگاه کردن مشتریان اجماع از [سختی کل پایانی](/glossary/#terminal-total-difficulty) 587500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 میباشد.
+
+- [مشخصات ارتقاء بلاتریکس را بخوانید](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix)
+
+
+
+---
+
+
+
+### گری گلاسیر {#gray-glacier}
+
+
+
+
+
+#### خلاصه {#gray-glacier-summary}
+
+ارتقاء شبکه گری گلاسیر[بمب سختی](/glossary/#difficulty-bomb) را سه ماه عقب انداخت. این تنها تغییری است که در این ارتقاء ایجاد شده است و ماهیت آن شبیه [گلاسیر پیکان](#arrow-glacier) و [ارتقاء گلاسیر مویر](#muir-glacier) است. a>. تغییرات مشابهی در [بیزانس](#byzantium)، [کنستانتینوپل](#constantinople) و ارتقاء شبکه لندن.
+
+- [EF Blog - اطلاعیه ارتقاء گری گلاسیر](https://blog.ethereum.org/2022/06/16/gray-glacier-announcement/)
+
+
+
+
+ - EIP-5133 - بمب سختی را تا سپتامبر 2022 به تعویق میاندازد
+
+
+
+
+
+
+
+
+## 2021 {#2021}
+
+
+
+### ارو گلیسیر {#arrow-glacier}
+
+
+
+
+
+#### خلاصه {#arrow-glacier-summary}
+
+ارتقاء شبکه Arrow Glacier [بمب سختی](/glossary/#difficulty-bomb) را چندین ماه عقب انداخت. این تنها تغییری است که در این ارتقاء ارائه شده است و ماهیت آن مشابه ارتقاء [Muir Glacier](#muir-glacier) است. تغییرات مشابهی در [بیزانس](#byzantium)، [کنستانتینوپل](#constantinople) و ارتقاء شبکه لندن.
+
+- [بلاگ EF - اطلاعیه ارتقاء Arrow Glacier](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/)
+- [Ethereum Cat Herders - ارتقاء Glacier Ethereum Arrow](https://medium.com/ethereum-cat-herders/ethereum-arrow-glacier-upgrade-e8d20fa4c002)
+
+
+
+
+ - EIP-4345 - بمب سختی را تا ژوئن 2022 به تعویق میاندازد
+
+
+
+
+---
+
+
+
+### آلتر {#altair}
+
+
+
+
+
+#### خلاصه {#altair-summary}
+
+ارتقاء آلتر اولین ارتقاء برنامه ریزی شده برای [زنجیره بیکون](/roadmap/beacon-chain) بود. پشتیبانی از «کمیتههای همگامسازی» را اضافه میکند - کلاینتهای سبک را فعال میکند و با پیشرفت توسعه به سمت مرج، عدم فعالیت اعتبارسنجی یا ولیدیتور و کاهش مجازاتها را افزایش میدهد.
+
+- [مشخصات ارتقاء آلتر را بخوانید](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
+
+
+
+#### حقیقت جذاب! {#altair-fun-fact}
+
+آلتر اولین ارتقاء شبکه بزرگی بود که زمان عرضه دقیقی داشت. هر ارتقای قبلی بر اساس یک شماره بلوک اعلام شده در زنجیره اثبات کار بود، جایی که زمان بلوک متفاوت است. زنجیره بیکون برای اثبات کار نیازی به حل ندارد و در عوض بر روی یک سیستم عصر اپوک (epoch) بر زمان متشکل از 32 «اسلات» دوازده ثانیهای کار میکند که اعتبارسنجیها میتوانند بلوکهایی را پیشنهاد کنند. به همین دلیل است که ما دقیقا میدانستیم چه زمانی میتوانیم به اپوک 74240 برسیم و آلتر اجرا شد!
+
+- [زمان بلوک](/developers/docs/blocks/#block-time)
+
+
+
+---
+
+
+
+### لندن {#london}
+
+
+
+
+
+#### خلاصه {#london-summary}
+
+ارتقاء لندن [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) را معرفی کرد که بازار کارمزد معاملات را همراه با تغییراتی در نحوه رسیدگی به بازپرداخت گس اصلاح و برنامه [عصر یخبندان](/glossary/#ice-age) را مدیریت کرد.
+
+
+
+#### ارتقاء لندن (London Upgrade) / EIP - 1559 چه بود؟ {#eip-1559}
+
+پیش از ارتقاء لندن، بلوکهای اتریوم اندازه ثابتی داشتند. در زمان تقاضای بالای شبکه، این بلوک ها با ظرفیت کامل کار می کردند. در نتیجه، کاربران عموماً باید صبر میکردند که تقاضای بالا کاهش یابد تا بتوانند در یک بلوک جای بگیرند، و این موضوع باعث میشد تجربه کاربری چندان خوب نباشد. ارتقاء لندن بلوکهای با اندازه متغیر را به اتریوم معرفی کرد.
+
+روشی که کارمزد تراکنش در شبکه اتریوم محاسبه میشد با [ارتقاء لندن](/history/#london) در اوت 2021 تغییر کرد. قبل از ارتقاء لندن، کارمزدها بدون تفکیک کارمزدهای `پایه` و `اولویت` به شرح زیر محاسبه می شد:
+
+فرض کنید آلیس باید 1 اتر به باب میپرداخت. در این تراکنش محدوده گاز برابر 21,000 واحد بود و قیمت گاز برابر 200 gwei.
+
+کارمز کلی معادل `واحد گاز (محدوده) * قیمت گاز به ازای هر واحد` یعنی 21,000 * 200 = 4,200,000 Gwei
یا 0.0042 ETH است
+
+اجرای [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) در ارتقاء لندن باعث شد که مکانیزم پرداخت کارمزد تراکنش پیچیدهتر شود، اما کارمزدهای گاز را قابل پیشبینیتر کرد که منجر به بازار کارمزد تراکنش کارآمدتر شد. کاربران میتوانند تراکنش را با یک `maxFeePerGas` مطابق با مبلغی که مایل هستند برای اجرای تراکنششان بپردازند ارسال کنند؛ با علم به این که نیازی نیست چیزی بیشتر از قیمت بازار برای گاز (`baseFeePerGas`) بپردازند، و اضافهپرداخت بیشتر از انعامشان را بازپس بگیرند.
+
+این ویدیو EIP-1559 و مزایای آن را توضیح میدهد: [EIP-1559 توضیح داده شده](https://www.youtube.com/watch?v=MGemhK9t44Q)
+
+- [آیا شما یک توسعه دهنده برنامه غیرمتمرکز (dapp) هستید؟ حتما کتابخانه ها و ابزار خود را ارتقا دهید.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md)
+- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/)
+- [توضیح دهنده اتریوم کت هدر را بخوانید](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41)
+
+
+
+
+ - EIP-1559 - بازار کارمزد تراکنش را بهبود میبخشد
+ - EIP-3198 -
BASEFEE
را از یک بلوک برمیگرداند
+ - EIP-3529 - بازپرداخت گس را برای عملیات ماشین مجازی اتریوم (EVM) کاهش میدهد
+ - EIP-3541 - از استقرار قراردادهایی که با
0xEF
شروع میشوند، جلوگیری میکند
+ - EIP-3554 - عصر یخبندان را تا دسامبر 2021 به تعویق میاندازد
+
+
+
+
+---
+
+
+
+### برلین {#berlin}
+
+
+
+
+
+#### خلاصه {#berlin-summary}
+
+ارتقاء برلین هزینه گس را برای برخی اقدامات ماشین مجازی اتریوم بهینه کرد و پشتیبانی از انواع مختلف تراکنش را افزایش داد.
+
+- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/)
+- [توضیح دهنده اتریوم کت هدر را بخوانید](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80)
+
+
+
+
+
+
+
+
+
+
+
+## 2020 {#2020}
+
+
+
+### ویژگی های زنجیره بیکن {#beacon-chain-genesis}
+
+
+
+
+
+#### خلاصه {#beacon-chain-genesis-summary}
+
+[بیکون زنجیره](/roadmap/beacon-chain/) برای ارسال ایمن به 16384 سپرده به 32 اتر استیک شده نیاز داشت. این اتفاق در 27 نوامبر رخ داد، به این معنی که زنجیره بیکون در 1 دسامبر 2020 شروع به تولید بلوک کرد. این اولین قدم مهم در دستیابی به [چشم انداز اتریوم](/roadmap/vision/) است.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21/)
+
+
+ زنجیره بیکن
+
+
+---
+
+
+
+### قرارداد واریز یا سپرده گذاری استیک دپلوی شد {#staking-deposit-contract}
+
+
+
+
+
+#### خلاصه {#deposit-contract-summary}
+
+قرارداد سپرده گذاری، [استیکینگ](/glossary/#staking) را به اکوسیستم اتریوم معرفی کرد. اگرچه یک قرارداد [شبکه اصلی](/glossary/#mainnet) بود، اما تأثیر مستقیمی بر جدول زمانی راهاندازی [زنجیره بیکون](/roadmap/beacon-chain/) داشت. a>، که یک [ارتقای مهم اتریوم](/roadmap/) است.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/)
+
+
+ سهام گذاری
+
+
+---
+
+
+
+### Muir Glacier {#muir-glacier}
+
+
+
+
+
+#### خلاصه {#muir-glacier-summary}
+
+فورک مویر گلاسیر(Muir Glacier) یک تاخیر برای [بمب سختی](/glossary/#difficulty-bomb) معرفی کرد. افزایش سختی بلوک مکانیزم اجماع [اثبات کار](/developers/docs/consensus-mechanisms/pow/)، با افزایش زمان انتظار برای ارسال تراکنشها و افزایش زمان انتظار برای ارسال تراکنشها و استفاده از dappها، قابلیت استفاده اتریوم را کاهش میدهد.
+
+- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/)
+- [توضیح دهنده اتریوم کت هدر را بخوانید](https://medium.com/ethereum-cat-herders/ethereum-muir-glacier-upgrade-89b8cea5a210)
+
+
+
+
+ - EIP-2384 - بمب سختی را برای 4,000,000 بلوک دیگر یا تقریبا 611 روز به تاخیر میاندازد. >
+
+
+
+
+
+
+
+
+## 2019 {#2019}
+
+
+
+### استانبول {#istanbul}
+
+
+
+
+
+#### خلاصه {#istanbul-summary}
+
+فورک استانبول:
+
+- بهینه سازی هزینه [گس](/glossary/#gas) برخی اقدامات در [ماشین مجازی اتریوم](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
+- بهبود انعطاف پذیری حملات انکار سرویس (denial-of-service).
+- راهحلهای [مقیاسگذاری لایه 2](/developers/docs/scaling/#layer-2-scaling) را بر اساس SNARK و STARK کارآمدتر کرد.
+- اتریوم و Zcash را فعال کرد تا با هم همکاری کنند.
+- به قراردادهای برای معرفی عملکردهای خلاقانه تر اجازه میدهد.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/)
+
+
+
+
+ - EIP-152 - به اتریوم اجازه میدهد با ارزهای حفظ حریم خصوصی مانند Zcash کار کند.
+ - EIP-1108 - رمزنگاری ارزانتر برای بهبود گس هزینه ها.
+ - EIP-1344 - با افزودن
CHAINID
از اتریوم در برابر حملات تکراری محافظت میکند. href="/developers/docs/ethereum-stack/#ethereum-virtual-machine">opcode.
+ - EIP-1884 - قیمتهای گس آپکد بر اساس مصرف بهینهسازی میکند.
+ - EIP-2028 - هزینه CallData را کاهش میدهد تا دادههای بیشتری را در بلوکها - برای مقیاسگذاری لایه 2 فراهم کند.
+ - EIP-2200 - سایر تغییرات قیمت گس کد opcode.
+
+
+
+
+---
+
+
+
+### قسطنطنیه {#constantinople}
+
+
+
+
+
+#### خلاصه {#constantinople-summary}
+
+فورک قسطنطنیه (Constantinople):
+
+- پاداشهای بلاک [mining](/developers/docs/consensus-mechanisms/pow/mining/) از 3 به 2 اتر کاهش یافت.
+- اطمینان حاصل شد که بلاکچین قبل از [اجرای اثبات سهام](#beacon-chain-genesis) فریز نشده است.
+- بهینه سازی هزینه [گس](/glossary/#gas) برخی اقدامات در [ماشین مجازی اتریوم](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
+- قابلیت تعامل با آدرسهایی که هنوز ایجاد نشدهاند، اضافه شده است.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/)
+
+
+
+
+ - EIP-145 - هزینه برخی اقدامات روی زنجیره را بهینه میکند.
+ - EIP-1014 - به شما امکان تعامل با آدرس هایی که نپزساخته نشده اند میدهد.
+ - EIP-1052 - هزینه برخی اقدامات روی زنجیره را بهینه میکند.
+ - EIP-1234 - اطمینان حاصل میکند که بلاک چین قبل از اثبات سهام ثابت (فریز) نمیشود و پاداش بلوک را از 3 به 2 اتر کاهش میدهد.
+
+
+
+
+
+
+
+
+## 2017 {#2017}
+
+
+
+### بیزانتیوم {#byzantium}
+
+
+
+
+
+#### خلاصه {#byzantium-summary}
+
+فورک بیزانتیوم:
+
+- پاداش[استخراج](/developers/docs/consensus-mechanisms/pow/mining/) بلوک را از ۵ به ۳ اتر کاهش داد.
+- [بمب سختی شبکه](/glossary/#difficulty-bomb)را یک سال به تاخیر انداخت.
+- توانایی ارسال درخواست به دیگر قرارداد ها بدون تغییر در وضعیت قرارداد اضافه کرد.
+- روش ها رمزنگاری معینی به پروتکل اضافه کرد تا مقیاس پذیری از طریق [لایه ۲ ](/developers/docs/scaling/#layer-2-scaling)میسر شوند.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/)
+
+
+
+
+ - EIP-140 - آپکد
REVERT
را اضافه میکند.
+ - EIP-658 - فیلد وضعیت به رسیدهای تراکنش اضافه شد تا موفقیت یا شکست را نشان دهد.
+ - EIP-196 - منحنی بیضی و ضرب اسکالر را برای زد-کی اسنارکز اضافه میکند. ZK-Snarks.
+ - EIP-197 - منحنی بیضی و ضرب اسکالر را برای زد-کی اسنارکز اضافه می کند ZK-Snarks.
+ - EIP-198 - تأیید امضای RSA را فعال میکند.
+ - EIP-211 - پشتیبانی از مقادیر بازگشتی طول متغیر را اضافه میکند.
+ - EIP-214 - آپکد
STATICCALL
را اضافه میکند و امکان تغییر حالت را برای فراخوانی قراردادهای دیگر نمیدهد.
+ - EIP-100 - فرمول تنظیم سختی شبکه را تغییر داد.
+ - EIP-649 -بمب سختی شبکهزا به مدت یک سال به تعویق انداخت و پاداش بلوک ها را از ۵ اتر به ۳ اتر کاهش داد.
+
+
+
+
+
+
+
+
+## 2016 {#2016}
+
+
+
+### Spurious Dragon {#spurious-dragon}
+
+
+
+
+
+#### خلاصه {#spurious-dragon-summary}
+
+فورک اسپوروس دراگون (Spurious Dragon) دومین پاسخ به حملات انکار سرویس (DoS) در شبکه بود (سپتامبر/اکتبر 2016) از جمله:
+
+- برای جلوگیری از حملات آتی به شبکه، پرایسینگ آپکد را تنظیم میکند.
+- فعال کردن "debloat" وضعیت بلاکچین.
+- اضافه کردن محافظت در برابر حمله ارسال مجدد.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/)
+
+
+
+
+ - EIP-155 - از انتشار دوباره یک تراکنش از یک شبکه اتریوم ، در یک شبکه دیگر جلوگیری میکند,به عنوان مثال تراکنشی بر روی شبکه تست نت دوباره بر روی شبکه اصلی اجرا شود.
+ - EIP-160 - پرایسینگ آپکد
EXP
را تنظیم میکند - کار را برای کند کردن شبکه از طریق عملیات قراردادی گرانقیمت دشوارتر میکند.
+ - EIP-161 - امکان حذف حساب های خالی اضافه شده با حمله DOS را فراهم میکند.
+ - EIP-170 - بیشیبنه سایزی که کد های یک قراردادهوشمند روی زنجیره بلوکی میتواند داشته باشد را به 24576بایت تغییر میدهد.
+
+
+
+
+---
+
+
+
+### Tangerine Whistle {#tangerine-whistle}
+
+
+
+
+
+#### خلاصه {#tangerine-whistle-summary}
+
+فورک Tangerine Whistle اولین پاسخ به حمله های داس سپتامبر/اکتبر۲۰۱۶ به شبکه بود که شامل:
+
+- پرداختن به مسائل فوری سلامت شبکه مربوط به کدهای عملیاتی ارزان قیمت.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/)
+
+
+
+
+
+
+
+---
+
+
+
+### فورک DAO {#dao-fork}
+
+
+
+
+
+#### خلاصه {#dao-fork-summary}
+
+فورک DAO در واکنش به [حملهی DAO در سال 2016](https://www.coindesk.com/learn/understanding-the-dao-attack/) رخ داد که در آن در یک هک، یک قرارداد [DAO](/glossary/#dao) ناامن از بیش از 3.6 میلیون اتر تخلیه شد. فورک وجوه از قرارداد معیوب را به [قرارداد جدید](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) با یک عملکرد واحد منتقل کرد: برداشت. هر کسی که سرمایه خود را از دست داده میتواند به ازای هر 100 توکن DAO در کیف پول خود 1 اتر برداشت کند.
+
+این کار توسط جامعهی اتریوم رأیگیری شد. هر دارندهی اتر میتوانست از طریق یک تراکنش در یک [سکوی رأیگیری](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/) رأی بدهد. تصمیم انجام فورک بیشتر از 85% از آرا را به خود اختصاص داد.
+
+بعضی استخراج گران از فورک شبکه امتناع کردند، زیرا حادثه DAOبخاطر ایرادی در پروتکل اتریوم نبود. آنها با هم دیگر [اتریوم کلاسیک](https://ethereumclassic.org/) را ساختند.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/07/20/hard-fork-completed/)
+
+
+
+---
+
+
+
+### میهن {#homestead}
+
+
+
+
+
+#### خلاصه {#homestead-summary}
+
+فورک هوم استد که به آینده مربوط است. این مورد شامل چندین تغییر پروتکل و یک تغییر شبکه بود که به اتریوم امکان ارتقای شبکه بیشتر را داد.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/02/29/homestead-release/)
+
+
+
+
+
+
+
+
+
+
+
+## 2015 {#2015}
+
+
+
+### ثاوینگ فرانتیر {#frontier-thawing}
+
+
+
+
+
+#### خلاصه {#frontier-thawing-summary}
+
+فورک ثاوینگ فرانتیر محدودیت 5000 [گس](/glossary/#gas) در هر [بلاک](/glossary/#block) را برداشت و قیمت پیشفرض گس را بر روی 51 قرار میدهد[gwei](/glossary/#gwei). این مورد امکان را برای تراکنشها فراهم میکند - تراکنشهایی که به 21000 گاز نیاز دارند. [بمب سختی](/glossary/#difficulty-bomb) برای اطمینان از یک هارد فورک آینده برای [اثبات سهام](/glossary/#pos) معرفی شد. .
+
+- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2015/08/04/the-thawing-frontier/)
+- [به روز رسانی ۱ پروتکل اتریوم را مطالعه کنید](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/)
+
+
+
+---
+
+
+
+### مرز (فرانتیر) {#frontier}
+
+
+
+
+
+#### خلاصه {#frontier-summary}
+
+فرانتیر اجرا شده بود، اما پیادهسازی از پروژه اتریوم بود. فاز تست موفقیت آمیز المپیک را به دنبال داشت. این مورد برای کاربران فنی، به ویژه توسعه دهندگان در نظر گرفته شده بود. [بلوکها](/glossary/#block) دارای محدودیت [گس](/glossary/#gas) 5000 بودند. این دوره «ثاوینگ» به استخراجکنندگان این امکان را میدهد تا عملیات خود را آغاز کنند و برای پذیرندگان اولیه مشتریان خود را بدون نیاز به «عجله» نصب کنند.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare/)
+
+
+
+
+
+## 2014 {#2014}
+
+
+
+### فروش اتر {#ether-sale}
+
+
+
+اتر به طور رسمی به مدت ۴۲ روز به فروش رسید. شما میتوانستید با بیتکوین آن را بخرید.
+
+[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2014/07/22/launching-the-ether-sale/)
+
+
+
+---
+
+
+
+### یلو پیپر منتشر شد {#yellowpaper}
+
+
+
+یلو پیپر نوشته دکتر گاوین وود یک تعریف فنی از پروتکل اتریوم است.
+
+[مشاهده یلو پیپر](https://github.com/ethereum/yellowpaper)
+
+
+
+
+
+## 2013 {#2013}
+
+
+
+### وایت پیپر منتشر شد {#whitepaper}
+
+
+
+مقاله مقدماتی که در سال 2013 توسط ویتالیک بوترین، بنیانگذار اتریوم، قبل از راه اندازی پروژه در سال 2015 منتشر شد.
+
+
+ وایت پیپر
+
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
new file mode 100644
index 00000000000..f6ff8aa65f8
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
@@ -0,0 +1,658 @@
+---
+title: آناتومی قراردادهای هوشمند
+description: یک نگاه عمیق به آناتومی قرارداد هوشمند - توابع، دادهها و متغیرها.
+lang: fa
+---
+
+قرارداد هوشمند برنامه ای است که در آدرسی در اتریوم اجرا می شود. آنها از داده ها و توابعی تشکیل شده اند که می توانند هنگام دریافت تراکنش اجرا شوند. در اینجا یک نمای کلی از آنچه که یک قرارداد هوشمند را تشکیل می دهد آورده شده است.
+
+## پیشنیازها {#prerequisites}
+
+مطمئن شوید که ابتدا درباره [قراردادهای هوشمند](/developers/docs/smart-contracts/) بخوانید. این سند فرض می کند که شما قبلاً با زبان های برنامه نویسی مانند جاوا اسکریپت یا پایتون آشنا هستید.
+
+## دادهها {#data}
+
+هر گونه داده قرارداد باید به مکانی اختصاص داده شود: یا به `حافظه` یا `مموری`. تغییر فضای ذخیرهسازی در یک قرارداد هوشمند پرهزینه است، بنابراین باید در نظر بگیرید که داده های شما در کجا قرار دارند.
+
+### ذخیرهسازی {#storage}
+
+داده های پایدار به عنوان ذخیرهسازی نامیده می شوند و با متغیرهای وضعیت نمایش داده می شوند. این مقادیر به طور دائم در زنجیره بلوکی ذخیره می شوند. باید نوع آن را اعلام کنید تا قرارداد بتواند در هنگام کامپایل کردن زنجیره بلوکی میزان فضای ذخیرهسازی مورد نیاز خود را پیگیری کند.
+
+```solidity
+// Solidity example
+contract SimpleStorage {
+ uint storedData; // State variable
+ // ...
+}
+```
+
+```python
+# Vyper example
+storedData: int128
+```
+
+اگر قبلاً زبان های شیگرا را برنامه ریزی کرده اید، احتمالاً با بیشتر انواع آن آشنا خواهید بود. با این حال، اگر در توسعه اتریوم تازهکار هستید، `آدرس` باید برای شما جدید باشد.
+
+یک نوع `آدرس` میتواند یک آدرس اتریوم را که برابر با 20 بایت یا 160 بیت است، در خود جای دهد. در نماد هگزادسیمال (مبنای ۱۶) با 0x در ابتدا برمی گردد.
+
+انواع دیگر شامل موارد زیر است:
+
+- Boolean
+- عدد صحیح
+- اعداد با نقطه ثابت
+- آرایه بایتی با سایز ثابت
+- آرایه بایتی با سایز پویا
+- لیترال صحیح و منطقی
+- لیترالهای رشتهای
+- اعداد هگز
+- اینام ها
+
+برای توضیحات بیشتر نگاهی به اسناد بیاندازید:
+
+- [نوعهای Vyper را ببینید](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types)
+- [نوعهای Solidity را ببینید](https://solidity.readthedocs.io/en/latest/types.html#value-types)
+
+### مموری {#memory}
+
+مقادیری که فقط برای طول عمر اجرای یک تابع قرارداد ذخیره می شوند، متغیرهای مموری نامیده می شوند. از آنجایی که این ها به طور دائم در زنجیره بلوکی ذخیره نمی شوند، استفاده از آنها بسیار ارزانتر است.
+
+در [مستندات Solidity](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack) دربارهی چگونگی نگهداری دادهها (حافظه، مموری و پشته) در ماشین مجازی اتریوم بیاموزید.
+
+### متغیرهای محیطی {#environment-variables}
+
+علاوه بر متغیرهایی که در قرارداد خود تعریف می کنید، چند متغیر جهانی ویژه نیز وجود دارد. آنها در درجه اول برای ارائه اطلاعات در مورد زنجیره بلوکی یا تراکنش فعلی استفاده می شوند.
+
+مثال ها:
+
+| **ابزار** | **متغیر حالت** | **توضیح** |
+| ----------------- | -------------- | ------------------------------ |
+| `block.timestamp` | uint256 | برچسب زمان ایپوک بلوک فعلی |
+| `msg.sender` | آدرس | فرستندهی پیام (فراخوانی فعلی) |
+
+## توابع {#functions}
+
+به سادهترین شکل، توابع میتوانند اطلاعات دریافت کنند یا اطلاعات را در پاسخ به تراکنشهای دریافتی تنظیم کنند.
+
+دو نوع فراخوانی تابع وجود دارد:
+
+- `داخلی` - اینها یک فراخوانی ماشین مجازی اتریوم را نمیسازند
+ - توابع داخلی و متغیرهای حالت فقط به صورت داخلی قابل دسترسی هستند (یعنی از داخل قرارداد فعلی یا قراردادهای ناشی از آن)
+- `خارجی` - اینها یک فراخوان ماشین مجازی اتریوم را میسازند
+ - توابع خارجی بخشی از رابط قرارداد هستند، به این معنی که می توان آنها را از قراردادهای دیگر و از طریق تراکنش ها فراخوانی کرد. یک تابع خارجی `f` نمیتواند به صورت داخلی فراخوانی شود (یعنی `f()` کار نمیکند اما `this.f()` کار میکند.
+
+توابع میتوانند `عمومی` یا `خصوصی` باشند
+
+- توابع `عمومی` میتوانند به صورت داخلی از داخل قرارداد و به صورت خارجی با پیامها فراخوانی شوند
+- توابع `خصوصی` فقط برای خود قرارداد قابل مشاهده هستند و دیگر قراردادها آن را نمیبینند
+
+هم تابع ها و هم متغیرهای حالت را می توان عمومی یا خصوصی کرد
+
+در اینجا یک تابع برای به روز رسانی یک متغیر حالت در یک قرارداد آمده است:
+
+```solidity
+// Solidity example
+function update_name(string value) public {
+ dapp_name = value;
+}
+```
+
+- پارامتر `value` از نوع `رشته` به تابع `update_name` داده میشود
+- به شکل `عمومی` اعلام شده، به این معنی که هر کسی میتواند به آن دسترسی داشته باشد
+- به شکل `view` اعلام نشده، بنابراین می تواند وضعیت قرارداد را تغییر دهد
+
+### توابع View {#view-functions}
+
+این توابع قرار است وضعیت داده های قرارداد را تغییر ندهند. مثالهای رایج توابع «getter» هستند – برای مثال میتوانید از آن برای دریافت موجودی کاربر استفاده کنید.
+
+```solidity
+// Solidity example
+function balanceOf(address _owner) public view returns (uint256 _balance) {
+ return ownerPizzaCount[_owner];
+}
+```
+
+```python
+dappName: public(string)
+
+@view
+@public
+def readName() -> string:
+ return dappName
+```
+
+آنچه حالت اصلاحی در نظر گرفته می شود:
+
+1. نوشتن بر روی متغیرهای حالت.
+2. [بیرون دادن رویدادها](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events).
+3. [ساختن دیگر قراردادها](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts).
+4. استفاده از `selfdestruct`.
+5. فرستادن اتر از طریق فراخوانیها.
+6. فراخوانی هر تابعی که `view` یا `pure` نباشد.
+7. استفاده از فراخوانیهای سطح پایین.
+8. استفاده از اسمبلی به صورت درخط که شامل کدگذاری های خاصی باشد.
+
+### توابع سازنده {#constructor-functions}
+
+توابع `constructor` فقط یک بار زمانی که قرارداد برای اولین بار ساخته میشود اجرا میشوند. مانند `constructor` در بسیاری از زبان های برنامه نویسی مبتنی بر کلاس، این توابع اغلب متغیرهای حالت را به مقادیر مشخص شده خود مقداردهی اولیه می کنند.
+
+```solidity
+// Solidity example
+// Initializes the contract's data, setting the `owner`
+// to the address of the contract creator.
+constructor() public {
+ // All smart contracts rely on external transactions to trigger its functions.
+ // `msg` is a global variable that includes relevant data on the given transaction,
+ // such as the address of the sender and the ETH value included in the transaction.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
+ owner = msg.sender;
+}
+```
+
+```python
+# Vyper example
+
+@external
+def __init__(_beneficiary: address, _bidding_time: uint256):
+ self.beneficiary = _beneficiary
+ self.auctionStart = block.timestamp
+ self.auctionEnd = self.auctionStart + _bidding_time
+```
+
+### توابع Built-in {#built-in-functions}
+
+علاوه بر متغیرها و توابعی که در قرارداد خود تعریف می کنید، چند تابع داخلی ویژه نیز وجود دارد. بدیهیترین مثال این است:
+
+- `address.send()` - Solidity
+- `send(address)` – Vyper
+
+اینها به قراردادها اجازه می دهد اتر را به حساب های دیگر ارسال کنند.
+
+## توابع Writing {#writing-functions}
+
+تابع شما به موارد زیر نیاز دارد:
+
+- متغیر پارامتر و نوع (در صورت پذیرش پارامترها)
+- اعلامیه داخلی/خارجی
+- اعلامیهی خالص/نما/قابل پرداخت
+- نوع بازگشت ها ( اگر که مقداری را برمیگرداند)
+
+```solidity
+pragma solidity >=0.4.0 <=0.6.0;
+
+contract ExampleDapp {
+ string dapp_name; // state variable
+
+ // Called when the contract is deployed and initializes the value
+ constructor() public {
+ dapp_name = "My Example dapp";
+ }
+
+ // Get Function
+ function read_name() public view returns(string) {
+ return dapp_name;
+ }
+
+ // Set Function
+ function update_name(string value) public {
+ dapp_name = value;
+ }
+}
+```
+
+یک قرارداد کامل ممکن است چیزی شبیه به این باشد. در اینجا تابع `constructor` یک مقدار اولیه برای متغیر `dapp_name` ارائه میکند.
+
+## رویدادها و گزارشها {#events-and-logs}
+
+رویدادها، قراردادهای هوشمند شما را قادر به برقراری ارتباط با فرانت اند یا سایر اپلیکیشن هایی که نیاز به کسب اطلاع از وقایع درون قرارداد هوشمند دارند می کنند. هنگامی که یک تراکنش اعتبارسنجی شده و به یک بلاک اضافه می شود، قراردادهای هوشمند می توانند رویدادها را نمایش داده و اصطلاحاً ساتع کنند و لاگ اطلاعات را چاپ کنند، بدین ترتیب فرانت اند می تواند اطلاعاتی که ساتع شده را پردازش کرده و آن را به کار بگیرد.
+
+## نمونه های مشروح {#annotated-examples}
+
+اینها نمونه هایی هستند که در Solidity نوشته شده اند. اگر میخواهید با کد بازی کنید، میتوانید در [Remix](http://remix.ethereum.org) با آنها تعامل داشته باشید.
+
+### سلام دنیا {#hello-world}
+
+```solidity
+// Specifies the version of Solidity, using semantic versioning.
+// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity ^0.5.10;
+
+// Defines a contract named `HelloWorld`.
+// A contract is a collection of functions and data (its state).
+// Once deployed, a contract resides at a specific address on the Ethereum blockchain.
+// Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // Declares a state variable `message` of type `string`.
+ // State variables are variables whose values are permanently stored in contract storage.
+ // The keyword `public` makes variables accessible from outside a contract
+ // and creates a function that other contracts or clients can call to access the value.
+ string public message;
+
+ // Similar to many class-based object-oriented languages, a constructor is
+ // a special function that is only executed upon contract creation.
+ // Constructors are used to initialize the contract's data.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) public {
+ // Accepts a string argument `initMessage` and sets the value
+ // into the contract's `message` storage variable).
+ message = initMessage;
+ }
+
+ // A public function that accepts a string argument
+ // and updates the `message` storage variable.
+ function update(string memory newMessage) public {
+ message = newMessage;
+ }
+}
+```
+
+### توکن {#token}
+
+```solidity
+pragma solidity ^0.5.10;
+
+contract Token {
+ // An `address` is comparable to an email address - it's used to identify an account on Ethereum.
+ // Addresses can represent a smart contract or an external (user) accounts.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address
+ address public owner;
+
+ // A `mapping` is essentially a hash table data structure.
+ // This `mapping` assigns an unsigned integer (the token balance) to an address (the token holder).
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types
+ mapping (address => uint) public balances;
+
+ // Events allow for logging of activity on the blockchain.
+ // Ethereum clients can listen for events in order to react to contract state changes.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events
+ event Transfer(address from, address to, uint amount);
+
+ // Initializes the contract's data, setting the `owner`
+ // to the address of the contract creator.
+ constructor() public {
+ // All smart contracts rely on external transactions to trigger its functions.
+ // `msg` is a global variable that includes relevant data on the given transaction,
+ // such as the address of the sender and the ETH value included in the transaction.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
+ owner = msg.sender;
+ }
+
+ // Creates an amount of new tokens and sends them to an address.
+ function mint(address receiver, uint amount) public {
+ // `require` is a control structure used to enforce certain conditions.
+ // If a `require` statement evaluates to `false`, an exception is triggered,
+ // which reverts all changes made to the state during the current call.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+
+ // Only the contract owner can call this function
+ require(msg.sender == owner, "You are not the owner.");
+
+ // Enforces a maximum amount of tokens
+ require(amount < 1e60, "Maximum issuance exceeded");
+
+ // Increases the balance of `receiver` by `amount`
+ balances[receiver] += amount;
+ }
+
+ // Sends an amount of existing tokens from any caller to an address.
+ function transfer(address receiver, uint amount) public {
+ // The sender must have enough tokens to send
+ require(amount <= balances[msg.sender], "Insufficient balance.");
+
+ // Adjusts token balances of the two addresses
+ balances[msg.sender] -= amount;
+ balances[receiver] += amount;
+
+ // Emits the event defined earlier
+ emit Transfer(msg.sender, receiver, amount);
+ }
+}
+```
+
+### دارایی دیجیتال منحصربفرد {#unique-digital-asset}
+
+```solidity
+pragma solidity ^0.5.10;
+
+// Imports symbols from other files into the current contract.
+// In this case, a series of helper contracts from OpenZeppelin.
+// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files
+
+import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol";
+import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol";
+import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol";
+import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol";
+
+// The `is` keyword is used to inherit functions and keywords from external contracts.
+// In this case, `CryptoPizza` inherits from the `IERC721` and `ERC165` contracts.
+// Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance
+contract CryptoPizza is IERC721, ERC165 {
+ // Uses OpenZeppelin's SafeMath library to perform arithmetic operations safely.
+ // Learn more: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath
+ using SafeMath for uint256;
+
+ // Constant state variables in Solidity are similar to other languages
+ // but you must assign from an expression which is constant at compile time.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables
+ uint256 constant dnaDigits = 10;
+ uint256 constant dnaModulus = 10 ** dnaDigits;
+ bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;
+
+ // Struct types let you define your own type
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs
+ struct Pizza {
+ string name;
+ uint256 dna;
+ }
+
+ // Creates an empty array of Pizza structs
+ Pizza[] public pizzas;
+
+ // Mapping from pizza ID to its owner's address
+ mapping(uint256 => address) public pizzaToOwner;
+
+ // Mapping from owner's address to number of owned token
+ mapping(address => uint256) public ownerPizzaCount;
+
+ // Mapping from token ID to approved address
+ mapping(uint256 => address) pizzaApprovals;
+
+ // You can nest mappings, this example maps owner to operator approvals
+ mapping(address => mapping(address => bool)) private operatorApprovals;
+
+ // Internal function to create a random Pizza from string (name) and DNA
+ function _createPizza(string memory _name, uint256 _dna)
+ // The `internal` keyword means this function is only visible
+ // within this contract and contracts that derive this contract
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters
+ internal
+ // `isUnique` is a function modifier that checks if the pizza already exists
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers
+ isUnique(_name, _dna)
+ {
+ // Adds Pizza to array of Pizzas and get id
+ uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1);
+
+ // Checks that Pizza owner is the same as current user
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+
+ // note that address(0) is the zero address,
+ // indicating that pizza[id] is not yet allocated to a particular user.
+
+ assert(pizzaToOwner[id] == address(0));
+
+ // Maps the Pizza to the owner
+ pizzaToOwner[id] = msg.sender;
+ ownerPizzaCount[msg.sender] = SafeMath.add(
+ ownerPizzaCount[msg.sender],
+ 1
+ );
+ }
+
+ // Creates a random Pizza from string (name)
+ function createRandomPizza(string memory _name) public {
+ uint256 randDna = generateRandomDna(_name, msg.sender);
+ _createPizza(_name, randDna);
+ }
+
+ // Generates random DNA from string (name) and address of the owner (creator)
+ function generateRandomDna(string memory _str, address _owner)
+ public
+ // Functions marked as `pure` promise not to read from or modify the state
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions
+ pure
+ returns (uint256)
+ {
+ // Generates random uint from string (name) + address (owner)
+ uint256 rand = uint256(keccak256(abi.encodePacked(_str))) +
+ uint256(_owner);
+ rand = rand % dnaModulus;
+ return rand;
+ }
+
+ // Returns array of Pizzas found by owner
+ function getPizzasByOwner(address _owner)
+ public
+ // Functions marked as `view` promise not to modify state
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions
+ view
+ returns (uint256[] memory)
+ {
+ // Uses the `memory` storage location to store values only for the
+ // lifecycle of this function call.
+ // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack
+ uint256[] memory result = new uint256[](ownerPizzaCount[_owner]);
+ uint256 counter = 0;
+ for (uint256 i = 0; i < pizzas.length; i++) {
+ if (pizzaToOwner[i] == _owner) {
+ result[counter] = i;
+ counter++;
+ }
+ }
+ return result;
+ }
+
+ // Transfers Pizza and ownership to other address
+ function transferFrom(address _from, address _to, uint256 _pizzaId) public {
+ require(_from != address(0) && _to != address(0), "Invalid address.");
+ require(_exists(_pizzaId), "Pizza does not exist.");
+ require(_from != _to, "Cannot transfer to the same address.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
+
+ ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1);
+ ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1);
+ pizzaToOwner[_pizzaId] = _to;
+
+ // Emits event defined in the imported IERC721 contract
+ emit Transfer(_from, _to, _pizzaId);
+ _clearApproval(_to, _pizzaId);
+ }
+
+ /**
+ * Safely transfers the ownership of a given token ID to another address
+ * If the target address is a contract, it must implement `onERC721Received`,
+ * which is called upon a safe transfer, and return the magic value
+ * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
+ * otherwise, the transfer is reverted.
+ */
+ function safeTransferFrom(address from, address to, uint256 pizzaId)
+ public
+ {
+ // solium-disable-next-line arg-overflow
+ this.safeTransferFrom(from, to, pizzaId, "");
+ }
+
+ /**
+ * Safely transfers the ownership of a given token ID to another address
+ * If the target address is a contract, it must implement `onERC721Received`,
+ * which is called upon a safe transfer, and return the magic value
+ * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
+ * otherwise, the transfer is reverted.
+ */
+ function safeTransferFrom(
+ address from,
+ address to,
+ uint256 pizzaId,
+ bytes memory _data
+ ) public {
+ this.transferFrom(from, to, pizzaId);
+ require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received.");
+ }
+
+ /**
+ * Internal function to invoke `onERC721Received` on a target address
+ * The call is not executed if the target address is not a contract
+ */
+ function _checkOnERC721Received(
+ address from,
+ address to,
+ uint256 pizzaId,
+ bytes memory _data
+ ) internal returns (bool) {
+ if (!isContract(to)) {
+ return true;
+ }
+
+ bytes4 retval = IERC721Receiver(to).onERC721Received(
+ msg.sender,
+ from,
+ pizzaId,
+ _data
+ );
+ return (retval == _ERC721_RECEIVED);
+ }
+
+ // Burns a Pizza - destroys Token completely
+ // The `external` function modifier means this function is
+ // part of the contract interface and other contracts can call it
+ function burn(uint256 _pizzaId) external {
+ require(msg.sender != address(0), "Invalid address.");
+ require(_exists(_pizzaId), "Pizza does not exist.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
+
+ ownerPizzaCount[msg.sender] = SafeMath.sub(
+ ownerPizzaCount[msg.sender],
+ 1
+ );
+ pizzaToOwner[_pizzaId] = address(0);
+ }
+
+ // Returns count of Pizzas by address
+ function balanceOf(address _owner) public view returns (uint256 _balance) {
+ return ownerPizzaCount[_owner];
+ }
+
+ // Returns owner of the Pizza found by id
+ function ownerOf(uint256 _pizzaId) public view returns (address _owner) {
+ address owner = pizzaToOwner[_pizzaId];
+ require(owner != address(0), "Invalid Pizza ID.");
+ return owner;
+ }
+
+ // Approves other address to transfer ownership of Pizza
+ function approve(address _to, uint256 _pizzaId) public {
+ require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner.");
+ pizzaApprovals[_pizzaId] = _to;
+ emit Approval(msg.sender, _to, _pizzaId);
+ }
+
+ // Returns approved address for specific Pizza
+ function getApproved(uint256 _pizzaId)
+ public
+ view
+ returns (address operator)
+ {
+ require(_exists(_pizzaId), "Pizza does not exist.");
+ return pizzaApprovals[_pizzaId];
+ }
+
+ /**
+ * Private function to clear current approval of a given token ID
+ * Reverts if the given address is not indeed the owner of the token
+ */
+ function _clearApproval(address owner, uint256 _pizzaId) private {
+ require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner.");
+ require(_exists(_pizzaId), "Pizza does not exist.");
+ if (pizzaApprovals[_pizzaId] != address(0)) {
+ pizzaApprovals[_pizzaId] = address(0);
+ }
+ }
+
+ /*
+ * Sets or unsets the approval of a given operator
+ * An operator is allowed to transfer all tokens of the sender on their behalf
+ */
+ function setApprovalForAll(address to, bool approved) public {
+ require(to != msg.sender, "Cannot approve own address");
+ operatorApprovals[msg.sender][to] = approved;
+ emit ApprovalForAll(msg.sender, to, approved);
+ }
+
+ // Tells whether an operator is approved by a given owner
+ function isApprovedForAll(address owner, address operator)
+ public
+ view
+ returns (bool)
+ {
+ return operatorApprovals[owner][operator];
+ }
+
+ // Takes ownership of Pizza - only for approved users
+ function takeOwnership(uint256 _pizzaId) public {
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
+ address owner = this.ownerOf(_pizzaId);
+ this.transferFrom(owner, msg.sender, _pizzaId);
+ }
+
+ // Checks if Pizza exists
+ function _exists(uint256 pizzaId) internal view returns (bool) {
+ address owner = pizzaToOwner[pizzaId];
+ return owner != address(0);
+ }
+
+ // Checks if address is owner or is approved to transfer Pizza
+ function _isApprovedOrOwner(address spender, uint256 pizzaId)
+ internal
+ view
+ returns (bool)
+ {
+ address owner = pizzaToOwner[pizzaId];
+ // Disable solium check because of
+ // https://github.com/duaraghav8/Solium/issues/175
+ // solium-disable-next-line operator-whitespace
+ return (spender == owner ||
+ this.getApproved(pizzaId) == spender ||
+ this.isApprovedForAll(owner, spender));
+ }
+
+ // Check if Pizza is unique and doesn't exist yet
+ modifier isUnique(string memory _name, uint256 _dna) {
+ bool result = true;
+ for (uint256 i = 0; i < pizzas.length; i++) {
+ if (
+ keccak256(abi.encodePacked(pizzas[i].name)) ==
+ keccak256(abi.encodePacked(_name)) &&
+ pizzas[i].dna == _dna
+ ) {
+ result = false;
+ }
+ }
+ require(result, "Pizza with such name already exists.");
+ _;
+ }
+
+ // Returns whether the target address is a contract
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ // Currently there is no better way to check if there is a contract in an address
+ // than to check the size of the code at that address.
+ // به https://ethereum.stackexchange.com/a/14016/36603 مراجعه کنید
+ // برای جزئیات بیشتر در مورد نحوه کار این.
+ // TODO قبل از انتشار Serenity دوباره این مورد را بررسی کنید، زیرا همه آدرس ها خواهند بود
+ // سپس قرارداد می بندد.
+ // solium-disable-next-line security/no-inline-assembly
+ assembly {
+ size := extcodesize(account)
+ }
+ return size > 0;
+ }
+}
+```
+
+## بیشتر بخوانید {#further-reading}
+
+برای بررسی کاملتر قراردادهای هوشمند، مستندات Solidity و Vyper را بررسی کنید:
+
+- [Solidity](https://solidity.readthedocs.io/)
+- [Vyper](https://vyper.readthedocs.io/)
+
+## موضوعات مرتبط {#related-topics}
+
+- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
+- [ماشین مجازی اتریوم](/developers/docs/evm/)
+
+## آموزشهای مرتبط {#related-tutorials}
+
+- [کوچک کردن قراردادها برای مبارزه با محدودیت اندازه قرارداد](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _ – چند نکته کاربردی برای کاهش اندازه قرارداد هوشمند شما._
+- [گزارش دادههای قراردادهای هوشمند با رویدادها](/developers/tutorials/logging-events-smart-contracts/) _– مقدمهای بر رویدادهای قرارداد هوشمند و چگونگی استفاده از آنها برای ثبت داده ها_
+- [تعامل با سایر قراردادهای Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– نحوه استقرار هوشمند قرارداد از یک قرارداد موجود و تعامل با آن._
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
new file mode 100644
index 00000000000..2cb3fbe499a
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
@@ -0,0 +1,282 @@
+---
+title: تدوین قرارداد هوشمند
+description: توضیحی در مورد اینکه چرا باید هوش پیمان را کامپایل کنید و کامپایل در واقع چه کاری انجام می دهد.
+lang: fa
+incomplete: true
+---
+
+شما باید قرارداد خود را کامپایل کنید تا برنامه وب و ماشین مجازی اتریوم (EVM) بتوانند آن را درک کنند.
+
+## پیشنیازها {#prerequisites}
+
+شاید برای شما مفید باشد که قبل از مطالعه در مورد کامپایل، مقدمه [قراردادهای هوشمند](/developers/docs/smart-contracts/) و [ماشین مجازی اتریوم](/developers/docs/evm/) را بخوانید.
+
+## EVM {#the-evm}
+
+برای اینکه [EVM](/developers/docs/evm/) بتواند قرارداد شما را اجرا کند، باید به صورت **بایت کد** باشد. فرآیند کامپایل کردن این را:
+
+```solidity
+pragma solidity 0.4.24;
+
+contract Greeter {
+
+ function greet() public constant returns (string) {
+ return "Hello";
+ }
+
+}
+```
+
+**به این تغییر می دهد**
+
+```
+PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900
+```
+
+اینها **آپکدها** نامیده میشوند. آپکدهای ماشین مجازی اتریوم دستورالعملهای سطح پایینی هستند که ماشین مجازی اتریوم (EVM) میتواند اجرا کند. هر کد عملیاتی یک عملیات خاص مانند عملیات حسابی، عملیات منطقی، دستکاری دادهها، جریان کنترل و غیره را نشان میدهد.
+
+[اطلاعات بیشتر در مورد کدهای عملیاتی](/developers/docs/evm/opcodes/)
+
+## برنامه های کاربردی وب {#web-applications}
+
+کامپایلر همچنین **Application Binary Interface (ABI)** را تولید می کند که برای اینکه برنامه شما بتواند یک قرارداد را درک کند و توابع قرارداد را فراخوانی کند به آن نیاز دارید.
+
+ABI یک فایل JSON است که قرارداد مستقر شده و توابع آن قرارداد هوشمند را توصیف می کند. این مورد به پر کردن شکاف بین web2 و web3 کمک می کند
+
+یک [کتابخانه کلاینتی Javascript](/developers/docs/apis/javascript/) که **ABI** را می خواند تا بتوانید قرارداد هوشمند را در رابط برنامه وب خود فراخوانی کنید.
+
+در زیر ABI برای قرارداد توکن ERC-20 آورده شده است. ERC-20 توکنی است که می توانید با آن در اتریوم معامله کنید.
+
+```json
+[
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "name",
+ "outputs": [
+ {
+ "name": "",
+ "type": "string"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": false,
+ "inputs": [
+ {
+ "name": "_spender",
+ "type": "address"
+ },
+ {
+ "name": "_value",
+ "type": "uint256"
+ }
+ ],
+ "name": "approve",
+ "outputs": [
+ {
+ "name": "",
+ "type": "bool"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "nonpayable",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "totalSupply",
+ "outputs": [
+ {
+ "name": "",
+ "type": "uint256"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": false,
+ "inputs": [
+ {
+ "name": "_from",
+ "type": "address"
+ },
+ {
+ "name": "_to",
+ "type": "address"
+ },
+ {
+ "name": "_value",
+ "type": "uint256"
+ }
+ ],
+ "name": "transferFrom",
+ "outputs": [
+ {
+ "name": "",
+ "type": "bool"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "nonpayable",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "decimals",
+ "outputs": [
+ {
+ "name": "",
+ "type": "uint8"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [
+ {
+ "name": "_owner",
+ "type": "address"
+ }
+ ],
+ "name": "balanceOf",
+ "outputs": [
+ {
+ "name": "balance",
+ "type": "uint256"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [],
+ "name": "symbol",
+ "outputs": [
+ {
+ "name": "",
+ "type": "string"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "constant": false,
+ "inputs": [
+ {
+ "name": "_to",
+ "type": "address"
+ },
+ {
+ "name": "_value",
+ "type": "uint256"
+ }
+ ],
+ "name": "transfer",
+ "outputs": [
+ {
+ "name": "",
+ "type": "bool"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "nonpayable",
+ "type": "function"
+ },
+ {
+ "constant": true,
+ "inputs": [
+ {
+ "name": "_owner",
+ "type": "address"
+ },
+ {
+ "name": "_spender",
+ "type": "address"
+ }
+ ],
+ "name": "allowance",
+ "outputs": [
+ {
+ "name": "",
+ "type": "uint256"
+ }
+ ],
+ "payable": false,
+ "stateMutability": "view",
+ "type": "function"
+ },
+ {
+ "payable": true,
+ "stateMutability": "payable",
+ "type": "fallback"
+ },
+ {
+ "anonymous": false,
+ "inputs": [
+ {
+ "indexed": true,
+ "name": "owner",
+ "type": "address"
+ },
+ {
+ "indexed": true,
+ "name": "spender",
+ "type": "address"
+ },
+ {
+ "indexed": false,
+ "name": "value",
+ "type": "uint256"
+ }
+ ],
+ "name": "Approval",
+ "type": "event"
+ },
+ {
+ "anonymous": false,
+ "inputs": [
+ {
+ "indexed": true,
+ "name": "from",
+ "type": "address"
+ },
+ {
+ "indexed": true,
+ "name": "to",
+ "type": "address"
+ },
+ {
+ "indexed": false,
+ "name": "value",
+ "type": "uint256"
+ }
+ ],
+ "name": "Transfer",
+ "type": "event"
+ }
+]
+```
+
+## بیشتر بخوانید {#further-reading}
+
+- [ABI spec](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _ – Solidity_
+
+## موضوعات مرتبط {#related-topics}
+
+- [کتابخانههای کلاینتی Javascript](/developers/docs/apis/javascript/)
+- [ماشین مجازی اتریوم](/developers/docs/evm/)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
new file mode 100644
index 00000000000..17ced1fd775
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
@@ -0,0 +1,81 @@
+---
+title: استقرار قرارداد هوشمند
+description:
+lang: fa
+---
+
+به منظور در دسترس بودن قرارداد هوشمند شما برای کاربران یک شبکه اتریوم، شما باید آن را پیادهسازی کنید.
+
+برای استقرار یک قرارداد هوشمند، شما فقط یک تراکنش اتریوم حاوی کد کامپایل شده قرارداد هوشمند را بدون تعیین هیچ گیرنده ای ارسال می کنید.
+
+## پیشنیازها {#prerequisites}
+
+شما باید [شبکهی اتریوم](/developers/docs/networks/)، [تراکنشها](/developers/docs/transactions/) و [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) را پیش از استقرار قرارداد هوشمند بدانید.
+
+پیادهسازی یک قرارداد نیز همچنین دارای هزینه اتر (ETH) است زیرا آنها بر روی زنجیرهی بلوکی ذخیره شده اند، بنابراین بایستی با مفهوم [هزینه و کارمزد](/developers/docs/gas/) بر روی اتریوم آشنا باشید.
+
+نهایتا نیاز به کامپایل کردن قرارداد خود پیش از استقرار آن دارید، پس مطمئن شوید که دربارهی [کامپایل کردن قرارداد هوشمند](/developers/docs/smart-contracts/compiling/) مطالعه کرده باشید.
+
+## چگونه یک قرارداد هوشمند را مستقر کنیم {#how-to-deploy-a-smart-contract}
+
+### آنچه نیاز خواهید داشت {#what-youll-need}
+
+- بایتکد قراردادتان - این توسط [کامپایل کردن](/developers/docs/smart-contracts/compiling/) ساخته میشود
+- اتر برای گاز - شما حد گاز خود را مانند سایر تراکنشها تعیین میکنید، بنابراین توجه داشته باشید که استقرار قرارداد به گاز بسیار بیشتری نسبت به یک انتقال ساده اتر نیاز دارد
+- یک اسکریپت یا افزونه استقرار
+- دسترسی به یک[گره اتریوم](/developers/docs/nodes-and-clients/)، با اجرای خودتان، یا اتصال به یک گره عمومی، و یا با استفاده از یک[سرویس گره](/developers/docs/nodes-and-clients/nodes-as-a-service/) از طریق یک API
+
+### گامهای استقرار یک قرارداد هوشمند {#steps-to-deploy}
+
+مراحل خاص مربوط به چارچوب توسعه مورد نظر بستگی دارد. برای مثال، میتوانید [ مستندات یا همان اسناد هاردهت در مورد استقرار قراردادهای خود](https://hardhat.org/guides/deploying.html) یا [ مستندات فاندری در مورد استقرار و تأیید قرارداد هوشمند را بررسی کنید](https://book.getfoundry.sh/forge/deploying). پس از استقرار، قرارداد شما مانند سایر [حسابها](/developers/docs/accounts/) دارای یک آدرس اتریوم خواهد بود و میتوان آن را با استفاده از ابزار تأیید کد منبع[](/developers/docs/smart-contracts/ تأیید کرد. verifying/#source-code-verification-tools).
+
+## ابزارهای مرتبط {#related-tools}
+
+**Remix - _Remix IDE امکان توسعه، استقرار و مدیریت قراردادهای هوشمند برای اتریوم مانند بلاک چین را فراهم می کند._**
+
+- [Remix](https://remix.ethereum.org)
+
+**Tenderly - _پلتفرم توسعه دهندگی در Web3 که با ارائه سرویس هایی چون دیباگ، نظارت و زیرساخت های توسعه قرارداد هوشمند توسعه، تست، نظارت، و اجرا قراردادهای هوشمند را میسر میسازد_**
+
+- [tenderly.co](https://tenderly.co/)
+- [Docs](https://docs.tenderly.co/)
+- [گیتهاب](https://github.com/Tenderly)
+- [دیسکورد](https://discord.gg/eCWjuvt)
+
+**Hardhat - _یک محیط توسعه برای کامپایل، استقرار، آزمایش و اشکال زدایی نرمافزار اتریوم شما_**
+
+- [hardhat.org](https://hardhat.org/getting-started/)
+- [مستنداتی بر استقرار قرارداد خودتان](https://hardhat.org/guides/deploying.html)
+- [گیت هاب](https://github.com/nomiclabs/hardhat)
+- [دیسکورد](https://discord.com/invite/TETZs2KK4k)
+
+**thirwenb - _با یک دستور، هر قرارداد هوشمندی را بر هر شبکه سازگار با ماشین مجازی اتریوم (EVM) به راحتی پیاده کنید_**
+
+- [اسناد](https://portal.thirdweb.com/deploy/)
+
+**کراس مینت- _پلتفرم توسعه Web3 درجه سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از API برای ایجاد، توزیع، فروش، ذخیره و ویرایش انافتی است._**
+
+- [crossmint.com](https://www.crossmint.com)
+- [اسناد](https://docs.crossmint.com)
+- [دیسکورد](https://discord.com/invite/crossmint)
+- [بلاگ](https://blog.crossmint.com)
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [استقرار اولین قرارداد هوشمندتان](/developers/tutorials/deploying-your-first-smart-contract/) _- مقدمه ای برای استقرار اولین قرارداد هوشمندتان در یک شبکه آزمایشی اتریوم._
+- [ سلام دنیا! | آموزش قرارداد هوشمند](/developers/tutorials/hello-world-smart-contract/)_–آموزشی ساده برای ساخت و& پیاده کردن یک قرارداد هوشمند ابتدایی روی اتریوم._
+- [تعامل با سایر قراردادهای Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– نحوه استقرار هوشمند قرارداد از یک قرارداد موجود و تعامل با آن._
+- [چگونه اندازه قرارداد خود را کوچک کنیم](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- چگونه اندازه قرارداد خود را کاهش دهید تا آن را زیر حد مجاز نگه دارید و در مصرف گاز صرفه جویی کنید_
+
+## بیشتر بخوانید {#further-reading}
+
+- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_
+- [استقرار قراردادتان با Hardhat](https://hardhat.org/guides/deploying.html) - _Nomic Labs_
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## موضوعات مرتبط {#related-topics}
+
+- [چارچوبهای توسعه](/developers/docs/frameworks/)
+- [اجرای یک گرهی اتریوم](/developers/docs/nodes-and-clients/run-a-node/)
+- [گره-بهعنوان-خدمت](/developers/docs/nodes-and-clients/nodes-as-a-service)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
new file mode 100644
index 00000000000..f0c2ad57684
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
@@ -0,0 +1,112 @@
+---
+title: معرفی قراردادهای هوشمند
+description: مروری بر قراردادهای هوشمند، با تمرکز بر ویژگی ها و محدودیت های منحصر به فرد آنها.
+lang: fa
+---
+
+## قراردادهای هوشمند چه هستند؟ {#what-is-a-smart-contract}
+
+«قرارداد هوشمند» به سادگی برنامه ای است که بر روی زنجیره بلوکی اتریوم اجرا می شود. مجموعه ای از کد (توابع آن) و داده ها (وضعیت آن) است که در یک آدرس خاص در زنجیره بلوکی اتریوم قرار دارد.
+
+قراردادهای هوشمند نوعی [حساب اتریوم](/developers/docs/accounts/) هستند. این بدین معنی است که آن ها میتوانند موجودی(دارایی) داشته باشند و تراکنش به آن ها ارسال شود. با این حال آنها توسط یک کاربر کنترل نمی شوند، در عوض در شبکه مستقر می شوند و طبق برنامه اجرا می شوند. سپس حسابهای کاربر میتوانند با ارسال تراکنشهایی که تابعی تعریف شده در قرارداد هوشمند را اجرا میکند، با یک قرارداد هوشمند تعامل کنند. قراردادهای هوشمند می توانند قوانینی را مانند یک قرارداد معمولی تعریف کنند و به طور خودکار آنها را از طریق کد اجرا کنند. قراردادهای هوشمند را نمی توان به طور پیش فرض حذف کرد و تعامل با آنها غیر قابل برگشت است.
+
+## پیش نیاز ها {#prerequisites}
+
+اگر تازه شروع کرده اید یا به دنبال معرفی کمتر تخصصی هستید، [معرفی قراردادهای هوشمند](/smart-contracts/) را توصیه می کنیم.
+
+مطمئن شوید که بخشهای [حسابها](/developers/docs/accounts/)، [تراکنشها](/developers/docs/transactions/) و [ماشین مجازی اتریوم](/developers/docs/evm/) را پیش از ورود به دنیای قراردادهای هوشمند خوانده باشید.
+
+## یک دستگاه فروش دیجیتال {#a-digital-vending-machine}
+
+همانطور که توسط [Nick Szabo](https://unenumerated.blogspot.com/) توضیح داده شده است، شاید بهترین استعاره برای یک قرارداد هوشمند، یک دستگاه فروش خودکار باشد. با ورودی های مناسب، خروجی مشخصی تضمین می شود.
+
+برای دریافت یک خوراکی از دستگاه فروش خودکار:
+
+```
+money + snack selection = snack dispensed
+```
+
+این منطق در ماشین فروش برنامه ریزی شده است.
+
+یک قرارداد هوشمند، مانند یک دستگاه فروش خودکار، منطق در آن برنامه ریزی شده است. مثالی ساده از یک دستگاه فروش خودکار اگر قرارداد هوشمندی به زبان سالیدیتی بود:
+
+```solidity
+pragma solidity 0.8.7;
+
+contract VendingMachine {
+
+ // Declare state variables of the contract
+ address public owner;
+ mapping (address => uint) public cupcakeBalances;
+
+ // When 'VendingMachine' contract is deployed:
+ // 1. set the deploying address as the owner of the contract
+ // 2. set the deployed smart contract's cupcake balance to 100
+ constructor() {
+ owner = msg.sender;
+ cupcakeBalances[address(this)] = 100;
+ }
+
+ // Allow the owner to increase the smart contract's cupcake balance
+ function refill(uint amount) public {
+ require(msg.sender == owner, "Only the owner can refill.");
+ cupcakeBalances[address(this)] += amount;
+ }
+
+ // Allow anyone to purchase cupcakes
+ function purchase(uint amount) public payable {
+ require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
+ require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase");
+ cupcakeBalances[address(this)] -= amount;
+ cupcakeBalances[msg.sender] += amount;
+ }
+}
+```
+
+قراردادهای هوشمند می توانند جایگزین واسطه ها در بسیاری از صنایع شوند، مانند اینکه چگونه یک دستگاه فروش خودکار نیاز به کارمند فروشنده را برطرف می کند.
+
+## بدون نیاز به مجوز {#permissionless}
+
+هر کسی می تواند یک قرارداد هوشمند بنویسد و آن را در شبکه مستقر کند. فقط باید یاد بگیرید که چگونه در [زبان قرارداد هوشمند](/developers/docs/smart-contracts/languages/) کدنویسی کنید، و اتر کافی برای اجرای قرارداد خود داشته باشید. پیاده سازی یک قرارداد هوشمند از نظر فنی یک تراکنش است، بنابراین باید [کارمزد](/developers/docs/gas/) خود را مانند وقتی که نیاز به پرداخت کارمزد برای انتقال ساده اتر دارید، پرداخت کنید. با این تفاوت که،کارمزد پیادهسازی یک قرارداد هوشمند بسیار بالاتر است.
+
+اتریوم دارای زبانهای مناسب برای توسعهدهندگان برای نوشتن قراردادهای هوشمند است:
+
+- Solidity
+- Vyper
+
+[بیشتر دربارهی زبانها](/developers/docs/smart-contracts/languages/)
+
+با این حال، آنها باید قبل از استقرار آنها کامپایل شوند تا ماشین مجازی اتریوم بتواند قرارداد را تفسیر و ذخیره کند. [اطلاعات بیشتر دربارهی کامپایل کردن](/developers/docs/smart-contracts/compiling/)
+
+## ترکیب پذیری {#composability}
+
+قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. این بدان معناست که می توانید قراردادهای هوشمند دیگری را در قرارداد هوشمند خود فرا بخوانید تا آنچه ممکن است را تا حد زیادی گسترش دهید. قراردادها حتی می توانند قراردادهای دیگری را مستقر کنند.
+
+دربارهی [ترکیب پذیری قرارداد هوشمند](/developers/docs/smart-contracts/composability/) بیشتر یاد بگیرید.
+
+## محدودیتها {#limitations}
+
+قراردادهای هوشمند به تنهایی نمی توانند اطلاعات مربوط به رویدادهای "دنیای واقعی" را دریافت کنند زیرا نمی توانند اطلاعاتی از منابع خارج زنجیره دریافت کنند. این بدین معنیست که نمیتوانند به اتفاقات دنیای واقعی پاسخ دهند. این بر اساس طراحی است. تکیه بر اطلاعات خارجی می تواند اجماع را که برای امنیت و تمرکززدایی مهم است، به خطر بیندازد.
+
+اما، برنامه های روی زنجیره باید بتوانند از اطلاعات خارج زنجیره استفاده کنند. راه حل آن [اوراکل ها](/developers/docs/oracles/) هستند که اطلاعات خارج زنجیره را جمع میکنند و در اختیار قراردادهای هوشمند میگذارند.
+
+یکی دیگر از محدودیت های قراردادهای هوشمند، حداکثر اندازه قرارداد است. یک قرارداد هوشمند می تواند حداکثر 24 کیلوبایت باشد وگرنه گاز آن تمام می شود. با استفاده از [الگوی الماس](https://eips.ethereum.org/EIPS/eip-2535) میتوان این موضوع را دور زد.
+
+## قراردادهای چند امضایی {#multisig}
+
+قراردادهای Multisig (چند امضایی) حسابهای قرارداد هوشمندی هستند که برای اجرای یک تراکنش به چندین امضای معتبر نیاز دارند. این مورد برای اجتناب از نقاط شکست منفرد برای قراردادهایی که مقادیر قابل توجهی اتر یا توکنهای دیگر دارند، بسیار مفید است. همچنین چند امضاییها مسئولیت اجرای قرارداد و مدیریت کلید را بین چندین طرف تقسیم میکند و از گم شدن یک کلید خصوصی که منجر به از دست دادن غیرقابل برگشت سرمایه میشود، جلوگیری میکنند. به این دلایل، قراردادهای چند امضایی را میتوان برای مدیریت ساده DAO استفاده کرد. چند امضاییها برای اجرا به N امضا از M امضای قابل قبول ممکن (که N ≤ M و M > 1) نیاز دارند. معمولاً از `N = 3، M = 5` و `N = 4، M = 7` استفاده میشود. یک چندامضایی 4/7 به چهار امضا از هفت امضای معتبر ممکن نیاز دارد. این بدان معناست که حتی اگر سه امضا از بین برود، وجوه هنوز قابل بازیابی هستند. در این مورد نیز به این معناست که اکثریت دارندگان کلید باید توافق و امضا کنند تا قرارداد اجرا شود.
+
+## منابع قرارداد هوشمند {#smart-contract-resources}
+
+**قراردادهای OpenZeppelin -** **_کتابخانهای برای توسعه قراردادهای هوشمند ایمن._**
+
+- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/)
+- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-contracts)
+- [تالار گفتگو](https://forum.openzeppelin.com/c/general/16)
+
+## بیشتر بخوانید {#further-reading}
+
+- [کوین بیس: قراردادهای هوشمند چه هستند؟](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract)
+- [چین لینک: قراردادهای هوشمند چه هستند؟](https://chain.link/education/smart-contracts)
+- [ویدیو: توضیح ساده قرارداد های هوشمند](https://youtu.be/ZE2HxTmxfrI)
+- [Cyfrin Updraft: بستر یادگیری و ممیزی Web3](https://updraft.cyfrin.io)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
new file mode 100644
index 00000000000..cb5283f2962
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
@@ -0,0 +1,326 @@
+---
+title: زبان های قرارداد هوشمند
+description: بررسی اجمالی و مقایسه دو زبان اصلی قرارداد هوشمند - Solidity و Vyper.
+lang: fa
+---
+
+یکی از جنبههای مهم در مورد اتریوم این است که قراردادهای هوشمند میتوانند با استفاده از زبانهای نسبتاً مناسب برای توسعهدهندگان برنامهنویسی شوند. اگر با پایتون و یا هر [ زبان براکت کرلی](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages) دیگر تجربه دارید، می توانید یک زبان با ترکیب مشابه را پیدا کنید.
+
+دو زبان فعال و نگهداری شده عبارتند از:
+
+- Solidity
+- Vyper
+
+Remix IDE یک محیط توسعه جامع برای ایجاد و تست قراردادها در سالیدیتی و وایپر فراهم میکند. [برای شروع کدنویسی، محیط توسعه Remix IDE](https://remix.ethereum.org) درون مرورگر را امتحان کنید.
+
+توسعهدهندگان با تجربهتر ممکن است بخواهند از Yul یک زبان میانی برای [ماشین مجازی اتریوم](/developers/docs/evm/)، یا Yul+ افزونهای برای Yul استفاده کنند.
+
+اگر کنجکاو هستید و دوست دارید زبانهای جدیدی را آزمایش کنید که هنوز در حال توسعه هستند، میتوانید با Fe، یک زبان قرارداد هوشمند نوظهور که در حال حاضر هنوز در مراحل ابتدایی خود است، آزمایش کنید.
+
+## پیشنیازها {#prerequisites}
+
+دانش قبلی از زبان های برنامه نویسی، به ویژه جاوا اسکریپت یا پایتون، می تواند به شما کمک کند تفاوت زبان های قرارداد هوشمند را درک کنید. ما همچنین توصیه می کنیم قبل از اینکه به مقایسه عمیق زبانها بپردازید، قراردادهای هوشمند را به عنوان یک مفهوم درک کنید. معرفی [قراردادهای هوشمند](/developers/docs/smart-contracts/).
+
+## Solidity {#solidity}
+
+- زبان شیگرا و سطح بالا برای اجرای قراردادهای هوشمند.
+- زبان براکتی کرلی که عمیقترین تأثیر را از C++ گرفته است.
+- استاتیک تایپ (نوع متغیر در زمان کامپایل مشخص است).
+- موارد زیر را پشتیبانی میکند:
+ - ارثبری (شما میتوانید دیگر قراردادها را بسط دهید).
+ - کتابخانه ها (شما می توانید کدهای قابل استفاده مجدد ایجاد کنید که می توانید آنها را از قراردادهای مختلف فراخوانی کنید - مانند توابع استاتیک در یک کلاس ثابت در سایر زبان های برنامه نویسی شی گرا).
+ - انواع پیچیده مشخصشده توسط کاربر.
+
+### پیوند های مهم {#important-links}
+
+- [مستندات](https://docs.soliditylang.org/en/latest/)
+- [پرتال زبان Solidity](https://soliditylang.org/)
+- [Solidity با مثال](https://docs.soliditylang.org/en/latest/solidity-by-example.html)
+- [گیت هاب](https://github.com/ethereum/solidity/)
+- [چت روم گیتر Solidity](https://gitter.im/ethereum/solidity) با پلی به [چت روم ماتریس Solidity](https://matrix.to/#/#ethereum_solidity:gitter.im)
+- [برگه تقلب](https://reference.auditless.com/cheatsheet)
+- [وبلاگ Solidity](https://blog.soliditylang.org/)
+- [توییتر Solidity](https://twitter.com/solidity_lang)
+
+### قرارداد نمونه {#example-contract}
+
+```solidity
+// SPDX-License-Identifier: GPL-3.0
+pragma solidity >= 0.7.0;
+
+contract Coin {
+ // The keyword "public" makes variables
+ // accessible from other contracts
+ address public minter;
+ mapping (address => uint) public balances;
+
+ // Events allow clients to react to specific
+ // contract changes you declare
+ event Sent(address from, address to, uint amount);
+
+ // Constructor code is only run when the contract
+ // is created
+ constructor() {
+ minter = msg.sender;
+ }
+
+ // Sends an amount of newly created coins to an address
+ // Can only be called by the contract creator
+ function mint(address receiver, uint amount) public {
+ require(msg.sender == minter);
+ require(amount < 1e60);
+ balances[receiver] += amount;
+ }
+
+ // Sends an amount of existing coins
+ // from any caller to an address
+ function send(address receiver, uint amount) public {
+ require(amount <= balances[msg.sender], "Insufficient balance.");
+ balances[msg.sender] -= amount;
+ balances[receiver] += amount;
+ emit Sent(msg.sender, receiver, amount);
+ }
+}
+```
+
+این مثال باید به شما این حس را بدهد که سینتکس قرارداد Solidity چگونه است. برای جزئیات بیشتر در مورد توابع و متغیرها [مستندات را مشاهده کنید](https://docs.soliditylang.org/en/latest/contracts.html).
+
+## Vyper {#vyper}
+
+- زبان برنامه نویسی پایتونیک
+- تایپ کردن قوی
+- کد کامپایلر کوچک و قابل فهم
+- تولید بایت کد کارآمد
+- عمدا دارای ویژگی های کمتری نسبت به Solidity با هدف ایمن تر کردن قراردادها و تسهیل حسابرسی است. Vyper موارد زیر را پشتیبانی نمی کند:
+ - اصلاحکنندهها
+ - ارثبری
+ - اسمبلی درخط
+ - اضافه بار تابع
+ - اضافه باز اپراتور
+ - فراخوانی بازگشتی
+ - لوپهای طول بینهایت
+ - نقاط ثابت دوتایی
+
+برای اطلاعات بیشتر [منطق Vyper را مطالعه کنید](https://vyper.readthedocs.io/en/latest/index.html).
+
+### لینک های مهم {#important-links-1}
+
+- [مستندات](https://vyper.readthedocs.io)
+- [Vyper با مثال](https://vyper.readthedocs.io/en/latest/vyper-by-example.html)
+- [Vyper بیشتر با مثال](https://vyper-by-example.org/)
+- [گیتهاب](https://github.com/vyperlang/vyper)
+- [انجمن چت Vyper Discord](https://discord.gg/SdvKC79cJk)
+- [برگه ی تقلب](https://reference.auditless.com/cheatsheet)
+- [چارچوب ها و ابزارهای توسعه قرارداد هوشمند برای Vyper](/developers/docs/programming-languages/python/)
+- [VyperPunk - یاد بگیرید که قراردادهای هوشمند Vyper را ایمن و هک کنید](https://github.com/SupremacyTeam/VyperPunk)
+- [VyperExamples - نمونه های آسیب پذیری Vyper](https://www.vyperexamples.com/reentrancy)
+- [Vyper Hub برای توسعه](https://github.com/zcor/vyper-dev)
+- [نمونههای مهم قرارداد هوشمند Vyper](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts)
+- [منابع عالی Vyper سرپرستی شده](https://github.com/spadebuilders/awesome-vyper)
+
+### مثال {#example}
+
+```python
+# Open Auction
+
+# Auction params
+# Beneficiary receives money from the highest bidder
+beneficiary: public(address)
+auctionStart: public(uint256)
+auctionEnd: public(uint256)
+
+# Current state of auction
+highestBidder: public(address)
+highestBid: public(uint256)
+
+# Set to true at the end, disallows any change
+ended: public(bool)
+
+# Keep track of refunded bids so we can follow the withdraw pattern
+pendingReturns: public(HashMap[address, uint256])
+
+# Create a simple auction with `_bidding_time`
+# seconds bidding time on behalf of the
+# beneficiary address `_beneficiary`.
+@external
+def __init__(_beneficiary: address, _bidding_time: uint256):
+ self.beneficiary = _beneficiary
+ self.auctionStart = block.timestamp
+ self.auctionEnd = self.auctionStart + _bidding_time
+
+# Bid on the auction with the value sent
+# together with this transaction.
+# The value will only be refunded if the
+# auction is not won.
+@external
+@payable
+def bid():
+ # Check if bidding period is over.
+ assert block.timestamp < self.auctionEnd
+ # Check if bid is high enough
+ assert msg.value > self.highestBid
+ # Track the refund for the previous high bidder
+ self.pendingReturns[self.highestBidder] += self.highestBid
+ # Track new high bid
+ self.highestBidder = msg.sender
+ self.highestBid = msg.value
+
+# Withdraw a previously refunded bid. The withdraw pattern is
+# used here to avoid a security issue. If refunds were directly
+# sent as part of bid(), a malicious bidding contract could block
+# those refunds and thus block new higher bids from coming in.
+@external
+def withdraw():
+ pending_amount: uint256 = self.pendingReturns[msg.sender]
+ self.pendingReturns[msg.sender] = 0
+ send(msg.sender, pending_amount)
+
+# End the auction and send the highest bid
+# to the beneficiary.
+@external
+def endAuction():
+ # It is a good guideline to structure functions that interact
+ # with other contracts (i.e. they call functions or send ether)
+ # into three phases:
+ # 1. checking conditions
+ # 2. performing actions (potentially changing conditions)
+ # 3. interacting with other contracts
+ # If these phases are mixed up, the other contract could call
+ # back into the current contract and modify the state or cause
+ # effects (ether payout) to be performed multiple times.
+ # If functions called internally include interaction with external
+ # contracts, they also have to be considered interaction with
+ # external contracts.
+
+ # 1. Conditions
+ # Check if auction endtime has been reached
+ assert block.timestamp >= self.auctionEnd
+ # Check if this function has already been called
+ assert not self.ended
+
+ # 2. Effects
+ self.ended = True
+
+ # 3. Interaction
+ send(self.beneficiary, self.highestBid)
+```
+
+این مثال باید به شما این حس را بدهد که سینتکس قرارداد Vyper چگونه است. برای جزئیات بیشتر در مورد توابع و متغیرها [مستندات را مشاهده کنید](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction).
+
+## Yul و +Yul {#yul}
+
+اگر به تازگی وارد اتریوم شده اید و هنوز هیچ کدنویسی با زبان های قرارداد هوشمند انجام نداده اید، توصیه می کنیم با Solidity یا Vyper شروع کنید. فقط زمانی به Yul یا +Yul نگاه کنید که با بهترین روشهای امنیتی قرارداد هوشمند و ویژگیهای کار با EVM آشنا شدید.
+
+**Yul**
+
+- زبان میانی برای اتریوم.
+- از [ماشین مجازی اتریوم](/developers/docs/evm) و [Ewasm](https://github.com/ewasm)، یک WebAssembly با طعم اتریوم، پشتیبانی می کند و طراحی شده تا مخرج مشترک قابل استفاده هر دو پلتفرم باشد.
+- هدف خوبی برای مراحل بهینهسازی سطح بالا است که میتواند برای هر دو پلتفرم ماشین مجازی اتریوم و Ewasm به طور یکسان مفید باشد.
+
+**+Yul**
+
+- یک برنامه افزودنی سطح پایین و بسیار کارآمد برای Yul.
+- در ابتدا برای یک قرارداد [رول آپ خوش بینانه](/developers/docs/scaling/optimistic-rollups/) طراحی شد.
+- +Yul را میتوان بهعنوان پیشنهاد ارتقای آزمایشی Yul در نظر گرفت و ویژگیهای جدیدی را به آن اضافه کرد.
+
+### پیوند های مهم {#important-links-2}
+
+- [مستندات Yul](https://docs.soliditylang.org/en/latest/yul.html)
+- [مستندات +Yul](https://github.com/fuellabs/yulp)
+- [زمین بازی +Yul](https://yulp.fuel.sh/)
+- [پست معرفی +Yul](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f)
+
+### قرارداد نمونه {#example-contract-2}
+
+مثال ساده زیر یک تابع توان را پیادهسازی می کند. میتواند با استفاده از `solc --strict-assembly --bin input.yul` کامپایل شود. مثال باید در فایل input.yul ذخیره شود.
+
+```
+{
+ function power(base, exponent) -> result
+ {
+ switch exponent
+ case 0 { result := 1 }
+ case 1 { result := base }
+ default
+ {
+ result := power(mul(base, base), div(exponent, 2))
+ if mod(exponent, 2) { result := mul(base, result) }
+ }
+ }
+ let res := power(calldataload(0), calldataload(32))
+ mstore(0, res)
+ return(0, 32)
+}
+```
+
+اگر قبلاً در قراردادهای هوشمند تجربه خوبی دارید، پیادهسازی کامل ERC20 در Yul را میتوانید در [اینجا](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example) پیدا کنید.
+
+## Fe {#fe}
+
+- زبان تایپ ایستا برای ماشین مجازی اتریوم (EVM).
+- با الهام از پایتون و Rust.
+- هدف این است که یادگیری آسان باشد -- حتی برای توسعه دهندگانی که به تازگی وارد اکوسیستم اتریوم شده اند.
+- توسعه Fe هنوز در مراحل اولیه خود است، این زبان در ژانویه 2021 انتشار نسخه آلفای خود را داشت.
+
+### پیوند های مهم {#important-links-3}
+
+- [گیتهاب](https://github.com/ethereum/fe)
+- [اطلاعیه Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/)
+- [نقشهی راه ۲۰۲۱ Fe](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg)
+- [چت دیسکورد Fe](https://discord.com/invite/ywpkAXFjZH)
+- [توییتر Fe](https://twitter.com/official_fe)
+
+### قرارداد نمونه {#example-contract-3}
+
+در زیر یک قرارداد ساده اجرا شده در Fe است.
+
+```
+type BookMsg = bytes[100]
+
+contract GuestBook:
+ pub guest_book: map
+
+ event Signed:
+ book_msg: BookMsg
+
+ pub def sign(book_msg: BookMsg):
+ self.guest_book[msg.sender] = book_msg
+
+ emit Signed(book_msg=book_msg)
+
+ pub def get_msg(addr: address) -> BookMsg:
+ return self.guest_book[addr].to_mem()
+
+```
+
+## چگونه انتخاب کنیم {#how-to-choose}
+
+مانند هر زبان برنامه نویسی دیگری، بیشتر در مورد انتخاب ابزار مناسب برای کار مناسب و همچنین ترجیحات شخصی است.
+
+اگر هنوز هیچ یک از زبان ها را امتحان نکرده اید، چند نکته را در نظر بگیرید:
+
+### چه چیز دربارهی Solidity عالی است؟ {#solidity-advantages}
+
+- اگر مبتدی هستید، آموزش ها و ابزارهای یادگیری زیادی وجود دارد. در بخش [آموزش با برنامهنویسی](/developers/learning-tools/) اطلاعات بیشتری در مورد آن ببینید.
+- ابزار توسعه دهنده خوب در دسترس است.
+- Solidity یک جامعه توسعه دهندگان بزرگ دارد، به این معنی که به احتمال زیاد پاسخ سوالات خود را خیلی سریع پیدا خواهید کرد.
+
+### چه چیز دربارهی Vyper عالی است؟ {#vyper-advatages}
+
+- راه عالی برای شروع برای توسعه دهندگان پایتون که می خواهند قراردادهای هوشمند بنویسند.
+- Vyper تعداد کمتری ویژگی دارد که آن را برای نمونه سازی سریع ایده ها عالی می کند.
+- هدف Vyper این است که برای ممیزی آسان و برای انسان حداکثر خوانا باشد.
+
+### چه چیزی در مورد Yul و +Yul عالی است؟ {#yul-advantages}
+
+- زبان سطح پایین ساده و کاربردی.
+- اجازه می دهد تا به EVM خام نزدیک تر شوید، که می تواند به بهینهسازی مصرف گاز در قراردادهای شما کمک کند.
+
+## مقایسههای زبان {#language-comparisons}
+
+برای مقایسه ترکیب اولیه، چرخه عمر قرارداد، رابط ها، عملگر ها، ساختارهای داده، توابع، جریان کنترل و موارد دیگر، این [برگه تقلب از Auditless](https://reference.auditless.com/cheatsheet/) را بررسی کنید
+
+## اطلاعات بیشتر {#further-reading}
+
+- [کتابخانه قراردادهای Solidity از OpenZeppelin](https://docs.openzeppelin.com/contracts)
+- [Solidity با مثال](https://solidity-by-example.org)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
new file mode 100644
index 00000000000..c8381e55810
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
@@ -0,0 +1,117 @@
+---
+title: کتابخانه های قرارداد هوشمند
+description:
+lang: fa
+---
+
+لازم نیست هر قرارداد هوشمندی را در پروژه خود از ابتدا بنویسید. بسیاری از کتابخانههای قراردادهای هوشمند منبع باز موجود هستند که بلوکهای ساختن قابل استفاده مجدد را برای پروژه شما فراهم میکنند که میتواند شما را از اختراع مجدد چرخ نجات دهد.
+
+## پیشنیازها {#prerequisites}
+
+قبل از ورود به کتابخانه های قرارداد هوشمند، ایده خوبی است که درک خوبی از ساختار قرارداد هوشمند داشته باشید. اگر هنوز این کار را نکردهاید، به [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) بروید.
+
+## در یک کتابخانه چه چیز است؟ {#whats-in-a-library}
+
+معمولاً میتوانید دو نوع بلوک ساختن را در کتابخانههای قراردادهای هوشمند بیابید: رفتارهای قابل استفاده مجدد که میتوانید به قراردادهای خود اضافه کنید، و اجرای استانداردهای مختلف.
+
+### رفتارها {#behaviors}
+
+هنگام نوشتن قراردادهای هوشمند، این احتمال وجود دارد که شما بارها و بارها الگوهای مشابهی را بنویسید، مانند اختصاص یک آدرس _ادمین_ برای انجام عملیات محافظت شده در یک قرارداد، یا افزودن دکمه _مکث_ اضطراری در صورت بروز مشکل غیرمنتظره.
+
+کتابخانههای قراردادهای هوشمند معمولاً پیادهسازیهای قابل استفاده مجدد از این رفتارها را بهعنوان [کتابخانهها](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) یا [ارثبری](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) در Solidity ارائه میکنند.
+
+به عنوان یک مثال، یک نسخهی سادهشده از [قرارداد `قابل تصاحب`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) از [کتابخانهی قراردادهای OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts) را دنبال کنید که یک آدرس را به عنوان مالک قرارداد تعیین می کند و یک اصلاح کننده برای محدود کردن دسترسی به یک روش فقط به آن مالک ارائه می دهد.
+
+```solidity
+contract Ownable {
+ address public owner;
+
+ constructor() internal {
+ owner = msg.sender;
+ }
+
+ modifier onlyOwner() {
+ require(owner == msg.sender, "Ownable: caller is not the owner");
+ _;
+ }
+}
+```
+
+برای استفاده از یک بلوک مانند این در قرارداد خود، باید ابتدا آن را وارد کنید، و سپس آن را در قراردادهای خود بسط دهید. این به شما امکان می دهد از اصلاح کننده ارائه شده توسط قرارداد پایه `Ownable` برای ایمنسازی توابع خود استفاده کنید.
+
+```solidity
+import ".../Ownable.sol"; // Path to the imported library
+
+contract MyContract is Ownable {
+ // The following function can only be called by the owner
+ function secured() onlyOwner public {
+ msg.sender.transfer(1 ether);
+ }
+}
+```
+
+یک مثال محبوب دیگر [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) یا [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html) است. اینها کتابخانههایی هستند (برخلاف قراردادهای پایه) که توابع حسابی را با بررسیهای سرریز ارائه میکنند که توسط زبان ارائه نمیشود. استفاده از هر یک از این کتابخانه ها به جای عملیات محاسباتی بومی برای محافظت از قرارداد شما در برابر سرریزها، که می تواند عواقب فاجعه باری داشته باشد، تمرین خوبی است!
+
+### استانداردها {#standards}
+
+برای تسهیل [ترکیب پذیری و قابلیت همکاری](/developers/docs/smart-contracts/composability/)، جامعهی اتریوم چند استاندارد به شکل **ERCها** طراحی کرده است. شما میتوانید دربارهی آنها در بخش [استانداردها](/developers/docs/standards/) بیشتر بخوانید.
+
+هنگامی که یک ERC را به عنوان بخشی از قراردادهای خود درج می کنید، ایده خوبی است که به جای اجرای پیادهسازی های خود، به دنبال پیادهسازی های استاندارد باشید. بسیاری از کتابخانه های قراردادهای هوشمند شامل پیادهسازی هایی برای محبوب ترین ERC ها هستند. برای مثال [استاندارد توکنهای قابل معاوضه ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) که همهجا وجود دارد میتوانند در [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)، [DappSys](https://github.com/dapphub/ds-token/) و [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) یافت شوند. علاوه بر این، برخی از ERC ها نیز پیادهسازی های متعارف را به عنوان بخشی از خود ERC ارائه می دهند.
+
+شایان ذکر است که برخی از ERC ها مستقل نیستند، بلکه اضافه شده به سایر ERC ها هستند. برای مثال، [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) یک افزونهای به ERC20 برای بهبود استفادهاش اضافه میکند.
+
+## چگونه یک کتابخانه اضافه کنیم {#how-to}
+
+برای دستورالعملهای خاص در مورد نحوه گنجاندن کتابخانه در پروژه، همیشه به مستندات کتابخانهای که اضافه میکنید مراجعه کنید. چندین کتابخانه قرارداد Solidity با استفاده از `npm` بسته بندی شده اند، بنابراین شما می توانید آنها را `npm install` کنید. بیشتر ابزارهای [کامپایل کردن](/developers/docs/smart-contracts/compiling/) قراردادها، به `node_modules` برای کتابخانههای قرارداد هوشمند نگاه میکنند، در نتیجه شما میتوانید به روش زیر عمل کنید:
+
+```solidity
+// This will load the @openzeppelin/contracts library from your node_modules
+import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
+
+contract MyNFT is ERC721 {
+ constructor() ERC721("MyNFT", "MNFT") public { }
+}
+```
+
+صرف نظر از روشی که استفاده میکنید، هنگام گنجاندن کتابخانه، همیشه به نسخه [زبان](/developers/docs/smart-contracts/languages/) توجه داشته باشید. به عنوان مثال، اگر قراردادهای خود را در Solidity 0.5 می نویسید، نمی توانید از کتابخانه برای Solidity 0.6 استفاده کنید.
+
+## چه زمانی استفاده کنیم {#when-to-use}
+
+استفاده از کتابخانه قرارداد هوشمند برای پروژه شما مزایای متعددی دارد. اول از همه، با ارائه بلوکهای ساخت آمادهای که میتوانید در سیستم خود بگنجانید، در وقت شما صرفهجویی میکند، نه اینکه خودتان آنها را کدنویسی کنید.
+
+امنیت نیز یک مزیت اصلی است. کتابخانه های قراردادهای هوشمند منبع باز نیز اغلب به شدت مورد بررسی قرار می گیرند. با توجه به اینکه بسیاری از پروژهها به آنها وابسته هستند، جامعه انگیزه زیادی برای نگه داشتن آنها تحت بررسی دائمی دارد. یافتن خطا در کد برنامه بسیار رایج تر از کتابخانه های قراردادی قابل استفاده مجدد است. برخی از کتابخانهها نیز برای امنیت بیشتر تحت [ممیزیهای خارجی](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) قرار میگیرند.
+
+با این حال، استفاده از کتابخانههای قرارداد هوشمند خطر گنجاندن کدهایی را که با آنها آشنا نیستید در پروژه خود به همراه دارد. وسوسه انگیز است که یک قرارداد را وارد کنید و آن را مستقیماً در پروژه خود شامل کنید، اما بدون درک خوب از آنچه آن قرارداد انجام می دهد، ممکن است به دلیل یک رفتار غیرمنتظره به طور ناخواسته مشکلی را در سیستم خود وارد کنید. همیشه مطمئن شوید که مستندات کدی را که وارد میکنید بخوانید و سپس قبل از اینکه آن را بخشی از پروژه خود کنید، خود کد را بررسی کنید!
+
+در آخر، هنگام تصمیم گیری در مورد گنجاندن کتابخانه، استفاده کلی از آن را در نظر بگیرید. یک مورد که به طور گسترده پذیرفته شده است و دارای مزایای داشتن یک جامعه بزرگتر و افراد بیشتر در آن برای رسیدگی به مسائل است. هنگام ساخت با قراردادهای هوشمند، امنیت باید تمرکز اصلی شما باشد!
+
+## ابزارهای مرتبط {#related-tools}
+
+**قراردادهای OpenZeppelin -** **_محبوب ترین کتابخانه برای توسعه قراردادهای هوشمند ایمن._**
+
+- [مستندات](https://docs.openzeppelin.com/contracts/)
+- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-contracts)
+- [انجمن گفتگو](https://forum.openzeppelin.com/c/general/16)
+
+**DappSys -** **_بلوک های ساخت ایمن، ساده و انعطافپذیر برای قراردادهای هوشمند._**
+
+- [مستندات](https://dappsys.readthedocs.io/)
+- [گیت هاب](https://github.com/dapphub/dappsys)
+
+**HQ20 -** **_یک پروژه Solidity با قراردادها، کتابخانه ها و نمونه هایی که به شما کمک می کند تا برنامه های کاربردی توزیع شده با ویژگی های کامل را برای دنیای واقعی بسازید._**
+
+- [گیت هاب](https://github.com/HQ20/contracts)
+
+**کیت توسعه نرمافزار سالیدیتی Thirdweb-****_ ابزار های لازم برای ساخت قراردادهای هوشمند بهینه و مؤثر را در اختیار توسعه دهندگان میگذارد_**
+
+- [اسناد](https://portal.thirdweb.com/solidity/)
+- [گیت هاب](https://github.com/thirdweb-dev/contracts)
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [ملاحظات امنیتی برای توسعه دهندگان اتریوم](/developers/docs/smart-contracts/security/) _- آموزشی در مورد ملاحظات امنیتی هنگام ساخت قراردادهای هوشمند، از جمله استفاده از کتابخانه._
+- [فهم قرارداد هوشمند توکن ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- آموزشی بر استاندارد ERC20، فراهم شده توسط چندین کتابخانه._
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
new file mode 100644
index 00000000000..9ea1fe4f85d
--- /dev/null
+++ "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
@@ -0,0 +1,580 @@
+---
+title: امنیت قرارداد هوشمند
+description: مروری بر دستورالعملهای ساخت قراردادهای هوشمند ایمن در اتریوم
+lang: fa
+---
+
+قراردادهای هوشمند بسیار انعطافپذیر هستند و می توانند مقادیر زیادی از ارزش و داده را کنترل کنند، در حالی که منطق تغییرناپذیر مبتنی بر کد مستقر در بلاک چین را اجرا می کنند. این یک اکوسیستم پر جنب و جوش از برنامه های کاربردی بی نیاز از اعتماد و غیرمتمرکز ایجاد کرده است که مزایای زیادی را نسبت به سیستم های قدیمی ارائه می دهد. آنها همچنین فرصتهایی را برای مهاجمانی که به دنبال سودجویی از طریق سوءاستفاده از آسیبپذیریها در قراردادهای هوشمند هستند، نشان میدهند.
+
+بلاک چین های عمومی، مانند اتریوم، مسئله ایمنسازی قراردادهای هوشمند را پیچیدهتر و سختتر می کند. _معمولا_ پس از استقرار کد قرارداد در شبکه، نمیتوان آن را به منظور رفع نقص های امنیتی را تغییر داد، در حالی که ردیابی دارایی های دزدیده شده از قراردادهای هوشمند بسیار دشوار است و عمدتاً به دلیل تغییر ناپذیری قابل بازیابی نیستند.
+
+اگرچه اعداد و ارقام متفاوت است، تخمین زده می شود که کل ارزش سرقت شده یا از دست رفته به دلیل نقص امنیتی در قراردادهای هوشمند به راحتی بیش از یک میلیارد دلار است. این شامل حوادث پرمخاطب، مانند [هک DAO](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3.6M اتریوم دزدیده شده، به ارزش بیش از 1 میلیارد دلار در قیمت های امروزی)، [هک کیف پول چند علامتی Parity ](https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach) (30 میلیون دلار از دست هکرها) و [ مشکل کیف پول منجمد شده](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (بیش از 300 میلیون دلار ETH برای همیشه قفل شده است).
+
+مسائل ذکر شده، توسعه دهندگان را مجبور میکند تا تلاش کنند قراردادهای هوشمند ایمن، نبوغ آمیز و منعطف بسازند. امنیت قراردادهای هوشمند یک تجارت جدی است و هر توسعهدهندهای باید آن را یاد بگیرد. این راهنما ملاحظات امنیتی برای توسعه دهندگان اتریوم را پوشش می دهد و منابعی را برای بهبود امنیت قراردادهای هوشمند بررسی می کند.
+
+## پیشنیازها {#prerequisites}
+
+قبل از پرداختن به امنیت، مطمئن شوید که با [مبانی توسعه قرارداد هوشمند](/developers/docs/smart-contracts/) آشنا هستید.
+
+## دستورالعمل هایی برای ساخت قراردادهای هوشمند ایمن در اتریوم {#smart-contract-security-guidelines}
+
+### 1. کنترل های دسترسی طراحی مناسب {#design-proper-access-controls}
+
+در قراردادهای هوشمند، عملکردهایی که `public` یا `external` علامتگذاری شدهاند، میتوانند توسط هر حساب تحت مالکیت خارجی (EOA) یا حساب قراردادی فراخوانی شوند. اگر میخواهید دیگران با قرارداد شما در تعامل باشند، مشخص کردن نمای عمومی برای عملکردها ضروری است. با این حال، عملکردهایی که با `private` علامتگذاری شدهاند، فقط توسط توابع داخل قرارداد هوشمند فراخوانی میشوند و در حسابهای خارجی مورد استفاده قرار نمی گیرند. دادن دسترسی به هر یک از شرکتکنندگان شبکه به توابع قرارداد میتواند باعث ایجاد مشکلاتی شود، بهویژه اگر به این معنی باشد که هر کسی بتواند عملیات حساس را انجام دهد (به عنوان مثال، استخراج توکنهای جدید).
+
+برای جلوگیری از استفاده غیرمجاز از توابع قرارداد هوشمند، لازم است کنترل های دسترسی ایمن را اجرا کنید. مکانیسمهای کنترل دسترسی، توانایی استفاده از عملکردهای خاص در یک قرارداد هوشمند را به نهادهای تایید شده، مانند حسابهای مسئول مدیریت قرارداد، محدود میکند. **الگوی مالکیت** و **کنترل مبتنی بر نقش** دو الگوی مفید برای اجرای کنترل دسترسی در قراردادهای هوشمند هستند:
+
+#### الگوی قابل مالکیت {#ownable-pattern}
+
+در الگویل قابل مالکیت، یک آدرس به عنوان "مالک" قرارداد در طول فرآیند ایجاد قرارداد تنظیم می شود. به توابع محافظت شده یک اصلاحکننده `OnlyOwner` اختصاص داده میشود، که تضمین میکند قرارداد قبل از اجرای تابع، هویت آدرس تماس را تأیید میکند. تماسهای توابع محافظتشده از آدرسهای دیگر به غیر از مالک قرارداد، همیشه برمیگردند و از دسترسی ناخواسته جلوگیری میکنند.
+
+#### کنترل دسترسی مبتنی بر نقش {#role-based-access-control}
+
+ثبت یک آدرس واحد بهعنوان `Owner` در یک قرارداد هوشمند، خطر تمرکز را معرفی میکند و نشاندهنده یک نقطه شکست واحد است. اگر کلیدهای حساب مالک به خطر بیفتد، مهاجمان می توانند به قرارداد مالکیت حمله کنند. به همین دلیل است که استفاده از الگوی کنترل دسترسی مبتنی بر نقش با چندین حساب اداری ممکن است گزینه بهتری باشد.
+
+در کنترل دسترسی مبتنی بر نقش، دسترسی به عملکردهای حساس بین مجموعه ای از شرکت کنندگان قابل اعتماد توزیع می شود. به عنوان مثال، یک حساب ممکن است مسئول ضرب توکن ها باشد، در حالی که حساب دیگری ارتقاء داده یا قرارداد را متوقف می کند. غیرمتمرکز کردن کنترل دسترسی به این روش، نقاط منفرد شکست را از بین می برد و مفروضات اعتماد را برای کاربران کاهش می دهد.
+
+##### استفاده از کیف پولهای چند امضایی
+
+روش دیگر برای اجرای کنترل دسترسی ایمن استفاده از [حساب چند امضایی](/developers/docs/smart-contracts/#multisig) برای مدیریت قرارداد است. برخلاف یک EOA معمولی، حسابهای چند امضایی متعلق به چندین نهاد هستند و برای انجام تراکنشها به امضای حداقل تعداد حسابها (مثلاً 3 از 5) نیاز دارند.
+
+استفاده از مالتی سیگ برای کنترل دسترسی، یک لایه امنیتی اضافی را معرفی میکند زیرا اقدامات روی قرارداد هدف مستلزم رضایت چندین طرف است. این مورد به ویژه در صورتی مفید است که استفاده از الگوی اونبل (Ownable) ضروری باشد، زیرا دستکاری عملکردهای حساس قرارداد برای اهداف مخرب را برای مهاجم دشوارتر میکند.
+
+### 2. برای محافظت از عملیات قرارداد از عبارات require() و assert() و revert() استفاده کنید {#use-require-assert-revert}
+
+همانطور که گفته شد، هر کسی میتواند توابع عمومی را در قرارداد هوشمند شما پس از استقرار در بلاکچین فراخوانی کند. از آنجایی که نمیتوانید از قبل بدانید حسابهای خارجی چگونه با یک قرارداد تعامل خواهند داشت، بهتراست که قبل از استقرار، حفاظتهای داخلی در برابر عملیات مشکلساز را اجرا کنید. میتوانید با استفاده از دستورات `require()`، `assert()` و `revert()` رفتار صحیح را در قراردادهای هوشمند برای راهاندازی استثناها و برگرداندن تغییرات حالت اعمال کنید، در صورتی که اجرا نتواند الزامات خاصی را برآورده کند.
+
+**`require()`**: دستورها `require` در شروع توابع تعریف میشوند و اطمینان میدهند که شرایط از پیش تعریف شده قبل از اجرای تابع فراخوانی شده برآورده میشوند. یک عبارت `require` را میتوان برای اعتبارسنجی ورودی های کاربر، بررسی متغیرهای حالت، یا احراز هویت حساب فراخوان قبل از پیشرفت با یک تابع استفاده کرد.
+
+**`assert()`**: دستور `assert()` برای شناسایی خطاهای داخلی و بررسی نقض "invariants" در کد شما استفاده می شود. یک invariant یک ادعای منطقی در مورد وضعیت قرارداد است که باید برای اجرای همه توابع صادق باشد. یک مثال ثابت، حداکثر عرضه یا موجودی یک قرارداد توکن است. استفاده از `assert()` تضمین میکند که قرارداد شما هرگز به یک وضعیت آسیبپذیر نمیرسد، و در صورت رسیدن، همه تغییرات در متغیرهای حالت برگردانده میشوند.
+
+**`revert()`**: دستور `revert()` را می توان در یک عبارت if-else استفاده کرد که در صورت عدم رعایت شرایط مورد نیاز، یک استثنا ایجاد می کند. قرارداد نمونه زیر از `revert()` برای محافظت از اجرای توابع استفاده می کند:
+
+```
+pragma solidity ^0.8.4;
+
+contract VendingMachine {
+ address owner;
+ error Unauthorized();
+ function buy(uint amount) public payable {
+ if (amount > msg.value / 2 ether)
+ revert("Not enough Ether provided.");
+ // Perform the purchase.
+ }
+ function withdraw() public {
+ if (msg.sender != owner)
+ revert Unauthorized();
+
+ payable(msg.sender).transfer(address(this).balance);
+ }
+}
+```
+
+### 3. قراردادهای هوشمند را تست کنید و صحت کد را تأیید کنید {#test-smart-contracts-and-verify-code-correctness}
+
+تغییرناپذیری کدهای در حال اجرا در [ماشین مجازی اتریوم](/developers/docs/evm/) به این معنی است که قراردادهای هوشمند سطح بالاتری از ارزیابی کیفیت را در مرحله توسعه می طلبد. تست قرارداد خود به طور گسترده و مشاهده آن برای نتایج غیرمنتظره امنیت را تا حد زیادی بهبود میبخشد و در دراز مدت از کاربران شما محافظت میکند.
+
+روش معمول نوشتن تستهای واحد کوچک با استفاده از دادههای ساختگی است که انتظار میرود قرارداد را از کاربران دریافت کند. [آزمایش Unit ](/developers/docs/smart-contracts/testing/#unit-testing) برای آزمایش عملکرد عملکردهای خاص و اطمینان از اینکه قرارداد هوشمند مطابق انتظار عمل می کند خوب است.
+
+متأسفانه، تست واحد برای بهبود امنیت قراردادهای هوشمند زمانی که به صورت مجزا مورد استفاده قرار میگیرد، حداقل مؤثر است. یک تست واحد ممکن است ثابت کند که یک تابع برای دادههای ساختگی به درستی اجرا میشود، اما تستهای واحد فقط به اندازه تستهای نوشته شده مؤثر هستند. این امر تشخیص موارد لبه از دست رفته و آسیب پذیری هایی را که می تواند ایمنی قرارداد هوشمند شما را به هم بزند، دشوار می کند.
+
+یک رویکرد بهتر ترکیب آزمایش واحد با آزمایش مبتنی بر ویژگی است که با استفاده از [تحلیل استاتیک و پویا](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) انجام میشود. تجزیه و تحلیل استاتیک بر نمایشهای سطح پایین، مانند [گرافهای جریان کنترل](https://en.wikipedia.org/wiki/Control-flow_graph) و [درختهای نحو انتزاعی](https:// deepsource.io/glossary/ast/) برای تجزیه و تحلیل وضعیتهای قابل دسترسی برنامه و مسیرهای اجرا. در همین حال، تکنیکهای تحلیل پویا، مانند [فازی قرارداد هوشمند](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)، قرارداد را اجرا میکنند. کد با مقادیر ورودی تصادفی برای شناسایی عملیاتی که ویژگیهای امنیتی را نقض میکند.
+
+[تأیید رسمی](/developers/docs/smart-contracts/formal-verification) تکنیک دیگری برای تأیید ویژگیهای امنیتی در قراردادهای هوشمند است. برخلاف تستهای معمولی، تأیید رسمی میتواند به طور قطعی عدم وجود خطا در یک قرارداد هوشمند را ثابت کند. این امر با ایجاد یک مشخصات رسمی که ویژگیهای امنیتی مورد نظر را نشان میدهد و اثبات اینکه مدل رسمی قراردادها به این مشخصات پایبند است، به دست میآید.
+
+### 4. درخواست بررسی مستقل کد خود را داشته باشید {#get-independent-code-reviews}
+
+پس از تست قرارداد خود، بهتر است از دیگران بخواهید که کد منبع را برای هرگونه مشکل امنیتی بررسی کنند. تست تمام ایرادات یک قرارداد هوشمند را آشکار نمیکند، اما دریافت یک بررسی مستقل امکان شناسایی آسیب پذیریها را افزایش میدهد.
+
+#### حسابرسیهای امنیتی {#audits}
+
+راهاندازی آدیت قرارداد هوشمند یکی از راههای انجام بررسی مستقل کد است. حسابرسان یا آدیتورها نقش مهمی در حصول اطمینان از ایمن بودن قراردادهای هوشمند و عاری از نقص کیفی و خطاهای طراحی دارند.
+
+با وجود همهی این موارد، شما نباید با حسابرسی امنیتی مانند پاسخی برای تمام مشکلات برخورد کنید. آدیت قراردادهای هوشمند هر اشکالی را شناسایی نمیکند و عمدتاً برای ارائه یک سری بررسی اضافی طراحی شده است که میتواند به شناسایی مشکلاتی که توسعه دهندگان در طول توسعه و تست اولیه از قلم انداختهاند کمک کند. همچنین باید بهترین روشها را برای کار با حسابرسان، مانند مستندسازی کد به درستی و افزودن نظرات درون خطی، دنبال کنید تا از مزایای حسابرسی قرارداد هوشمند به حداکثر برسانید.
+
+- [نکات حسابرسی قرارداد هوشمند و amp; ترفندها](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_
+- [از حسابرسی خود حداکثر استفاده را ببرید](https://inference.ag/blog/2023-08-14-tips/) - _ em>
+
+#### پاداشهای باگ {#bug-bounties}
+
+راه اندازی یک برنامه باگ بانتی روش دیگری برای اجرای بررسی کدهای خارجی است. جایزه باگ یک پاداش مالی است که به افرادی (معمولاً هکرهای کلاه سفید) که آسیبپذیریهای یک برنامه را کشف میکنند، داده میشود.
+
+هنگامی که به درستی استفاده میشود، پاداشهای باگ به اعضای جامعه هکر انگیزه میدهد تا کد شما را از نظر نقصهای مهم بررسی کنند. یک مثال واقعی "باگ پول بینهایت" است که به مهاجم اجازه میدهد مقدار نامحدودی اتر را در [آپتیمیزم](https://www.optimism.io/) ایجاد کند، یک < یک پروتکل href="/layer-2/">لایه 2 که روی اتریوم اجرا میشود. خوشبختانه، یک هکر whitehat [این نقص را کشف کرد](https://www.saurik.com/optimism.html) و به تیم اطلاع داد، [کسب پرداختی بزرگ در این فرآیند انجام شد](https://cryptoslate.com/ بحرانی-اشکال-in-ethereum-l2-optimism-2m-bounty-paid/).
+
+یک استراتژی مفید این است که پرداخت برنامه پاداش اشکال را متناسب با مقدار وجوه مورد نظر تنظیم کنید. این رویکرد بهعنوان «[اشکال مقیاسگذاری](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) توصیف میشود. انگیزههای مالی برای افراد برای افشای مسئولانه آسیب پذیریها به جای سوء استفاده از آنها را ایجاد میکند.
+
+### 5. در هنگام توسعه قراردادهای هوشمند بهترین رویه های موجود را دنبال کنید {#follow-smart-contract-development-best-practices}
+
+وجود آدیت و پاداش باگ مسئولیت شما را برای نوشتن کد با کیفیت بالا توجیه نمیکند. امنیت قرارداد هوشمند خوب با فرآیندهای طراحی و توسعه مناسب زیر شروع میشود:
+
+- همه کدها را در یک سیستم کنترل نسخه مانند git ذخیره کنید
+
+- تمام تغییرات کد را از طریق درخواستهای pull انجام دهید
+
+- اطمینان حاصل کنید که درخواستهای pull حداقل یک بازبین مستقل دارند—اگر به تنهایی روی پروژهای کار میکنید، توسعهدهندگان دیگر و بررسیهای کد تجاری را پیدا کنید
+
+- از یک [محیط توسعه](/developers/docs/فریم ورک/) برای آزمایش، کامپایل، استقرار قراردادهای هوشمند استفاده کنید
+
+- کد خود را از طریق ابزارهای اصلی تجزیه و تحلیل کد، مانند [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn)، Mythril و Slither اجرا کنید. در حالت ایدهآل، باید این کار را قبل از ادغام هر درخواست pull انجام دهید و تفاوتها را در خروجی مقایسه کنید
+
+- مطمئن شوید که کد شما بدون خطا کامپایل شده است و کامپایلر سالیدیتی هیچ هشداری صادر نمیکند
+
+- کد خود را به درستی مستند کنید (با استفاده از [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)) و جزئیات مربوط به معماری قرارداد را به آسانی شرح دهید. این کار بررسی و بازبینی کد شما را برای دیگران آسانتر میکند.
+
+### 6. اجرای طرحهای قوی بازیابی حوادث {#implement-disaster-recovery-plans}
+
+طراحی کنترلهای دسترسی ایمن، اجرای اصلاحکنندههای عملکرد و سایر پیشنهادها میتواند امنیت قرارداد هوشمند را بهبود بخشد، اما نمیتواند احتمال سوء استفادههای مخرب را رد کند. ایجاد قراردادهای هوشمند ایمن مستلزم «آماده شدن برای شکست» و داشتن یک برنامه بازگشتی برای پاسخگویی مؤثر به حملات است. یک طرح مناسب برای بازیابی حوادث شامل برخی یا همه اجزای زیر است:
+
+#### ارتقاهای قرارداد {#contract-upgrades}
+
+در حالی که قراردادهای هوشمند اتریوم به طور پیش فرض تغییر ناپذیر هستند، میتوان با استفاده از الگوهای ارتقا به درجاتی از تغییرپذیری دست یافت. به روز رسانی قراردادها در مواردی ضروری است که یک نقص مهم قرارداد قدیمی شما را غیرقابل استفاده میکند و به کارگیری منطق جدید امکان پذیرترین گزینه است.
+
+مکانیسمهای ارتقای قرارداد متفاوت عمل میکنند، اما «الگوی پروکسی» یکی از محبوبترین رویکردها برای ارتقای قراردادهای هوشمند است. [الگوهای پراکسی](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) منطق اجرائی و فضای ذخیرهسازی دادهها را بین _دو_ قرارداد تقسیم میکند. قرارداد اول (که "قرارداد پراکسی" نامیده میشود) متغیرهای حالت را ذخیره میکند (به عنوان مثال، موجودی کاربر)، در حالی که قرارداد دوم (که "منطق قرارداد" نامیده میشود) کد اجرای توابع قرارداد را نگه میدارد.
+
+حسابها با قرارداد پروکسی تعامل دارند، که همه فراخوانیهای تابع را با استفاده از [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight به قرارداد منطقی ارسال میکند. =delegatecall#delegatecall-callcode-and-libraries) تماس سطح پایین. برخلاف یک تماس پیامی معمولی، `delegatecall()` تضمین میکند که کد در حال اجرا در آدرس قرارداد منطقی در متن قرارداد فراخوانی اجرا میشود. یک تماس پیامی معمولی، `delegatecall()` تضمین میکند که کد در حال اجرا در آدرس قرارداد منطقی در متن قرارداد فراخوانی اجرا میشود.
+
+واگذاری تماسها به قرارداد منطقی مستلزم ذخیره آدرس آن در فضای ذخیرهسازی قرارداد پروکسی است. از این رو، ارتقاء منطق قرارداد فقط به استقرار یک قرارداد منطقی دیگر و ذخیره آدرس جدید در قرارداد پروکسی بستگی دارد. از آنجایی که فراخوانی یا تماسهای بعدی به قرارداد پروکسی به طور خودکار به قرارداد منطقی جدید هدایت میشوند، میتوانید قرارداد را بدون تغییر واقعی کد «ارتقاء» میدادید.
+
+[اطلاعات بیشتر در مورد ارتقاء قراردادها](/developers/docs/smart-contracts/upgrading/).
+
+#### توقفهای اضطراری {#emergency-stops}
+
+همانطور که گفته شد، آدیت و آزمایش گسترده نمیتواند تمام اشکالات یک قرارداد هوشمند را کشف کند. اگر پس از استقرار یک آسیبپذیری در کد شما ظاهر شد، اصلاح آن غیرممکن است، زیرا نمیتوانید کد در حال اجرا در آدرس قرارداد را تغییر دهید. همچنین، مکانیسمهای ارتقا (مثلاً الگوهای پروکسی) ممکن است برای پیادهسازی زمان ببرد (اغلب به تأیید طرفهای مختلف نیاز دارند)، که تنها به مهاجمان زمان بیشتری برای ایجاد آسیب بیشتر میدهد.
+
+گزینه هستهای اجرای یک تابع "توقف اضطراری" است که تماسهای عملکردهای آسیب پذیر را در یک قرارداد مسدود میکند. توقفهای اضطراری معمولاً شامل اجزای زیر است:
+
+1. یک متغیر جهانی بولی (Boolean) که نشان میدهد قرارداد هوشمند در حالت توقف است یا خیر. این متغیر هنگام تنظیم قرارداد روی `false` تنظیم میشود، اما پس از توقف قرارداد به `true` برمیگردد.
+
+2. توابعی که در اجرای خود به متغیر بولی (Boolean) اشاره میکنند. زمانی که قرارداد هوشمند متوقف نشده باشد، چنین عملکردهایی قابل دسترسی هستند و با فعال شدن ویژگی توقف اضطراری، غیرقابل دسترس میشوند.
+
+3. موجودی که به تابع توقف اضطراری دسترسی دارد، که متغیر Boolean را روی `true` تنظیم میکند. برای جلوگیری از اعمال مخرب، تماسهای این تابع را میتوان به یک آدرس مطمئن محدود کرد (به عنوان مثال، مالک قرارداد).
+
+هنگامی که قرارداد توقف اضطراری را فعال کرد، عملکردهای خاصی قابل فراخوانی نخواهند بود. این مورد با قرار دادن توابع انتخابی در یک اصلاح کننده که به متغیر سراسری ارجاع میدهد، به دست میآید. در زیر [نمونهای](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) وجود دارد که اجرای این الگو را در قراردادها شرح میدهد:
+
+```solidity
+// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk.
+
+contract EmergencyStop {
+
+ bool isStopped = false;
+
+ modifier stoppedInEmergency {
+ require(!isStopped);
+ _;
+ }
+
+ modifier onlyWhenStopped {
+ require(isStopped);
+ _;
+ }
+
+ modifier onlyAuthorized {
+ // Check for authorization of msg.sender here
+ _;
+ }
+
+ function stopContract() public onlyAuthorized {
+ isStopped = true;
+ }
+
+ function resumeContract() public onlyAuthorized {
+ isStopped = false;
+ }
+
+ function deposit() public payable stoppedInEmergency {
+ // Deposit logic happening here
+ }
+
+ function emergencyWithdraw() public onlyWhenStopped {
+ // Emergency withdraw happening here
+ }
+}
+```
+
+این مثال ویژگیهای اساسی توقفهای اضطراری را نشان میدهد:
+
+- `isStopped` یک بولین است که در ابتدا به `false` و هنگامی که قرارداد وارد حالت اضطراری میشود `true` ارزیابی میشود.
+
+- تغییردهنده تابع `onlyWhenStopped` و `stoppedInEmergency` متغیر `isStopped` را بررسی میکنند. `stoppedInEmergency` برای کنترل توابعی استفاده میشود که در صورت آسیبپذیر بودن قرارداد، غیرقابل دسترسی هستند (به عنوان مثال، `deposit()`). تماسهای این توابع به سادگی برمیگردند.
+
+`onlyWhenStopped` برای توابعی استفاده میشود که باید در مواقع اضطراری قابل فراخوانی باشند (مانند `emergencyWithdraw()`). چنین توابعی میتوانند به حل وضعیت کمک کنند، از این رو آنها را از لیست "عملکردهای محدود" حذف میکنند.
+
+استفاده از عملکرد توقف اضطراری یک توقف مؤثر برای مقابله با آسیب پذیریهای جدی در قرارداد هوشمند شما فراهم میکند. با این حال، نیاز کاربران به اعتماد به توسعهدهندگان را افزایش میدهد تا آن را به دلایل خود خدمتی فعال نکنند. برای این منظور، غیرمتمرکز کردن کنترل توقف اضطراری یا با قرار دادن آن در معرض مکانیزم رایگیری زنجیرهای، قفل زمانی یا تایید از یک کیف پول مالتی سیگ راهحلهای ممکن است.
+
+#### نظارت بر رویداد {#event-monitoring}
+
+[رویدادها](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) به شما امکان میدهد تماسهای مربوط به عملکردهای قرارداد هوشمند را ردیابی و تغییرات متغیرهای حالت را نظارت کنید. بهتر است که قرارداد هوشمند خود را طوری برنامهریزی کنید که هر زمان که یکی از طرفین یک اقدام مهم ایمنی (مثلاً برداشت وجه) انجام میدهد، رویدادی را منتشر کند.
+
+ثبت رویدادها و نظارت بر آنها به صورت غیر زنجیرهای بینشهایی در مورد عملیات قرارداد ارائه میدهد و به کشف سریعتر اقدامات مخرب کمک میکند. این بدان معناست که تیم شما میتواند سریعتر به هکها پاسخ دهد و برای کاهش تأثیر روی کاربران، مانند توقف موقت عملکردها یا انجام ارتقا، اقدام کند.
+
+همچنین میتوانید ابزار نظارتی خارج از قفسه را انتخاب کنید که به طور خودکار هشدارها را هر زمان که کسی با قراردادهای شما تعامل دارد، ارسال میکند. این ابزارها به شما این امکان را میدهند که بر اساس محرکهای مختلف، مانند حجم تراکنش، فرکانس فراخوانی عملکرد، یا عملکردهای خاص، هشدارهای سفارشی ایجاد کنید. برای مثال، میتوانید هشداری را برنامهریزی کنید که زمانی که مبلغ برداشت شده در یک تراکنش از یک آستانه خاص عبور میکند، وارد میشود.
+
+### 7. طراحی سیستمهای حاکمیت ایمن {#design-secure-governance-systems}
+
+ممکن است بخواهید با سپردن کنترل قراردادهای هوشمند اصلی به اعضای جامعه، برنامه خود را غیرمتمرکز کنید. در این مورد، سیستم قرارداد هوشمند شامل یک ماژول حاکمیتی خواهد بود – مکانیزمی که به اعضای جامعه اجازه میدهد تا اقدامات اداری را از طریق یک سیستم حاکمیت زنجیرهای تأیید کنند. برای مثال، پیشنهادی برای ارتقاء قرارداد پروکسی به یک پیادهسازی جدید ممکن است توسط دارندگان توکن به رأی گذاشته شود.
+
+حاکمیت غیرمتمرکز می تواند سودمند باشد، به ویژه به این دلیل که منافع توسعه دهندگان و کاربران نهایی را همسو می کند. با این وجود، مکانیسمهای حکمرانی قراردادهای هوشمند ممکن است در صورت اجرای نادرست، خطرات جدیدی را ایجاد کنند. یک سناریوی قابل قبول این است که مهاجم با گرفتن [وام فوری](/defi/#flash-loans) قدرت رای عظیمی (که بر حسب تعداد توکنهای نگهداری شده اندازهگیری میشود) به دستآورد و یک پیشنهاد مخرب را انجام دهد.
+
+یکی از راه های جلوگیری از مشکلات مربوط به حاکمیت زنجیره ای، [استفاده از قفل زمانی](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/) است. قفل زمانی مانع از اجرای یک قرارداد هوشمند تا زمان مشخصی می شود. راهبردهای دیگر عبارتند از اختصاص یک "وزن رای" به هر توکن بر اساس مدت زمانی که قفل شده است، یا اندازه گیری قدرت رای دادن یک آدرس در یک دوره تاریخی (مثلاً 2-3 بلوک در گذشته) به جای بلوک فعلی. هر دو روش امکان جمعآوری سریع قدرت رای برای تغییر آرای زنجیره ای را کاهش می دهند.
+
+اطلاعات بیشتر در مورد [طراحی سیستمهای حاکمیت ایمن](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)، [مکانیسمهای رایگیری مختلف در DAOها](https://hackernoon.com/governance-is-the-holy-grail-for-daos)، و [بردارهای رایج حمله DAO با استفاده از دیفای](https://dacian.me/dao-governance-defi-attacks) در لینکهای مشترک.
+
+### 8. کاهش پیچیدگی کد به حداقل {#reduce-code-complexity}
+
+توسعه دهندگان نرمافزار سنتی با اصل KISS ("ساده نگهش دار، احمقانه") آشنا هستند، که توصیه می کند از وارد کردن پیچیدگی های غیر ضروری در طراحی نرمافزار خودداری کنید. این امر متعاقب این تفکر دیرینه است که "سیستم های پیچیده به روش های پیچیده شکست می خورند" و بیشتر مستعد خطاهای پرهزینه هستند.
+
+با توجه به اینکه قراردادهای هوشمند به طور بالقوه مقادیر زیادی از ارزش را کنترل می کنند، ساده نگه داشتن چیزها هنگام نوشتن قراردادهای هوشمند از اهمیت ویژه ای برخوردار است. نکته ای برای دستیابی به سادگی هنگام نوشتن قراردادهای هوشمند، استفاده مجدد از کتابخانه های موجود، مانند [قراردادهای OpenZeppelin](https://docs.openzeppelin.com/contracts/4.x/)، در صورت امکان است. از آنجایی که این کتابخانه ها به طور گسترده توسط توسعه دهندگان ممیزی و آزمایش شده اند، استفاده از آنها با نوشتن عملکردهای جدید از ابتدا، شانس معرفی اشکالات را کاهش می دهد.
+
+توصیه رایج دیگر نوشتن توابع کوچک و مدولار نگه داشتن قراردادها با تقسیم منطق تجاری در چندین قرارداد است. نه تنها نوشتن کد سادهتر سطح حمله را در یک قرارداد هوشمند کاهش میدهد، بلکه استدلال درباره درستی سیستم کلی و تشخیص زودهنگام خطاهای احتمالی طراحی را آسانتر میکند.
+
+### 9. دفاع در برابر آسیبپذیریهای رایج قرارداد هوشمند {#mitigate-common-smart-contract-vulnerabilities}
+
+#### ورود دوباره {#reentrancy}
+
+EVM اجازه همزمانی را نمی دهد، به این معنی که دو قرارداد درگیر در یک تماس پیام نمی توانند به طور همزمان اجرا شوند. یک فراخوانی خارجی، اجرای قرارداد و حافظه فراخوان را تا زمانی که تماس برگردد، متوقف میکند، در این مرحله اجرا به طور معمول ادامه مییابد. این فرآیند را می توان به طور رسمی به عنوان انتقال [جریان کنترل](https://www.computerhope.com/jargon/c/contflow.htm) به قرارداد دیگری توصیف کرد.
+
+اگرچه اغلب بی ضرر هستند، اما انتقال جریان کنترل به قراردادهای غیرقابل اعتماد می تواند مشکلاتی مانند ورود دوباره ایجاد کند. یک حمله ورود دوباره زمانی اتفاق میافتد که یک قرارداد مخرب قبل از تکمیل فراخوانی عملکرد اصلی، یک قرارداد آسیبپذیر را دوباره فراخوانی کند. این نوع حمله به بهترین شکل با یک مثال توضیح داده می شود.
+
+یک قرارداد هوشمند ساده ("قربانی") را در نظر بگیرید که به هر کسی اجازه می دهد اتر را واریز و برداشت کند:
+
+```solidity
+// This contract is vulnerable. Do not use in production
+
+contract Victim {
+ mapping (address => uint256) public balances;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ }
+
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ balances[msg.sender] = 0;
+ }
+}
+```
+
+این قرارداد یک تابع `withdraw()` را نشان میدهد تا به کاربران امکان میدهد ETH را که قبلاً در قرارداد سپرده شده برداشت کنند. هنگام پردازش یک برداشت، قرارداد عملیات زیر را انجام میدهد:
+
+1. تعادل اتر کاربر را بررسی میکند
+2. وجوه را به آدرس تماس ارسال میکند
+3. موجودی آنها را به 0 بازنشانی میکند و از برداشت اضافی از کاربر جلوگیری میکند
+
+تابع `withdraw()` در قرارداد ` قربانی` از الگوی "بررسی-تعامل-اثرات" پیروی می کند. که _بررسی میکند_ آیا شرایط لازم برای اجرا برآورده شده است (یعنی کاربر دارای موجودی ETH مثبت است) و قبل از اعمال _اثرات_ تراکنش (یعنی کاهش موجودی کاربر) _تعامل_ را با ارسال ETH به آدرس تماسگیرنده انجام میدهد.
+
+اگر `withdraw()` از یک حساب تحت مالکیت خارجی (EOA) فراخوانی شود، تابع همانطور که انتظار می رود اجرا می شود: `msg.sender.call.value()` ETH را برای تماس گیرنده ارسال می کند. با این حال، اگر `msg.sender` یک حساب قرارداد هوشمند باشد، `withdraw()` را فراخوانی میکند، ارسال وجوه با استفاده از `msg.sender.call.value()` انجام میشود. همچنین کدهای ذخیره شده در آن آدرس را برای اجرا راه اندازی کنید.
+
+تصور کنید این کدی است که در آدرس قرارداد مستقر شده است:
+
+```solidity
+ contract Attacker {
+ function beginAttack() external payable {
+ Victim(victim_address).deposit.value(1 ether)();
+ Victim(victim_address).withdraw();
+ }
+
+ function() external payable {
+ if (gasleft() > 40000) {
+ Victim(victim_address).withdraw();
+ }
+ }
+}
+```
+
+این قرارداد برای انجام سه کار طراحی شده است:
+
+1. پذیرش سپرده از حساب دیگری (احتمالاً EOA مهاجم)
+2. واریز یک سکه ETH به قرارداد قربانی
+3. برداشت یک سکه ETH ذخیره شده در قرارداد هوشمند
+
+هیچ مشکلی در اینجا وجود ندارد، به جز اینکه `مهاجم` تابع دیگری دارد که اگر گس باقی مانده از `msg.sender.call.value` ورودی بیش از 40،000 باشد.ده باشد، تابع دیگری دارد که `withdraw()` را در ` قربانی` دوباره فراخوانی میکند. این به `مهاجم` این امکان را میدهد تا `قربانی` را دوباره وارد کرده و وجوه بیشتری را _قبل از_ تکمیل اولین فراخوان `خروج` برداشت کند. چرخه به این صورت است:
+
+```solidity
+- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH
+- `Attacker.beginAttack()` deposits 1 ETH into `Victim`
+- `Attacker` calls `withdraw() in `Victim`
+- `Victim` checks `Attacker`’s balance (1 ETH)
+- `Victim` sends 1 ETH to `Attacker` (which triggers the default function)
+- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal)
+- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call)
+- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function)
+- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals
+- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0
+```
+
+خلاصه موضوع این است که چون موجودی تماسگیرنده تا زمانی که اجرای تابع کامل نشود روی 0 تنظیم نمیشود، فراخوانیهای بعدی موفق خواهند شد و به تماسگیرنده اجازه میدهند تا موجودی خود را چندین بار برداشت کند. از این نوع حمله می توان برای تخلیه یک قرارداد هوشمند از وجوه آن استفاده کرد، مانند آنچه در [هک DAO سال 2016](https://www.coindesk.com/learn/2016/06/25/understanding-the-dao-attack/) اتفاق افتاد. همانطور که [فهرستهای عمومی اکسپلویتهای reentrancy](https://github.com/pcaversaccio/reentrancy-attacks) نشان میدهند، حملات reentrancy امروزه همچنان یک موضوع حیاتی برای قراردادهای هوشمند است.
+
+##### چگونه از حملات بازگشت مجدد جلوگیری کنیم
+
+یک رویکرد برای مقابله با reentrancy، پیروی از [الگوی بررسی-اثرات-تعامل](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) است. این الگو دستور اجرای توابع را میدهد به گونهای که کدی که بررسیهای لازم را قبل از پیشرفت در اجرا انجام میدهد، ابتدا میآید، به دنبال آن کدی که وضعیت قرارداد را دستکاری میکند، کدی که با قراردادهای دیگر تعامل دارد یا EOAها در آخر میآیند.
+
+الگوی بررسی-اثرات-تعامل در نسخه اصلاح شده قرارداد `قربانی` که در زیر نشان داده شده است استفاده می شود:
+
+```solidity
+contract NoLongerAVictim {
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ }
+}
+```
+
+این قرارداد یک _بررسی_ در موجودی کاربر انجام می دهد، _اثرات_ تابع `withdraw()` را اعمال می کند (با تنظیم مجدد موجودی کاربر به 0)، و به انجام _تعامل_ (ارسال ETH به آدرس کاربر) ادامه می دهد. این مورد تضمین میکند که قرارداد قبل از تماس خارجی، فضای ذخیرهسازی خود را بهروزرسانی میکند و شرایط ورود مجدد را که اولین حمله را فعال میکرد، حذف میکند. قرارداد `مهاجم` همچنان میتواند به `NoLongerAVictim` برگردد، اما از آنجایی که `balances[msg.sender]` روی 0 تنظیم شده است، برداشتهای اضافی با خطا مواجه میشوند.
+
+گزینه دیگر استفاده از یک قفل محرومیت متقابل (که معمولاً به عنوان "mutex" توصیف می شود) است که بخشی از وضعیت قرارداد را تا زمانی که فراخوانی عملکرد کامل شود قفل می کند. این امر با استفاده از یک متغیر بولین که قبل از اجرای تابع روی `true` تنظیم شده است و پس از انجام فراخوانی به `false` برمیگردد پیادهسازی میشود. همانطور که در مثال زیر مشاهده میشود، استفاده از میوتکس از یک تابع در برابر تماسهای بازگشتی محافظت میکند در حالی که فراخوان اصلی هنوز در حال پردازش است، و به طور مؤثر ورود مجدد را متوقف میکند.
+
+```solidity
+pragma solidity ^0.7.0;
+
+contract MutexPattern {
+ bool locked = false;
+ mapping(address => uint256) public balances;
+
+ modifier noReentrancy() {
+ require(!locked, "Blocked from reentrancy.");
+ locked = true;
+ _;
+ locked = false;
+ }
+ // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again.
+ // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier
+ function withdraw(uint _amount) public payable noReentrancy returns(bool) {
+ require(balances[msg.sender] >= _amount, "No balance to withdraw.");
+
+ balances[msg.sender] -= _amount;
+ bool (success, ) = msg.sender.call{value: _amount}("");
+ require(success);
+
+ return true;
+ }
+}
+```
+
+همچنین میتوانید به جای سیستم «پرداخت فشاری» که وجوه را به حسابها ارسال میکند، از سیستم [برگشت پرداختها](https://docs.openzeppelin.com/contracts/4.x/api/security#PullPayment) استفاده کنید که کاربران را ملزم به برداشت وجه از قراردادهای هوشمند میکند. با این کار امکان راهاندازی ناخواسته کد در آدرسهای ناشناس حذف میشود (و همچنین میتواند از برخی حملات انکار سرویس جلوگیری کند).
+
+#### پاریز و سرریز اعداد صحیح {#integer-underflows-and-overflows}
+
+سرریز یا اورفلو اعداد صحیح زمانی اتفاق میافتد که نتایج یک عملیات حسابی خارج از محدوده قابل قبول مقادیر قرار میگیرد و باعث میشود که آن را به پایینترین مقدار قابل نمایش تبدیل کند. برای مثال، یک `uint8` فقط میتواند مقادیر تا 2^8-1=255 را ذخیره کند. عملیات حسابی که به مقادیر بالاتر از `255` منجر میشود، سرریز یا اورفلو میشوند و `uint` را به `0` بازنشانی میکنند، مشابه اینکه کیلومترشمار ماشین بعد از به حداکثر رسیدن مسافت پیموده شده (999999) به 0 بازنشانی شود.
+
+جریانهای آندرفلو صحیح به دلایل مشابهی اتفاق میافتد: نتایج یک عملیات حسابی کمتر از محدوده قابل قبول است. فرض کنید سعی کردهاید `0` را در `uint8` کاهش دهید، نتیجه به سادگی به حداکثر مقدار قابل نمایش (`255`) میرسد.
+
+هم اورفلو و هم آندرفلو اعداد صحیح میتواند منجر به تغییرات غیرمنتظره در متغیرهای حالت قرارداد شود و منجر به اجرای برنامه ریزی نشده شود. در زیر مثالی وجود دارد که نشان میدهد چگونه یک مهاجم میتواند از سرریز حسابی در یک قرارداد هوشمند برای انجام یک عملیات نامعتبر سوء استفاده کند:
+
+```
+pragma solidity ^0.7.6;
+
+// This contract is designed to act as a time vault.
+// User can deposit into this contract but cannot withdraw for at least a week.
+// User can also extend the wait time beyond the 1 week waiting period.
+
+/*
+1. Deploy TimeLock
+2. Deploy Attack with address of TimeLock
+3. Call Attack.attack sending 1 ether. You will immediately be able to
+ withdraw your ether.
+
+What happened?
+Attack caused the TimeLock.lockTime to overflow and was able to withdraw
+before the 1 week waiting period.
+*/
+
+contract TimeLock {
+ mapping(address => uint) public balances;
+ mapping(address => uint) public lockTime;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ lockTime[msg.sender] = block.timestamp + 1 weeks;
+ }
+
+ function increaseLockTime(uint _secondsToIncrease) public {
+ lockTime[msg.sender] += _secondsToIncrease;
+ }
+
+ function withdraw() public {
+ require(balances[msg.sender] > 0, "Insufficient funds");
+ require(block.timestamp > lockTime[msg.sender], "Lock time not expired");
+
+ uint amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+
+ (bool sent, ) = msg.sender.call{value: amount}("");
+ require(sent, "Failed to send Ether");
+ }
+}
+
+contract Attack {
+ TimeLock timeLock;
+
+ constructor(TimeLock _timeLock) {
+ timeLock = TimeLock(_timeLock);
+ }
+
+ fallback() external payable {}
+
+ function attack() public payable {
+ timeLock.deposit{value: msg.value}();
+ /*
+ if t = current lock time then we need to find x such that
+ x + t = 2**256 = 0
+ so x = -t
+ 2**256 = type(uint).max + 1
+ so x = type(uint).max + 1 - t
+ */
+ timeLock.increaseLockTime(
+ type(uint).max + 1 - timeLock.lockTime(address(this))
+ );
+ timeLock.withdraw();
+ }
+}
+```
+
+##### چگونه از سرریز و آندرفلو اعداد صحیح جلوگیری کنیم
+
+از نسخه 0.8.0، کامپایلر سالیدیتی کدهایی را که منجر به سرریز و زیر جریان یا همان آندر فلو اعداد صحیح میشود، رد میکند. با این حال، قراردادهایی که با یک نسخه کامپایلر پایینتر کامپایل میشوند باید یا باید توابع مربوط به عملیات حسابی را بررسی یا از یک کتابخانه استفاده کنند (به عنوان مثال، [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) که اورفلو یا آندرفلو را بررسی میکند.
+
+#### دستکاری اوراکل {#oracle-manipulation}
+
+[اوراکلها](/developers/docs/oracles/) اطلاعات خارج از زنجیره را منبع قرار میدهند و آنها را به صورت زنجیرهای برای استفاده از قراردادهای هوشمند ارسال میکند. با اوراکلها، میتوانید قراردادهای هوشمندی را طراحی کنید که با سیستمهای خارج از زنجیره، مانند بازارهای سرمایه، همکاری میکنند و کاربرد آنها را تا حد زیادی گسترش میدهند.
+
+اما اگر اوراکل خراب شود و اطلاعات نادرست را روی زنجیره ارسال کند، قراردادهای هوشمند بر اساس ورودیهای اشتباه اجرا میشوند که میتواند مشکلاتی را ایجاد کند. این اساس "مشکل اوراکل" است که به وظیفه اطمینان از دقیق، به روز و به موقع بودن اطلاعات یک اوراکل بلاک چین مربوط میشود.
+
+یک نگرانی امنیتی مرتبط، استفاده از یک اوراکل زنجیرهای، مانند یک صرافی غیرمتمرکز، برای دریافت قیمت ای یک دارایی است. پلتفرمهای وامدهی در صنعت [مالی غیرمتمرکز (DeFi)](/defi/) اغلب این کار را برای تعیین ارزش وثیقه کاربر انجام میدهند تا تعیین کنند چقدر میتوانند وام بگیرند.
+
+قیمتهای صرافیهای غیرمتمرکز اغلب دقیق هستند، که عمدتاً به دلیل بازیابی برابری توسط آربیتراژها در بازارها است. با این حال، آنها در معرض دستکاری هستند، به ویژه اگر اوراکل روی زنجیره قیمت داراییها را بر اساس الگوهای معاملاتی تاریخی محاسبه کند (همانطور که معمولاً اتفاق میافتد).
+
+به عنوان مثال، یک مهاجم میتواند بهطور مصنوعی قیمت نقدی یک دارایی را با گرفتن وام فوری یا همان فلش لون درست قبل از تعامل با قرارداد وام شما، افزایش دهد. پرس و جو از دکس برای قیمت دارایی، ارزشی بالاتر از حد معمول را به دست میآورد (به دلیل تقاضای انحرافی «سفارش خرید» مهاجم برای دارایی)، به آنها اجازه میدهد بیشتر از آنچه باید وام بگیرند. چنین "حملات وام فلش یا همان فلش لون" برای بهرهبرداری از اتکا به اوراکلهای قیمت در میان برنامههای کاربردی دیفای استفاده شده است که میلیونها وجوه از دست رفته پروتکلها ایجاد کرده است.
+
+##### چگونه از دستکاری اوراکل جلوگیری کنیم؟
+
+حداقل نیاز برای [جلوگیری از دستکاری اوراکل](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) استفاده از یک شبکه اوراکل غیرمتمرکز است که پرس و جو یا اطلاعات از چندین منبع برای جلوگیری از نقاط شکست کوئری میکند. در بیشتر موارد، اوراکلهای غیرمتمرکز دارای انگیزههای اقتصادی رمزارزی شدهاند تا نود یا گرههای اوراکل را تشویق کرده تا اطلاعات صحیح را گزارش کنند و آنها را از اوراکلهای متمرکز ایمنتر میکند.
+
+اگر قصد دارید از یک اوراکل زنجیرهای یا آنچین برای قیمت داراییها پرس و جو کنید، از یکی استفاده کنید که مکانیزم قیمت میانگین وزن شده با زمان (TWAP) را پیادهسازی میکند. یک [اوراکل TWAP](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) قیمت یک دارایی را در دو مقطع زمانی مختلف (که شما میتوانید اصلاح کنید) و قیمت لحظهای را بر اساس میانگین به دست آمده محاسبه میکند. انتخاب دورههای زمانی طولانیتر از پروتکل شما در برابر دستکاری قیمت محافظت میکند، زیرا سفارشهای بزرگی که اخیراً اجرا شدهاند نمیتوانند بر قیمت دارایی تأثیر بگذارند.
+
+## منابع امنیتی قرارداد هوشمند برای توسعهدهندگان {#smart-contract-security-resources-for-developers}
+
+### ابزارهایی برای تجزیه و تحلیل قراردادهای هوشمند و تأیید صحت کد {#code-analysis-tools}
+
+- **[ابزارها و کتابخانههای تست](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - < em x-id="4">مجموعه ای از ابزارها و کتابخانههای استاندارد صنعتی برای انجام تستهای واحد، تجزیه و تحلیل استاتیک و تجزیه و تحلیل پویا در قراردادهای هوشمند است
+
+- **[ابزارهای تأیید رسمی](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _ابزارهایی برای تأیید صحت عملکرد در قراردادهای هوشمند و بررسی متغیرها هستند._
+
+- **[خدمات حسابرسی قراردادهای هوشمند](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - < em x-id="4">فهرست هایی که خدمات حسابرسی قرارداد هوشمند برای پروژههای توسعه اتریوم ارائه میکنند.
+
+- **[پلتفرمهای پاداش باگ](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _پلتفرمهایی برای هماهنگی پاداشهای اشکال و پاداش افشای مسئولانه آسیبپذیریهای مهم در قراردادهای هوشمند هستند_
+
+- **[فورک چکر](https://forkchecker.hashex.org/)** - _رایگان بوده و ابزار آنلاین برای بررسی تمام اطلاعات موجود در مورد قرارداد منشعب شده است._
+
+- **[رمزگذار ABI](https://abi.hashex.org/)** - _یک رمزگذار رایگان سرویس آنلاین برای رمزگذاری توابع قرارداد سالیدیتی و آرگومانهای سازنده (constructor) شما است._
+
+- **[آدرین](https://github.com/Cyfrin/aderyn)** - _ تحلیلگر استاتیک سالیدیتی ، از درختان نحو انتزاعی (AST) عبور میکند تا آسیبپذیریهای مشکوک را مشخص کرده و مسائل را در قالب علامتگذاری آسان برای مصرف چاپ کند._
+
+### ابزارهای نظارت بر قراردادهای هوشمند {#smart-contract-monitoring-tools}
+
+- **[OpenZeppelin Defender Sentinels](https://docs.openzeppelin.com/defender/v1/sentinel)** - _ابزاری برای نظارت و پاسخگویی خودکار به رویدادها، عملکردها و پارامترهای تراکنش در قراردادهای هوشمند شما است._
+
+- **[هشدار همزمان با ملایمت](https://tenderly.co/alerting/)** - _ابزاری برای دریافت اعلانهای همزمان هنگامی که رویدادهای غیرمنتظره در قراردادهای هوشمند یا کیف پولهای شما اتفاق میافتد._
+
+### ابزارهایی برای مدیریت امن قراردادهای هوشمند {#smart-contract-administration-tools}
+
+- **[OpenZeppelin Defender Admin](https://docs.openzeppelin.com/defender/v1/admin)** - _رابطی برای مدیریت قراردادهای هوشمند، از جمله کنترلهای دسترسی، ارتقاء و توقف است._
+
+- **[ایمن](https://safe.global/)** - _کیف پول قرارداد هوشمند در حال اجرا اتریوم که به حداقل تعداد افراد نیاز دارد تا تراکنش را قبل از انجام آن تأیید کنند (M-of-N)._
+
+- **[قراردادهای اوپن زپلین](https://docs.openzeppelin.com/contracts/4.x/)** - _کتابخانهها را برای اجرای ویژگیهای اداری، از جمله مالکیت قرارداد، ارتقاء، کنترلهای دسترسی، حاکمیت، قابلیت توقف موقت و موارد دیگر مدیریت میکند._
+
+### خدمات حسابرسی قرارداد هوشمند {#smart-contract-auditing-services}
+
+- **[ConsenSys Diligence](https://consensys.net/diligence/)** - _خدمات آدیت قرارداد هوشمند که به پروژهها در سراسر اکوسیستم بلاک چین کمک میکند مطمئن شوند که پروتکلهای آنها برای راهاندازی آماده هستند و برای محافظت از کاربران ساخته شدهاند._
+
+- **[CertiK](https://www.certik.com/)** - _شرکت امنیت بلاک چین پیشگام در استفاده از فناوری تایید رسمی پیشرفته در قراردادهای هوشمند و شبکههای بلاک چین است._
+
+- **[رد بیت](https://www.trailofbits.com/)** - _امنیت سایبری شرکتی که تحقیقات امنیتی را با ذهنیت مهاجم برای کاهش ریسک و تقویت کد ترکیب میکند._
+
+- **[PeckShield](https://peckshield.com/)** - _شرکت امنیت بلاک چین که محصولات و خدماتی برای امنیت، حریم خصوصی و قابلیت استفاده کل اکوسیستم بلاک چین ارائه میکند._
+
+- **[QuantStamp](https://quantstamp.com/)** - _سرویس حسابرسی تسهیل کننده جریان اصلی پذیرش فناوری بلاک چین از طریق خدمات امنیت و ارزیابی ریسک است._
+
+- **[اوپن زپلین](https://www.openzeppelin.com/security-audits)** - _ شرکت امنیتی قرارداد هوشمند که حسابرسیهای امنیتی سیستمهای توزیع شده را ارائه میدهد._
+
+- **[تأیید زمان اجرا](https://runtimeverification.com/)** - _شرکت امنیتی متخصص در مدل سازی رسمی و تأیید قراردادهای هوشمند است_
+
+- **[هک](https://hacken.io)** - _حسابرس امنیت سایبری Web3 که ارائه دهنده 360 رویکرد درجه به امنیت بلاک چین است._
+
+- **[Nethermind](https://nethermind.io/smart-contracts-audits)** - _ خدمات حسابرسی سالیدیتی و کایرو، تضمین یکپارچگی قراردادهای هوشمند و ایمنی کاربران در سراسر اتریوم و استارک نت را ارائه میدهد._
+
+- **[HashEx](https://hashex.org/)** - _HashEx بر روی بلاکین و حسابرسی قراردادهای هوشمند برای اطمینان از امنیت ارزهای دیجیتال، ارائه خدماتی مانند توسعه قرارداد هوشمند، تست نفوذ، مشاوره بلاکچین تمرکز دارد. 2>
+
+- **[Code4rena](https://code4rena.com/)** - _پلتفرم حسابرسی رقابتی که کارشناسان امنیت قراردادهای هوشمند را تشویق میکند تا آسیبپذیریها را بیابند و به ایمنتر شدن Web3 کمک کنند._
+
+- **[CodeHawks](https://codehawks.com/)** - _پلتفرم حسابرسی رقابتی میزبان مسابقات حسابرسی قراردادهای هوشمند برای محققان امنیتی._
+
+- **[Cyfrin](https://cyfrin.io)** - _ نیروگاه امنیتی وب3، انکوباتور امنیت رمزارز از طریق محصولات و خدمات حسابرسی قرارداد هوشمند._
+
+- **[ImmuneBytes](https://www.immunebytes.com//smart-contract-audit/)** - _شرکت امنیتی وب3 که ممیزی های امنیتی سیستم های بلاکچین را از طریق تیمی از حسابرسان مجرب و بهترین ابزارها ارائه می کند._
+
+- **[Oxorio](https://oxor.io/)** - _ممیزی قراردادهای هوشمند و خدمات امنیتی بلاکین با تخصص در EVM، سالیدیتی، ZK، فناوری زنجیرهای متقابل برای شرکتهای رمزنگاری و پروژههای دیفای._
+
+- **[Inference](https://inference.ag/)** - _شرکت حسابرسی امنیتی، متخصص در حسابرسی قراردادهای هوشمند برای بلاکچینهای مبتنی بر EVM. با تشکر از حسابرسان متخصص آن، آنها مشکلات بالقوه را شناسایی کرده و راهحلهای عملی را برای رفع آنها قبل از استقرار پیشنهاد میکنند._
+
+### پلتفرمهای باگبانتی {#bug-bounty-platforms}
+
+- **[Immunefi](https://immunefi.com/)** - _پلتفرم باگبانتی برای قراردادهای هوشمند و پروژههای دیفای، که در آن محققان امنیتی کد را بررسی میکنند، آسیبپذیریها را فاش میکنند، پاداش دریافت میکنند و دنیای رمزارز را ایمنتر میکنند._
+
+- **[HackerOne](https://www.hackerone.com/)** - _پلتفرم هماهنگی آسیبپذیری و باگبانتی که کسبوکارها را با کارشناسان تست نفوذ و محققان امنیت سایبری مرتبط میکند._
+
+- **[HackenProof](https://hackenproof.com/)** - _پلتفرم باگبانتی متخصص برای پروژههای رمزارزی (دیفای، قراردادهای هوشمند، کیف پولها، CEX و موارد دیگر)، جایی که متخصصان امنیتی خدمات تریاژ را ارائه می دهند و محققان برای گزارش های مربوط به باگ هایتأیید شده پاداش دریافت می کنند._
+
+- **[Sherlock](https://www.sherlock.xyz/)** - _ عریضهنویس در وب3 برای امنیت قراردادهای هوشمند، با پرداختهایی برای حسابرسان که از طریق قراردادهای هوشمند مدیریت میشوند تا از پرداخت عادلانه باگ های مربوطه اطمینان حاصل شود._
+
+- **[CodeHawks](https://www.codehawks.com/)** - _پلتفرم باگبانتی رقابتی که در آن حسابرسان در مسابقات و چالشهای امنیتی و (به زودی) در ممیزیهای خصوصی خودشان شرکت میکنند._
+
+### رسانه های آسیب پذیری ها و اکسپلویت های شناخته شده قرارداد هوشمند {#common-smart-contract-vulnerabilities-and-exploits}
+
+- قماله **[کانسنسیس: حملات شناخته شده قرارداد هوشمند](https://consensys.github.io/smart-contract-best-practices/attacks/)** - _توضیحات مبتدی مهم ترین آسیب پذیری های قرارداد، با کد نمونه برای اکثر موارد._
+
+- **[SWC Registry](https://swcregistry.io/)** - _فهرست تنظیمشده از موارد سرشماری ضعف مشترک (CWE) که در قراردادهای هوشمند اتریوم اعمال میشود._
+
+- **[Rekt](https://rekt.news/)** - _ انتشار منظم هکها و سوء استفادههای رمزنگاری با مشخصات بالا، همراه با کالبدشکافی._
+
+### چالشهای یادگیری امنیت قراردادهای هوشمند {#challenges-for-learning-smart-contract-security}
+
+- **[Awesome BlockSec CTF ](https://github.com/blockthreat/blocksec-ctfs)** - _فهرست تنظیمشده بازیهای امنیتی بلاکچین، چالشها و مسابقات [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) و نوشتههای راهحل._
+
+- **[DeFi آسیب پذیر لعنتی](https://www.damnvulnerabledefi.xyz/)** - _بازی برای یادگیری امنیت تهاجمی قراردادهای هوشمند دیفای و ایجاد مهارت در شکار باگ و ممیزی امنیتی._
+
+- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _بازی جنگی مبتنی بر وب3/سالیدیتی که در آن هر سطح یک قرارداد هوشمند است که باید "هک" شود._
+
+- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _چالش هک قرارداد هوشمند، در یک ماجراجویی فانتزی. تکمیل موفقیتآمیز چالش به یک برنامه باگبانتی خصوصی نیز دسترسی پیدا میکند._
+
+### بهترین روش ها برای ایمن سازی قراردادهای هوشمند {#smart-contract-security-best-practices}
+
+- **[کانسنسیس: بهترین روشهای امنیتی قراردادهای هوشمند اتریوم](https://consensys.github.io/smart-contract-best-practices/)** - _فهرست جامع دستورالعملها برای ایمن کردن قراردادهای هوشمند اتریوم._
+
+- **[Nascent: ابزار ساده امنیتی](https://github.com/nascentxyz/simple-security-toolkit)** - _مجموعه راهنماها و چک لیست های عملی مبتنی بر امنیت برای توسعه قراردادهای هوشمند._
+
+- **[Solidity Patterns](https://fravoll.github.io/solidity-patterns/)** - _تلفیقی مفید از الگوهای امن و بهترین شیوه ها برای زبان برنامه نویسی قرارداد هوشمند سالیدیتی._
+
+- **[اسناد سالیدیتی: ملاحظات امنیتی](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _دستورالعملهایی برای نوشتن قراردادهای هوشمند ایمن با سالیدیتی._
+
+- **[استاندارد تأیید امنیت قراردادهای هوشمند](https://github.com/securing/SCSVS)** - _چک لیست چهارده قسمتی ایجاد شده برای استانداردسازی امنیت قراردادهای هوشمند برای توسعه دهندگان، معماران، بازبینان امنیتی و فروشندگان._
+
+- **[امنیت و حسابرسی قرارداد هوشمند را بیاموزید](https://updraft.cyfrin.io/courses/security) - _دوره ممیزی و امنیت قراردادهای هوشمند نهایی، ایجاد شده برای توسعه دهندگان قراردادهای هوشمند که به دنبال ارتقای بهترین شیوه های امنیتی خود و تبدیل شدن به محققین امنیتی هستند._
+
+### آموزش امنیت قراردادهای هوشمند {#tutorials-on-smart-contract-security}
+
+- [نحوه نوشتن قراردادهای هوشمند امن](/developers/tutorials/secure-development-workflow/)
+
+- [نحوه استفاده از Slither برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+
+- [نحوه استفاده از Manticore برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+
+- [راهنمای امنیتی قراردادهای هوشمند](/developers/tutorials/smart-contract-security-guidelines/)
+
+- [چگونه به طور ایمن قرارداد توکن خود را با توکنهای دلخواه ادغام کنیم](/developers/tutorials/token-integration-checklist/)
+
+- [Cyfrin Updraft - امنیت قراردادهای هوشمند و دوره کامل ممیزی](https://updraft.cyfrin.io/courses/security)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
new file mode 100644
index 00000000000..3e0b74870d6
--- /dev/null
+++ "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
@@ -0,0 +1,76 @@
+---
+title: ترکیب پذیری قراردادهای هوشمند
+description:
+lang: fa
+incomplete: true
+---
+
+## معرفی مختصر {#a-brief-introduction}
+
+قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. برای تبدیل شدن به یک توسعه دهنده dapp نیازی به نوشتن قرارداد هوشمند خود ندارید، فقط باید بدانید که چگونه با آنها تعامل داشته باشید. برای مثال، میتوانید از قراردادهای هوشمند موجود در [Uniswap](https://uniswap.exchange/swap)، یک صرافی غیرمتمرکز، برای مدیریت همه منطق مبادله توکن ها در برنامه خود استفاده کنید - لازم نیست از صفر شروع کنید. برخی از قراردادهای [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) و v3 را بررسی کنید.
+
+## ترکیبپذیری چیست؟ {#what-is-composability}
+
+ترکیب پذیری به معنای ترکیب کامپوننت های مجزا، با یکدیگر، به منظور ساخت یک سیستم و یا خروجی جدید می باشد. در توسعه نرمافزار، مبحث ترکیب پذیری به این معناست که توسعه دهنده می توانند با استفاده مجدد از کامپوننت های نرم افزاری موجود، یک اپلیکیشن جدید مد نظر خود را بسازند. یک راه خوب برای درک ترکیب پذیری این است که قطعات ترکیب پذیر را به صور قطعات لگو در نظر بگیریم. هر یک از قطعات لگو، می تواند با سایر قطعات تلفیق شده و با این تلفیق هایی که انجام میشود، قابلیت ساخت سازه های پیچیده ای را فراهم کند.
+
+در اتریوم، قراردادهای هوشمند را میتوان به نوعی مشابه یک پازل یا لگو داست که می توانید با کنار هم قراردادن پروژه های مختلف در قرارداد هوشمندتان، پروژه خود را بسازید. این موضوع به این معناست که نیاز نیست چرخ را دوباره اختراع کنید و یا ساخت پروژه خود را از صفر شروع کنید.
+
+## ترکیب پذیری چگونه عمل میکند؟ {#how-does-composability-work}
+
+قراردادهای هوشمند اتریومی، مشابه API های عمومی هستند که هر کسی می تواند با آنها ارتباط برقرار کرده و یا اپلیکیشن غیر متمرکز خود را با ویژگی های مد نظر، با آن تطبیق داده و یکپارچه کند. به عبارت کلی در خصوص ترکیب پذیری در قراردادهای هوشمند میتوان به سه اصل اساسی و مهم اشاره کرد: ماژولاریتی، خود اجرا بودن، و قابلیت دسترسی:
+
+**1. ماژولاریتی**: به معنای ویژگی هر کامپوننت برای انجام یک عملیات خاص و مشخص می باشد. هر کدام از قراردادهای هوشمند در اتریوم، یک مورد استفاده مخصوص به خود دارد. (همانطور که در مثال Uniswap نمایش داده شده است).
+
+**2. استقلال یا خوداجرایی**: کامپوننت هایی که قابل ترکیب هستند باید بتوانند به صورت مجزا از یکدیگر عمل کنند. هر قرارداد هوشمند در اتریوم، به صورت خودمختار اجرا میشود و میتواند بدون نیاز به بقیه المان های سیستم کار کند.
+
+**3. قابلیت دسترسی**: در صورتی که کتابخانه ها و یا قراردادهای هوشمندی که توسعه دهنده ها بخواهند از آنها در اپلیکیشن های خود استفاده کنند، به صورت عمومی در دسترس نباشند، توسعه دهنده ها نمیتوانند آنها را فراخوانی کرده و از آنها استفاده کنند. با توجه به نوع طراحی پیش فرض در شبکه اتریوم، قراردادهای هوشمند کد باز بوده و هر کسی میتواند این قراردادها را فراخوانی و استفاده نموده و یا کدهای مورد نظر خود را از یک مخزن منشعب نموده و از آن استفاده کند.
+
+## مزایای ترکیب پذیری {#benefits-of-composability}
+
+### چرخه توسعه کوتاه تر {#shorter-development-cycle}
+
+در زمان تولید [اپلیکیشن های غیرمتمرکز](/dapps/#what-are-dapps) (یا dapp ها) ترکیب پذیری می تواند باعث کاهش حجم کار توسعه دهنده های نرمافزار شود. [همانطور که Naval Ravikant می گوید: ](https://twitter.com/naval/status/1444366754650656770) "متن باز یعنی هر مشکلی فقط باید یکبار حل شود."
+
+اگر یک قرارداد هوشمند میتواند یک مشکل را حل کند، سایر توسعه دهنده ها می توانند از آن استفاده کنند و نیازی نیست که یک مشکل یکسان را دوباره حل کنند. بدین ترتیب توسعه دهنده ها میتوانند با استفاده از کتابخانه های موجود و اضافه کردن قابلیت های اضافی به آنها، اپلیکیشن های غیر متمرکز جدیدی را بسازند.
+
+### نوآوری بیشتر {#greater-innovation}
+
+ترکیب پذیری، مشوقی برای نوآوری و تجربه های بیشتر است، به این خاطر که توسعه دهنده ها می توانند به راحتی و آزادانه از کدهای موجود استفاده مجدد کنند، آنها را تغییر دهند، کپی کنند، و یا به هر ترتیب دیگری جهت رسیدن به نتیجه مطلوب خود بهره ببرند. در نتیجه، تیم های نرم افزاری زمان کمتری را برای پیادهسازی قابلیت های ابتدایی و ساده سپری خواهند کرد و میتوانند زمان خود را صرف ویژگی های بهتر و تجربه موارد جدیدتر کنند.
+
+### تجربه کاربری بهتر {#better-user-experience}
+
+ارتباط بین کامپوننت ها در اکوسیستم اتریوم باعث افزایش تجربه کاربری می شود. در اکوسیستمی که اپلیکیشن های غیرمتمرکز با سایر قراردادهای هوشمند مورد نیاز یکپارچه شده باشند، دست کاربر برای دسترسی به امکانات و قابلیت های بیشتر، نسبت به زمانی که در یک اکوسیستم، اپلیکیشن ها نتوانند با یکدیگر ارتباط برقرار کنند، بازتر است.
+
+به منظور نمایش مزایای قابلیت های ارتباط گیری بین اجزای مختلف، مثالی از یک آربیتراژ را استفاده خواهیم کرد:
+
+اگر توکنی در `صرافی A` قیمتی بیش از `صرافی B` داشته باشد، از این تفاوت قیمت میتوان برای کسب سود استفاده کرد. با این حال، تنها در زمانی میتوانید این کار رانجام دهید که سرمایه لازم برای اجرای تراکنش مورد نیاز را داشته باشید ( خرید توکن از `صرافی B` و فروش در `صرافی A`).
+
+در زمانی که سرمایه لازم برای انجام این ترید را نداشته باشید، استفاده از وام سریع یا همان flash loan گزینه ای ایده آل به حساب می آید. [وام های سریع](/defi/#flash-loans) مفهومی بسیار تکنیکال دارند، اما اگر بخواهیم به صورت ساده بگوئیم، ایده کلی به این صورت است که بدون نیاز به هیچ گونه گروگذاری یا داشتن سرمایه اولیه، می توان دارایی مورد نظر را قرض گرفت و البته که باید بازگشت وام، <0>در همان تراکنش0> صورت بگیرد.
+
+به مثال ابتدایی خود بر میگردیم، یک تریدر آربیتراژ می تواند با دریافت حجم زیادی وام سریع، توکن ها را از `صرافی B` خریده، آنها را در `صرافی A` بفروشد، وام گرفته شده را به همراه بهره آن بپردازد، و در نهایت سود باقیمانده را برای خود نگه دارد، و همه این اتفاقات تنها در همان یک تراکنش رخ می دهد. این منطق پیچیده نیاز به فراخوانی و استفاده ترکیبی از چندین قرارداد مختلف دارد، که در صورت نبود قابلیت ارتباط گیری بین قراردادهای هوشمند، امکانپذیر نبود.
+
+## مثالهایی از ترکیب پذیری در اتریوم {#composability-in-ethereum}
+
+### معاوضه توکنها {#token-swaps}
+
+اگر اپلیکیشن غیر متمرکزی بسازید که نیازمند پرداخت به تراکنش ها با اتر باشد، میتوانید از طریق یکپارچه سازی آن با منطق معاوضه توکن ها، قابلیت پرداخت با سایر توکن های ERC20 را برای کاربران فراهم کنید. این کد، پیش از اینکه تابع مورد نظر را اجرا کند، توکن کاربر را به صورت خودکار به اتر (ETH) تبدیل میکند.
+
+### حکومت {#governance}
+
+ساخت یک سیستم حاکمیتی سفارشی برای یک [DAO](/dao/) می تواند بسیار هزینه و زمان بر باشد. به جای آن، می توانید از یک تولکیت یا مجموعه ابزار متن باز حاکمیتی، مثل [Aragon Client](https://client.aragon.org/) استفاده کنید تا DAO خود را گسترش داده و به سرعت هر چه تمامتر یک چارچوب حاکمیتی بسازید.
+
+### مدیریت هویت {#identity-management}
+
+به جای ساختن یک سیستم احراز هویت و یا تکیه بر سرویس دهنده های متمرکز، می توانید ابزارهای هویت غیرمتمرکز (DID) را برای مدیریت احراز هویت کاربران با سیستم خود یکپارچه سازی و استفاده کنید. نمونه ای از این ابزارها، [SpruceID](https://www.spruceid.com/) است که قابلیت "ورود با اتریوم" را ارئه میدهد که با استفاده از آن کاربران میتوانند عملیات احراز هویت خود را با کیف پول اتریومی انجام دهند.
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [رابط کاربری اپلیکیشن غیرمتمرکز خود را به سرعت با create-eth-app ایجاد کنید](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/)_- نمای کلی نحوه استفاده از create-eth-app برای ساخت اپلیکیشن ها که قراردادهای هوشمند نیز در آنها قابل استفاده هستند._
+
+## اطلاعات بیشتر {#further-reading}
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
+
+- [ترکیب پذیری، نوآوری است](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/)
+- [علت اهمیت ترکیب پذیری برای Web3](https://hackernoon.com/why-composability-matters-for-web3)
+- [ترکیب پذیری چیست؟](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
new file mode 100644
index 00000000000..ac046a229b2
--- /dev/null
+++ "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
@@ -0,0 +1,310 @@
+---
+title: تایید رسمی قراردادهای هوشمند
+description: مروری بر تایید رسمی قراردادهای هوشمند اتریوم
+lang: fa
+---
+
+[قراردادهای هوشمند](/developers/docs/smart-contracts/) امکان ایجاد برنامههای غیرمتمرکز، بدون نیاز به اعتماد و قوی را فراهم میکنند که موارد استفاده جدیدی را معرفی کرده و ارزش را برای کاربران آزاد میکنند. از آنجایی که قراردادهای هوشمند مقادیر زیادی از ارزش را مدیریت میکنند، امنیت یک ملاحظهی حیاتی برای توسعهدهندگان است.
+
+تأیید رسمی یکی از تکنیک های توصیه شده برای بهبود [امنیت قرارداد هوشمند](/developers/docs/smart-contracts/security/) است. تأیید رسمی، که از [روشهای رسمی](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) برای تعیین، طراحی و تأیید برنامهها استفاده میکند، سالهاست که برای اطمینان از صحت سیستمهای سختافزاری و نرمافزاری حیاتی استفاده میشود.
+
+هنگامی که در قراردادهای هوشمند پیادهسازی می شود، تأیید رسمی می تواند ثابت کند که منطق تجاری یک قرارداد با مشخصات از پیش تعریف شده مطابقت دارد. در مقایسه با روشهای دیگر برای ارزیابی صحت کد قرارداد، مانند آزمایش، تأیید رسمی تضمینهای قویتری برای صحیح بودن قرارداد هوشمند میدهد.
+
+## تایید رسمی چیست؟ {#what-is-formal-verification}
+
+تأیید رسمی به فرآیند ارزیابی صحت یک سیستم با توجه به مشخصات رسمی اشاره دارد. به عبارت سادهتر، تأیید رسمی به ما امکان می دهد بررسی کنیم که آیا رفتار یک سیستم برخی از الزامات را برآورده می کند (یعنی آنچه را که ما می خواهیم انجام می دهد).
+
+رفتارهای مورد انتظار سیستم (در این مورد یک قرارداد هوشمند) با استفاده از مدلسازی رسمی توصیف میشوند، در حالی که زبانهای مشخصات امکان ایجاد خواص رسمی را فراهم میکنند. سپس تکنیکهای تأیید رسمی میتوانند تأیید کنند که اجرای یک قرارداد با مشخصات آن مطابقت دارد و اثبات ریاضی صحت قرارداد اول را به دست میآورد. زمانی که یک قرارداد با مشخصات خود مطابقت داشته باشد، به عنوان "صحیح عملکردی"، "درست بر اساس طراحی" یا "درست بر اساس ساخت" توصیف می شود.
+
+### مدل رسمی چیست؟ {#what-is-a-formal-model}
+
+در علوم کامپیوتر، [مدل رسمی](https://en.wikipedia.org/wiki/Model_of_computation) توصیفی ریاضی از یک فرآیند محاسباتی است. برنامهها به توابع ریاضی (معادلات) انتزاعی میشوند، و مدل نحوه محاسبه خروجیهای توابع را با توجه به ورودی توصیف میکند.
+
+مدلهای رسمی سطحی از انتزاع را فراهم میکنند که در آن تحلیل رفتار یک برنامه قابل ارزیابی است. وجود مدلهای رسمی امکان ایجاد یک _مشخصات رسمی_ را فراهم میکند که ویژگیهای مورد نظر مدل مورد نظر را توصیف میکند.
+
+تکنیکهای مختلفی برای مدلسازی قراردادهای هوشمند برای تأیید رسمی استفاده میشود. به عنوان مثال، برخی از مدل ها برای استدلال در مورد رفتار سطح بالای یک قرارداد هوشمند استفاده می شوند. این تکنیکهای مدلسازی یک نمای جعبه سیاه را برای قراردادهای هوشمند اعمال میکنند و آنها را به عنوان سیستمهایی میبینند که ورودیها را میپذیرند و محاسبات را بر اساس آن ورودیها اجرا میکنند.
+
+مدلهای سطح بالا بر رابطه بین قراردادهای هوشمند و عوامل خارجی، مانند حسابهای تحت مالکیت خارجی (EOAs)، حسابهای قراردادی و محیط بلاک چین تمرکز دارند. چنین مدل هایی برای تعریف ویژگی هایی مفید هستند که مشخص می کنند یک قرارداد چگونه باید در پاسخ به تعاملات خاص کاربر رفتار کند.
+
+برعکس، سایر مدلهای رسمی بر رفتار سطح پایین قرارداد هوشمند تمرکز دارند. در حالی که مدلهای سطح بالا میتوانند به استدلال در مورد عملکرد قرارداد کمک کنند، ممکن است نتوانند جزئیات مربوط به عملکرد داخلی پیادهسازی را ثبت کنند. مدلهای سطح پایین از نمای جعبه سفید برای تجزیه و تحلیل برنامه استفاده میکنند و برای استدلال در مورد ویژگیهای مربوط به اجرای قرارداد، به نمایشهای سطح پایینتر برنامههای قرارداد هوشمند، مانند ردیابی برنامه و [گرافهای جریان کنترل](https://en.wikipedia.org/wiki/Control-flow_graph) تکیه میکنند.
+
+مدلهای سطح پایین ایدهآل در نظر گرفته میشوند زیرا نشاندهنده اجرای واقعی یک قرارداد هوشمند در محیط اجرای اتریوم هستند (یعنی [EVM](/developers/docs/evm/)). تکنیکهای مدلسازی سطح پایین بهویژه در ایجاد ویژگیهای ایمنی حیاتی در قراردادهای هوشمند و شناسایی آسیبپذیریهای بالقوه مفید هستند.
+
+### مشخصات رسمی چیست؟ {#what-is-a-formal-specification}
+
+یک مشخصات به سادگی یک الزام فنی است که یک سیستم خاص باید برآورده کند. در برنامه نویسی، مشخصات، ایده های کلی در مورد اجرای یک برنامه (یعنی آنچه برنامه باید انجام دهد) را نشان می دهد.
+
+در زمینه قراردادهای هوشمند، مشخصات رسمی به _ویژگیها_ اشاره میکند—توضیحات رسمی الزاماتی که یک قرارداد باید برآورده کند. چنین ویژگی هایی به عنوان "غیر متغیر" توصیف می شوند و بیانگر ادعاهای منطقی در مورد اجرای یک قرارداد هستند که باید تحت هر شرایط ممکن، بدون هیچ استثنایی صادق باقی بماند.
+
+بنابراین، ما می توانیم مشخصات رسمی را به عنوان مجموعه ای از اظهارات نوشته شده به زبان رسمی در نظر بگیریم که اجرای مورد نظر یک قرارداد هوشمند را توصیف می کند. مشخصات، ویژگی های قرارداد را پوشش می دهد و نحوه رفتار قرارداد را در شرایط مختلف تعریف می کند. هدف از تأیید رسمی این است که مشخص شود آیا قرارداد هوشمند دارای این ویژگیها (غیر متغیرها) است یا خیر و اینکه این ویژگیها در طول اجرا نقض نمیشوند.
+
+مشخصات رسمی در توسعه پیادهسازی ایمن قراردادهای هوشمند حیاتی هستند. قراردادهایی که در اجرای خود موفق به پیادهسازی ثابتها نمیشوند یا خواص آنها نقض میشود، مستعد آسیبپذیریهایی هستند که میتوانند به عملکرد آسیب برسانند یا باعث سوء استفادههای مخرب شوند.
+
+## انواع مشخصات رسمی قراردادهای هوشمند {#formal-specifications-for-smart-contracts}
+
+مشخصات رسمی استدلال ریاضی در مورد صحت اجرای برنامه را امکانپذیر می کند. همانند مدلهای رسمی، مشخصات رسمی میتوانند ویژگیهای سطح بالا یا رفتار سطح پایین اجرای قرارداد را نشان دهند.
+
+مشخصات رسمی با استفاده از عناصر [منطق برنامه](https://en.wikipedia.org/wiki/Logic_programming) به دست میآیند که امکان استدلال رسمی در مورد ویژگیهای یک برنامه را فراهم میکند. یک منطق برنامه دارای قوانین رسمی است که رفتار مورد انتظار یک برنامه را (به زبان ریاضی) بیان میکند. منطق برنامه های مختلف در ایجاد مشخصات رسمی استفاده می شود، از جمله [منطق دسترسی پذیری](https://en.wikipedia.org/wiki/Reachability_problem)، [منطق زمانی](https://en.wikipedia.org/wiki/Temporal_logic)، و [منطق هوآر](https://en.wikipedia.org/wiki/Hoare_logic).
+
+مشخصات رسمی قراردادهای هوشمند را می توان به طور کلی به عنوان مشخصات **سطح بالا** یا **سطح پایین** طبقه بندی کرد. صرف نظر از اینکه یک مشخصات به چه دسته ای تعلق دارد، باید به طور کافی و بدون ابهام ویژگی سیستم مورد تجزیه و تحلیل را توصیف کند.
+
+### مشخصات سطح بالا {#high-level-specifications}
+
+همانطور که از نام آن پیداست، یک مشخصات سطح بالا (که "مشخصات مدل گرا" نیز نامیده می شود) رفتار سطح بالای یک برنامه را توصیف می کند. مشخصات سطح بالا یک قرارداد هوشمند را به عنوان یک [ماشین حالت متناهی](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) مدلسازی میکند که میتواند با انجام عملیات بین حالتها جابهجا شود، و از منطق زمانی برای تعریف خواص رسمی برای مدل FSM استفاده میشود.
+
+[منطقهای زمانی](https://en.wikipedia.org/wiki/Temporal_logic) "قوانینی برای استدلال درباره گزارههایی هستند که از نظر زمانی واجد شرایط هستند (مثلاً "من _همیشه_ گرسنه هستم" یا "من _در نهایت_ گرسنه خواهم شد.")" هنگامی که برای تأیید رسمی اعمال می شود، از منطق های زمانی برای بیان ادعاهای مربوط به رفتار صحیح سیستم های مدل سازی شده به عنوان ماشین های حالت استفاده می شود. به طور خاص، یک منطق زمانی وضعیتهای آیندهای را که یک قرارداد هوشمند میتواند در آن قرار گیرد و نحوه انتقال آن بین حالتها را توصیف میکند.
+
+مشخصات سطح بالا به طور کلی دو ویژگی مهم زمانی را برای قراردادهای هوشمند نشان می دهد: **ایمنی** و **زندهمانی**. ویژگی های ایمنی بیانگر این ایده است که "هیچ چیز بدی اتفاق نمی افتد" و معمولاً بیانگر تغییر ناپذیری است. یک ویژگی ایمنی ممکن است الزامات کلی نرمافزار را تعریف کند، مانند آزادی از [قفل شدن](https://www.techtarget.com/whatis/definition/deadlock)، یا خواص خاص دامنه را برای قراردادها بیان کند (به عنوان مثال، ثابتهای کنترل دسترسی برای توابع، مقادیر مجاز متغیرهای حالت یا شرایط برای انتقال توکن).
+
+به عنوان مثال این الزام ایمنی را در نظر بگیرید که شرایط استفاده از `transfer()` یا `transferFrom()` در قراردادهای توکن ERC-20 را پوشش می دهد: _"باقیمانده حساب فرستنده هرگز کمتر از مقدار درخواستی توکنهای ارسال شده نیست."_. این توصیف به زبان طبیعی از یک قرارداد ثابت را می توان به یک مشخصات رسمی (ریاضی) ترجمه کرد، که سپس می توان آن را به شدت از نظر اعتبار بررسی کرد.
+
+خواص زنده بودن تأکید میکنند که "بالاخره اتفاق خوبی میافتد" و مربوط به توانایی یک قرارداد برای پیشرفت از طریق حالات مختلف است. یک مثال از ویژگی زنده بودن "نقدینگی" است که به توانایی یک قرارداد برای انتقال موجودی خود به کاربران در صورت درخواست اشاره دارد. اگر این ویژگی نقض شود، کاربران نمیتوانند داراییهای ذخیرهشده در قرارداد را برداشت کنند، مانند آنچه در [حادثه کیف پول Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) اتفاق افتاد.
+
+### مشخصات سطح پایین {#low-level-specifications}
+
+مشخصات سطح بالا به عنوان نقطه شروع یک مدل حالت محدود از یک قرارداد را در نظر گرفته و ویژگی های مورد نظر این مدل را تعریف می کند. در مقابل، مشخصات سطح پایین (که همچنین به عنوان "مشخصات گرا به ویژگی" شناخته میشوند) اغلب برنامهها (قراردادهای هوشمند) را به عنوان سیستمهایی متشکل از مجموعهای از توابع ریاضی مدلسازی میکنند و رفتار صحیح چنین سیستمهایی را توصیف میکنند.
+
+به عبارت سادهتر، مشخصات سطح پایین _ردهای برنامه_ را تجزیه و تحلیل می کنند و سعی می کنند ویژگی های یک قرارداد هوشمند را بر روی این ردیابی ها تعریف کنند. ردیابیها به توالیهای اجرای توابع اشاره دارند که حالت یک قرارداد هوشمند را تغییر میدهند؛ از این رو، مشخصات سطح پایین به مشخص کردن الزامات برای اجرای داخلی یک قرارداد کمک میکنند.
+
+مشخصات رسمی سطح پایین را می توان به عنوان ویژگی های سبک هوآر یا به صورت ثابت در مسیرهای اجرا ارائه کرد.
+
+### خواص سبک هوآر {#hoare-style-properties}
+
+[منطق هوآر](https://en.wikipedia.org/wiki/Hoare_logic) مجموعهای از قوانین رسمی را برای استدلال در مورد صحت برنامهها، از جمله قراردادهای هوشمند، ارائه میکند. یک ویژگی به سبک هوآر با یک سهگانه هوآر {_P_}_c_{_Q_} نشان داده میشود، که در آن _c_ یک برنامه است و _P_ و _Q_ گزارههایی در مورد حالت c (یعنی برنامه) هستند که به ترتیب به صورت _پیش شرطها_ و _پس شرطها_ توصیف میشوند.
+
+پیش شرط یک گزاره است که شرایط لازم برای اجرای صحیح یک تابع را توصیف می کند. کاربرانی که قرارداد را امضا می کنند باید این شرط را برآورده کنند. پیش شرط یک گزاره است که شرایط لازم برای اجرای صحیح یک تابع را توصیف می کند. کاربرانی که قرارداد را امضا کنند باید این شرط را تعیین کنند. یک _ثابت_ در منطق هوآر یک گزاره است که توسط اجرای یک تابع حفظ میشود (یعنی تغییر نمیکند).
+
+مشخصات سبک هوآر می تواند _صحت جزئی_ یا _صحت کامل_ را تضمین کند. اگر پیش شرط قبل از اجرای تابع صادق باشد، اجرای یک تابع قرارداد "تا حدی صحیح" است، و اگر اجرا خاتمه یابد، پس شرط نیز صادق است. اگر یک پیش شرط قبل از اجرای تابع درست باشد، اثبات صحت کلی به دست میآید، اجرا تضمین میشود که پایان یابد و زمانی که انجام شد، شرط پسشرط صادق است.
+
+کسب اثبات صحت کامل دشوار است زیرا برخی از اجراها ممکن است قبل از خاتمه به تأخیر بیفتند یا اصلاً هرگز خاتمه نیابند. با این حال، این سؤال که آیا اجرا خاتمه مییابد یا خیر، قابل بحث است، زیرا مکانیسم گس اتریوم از حلقههای بینهایت برنامه جلوگیری میکند (اجرا یا با موفقیت خاتمه مییابد یا به دلیل خطای "تمام شدن گس" پایان مییابد).
+
+مشخصات قرارداد هوشمند ایجاد شده با استفاده از منطق هوآر دارای پیششرطها، پسشرطها و متغیرهایی هستند که برای اجرای توابع و حلقهها در یک قرارداد تعریف شدهاند. پیششرطها اغلب شامل امکان ورودیهای اشتباه به یک تابع هستند، با شرایط پسشرطی که پاسخ مورد انتظار به این ورودیها را توصیف میکنند (به عنوان مثال، ایجاد یک استثنا خاص). به این ترتیب ویژگی های سبک هوآر برای اطمینان از صحت اجرای قرارداد مؤثر است.
+
+بسیاری از چارچوبهای تأیید رسمی از مشخصات سبک هوآر برای اثبات صحت معنایی توابع استفاده میکنند. همچنین میتوان خواص به سبک هوآر (به عنوان ادعاها) را به طور مستقیم با استفاده از عبارات `require` و `assert` در سالیدیتی به کد قرارداد اضافه کرد.
+
+عبارات `require` بیانگر یک پیش شرط یا ثابت هستند و اغلب برای اعتبارسنجی ورودی های کاربر استفاده می شوند، در حالی که `assert` یک شرط پسین لازم برای ایمنی را نشان می دهد. به عنوان مثال، کنترل دسترسی مناسب برای توابع (مثالی از یک ویژگی ایمنی) را میتوان با استفاده از `require` به عنوان یک بررسی پیش شرط بر روی هویت حساب فراخوانی کننده به دستآورد. به طور مشابه، یک ثابت بر روی مقادیر مجاز متغیرهای حالت در یک قرارداد (به عنوان مثال، کل تعداد توکنهای در گردش) را میتوان از نقض با استفاده از `assert` برای تأیید وضعیت قرارداد پس از اجرای تابع محافظت کرد.
+
+### ویژگیهای سطح ردیابی {#trace-level-properties}
+
+مشخصات مبتنی بر ردیابی عملیاتهایی را توصیف میکنند که یک قرارداد را بین حالتهای مختلف انتقال میدهند و روابط بین این عملیاتها را مشخص میکنند. همانطور که قبلا توضیح داده شد، ردیابی ها دنباله ای از عملیات هستند که وضعیت یک قرارداد را به روشی خاص تغییر می دهند.
+
+این رویکرد بر مدل قراردادهای هوشمند به عنوان سیستمهای انتقال حالت با برخی حالتهای از پیش تعریفشده (توصیفشده توسط متغیرهای حالت) به همراه مجموعهای از انتقالهای از پیش تعریفشده (توصیفشده توسط توابع قرارداد) متکی است. علاوه بر این، یک [گراف جریان کنترل](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG)، که یک نمایش گرافیکی از جریان اجرای یک برنامه است، اغلب برای توصیف معنایی عملیاتی یک قرارداد استفاده میشود. در اینجا، هر ردیابی به عنوان یک مسیر در نمودار جریان کنترل نشان داده می شود.
+
+در درجه اول، مشخصات سطح ردیابی برای استدلال در مورد الگوهای اجرای داخلی در قراردادهای هوشمند استفاده می شود. با ایجاد مشخصات سطح ردیابی، ما مسیرهای اجرایی قابل قبول (به عنوان مثال، انتقال حالت) را برای یک قرارداد هوشمند اعلام می کنیم. با استفاده از تکنیک هایی مانند اجرای نمادین، می توانیم به طور رسمی تأیید کنیم که اجرا هرگز از مسیری پیروی نمی کند که در مدل رسمی تعریف نشده است.
+
+بیایید از نمونه ای از قرارداد [DAO](/dao/) استفاده کنیم که دارای برخی از توابع در دسترس عموم برای توصیف ویژگی های سطح ردیابی است. در اینجا، ما فرض می کنیم که قرارداد DAO به کاربران اجازه می دهد تا عملیات زیر را انجام دهند:
+
+- واریز وجه
+
+- رای دادن به یک پیشنهاد پس از واریز وجوه
+
+- درخواست بازپرداخت در صورت عدم رای دادن به یک پیشنهاد
+
+نمونهای از ویژگیهای سطح ردیابی میتواند _"کاربرانی که وجوهی را واریز نمیکنند نمیتوانند به پیشنهادی رای دهند"_ یا _"کاربرانی که به پیشنهادی رای نمیدهند همیشه باید بتوانند ادعای بازپرداخت داشته باشند" _. هر دو ویژگی ترتیب ترجیحی اجرا را بیان میکنند (رایگیری نمیتواند _قبل از_ واریز وجوه انجام شود و ادعای بازپرداخت نمیتواند _پس از_ رای دادن به یک پیشنهاد انجام شود).
+
+## تکنیکهایی برای تأیید رسمی قراردادهای هوشمند {#formal-verification-techniques}
+
+### بررسی مدل {#model-checking}
+
+بررسی مدل یک تکنیک تأیید رسمی است که در آن یک الگوریتم مدل رسمی یک قرارداد هوشمند را در برابر مشخصات آن بررسی میکند. در بررسی مدل، قراردادهای هوشمند اغلب به عنوان سیستمهای انتقال حالت نشان داده میشوند، در حالی که ویژگیهای روی حالتهای قرارداد مجاز با استفاده از منطق زمانی تعریف میشوند.
+
+بررسی مدل مستلزم ایجاد یک نمایش ریاضی انتزاعی از یک سیستم (به عنوان مثال، یک قرارداد) و بیان ویژگیهای این سیستم با استفاده از فرمولهایی است که ریشه در [منطق گزارهای](https://www.baeldung.com/cs/propositional-logic) دارند. این کار الگوریتم بررسی مدل را ساده می کند، یعنی ثابت کند که یک مدل ریاضی یک فرمول منطقی معین را برآورده می کند.
+
+بررسی مدل در راستیآزمایی رسمی عمدتاً برای ارزیابی ویژگیهای زمانی استفاده میشود که رفتار یک قرارداد را در طول زمان توصیف میکنند. ویژگی های موقت قراردادهای هوشمند شامل _ایمنی_ و _زندگی_ است که قبلا توضیح دادیم.
+
+به عنوان مثال، یک ویژگی امنیتی مربوط به کنترل دسترسی (به عنوان مثال، _فقط مالک قرارداد می تواند `selfdestruct`_ را فراخوانی کند) می تواند در منطق رسمی نوشته شود. پس از آن، الگوریتم بررسی مدل می تواند تأیید کند که آیا قرارداد با این مشخصات رسمی مطابقت دارد یا خیر.
+
+بررسی مدل از کاوش فضای حالت استفاده میکند، که شامل ساخت همه حالتهای ممکن یک قرارداد هوشمند و تلاش برای یافتن حالتهای قابل دسترسی است که منجر به نقض مالکیت میشود. با این حال، این می تواند به تعداد نامحدودی از حالت ها منجر شود (معروف به "مشکل انفجار حالت")، از این رو بررسی کنندگان مدل برای امکان تحلیل کارآمد قراردادهای هوشمند به تکنیک های انتزاعی تکیه می کنند.
+
+### اثبات قضیه {#theorem-proving}
+
+اثبات قضیه روشی برای استدلال ریاضی درباره صحت برنامه ها از جمله قراردادهای هوشمند است. این شامل تبدیل مدل سیستم قرارداد و مشخصات آن به فرمول های ریاضی (گزاره های منطقی) است.
+
+هدف از اثبات قضیه، تأیید هم ارزی منطقی بین این گزاره ها است. "تعادل منطقی" (که "منطقی دو مفهومی" نیز نامیده می شود) نوعی رابطه بین دو عبارت است به طوری که گزاره اول درست است _اگر و فقط اگر_ گزاره دوم درست باشد.
+
+رابطه مورد نیاز (تعادل منطقی) بین گزارههای مربوط به مدل قرارداد و ویژگیهای آن به عنوان یک گزاره قابل اثبات (به نام قضیه) فرموله میشود. با استفاده از یک سیستم رسمی استنتاج، اثبات کننده قضیه خودکار می تواند اعتبار قضیه را تأیید کند. به عبارت دیگر، یک اثبات کننده قضیه می تواند به طور قطعی ثابت کند که مدل قرارداد هوشمند دقیقاً با مشخصات آن مطابقت دارد.
+
+در حالی که مدلهای بررسی مدل به عنوان سیستمهای انتقالی با حالتهای محدود منقبض میشوند، اثبات قضیه میتواند تجزیه و تحلیل سیستمهای حالت نامتناهی را انجام دهد. با این حال، این بدان معناست که یک اثبات کننده قضیه خودکار همیشه نمی تواند بفهمد که آیا یک مسئله منطقی "قابل تصمیم گیری" است یا خیر.
+
+در نتیجه، کمک های انسانی اغلب برای راهنمایی اثبات کننده قضیه در استخراج براهین صحت مورد نیاز است. استفاده از تلاش انسانی در اثبات قضیه، استفاده از آن را نسبت به بررسی مدل که کاملاً خودکار است، گرانتر میکند.
+
+### اجرای نمادین {#symbolic-execution}
+
+اجرای نمادین روشی برای تجزیه و تحلیل قرارداد هوشمند با اجرای توابع با استفاده از _مقادیر نمادین_ (به عنوان مثال، `x > 5`) به جای _مقادیر مشخص_ ( به عنوان مثال، `x == 5`). به عنوان یک تکنیک تأیید رسمی، اجرای نمادین برای استدلال رسمی در مورد ویژگیهای سطح ردیابی در کد قرارداد استفاده میشود.
+
+اجرای نمادین یک رد اجرا را به عنوان یک فرمول ریاضی بر روی مقادیر ورودی نمادین نشان می دهد که در غیر این صورت _گزاره مسیر_ نامیده می شود. یک [حلکننده SMT](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) برای بررسی اینکه آیا یک گزاره مسیر "رضایتپذیر" است یا نه استفاده میشود (یعنی مقداری وجود دارد که میتواند فرمول را برآورده کند). اگر یک مسیر آسیب پذیر قابل رضایت باشد، حل کننده SMT یک مقدار مشخص ایجاد می کند که اجرای آن را به سمت آن مسیر هدایت می کند.
+
+فرض کنید تابع قرارداد هوشمند یک مقدار `uint` (`x`) را به عنوان ورودی می گیرد و زمانی که `x` بزرگتر از `5` باشد برمی گردد. و همچنین کمتر از `10`. یافتن مقداری برای `x` که خطا را با استفاده از یک روش آزمایش معمولی ایجاد میکند، مستلزم اجرای دهها تست (یا بیشتر) بدون اطمینان از یافتن ورودی محرک خطا است.
+
+برعکس، یک ابزار اجرای نمادین تابع را با مقدار نمادین اجرا می کند: `X > 5 ∧ X < 10` (یعنی `x` بزرگتر از 5 است و `x` کمتر از 10 است). گزاره مسیر مرتبط `x = X > 5 ∧ X < 10` سپس به حل کننده SMT داده می شود تا حل کند. اگر مقدار خاصی با فرمول `x = X > 5 ∧ X < 10`، حلکننده SMT آن را محاسبه میکند - برای مثال، حلکننده ممکن است `7` را به عنوان مقدار `x` تولید کند.
+
+از آنجایی که اجرای نمادین به ورودی های یک برنامه متکی است و مجموعه ورودی ها برای کاوش همه حالت های قابل دسترسی به طور بالقوه نامحدود است، هنوز هم نوعی آزمایش است. با این حال، همانطور که در مثال نشان داده شده است، اجرای نمادین کارآمدتر از آزمایش معمولی برای یافتن ورودی هایی است که باعث نقض مالکیت می شود.
+
+علاوه بر این، اجرای نمادین نسبت به سایر تکنیکهای مبتنی بر ویژگی (مثلاً فازی) که بهطور تصادفی ورودیهای یک تابع را تولید میکنند، نکات مثبت کاذب کمتری تولید میکند. اگر یک حالت خطا در طول اجرای نمادین ایجاد شود، می توان یک مقدار مشخص ایجاد کرد که باعث ایجاد خطا و بازتولید مسئله می شود.
+
+اجرای نمادین همچنین می تواند درجاتی از اثبات ریاضی درستی را ارائه دهد. مثال زیر از یک تابع قرارداد با حفاظت از سرریز را در نظر بگیرید:
+
+```
+function safe_add(uint x, uint y) returns(uint z){
+
+ z = x + y;
+ require(z>=x);
+ require(z>=y);
+
+ return z;
+```
+
+یک ردیابی اجرا که منجر به سرریز اعداد صحیح می شود باید این فرمول را برآورده کند: `z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)` بعید است چنین فرمولی حل شود، از این رو یک اثبات ریاضی است که تابع `safe_add` هرگز سرریز نمی شود.
+
+### چرا از تأیید رسمی برای قراردادهای هوشمند استفاده کنیم؟ {#benefits-of-formal-verification}
+
+#### نیاز به قابلیت اطمینان {#need-for-reliability}
+
+راستیآزمایی رسمی برای ارزیابی درستی سیستمهای حیاتی ایمنی استفاده میشود که خرابی آنها میتواند عواقب مخربی مانند مرگ، جراحت یا خرابی مالی داشته باشد. قراردادهای هوشمند، برنامههای کاربردی با ارزشی هستند که مقادیر زیادی از ارزش را کنترل میکنند و خطاهای ساده در طراحی میتواند منجر به
+خسارت جبرانناپذیر برای کاربران شود. با این حال، تأیید رسمی یک قرارداد قبل از استقرار، میتواند تضمینهایی را افزایش دهد که پس از اجرا بر روی بلاکچین، مطابق انتظار عمل میکند.
+
+قابلیت اطمینان یک کیفیت بسیار مطلوب در هر قرارداد هوشمند است، به خصوص به این دلیل که کد مستقر شده در ماشین مجازی اتریوم (EVM) معمولاً تغییرناپذیر است. از آنجایی که بروزرسانیهای پس از راهاندازی به راحتی قابل دسترسی نیستند، نیاز به تضمین قابلیت اطمینان قراردادها تأیید رسمی را ضروری میکند. راستیآزمایی رسمی میتواند مسائل پیچیدهای مانند سرریز و سرریز اعداد صحیح، ورود مجدد و بهینهسازی ضعیف گاز را شناسایی کند که ممکن است از دست حسابرسان و آزمایشکنندگان خارج شود.
+
+
+
+#### اثبات صحت عملکرد {#prove-functional-correctness}
+
+تست برنامه رایج ترین روش برای اثبات اینکه یک قرارداد هوشمند برخی از الزامات را برآورده می کند. این شامل اجرای یک قرارداد با نمونهای از دادههایی است که انتظار میرود مدیریت کند و رفتار آن را تحلیل کند. اگر قرارداد نتایج مورد انتظار را برای داده های نمونه برگرداند، توسعه دهندگان اثبات عینی برای صحت آن دارند.
+
+با این حال، این رویکرد نمی تواند اجرای صحیح را برای مقادیر ورودی که بخشی از نمونه نیستند ثابت کند. بنابراین، آزمایش یک قرارداد ممکن است به شناسایی اشکالات کمک کند (به عنوان مثال، اگر برخی از مسیرهای کد نتوانند نتایج دلخواه را در طول اجرا برگردانند)، اما **نمیتواند به طور قطعی عدم وجود اشکالات را ثابت کند**.
+
+برعکس، راستیآزمایی رسمی میتواند به طور رسمی ثابت کند که یک قرارداد هوشمند نیازمندیهای دامنه بینهایتی از اجراها را _بدون_ اجرای قرارداد برآورده میکند. این امر مستلزم ایجاد یک مشخصات رسمی است که دقیقاً رفتارهای صحیح قرارداد را توصیف می کند و یک مدل رسمی (ریاضی) از سیستم قرارداد را توسعه می دهد. سپس میتوانیم یک روش اثبات رسمی را برای بررسی سازگاری بین مدل قرارداد و مشخصات آن دنبال کنیم.
+
+با تأیید رسمی، سؤال تأیید اینکه آیا منطق تجاری یک قرارداد الزامات را برآورده می کند یک گزاره ریاضی است که می تواند اثبات یا رد شود. با اثبات رسمی یک گزاره، میتوانیم تعداد نامتناهی از موارد آزمایشی را با تعداد مراحل محدود تأیید کنیم. به این ترتیب تأیید رسمی چشم اندازهای بهتری برای اثبات صحت عملکرد قرارداد با توجه به مشخصات دارد.
+
+
+
+#### اهداف تأیید ایده آل {#ideal-verification-targets}
+
+هدف راستیآزمایی، سیستمی را که باید بهطور رسمی تأیید شود، توصیف میکند. تأیید رسمی به بهترین وجه در «سیستمهای تعبیهشده» (نرمافزارهای کوچک و ساده که بخشی از یک سیستم بزرگتر را تشکیل میدهند) استفاده میشود. آنها همچنین برای دامنه های تخصصی که قوانین کمی دارند ایده آل هستند، زیرا این کار تغییر ابزارها را برای تأیید ویژگی های خاص دامنه آسان تر می کند.
+
+قراردادهای هوشمند - حداقل تا حدی - هر دو الزام را برآورده می کنند. به عنوان مثال، اندازه کوچک قراردادهای اتریوم باعث می شود که آنها را به تأیید رسمی برساند. به طور مشابه، EVM از قوانین ساده پیروی می کند، که تعیین و تأیید ویژگی های معنایی را برای برنامه های در حال اجرا در EVM آسان تر می کند.
+
+
+
+### چرخه توسعه سریعتر {#faster-development-cycle}
+
+تکنیکهای تأیید رسمی، مانند بررسی مدل و اجرای نمادین، معمولاً کارآمدتر از تجزیه و تحلیل منظم کد قرارداد هوشمند (که در طول آزمایش یا ممیزی انجام میشود) هستند. این به این دلیل است که تأیید رسمی برای آزمایش ادعاها به مقادیر نمادین متکی است ("اگر کاربر سعی کند _n_ اتر را خارج کند چه؟" برخلاف آزمایشی که از مقادیر مشخصی استفاده می کند ("اگر کاربر بخواهد 5 اتر را خارج کند چه؟".
+
+متغیرهای ورودی نمادین میتوانند چندین کلاس از مقادیر بتن را پوشش دهند، بنابراین رویکردهای تأیید رسمی پوشش کد بیشتری را در بازه زمانی کوتاهتر وعده میدهند. هنگامی که به طور موثر استفاده می شود، تأیید رسمی می تواند چرخه توسعه را برای توسعه دهندگان تسریع کند.
+
+تأیید رسمی همچنین فرآیند ساخت دپها (dapps) را با کاهش خطاهای طراحی پرهزینه بهبود می بخشد. ارتقاء قراردادها (در صورت امکان) برای رفع آسیب پذیری ها مستلزم بازنویسی گسترده پایگاه های کد و تلاش بیشتر برای توسعه است. راستیآزمایی رسمی میتواند بسیاری از خطاها را در اجرای قرارداد شناسایی کند که ممکن است آزمایشکنندگان و حسابرسان را پشت سر بگذارد و فرصت کافی برای رفع آن مشکلات قبل از استقرار قرارداد فراهم میکند.
+
+
+
+## معایب تأیید رسمی {#drawbacks-of-formal-verification}
+
+
+
+### هزینه نیروی کار {#cost-of-manual-labor}
+
+راستیآزمایی رسمی، بهویژه تأیید نیمه خودکار که در آن یک انسان اثباتکننده را برای به دست آوردن اثبات صحت راهنمایی میکند، به کار دستی قابلتوجهی نیاز دارد. علاوه بر این، ایجاد مشخصات رسمی یک فعالیت پیچیده است که به سطح بالایی از مهارت نیاز دارد.
+
+این عوامل (تلاش و مهارت) تأیید رسمی را در مقایسه با روشهای معمول ارزیابی صحت قراردادها، مانند آزمایش و ممیزی، پرهزینهتر و پرهزینهتر میسازد. با این وجود، با توجه به هزینه خطاها در اجرای قراردادهای هوشمند، پرداخت هزینه برای ممیزی تأیید کامل عملی است.
+
+
+
+### منفی های کاذب {#false-negatives}
+
+تأیید رسمی فقط می تواند بررسی کند که آیا اجرای قرارداد هوشمند با مشخصات رسمی مطابقت دارد یا خیر. به این ترتیب، مهم است که مطمئن شوید مشخصات به درستی رفتارهای مورد انتظار یک قرارداد هوشمند را توصیف می کند.
+
+اگر مشخصات ضعیف نوشته شده باشند، نقض ویژگیها - که به اعدامهای آسیبپذیر اشاره دارد - توسط ممیزی تأیید رسمی قابل شناسایی نیست. در این مورد، یک توسعه دهنده ممکن است به اشتباه فرض کند که قرارداد بدون اشکال است.
+
+
+
+### مسائل مربوط به عملکرد {#performance-issues}
+
+تأیید رسمی با تعدادی از مشکلات عملکرد مواجه می شود. برای مثال، مشکلات انفجار حالت و مسیر که به ترتیب در حین بررسی مدل و بررسی نمادین با آن مواجه میشوند، میتوانند بر رویههای تأیید تأثیر بگذارند. همچنین، ابزارهای تأیید رسمی اغلب از حل کننده های SMT و سایر حل کننده های محدودیت در لایه زیرین خود استفاده می کنند و این حل کننده ها بر رویه های محاسباتی فشرده تکیه می کنند.
+
+همچنین، تعیین اینکه آیا یک ویژگی (که به عنوان یک فرمول منطقی توصیف میشود) میتواند برآورده شود یا خیر، برای تأییدکنندگان برنامه همیشه امکانپذیر نیست («[مشکل تصمیمپذیری](https://en.wikipedia.org/wiki/Decision_problem)») زیرا ممکن است یک برنامه هرگز خاتمه یابد. به این ترتیب، ممکن است اثبات برخی از خواص برای یک قرارداد، حتی اگر به خوبی مشخص شده باشد، غیرممکن باشد.
+
+
+
+## ابزارهای تأیید رسمی قراردادهای هوشمند اتریوم {#formal-verification-tools}
+
+
+
+### زبان های مشخصات برای ایجاد مشخصات رسمی {#specification-languages}
+
+**Act**: _*Act اجازه میدهد تا مشخصات بهروزرسانیهای ذخیرهسازی، شرایط قبل/پست و متغیرهای قرارداد را مشخص کنید. مجموعه ابزار آن همچنین دارای پشتیبانهای اثباتی است که میتوانند ویژگیهای زیادی را از طریق Coq، حلکنندههای SMT یا hevm اثبات کنند.**
+
+- [گیتهاب](https://github.com/ethereum/act)
+- [اسناد](https://ethereum.github.io/act/)
+
+**Scribble** - _*Scribble حاشیه نویسی کد در زبان مشخصات Scribble را به ادعاهای مشخصی تبدیل می کند که مشخصات را بررسی می کند.**
+
+- [مستندات](https://docs.scribble.codes/)
+
+**Dafny** - _*Dafny یک زبان برنامه نویسی آماده تأیید است که برای استدلال و اثبات درستی کد به حاشیه نویسی های سطح بالا متکی است.**
+
+- [گیتهاب](https://github.com/dafny-lang/dafny)
+
+
+
+### تأیید کننده های برنامه برای بررسی صحت {#program-verifiers}
+
+**Certora Prover** - _Certora Prover یک ابزار تأیید رسمی خودکار برای بررسی صحت کد در قراردادهای هوشمند است. مشخصات به زبان CVL (زبان تأیید Certora) نوشته شده است، با استفاده از ترکیبی از تجزیه و تحلیل استاتیک و حل محدودیت، نقض مالکیت شناسایی میشود._
+
+- [وبسایت](https://www.certora.com/)
+- [اسناد](https://docs.certora.com/en/latest/index.html)
+
+**Solidity SMTCchecker** - _*Solidity's SMTCchecker یک مدل بررسی کننده داخلی است که بر اساس SMT (تئوری های مدول رضایت پذیری) و حل شاخ است. تأیید می کند که کد منبع قرارداد با مشخصات در طول تدوین مطابقت دارد یا خیر و به طور ایستا نقض ویژگی های ایمنی را بررسی می کند.**
+
+- [گیتهاب](https://github.com/ethereum/solidity)
+
+**solc-verify** - _*solc-verify نسخه توسعه یافته کامپایلر سالیدیتی است که می تواند با استفاده از حاشیه نویسی و تأیید برنامه مدولار، تأیید رسمی خودکار را روی کد سالیدیتی انجام دهد.**
+
+- [گیتهاب](https://github.com/SRI-CSL/solidity)
+
+**KEVM** - _*KEVM یک معناشناسی رسمی از ماشین مجازی اتریوم (EVM) است که در چارچوب K نوشته شده است. KEVM قابل اجرا است و میتواند برخی ادعاهای مربوط به ویژگی را با استفاده از منطق دسترسپذیری اثبات کند.**
+
+- [گیتهاب](https://github.com/runtimeverification/evm-semantics)
+- [مستندات](https://jellopaper.org/)
+
+
+
+### چارچوب های منطقی برای اثبات قضیه {#theorem-provers}
+
+**Isabelle** - _Isabelle/HOL یک دستیار اثبات است که به فرمول های ریاضی اجازه می دهد تا به زبان رسمی بیان شوند و ابزارهایی برای اثبات آن فرمول ها فراهم می کند. کاربرد اصلی، رسمیسازی اثباتهای ریاضی و بهویژه تأیید رسمی است که شامل اثبات صحت سختافزار یا نرمافزار رایانه و اثبات ویژگیهای زبانها و پروتکلهای رایانه میشود._
+
+- [گیتهاب](https://github.com/isabelle-prover)
+- [مستندات](https://isabelle.in.tum.de/documentation.html)
+
+**Coq** - _Coq یک اثبات کننده قضیه تعاملی است که به شما امکان می دهد برنامه ها را با استفاده از قضایا تعریف کنید و به طور تعاملی اثبات صحت بررسی شده توسط ماشین را ایجاد کنید._
+
+- [گیتهاب](https://github.com/coq/coq)
+- [اسناد](https://coq.github.io/doc/v8.13/refman/index.html)
+
+
+
+### ابزارهای مبتنی بر اجرای نمادین برای تشخیص الگوهای آسیب پذیر در قراردادهای هوشمند {#symbolic-execution-tools}
+
+**Manticore** - _*ابزاری برای تجزیه و تحلیل ابزار تجزیه و تحلیل بایت کد EVM بر اساس اجرای نمادین*.*
+
+- [گیتهاب](https://github.com/trailofbits/manticore)
+- [مستندات](https://github.com/trailofbits/manticore/wiki)
+
+**hevm** - _*hevm یک موتور اجرای نمادین و جستجوگر معادل برای بایت کد EVM است.**
+
+- [گیت هاب](https://github.com/dapphub/dapptools/tree/master/src/hevm)
+
+**Mythil** - _ابزار اجرای نمادین برای شناسایی آسیبپذیریها در قراردادهای هوشمند اتریوم_
+
+- [گیتهاب](https://github.com/ConsenSys/mythril-classic)
+- [مستندات](https://mythril-classic.readthedocs.io/en/develop/)
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [چگونه تأیید رسمی قراردادهای هوشمند کار می کند؟](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/)
+- [چگونه تأیید رسمی می تواند قراردادهای هوشمند بی عیب و نقص را تضمین کند؟](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1)
+- [مروری بر پروژه های تایید رسمی در اکوسیستم اتریوم](https://github.com/leonardoalt/ethereum_formal_verification_overview)
+- [تایید رسمی اند تو اند قرارداد هوشمند سپرده گذاری اتریوم 2.0](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/)
+- [تایید رسمی محبوب ترین قرارداد هوشمند جهان](https://www.zellic.io/blog/formal-verification-weth)
+- [SMTCchecker و تأیید رسمی](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
new file mode 100644
index 00000000000..beb008abc76
--- /dev/null
+++ "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
@@ -0,0 +1,372 @@
+---
+title: آزمایش قرارداد هوشمند
+description: نمای کلی تکنیک ها و ملاحظات تست کردن قراردادهای هوشمند سالیدیتی.
+lang: fa
+---
+
+بلاک چین های عمومی مانند اتریوم تغییر ناپذیر هستند و تغییر کد قراردادهای هوشمند پس از استقرار را دشوار می کند. الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر این، یک ارتقا فقط میتواند یک خطا را پس از کشف آن برطرف کند - اگر مهاجم ابتدا آسیبپذیری را کشف کند، قرارداد هوشمند شما در معرض خطر سوء استفاده قرار میگیرد.
+الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر آن، بروزرسانی، فقط میتواند خطا را_پس از _ کشف شدن آن تصحیح کند - اگر یک مهاجم، زودتر از تصحیح آن خطا، خطا را پیدا کند، قرارداد هوشمند مربوطه در معرض سوء استفاده واقع میشود.
+
+به همین علت است که تست کردن قراردادهای هوشمند پیش از [دیپلوی](/developers/docs/smart-contracts/deploying/) بر روی شبکه اصلی، به عنوان حداقل میزان رعایت [ایمنی](/developers/docs/smart-contracts/security/) تلقی می شود. برای تست و ارزیابی میزان صحت کدهای قراردادهای هوشمند، تکنیک های مختلفی وجود دارد؛ این که انتخاب شما کدام تکنیک و به چه صورت باشد به نیازمندی و خواست خود شما بر میگردد. ضمناً، مجموعه های تستی که متشکل از ابزارها و نگرش های مختلف باشند به عنوان گزینه ای ایدهآل برای کشف و عیب یابی نواقص امنیتی کم اهمیت و پر اهمیت در کد کانترکت می باشند.
+
+
+
+## پیشنیازها {#prerequisites}
+
+در این صفحه به بررسی چگونگه تست قراردادهای هوشمند پیش از دیپلوی روی شبکه اتریوم می پردازیم. فرض بر این است که با [قراردادهای هوشمند](/developers/docs/smart-contracts/) آشنا هستید.
+
+
+
+## تست کردن قرارداد هوشمند چیست؟ {#what-is-smart-contract-testing}
+
+تست کردن قرارداد هوشمند پروسه ای است که با استفاده از آن می توانیم از صحت عملکرد کد قرارداد هوشمند به نسبت نحوه عملکرد آن کد اطمینان حاصل کنیم. در زمانی که بخواهیم از قابل اطمینان بودن، قابل استفاده بودن، و ایمنی قرارداد هوشمند مطمئن شویم، تست کردن بسیار کاربردی و مفید است.
+
+اگرچه که رویکردهای مختلفی وجود دارند، بیشتر روش های تست کردن مبنی بر اجرای یک قراردادهای هوشمند با نمونه کوچکی از داده هایی که انتظار اجرا شدن کدها با آن را داریم، میباشد. اگر کانترکت در ازای این داده های نمونه، جواب صحیح برگرداند، به معنای صحت عملکرد کد مربوطه است. بیشتر ابزارهای تست کردن، به منظور چک کردن تطابق نتایج حاصله با نتایج عملیاتی کانترکت، منابعی را به منظور نوشتن و اجرا کردن [موارد تست](https://en.m.wikipedia.org/wiki/Test_case) فراهم می کنند.
+
+
+
+### علت اهمیت تست قراردادهای هوشمند چیست؟ {#importance-of-testing-smart-contracts}
+
+قراردادهای هوشمند به طور معمول حجم زیادی از دارایی های مالی را مدیریت میکنند، کوچکترین اشتباه برنامه نویسی می تواند باعث [خسارت هنگفت به کاربران](https://rekt.news/leaderboard/) شود. تست دقیق، می تواند در یافتن عیب ها و مشکلات کد یک قرارداد هوشمند در مراحل اولیه، و تصحیح آنها پیش از عرضه کانترکت مربوطه، به شما کمک کند.
+
+اگرچه در صورتی که یک خطا یا باگ در قرارداد هوشمند کشف شود، امکان آپدیت و ارتقای آن وجود دارد، اما آپدیت کردن آن می تواند امری پیچیده بوده و در صورتی که به خطای مربوطه به درستی رسیدگی نشود، خود باعث [خطاهای دیگر](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) شود. علاوه بر آن، بروزرسانی یک کانترکت ناقض اصل تغییرناپذیری بوده و مفروضات اعتمادی اضافه ای را بر کاربران تحمیل می کند. برعکس، یک برنامه جامع برای آزمایش و تست قرارداد شما خطرات امنیتی قرارداد هوشمند را کاهش میدهد و نیاز به انجام ارتقاء منطقی پیچیده پس از استقرار یا دپلوی را کاهش میدهد.
+
+
+
+## روشهای تست قراردادهای هوشمند {#methods-for-testing-smart-contracts}
+
+روشهای تست قراردادهای هوشمند اتریوم در دو دسته کلی قرار میگیرند: **تست خودکار** و **تست دستی**. تست خودکار و تست دستی مزایا و بخشهای منحصر به فردی را ارائه میدهند، اما میتوانید هر دو را برای ایجاد یک برنامه قوی برای تجزیه و تحلیل قراردادهای خود ترکیب کنید.
+
+
+
+### تست خودکار {#automated-testing}
+
+تست خودکار از ابزارهایی استفاده میکند که به طور خودکار کد قراردادهای هوشمند را برای خطا در اجرا بررسی میکند. مزیت تست خودکار برای استفاده از [اسکریپتها](https://www.techtarget.com/whatis/definition/script?amp=1) برای راهنمایی ارزیابی عملکردهای قرارداد ناشی میشود. تست اسکریپتشده را میتوان برای اجرای مکرر با حداقل مداخله انسانی برنامهریزی کرد و تست خودکار را کارآمدتر از روشهای دستی برای تست کردن میکند.
+
+تست خودکار به ویژه زمانی مفید است که تستها تکراری و وقت گیر باشند. انجام تست دستی دشوار است؛ مستعد خطای انسانی؛ یا شامل ارزیابی عملکردهای مهم قرارداد میشود. اما ابزارهای تست خودکار میتوانند اشکالاتی داشته باشند—ممکن است برخی از اشکالات را از دست بدهند و [فضای مثبت کاذب](https://www.contrastsecurity.com/glossary/false-positive) زیادی ایجاد کنند. از این رو، جفت کردن تست خودکار با تست دستی برای قراردادهای هوشمند ایدهآل است.
+
+
+
+### تست دستی {#manual-testing}
+
+تست دستی به کمک انسان است و شامل اجرای هر یک از موارد تستی در مجموعه آزمایشی شما هنگام تجزیه و تحلیل صحت قراردادهای هوشمند است. این مورد برخلاف تست خودکار است که در آن میتوانید به طور همزمان چندین تست مجزا را روی یک قرارداد اجرا کرده و گزارشی دریافت کنید که تمام تستهای شکست خورده و قبولی را نشان میدهد.
+
+تست دستی میتواند توسط یک فرد به دنبال یک برنامه آزمون کتبی که سناریوهای مختلف آزمون را پوشش میدهد، انجام شود. همچنین میتوانید چندین فرد یا گروه را به عنوان بخشی از تست دستی و تعامل با یک قرارداد هوشمند در یک دوره مشخص بخواهید. تستکنندگان رفتار واقعی قرارداد را با رفتار مورد انتظار مقایسه کرده و هر تفاوتی را بهعنوان یک اشکال یا باگ علامتگذاری میکنند.
+
+تست دستی مؤثر به منابع قابلتوجهی (مهارت، زمان، پول و تلاش) نیاز دارد و ممکن است - به دلیل خطای انسانی - خطاهای خاصی را در حین اجرای تستها از دست داد. اما تست دستی نیز میتواند سودمند باشد - برای مثال، یک تستکننده انسانی (مثلاً یک حسابرس یا آدیتور) ممکن است از شهود برای تشخیص موارد که ابزار تست خودکار از دست میدهد استفاده کند.
+
+
+
+## تست خودکار برای قراردادهای هوشمند {#automated-testing-for-smart-contracts}
+
+
+
+### تست واحد {#unit-testing-for-smart-contracts}
+
+تست واحد عملکردهای قرارداد را به طور جداگانه ارزیابی و بررسی کرده که هر جزء به درستی کار میکند. تستهای واحد مطلوب باید ساده، سریع اجرا شوند و ایده روشنی از اینکه در صورت شکست تستها چه اشتباهی رخ داده است، ارائه دهند.
+
+تستهای واحد برای بررسی اینکه آیا توابع مقادیر مورد انتظار را برمیگردانند و اینکه ذخیرهسازی قرارداد بهدرستی پس از اجرای تابع بهروز شده است مفید هستند. علاوه بر این، اجرای تستهای واحد پس از ایجاد تغییرات در پایگاه کد قراردادها، تضمین میکند که افزودن منطق جدید باعث ایجاد خطا نمیشود. در زیر چند دستورالعمل برای اجرای تستهای واحد مؤثر آورده شده است:
+
+
+
+#### راهنماهایی برای تست واحد قراردادهای هوشمند {#unit-testing-guidelines}
+
+
+
+##### 1. منطق تجاری و گردش کار قراردادهای خود را درک کنید
+
+قبل از نوشتن تستهای واحد، دانستن اینکه یک قرارداد هوشمند چه ویژگیهایی را ارائه میدهد و کاربران چگونه به آن عملکردها دسترسی خواهند داشت و از آنها استفاده میکنند، کمک میکند. این مورد به ویژه برای اجرای [تستهای مسیر درست](https://en.m.wikipedia.org/wiki/Happy_path) مفید است که تعیین میکند آیا توابع در قرارداد، خروجی صحیح را برای ورودیهای معتبر کاربر برمیگردانند یا خیر. ما این مفهوم را با استفاده از این مثال (مختلف) از [یک قرارداد مزایده](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple- توضیح خواهیم داد. open-auction)
+
+
+
+```
+constructor(
+ uint biddingTime,
+ address payable beneficiaryAddress
+ ) {
+ beneficiary = beneficiaryAddress;
+ auctionEndTime = block.timestamp + biddingTime;
+ }
+
+function bid() external payable {
+
+ if (block.timestamp > auctionEndTime)
+ revert AuctionAlreadyEnded();
+
+ if (msg.value <= highestBid)
+ revert BidNotHighEnough(highestBid);
+
+ if (highestBid != 0) {
+ pendingReturns[highestBidder] += highestBid;
+ }
+ highestBidder = msg.sender;
+ highestBid = msg.value;
+ emit HighestBidIncreased(msg.sender, msg.value);
+ }
+
+ function withdraw() external returns (bool) {
+ uint amount = pendingReturns[msg.sender];
+ if (amount > 0) {
+ pendingReturns[msg.sender] = 0;
+
+ if (!payable(msg.sender).send(amount)) {
+ pendingReturns[msg.sender] = amount;
+ return false;
+ }
+ }
+ return true;
+ }
+
+function auctionEnd() external {
+ if (block.timestamp < auctionEndTime)
+ revert AuctionNotYetEnded();
+ if (ended)
+ revert AuctionEndAlreadyCalled();
+
+ ended = true;
+ emit AuctionEnded(highestBidder, highestBid);
+
+ beneficiary.transfer(highestBid);
+ }
+}
+```
+
+
+این یک قرارداد مزایده ساده است که برای دریافت پیشنهادها در طول دوره مناقصه طراحی شده است. اگر این مورد `highestBid` افزایش یابد، بالاترین پیشنهاد قبلی پول خود را دریافت میکند. پس از پایان دوره مناقصه، `ذینفع` قرارداد را فراخوانی میکند تا پول خود را دریافت کند.
+
+تستهای واحد برای قراردادی مانند این، عملکردهای مختلفی را که کاربر ممکن است هنگام تعامل با قرارداد فراخوانی کند، پوشش میدهد. یک مثال برای تست واحد این است که بررسی میکند آیا کاربر میتواند در حین انجام مزایده پیشنهادی ارائه دهد (یعنی تماسهای `قیمتگذاری()` موفقیتآمیز است) یا آزمایشی که بررسی میکند آیا کاربر میتواند پیشنهاد بالاتری از پیشنهاد فعلی ارائه دهد یا خیر. `highestBid`.
+
+همچنین درک گردش کار عملیاتی قراردادها به نوشتن تستهای واحد کمک میکند تا بررسی کند که آیا اجرا با الزامات مطابقت دارد یا خیر. برای مثال، قرارداد مزایده مشخص میکند که کاربران نمیتوانند پس از پایان حراج، پیشنهاد بدهند (یعنی زمانی که `زمان مزایده یا حراج تمام شود` کمتر از `block.timestamp` است). بنابراین، یک توسعهدهنده ممکن است تست واحدی را اجرا کند که بررسی میکند آیا فراخوانیهای تابع `bid()` موفق میشوند یا شکست میخورند پس از پایان حراج (یعنی وقتی `auctionEndTime` > `block.timestamp`).
+
+
+
+##### 2. کلیه مفروضات مربوط به اجرای قرارداد را ارزیابی کنید
+
+ثبت هرگونه فرضی در مورد اجرای قرارداد و نوشتن تستهای واحد برای تأیید صحت آن مفروضات مهم است. جدا از ارائه محافظت در برابر اجرای غیرمنتظره، اظهارات تست شما را مجبور میکند به عملیاتی فکر کنید که میتواند مدل امنیتی قراردادهای هوشمند را شکست دهد. یک نکته مفید این است که فراتر از "تستهای کاربر" بروید و تستهای منفی بنویسید که بررسی میکند آیا یک تابع برای ورودیهای اشتباه ناموفق است یا خیر.
+
+بسیاری از فریم ورکهای تست واحد به شما اجازه میدهند تا اظهارات را ایجاد کنید - عبارتهای سادهای که بیان میکند قرارداد چه کاری میتواند انجام دهد و چه کاری نمیتواند انجام دهد - و تستهایی را برای مشاهده اینکه آیا این ادعاها در حال اجرا هستند یا خیر، اجرا کنید. توسعهدهندهای که روی قرارداد حراج که قبلاً توضیح داده شد کار میکند، میتواند پیش از اجرای تستهای منفی، در مورد رفتار خود اظهارات زیر را بیان کند:
+
+- وقتی مزایده تمام شده یا شروع نشده است، کاربران نمیتوانند پیشنهاد دهند.
+
+- اگر پیشنهادی کمتر از آستانه قابل قبول باشد، قرارداد مزایده لغو میشود.
+
+- کاربرانی که موفق به برنده شدن در مناقصه نشوند با وجوه خود اعتبار داده میشوند
+
+**نکته**: روش دیگری برای تست مفروضات، نوشتن تستهایی است که [مادیفایر یا اصلاحکننده تابع](https://docs.soliditylang.org/en/v0.8.16/contracts را راهاندازی میکنند. html#function-modifiers) در یک قرارداد، به خصوص عبارتهای `require`، `assert` و `if…else`.
+
+
+
+##### 3. پوشش کد را اندازهگیری کنید (code coverage)
+
+[پوشش کد](https://en.m.wikipedia.org/wiki/Code_coverage) یک معیار آزمایشی است که تعداد شاخهها، خطوط و عبارات کد شما را که در طول تستها اجرا میشوند، ردیابی میکند. تستها باید پوشش کد خوبی داشته باشند، در غیر این صورت ممکن است "منفی کاذب" دریافت کنید و زمانی اتفاق میافتد که یک قرارداد همه تستها را با موفقیت پشت سر میگذارد، اما آسیب پذیریها همچنان در کد وجود دارد. با این حال، ثبت پوشش بالای کد این اطمینان را به شما میدهد که تمام عبارات/عملکردهای یک قرارداد هوشمند به اندازه کافی برای صحت تست شدهاند.
+
+
+
+##### 4. از فریم ورکهای آزمایشی توسعه یافته استفاده کنید
+
+کیفیت ابزارهای مورد استفاده در اجرای تستهای واحد برای قراردادهای هوشمند شما بسیار مهم است. یک فریم ورک تست ایده آل، فریم ورکی است که به طور منظم نگهداری شود. ویژگیهای مفیدی را ارائه میدهد (به عنوان مثال، قابلیتهای ثبت و گزارش). و باید به طور گسترده توسط توسعه دهندگان دیگر مورد استفاده و بررسی قرار گرفته باشد.
+
+فریم ورکهای تست واحد برای قراردادهای هوشمند سالیدیتی به زبانهای مختلف (عمدتاً جاوا اسکریپت، پایتون و Rust) ارائه میشوند. برخی از راهنماهای زیر را برای اطلاع از نحوه شروع اجرای تستهای واحد با فریم ورکهای تست مختلف مشاهده کنید:
+
+- **[اجرای تست واحد با Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
+- **[اجرای تست واحد با فوندری](https://book.getfoundry.sh/forge/writing-tests)**
+- **[اجرای تست واحد با وافل](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
+- **[اجرای تست واحد با ریمیکس](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
+- **[اجرای تست واحد با ایپ](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
+- **[اجرای تستهای واحد با هاردهات](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
+- **[اجرای تستهای واحد با Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
+
+
+
+### تست یکپارچهسازی {#integration-testing-for-smart-contracts}
+
+در حالی که تست واحد عملکردهای قرارداد را به صورت مجزا اشکال زدایی میکند، تستهای یکپارچهسازی اجزای یک قرارداد هوشمند را به عنوان یک کل ارزیابی میکنند. تست یکپارچه سازی میتواند مشکلات ناشی از فراخوانیهای قراردادی متقابل یا تعامل بین عملکردهای مختلف در یک قرارداد هوشمند را شناسایی کند. به عنوان مثال، تستهای یکپارچهسازی میتوانند به بررسی اینکه آیا مواردی مانند [ارثبری](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) و وابستگی به درستی کار میکنند یا خیر کمک میکند.
+
+تست یکپارچهسازی در صورتی مفید است که قرارداد شما در طول اجرا از معماری مدولار استفاده کند یا با سایر قراردادهای زنجیرهای ارتباط برقرار کند. یکی از راههای اجرای تستهای یکپارچهسازی این است که [بلاک چین](/glossary/#fork) را در یک ارتفاع خاص (با استفاده از ابزاری مانند [Forge](https://book.getfoundry.sh فورک کنید. /forge/fork-testing) یا [هاردهت](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) و تعاملات بین قرارداد شما و قراردادهای مستقر را شبیهسازی کنید.
+
+بلاک چین فورک شده مشابه شبکه اصلی رفتار خواهد کرد و دارای حسابهایی با وضعیتها و موجودیهای مرتبط است. اما فقط به عنوان یک محیط توسعه محلی سندباکس شده عمل میکند، به این معنی که برای تراکنشها به ETH واقعی نیاز نخواهید داشت، همچنین تغییرات شما بر پروتکل واقعی اتریوم تأثیر نمیگذارد.
+
+
+
+### تست مبتنی بر مشخصات {#property-based-testing-for-smart-contracts}
+
+تست مبتنی بر دارایی فرآیند بررسی این است که آیا قرارداد هوشمند برخی از ویژگیهای تعریف شده را برآورده میکند یا خیر. ویژگیها حقایقی را در مورد رفتار قرارداد بیان میکنند که انتظار میرود در سناریوهای مختلف درست باقی بماند - نمونهای از ویژگی قرارداد هوشمند میتواند "عملیات حسابی در قرارداد هرگز اورفلو یا آندرفلو" نباشد
+
+**تحلیل استاتیک** و **تحلیل دینامیکی** دو تکنیک رایج برای اجرای تست مبتنی بر ویژگی هستند و هر دو میتوانند تأیید کنند که کد یک برنامه (یک قرارداد هوشمند در این مورد) برخی از ویژگیهای از پیش تعریف شده را برآورده میکند. برخی از ابزارهای تست مبتنی بر دارایی با قوانین از پیش تعریف شده در مورد ویژگیهای قرارداد مورد انتظار ارائه میشوند و کد را در برابر آن قوانین بررسی میکنند، در حالی که برخی دیگر به شما امکان میدهند ویژگیهای سفارشی را برای یک قرارداد هوشمند ایجاد کنید.
+
+
+
+#### تجزیه و تحلیل استاتیک {#static-analysis}
+
+یک آنالایزر استاتیک کد منبع یک قرارداد هوشمند را به عنوان ورودی دریافت کرده و نتایج را با اعلام اینکه آیا قرارداد یک ویژگی را برآورده میکند یا نه، خروجی میگیرد. بر خلاف تحلیل پویا، تحلیل استاتیک شامل اجرای قرارداد برای تجزیه و تحلیل آن برای صحت نیست. تجزیه و تحلیل استاتیک در عوض درباره تمام مسیرهای احتمالی که یک قرارداد هوشمند میتواند در طول اجرا طی کند (به عنوان مثال، با بررسی ساختار کد منبع برای تعیین معنای آن برای عملیات قراردادها در زمان اجرا) استدلال میکند.
+
+[Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) و [تست استاتیک](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) روشهای رایج برای اجرای تحلیل استاتیک در قراردادها هستند. هر دو نیازمند تجزیه و تحلیل نمایشهای سطح پایین اجرای قرارداد هستند، مانند [درخت نحو انتزاعی](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) و [کنترل نمودارهای جریان](https: //www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) خروجی توسط کامپایلر.
+
+در بیشتر موارد، تجزیه و تحلیل استاتیک برای تشخیص مسائل ایمنی مانند استفاده از ساختارهای ناامن، خطاهای نحوی یا نقض استانداردهای کدگذاری در کد قرارداد مفید است. با این حال، آنالایزرهای استاتیک به طور کلی در تشخیص آسیبپذیریهای عمیقتر نامطلوب هستند و ممکن است مثبت کاذب بیش از حد تولید کنند.
+
+
+
+#### تحلیل دینامیک {#dynamic-analysis}
+
+تحلیل پویا ورودیهای نمادین (مثلاً در [اجرای نمادین](https://en.m.wikipedia.org/wiki/Symbolic_execution)) یا ورودیهای مشخص (مثلاً در [fuzzing](https://owasp.org/www-community/Fuzzing)) به یک قرارداد هوشمند عمل میکند تا ببیند آیا هر رد یا تریس(های) اجرایی خاصیت خاصی را نقض میکند یا خیر. این شکل از تست مبتنی بر ویژگی با تستهای واحد متفاوت است، زیرا موارد تست سناریوهای متعددی را پوشش میدهند و یک برنامه تولید موارد تست را انجام میدهد.
+
+[Fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) نمونهای از تکنیک تحلیل پویا برای تأیید ویژگیهای دلخواه در قراردادهای هوشمند است. یک فازر توابع را در یک قرارداد هدف با تغییرات تصادفی یا به شکل نادرست یک مقدار ورودی تعریف شده فراخوانی میکند. اگر قرارداد هوشمند وارد یک حالت خطا شود (به عنوان مثال، وضعیتی که یک ادعا با شکست مواجه شود)، مشکل علامتگذاری میشود و ورودیهایی که اجرا را به سمت مسیر آسیبپذیر هدایت میکند در یک گزارش تولید میشود.
+
+فازینگ برای ارزیابی مکانیزم اعتبارسنجی ورودی قراردادهای هوشمند مفید است زیرا مدیریت نادرست ورودیهای غیرمنتظره ممکن است منجر به اجرای ناخواسته و ایجاد اثرات خطرناک شود. این شکل از تست مبتنی بر ویژگی میتواند به دلایل زیادی ایدهآل باشد:
+
+1. **نوشتن موارد تست برای پوشش دادن بسیاری از سناریوها دشوار است.** تست ویژگی فقط مستلزم آن است که یک رفتار و طیف وسیعی از دادهها را برای تست رفتار تعریف کنید—برنامه به طور خودکار تست را تولید میکند و موارد بر اساس ویژگی تعریف شده است.
+
+2. **مجموعه تست شما ممکن است به اندازه کافی تمام مسیرهای ممکن در برنامه را پوشش ندهد.** حتی با پوشش ۱۰۰٪، ممکن است موارد حیاتی را از دست بدهید.
+
+3. **تستهای واحد ثابت میکنند که یک قرارداد برای دادههای نمونه به درستی اجرا میشود، اما اینکه آیا قرارداد برای ورودیهای خارج از نمونه به درستی اجرا میشود یا خیر، ناشناخته باقی میماند.** تستهای ویژگی، یک قرارداد هدف را با تغییرات چندگانه یک قرارداد اجرا میکنند. مقدار ورودی داده شده برای یافتن آثار اجرایی که باعث شکست ادعا میشوند. بنابراین، یک تست ویژگی تضمینهای بیشتری برای اجرای صحیح قرارداد برای یک کلاس وسیع از دادههای ورودی ارائه میدهد.
+
+
+
+### دستورالعملهایی برای اجرای تست مبتنی بر اموال برای قراردادهای هوشمند {#running-property-based-tests}
+
+اجرای تست مبتنی بر ویژگی معمولاً با تعریف یک ویژگی (به عنوان مثال، عدم وجود [اورفلو عدد صحیح](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) یا مجموعهای از ویژگیهایی که میخواهید در یک قرارداد هوشمند تأیید کنید، میباشد. همچنین ممکن است لازم باشد محدودهای از مقادیر را تعریف کنید که در آن برنامه میتواند دادههایی را برای ورودیهای تراکنش هنگام نوشتن تستهای ویژگی تولید کند.
+
+هنگامی که به درستی پیکربندی شد، ابزار تست، توابع قراردادهای هوشمند شما را با ورودیهای تولید شده بهطور تصادفی اجرا میکند. در صورت وجود هرگونه تخلف ادعایی، باید گزارشی با دادههای ورودی مشخص دریافت کنید که دارایی تحت ارزیابی را نقض میکند. برای شروع تست مبتنی بر ویژگی با ابزارهای مختلف، برخی از راهنماهای زیر را ببینید:
+
+- **[تجزیه و تحلیل استاتیک قراردادهای هوشمند با اسلیتر (Slither)](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)**
+- **[تجزیه و تحلیل استاتیک قراردادهای هوشمند با Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
+- **[تست مبتنی بر ویژگی با Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
+- **[قراردادهای فازی با فاندری (Foundry)](https://book.getfoundry.sh/forge/fuzz-testing)**
+- **[قراردادهای فازی با Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
+- **[قراردادهای فازی با ویک](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
+- **[اجرای نمادین قراردادهای هوشمند با مانتیکر (Manticore)](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
+- **[اجرای نمادین قراردادهای هوشمند با Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
+
+
+
+## تست دستی برای قراردادهای هوشمند {#manual-testing-for-smart-contracts}
+
+تست دستی قراردادهای هوشمند اغلب بعد از اجرای تستهای خودکار در چرخه توسعه انجام میشود. این شکل از تست قرارداد هوشمند را به عنوان یک محصول کاملاً یکپارچه ارزیابی میکند تا ببیند آیا مطابق با الزامات فنی مشخص شده است یا خیر.
+
+
+
+### تست قراردادها بر روی یک بلاک چین لوکال {#testing-on-local-blockchain}
+
+در حالی که تست خودکار انجام شده در یک محیط توسعه محلی یا لوکال میتواند اطلاعات مفیدی برای اشکال زدایی یا دیباگ کردن ارائه دهد، شما باید بدانید که قرارداد هوشمند شما در یک محیط تولید چگونه رفتار میکند. با این حال، استقرار یا دپلوی در زنجیره اصلی اتریوم مستلزم هزینههای گس است – ناگفته نماند که اگر قرارداد هوشمند شما همچنان دارای اشکال یا باگ باشد، شما یا کاربرانتان میتوانید پول واقعی خود را از دست بدهید.
+
+تست قرارداد خود بر روی یک بلاک چین محلی (همچنین به عنوان [شبکه توسعه](/developers/docs/development-networks/) نیز شناخته می شود) جایگزین توصیه شده برای آزمایش در شبکه اصلی است. یک بلاک چین محلی یک کپی از بلاک چین اتریوم است که به صورت محلی روی رایانه شما اجرا میشود و رفتار لایه اجرایی اتریوم را شبیهسازی میکند. به این ترتیب، میتوانید تراکنشها را طوری برنامهریزی کنید که با یک قرارداد تعامل داشته باشند، بدون اینکه هزینههای بیشتر قابلتوجهی را متحمل شوند.
+
+اجرای قراردادها بر روی یک بلاک چین محلی میتواند به عنوان نوعی تست ادغام دستی مفید باشد. [قراردادهای هوشمند بسیار قابل ترکیب هستند](/developers/docs/smart-contracts/composability/)، به شما امکان میدهد با پروتکلهای موجود ادغام کنید—اما همچنان باید اطمینان حاصل کنید که چنین بخش پیچیدهای در زنجیره فعل و انفعالات نتایج صحیح را ایجاد میکند.
+
+[اطلاعات بیشتر در مورد شبکههای توسعه.](/developers/docs/development-networks/)
+
+
+
+### تست قراردادها بر روی تست نتها یا شبکه آزمایشی {#testing-contracts-on-testnets}
+
+یک شبکه آزمایشی دقیقاً مانند شبکه اصلی اتریوم کار میکند، با این تفاوت که از اتر (ETH) بدون ارزش واقعی استفاده میکند. استقرار قرارداد خود در یک [شبکه آزمایشی](/developers/docs/networks/#ethereum-testnets) به این معنی است که هر کسی میتواند با آن تعامل داشته باشد (مثلاً از طریق فرانتاند برنامه غیرمتمرکز) بدون اینکه سرمایهای را در معرض خطر قرار دهد.
+
+این شکل از تست دستی برای ارزیابی جریان انتها به انتها برنامه شما از دیدگاه کاربر مفید است. در اینجا، آزمایشکنندههای بتا میتوانند اجرای آزمایشی را نیز انجام دهند و هرگونه مشکل در منطق تجاری و عملکرد کلی قرارداد را گزارش کنند.
+
+استقرار یا دپلوی در یک شبکه آزمایشی پس از تست بر روی یک بلاک چین محلی ایدهآل است زیرا مورد اول به رفتار ماشین مجازی اتریوم نزدیکتر است. بنابراین، برای بسیاری از پروژههای بومی اتریوم، استفاده از برنامههای غیرمتمرکز در شبکههای آزمایشی برای ارزیابی عملیات قراردادهای هوشمند در شرایط دنیای واقعی رایج است.
+
+[اطلاعات بیشتر در مورد شبکههای آزمایشی اتریوم.](/developers/docs/development-networks/#public-beacon-testchains)
+
+
+
+## تست در مقابل تأیید رسمی {#testing-vs-formal-verification}
+
+در حالی که تست کمک میکند تا تأیید شود که یک قرارداد نتایج مورد انتظار را برای برخی از ورودیهای داده برمیگرداند یا خیر، ولی نمیتواند به طور قطعی همان را برای ورودیهایی که در طول تست استفاده نشدهاند ثابت کند. بنابراین، تست یک قرارداد هوشمند نمیتواند «صحت عملکردی» را تضمین کند (یعنی نمیتواند نشان دهد که یک برنامه برای _همه_ مجموعههای مقادیر ورودی، آنطور که لازم است رفتار میکند).
+
+تأیید رسمی رویکردی برای ارزیابی صحت نرمافزار با بررسی اینکه آیا مدل رسمی برنامه با مشخصات رسمی مطابقت دارد یا خیر. یک مدل رسمی یک نمایش ریاضی انتزاعی از یک برنامه است، در حالی که یک مشخصات رسمی ویژگیهای یک برنامه را تعریف میکند (یعنی ادعاهای منطقی در مورد اجرای برنامه).
+
+از آنجایی که ویژگیها به صورت ریاضی نوشته شدهاند، میتوان تأیید کرد که یک مدل رسمی (ریاضی) سیستم با استفاده از قوانین منطقی استنتاج، مشخصاتی را برآورده میکند یا خیر. بنابراین، گفته میشود که ابزارهای تأیید رسمی «اثبات ریاضی» درستی یک سیستم را ارائه میدهند.
+
+برخلاف تست، تأیید رسمی میتواند برای تأیید اینکه اجرای قراردادهای هوشمند دارای مشخصات رسمی برای _همه_ اجراها است (یعنی بدون باگ) بدون نیاز به اجرای آن با نمونه دادهها استفاده شود. این مورد نه تنها زمان صرف شده برای اجرای دهها تست واحد را کاهش میدهد، بلکه در شناسایی آسیبپذیریهای پنهان نیز موثرتر است. گفتنی است، تکنیکهای تأیید رسمی بسته به دشواری اجرا و مفید بودنشان در طیفی قرار دارند.
+
+[بیشتر در مورد تأیید رسمی برای قراردادهای هوشمند.](/developers/docs/smart-contracts/formal-verification)
+
+
+
+## تست در مقابل ممیزی یا آدیت و پاداش باگ {#testing-vs-audits-bug-bounties}
+
+همانطور که ذکر شد، تست دقیق به ندرت میتواند عدم وجود اشکال یا باگ در قرارداد را تضمین کند. رویکردهای تأیید رسمی میتوانند تضمینهای قویتری از صحت ارائه دهند، اما در حال حاضر استفاده از آنها دشوار است و هزینههای قابل توجهی را متحمل میشود.
+
+با این وجود، میتوانید با بررسی کد مستقل، امکان شناسایی آسیبپذیریهای قرارداد را بیشتر کنید. [ممیزی یا آدیت قراردادهای هوشمند](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) و [پاداشهای باگ](https://medium. com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) دو راه برای ترغیب دیگران به تجزیه و تحلیل قراردادهای شما هستند.
+
+ممیزیها توسط حسابرسان با تجربه در یافتن موارد نقص امنیتی و شیوههای توسعه ضعیف در قراردادهای هوشمند انجام میشود. ممیزی معمولاً شامل تست (و احتمالاً تأیید رسمی) و همچنین بررسی دستی کل پایگاه کد است.
+
+برعکس، برنامه پاداش باگ معمولاً شامل ارائه پاداش مالی به یک فرد است (که معمولاً به عنوان [هکرهای کلاه سفید](https://en.wikipedia.org/wiki/White_hat_(computer_security)) توصیف میشود) یک آسیبپذیری را در یک قرارداد هوشمند کشف کرده و آن را برای توسعهدهندگان فاش میکند. پاداش باگ مشابه ممیزی یا آدیت است زیرا شامل درخواست از دیگران برای کمک به یافتن نقص در قراردادهای هوشمند است.
+
+تفاوت عمده این است که برنامههای پاداش باگ برای جامعه توسعهدهندگان/هکرهای گستردهتر باز است و طبقه وسیعی از هکرهای اخلاقی و متخصصان امنیتی مستقل را با مهارتها و تجربههای منحصربهفرد جذب میکنند. این مورد ممکن است یک مزیت نسبت به ممیزی یا آدیت قراردادهای هوشمند باشد که عمدتاً به تیمهایی متکی است که ممکن است تخصص محدودی داشته باشند.
+
+
+
+## کتابخانهها و ابزارهای آزمایش {#testing-tools-and-libraries}
+
+
+
+### ابزار تست واحد {#unit-testing-tools}
+
+- **[کاورج یا پوشش سالیدیتی](https://github.com/sc-forks/solidity-coverage)** - _ابزار پوشش کد برای قراردادهای هوشمند نوشته شده در سالیدیتی است._
+
+- **[وافل](https://ethereum-waffle.readthedocs.io/en/latest/)** - *چارچوبی برای توسعه و تست قراردادهای هوشمند پیشرفته (بر اساس ethers.js) است*.
+
+- **[تستهای ریمیکس](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _ابزاری برای آزمایش قراردادهای هوشمند سالیدیتی است. در زیر پلاگین ریمیکس "Solidity Unit Testing" کار میکند که برای نوشتن و اجرای موارد تست برای قرارداد استفاده میشود._
+
+- **[کمککننده تست اوپن زپلین](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _کتابخانه ازرشن برای تست قرارداد هوشمند اتریوم. مطمئن شوید که قراردادهای شما مطابق انتظار عمل می کند!_
+
+- **[فریم ورک تست واحد براونی](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _براونی از Pytest استفاده میکند، یک فریم ورک تستی غنی از ویژگیها که به شما امکان میدهد تستهای کوچک را با حداقل کد بنویسید و برای پروژههای بزرگ مقیاسپذیری خوبی دارد و بسیار قابل توسعه است._
+
+- **[تستهای فاندری ](https://github.com/foundry-rs/foundry/tree/master/forge)** - _Foundry Forge را ارائه میکند، یک فریم ورک آزمایشی سریع و انعطافپذیر اتریوم که قادر به اجرای آزمایشهای واحد ساده، بررسیهای بهینهسازی گس و فازبندی قرارداد است._
+
+- **[تستهای هاردهت](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _چارچوبی برای آزمایش قراردادهای هوشمند مبتنی بر ethers.js، موکا و چای است._
+
+- **[ایپ ورکس](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _چارچوب توسعه و آزمایش مبتنی بر پایتون برای قراردادهای هوشمند با هدف قرار دادن ماشین مجازی اتریوم است._
+
+- **[ویک](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _چارچوب مبتنی بر پایتون برای آزمایش واحد و فازی کردن با قابلیتهای اشکالزدایی قوی و پشتیبانی از آزمایش زنجیرهای متقابل، استفاده از pytest و Anvil برای بهترین تجربه و عملکرد کاربر است._
+
+
+
+### ابزارهای تست مبتنی بر ویژگی {#property-based-testing-tools}
+
+
+
+#### ابزارهای تحلیل استاتیکی {#static-analysis-tools}
+
+- **[Slither](https://github.com/crytic/slither)** - _Python- فریم ورک تجزیه و تحلیل استاتیک سالیدیتی برای یافتن آسیبپذیریها، بهبود درک کد و نوشتن تحلیلهای سفارشی برای قراردادهای هوشمند._
+
+- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _دریچهای برای اعمال بهترین شیوهها و شیوههای امنیتی برای زبان برنامه نویسی قرارداد هوشمند سالیدیتی است._
+
+- **[سایفرین آدرین](https://cyfrin.io/tools/aderyn)** - _تحلیلگر استاتیک مبتنی بر استاتیک که به طور خاص برای امنیت و توسعه قراردادهای هوشمند وب3 طراحی شده است._
+
+- **[ویک](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - < em x-id="4">چارچوب تحلیل استاتیک مبتنی بر پایتون با آشکارسازهای آسیبپذیری و کیفیت کد، چاپگرهایی برای استخراج اطلاعات مفید از کد و پشتیبانی برای نوشتن زیرماژولهای سفارشی.
+
+
+
+#### ابزارهای تحلیل پویا {#dynamic-analysis-tools}
+
+- **[اکیدنا](https://github.com/crytic/echidna/)** - _فازر سریع قرارداد برای شناسایی آسیبپذیریها در قراردادهای هوشمند از طریق تست مبتنی بر دارایی است._
+
+- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _ابزار فازینگ خودکار برای تشخیص تخلفات دارایی در کد قرارداد هوشمند مفید است._
+
+- **[مانتیکر](https://manticore.readthedocs.io/en/latest/index.html)** - _فریم ورک اجرای نمادین پویا برای تجزیه و تحلیل بایت کد ماشین مجازی اتریوم است._
+
+- **[میثریل (Mythril)](https://github.com/ConsenSys/mythril-classic)** - _ ابزار ارزیابی بایت کد ماشین مجازی اتریوم برای شناسایی آسیبپذیریهای قرارداد با استفاده از تجزیه و تحلیل تینت، تجزیه و تحلیل کونکولیک، و بررسی جریان کنترل است._
+
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _ Scribble یک زبان مشخصات و ابزار تأیید زمان اجرا است که به شما امکان میدهد قراردادهای هوشمند را با ویژگیهایی حاشیه نویسی کنید که به شما امکان میدهد به طور خودکار قراردادها را با ابزارهایی مانند Diligence Fuzzing یا MythX تست کنید._
+
+
+
+## آموزشهای مرتبط {#related-tutorials}
+
+- [نمای کلی و مقایسه محصولات تست مختلف](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
+- [نحوه استفاده از Echidna برای آزمایش قراردادهای هوشمند](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
+- [نحوه استفاده از Manticore برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+- [نحوه استفاده از Slither برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+- [چگونه قراردادهای Solidity را برای آزمایش شبیه سازی کنیم](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [نحوه اجرای تست های واحد در سالیدیتی با استفاده از Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [راهنمای عمیق برای تست قراردادهای هوشمند اتریوم](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
+- [نحوه تست قراردادهای هوشمند اتریوم](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
+- [راهنمای تست واحد مولوک دائو (MolochDAO) برای توسعه دهندگان](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
+- [نحوه تست قراردادهای هوشمند مانند یک حرفهای](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
new file mode 100644
index 00000000000..0e913098cac
--- /dev/null
+++ "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
@@ -0,0 +1,165 @@
+---
+title: ارتقای قراردادهای هوشمند
+description: نگاهی کلی به الگوهای ارتقا برای قراردادهای هوشمند اتریوم
+lang: fa
+---
+
+قراردادهای هوشمند در اتریوم برنامههای خودکاری هستند که در ماشین مجازی اتریوم (EVM) اجرا میشوند. این برنامه ها از نظر طراحی تغییر ناپذیر هستند که از هرگونه بهروز رسانی منطق تجاری پس از پیادهسازی و استقرار قرارداد جلوگیری می کند.
+
+در حالی که این تغییرناپذیری برای حداقل سازی اعتماد، عدم تمرکز و امنیت قراردادهای هوشمند ضروریاند، ممکن است در برخی موارد مشکلاتی ایجاد کنند. برای مثال، کد تغییرناپذیر باعث میشود تا اصلاح کد قرارداد هوشمندی که دارای نقص امنیتی است امکانناپذیر شود.
+
+با این حال، افزایش تحقیقات در مورد بهبود قراردادهای هوشمند منجر به معرفی چندین الگوی ارتقاء شده است. این الگوهای ارتقاء به توسعه دهندگان این امکان را می دهد تا با قرار دادن منطق تجاری در قراردادهای مختلف، قراردادهای هوشمند را (در عین حفظ تغییر ناپذیری) ارتقا دهند.
+
+## پیشنیازها {#prerequisites}
+
+شما باید درک خوبی از [قراردادهای هوشمند](/developers/docs/smart-contracts/)، [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) و [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) داشته باشید. این راهنما همچنین فرض میکند که خوانندگان درک درستی از برنامهنویسی قراردادهای هوشمند دارند.
+
+## ارتقاء قرارداد هوشمند چیست؟ {#what-is-a-smart-contract-upgrade}
+
+ارتقای قرارداد هوشمند شامل تغییر منطق تجاری یک قرارداد هوشمند و در عین حال حفظ وضعیت قرارداد است. واضح است که قابلیت ارتقا و تغییرپذیری یکسان نیستند، به خصوص در زمینه قراردادهای هوشمند.
+
+شما هنوز نمی توانید یک برنامه مستقر شده را به آدرسی در شبکه اتریوم تغییر دهید. اما میتوانید کدی را که هنگام تعامل کاربران با یک قرارداد هوشمند اجرا میشود، تغییر دهید.
+
+این کار از طریق روش های زیر قابل انجام است:
+
+1. ایجاد چندین نسخه از یک قرارداد هوشمند و انتقال حالت (یعنی داده ها) از قرارداد قدیمی به نمونه جدیدی از قرارداد.
+
+2. ایجاد قراردادهای جداگانه برای ذخیره کردن منطق تجاری و حالت.
+
+3. استفاده از الگوهای پراکسی برای واگذاری فراخوانی های تابع از یک قرارداد پروکسی تغییرناپذیر به یک قرارداد منطقی قابل تغییر.
+
+4. ایجاد یک قرارداد اصلی تغییر ناپذیر که با قراردادهای ماهواره ای انعطاف پذیر برای اجرای عملکردهای خاص ارتباط برقرار می کند و به آنها متکی است.
+
+5. استفاده از الگوی الماس برای واگذاری فراخوانی های تابع از یک قرارداد پراکسی به قراردادهای منطقی.
+
+### مکانیسم ارتقا شماره 1: انتقال قرارداد {#contract-migration}
+
+انتقال قرارداد مبتنی بر نسخه سازی است - ایده ایجاد و مدیریت حالت های منحصر به فرد یک نرم افزار. انتقال قرارداد شامل استقرار یک نمونه جدید از یک قرارداد هوشمند موجود و انتقال ذخیره و موجودی به قرارداد جدید است.
+
+قراردادی که به تازگی مستقر شده است یک فضای ذخیره خالی خواهد داشت که به شما امکان می دهد داده ها را از قرارداد قدیمی بازیابی کنید و آن را در پیاده سازی جدید بنویسید. پس از آن، باید همه قراردادهایی را که با قرارداد قدیمی در تعامل بودند، بهروزرسانی کنید تا نشانی جدید را منعکس کنند.
+
+آخرین مرحله در انتقال قرارداد متقاعد کردن کاربران برای تغییر استفاده از قرارداد جدید است. نسخه جدید قرارداد تعادل و آدرس های کاربر را حفظ می کند که تغییر ناپذیری را حفظ می کند. اگر این قرارداد مبتنی بر توکن است، همچنین باید با صرافیها تماس بگیرید تا قرارداد قدیمی را کنار بگذارید و از قرارداد جدید استفاده کنید.
+
+انتقال قرارداد یک اقدام نسبتاً ساده و ایمن برای ارتقاء قراردادهای هوشمند بدون ایجاد اختلال در تعاملات کاربر است. با این حال، انتقال دستی ذخیره سازی و موجودی کاربر به قرارداد جدید زمان بر است و می تواند کارمزد گس زیادی را به همراه داشته باشد.
+
+[اطلاعات بیشتر در مورد انتقال قرارداد.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
+
+### مکانیسم ارتقاء شماره 2: جداسازی داده ها {#data-separation}
+
+روش دیگر برای ارتقای قراردادهای هوشمند، تفکیک منطق تجاری و ذخیره داده ها به قراردادهای جداگانه است. این بدان معنی است که کاربران با قرارداد منطقی تعامل دارند، در حالی که داده ها در قرارداد ذخیره سازی ذخیره می شوند.
+
+قرارداد منطقی شامل کدی است که هنگام تعامل کاربران با برنامه اجرا می شود. همچنین آدرس قرارداد ذخیره سازی را نگه می دارد و برای دریافت و تنظیم داده ها با آن تعامل دارد.
+
+در همین حال، قرارداد ذخیره سازی وضعیت مرتبط با قرارداد هوشمند، مانند موجودی ها و آدرس های کاربر را حفظ می کند. توجه داشته باشید که قرارداد ذخیره سازی متعلق به قرارداد منطقی است و با آدرس دومی در هنگام استقرار پیکربندی شده است. این امر از تماس قراردادهای غیرمجاز با قرارداد ذخیره سازی یا به روز رسانی داده های آن جلوگیری می کند.
+
+بهطور پیشفرض، قرارداد ذخیرهسازی تغییر ناپذیر است، اما میتوانید قرارداد منطقی را که به آن اشاره میکند با یک پیادهسازی جدید جایگزین کنید. با این کار کدی که در EVM اجرا میشود، تغییر میکند، در حالی که فضای ذخیرهسازی و تعادل را دست نخورده نگه میدارد.
+
+استفاده از این روش ارتقا مستلزم بروز رسانی آدرس قرارداد منطقی در قرارداد ذخیره سازی است. همچنین به دلایلی که قبلا توضیح داده شد، باید قرارداد منطقی جدید را با آدرس قرارداد ذخیره سازی پیکربندی کنید.
+
+پیاده سازی الگوی جداسازی داده ها در مقایسه با انتقال قرارداد ساده تر است. با این حال، باید چندین قرارداد را مدیریت کنید و طرحهای مجوز پیچیده را برای محافظت از قراردادهای هوشمند در برابر ارتقاهای مخرب اجرا کنید.
+
+### مکانیسم ارتقاء شماره 3: الگوهای پراکسی {#proxy-patterns}
+
+الگوی پراکسی همچنین از جداسازی داده ها برای حفظ منطق تجاری و داده ها در قراردادهای جداگانه استفاده می کند. با این حال، در یک الگوی پراکسی، قرارداد ذخیرهسازی (به نام پراکسی) قرارداد منطقی را در طول اجرای کد فراخوانی می کند. این روش برعکس روش جداسازی داده است، که در آن قرارداد منطقی قرارداد ذخیره سازی را فرامیخواند.
+
+این چیزی است که در یک الگوی پراکسی اتفاق می افتد:
+
+1. کاربران با قرارداد پراکسی تعامل دارند، که دادهها را ذخیره میکند، اما منطق تجاری را حفظ نمیکند.
+
+2. قرارداد پراکسی آدرس قرارداد منطقی را ذخیره می کند و تمام فراخوانی های تابع را با استفاده از تابع `delegatecall` به قرارداد منطقی (که منطق تجاری را نگه می دارد) واگذار می کند.
+
+3. پس از ارسال فراخوانی به قرارداد منطقی، داده های برگشتی از قرارداد منطقی بازیابی شده و به کاربر بازگردانده می شود.
+
+استفاده از الگوهای پراکسی نیاز به درک عملکرد **delegatecall** دارد. اساساً، `delegatecall` یک کد عملیاتی است که به یک قرارداد اجازه میدهد قرارداد دیگری را فراخوانی کند، در حالی که اجرای کد واقعی در متن قرارداد فراخوانی اتفاق میافتد. مفهوم استفاده از `delegatecall` در الگوهای پراکسی این است که قرارداد پراکسی در حافظه خود می خواند و می نویسد و منطق ذخیره شده در قرارداد منطقی را اجرا می کند که گویی در حال فراخوانی یک تابع داخلی است.
+
+از [اسناد سالیدیتی](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries):
+
+> _نوع خاصی از تماس پیام وجود دارد، به نام **delegatecall** که با فراخوانی پیام یکسان است، صرف نظر از این که کد در آدرس مورد نظر در متن (یعنی در آدرس) اجرا می شود قرارداد فراخوانی و `msg.sender` و `msg.value` مقادیر خود را تغییر نمی دهند._ _این بدان معناست که یک قرارداد می تواند به صورت پویا کد را از آدرسی متفاوت در زمان اجرا بارگیری کند. محل ذخیره، آدرس فعلی و موجودی همچنان به قرارداد فراخوانی استناد میکنند، فقط کد از آدرس فراخوانی گرفته میشود._
+
+قرارداد پراکسی میداند که هر زمان که کاربر تابعی را فراخوانی میکند، `delegatecall` را فراخوانی میکند زیرا یک تابع `fallback` در آن تعبیه شده است. در برنامه نویسی سالیدیتی، [تابع fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) زمانی اجرا می شود که یک فراخوانی تابع با توابع مشخص شده در قرارداد مطابقت نداشته باشد.
+
+برای کارکرد الگوی پراکسی نیاز به نوشتن یک تابع بازگشتی سفارشی است که مشخص میکند قرارداد پراکسی چگونه باید فراخوانیهای تابعی را که پشتیبانی نمیکند مدیریت کند. در این مورد، تابع fallback پراکسی برای شروع یک فراخوانی واگذاری و تغییر مسیر درخواست کاربر به اجرای قرارداد منطقی فعلی برنامه ریزی شده است.
+
+قرارداد پراکسی به طور پیش فرض تغییر ناپذیر است، اما قراردادهای منطقی جدید با منطق تجاری به روز شده می توانند ایجاد شوند. در این صورت انجام ارتقاء به تغییر آدرس قرارداد منطقی اشاره شده در قرارداد پراکسی بستگی دارد.
+
+با اشاره قرارداد پراکسی به یک قرارداد منطقی جدید، کد اجرا شده هنگام فراخوانی تابع قرارداد پراکسی تغییر می کند. این به ما امکان میدهد تا منطق قرارداد را بدون درخواست از کاربران برای تعامل با یک قرارداد جدید ارتقا دهیم.
+
+الگوهای پراکسی روشی محبوب برای ارتقای قراردادهای هوشمند هستند زیرا مشکلات مربوط به انتقال قرارداد را از بین می برند. با این حال، استفاده از الگوهای پراکسی پیچیدهتر است و در صورت استفاده نادرست، میتواند نقصهای مهمی مانند [برخورد انتخابگر تابع](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) ایجاد کند.
+
+[اطلاعات بیشتر در مورد الگوهای پراکسی](https://blog.openzeppelin.com/proxy-patterns/).
+
+### مکانیسم ارتقاء شماره 4: الگوی استراتژی {#strategy-pattern}
+
+این تکنیک تحت تأثیر [الگوی استراتژی](https://en.wikipedia.org/wiki/Strategy_pattern) است، که ایجاد برنامههای نرمافزاری را تشویق میکند که با برنامههای دیگر برای پیادهسازی ویژگیهای خاص ارتباط برقرار کنند. اعمال الگوی استراتژی برای توسعه اتریوم به معنای ساخت یک قرارداد هوشمند است که توابع قراردادهای دیگر را فراخوانی می کند.
+
+قرارداد اصلی در این مورد حاوی منطق اصلی تجارت است، اما با سایر قراردادهای هوشمند ("قراردادهای ماهواره ای") برای اجرای عملکردهای خاص ارتباط برقرار می کند. این قرارداد اصلی همچنین آدرس هر قرارداد اقماری را ذخیره می کند و می تواند بین پیاده سازی های مختلف قرارداد اقماری جابجا شود.
+
+می توانید یک قرارداد اقماری جدید بسازید و قرارداد اصلی را با آدرس جدید پیکربندی کنید. این به شما امکان میدهد _استراتژیها_ (یعنی اجرای منطق جدید) را برای یک قرارداد هوشمند تغییر دهید.
+
+اگرچه شبیه به الگوی پراکسی که قبلاً مورد بحث قرار گرفت، الگوی استراتژی متفاوت است زیرا قرارداد اصلی که کاربران با آن تعامل دارند، منطق تجاری را حفظ می کند. استفاده از این الگو به شما این فرصت را می دهد که تغییرات محدودی را در یک قرارداد هوشمند بدون تأثیر بر زیرساخت اصلی ایجاد کنید.
+
+اشکال اصلی این است که این الگو بیشتر برای بهروزرسانیهای جزئی مفید است. همچنین، اگر قرارداد اصلی به خطر بیفتد (به عنوان مثال، از طریق هک)، نمی توانید از این روش ارتقا استفاده کنید.
+
+### مکانیسم ارتقاء شماره 5: الگوی الماس {#diamond-pattern}
+
+الگوی الماس را می توان بهبود در الگوی پروکسی در نظر گرفت. الگوهای الماس با الگوهای پراکسی متفاوت هستند زیرا قرارداد پروکسی الماس می تواند فراخوانی های تابع را به بیش از یک قرارداد منطقی واگذار کند.
+
+قراردادهای منطقی در الگوی الماس به عنوان _فاست_ شناخته می شوند. برای اینکه الگوی الماس کار کند، باید در قرارداد پراکسی یک نقشه برداری ایجاد کنید که [انتخابگرهای تابع](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) را به آدرسهای جنبههای مختلف نگاشت میکند.
+
+هنگامی که یک کاربر یک تابع را فراخوانی می کند، قرارداد پراکسی نگاشت را بررسی می کند تا فاست مسئول اجرای آن تابع را پیدا کند. سپس `delegatecall` را فراخوانی میکند (با استفاده از تابع fallback) و فراخوانی را به قرارداد منطقی مناسب هدایت میکند.
+
+الگوی ارتقاء الماس دارای مزایایی نسبت به الگوهای ارتقاء پراکسی سنتی است:
+
+1. این به شما امکان می دهد بخش کوچکی از قرارداد را بدون تغییر تمام کد ارتقا دهید. استفاده از الگوی پراکسی برای ارتقاء مستلزم ایجاد یک قرارداد منطقی کاملاً جدید است، حتی برای ارتقاهای جزئی.
+
+2. همه قراردادهای هوشمند (از جمله قراردادهای منطقی مورد استفاده در الگوهای پراکسی) دارای محدودیت اندازه 24 کیلوبایت هستند که می تواند یک محدودیت باشد – به خصوص برای قراردادهای پیچیده که به عملکردهای بیشتری نیاز دارند. الگوی الماس حل این مشکل را با تقسیم توابع در چندین قرارداد منطقی آسان می کند.
+
+3. الگوهای پراکسی یک رویکرد همه جانبه را برای کنترل های دسترسی اتخاذ می کنند. یک نهاد با دسترسی به توابع ارتقا میتواند قرارداد _کل_ را تغییر دهد. اما الگوی الماس یک رویکرد مجوزهای مدولار را فعال می کند، که در آن می توانید موجودیت ها را به ارتقاء عملکردهای خاص در یک قرارداد هوشمند محدود کنید.
+
+[اطلاعات بیشتر در مورد الگوی الماس](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
+
+## مزایا و معایب ارتقای قراردادهای هوشمند {#pros-and-cons-of-upgrading-smart-contracts}
+
+| نقاط مثبت | نقاط منفی |
+| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ارتقای قرارداد هوشمند میتواند رفع آسیبپذیریهای کشف شده در مرحله پس از استقرار را آسانتر کند. | ارتقای قراردادهای هوشمند، ایده تغییرناپذیری کد را که پیامدهایی برای تمرکززدایی و امنیت دارد، نفی میکند. |
+| توسعه دهندگان می توانند از ارتقاء منطقی برای افزودن ویژگی های جدید به برنامه های غیرمتمرکز استفاده کنند. | کاربران باید به توسعه دهندگان اعتماد کنند که قراردادهای هوشمند را خودسرانه تغییر ندهند. |
+| ارتقاء قراردادهای هوشمند می تواند ایمنی را برای کاربران نهایی بهبود بخشد زیرا باگ ها را می توان به سرعت برطرف کرد. | برنامه نویسی عملکرد ارتقاء به قراردادهای هوشمند لایه دیگری از پیچیدگی را اضافه می کند و احتمال نقص های مهم را افزایش می دهد. |
+| ارتقاء قرارداد به توسعه دهندگان فضای بیشتری برای آزمایش ویژگی های مختلف و بهبود دپ ها در طول زمان می دهد. | فرصت ارتقای قراردادهای هوشمند ممکن است توسعهدهندگان را تشویق کند پروژهها را سریعتر راهاندازی کنند بدون اینکه در مرحله توسعه دقت لازم را انجام دهند. |
+| | کنترل دسترسی ناامن یا متمرکز شدن در قراردادهای هوشمند میتواند بهروزرسانیهای غیرمجاز را برای عوامل مخرب آسانتر کند. |
+
+## ملاحظات ارتقای قراردادهای هوشمند {#considerations-for-upgrading-smart-contracts}
+
+1. برای جلوگیری از ارتقاء قراردادهای هوشمند غیرمجاز، به ویژه اگر از الگوهای پراکسی، الگوهای استراتژی یا جداسازی داده ها استفاده می شود، از مکانیسم های کنترل دسترسی/مجوز دسترسی ایمن استفاده کنید. یک مثال محدود کردن دسترسی به عملکرد ارتقاء است، طوری که فقط مالک قرارداد می تواند آن را فراخوانی کند.
+
+2. ارتقای قراردادهای هوشمند یک فعالیت پیچیده است و برای جلوگیری از معرفی آسیبپذیریها نیاز به دقت بالایی دارد.
+
+3. کاهش مفروضات اعتماد با تمرکززدایی از فرآیند اجرای ارتقاء. استراتژیهای احتمالی شامل استفاده از [قرارداد کیف پول چند امضایی](/developers/docs/smart-contracts/#multisig) برای کنترل ارتقاء، یا الزام [اعضای DAO](/dao/) برای رای دادن به تایید ارتقاء است.
+
+4. از هزینه های مربوط به ارتقاء قراردادها آگاه باشید. به عنوان مثال، کپی کردن حالت (به عنوان مثال، موجودی کاربر) از یک قرارداد قدیمی به یک قرارداد جدید در طول انتقال قرارداد ممکن است به بیش از یک تراکنش نیاز داشته باشد، به این معنی که کارمزدهای گس بیشتر است.
+
+5. برای محافظت از کاربران، **قفل های زمانی** را در نظر بگیرید. قفل زمانی به تاخیر اعمال شده در تغییرات یک سیستم اشاره دارد. قفلهای زمانی را میتوان با یک سیستم حاکمیت چند امضایی برای کنترل ارتقاها ترکیب کرد: اگر یک اقدام پیشنهادی به آستانه تأیید لازم برسد، تا زمانی که دوره تاخیر از پیش تعریفشده سپری نشود، اجرا نمیشود.
+
+قفلهای زمانی به کاربران در صورت مخالفت با تغییر پیشنهادی (مثلاً ارتقاء منطقی یا طرحهای هزینه جدید) مدتی زمان میدهند تا از سیستم خارج شوند. بدون قفل زمانی، کاربران باید به توسعه دهندگان اعتماد کنند تا بدون اطلاع قبلی تغییرات دلخواه را در یک قرارداد هوشمند اعمال نکنند. اشکال در اینجا این است که قفل های زمانی توانایی اصلاح سریع آسیب پذیری ها را محدود می کنند.
+
+## منابع {#resources}
+
+**پلاگین های ارتقاء OpenZeppelin - _مجموعه ای از ابزارها برای استقرار و ایمنسازی قراردادهای هوشمند قابل ارتقا._**
+
+- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-upgrades)
+- [اسناد](https://docs.openzeppelin.com/upgrades)
+
+## آموزشها {#tutorials}
+
+- [به روز رسانی قراردادهای هوشمند | آموزش یوتیوب](https://www.youtube.com/watch?v=bdXJmWajZRY) از پاتریک کالینز
+- [آموزش انتقال قرارداد هوشمند اتریوم](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) توسط آستین گریفیث
+- [استفاده از الگوی پراکسی UUPS برای ارتقاء قراردادهای هوشمند](https://blog.logrocket.com/author/praneshas/) از Pranesh A.S
+- [آموزش Web3: نوشتن قرارداد هوشمند قابل ارتقا (پراکسی) با استفاده از OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) از fangjun.eth
+
+## بیشتر بخوانید {#further-reading}
+
+- [حالت ارتقاهای قرارداد هوشمند](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) از سانتیاگو پالادینو
+- [روش های متعدد برای ارتقاء قرارداد هوشمند سالیدیتی](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - وبلاگ Crypto Market Pool
+- [بیاموزید: ارتقای قراردادهای هوشمند](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - در اسناد OpenZeppelin
+- [الگوهای پراکسی برای ارتقای قراردادهای سالیدیتی: شفاف در مقابل پروکسی های UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) از نوین ساهو
+- [ ارتقاء الماس چگونه کار می کند](https://dev.to/mudgen/how-diamond-upgrades-work-417j) از نیک ماج
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
new file mode 100644
index 00000000000..b88037cb5e7
--- /dev/null
+++ "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
@@ -0,0 +1,119 @@
+---
+title: تأیید کردن قراردادهای هوشمند
+description: نگاهی بر تائید کردن کد قراردادهای هوشمند اتریوم
+lang: fa
+---
+
+[قراردادهای هوشمند](/developers/docs/smart-contracts/) به گونه ای طراحی شده اند که بی نیاز از اطمینان باشند، به این معنی که کاربرها پیش از برقراری ارتباط با یک کانترکت، نیازی نباشد به شخص یا اشخاص سوم شخص(خواه توسعه دهنده و خواه شرکت ها) اعتماد کنند. به عنوان یکی از نیازمندی های بی نیازی از اعتماد، کاربران و همینطور سایر توسعه دهنده باید بتوانند به راحتی به کدهای قراردادهای هوشمند دسترسی داشته باشند تا عملکرد آنها را بررسی و تائید کنند. وریفای یا تائید کد قرارداد هوشمند، این اطمینان خاطر را به کاربران و توسعه دهندگان میدهد که کد منتشر شده از قرارداد هوشمند، دقیقاً همان کدی است که در آدرس آن قرارداد بر بستر بلاکچین اتریوم وجود دارد.
+
+نکته مهمی که وجود دارد این است که باید بین تائید کردن کد و [تائید رسمی](/developers/docs/smart-contracts/formal-verification/) تمایز قائل شد. تائید کردن کد، که در ادامه به تفصیل آن را شرح خواهیم داد، به عملیاتی اطلاق میشود که کدهای یک قرارداد هوشمند در یک زبان سطح بالا (مثل سالیدیتی) دقیقاً به همان بایت کد اجرایی قرارداد هوشمند کامپایل شود. ولی تائید رسمی به توضیح صحیح بودن قرارداد هوشمند مطابق با عملکرد مورد انتظار میپردازد. اگرچه در مفاهیمی که در حال صحبت از آن هستیم، وریفای یا تائید کردن قرارداد عموماً به تائید کدها اطلاق میشود.
+
+## تائید کد چیست؟ {#what-is-source-code-verification}
+
+پیش از دیپلوی یک قرارداد هوشمند در [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)، توسعه دهنده ها کد قرارداد-دستورالعملهای [نوشته شده به زبان سالیدیتی](/developers/docs/smart-contracts/compiling/) یا سایر زبان های سطح بالا- را به بایت کد [کامپایل](/developers/docs/smart-contracts/languages/) می کنند. از آنجایی که EVM توانایی تفسیر دستورات سطح بالا را ندارد، به منظور اجرای منطق قرارداد بر روی EVM، کامپایل کردن کدها به بایت کد(دستورات سطح پایین و قابل درک برای ماشین) ضروری است.
+
+تائید کردن کد به معنای مقایسه ی کد قرارداد هوشمند و بایت کد کامپایل شده ای که در زمان ساخته شدن قرارداد استفاده میشود، و به منظور شناسایی هرگونه تفاوت می باشد. تائید کردن قرارداد هوشمند از این جهت حائز اهمیت است که کد قرارداد تبلیغ شده، ممکن است با آنچه که در حال اجرا بر روی بلاکچین است متفاوت باشد.
+
+تائید قرارداد هوشمند امکان بررسی و تحقیق کاری که قرارداد انجام می دهد را از طریق خواندن کدهای سطح بالا و بدون نیاز به خواندن کدهای ماشین فراهم می سازد. توابع، مقادیر، و عموماً اسامی متغیرها و کامنت ها عیناً مطابق کد اصلی ای هستند که قرارداد با آنها کامپایل و دیپلوی شده است. این موضوع، خواندن کد را بسیار راحت تر می کند. تائید کد، همچنین مستندات کد را فراهم آوری می کند و باعث میشود تا کاربران نهایی بتوانند متوجه شوند که قرارداد هوشمند مربوطه برای چه کاری طراحی شده است.
+
+### تائید کامل چیست؟ {#full-verification}
+
+بخش هایی از قرارداد هوشمند، از جمله کامنت ها یا اسامی متغیرها بر روی بایت کدهای کامپایل شده تاثیری ندارند. این موضوع بدین معناست که دو کد مختلف، با اسامی متغیر و همینطور کامنت های متفاوت، می توانند توسط یک قرارداد یکسان تائید شوند. با استفاده از این مسئله، یک کاربر بداندیش، می تواند با افزودن کامنت های فریبنده و یا نام گذاری گمراه کننده نام متغیرها در کد، کدی متفاوت از کد اصلی را تائید کند.
+
+به منظور جلوگیری از این اتفاق، می توان با افزودن یک داده اضافه به بایت کد که در حکم یک _تضمین رمزنگاری_ و به عنوان _ اثر انگشت_ عملیات کامپایل برای همسان بودن کد می باشد اقدام نمود. اطلاعات ضروری در [داده های متای قرارداد سالیدیتی](https://docs.soliditylang.org/en/v0.8.15/metadata.html) قابل دستیابی است، همچنین هش این فایل نیز به بایت کد قرارداد الحاق میشود. این مورد را می توانید به طور عملیاتی در [فضای بازی داده های متا](https://playground.sourcify.dev) مشاهده کنید
+
+فایل داده های متا یا متادیتا، حاوی اطلاعاتی در خصوص کامپایل شدن قرارداد هوشمند و شامل کدها و هش آنها می باشد. این بدین معناست که در صورت رخ دادن کوچکترین تغییری در تنظیمات کامپایل و یا حتی تغییر در یک بایت از کدها، فایل متادیتا تغییر خواهد کرد. همچنین متعاقباً، هش فایل متادیتا که به بایت کد الحاق شده است نیز تغییر خواهد کرد. این بدین معناست که اگر بایت کد یک قرارداد + هش متادیتای الحاص شده به آن، با کد داده شده و تنظیمات کامپایل یکسان باشد، می توانیم کاملاً مطمئن باشیم که حتی یک بایت نیز تغییری نکرده و این کد، کد اصلی کامپایل شده می باشد.
+
+به این نوع از تائید که از هش متادیتا بهره می برد، اصطلاحاً **[تائید کامل](https://docs.sourcify.dev/docs/full-vs-partial-match/)** (همچنین "تائید بی نقص") گفته می شود. اگر هش های متادیتا یکسان نبوده و یا به عنوان تائید شده نباشند، به آن "تطابق جزئی" گفته می شود، که در حال حاضر رایج ترین شیوه در تائید قراردادهاست. در صورتی که عملیات تائید کردن به صورت کامل نباشد، این امکان وجود دارد که [کد مخربی به قرارداد وارد شود](https://samczsun.com/hiding-in-plain-sight/) که در کد تائید شده قابل مشاهده نباشد. بیشتر توسعه دهنده ها از وجود تائیدیه کامل بی اطلاع اند و فایل متادیتای کامپایل خود را نگهداری نمی کنند، از این رو، عملاً تاکنون تائید جزئی به عنوان روش تائید قراردادها مورد استفاده قرار میگیرد.
+
+## چرا تائید کد مهم است؟ {#importance-of-source-code-verification}
+
+### بی نیازی از اعتماد {#trustlessness}
+
+بدون شک، بی نیازی از اعتماد یکی از بزرگترین وعده های قراردادهای هوشمند و [اپلیکیشن های غیرمتمرکز(dappها)](/developers/docs/dapps/) است. قراردادهای هوشمند "تغییر ناپذیر" بوده و امکان عوض کردن ندارند؛ یک قرارداد، تنها مسئول اجرای منطق کاری است که در زمان دیپلوی شدن، در کدش تعریف شده است. این موضوع به این معناست که توسعه دهندهها و شرکتها(و البته قابل بسط به سایر افراد نیز می باشد)، پس از دیپلوی(استقرار) بر روی شبکه اتریوم، نمیتوانند تغییری در کد قرارداد ایجاد کنند.
+
+به منظور بی نیاز بودن از اعتماد در یک قرارداد هوشمند، کد قرارداد باید جهت تائید شدن به صورت مستقل، قابل دسترس باشد. اگرچه بایتکد کامپایل شده ی قراردادهای هوشمند بهصورت عمومی بر روی بلاکچین قابل دسترسی است، اما درک زبان سطح پایین، هم برای توسعه دهنده ها و هم کاربران عادی سخت است.
+
+به منظور کاهش گمانه زنی ها در خصوص اعتمادپذیری، پروژه ها کد قراردادهای خود را منتشر می کنند. اما همین موضوع، باعث ایجاد یک مشکل دیگر می شود: تائید همسان بودن کد منتشر شده با بایت کدهای قرارداد مربوطه، سخت است. در این سناریو، بدلیل اینکه کاربران باید به توسعه دهنده اعتماد کنند که منطق کاری قرارداد (با تغییر دادن بایتکد) را پیش از دیپلوی بر روی بلاکچین تغییر نمیدهد، ارزش بی نیازی از اعتماد، در عمل از بین می رود.
+
+ابزارهای تائید کد، ضمانت می کنند که کد قرارداد هوشمند دقیقاً منطبق بر کد اسمبلی آن قرارداد باشد. نتیجه این امر، پدید آمدن یک اکوسیستم بی نیاز از اعتماد است، جایی که کاربران، چشم و گوش بسته به افراد یا نهادهای سوم شخص اعتماد نکرده و به جای آن، پیش از انجام هرگونه واریز دارایی به یک قرارداد، کدهای آن قرارداد را تائید می کنند.
+
+### امنیت کاربر {#user-safety}
+
+معمولاً هر جا که قراردادهای هوشمند باشند، پول زیادی نیز سپرده گذاری شده است. به همین خاطر پیش از استفاده از قراردادهای هوشمند، نیاز بیشتری به تضمین امنیت و تائید بودن منطق آن قرارداد بوجود می آید. مشکلی که در اینجا وجود دارد این است که توسعه دهنده های بی اخلاق و شرور، می توانند کاربران را با وارد کردن کدهای مخرب به قرارداد هوشمند، فریب دهند. بدون انجام تائیدیه، قراردادهای هوشمند مخرب میتوانند شامل کدهای مخربی از جمله: [در پشتی](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)، مکانیزمهای کنترل دسترسی ناجور، آسیبپذیریهای قابل سوء استفاده، و سایر مخاطراتی که امنیت کاربر را به خطر می اندازند بوده که این کدها قابل شناسایی نباشند.
+
+انتشار فایل کدهای قرارداد هوشمند، دسترسی به نواحی ای از قرارداد که پتانسیل مورد حمله واقع شدن را دارند را برای علاقه مندانی مثل حسابرسان کد تسهیل می کند. وجود اشخاص مستقل از هم که عملیات تائید قرارداد هوشمند را انجام دهند، تضمینی قوی تر برای امنیت کاربران به حساب می آید.
+
+## نحوه تائید کد قراردادهای هوشمند اتریومی {#source-code-verification-for-ethereum-smart-contracts}
+
+[استقرار قرارداد هوشمند بر روی اتریوم](/developers/docs/smart-contracts/deploying/) نیازمند ارسال یک تراکنش با پی لود حاوی داده(بایت کد کامپایل شده) به یک آدرس خاص است. پی لود داده، با کامپایل شدن کد قرارداد، به علاوه ی [آرگومانهای کانستراکتور](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) قرارداد که به پی لود داده در تراکنش الحاق شده است ساخته می شود. عملیات کامپایل قطعی است، به این معنا که اگر فایل کدها و تنظیمات کامپایل(از جمله نسخه کامپایلر، اپتیمایز، و ...) یکسان باشند، همیشه یک خروجی یکسان(بایتکد قرارداد) ایجاد خواهد شد.
+
+![دیاگرامی که نمایش دهنده کد وریفای شده قرارداد هوشمند میباشد](./source-code-verification.png)
+
+وریفای کردن یک قرارداد هوشمند اساساً شامل مراحل زیر می باشد:
+
+1. وارد کردن فایل کدها و تنظیمات کامپایل به یک کامپایلر.
+
+2. کامپایلر، بایتکد قرارداد را به عنوان خروجی بر میگرداند
+
+3. بایتکد قرارداد دیپلوی شده در یک آدرس مشخص شده قابل دستیابی است
+
+4. بایتکد دیپلوی شده با بایتکد حاصله از دیپلوی مجدد مقایسه می شود. در صورت تصاطبق کدها، قرارداد با کد داده شده و تنظیمات کامپایل مشخص شده تائید و وریفای می شود.
+
+5. علاوه بر این، در صورتی که هش داده های اضافی یا همان متا دیتای در انتهای بایتکد، منطبق باشند، یک تطابق کامل خواهیم داشت.
+
+توجه داشته باشید که در اینجا توضیح ساده ای از تائید کردن را به میان آورده ایم، و در این پروسه استثناهای بسیاری وجود دارند که ممکن است توضیحات متفاوتی با آنچه که در حال صحبت در اینجا هستیم داشته باشند، مثلاً در زمانی که
+
+متغیرهای از نوع immutable" داشته باشیم.
+
+
+
+## ابزارهای وریفای کد {#source-code-verification-tools}
+
+پروسه مرسوم وریفای کردن قراردادها می توانند پیچیده باشند. به همین علت است که ابزارهایی برای وریفای کد قراردادهای هوشمند مستفر شده بر روی اتریوم داریم. این ابزارها بهطور اتوماتیک بخش های بزرگی از کد را تائید و وریفای کرده و همچنین می توانند کدهای وریفای شده را برای انتفاع کاربرها گلچین کنند.
+
+
+
+### Etherscan {#etherscan}
+
+اگرچه اکثراً آنرا به عنوان [مرورگر بلاکچین اتریوم](/developers/docs/data-and-analytics/block-explorers/) می شناسند، اتراسکن همچنین [سرویس تائید کد](https://etherscan.io/verifyContract) برای توسعه دهندههای قراردادهای هوشمند و کاربران عادی را ارائه می دهد.
+
+اتراسکن اجازه کامپایل مجدد بایتکد قرارداد از پی لود داده اصلی (کد، آدرس کتابخانه، تنظیمات کامپایلر، آدرس قرارداد، و ...) را به شما می دهد در صورتی که بایتکد مجدد کامپایل شده، با بایتکد (و پارامترهای کانستراکتور) قراردادی بر روی بلاکچین (آن-چین) منطبق باشد، سپس [قرارداد وریفای می شود](https://info.etherscan.com/types-of-contract-verification/).
+
+هنگامی که قرارداد وریفای شود، کد قرارداد شما برچسب "verified" دریافت کرده و به منظور حسابرسی و آدیت شدن سایرین، بر روی اتراسکن منتشر می شود. همچنین به قسمت قراردادهای وریفای شده0> یا همان verified contracts -که مخزنی از قراردادهای هوشمند با کدهای وریفای شده است- اضافه می شود.
+
+اتر اسکن، پر استفاده ترین ابزار وریفای و تائید قراردادهای هوشمند است. هرچند، سرویس وریفای قراردادهای اتراسکن نواقصی نیز دارد: از جمله این نواقص می توان به ناتوانی در مقایسه **هش متادیتا**ی بایتکد آن-چین و بایتکد مجدد کامپایل شده اشاره کرد. بنابراین می توان گفت که تطابقهای اتراسکن از نوع تطابق جزئی است.
+
+[مطالب بیشتر در خصوص وریفای قراردادهای هوشمند در اتراسکن](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
+
+
+
+### Sourcify {#sourcify}
+
+ابزار دیگری که متن باز و غیرمتمرکز بوده و برای وریفای قراردادهای هوشمند به کار میرود، [Sourcify](https://sourcify.dev/#/verifier) میباشد. این ابزار، مرورگر بلاک ها نیست و فقط قراردادها را بر روی [انواع شبکه های منطبق بر ماشین مجازی اتریوم](https://docs.sourcify.dev/docs/chains) وریفای می کند. این ابزار به عنوان یک زیرساخت عمومی برای سایر ابزارها عمل می کند، و هدفش این است که ارتباط گیری با قراردادهای هوشمند را با استفاده از [ABI](/developers/docs/smart-contracts/compiling/#web-applications) و کامنتهای از نوع [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) که در فایل متادیتا یافت می شود، کاربر پسند تر کند.
+
+بر خلاف اتراسکن، Sourcify از تطابق کامل با هش متادیتا پشتیبانی می کند. قراردادهای تائید شده، در [مخزن عمومی](https://docs.sourcify.dev/docs/repository/) یا HTTP و [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) که یک فضای ذخیرهسازی غیر متمرکز [مبتنی بر آدرس](https://web3.storage/docs/concepts/content-addressing/) است قرار میگیرند. از آنجایی که هش متادیتای الحاق شده، یک هش IPFS است، این امر اجازه ی واکشی فایل متادیتای یک قرارداد از بستر IPFS را فراهم میآورد.
+
+به علاوه، از آنجایی که هش IPFS این فایلها همچنین در متادیتا نیز یافت میشود، هر کسی این امکان را دارد که فایل کد را از طریق IPFS دریافت کند. با فراهمسازی فایل متادیتا و فایل کدها از طریق API و یا [رابط کاربری](https://sourcify.dev/#/verifier)، و یا استفاده از پلاگینهای آن، می توان قرارداد را وریفای کرد. همچنین ابزار مانیتورینگ و رصد Sourcify گوش به زنگ ساخته شدن قراردادها در بلوکهای جدید بوده و اگر متادیتا و فایل کد قراردادی در IPFS منتشر شده است، سعی میکند آنرا وریفای کند.
+
+[مطالب بیشتر در خصوص وریفای قراردادها بر روی Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/).
+
+
+
+### Tenderly {#tenderly}
+
+پلتفرم [Tenderly](https://tenderly.co/) به توسعهدهندههای وب3 قابلیت ساخت، تست، مانیتور کردن، و اجرای قراردادهای هوشمند را میدهد. تندرلی، با مجموعه ای از ابزارهای اشکالزدایی، با ابزارهای قابل مشاهده پذیری و زیرساخت ساخته شدن بلوکها، در مسیر توسعه قرارداد هوشمند، به توسعه دهنده ها سرعت میبخشد. به منظور بهرهمندی از تمامی امکانات تندرلی، توسعهدهندهها نیاز به [وریفای کردن کدقرارداد](https://docs.tenderly.co/monitoring/contract-verification) دارند.
+
+امکان وریفای عمومی یا خصوصی یک قرارداد وجود دارد. در صورت وریفای بهصورت خصوصی، قرارداد هوشمند فقط برای شما (و افراد تیم پروژهی شما) قابل مشاهده است. وریفای کردن عمومی قرارداد، آنرا برای تمامی کاربران پلتفرم تندرلی قرار میدهد.
+
+شما می توانید با استفاده از [داشبورد کاربری](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract)، [پلاگین هاردهت تندرلی](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin)، و یا [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) قراردادهای خود را وریفای کنید.
+
+در صورتی که قرارداد خود را از طریق داشبورد کاربری وریفای کنید نیاز دارید که فایل کد یا فایل متادیتای ساخته شده توسط کامپایلر سالیدیتی، آدرس/شبکه، و تنظیمات کامپایلر را ایمپورت کنید.
+
+با استفاده از پلاگین هاردهت تندرلی، می توانید دسترسی های بیشتر با سختی کمتری در خلال پروسه وریفای کردن داشته باشید، و این باعث فعالسازی امکان انتخاب وریفای بین روش اتوماتیک (بدون کد) و دستی (نیازمند کدنویسی) میشود.
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [وریفای کردن کد منبع قرارداد](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/fa/21) Whitepaper/whitepaper/index.md b/public/content/translations/fa/21) Whitepaper/whitepaper/index.md
new file mode 100644
index 00000000000..42e678b2a6f
--- /dev/null
+++ b/public/content/translations/fa/21) Whitepaper/whitepaper/index.md
@@ -0,0 +1,610 @@
+---
+title: برگه سفید اتریوم
+description: مقاله مقدماتی اتریوم که در سال 2013 قبل از راهاندازی آن منتشر شد.
+lang: fa
+sidebarDepth: 2
+hideEditButton: true
+---
+
+# برگه سفید اتریوم {#ethereum-whitepaper}
+
+_این مقاله مقدماتی در ابتدا در سال ۲۰۱۳ توسط ویتالیک بوترین، بنیانگذار [اتریوم](/what-is-ethereum/)، پیش از راهاندازی پروژه در سال ۲۰۱۵ منتشر شد. شایان ذکر است که اتریوم، مانند بسیاری از پروژه های جامعه محور، پروژه های نرم افزاری منبع باز، از زمان نقطه آغازینش تکامل پیدا کرده است._
+
+_با وجود عمری چندین ساله، ما این مقاله را حفظ میکنیم چون میتواند به عنوان مرجعی مفید و نمودی دقیق از اتریوم و چشم اندازش عمل کند. برای اطلاع از آخرین پیشرفتهای اتریوم و اینکه تغییرات در پروتکل چگونه اعمال میشوند، [این راهنما](/learn/) را توصیه میکنیم._
+
+[محققان و دانشگاهیان که به دنبال یک نسخه تاریخی یا متعارف از وایت پیپر [از دسامبر 2014] هستند، باید از این PDF استفاده کنند.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf)
+
+## یک پلتفرم قرارداد هوشمند و برنامهی غیرمتمرکز نسل بعدی {#a-next-generation-smart-contract-and-decentralized-application-platform}
+
+توسعه بیت کوین توسط ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب به عنوان یک تحول اساسی درصنعت پول و رمزارز مورد استقبال قرار گرفته است، اولین نمونه یک دارایی دیجیتال که به طور همزمان نه هیچ پشتوانه یا "[ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" دارد و نه هیچ مرجع عرضه متمرکز یا کنترل کننده. با این حال، یکی از بخشهای - شاید مهم تر - تجربه بیت کوین زیربنای فناوری زنجیره بلوکی آن به عنوان ابزاری برای اجماع توزیع شده است، و توجهات به سرعت در حال شروع به تغییر به این جنبه دیگر بیت کوین است. کاربردهای جایگزین رایج فناوری بلاک چین شامل استفاده از دارایی های دیجیتال درون بلاک چین برای نشان دادن ارزهای سفارشی و ابزارهای مالی ("[سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lBEoW2T ویرایش)")، مالکیت یک دستگاه فیزیکی زیربنایی ("[اموال هوشمند](https://en.bitcoin.it/wiki/Smart_Property)")، داراییهای غیرقابل تعویض مانند نامهای دامنه ("[Namecoin](http://namecoin.org)")، و همچنین برنامههای پیچیدهتر شامل داشتن داراییهای دیجیتال که مستقیماً توسط یک قطعه کد کنترل میشوند. اجرای قوانین دلخواه ("[هوشمند قراردادها](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") یا حتی "
+
+سازمان های مستقل غیرمتمرکز" (DAOs). آنچه اتریوم قصدش را دارد فراهمسازی یک زنجیره بلوکی با یک زبان برنامه نویسی توکار تورینگ-کامل تمام عیار است که بتوان از آن برای ساخت "قرارداد" هایی که میتوانند برای کد کردن توابع انتقال وضعیت دلخواه مورد استفاده قرار بگیرند بهره برد، که به کاربرها اجازه ساخت هر کدام از سیستم های پیشتر ذکر شده را و همچنین بسیاری از انواع دیگری که حتی تصورشان را هم هنوز نکرده ایم میدهد، صرفاً با به نوشته در آوردن منطق آن در چند خط کد.
+
+
+
+## مقدمه ای بر بیت کوین و مفاهیم موجود {#introduction-to-bitcoin-and-existing-concepts}
+
+
+
+### تاریخچه {#history}
+
+مفهوم ارز دیجیتال نامتمرکز و همچنین برنامه های جایگزین مانند ثبت اموال، برای دهه ها وجود داشته است. پروتکلهای پول نقد الکترونیکی ناشناس در دهههای 1980 و 1990، عمدتاً متکی به یک رمزنگاری بدوی به نام کورکننده چاومین، ارزی با درجه بالایی از حریم خصوصی ارائه می شدند، اما پروتکلها عمدتاً به دلیل اتکا به یک واسطه متمرکز نتوانستند مورد توجه قرار گیرند. در سال 1998، [b-money](http://www.weidai.com/bmoney.txt) از Wei Dai نخستین طرحی شد که ایده ساخت پول از طریق حل معما های محاسباتی و نیز اجماع نامتمرکز را معرفی میکرد، اما جزئیات طرح پیرامون اینکه اجماع نامتمرکز در واقع چگونه میتوانست تعبیه شود ناچیز بود. در سال 2005، هال فینی مفهوم [اثبات کار قابل استفاده مجدد](https://nakamotoinstitute.org/finney/rpow/) را معرفی کرد، سیستمی که از ایدههایی از b-money به همراه پازلهای سخت محاسباتی Hashcash آدام بک برای ایجاد مفهومی برای یک ارز دیجیتال بهره میبرد، اما بار دیگر به دلیل تکیه بر محاسبات قابل اعتماد به عنوان یک بکاند، دور از ایدهآل قرار گرفت. در سال 2009، یک ارز غیرمتمرکز برای اولین بار در عمل توسط ساتوشی ناکاموتو پیادهسازی شد، که ترکیبی از اصول اولیه برای مدیریت مالکیت از طریق رمزنگاری کلید عمومی همچنین الگوریتم اجماع برای پیگیری صاحبان سکهها، معروف به "اثبات کار" اجرا شد.
+
+سازوکار پشت اثبات کار پیشرفت شگفت انگیزی بود چون به طور همزمان دو مشکل را حل میکرد. در وهله اول يك الگوريتم اجماع و ساده و موثر را ارائه مي كرد و به گره ها در شبكه اجازه مي دهد كه بصورت جامع و متمركز بر حالت به روز شده دفتر حساب بيتكوين توافق كنند. دوماً، مکانیسمی را برای ورود آزادانه به فرآیند اجماع ارائه داد که مشکل تصمیم گیری برای اینکه چه کسی هم بر اجماع تاثیر بگذارد و هم از حملات sybil جلوگیری کند. این کار را با جایگزین کردن یک مانع رسمی برای مشارکت، مانند الزام به ثبت نام به عنوان یک موجودیت منحصر به فرد در یک لیست خاص، با یک مانع اقتصادی انجام می دهد - وزن یک گره واحد در فرآیند رای گیری اجماع مستقیماً با قدرت محاسباتی که گره به ارمغان می آورد، متناسب است. از آن زمان، یک رویکرد جایگزین به نام _اثبات سهام_ پیشنهاد شده است که وزن یک گره را متناسب با دارایی های ارز آن محاسبه می کند و نه منابع محاسباتی. بحث در مورد مزایای نسبی دو رویکرد خارج از محدوده این مقاله است، اما باید توجه داشت که هر دو رویکرد می توانند به عنوان ستون فقرات یک رمزارز مورد استفاده قرار گیرند.
+
+
+
+### بیت کوین به عنوان یک سیستم انتقال حالت {#bitcoin-as-a-state-transition-system}
+
+![انتقال حالت اتریوم](./ethereum-state-transition.png)
+
+از نقطه نظر فنی، دفتر کل رمزارزهایی مانند بیتکوین را می توان به عنوان یک سیستم انتقال حالت در نظر گرفت، که در آن یک "حالت" متشکل از وضعیت مالکیت تمام بیتکوین های موجود و یک "تابع انتقال حالت" که یک حالت و یک تراکنش را می گیرد و یک حالت جدید را که نتیجه آن است، خروجی می دهد. به عنوان مثال، در یک سیستم بانکی استاندارد، حالت یک صفحهی موجودی است، تراکنش یک درخواست برای انتقال x ریال از آ به ب، و تابع انتقال حالت از حساب آ مقدار x ریال را کسر میکند و به حساب ب مقدار x ریال را میافزاید. اگر حساب آ از پیش کمتر از $X داشته باشد، تابع انتقال حالت یک خطا بازمیگرداند. سرآخر میتوان به شکل استاندارد تعریف کرد:
+
+
+
+```
+APPLY(S,TX) -> S' or ERROR
+```
+
+
+در سیستم بانکی که بالا تعریف شد:
+
+
+
+```js
+APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
+```
+
+
+اما:
+
+
+
+```js
+APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
+```
+
+
+"وضعیت" در بیت کوین مجموعه ای از تمام کوین ها (از لحاظ فنی، "خروجی های تراکنش خرج نشده" یا UTXO) است که ضرب شده اند و هنوز خرج نشده اند، با هر UTXO دارای یک اسم و یک مالک (که با یک آدرس 20 بایتی تعریف می شود. اساسا یک کلید عمومی رمزنگاری است[fn1](#notes)). یک تراکنش شامل یک یا چند ورودی است که هر ورودی حاوی ارجاع به یک UTXO موجود و یک امضای رمزنگاری شده توسط کلید خصوصی مرتبط با آدرس مالک است و یک یا چند خروجی که هر خروجی حاوی یک UTXO جدید است که باید به آن حالت اضافه شود.
+
+تابع انتقال حالت `APPLY(S,TX) -> S'` را می توان تقریباً به صورت زیر تعریف کرد:
+
+
+ -
+ برای هر ورودی در
TX
:
+
+ -
+ اگر UTXOی ارجاعی در
S
نیست، خطا را برگردان.
+
+ -
+ اگر امضای ارائه شده با صاحب UTXO مطابقت ندارد، خطا را برگردان.
+
+
+
+ -
+ اگر مجموع نامهای تمام UTXO ورودی کمتر از مجموع نامهای همه UTXO خروجی باشد، خطا را برگردان.
+
+ -
+
S
را با حذف تمام ورودی UTXO و اضافه شدن تمام خروجی UTXO برگردان.
+
+
+
+نیمهی اول از گام اول مانع از این میشود که فرستندهها کوینهایی که وجود ندارند را خرج کنند، نیمهی دوم از گام اول مانع از این میشود که فرستندهها کوینهای دیگر افراد را خرج نکنند، و گام دوم فرستنده را مجبور میکند که ارزش را حفظ کند. برای این که از این برای پرداخت استفاده کنیم، پروتکل به شکل زیر است. فرض کنید که آلیس میخواهد ۱۱٬۷ BTC را به باب بفرستد. ابتدا آلیس به دنبال یک مجموعه از UTXO از آنهایی که خود مالک آنهاست میگردد که مجموعشان حداقل ۱۱٬۷ BTC شود. واقعبینانه، آلیس نخواهد توانست که دقیقا ۱۱٬۷ BTC را بیابد؛ فرض کنید کمترین میزانی که آلیس میتواند بسازد ۶+۴+۲=۱۲ باشد. در گام بعدی او یک تراکنش با سه ورودی گفتهشده و دو خروجی میسازد. اولین خروجی ۱۱٬۷ BTC به آدرس باب خواهد بود و دومین خروجی مقدار ۰٬۳ BTC باقیمانده به عنوان «پول خرد»، به آدرس خود آلیس است.
+
+
+
+### استخراج {#mining}
+
+![بلوک های اتریوم](./ethereum-blocks.png)
+
+اگر ما به یک سرویس متمرکز قابل اعتماد دسترسی داشتیم، ساخت این سیستم بدیهی بود و میتوانست دقیقا به صورتی که توصیف شد با استفاده از سختافزار سرور متمرکز برای نگهداری حالتها برنامهنویسی شود. هر چند، با بیتکوین ما میخواهیم یک ارز غیرمتمرکز بسازیم، در نتیجه نیاز داریم که سیستم انتقال حالت را با یکی سیستم اجماع بسازیم که همه بر روی ترتیب تراکنشها توافق داشتهباشند. پروسهی اجماع غیرمتمرکز بیتکوین نیاز به گرههایی در شبکه دارد که به طور مرتب پکیجهایی به نام «بلوک» را بسازند. این شبکه قرار است تقریبا هر ۱۰ دقیقه یک بلوک بسازد که در هر بلوک یک برچسب زمان (Timestamp)، یک نانس و یک ارجاع (هش) به بلاک قبلی و لیستی از همهی تراکنشهایی که از بلوک قبلی تا به حال اتفاق افتادهاند، وجود دارد. در طی زمان، این موضوع یک «زنجیرهی بلوکی» پایدار و رشدکننده میسازد که به طور مرتب بروز میشود تا آخرین حالت دفترکل بیتکوین را نمایش دهد.
+
+الگوریتمی که نشان میدهد یک بلوک معتبر است به صورت زیر توضیح داده میشود:
+
+1. بررسی کنید که آیا بلوک قبلی که توسط بلوک به آن ارجاع داده شده وجود دارد و معتبر است یا خیر.
+2. بررسی کنید که مُهر زمانی بلوک بزرگتر از بلوک قبلی باشد[fn2](#notes) و کمتر از 2 ساعت در آینده باشد
+3. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
+4. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
+5. فرض کن `TX` لیست تراکنشهای بلوک با تعداد `n` تراکنش است. برای همه `i` در `0...n-1`، `S[i+1] = APPLY(S[i], TX[i]) را تنظیم کنید /code> اگر هر برنامه ای خطا را برمیگرداند، از آن خارج شوید و false را برگردانید.
+True را برگردانید و S[n]` را به عنوان وضعیت در انتهای این بلوک ثبت کنید.
+
+در واقع هر تراکنش در بلوک باید یک انتقال حالت معتبر را از حالت قبل از انجام تراکنش به حالت جدید انجام دهد. باید توجه کرد که حالت به هیچ صورتی در بلوک ثبت نمیشود؛ این یک موضوع تماما انتزاعی است برای این که توسط گرههای اعتبارسنج به خاطر سپرده شود و تنها میتوان (به صورت ایمن) با شروع از حالت بلوک پیدایش و حرکت بر روی تراکنشهای هر بلوک، حالت بلوک فعلی را به دست آورد. علاوه بر این، توجه کنید که ترتیبی که استخراجگر تراکنشها را در بلوک ثبت میکند مهم است؛ اگر دو تراکنش آ و ب وجود داشته باشند به طوری که ب یک UTXOی ساختهشده از آ را خرج کند، در این صورت بلوک معتبر است اگر آ قبل از ب ثبت شود و نه برعکس.
+
+شرط صحتی که در دیگر سیستمها دیده نمیشود و در لیست بالا به آن اشاره شد، لازمهی «اثبات کار» است. شرط دقیق به این شکل است که هش double-SHA256 هر بلوک، به عنوان یک عدد ۲۵۶ بیتی، باید کمتر از یک هدف به شکل پویا متغیر باشد، که در زمان نوشتن این مقاله ۲۱۸۷ است. هدف از این امر "سخت کردن" ساخت بلوک از لحاظ محاسباتی و در نتیجه باز داشتن مهاجمان sybil از بازسازی کل زنجیره بلوکی به نفع خودشان است. چون SHA256 طراحی شده تا یک تابع کاملا شبه تصادفی غیرقابل پیشبینی باشد، تنها راه ساخت یک بلوک معتبر صرفا آزمون و خطا، اضافه کردن نانس و دیدن این است که آیا هش جدید تطابق میکند یا خیر.
+
+در هدف کنونی \~۲۱۸۷، شبکه باید به طور میانگین اقدام به \~۲۶۹ آزمون پیش از یافتن یک بلوک معتبر بکند; به طور کلی، هدف به ازای هر ۲۰۱۶ بلوک توسط شبکه بازتنظیم میشود به شکلی که به طور میانگین هر ۱۰ دقیقه یک بلوک جدید توسط یک گره در شبکه تولید شود. به منظور جبران کار ماینرها برای این محاسبات ، استخراجگر هر بلوک حق دارد یک تراکنش را شامل شود که به خودشان 12.5 بیت کوین می دهد. بهعلاوه، اگر هر تراکنشی در ورودیهای خود ارزش کل بالاتری نسبت به خروجیهای خود داشته باشد، تفاوت نیز به عنوان «کارمزد تراکنش» به ماینر میرسد. اتفاقاً این تنها مکانیزمی است که توسط آن BTC صادر می شود. در اول ایجاد این شبکه هیچ سکه ای وجود نداشت.
+
+برای درک بهتر هدف استخراج، اجازه دهید بررسی کنیم که در صورت بروز یک هجوم مخرب چه اتفاقی می افتد. از آنجایی که رمزنگاری زیربنایی بیت کوین امن است، مهاجم قسمتی از سیستم بیت کوین را که مستقیماً توسط رمزنگاری محافظت نمی شود، هدف قرار می دهد: ترتیب تراکنش ها. استراتژی مهاجم ساده است:
+
+1. تعداد 100 بیتکوین را به یک صرافی در ازای مقداری محصول بفرستید (ترجیحاً کالای دیجیتالی با تحویل سریع)
+2. منتظر تحویل محصول میماند
+3. یک تراکنش دیگر ایجاد کرده و همان 100 بیت کوین را برای خودش ارسال میکند
+4. سعی کنید شبکه را متقاعد کنید که تراکنش او با خودش اولین معامله بوده است.
+
+هنگامی که مرحله (1) انجام شد، پس از چند دقیقه برخی از ماینرها تراکنش را در یک بلوک، مثلاً بلوک شماره 270000، وارد می کنند. بعد از حدود یک ساعت، پنج بلوک دیگر به زنجیره پس از آن بلوک، اضافه میشود که هر کدام از این بلوک ها به طور غیر مستقیم به تراکنش اشاره کرده و بنابراین آن را تایید میکنند. در این نقطه، تاجر پرداخت را نهایی تلقی میکند و محصول را تحویل میدهد. همچنان که فرض کردیم این کالا دیجیتال است و تحویل آن فوری است. حال مهاجم تراکنش دیگری را ایجاد میکند و 100 بیت کوین را به خودش ارسال میکند. اگر مهاجم به سادگی آن را رها کند، تراکنش پردازش نخواهد شد. استخراج کنندگان تلاش میکنند که `APPLY(S, TX)` را اعمال کنند و متوجه میشوند که `TX` یک UTXO را مصرف میکند که دیگر در آن حالت نیست. بنابراین در عوض آن، مهاجم یک انشعاب (فورک) از زنجیره بلوکی را ایجاد میکند که با استخراج نسخه دیگری از بلوک 270 شروع میشود که به همان بلوک 269، به عنوان بلوک مادر اشاره میکند، اما با معرفی تراکنش جدید در جای تراکنش قدیمی. از آنجا که داده های بلوک متفاوت است، این مستلزم انجام مجدد اثبات کار است. علاوه بر این، نسخه جدید بلوک 270 مهاجم دارای هش متفاوتی است، بنابراین بلوک های اصلی 271 تا 275 به آن اشاره نمی کنند. بنابراین، زنجیره اصلی و زنجیره جدید مهاجم کاملاً جدا هستند. قانون این است که در یک فورک طولانیترین زنجیره بلوکی حقیقی در نظر گرفته میشود، و بنابراین ماینرهای قانونی روی زنجیره ۲۷۵ کار میکنند در حالی که مهاجم به تنهایی روی زنجیره ۲۷۰ کار میکند. برای اینکه مهاجم بتواند زنجیره بلوکی خود را تبدیل به طولانیترین رنجیره کند، باید قدرت محاسباتی بیشتری نسبت به مجموع سایر شبکهها داشته باشد تا بتواند به آنها برسد (یعنی، "حمله 51٪").
+
+
+
+### درختان Merkle {#merkle-trees}
+
+![SPV در بیتکوین](./spv-bitcoin.png)
+
+_طرف چپ: کافی است که فقط تعداد کمی از گره ها را در یک درخت Merkle ارائه داد تا اثبات اعتبار شاخه ایجاد شود._
+
+_طرف راست: هر تلاشی برای تغییر هر بخشی از درخت Merkle سرانجام منجر به عدم سازگاری در جایی در بالای زنجیره میشود._
+
+یک ویژگی مقیاس پذیری مهم بیت کوین این است که بلوک مورد نظر در یک ساختار دادهی چند لایه ذخیره میشود. هش یک بلوک در واقع تنها هش بلوک اصلی است، تقریبا 200 بایت اطالعات شامل ثبت زمان، نانس، هش بلوک قبلی و هش ریشه ساختار داده که درخت Merkle نامیده میشود و همه تراکنش ها را در بلوک ذخیره میکند. درخت Merkle نوعی درخت باینری است که متشکل از مجموعه ای گره است که همراه با تعداد زیادی گره برگی در پایین درخت میباشد که شامل داده های زیربنایی میشوند. یک مجموعه از گره های میانجی هم هستند که هر کدام از آنها هش دو بچه خود میباشند و بخش بالایی درخت را ارائه میدهند. مقصود از درخت Merkle، مجوز دادن به داده های یک بلوک برای تحویل تدریجی است. یک گره از یک منبع، فقط هدر (header) بلوک را دانلود میکند. بخش کوچک درخت از طریق منبع دیگری به آنها مربوط میشود و با این وجود اطمینان حاصل میشود که همه داده ها صحیح هستند. دلیل این کار این است که هش ها به سمت بالا منتشر می شوند: اگر یک کاربر بداندیش تلاش کند که در یک تراکنش جعلی به پایین درخت Merkle تغییر وضعیت دهد، این تغییر منجر به تغییر در گره بالا میشود و سپس تغییر در گره بالاتر آن و سرانجام ریشه درخت را تغییر میدهد و بنابراین هش بلوک، سبب میشود که پروتکل آن را به عنوان یک بلوک کامل متفاوت ثبت کند (با احتمال قریب به یقین به عنوان یک اثبات کار غیر معتبر).
+
+پروتکل درخت Merkle به طور قابل دفاعی در ماندگاری دراز مدت نقش اساسی دارد. یک گره کامل در شبکه بیت کوین، گره ای است که کلیت یک بلوک را ذخیره و پردازش میکند و حدود 15 گیگابایت از فضای دیسک شبکه بیت کوین را در آپریل 2014 اشغال میکرد و هر ماه حدود یک گیگابایت به این مقدار اضافه میشد. در حال حاضر، این برای برخی از رایانههای دسکتاپ و نه تلفنها قابل اجرا است و بعداً در آینده فقط مشاغل و علاقهمندان میتوانند در آن شرکت کنند. پروتکلی به نام "تأیید پرداخت ساده" (SPV) اجازه می دهد تا کلاس دیگری از گره ها به نام "گره های سبک" وجود داشته باشد که هدرهای بلوک را دانلود می کنند، اثبات کار روی هدرهای بلوک را تأیید می کنند و سپس فقط "شاخه ها"ی مرتبط با تراکنش هایی که به آنها مربوط است را دانلود می کنند. این به گرههای سبک اجازه میدهد تا با ضمانت امنیتی قوی، وضعیت هر تراکنش بیتکوین و موجودی فعلی آنها را تعیین کنند، در حالی که تنها بخش بسیار کوچکی از کل زنجیره بلوکی را دانلود میکنند.
+
+
+
+### کاربردهای جایگزین زنجیره بلوکی {#alternative-blockchain-applications}
+
+ایده گرفتن ایده اصلی زنجیره بلوکی و اعمال آن در مفاهیم دیگر نیز سابقه طولانی دارد. در سال 2005، نیک زابو به مفهوم [عناوین ملکی ایمن با اختیار مالک](https://nakamotoinstitute.org/secure-property-titles/)، سندی که چگونگی "پیشرفت های جدید در فناوری پایگاه داده تکراری" را توضیح می دهد اشاره کرد. یک سیستم مبتنی بر بلاکچین برای ذخیره یک رجیستری از اینکه چه کسی امکانپذیر است که مالک چه زمینی است و یک چارچوب مفصل از جمله مفاهیمی از این قبیل ایجاد می کند به عنوان خانه داری، مالکیت نامناسب و مالیات زمین میلادی ایجاد می کند. با این حال، متأسفانه هیچ سیستم پایگاه داده تکثیر شده مؤثری در آن زمان موجود نبود، و بنابراین این پروتکل هرگز در عمل اجرا نشد. با این حال، پس از سال 2009، هنگامی که اجماع غیرمتمرکز بیت کوین توسعه یافت، تعدادی از برنامه های کاربردی جایگزین به سرعت شروع به ظهور کردند.
+
+- **Namecoin** - ایجاد شده در سال 2010، [Namecoin](https://namecoin.org/) به بهترین وجه به عنوان یک پایگاه داده ثبت نام غیرمتمرکز توصیف می شود. در پروتکل های غیرمتمرکز مانند Tor، Bitcoin و BitMessage، باید راهی برای شناسایی حساب ها وجود داشته باشد تا افراد دیگر بتوانند با آنها تعامل داشته باشند، اما در همه راه حل های موجود، تنها نوع شناسه موجود یک هش شبه تصادفی مانند `1LW79wp5ZBqaHW1jL5TCiBCrhWQYHagUt` است. در حالت ایده آل، شخصی ممکن است دوست داشته باشد که بتواند یک حساب کاربری با نامی مانند "جورج" داشته باشد. با این حال، مشکل این است که اگر یک نفر بتواند یک حساب کاربری به نام "جورج" ایجاد کند، شخص دیگری نیز می تواند از همین فرآیند برای ثبت "جورج" برای خود و جعل هویت آنها استفاده کند. تنها راه حل یک پارادایم اول به فایل است که در آن ثبت کننده اول موفق می شود و دومی شکست می خورد - مشکلی که کاملاً برای پروتکل اجماع بیتکوین متناسب است. Namecoin قدیمی ترین و موفق ترین مدل پیاده سازی شده سیستم ثبت نام با استفاده از چنین ایده ای است.
+- **سکه های رنگی** - هدف [سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) این است که به عنوان پروتکلی عمل کند تا به مردم اجازه دهد رمزارزهای خود را ایجاد کنند - یا در مورد مهم پیش پا افتاده ارز با یک واحد، توکن های دیجیتال، در بلاکچین بیت کوین. در پروتکل کوینهای رنگی، یک ارز جدید با اختصاص دادن یک رنگ به یک بیت کوین UTXO خاص به صورت عمومی یک ارز جدید صادر میکند و پروتکل به صورت بازگشتی رنگ سایر UTXOها را با رنگ ورودیهایی که تراکنش ایجاد میکند، مشخص میکند. (برخی قوانین خاص در مورد ورودیهای رنگی مخلوط اعمال میشود). این مورد به کاربران اجازه میدهد تا کیف پولهایی را که فقط حاوی UTXO با یک رنگ خاص هستند نگهداری کنند و آنها را مانند بیتکوینهای معمولی به اطراف بفرستند و از طریق بلاکچین به عقب برگردند تا رنگ هر UTXO دریافتی را تعیین کنند.
+- **Metacoins** - ایده پشت متاکوین داشتن پروتکلی است که بر روی بستر بیتکوین زندگی می کند، از تراکنش های بیتکوین برای ذخیره تراکنش های متاکوین استفاده می کند، اما دارای یک تابع انتقال حالت متفاوت یعنی `APPLY'` است،. از آنجایی که پروتکل متاکوین نمی تواند از نمایش تراکنش های متاکوین نامعتبر در بلاکچین بیتکوین جلوگیری کند، قانونی اضافه می شود که اگر `APPLY'(S,TX)` خطایی را برگرداند، پروتکل به طور پیش فرض به `APPLY'( S,TX) = S` بر می گردد. این مورد یک مکانیسم آسان برای ایجاد یک پروتکل ارز دیجیتال دلخواه، با ویژگیهای پیشرفته است که نمیتواند در داخل بیتکوین با هزینه توسعه بسیار پایین پیادهسازی شود، زیرا پیچیدگیهای استخراج و شبکهسازی قبلاً توسط پروتکل بیتکوین مدیریت میشود. متاکوینها برای اجرای برخی از کلاسهای قراردادهای مالی، ثبت نام و مبادلات غیرمتمرکز استفاده شدهاند.
+
+بنابراین، به طور کلی، دو رویکرد برای ایجاد یک پروتکل اجماع وجود دارد: ایجاد یک شبکه مستقل، و ساخت یک پروتکل در بالای بیت کوین. رویکرد قبلی، اگرچه در مورد برنامههایی مانند Namecoin به طور معقولی موفق بود، اما پیادهسازی آن دشوار است. هر پیادهسازی جداگانه نیاز به راهاندازی یک زنجیره بلوکی مستقل و همچنین ساخت و آزمایش تمام انتقال وضعیت و کد شبکه دارد. علاوه بر این، ما پیشبینی میکنیم که مجموعه برنامههای کاربردی برای فناوری اجماع غیرمتمرکز از یک توزیع قانون قدرت پیروی میکنند که در آن اکثریت قریب به اتفاق برنامهها برای تضمین زنجیره بلوکی خود بسیار کوچک هستند، و توجه داریم که کلاسهای بزرگی از برنامههای غیرمتمرکز، بهویژه مستقل غیرمتمرکز وجود دارد، سازمان هایی که نیاز به تعامل با یکدیگر دارند.
+
+از سوی دیگر، رویکرد مبتنی بر بیتکوین دارای این نقص است که ویژگیهای تأیید پرداخت ساده بیتکوین را به ارث نمیبرد. SPV برای بیت کوین کار می کند زیرا می تواند از عمق بلاک چین به عنوان یک پروکسی برای اعتبار استفاده کند. زمانی که پیشینههای یک تراکنش به اندازه کافی به عقب بروند، می توان با اطمینان گفت که آنها به طور قانونی بخشی از وضعیت بودند. از سوی دیگر، فراپروتکلهای مبتنی بر زنجیرهی بلوکی نمیتوانند زنجیرهی بلوکی را مجبور کنند که تراکنشهایی را که در چارچوب پروتکلهای خود معتبر نیستند، در بر نگیرد. از این رو، اجرای فراپروتکل SPV کاملاً ایمن باید تا ابتدای زنجیرهی بلوکی بیت کوین را به عقب اسکن کند تا مشخص شود که آیا تراکنش های خاصی معتبر هستند یا خیر. در حال حاضر، تمام پیادهسازیهای «سبک» فراپروتکلهای مبتنی بر بیتکوین برای ارائهی دادهها به یک سرور قابل اعتماد متکی هستند، که مسلماً نتیجهای بسیار نابهینه است، بهویژه زمانی که یکی از اهداف اصلی یک ارز دیجیتال حذف نیاز به اعتماد باشد.
+
+
+
+### اسکریپت نویسی {#scripting}
+
+درواقع پروتکل بیت کوین حتی بدون هیچ گونه افزونهای، نسخه ضعیفی از قرارداد های هوشمند را تسهیل میکند. UTXO در بیت کوین فقط با یک کلید عمومی مالکیت پیدا نمیکند، بلکه همچنین اسکریپت پیچیده تری در زبان برنامه نویسی بر پایهی پشتهی ساده ابراز میشود. در این الگو، تراکنشی که آن UTXO را خرج میکند، باید داده هایی را فراهم کند که اسکریپت را قانع کند. در واقع حتی مکانیزم مالکیت کلید عمومی اصلی، از طریق یک اسکریپت پیاده میشود. این اسکریپت یک امضای منحنی بیضوی را به عنوان ورودی اعمال میکند که آن را در برابر تراکنش و آدرسی که مالک UTXO است، تایید میکند و اگر تایید موفق باشد، 1 و در غیر این صورت 0 ارجاع داده میشود. اسکریپت های پیچیدهتر دیگری برای موارد استفاده اضافی متعددی موجود هستند. به عنوان مثال فرد میتواند اسکریپتی بسازد که نیازمند امضاهایی شامل دو از سه کلید خصوصی باشد تا اعتبارسنجی انجام شود. (multisig) این چیدمان برای اکانت های سازمانی، اکانت های پس انداز ایمن و موقعیت های شخص ثالث بازرگان، مفید است. اسکریپت ها همچنین میتوانند برای پرداخت جایزه هایی که برای راه حل های محاسباتی داده میشوند، استفاده شوند و فرد میتواند حتی اسکریپتی بسازد که چیزی مانند این که UTXO بیت کوین متعلق به چه کسی است، نشان داده شود. اگر بتوان یک مدرک SPV فراهم کرد که فرد یک تراکنش دوجکوین را فرستاده است، در اساس این امر مجوز یک تراکنش متقابل غیر متمرکز رمزارز را میدهد.
+
+اما زبان اسکریپت، آنچنان که در بیت کوین پیاده شده، محدودیت های مهمی هم دارد:
+
+- **عدم کامل بودن تورینگ** - یعنی در حالی که زیرمجموعه بزرگی از محاسبات وجود دارد که زبان برنامه نویسی بیتکوین از آن پشتیبانی می کند، تقریباً همه چیز را پشتیبانی نمی کند. دسته اصلی که گم شده است حلقه ها هستند. این کار برای جلوگیری از حلقه های بی نهایت در حین تأیید تراکنش انجام می شود. از نظر تئوری، این یک مانع قابل عبور برای برنامه نویسان اسکریپت است، زیرا هر حلقه را می توان با تکرار چندین بار کد اصلی با یک دستور if شبیه سازی کرد، اما منجر به اسکریپت هایی می شود که بسیار کم فضا هستند. به عنوان مثال، اجرای یک الگوریتم امضای منحنی بیضوی جایگزین احتمالاً به 256 دور ضرب مکرر نیاز دارد که همه به صورت جداگانه در کد گنجانده شده است.
+- **کوری مقدار** - هیچ راهی برای اسکریپت UTXO وجود ندارد که بتواند کنترل دقیقی بر مقدار قابل برداشت ارائه دهد. به عنوان مثال، یکی از موارد استفاده قدرتمند از یک قرارداد اوراکل، قرارداد پوشش ریسک است، که در آن A و B مقدار 1000 دلار بیتوین وارد می کنند و پس از 30 روز، اسکریپت 1000 دلار بیتکوین را به A و بقیه را به B ارسال می کند. اوراکل برای تعیین ارزش 1 بیتکوین به دلار آمریکا، اما حتی در آن زمان نیز از نظر اعتماد و نیاز به زیرساخت نسبت به راه حل های کاملاً متمرکزی که در حال حاضر در دسترس هستند، یک پیشرفت عظیم است. با این حال، از آنجایی که UTXO همه یا هیچ هستند، تنها راه برای دستیابی به این هدف از طریق هک بسیار ناکارآمد داشتن تعداد زیادی UTXO با ارزشهای مختلف است (مثلاً یک UTXO از 2k برای هر k تا 30) و اوراکل انتخاب کنید که کدام UTXO به A و کدام به B ارسال شود.
+- **عدم وضعیت** - UTXO می تواند خرج شود یا خرج نشده باشد. هیچ فرصتی برای قراردادها یا قراردادهای چند امضایی وجود ندارد که هر حالت داخلی دیگری را فراتر از آن حفظ کند. این امر بستن قراردادهای گزینههای چند مرحلهای، پیشنهادها مبادله غیرمتمرکز یا پروتکلهای تعهد رمزنگاری دو مرحلهای (ضروری برای پاداشهای محاسباتی ایمن) را دشوار میکند. همچنین به این معنی است که UTXO فقط میتواند برای ایجاد قراردادهای ساده و یکبار استفاده شود و نه قراردادهای پیچیدهتر مانند سازمانهای غیرمتمرکز، و اجرای فراپروتکلها را دشوار میکند. حالت دودویی همراه با ارزش کوری همچنین به این معنی است که یک برنامه مهم دیگر، محدودیتهای برداشت، غیرممکن است.
+- **کوری بلاکچین** - UTXO نسبت به داده هایبلاک چین مانند نانس، مهر زمانی و هش بلوک قبلی کور است. این امر با محروم کردن زبان برنامهنویسی از منبع بالقوه با ارزش تصادفی، برنامههای کاربردی در قمار و چندین دسته دیگر را به شدت محدود میکند.
+
+بنابراین، ما سه رویکرد برای ایجاد برنامه های کاربردی پیشرفته در بالای آن می بینیم ارز دیجیتال: ساخت یک بلاکچین جدید، استفاده از اسکریپت در بالای بیت کوین و ساخت یک فرا پروتکل در بالای بیت کوین. ساخت یک زنجیرهی بلوکی جدید آزادی نامحدودی را در ساخت مجموعه ویژگیها امکانپذیر میکند، اما به قیمت زمان توسعه، تلاش و امنیت راهاندازی. استفاده از اسکریپت برای پیادهسازی و استانداردسازی آسان است، اما در قابلیت های آن بسیار محدود است و فرا پروتکل ها، در عین سادگی، از اشکالاتی در مقیاس پذیری رنج می برند. با اتریوم، ما قصد داریم یک چارچوب جایگزین بسازیم که دستاوردهای بزرگتری را در سهولت توسعه و همچنین ویژگیهای کلاینت سبک حتی قویتر فراهم میکند و در عین حال به برنامهها اجازه میدهد محیط اقتصادی و امنیت زنجیرهی بلوکی را به اشتراک بگذارند.
+
+
+
+## اتریوم {#ethereum}
+
+هدف اتریوم ایجاد یک پروتکل جایگزین برای ساخت برنامههای غیرمتمرکز است که مجموعهای متفاوت از معاوضهها را ارائه میکند که معتقدیم برای کلاس بزرگی از برنامههای غیرمتمرکز بسیار مفید خواهد بود، با تاکید ویژه بر موقعیتهایی که زمان توسعه سریع، امنیت برای کوچک و برنامههایی که به ندرت استفاده میشوند و توانایی برنامههای مختلف برای تعامل بسیار کارآمد، مهم هستند. اتریوم این کار را با ساختن لایه اساسی انتزاعی نهایی انجام می دهد: یک بلاک چین با زبان برنامه نویسی داخلی کامل تورینگ، که به هر کسی اجازه می دهد قراردادهای هوشمند و برنامه های غیرمتمرکز بنویسد که در آن می توانند قوانین دلخواه خود را برای مالکیت، فرمت های تراکنش و توابع انتقال حالت ایجاد کنند. توابع انتقال حالت یک نسخه بدون استخوان Namecoin را می توان در دو خط کد نوشت و سایر پروتکل ها مانند ارزها و سیستم های شهرت را می توان در کمتر از بیست خط ایجاد کرد. قراردادهای هوشمند، "جعبه های" رمزنگاری که حاوی مقدار باشد و فقط در صورت رعایت شرایط خاص، می تواند قفل آن را باز کند در بالای پلت فرم ساخته شود، با قدرت بسیار بیشتر از آن ارائه شده توسط اسکریپت بیت کوین به دلیل قدرت های اضافه شده تورینگ-کامل بودن، آگاهی از ارزش، آگاهی از بلاک چین و وضعیت.
+
+
+
+### حساب های اتریوم {#ethereum-accounts}
+
+در اتریوم، حالت از اشیایی به نام «حسابها» تشکیل میشود که هر حساب دارای یک آدرس 20 بایتی است و انتقال حالت، انتقال مستقیم ارزش و اطلاعات بین حسابها است. یک حساب اتریوم شامل چهار فیلد است:
+
+- **نانس**، یک شمارنده برای اطمینان از اینکه هر تراکنش فقط یک بار قابل پردازش است استفاده می شود
+- میزان اتریوم فعلی موجود در کیف پول
+- **کد قرارداد** کیف پول، در صورت موجود بودن
+- **فضای ذخیرهسازی** حساب (به طور پیش فرض خالی است)
+
+"اتر" اصلی ترین سوخت رمزارزی داخلی اتریوم است و برای پرداخت هزینه تراکنش استفاده می شود. به طور کلی، دو نوع حساب وجود دارد: **حسابهای متعلق به خارجی** که توسط کلیدهای خصوصی کنترل میشوند، و **حسابهای قرارداد** که توسط کد قرارداد آنها کنترل میشود. یک حساب دارای مالکیت خارجی هیچ کدی ندارد و می توان با ایجاد و امضای یک تراکنش، از یک حساب دارای مالکیت خارجی پیام ارسال کرد. در یک حساب قراردادی، هر بار که حساب قرارداد پیامی دریافت میکند، کد آن فعال میشود و به آن اجازه میدهد در حافظه داخلی بخواند و بنویسد و پیامهای دیگری ارسال کند یا به نوبه خود قرارداد ایجاد کند.
+
+توجه داشته باشید که "قراردادها" در اتریوم نباید به عنوان چیزی که باید "پر شده" یا "منطبق با" تلقی شود. در عوض، آنها بیشتر شبیه «عاملهای مستقل» هستند که در محیط اجرای اتریوم زندگی میکنند، همیشه یک قطعه کد خاص را هنگام «صدا زدن» توسط یک پیام یا تراکنش اجرا میکنند و کنترل مستقیم بر تعادل اتر خود و ذخیره کلید/مقدار خود برای پیگیری متغیرهای پایدار دارند.
+
+
+
+### پیغام ها و تراکنش ها {#messages-and-transactions}
+
+واژه "تراکنش" در اتریوم برای اشاره به بسته داده امضا شده ای استفاده می شود که پیغامی را ذخیره می کند تا از یک حساب مالکیت خارجی ارسال شود. معاملات شامل:
+
+- گیرنده پیام
+- امضایی برای شناسایی فرستنده
+- مقدار اتر برای انتقال از فرستنده به گیرنده
+- یک فیلد داده اختیاری
+- یک مقدار `STARTGAS`، نشان دهنده حداکثر تعداد مراحل محاسباتی است که اجرای تراکنش مجاز به انجام آن است
+- مقدار `GASPRICE`، نشان دهنده هزینه ای است که فرستنده در هر مرحله محاسباتی می پردازد
+
+سه مورد اول، فیلدهای استاندارد مورد انتظار در هر ارز دیجیتال هستند. فیلد داده به طور پیش فرض عملکردی ندارد، اما ماشین مجازی دارای یک کد عملیاتی است که با استفاده از آن قرارداد می تواند به داده ها دسترسی داشته باشد. به عنوان مثال، اگر قراردادی به عنوان یک سرویس ثبت دامنه روی بلاکچین عمل می کند، ممکن است بخواهد داده های ارسال شده به آن را به عنوان حاوی دو "فیلد" تفسیر کند. فیلد اول دامنه ای برای ثبت نام و فیلد دوم آدرس IP برای ثبت آن است. قرارداد این مقادیر را از داده های پیام خوانده و به طور مناسب آنها را در فضای ذخیرهسازی قرار می دهد.
+
+فیلدهای `STARTGAS` و `GASPRICE` برای مدل ضد انکار خدمات اتریوم بسیار مهم هستند. به منظور جلوگیری از حلقههای نامحدود تصادفی یا متخاصم یا سایر اتلافهای محاسباتی در کد، هر تراکنش باید محدودیتی برای تعداد مراحل محاسباتی اجرای کد تعیین کند. واحد اساسی محاسبات "گس" است. معمولاً، یک مرحله محاسباتی 1 گس هزینه دارد، اما برخی از عملیات ها به دلیل اینکه از نظر محاسباتی گرانتر هستند یا مقدار داده هایی را که باید به عنوان بخشی از حالت ذخیره شوند افزایش می دهند، مقدار گس بیشتری را هزینه می کنند. همچنین برای هر بایت در داده های تراکنش 5 گس کارمزد دریافت می شود. هدف سیستم کارمزد این است که از مهاجم بخواهد به ازای هر منبعی که مصرف میکند، از جمله محاسبات، پهنای باند و ذخیرهسازی، به نسبت هزینه پرداخت کند. از این رو، هر تراکنشی که منجر به مصرف شبکه مقدار بیشتری از هر یک از این منابع شود، باید هزینه گس تقریباً متناسب با افزایش داشته باشد.
+
+
+
+### پیامها {#messages}
+
+قراردادها قابلیت ارسال «پیام» به سایر قراردادها را دارند. پیام ها اشیای مجازی هستند که هرگز سریالی نمی شوند و فقط در محیط اجرای اتریوم وجود دارند. یک پیام شامل موارد زیر است:
+
+- فرستنده پیام (ضمنی)
+- گیرنده پیام
+- مقدار اتر برای انتقال در کنار پیام
+- یک فیلد داده اختیاری
+- یک مقدار `STARTGAS`
+
+اساساً یک پیام مانند یک معامله است، با این تفاوت که توسط یک قرارداد تولید می شود نه یک عامل خارجی. یک پیام زمانی تولید می شود که قراردادی که در حال حاضر کد را اجرا می کند، اپکد `CALL` را اجرا می کند، که پیامی را تولید و اجرا می کند. مانند یک تراکنش، یک پیام به حساب گیرنده منتهی می شود که کد آن را اجرا می کند. بنابراین، قراردادها می توانند دقیقاً به همان شکلی که بازیگران خارجی می توانند با سایر قراردادها رابطه داشته باشند.
+
+توجه داشته باشید که کمک هزینه گس تعیین شده توسط یک معامله یا قرارداد برای کل گس مصرف شده توسط آن معامله و کلیه اجراهای فرعی اعمال می شود. به عنوان مثال، اگر یک بازیگر خارجی A یک تراکنش را با 1000 گس به B ارسال کند، و B قبل از ارسال پیام به C، مقدار 600 گس مصرف کند، و اجرای داخلی C قبل از بازگشت، 300 گس مصرف کند، B می تواند قبل از تمام شدن گس 100 گس دیگر خرج کند.
+
+
+
+### تابع انتقال حالت اتریوم {#ethereum-state-transition-function}
+
+![انتقال حالت اتر](./ether-state-transition.png)
+
+تابع انتقال حالت اتریوم، `APPLY(S,TX) -> S'` را می توان به صورت زیر تعریف کرد:
+
+1. بررسی کنید که آیا تراکنش به خوبی شکل گرفته است (یعنی تعداد مقادیر مناسبی دارد)، امضا معتبر است، و نانس با نانس در حساب فرستنده مطابقت دارد. اگر اینطور نیست، یک خطا بازگردان.
+2. کارمزد تراکنش را به صورت `STARTGAS * GASPRICE` محاسبه کنید و آدرس ارسال را از روی امضا تعیین کنید. کارمزد را از موجودی حساب فرستنده کم کنید و نانس فرستنده را افزایش دهید. اگر موجودی کافی برای خرج کردن وجود ندارد، یک خطا را برگردان.
+3. `GAS = STARTGAS` را راهاندازی کنید و مقدار مشخصی گس را در هر بایت بردارید تا هزینه بایتهای موجود در تراکنش را بپردازید.
+4. انتقال ارزش تراکنش از حساب فرستنده به حساب دریافت کننده. اگر حساب دریافت کننده هنوز وجود ندارد، آن را ایجاد کنید. اگر اکانت دریافت کننده قراردادی است، کد قرارداد را تا پایان یا تا زمانی که گس موجود است اجرا کن.
+5. اگر انتقال ارزش به دلیل نداشتن پول کافی فرستنده انجام نشد، یا بنزین اجرای کد تمام شد، همه تغییرات حالت به جز پرداخت هزینه ها را برگردان و هزینه ها را به حساب ماینر اضافه کن.
+6. در غیر این صورت، هزینه تمام گس باقیمانده را به فرستنده بازپرداخت کن و هزینه های پرداخت شده برای گس مصرف شده را برای ماینر ارسال کن.
+
+به عنوان مثال، فرض کنید که کد قرارداد این است:
+
+
+
+```py
+if !self.storage[calldataload(0)]:
+ self.storage[calldataload(0)] = calldataload(32)
+```
+
+
+توجه داشته باشید که در واقع کد قرارداد در کد EVM سطح پایین نوشته شده است. این مثال برای وضوح در Serpent، یکی از زبان های سطح بالای ما، نوشته شده است و می توان آن را به کد EVM کامپایل کرد. فرض کنید ذخیرهسازی قرارداد خالی شروع میشود و تراکنشی با 10 مقدار اتر، 2000 گس، 0.001 اتر قیمت گس و 64 بایت داده ارسال میشود، با بایتهای 0-31 نشان دهنده عدد `2` و بایت است. 32-63 نشان دهنده رشته `CHARLIE` است. فرآیند تابع انتقال حالت در این مورد به شرح زیر است:
+
+1. بررسی کنید که تراکنش معتبر و به خوبی شکل گرفته است.
+2. بررسی کنید که فرستنده تراکنش حداقل 2000 \* 0.001 = 2 اتر داشته باشد. اگر اینطور است، 2 اتر از حساب فرستنده کم کنید.
+3. گس اولیه = 2000; با فرض اینکه تراکنش 170 بایت و هزینه بایت 5 باشد، 850 را کم کنید تا 1150 گس باقی بماند.
+4. مقدار 10 اتر دیگر از حساب فرستنده کم کنید و آن را به حساب قرارداد اضافه کنید.
+5. کد را اجرا کنید. `GAS = STARTGAS` را راهاندازی کنید و مقدار مشخصی از گس را در هر بایت برداشت تا هزینه بایتهای موجود در تراکنش را بپردازید. فرض کنید این 187 گس می گیرد، بنابراین مقدار گس باقیمانده 1150 - 187 = 963 است
+6. 963 \* 0.001 = 0.963 اتر را دوباره به حساب فرستنده اضافه کنید و حالت حاصل را برگردانید.
+
+اگر قراردادی در پایان تراکنش وجود نداشت، کل کارمزد تراکنش به سادگی برابر با `GASPRICE` ارائه شده ضرب در طول تراکنش بر حسب بایت و داده های ارسال شده در کنار تراکنش بی ربط خواهد بود.
+
+توجه داشته باشید که پیامها از نظر بازگردانیها مانند تراکنشها کار میکنند: اگر گس اجرای پیام تمام شود، اجرای آن پیام و همه اجرایهای دیگر که توسط آن اجرا آغاز میشوند، برمیگردند، اما اجرای والد نیازی به برگرداندن ندارد. این بدان معناست که برای قراردادی "ایمن" است که قرارداد دیگری را فراخوانی کند، زیرا اگر A با گس G برود B را صدا کند، اجرای A تضمین شده است که حداکثر گس G را از دست می دهد. در نهایت، توجه داشته باشید که یک opcode وجود دارد، `CREATE`، که یک قرارداد ایجاد می کند. مکانیک اجرای آن به طور کلی شبیه `CALL` است، با این استثنا که خروجی اجرا کد یک قرارداد جدیدآً ایجاد شده را تعیین می کند.
+
+
+
+### اجرای کد {#code-execution}
+
+کد در قراردادهای اتریوم به زبان بایت کد مبتنی بر پشته، سطح پایین نوشته می شود که به آن «کد ماشین مجازی اتریوم» یا «کد EVM» گفته می شود. کد شامل یک سری بایت است که هر بایت نشان دهنده یک عملیات است. به طور کلی، اجرای کد یک حلقه بی نهایت است که شامل انجام مکرر عملیات در شمارنده برنامه فعلی (که از صفر شروع می شود) و سپس افزایش شمارنده برنامه به یک اندازه، تا رسیدن به انتهای کد یا یک خطا یا < دستورالعمل 0>STOP
یا `RETURN` شناسایی شد. عملیات به سه نوع فضای ذخیرهسازی دادهها دسترسی دارند:
+
+- این **پشته**، محفظهای که میتوان آنها را به بیرون فرستاد و مقادیر را به آن منتقل کرد
+- **Memory**، یک آرایه بایت بی نهایت قابل گسترش است
+- **ذخیره** طولانی مدت قرارداد، یک ذخیره از کلید/ارزش. برخلاف پشته و حافظه که پس از پایان محاسبات بازنشانی میشوند، ذخیرهسازی برای طولانی مدت باقی میماند.
+
+این کد همچنین میتواند به مقدار، فرستنده و دادههای پیام دریافتی و همچنین دادههای هدر بلوک دسترسی داشته باشد و کد همچنین میتواند یک آرایه بایتی از دادهها را به عنوان خروجی برگرداند.
+
+مدل اجرای رسمی کد EVM به طرز شگفت آوری ساده است. در حالی که ماشین مجازی اتریوم در حال اجرا است، حالت محاسباتی کامل آن را میتوان با چند `(block_state، تراکنش، پیام، کد، حافظه، پشته، کامپیوتر، گس)` تعریف کرد، جایی که `block_state 0> حالت جهانی است که شامل تمام حساب ها و شامل موجودی ها و ذخیرهسازی است. در شروع هر دور اجرا، دستورالعمل فعلی با گرفتن pc`امین بایت `کد` (یا 0 اگر `pc >= len(code)`)، و هر دستورالعمل از نظر نحوه تأثیرگذاری بر تاپل، تعریف خاص خود را دارد. برای مثال، `ADD` دو مورد را از پشته بیرون میآورد و مجموع آنها را فشار میدهد، `گس` را به 1 کاهش میدهد و `pc` را به 1 افزایش میدهد و ` SSTORE` دو مورد بالا را از پشته بیرون میآورد و مورد دوم را در فهرستی که مورد اول مشخص کرده است در محل ذخیره قرارداد قرار میدهد. اگرچه راههای زیادی برای بهینهسازی اجرای ماشین مجازی اتریوم از طریق کامپایلسازی بهموقع وجود دارد، پیادهسازی اولیه اتریوم را میتوان در چند صد خط کد انجام داد.
+
+
+
+### بلاکچین و ماینینگ {#blockchain-and-mining}
+
+![بلوک دیاگرام اتریوم اعمال میشود](./ethereum-apply-block-diagram.png)
+
+بلاکچین اتریوم از بسیاری جهات شبیه بلاکچین بیتکوین است، اگرچه تفاوتهایی نیز دارد. تفاوت اصلی بین اتریوم و بیتکوین در معماری بلاکچین این است که بر خلاف بیتکوین، بلاکهای اتریوم شامل یک کپی از لیست تراکنشها و آخرین وضعیت هستند. به غیر از آن، دو مقدار دیگر، شماره بلوک و سختی نیز در بلوک ذخیره میشوند. الگوریتم اصلی اعتبارسنجی بلوک در اتریوم به شرح زیر است:
+
+1. بررسی کنید که آیا بلوک قبلی ارجاع شده وجود دارد و معتبر است.
+2. بررسی کنید که مهر زمانی بلوک بزرگتر از بلوک قبلی ارجاع شده و کمتر از 15 دقیقه در آینده باشد
+3. بررسی کنید که شماره بلوک، سختی، ریشه تراکنش، ریشه عمو و محدودیت گس (مفاهیم مختلف سطح پایین ویژه اتریوم) معتبر هستند.
+4. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
+5. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
+6. اجازه دهید `TX` لیست تراکنش بلوک با `n` تراکنش باشد. برای همه `iها` در `0...n-1`، `S[i+1] = APPLY(S[i],TX[i]) را تنظیم کنید /0>. اگر هر برنامهای خطایی را برمیگرداند، یا اگر کل گس مصرفشده در بلوک تا این نقطه از GASLIMIT` بیشتر شود، یک خطا را برگردانید.
+7. بگذارید `S_FINAL` `S[n]` باشد، اما پاداش بلوک پرداختی به ماینر را اضافه کنید.
+8. بررسی کنید که آیا ریشه درخت مرکل حالت `S_FINAL` با ریشه حالت نهایی ارائه شده در هدر بلوک برابر است یا خیر. اگر چنین باشد، بلوک معتبر است. در غیر این صورت معتبر نیست.
+
+این رویکرد ممکن است در نگاه اول بسیار ناکارآمد به نظر برسد، زیرا باید کل حالت را با هر بلوک ذخیره کند، اما در واقع کارایی باید با بیتکوین قابل مقایسه باشد. دلیل آن این است که حالت در ساختار درختی ذخیره می شود و بعد از هر بلوک فقط قسمت کوچکی از درخت باید تغییر کند. بنابراین، به طور کلی، بین دو بلوک مجاور، اکثریت قریب به اتفاق درخت باید یکسان باشد، و بنابراین داده ها را می توان یک بار ذخیره کرد و دو بار با استفاده از نشانگرها (به عنوان مثال هش درختان فرعی) ارجاع داد. نوع خاصی از درخت که به نام "درخت پاتریشیا" شناخته می شود برای انجام این کار استفاده می شود، از جمله اصلاح مفهوم درخت مرکل که به گره ها اجازه می دهد تا درج و حذف شوند، و نه تنها به طور مؤثر تغییر کنند. علاوه بر این، از آنجایی که تمام اطلاعات وضعیت بخشی از آخرین بلوک است، نیازی به ذخیره کل تاریخچه بلاکچین نیست - استراتژی که اگر بتوان آن را در بیتکوین اعمال کرد، میتوان آن را محاسبه کرد تا 5 تا 20 برابر در فضا صرفهجویی کند.
+
+یک سوال متداول این است که کد قرارداد از نظر سخت افزار فیزیکی "کجا" اجرا می شود. جواب هم ساده است: فرآیند اجرای کد قرارداد بخشی از تعریف تابع انتقال حالت است که بخشی از الگوریتم اعتبارسنج بلوک است، بنابراین اگر تراکنش به بلوک `B` اضافه شود، کد اجرای ایجاد شده توسط آن تراکنش توسط همه گرهها، در حال حاضر و در آینده، که بلوک `B` دانلود و اعتبارسنج میکنند، اجرا خواهد شد.
+
+
+
+## برنامههای کاربردی {#applications}
+
+به طور کلی، سه نوع برنامه سوار بر اتریوم هستند: دسته اول برنامه های مالی هستند که روش های قدرتمندتری را برای مدیریت و عقد قراردادها با استفاده از پول در اختیار کاربران قرار می دهند. این شامل ارزهای فرعی، مشتقات مالی، قراردادهای پوشش ریسک، کیف پول های پس انداز، وصیت نامه و در نهایت حتی برخی از کلاس های قراردادهای کار در مقیاس کامل است. دسته دوم برنامه های نیمه مالی است که در آن پول درگیر است، اما جنبه غیر پولی سنگینی نیز برای کاری که انجام می شود وجود دارد. یک مثال عالی، پاداش های خود-اجباری برای راه حل های مسائل محاسباتی است. در نهایت، برنامه هایی مانند رای گیری آنلاین و حاکمیت غیرمتمرکز وجود دارند که اصلاً مالی نیستند.
+
+
+
+### سیستمهای توکن {#token-systems}
+
+سیستمهای توکن درون بلاکچین کاربردهای زیادی دارند، از ارزهای فرعی که داراییهایی مانند دلار یا طلا را نشان میدهند تا سهام شرکت، توکنهای فردی که نشان دهنده دارایی هوشمند، کوپنهای غیرقابل جعل امن و حتی سیستمهای رمزی بدون هیچ ارتباطی با ارزش متعارف، به عنوان سیستمهای نقطهای برای ایجاد انگیزه استفاده میشوند. پیاده سازی سیستم های توکن در اتریوم به طرز شگفت انگیزی آسان است. نکته کلیدی برای درک این است که تمام یک ارز یا سیستم توکن، اساساً یک پایگاه داده با یک عملیات است: X واحدها را از A کم کنید و واحدهای X را به B بدهید، با این شرط که (i) A حداقل X واحد داشته باشد. قبل از تراکنش و (2) تراکنش توسط A تأیید شود. تمام آنچه برای پیاده سازی یک سیستم توکن نیاز است، پیاده سازی این منطق در یک قرارداد است.
+
+کد اصلی برای پیاده سازی یک سیستم توکن در Serpent به صورت زیر است:
+
+
+
+```py
+def send(to, value):
+ if self.storage[msg.sender] >= value:
+ self.storage[msg.sender] = self.storage[msg.sender] - value
+ self.storage[to] = self.storage[to] + value
+```
+
+
+این اساساً اجرای تحت اللفظی تابع انتقال حالت "سیستم بانکی" است که در بالا در این سند شرح داده شد. چند خط کد اضافی باید اضافه شود تا مرحله اولیه توزیع واحدهای ارزی در وهله اول و چند مورد لبه دیگر فراهم شود، و در حالت ایدهآل تابعی اضافه میشود که به قراردادهای دیگر اجازه میدهد تا تعادل یک آدرس را جستجو کنند. اما این تمام چیزی است که وجود دارد. از نظر تئوری، سیستمهای توکن مبتنی بر اتریوم که بهعنوان ارزهای فرعی عمل میکنند، میتوانند به طور بالقوه ویژگی مهم دیگری را داشته باشند که متا ارزهای مبتنی بر بیتکوین روی زنجیره فاقد آن هستند: توانایی پرداخت مستقیم هزینههای تراکنش در آن ارز. روش اجرای این امر به این صورت است که قرارداد دارای تعادل اتری است که با آن اتری که برای پرداخت هزینهها به فرستنده استفاده میشود بازپرداخت میکند، و این موجودی را با جمعآوری واحدهای ارز داخلی که کارمزد دریافت میکند و فروش مجدد آنها در یک حراج دائمی دوباره پر میکند. بنابراین کاربران باید حساب های خود را با اتر "فعال کنند"، اما زمانی که اتر وجود دارد، قابل استفاده مجدد خواهد بود زیرا قرارداد هر بار آن را بازپرداخت می کند.
+
+
+
+### مشتقات مالی و ارزهای با ارزش ثابت {#financial-derivatives-and-stable-value-currencies}
+
+مشتقات مالی رایج ترین کاربرد "قرارداد هوشمند" و یکی از سادهترین آنها برای پیادهسازی در کد هستند. چالش اصلی در اجرای قراردادهای مالی این است که اکثر آنها نیاز به ارجاع به شاخص قیمت خارجی دارند. به عنوان مثال، یک برنامه بسیار مطلوب، یک قرارداد هوشمند است که در برابر نوسانات اتر (یا یک رمزارز دیگر) با توجه به دلار آمریکا محافظت می کند، اما انجام این کار مستلزم آن است که قرارداد بداند ارزش ETH/USD چقدر است. ساده ترین راه برای انجام این کار، از طریق قرارداد «فید داده» است که توسط یک طرف خاص (مثلاً NASDAQ) نگهداری می شود که به گونه ای طراحی شده است که آن طرف توانایی بهروزرسانی قرارداد را در صورت نیاز داشته باشد، و ارائه رابطی که به سایر قراردادها اجازه می دهد تا یک پیام ارسال کنند. به آن قرارداد پیام دهید و پاسخی دریافت کنید که قیمت را ارائه می دهد.
+
+با توجه به آن عنصر حیاتی، قرارداد پوشش ریسک به شرح زیر است:
+
+1. منتظر بمانید تا طرف اول 1000 اتر را وارد کند.
+2. منتظر بمانید تا طرف دوم 1000 اتر را وارد کند.
+3. ارزش دلاری 1000 اتر را که با کوئری زدن به قرارداد خوراک داده محاسبه می شود، در فضای ذخیرهسازی ثبت کنید، بگویید این مقدار $x است.
+4. پس از 30 روز، به طرف اول و دوم اجازه دهید تا قرارداد را "دوباره فعال کنند" تا اتر به ارزش $x (که با کوئری زدن مجدد به قرارداد خوراک داده برای دریافت قیمت جدید محاسبه می شود) به طرف اول و بقیه به طرف دوم ارسال شود.
+
+چنین قراردادی پتانسیل قابل توجهی در تجارت کریپتویی خواهد داشت. یکی از اصلیترین مشکلاتی که در مورد رمزارزها به آن اشاره میشود، فرِار بودن آن است. اگرچه بسیاری از کاربران و بازرگانان ممکن است امنیت و راحتی کار با دارایی های رمزنگاری شده را بخواهند، اما بسیاری از آنها نمی خواهند با این چشم انداز از دست دادن 23٪ از ارزش سرمایه خود در یک روز روبرو شوند. تا کنون، متداولترین راهحل پیشنهادی، داراییهای دارای پشتوانه صادرکننده بوده است. ایده این است که یک ناشر یک ارز فرعی ایجاد می کند که در آن حق صدور و ابطال واحدها را دارد و یک واحد ارز را به هر کسی که (آفلاین) یک واحد از یک دارایی اساسی مشخص (مثلاً طلا، دلار) را در اختیار آنها قرار می دهد، ارائه دهید. سپس صادرکننده قول میدهد که یک واحد از دارایی پایه را به هر کسی که یک واحد از دارایی رمزنگاری شده را پس میفرستد، ارائه دهد. این مکانیزم به هر دارایی رمزنگارینشده اجازه می دهد تا به یک دارایی رمزنگاری "سربلند" تبدیل شود، مشروط بر اینکه بتوان به صادرکننده اعتماد کرد.
+
+با این حال، در عمل، ناشران همیشه قابل اعتماد نیستند و در برخی موارد زیرساخت بانکی برای وجود چنین خدماتی بسیار ضعیف یا بسیار خصمانه است. مشتقات مالی یک جایگزین را ارائه می دهند. در اینجا، به جای اینکه یک صادرکننده واحد پولی را برای پشتیبانگیری از یک دارایی فراهم کند، یک بازار غیرمتمرکز از سفتهبازان که شرط میبندند قیمت یک دارایی مرجع رمزنگاری (مثلا اتر) بالا خواهد رفت، این نقش را ایفا میکند. بر خلاف صادرکننده، سفته بازان هیچ گزینه ای برای نکول در معامله خود ندارند زیرا قرارداد پوشش ریسک وجوه آنها را در امان نگه می دارد. توجه داشته باشید که این رویکرد کاملاً غیرمتمرکز نیست، زیرا هنوز یک منبع قابل اعتماد برای ارائه شاخص قیمت مورد نیاز است، اگرچه احتمالاً حتی هنوز هم این یک پیشرفت بزرگ از نظر کاهش الزامات زیرساختی است (برخلاف صادرکننده بودن، صدور خوراک قیمت نیازی به مجوز ندارد. و احتمالاً می تواند به عنوان آزادی بیان طبقه بندی شود) و پتانسیل تقلب را کاهش می دهد.
+
+
+
+### سیستم های هویت و شهرت {#identity-and-reputation-systems}
+
+اولین رمزارز جایگزین، [Namecoin](http://namecoin.org/)، تلاش کرد از یک بلاکچین مانند بیتکوین برای ارائه یک سیستم ثبت نام استفاده کند، جایی که کاربران می توانند نام خود را در یک پایگاه داده عمومی در کنار سایر داده ها ثبت کنند. مورد استفاده عمده ذکر شده متعلق به یک سیستم [DNS](https://wikipedia.org/wiki/Domain_Name_System) است که نام های دامنه مانند "bitcoin.org" (یا در مورد Namecoin، "bitcoin.bit") را به یک آدرس IP نگاشت می کند. موارد استفاده دیگر عبارتند از احراز هویت ایمیل و سیستم های شهرت بالقوه پیشرفتهتر. در اینجا قرارداد اصلی برای ارائه یک سیستم ثبت نام مشابه Namecoin در اتریوم است:
+
+
+
+```py
+def register(name, value):
+ if !self.storage[name]:
+ self.storage[name] = value
+```
+
+
+قرارداد بسیار ساده است. همه اینها یک پایگاه داده در داخل شبکه اتریوم است که می توان به آن اضافه کرد، اما نمی توان آن را تغییر داد یا حذف کرد. هر کسی می تواند نامی با مقداری را ثبت کند و آن ثبت نام برای همیشه باقی می ماند. یک قرارداد پیچیدهتر ثبت نام همچنین دارای یک «بند عملکرد» است که به سایر قراردادها امکان میدهد آن را پرس و جو کنند، و همچنین مکانیزمی برای «مالک» (یعنی اولین ثبتکننده) نام برای تغییر داده یا انتقال مالکیت. حتی می توان شهرت و قابلیت های شبکه ای از اعتماد را در بالای آن اضافه کرد.
+
+
+
+### ذخیره سازی غیرمتمرکز فایل {#decentralized-file-storage}
+
+در چند سال گذشته، تعدادی راهانداز ذخیرهسازی فایل آنلاین، معروفترین آنها Dropbox به وجود آمدهاند که به دنبال اجازه دادن به کاربران برای آپلود یک نسخه پشتیبان از هارد دیسک خود و اینکه سرویس پشتیبان را ذخیره کند و به کاربر اجازه دهد در ازای پرداخت هزینه ماهانه به آن دسترسی داشته باشد هستند. با این حال، در این مرحله، بازار ذخیرهسازی فایل در زمانهایی نسبتاً ناکارآمد است. نگاهی گذرا به راهحلهای مختلف موجود نشان میدهد که، بهویژه در سطح 20-200 گیگابایتی «دره غیرعادی» که نه سهمیههای رایگان و نه تخفیفهای سطح سازمانی آغاز میشود، قیمت های ماهانه هزینه های ذخیره سازی فایل اصلی به گونه ای است که شما بیش از هزینه کل هارد دیسک در یک ماه پرداخت می کنید. قراردادهای اتریوم میتوانند به توسعه یک اکوسیستم ذخیرهسازی فایل غیرمتمرکز اجازه دهند، که در آن کاربران فردی میتوانند با اجاره هارد دیسکهای خود مقادیر کمی پول به دست آورند و از فضای بلااستفاده برای کاهش بیشتر هزینههای ذخیرهسازی فایل استفاده شود.
+
+بخش کلیدی زیربنای چنین دستگاهی همان چیزی است که ما آن را "قرارداد غیرمتمرکز Dropbox" نامیده ایم. این قرارداد به شرح زیر عمل می کند. ابتدا، دادههای مورد نظر را به بلوکها تقسیم میکند، هر بلوک را برای حفظ حریم خصوصی رمزگذاری میکند و درخت مرکل را از آن میسازد. سپس یک قرارداد با این قانون منعقد میکند که، هر N بلوک، قرارداد یک شاخص تصادفی در درخت مرکل انتخاب میکند (با استفاده از هش بلوک قبلی، قابل دسترسی از کد قرارداد، به عنوان منبع تصادفی)، و X اتر را به اولین نهادی که یک تراکنش را با یک سند تأیید پرداخت ساده شده مبنی بر مالکیت بلوک در آن شاخص خاص در درخت ارائه می کند، می دهد. هنگامی که کاربر می خواهد فایل خود را دوباره دانلود کند، می تواند از پروتکل کانال پرداخت خرد (مثلاً پرداخت 1 زابو در هر 32 کیلوبایت) برای بازیابی فایل استفاده کند. کارآمدترین رویکرد این است که پرداخت کننده تراکنش را تا پایان منتشر نکند، در عوض تراکنش را با تراکنش کمی سودآورتر با همان نانس پس از هر 32 کیلوبایت جایگزین کند.
+
+یکی از ویژگی های مهم پروتکل این است که، اگرچه ممکن است به نظر برسد که یک نفر به بسیاری از گره های تصادفی اعتماد دارد تا تصمیم به فراموش کردن فایل نداشته باشد، و یک نفر میتواند با تقسیم کردن فایل به قطعات متعدد از طریق اشتراکگذاری مخفی، این ریسک را به نزدیک به صفر کاهش دهد و تماشای قراردادها برای دیدن هر قطعه هنوز در اختیار برخی از گرهها است. اگر یک قرارداد همچنان پولی را پرداخت میکند، این یک مدرک رمزنگاری شده است که نشان میدهد یک نفر هنوز در آنجا دارد فایل را ذخیره میکند.
+
+
+
+### سازمان خودمختار غیرمتمرکز {#decentralized-autonomous-organizations}
+
+مفهوم کلی "سازمان خودمختار غیرمتمرکز" عبارت است از یک نهاد مجازی که دارای مجموعه معینی از اعضا یا سهامداران است که شاید با اکثریت 67 درصدی، حق دارند وجوه آن واحد را خرج کرده و کد آن را اصلاح کنند. اعضا به طور جمعی در مورد نحوه تخصیص بودجه توسط سازمان تصمیم می گیرند. روشهای تخصیص وجوه یک DAO میتواند از جوایز، حقوق گرفته تا مکانیسمهای عجیبتری مانند ارز داخلی برای پاداش دادن به کار متغیر باشد. این اساساً موارد قانونی یک شرکت سنتی یا غیرانتفاعی را تکرار می کند، اما تنها از فناوری بلاکچین رمزنگاری شده برای اجرا استفاده می کند. تاکنون بسیاری از صحبتها در مورد DAOها حول مدل «سرمایهداری» یک «شرکت مستقل غیرمتمرکز» (DAC) با سهامداران دریافتکننده سود سهام و سهام قابل معامله بوده است. یک جایگزین، که شاید به عنوان «جامعه خودمختار غیرمتمرکز» توصیف شود، این است که همه اعضا سهم برابری در تصمیمگیری دارند و 67 درصد از اعضای موجود باید با اضافه کردن یا حذف یک عضو موافقت کنند. این شرط که یک نفر فقط می تواند یک عضویت داشته باشد باید به طور جمعی توسط گروه اجرا شود.
+
+یک طرح کلی برای نحوه کدنویسی یک DAO به شرح زیر است. سادهترین طرح صرفاً یک قطعه کد خود اصلاحکننده است که در صورت توافق دو سوم اعضا بر روی تغییرات تغییر میکند. اگرچه کد از نظر تئوری تغییرناپذیر است، اما با داشتن تکههایی از کد در قراردادهای جداگانه، و ذخیره آدرس قراردادهای فراخوانی ذخیره شده در ذخیرهسازی قابل تغییر، میتوان به راحتی از این موضوع عبور کرد و تغییرپذیری واقعی داشت. در اجرای ساده چنین قرارداد DAO، سه نوع تراکنش وجود دارد که با داده های ارائه شده در تراکنش متمایز می شوند:
+
+- `[0,i,K,V]` برای ثبت پیشنهاد با نمایه `i` برای تغییر آدرس در فهرست ذخیرهسازی `K` به مقدار ` V`
+- برای ثبت رای به نفع پیشنهاد `[1,i]` `i`
+- `[2,i]` برای نهایی کردن پیشنهاد `i` اگر رای کافی داده شده باشد
+
+سپس قرارداد برای هر یک از اینها بندهایی خواهد داشت. این یک رکورد از همه تغییرات فضای باز را به همراه فهرستی از افرادی که به آنها رای داده اند حفظ می کند. همچنین فهرستی از همه اعضا را خواهد داشت. هنگامی که هر تغییر فضای ذخیرهسازی به دو سوم اعضا می رسد که به آن رأی می دهند، یک تراکنش نهایی می تواند تغییر را اجرا کند. یک اسکلت پیچیدهتر همچنین میتواند قابلیت رایگیری داخلی برای ویژگیهایی مانند ارسال تراکنش، افزودن اعضا و حذف اعضا داشته باشد، و حتی ممکن است امکان تفویض رأی به سبک [دموکراسی نقد](https://wikipedia.org/wiki/Liquid_democracy) را فراهم کند (یعنی هرکسی میتواند شخصی را به رای دادن به او اختصاص دهد، و انتساب انتقالی است، بنابراین اگر A به B و B به C اختصاص دهد، C رای A را تعیین میکند). این طراحی به DAO اجازه می دهد تا به صورت ارگانیک به عنوان یک جامعه غیرمتمرکز رشد کند، و به مردم این امکان را می دهد تا در نهایت وظیفه فیلتر کردن اعضای آن را به متخصصان محول کنند، اگرچه برخلاف «سیستم فعلی»، متخصصان به راحتی می توانند در طول زمان وارد و خارج شوند همانطور که افراد جامعه صف بندی خود را تغییر می دهند.
+
+یک مدل جایگزین برای یک شرکت غیرمتمرکز است، که در آن هر حسابی میتواند دارای سهام صفر یا بیشتر باشد و دو سوم سهام برای تصمیمگیری لازم است. یک اسکلت کامل شامل عملکرد مدیریت دارایی، توانایی ارائه پیشنهاد برای خرید یا فروش سهام، و توانایی پذیرش پیشنهادها (ترجیحا با مکانیزم تطبیق سفارش در داخل قرارداد) است. تفویض اختیار نیز به سبک دموکراسی مایع وجود خواهد داشت که مفهوم "هیئت مدیره" را تعمیم می دهد.
+
+
+
+### برنامههای کاربردهای بیشتر {#further-applications}
+
+**1. کیفهای پول پسانداز**. فرض کنید که آلیس (Alice) میخواهد سرمایه خود را ایمن نگه دارد، اما نگران است که از دست بدهد یا کسی کلید خصوصی او را هک کند. او اتر را در یک قرارداد با باب، یک بانک، به شرح زیر قرار می دهد:
+
+- آلیس به تنهایی میتواند حداکثر 1 درصد از وجوه را در روز برداشت کند.
+- باب به تنهایی میتواند حداکثر 1 درصد از وجوه را در روز برداشت کند، اما آلیس این توانایی را دارد که با کلید خود معامله کند و این توانایی را خاموش کند.
+- آلیس و باب با هم میتوانند هر چیزی را پس بگیرند.
+
+به طور معمول، 1 درصد در روز برای آلیس کافی است، و اگر آلیس بخواهد بیشتر برداشت کند، میتواند برای کمک با باب تماس بگیرد. اگر کلید آلیس هک شود، او به سراغ باب میرود تا سرمایه را به یک قرارداد جدید منتقل کند. اگر او کلید خود را گم کند، باب در نهایت وجوه را بیرون خواهد آورد. اگر معلوم شود که باب بدخواه است، او می تواند دسترسی باب را برای برداشت خاموش کند.
+
+**2. بیمه محصول**. می توان به راحتی قرارداد مشتقات مالی منعقد کرد، اما به جای هر شاخص قیمت، از داده های آب و هوا استفاده کرد. اگر یک کشاورز در آیووا مشتقی را خریداری کند که بر اساس بارندگی در آیووا به طور معکوس پرداخت می کند، اگر خشکسالی وجود داشته باشد، کشاورز به طور خودکار پول دریافت می کند و اگر باران کافی باشد، کشاورز خوشحال خواهد شد زیرا محصولات آنها به خوبی انجام می شود. این را می توان به طور کلی به بیمه بلایای طبیعی گسترش داد.
+
+**3. یک خوراک دیتای غیرمتمرکز**. برای قراردادهای مالی برای تفاوت، ممکن است واقعاً بتوان فید داده را از طریق پروتکلی به نام "[SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) غیرمتمرکز کرد". شلینگ کوین (SchellingCoin) اساساً به این صورت عمل میکند: N طرف همه ارزش یک داده معین (مثلاً قیمت اتر/USD) را در سیستم قرار میدهند، مقادیر مرتب میشوند، و هر کس بین صدک 25 و 75 یک توکن به عنوان پاداش دریافت میکند. همه انگیزه ای برای ارائه پاسخی دارند که دیگران ارائه خواهند کرد، و تنها ارزشی که تعداد زیادی از بازیکنان می توانند به طور واقع بینانه روی آن توافق کنند، پیش فرض آشکار است: حقیقت. این مورد یک پروتکل غیرمتمرکز ایجاد میکند که از نظر تئوری میتواند مقادیر زیادی از جمله قیمت اتر/USD، دمای برلین یا حتی نتیجه یک محاسبه سخت خاص را ارائه دهد.
+
+**4. ضمانت چند امضایی هوشمند**. بیتکوین به قراردادهای تراکنش چند امضایی اجازه میدهد که برای مثال، سه کلید از پنج کلید معین میتوانند وجوه را خرج کنند. اتریوم به جزئیات بیشتر اجازه میدهد. به عنوان مثال، از هر پنج نفر چهار نفر میتوانند همه چیز را خرج کنند، از هر پنج نفر سه نفر میتوانند تا 10 درصد در روز و از هر پنج نفر دو نفر میتوانند تا 0.5 درصد در روز خرج کنند. علاوه بر این، اتریوم مالتی سیگ ناهمزمان است - دو طرف میتوانند امضاهای خود را در زمانهای مختلف روی بلاکچین ثبت کنند و آخرین امضا به طور خودکار تراکنش را ارسال میکند.
+
+**5. پردازش ابری**. فناوری EVM همچنین میتواند برای ایجاد یک محیط محاسباتی قابل تأیید استفاده شود و به کاربران این امکان را میدهد که از دیگران بخواهند محاسبات را انجام دهند و سپس بهصورت اختیاری، مدارکی بخواهند که محاسبات در نقاط بازرسی بهطور تصادفی انتخاب شده به درستی انجام شده است. این مورد امکان ایجاد یک بازار رایانش ابری را فراهم میکند که در آن هر کاربر میتواند با دسکتاپ، لپتاپ یا سرور تخصصی خود در آن شرکت کند و از چک کردن اسپات همراه با سپردههای امنیتی میتوان برای اطمینان از قابل اعتماد بودن سیستم استفاده کرد (یعنی گرهها یا نودها نمیتوانند به طور سودآوری تقلب کنند). اگرچه چنین سیستمی ممکن است برای همه کارها مناسب نباشد. به عنوان مثال، کارهایی که به سطح بالایی از ارتباطات بین فرآیندی نیاز دارند، نمیتوانند به راحتی بر روی یک ابر بزرگ از گرهها یا نودها انجام شوند. با این حال، موازی سازی سایر وظایف بسیار آسان تر است. پروژه هایی مانند SETI@home، folding@home و الگوریتم های ژنتیک را می توان به راحتی بر روی چنین پلتفرمی پیادهسازی کرد.
+
+**6. قمار همتا به همتا**. هر تعداد پروتکل قمار همتا به همتا مانند [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Frank Stajano و Richard Clayton را می توان در بلاکچین اتریوم پیادهسازی کرد. سادهترین پروتکل قمار در واقع صرفاً یک قرارداد برای تفاوت در هش بلوک بعدی است و پروتکلهای پیشرفتهتری را میتوان از آنجا ایجاد کرد و خدمات قمار با هزینههای تقریباً صفر ایجاد کرد که توانایی تقلب ندارند.
+
+**7. بازارهای پیش بینی**. به شرط یک اوراکل یا شلینگ کوین، پیادهسازی بازارهای پیشبینی نیز آسان است، و بازارهای پیشبینی همراه با شلینگ کوین ممکن است اولین کاربرد جریان اصلی [futarchy](http://hanson.gmu.edu/futarchy.html) به عنوان پروتکل حاکمیتی برای سازمانهای غیرمتمرکز باشد.
+
+**8. بازارهای غیرمتمرکز زنجیرهای**، با استفاده از سیستم هویت و شهرت به عنوان پایگاه.
+
+
+
+## مسائل متفرقه و نگرانیها {#miscellanea-and-concerns}
+
+
+
+### پروتکل اصلاح شده ی GHOST {#modified-ghost-implementation}
+
+پروتکل "طماعترین زیردرخت مشاهده شده" (GHOST) یک نوآوری است که برای اولین بار توسط Yonatan Sompolinsky و Aviv Zohar در [دسامبر 2013](https://eprint.iacr.org/2013/881.pdf) معرفی شد. انگیزه پشت GHOST این است که بلاک چینهایی با زمان تایید سریع در حال حاضر به دلیل نرخ قدیمی بالا از امنیت کمتری رنج میبرند - زیرا بلوکها زمان مشخصی را برای انتشار در شبکه میطلبند، اگر ماینر A یک بلوک را استخراج کند و سپس ماینر B بلوک دیگری را استخراج کند. قبل از انتشار بلوک ماینر A به B، بلوک ماینر B به هدر می رود و به امنیت شبکه کمک نمی کند. علاوه بر این، یک مشکل متمرکز وجود دارد: اگر ماینر A یک استخر استخراج با 30٪ قدرت هش و B دارای 10٪ قدرت هش باشد، A در 70٪ مواقع (از 30٪ بقیه مواقع) خطر تولید یک بلوک قدیمی را خواهد داشت. A آخرین بلوک را تولید می کند و بنابراین بلافاصله داده های استخراج را دریافت می کند) در حالی که B در 90٪ مواقع خطر تولید یک بلوک قدیمی را دارد. بنابراین، اگر فاصله بلوک به اندازهای کوتاه باشد که نرخ بیات بالا باشد، A بهدلیل اندازهاش به طور قابلتوجهی کارآمدتر خواهد بود. با ترکیب این دو اثر، بلاکچینهایی که بلوکها را به سرعت تولید میکنند، به احتمال زیاد منجر به یک استخر ماینینگ میشوند که درصد زیادی از قدرت هش شبکه را داشته باشد تا بتواند بالفعل بر فرآیند استخراج کنترل داشته باشد.
+
+همانطور که توسط Sompolinsky و Zohar توضیح داده شد، GHOST اولین مشکل از دست دادن امنیت شبکه را با گنجاندن بلوک های قدیمی در محاسبه اینکه کدام زنجیره "طولانی ترین" است را حل می کند. به این معنا که نه تنها والدین و اجداد بعدی یک بلوک، بلکه نوادگان قدیمی اجداد بلوک (در اصطلاح اتریومی، "عمو ها") به محاسباتی اضافه می شوند که کدام بلوک دارای بزرگترین اثبات کار است. برای حل مسئله دوم سوگیری متمرکزسازی، ما فراتر از پروتکل توصیف شده توسط Sompolinsky و Zohar میرویم، و همچنین پاداشهای بلوک را برای قدیمیها ارائه میکنیم: یک بلوک قدیمی 87.5٪ از پاداش پایه خود را دریافت میکند و برادرزاده که شامل بلوک قدیمی است، 12.5 درصد بقیه را دریافت میکند. با این حال، کارمزد تراکنش به عموها تعلق نمی گیرد.
+
+اتریوم نسخه ساده شده GHOST را پیاده سازی می کند که تنها در هفت سطح پایین می آید. به طور مشخص به صورت زیر تعریف می شود:
+
+- یک بلوک باید یک والد را مشخص کند و باید 0 یا چند عمو را مشخص کند
+- عموی موجود در بلوک B باید دارای ویژگی های زیر باشد:
+ - این باید یک فرزند مستقیم از اجداد نسل k ام B باشد که در آن `2 <= k <= 7`.
+ - نمی تواند جد B باشد
+ - عمو باید یک هدر بلوک معتبر باشد، اما نیازی نیست که قبلاً یک بلوک تأیید شده یا حتی معتبر باشد
+ - یک عمو باید با همه عموهای موجود در بلوک های قبلی و سایر عموهای موجود در همان بلوک متفاوت باشد (غیر شامل دوگانه)
+- به ازای هر عموی U در بلوک B، ماینر B 3.125٪ اضافی به پاداش کوینبیس خود اضافه می کند و ماینر U 93.75٪ از پاداش استاندارد کوینبیس را دریافت می کند.
+
+این نسخه محدود GHOST، با عموهایی که فقط تا 7 نسل را شامل می شود، به دو دلیل استفاده شد. اولاً، GHOST نامحدود شامل پیچیدگی های بسیار زیادی در محاسبه است که عموهای یک بلوک معین معتبر هستند. دوم، GHOST نامحدود با جبرانی که در اتریوم استفاده میشود، انگیزه استخراجکننده را برای استخراج از زنجیره اصلی و نه زنجیره مهاجم عمومی را از بین میبرد.
+
+
+
+### کارمزدها {#fees}
+
+از آنجایی که هر تراکنش منتشر شده در بلاکچین، هزینه دانلود و تأیید آن را بر شبکه تحمیل میکند، برای جلوگیری از سوء استفاده، نیاز به مکانیزمی نظارتی وجود دارد که معمولاً شامل کارمزد تراکنش است. رویکرد پیشفرض، که در بیتکوین استفاده میشود، داشتن هزینههای کاملاً داوطلبانه است، با تکیه بر ماینرها که به عنوان دروازهبان عمل میکنند و حداقلهای پویا را تعیین میکنند. این رویکرد در جامعه بیتکوین با استقبال بسیار خوبی مواجه شده است، بهویژه به این دلیل که «مبتنی بر بازار» است و به عرضه و تقاضای بین ماینرها و فرستندگان تراکنش اجازه میدهد تا قیمت را تعیین کنند. با این حال، مشکل این خط استدلال این است که پردازش معاملات یک بازار نیست. اگرچه به طور شهودی درک پردازش تراکنش به عنوان خدماتی که ماینر به فرستنده ارائه میدهد جذاب است، در واقع هر تراکنشی که توسط ماینر شامل میشود باید توسط هر گره یا نود در شبکه پردازش شود، بنابراین اکثریت قریب به اتفاق هزینه تراکنش پردازش به عهده اشخاص ثالث است و نه ماینری که تصمیم می گیرد که آن را شامل شود یا نه. از این رو، مشکلات تراژدی رایج بسیار محتمل است.
+
+با این حال، همانطور که مشخص است این نقص در مکانیسم مبتنی بر بازار، زمانی که یک فرض سادهسازی نادرست خاص داده میشود، به طور جادویی خود را خنثی میکند. استدلال به شرح زیر است. فرض کنید که:
+
+1. یک تراکنش به عملیات `k` منتهی میشود، و پاداش `kR` را به هر استخراجکنندهای که شامل آن میشود، ارائه میکند، جایی که `R` توسط فرستنده و `k تنظیم شده است. ` و `R` از قبل (تقریبا) برای ماینر قابل مشاهده هستند.
+2. یک عملیات دارای هزینه پردازش `C` برای هر گره است (یعنی همه گره ها کارایی یکسانی دارند)
+3. تعداد `N` گره ماینینگ وجود دارد که هر کدام دقیقاً قدرت پردازشی برابری دارند (یعنی `1/N` از کل)
+4. هیچ گره کامل غیر ماینینگی وجود ندارد.
+
+اگر پاداش مورد انتظار بیشتر از هزینه باشد، یک ماینر مایل به پردازش یک تراکنش است. بنابراین، پاداش مورد انتظار `kR/N` است زیرا ماینر شانس `1/N` برای پردازش بلوک بعدی را دارد و هزینه پردازش برای ماینر به سادگی ` است. kC`. بنابراین، ماینرها شامل تراکنشهایی میشوند که در آنها `kR/N > kC`، یا `R > NC` باشد. توجه داشته باشید که `R` کارمزد هر عملیات ارائه شده توسط فرستنده است، و بنابراین یک حد پایینتر برای سودی است که فرستنده از تراکنش کسب میکند،و `NC` هزینه کل شبکه برای پردازش یک عملیات است. از این رو، ماینرها این انگیزه را دارند که فقط آن دسته از تراکنشهایی را بگنجانند که کل سود از هزینه آن بیشتر باشد.
+
+با این حال، چندین انحراف مهم از این فرضیات در واقعیت وجود دارد:
+
+1. ماینر هزینه بیشتری را برای پردازش تراکنش نسبت به سایر گرهها یا نودهای تأیید کننده پرداخت میکند، زیرا زمان تأیید اضافی انتشار بلوک را به تأخیر میاندازد و در نتیجه احتمال بسته شدن بلوک را افزایش میدهد.
+2. گره یا نودهای کامل غیر ماینینگ وجود دارد.
+3. توزیع نیروی استخراج ممکن است در عمل به شدت نابرابر شود.
+4. دلالان، دشمنان سیاسی و دیوانههایی که عملکرد مفید آنها شامل ایجاد آسیب به شبکه است، وجود دارند، و میتوانند هوشمندانه قراردادهایی را تنظیم کنند که هزینه آنها بسیار کمتر از هزینه پرداخت شده توسط سایر گرهها یا نودهای تأیید کننده باشد.
+
+(1) تمایلی را برای ماینر فراهم می کند که تراکنش های کمتری را شامل شود، و (2) `NC` را افزایش می دهد. بنابراین، این دو اثر حداقل تا حدی یکدیگر را خنثی می کنند.[چگونه؟] https://github.com/ethereum/wiki/issues/447#issuecomment-316972260) (3) و (4) موضوع اصلی هستند. برای حل آنها به سادگی یک سرمایه شناور ایجاد می کنیم: هیچ بلوکی نمی تواند بیش از `BLK_LIMIT_FACTOR` برابر میانگین متحرک نمایی بلندمدت عملیات داشته باشد. به خصوص:
+
+
+
+```js
+blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
+floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)
+```
+
+
+`BLK_LIMIT_FACTOR` و `EMA_FACTOR` ثابتهایی هستند که فعلاً روی 65536 و 1.5 تنظیم میشوند، اما احتمالاً پس از تجزیه و تحلیل بیشتر تغییر خواهند کرد.
+
+عامل دیگری نیز وجود دارد که اندازه بلوکهای بزرگ را در بیتکوین از بین میبرد: بلوکهایی که بزرگ هستند زمان بیشتری طول میکشد تا انتشار پیدا کنند و در نتیجه احتمال بیات شدن آنها بیشتر است. در اتریوم، انتشار بلوکهای بسیار مصرفکننده گس هم به دلیل بزرگتر بودن و هم به دلیل اینکه پردازش انتقالهای حالت تراکنش برای تأیید اعتبار بیشتر طول میکشد، ممکن است بیشتر طول بکشد. این بازدارنده تاخیر در بیتکوین مورد توجه قرار می گیرد، اما در اتریوم به دلیل پروتکل GHOST کمتر مورد توجه قرار می گیرد. از این رو، تکیه بر محدودیت های بلوک تنظیم شده، پایه پایدارتری را فراهم می کند.
+
+
+
+### محاسبات و تورینگ کامل بودن {#computation-and-turing-completeness}
+
+یک نکته مهم این است که ماشین مجازی اتریوم تورینگ کامل است. این بدان معنی است که کد EVM می تواند هر محاسباتی را که می توان انجام داد، از جمله حلقه های بی نهایت، رمزگذاری کند. کد EVM به دو صورت امکان حلقه زدن را می دهد. اول، یک دستورالعمل `JUMP` وجود دارد که به برنامه اجازه می دهد به نقطه قبلی در کد بازگردد، و یک دستور `JUMPI` برای انجام پرش شرطی، اجازه می دهد تا عباراتی مانند `در حالی که x < 27: x = x * 2` است. دوم، قراردادها میتوانند قراردادهای دیگری را فراخوانی کنند، که امکان چرخش از طریق بازگشت را فراهم میکند. این مورد به طور طبیعی منجر به یک مشکل میشود: آیا کاربران مخرب اساساً میتوانند ماینرها و گره یا نودهای کامل را با مجبور کردن آنها برای ورود به یک لوپ (loop) بینهایت ببندند؟ این موضوع به دلیل مشکلی در علم کامپیوتر به نام مشکل توقف به وجود میآید: در حالت کلی، هیچ راهی برای تشخیص اینکه آیا یک برنامه مشخص هرگز متوقف میشود یا خیر وجود ندارد.
+
+همانطور که در بخش انتقال وضعیت توضیح داده شد، راهحل ما با نیاز به یک تراکنش برای تنظیم حداکثر تعداد مراحل محاسباتی که مجاز به انجام آن هستند، کار میکند، و اگر اجرا طول بکشد، محاسبات برگردانده میشود اما هنوز هزینهها پرداخت میشود. پیامها به همین صورت عمل میکنند. برای نشان دادن انگیزه راه حل ما، مثالهای زیر را در نظر بگیرید:
+
+- یک مهاجم قراردادی ایجاد میکند که یک حلقه بینهایت اجرا میکند، و سپس یک تراکنش فعالسازی آن حلقه را برای ماینر ارسال میکند. ماینر تراکنش را پردازش می کند، حلقه بی نهایت را اجرا می کند و منتظر می ماند تا گس آن تمام شود. حتی اگر گس اجرا تمام شود و در نیمه راه متوقف شود، تراکنش هنوز معتبر است و ماینر همچنان هزینه هر مرحله محاسباتی را از مهاجم مطالبه می کند.
+- یک مهاجم یک حلقه بینهایت بسیار طولانی ایجاد می کند که قصد دارد ماینر را مجبور کند که محاسبات را برای مدت طولانی ادامه دهد تا زمانی که محاسبات به پایان برسد، چند بلوک دیگر بیرون آمده و برای ماینر امکان گنجاندن تراکنش برای مطالبه کارمزد وجود نخواهد داشت. با این حال، مهاجم باید مقداری را برای `STARTGAS` ارسال کند که تعداد مراحل محاسباتی را که اجرا میتواند انجام دهد محدود میکند. بنابراین ماینر از قبل میداند که محاسبه تعداد بسیار زیادی از مراحل را طی میکند.
+- مهاجم قراردادی را با کدهایی مانند `send(A,contract.storage[A]) می بیند. contract.storage[A] = 0`، و تراکنش را با گس کافی برای اجرای مرحله اول ارسال می کند اما مرحله دوم را نه (یعنی برداشت انجام می دهد اما اجازه نمی دهد موجودی پایین بیاید). نویسنده قرارداد نیازی به نگرانی در مورد محافظت در برابر چنین حملاتی ندارد، زیرا اگر اجرا در نیمه راه متوقف شود، تغییرات برگردانده می شوند.
+- یک قرارداد مالی با استفاده از میانه 9 خوراک دیتای اختصاصی به منظور به حداقل رساندن ریسک کار می کند. مهاجم یکی از فیدهای داده را در اختیار می گیرد که به گونه ای طراحی شده است که از طریق مکانیسم متغیر-آدرس-فراخوانی توضیح داده شده در بخش DAO قابل تغییر باشد، و آن را به یک حلقه بی نهایت تبدیل می کند، در نتیجه تلاش می کند هر گونه تلاش برای مطالبه وجوه از قرارداد مالی را مجبور به تمام شدن گاز کند. با این حال، قرارداد مالی می تواند برای جلوگیری از این مشکل محدودیتی برای پیام تعیین کند.
+
+تورینگ کامل نبودن جایگزین تورینگ کامل بودن است، که در آن `JUMP` و `JUMPI` وجود ندارند و فقط یک نسخه از هر قرارداد مجاز است در هر زمان معین در پشته تماس وجود داشته باشد. با این سیستم، سیستم کارمزد توصیف شده و عدم اطمینان در مورد اثربخشی راه حل ما ممکن است ضروری نباشد، زیرا هزینه اجرای یک قرارداد به اندازه آن محدود می شود. علاوه بر این، ناقص بودن تورینگ حتی یک محدودیت بزرگ هم نیست. از بین تمام نمونههای قراردادی که به صورت داخلی تصور کردهایم، تا کنون تنها یک مورد نیاز به یک حلقه داشت، و حتی آن حلقه را می توان با ایجاد 26 تکرار از یک قطعه کد یک خطی حذف کرد. با توجه به پیامدهای جدی تورینگ کامل بودن و مزایای محدود، چرا به سادگی یک زبان تورینگ ناکامل نداشته باشیم؟ با این حال، در واقعیت، تورینگ ناکامل به دور از یک راه حل ساده برای مشکل است. برای اینکه بفهمید چرا، قراردادهای زیر را در نظر بگیرید:
+
+
+
+```sh
+C0: call(C1); call(C1);
+C1: call(C2); call(C2);
+C2: call(C3); call(C3);
+...
+C49: call(C50); call(C50);
+C50: (run one step of a program and record the change in storage)
+```
+
+
+اکنون یک تراکنش به A ارسال کنید. بنابراین، در 51 تراکنش، قراردادی داریم که 250 مرحله محاسباتی را طی می کند. ماینرها میتوانند با حفظ مقداری در کنار هر قرارداد که حداکثر تعداد مراحل محاسباتی را که میتواند انجام دهد، این بمبهای منطقی را پیش از موعد شناسایی کنند، و محاسبه این برای قراردادهایی که قراردادهای دیگر را به صورت بازگشتی فراخوانی میکنند، اما این امر مستلزم آن است که ماینرها قراردادهایی را که قراردادهای دیگری ایجاد میکنند ممنوع کنند (از آنجایی که ایجاد و اجرای تمام 26 قرارداد فوق به راحتی می تواند در یک قرارداد واحد تبدیل شود). نکته مشکلساز دیگر این است که فیلد آدرس یک پیام یک متغیر است، بنابراین به طور کلی ممکن است حتی نتوان گفت که یک قرارداد معین با کدام قراردادهای دیگر پیش از موعد تماس خواهد گرفت. بنابراین، در مجموع، ما یک نتیجه شگفتانگیز داریم: مدیریت کامل بودن تورینگ بهطور شگفتانگیزی آسان است، و مدیریت عدم وجود تورینگ کامل بودن به همان اندازه دشوار است، مگر اینکه دقیقاً همان کنترلها وجود داشته باشد - اما در این مورد چرا نه فقط اجازه دهید پروتکل تورینگ کامل باشد?
+
+
+
+### ارز و صدور {#currency-and-issuance}
+
+شبکه اتریوم شامل ارز داخلی خود به نام اتر است که هدف دوگانه ارائه یک لایه نقدینگی اولیه را برای تبادل کارآمد بین انواع مختلف داراییهای دیجیتال و مهمتر از آن، ارائه مکانیزمی برای پرداخت هزینه تراکنشها دارد. برای سهولت و اجتناب از استدلال های آینده (به بحث فعلی mBTC/uBTC/satoshi در بیتکوین مراجعه کنید)، مقادیر ارزش از قبل نامگذاری گذاری خواهند شد:
+
+- 1: wei
+- 1012: szabo
+- 1015: finney
+- 1018: ether
+
+این باید به عنوان یک نسخه توسعه یافته از مفهوم "دلار" و "سنت" یا "بیتکوین" و "ساتوشی" در نظر گرفته شود. در آینده نزدیک، ما انتظار داریم که "اتر" برای تراکنش های معمولی، "finney" برای تراکنش های خرد و "szabo" و "wei" برای بحث های فنی در مورد هزینه ها و اجرای پروتکل استفاده شود. ارزشهای باقیمانده ممکن است بعداً مفید باشند و در این مرحله نباید در مشتریان گنجانده شوند.
+
+مدل صدور به صورت زیر خواهد بود:
+
+- اتر در فروش ارزی با قیمت 1000 تا 2000 اتر در هر بیتکوین عرضه خواهد شد، مکانیزمی که برای تامین مالی سازمان اتریوم و پرداخت هزینه توسعه در نظر گرفته شده است که با موفقیت توسط پلتفرمهای دیگری مانند مسترکوین (Mastercoin) و NXT استفاده شده است. خریداران اولیه از تخفیفهای بیشتری بهرهمند خواهند شد. بیت کوین دریافتی از فروش کامل برای پرداخت حقوق و جوایز به توسعهدهندگان و سرمایهگذاری در پروژههای مختلف انتفاعی و غیرانتفاعی در اتریوم و اکوسیستم ارزهای دیجیتال استفاده میشود.
+- 0.099 برابر کل مبلغ فروخته شده (60102216 اتر) برای جبران خسارت مشارکتکنندگان اولیه و پرداخت هزینههای اتر قبل از بلوک پیدایش به سازمان تخصیص داده میشود.
+- 0.099 برابر کل مبلغ فروخته شده به عنوان ذخیره بلند مدت نگهداری میشود.
+- 0.26 برابر کل مبلغ فروخته شده برای همیشه پس از آن نقطه به ماینرها در سال اختصاص می یابد.
+
+| گروه | در زمان راهاندازی | بعد از 1 سال | بعد از 5 سال |
+| ------------------------ | ------------------ | ------------ | ------------ |
+| واحدهای ارزی | 1.198X | 1.458X | 2.498X |
+| خریداران | 83.5% | 68.6% | 40.0% |
+| رزرو صرف شده در پیش فروش | 8.26% | 6.79% | 3.96% |
+| رزرو صرف شده پس از فروش | 8.26% | 6.79% | 3.96% |
+| ماینرها | 0% | 17.8% | 52.0% |
+
+
+
+
+#### نرخ رشد عرضه بلندمدت (درصد)
+
+![تورم اتریوم](./ethereum-inflation.png)
+
+_با وجود انتشار ارز خطی، درست مانند بیتکوین در طول زمان، نرخ رشد عرضه با این وجود به صفر میرسد._
+
+دو انتخاب اصلی در مدل فوق عبارتند از (1) وجود و اندازه یک استخر وقف، و (2) وجود یک عرضه خطی دائما در حال رشد، در مقابل عرضه سقفی مانند بیتکوین. توجیه استخر وقف به شرح زیر است. اگر استخر وقف وجود نداشت، و انتشار خطی به 0.217 برابر کاهش می یافت تا نرخ تورم یکسانی ارائه شود، آنگاه مقدار کل اتر 16.5٪ کمتر می شد و بنابراین هر واحد 19.8٪ ارزش بیشتری داشت. بنابراین، در حالت تعادل 19.8٪ اتر بیشتر در فروش خریداری می شود، بنابراین هر واحد دوباره دقیقاً به اندازه قبل ارزشمند خواهد بود. این سازمان همچنین 1.198 برابر همان بیتکوین خواهد داشت که می توان آن را به دو بخش تقسیم کرد: بیتکوین اصلی و 0.198 برابر دیگر. از این رو، این وضعیت _دقیقاً معادل_ با وقف است، اما با یک تفاوت مهم: سازمان صرفاً BTC را در اختیار دارد، و بنابراین انگیزه ای برای حمایت از ارزش واحد اتر ندارد.
+
+مدل رشد عرضه خطی دائمی خطر آنچه را که برخی به عنوان تمرکز بیش از حد ثروت در بیتکوین می دانند، کاهش می دهد. و به افرادی که در دوران کنونی و آینده زندگی می کنند فرصت مناسبی برای بدست آوردن واحدهای ارزی می دهد، در حالی که در عین حال انگیزه قوی برای به دست آوردن و نگهداری اتر حفظ می شود زیرا "نرخ رشد عرضه" به عنوان درصد همچنان در طول زمان به صفر تمایل دارد. ما همچنین این نظریه را مطرح می کنیم که چون سکه ها همیشه در طول زمان به دلیل بی احتیاطی، مرگ و غیره گم می شوند، و زیان سکه را می توان به صورت درصدی از کل عرضه در سال مدل کرد، که در واقع عرضه کل ارز در گردش در نهایت در ارزشی برابر با انتشار سالانه تقسیم بر نرخ ضرر تثبیت می شود. (به عنوان مثال، با نرخ ضرر 1٪، هنگامی که عرضه به 26X رسید، 0.26X استخراج می شود و 0.26X هر سال از دست می رود و تعادل ایجاد می کند).
+
+توجه داشته باشید که در آینده، این احتمال وجود دارد که اتریوم برای امنیت به مدل اثبات سهام روی بیاورد و نیاز صدور را بین صفر تا 0.05 برابر در سال کاهش دهد. در صورتی که سازمان اتریوم بودجه خود را از دست بدهد یا به هر دلیل دیگری ناپدید شود، یک "قرارداد اجتماعی" را باز می گذاریم: هر کسی حق دارد یک نسخه کاندید آینده اتریوم ایجاد کند، تنها شرط این است که مقدار اتر باید حداکثر برابر با `60102216 * (1.198 + 0.26 * n)` باشد که در آن `n` تعداد سالهای پس از بلوک پیدایش است. سازندگان مختارند که به صورت انبوه بفروشند یا برخی یا تمام تفاوت بین گسترش عرضه مبتنی بر PoS و حداکثر گسترش عرضه مجاز را برای پرداخت هزینه توسعه اختصاص دهند. نامزدهای ارتقا که با قرارداد اجتماعی مطابقت ندارند، ممکن است به طور موجه در نسخه های سازگار تقسیم شوند.
+
+
+
+### تمرکزگرایی ماینینگ {#mining-centralization}
+
+الگوریتم استخراج بیتکوین به این صورت کار می کند که ماینرها SHA256 را بر روی نسخه های کمی تغییر یافته هدر بلوک میلیون ها بار و بارها محاسبه کنند تا اینکه در نهایت یک گره نسخه ای را ارائه می دهد که هش آن کمتر از هدف است (در حال حاضر حدود 2192 ). با این حال، این الگوریتم استخراج در برابر دو شکل از تمرکزگرایی آسیب پذیر است. اول، اکوسیستم ماینینگ تحت تسلط ASIC ها (مدارهای مجتمع ویژه برنامه)، تراشه های کامپیوتری طراحی شده و در نتیجه هزاران بار کارآمدتر در وظایف خاص استخراج بیتکوین قرار گرفته است. این به این معنی است که استخراج بیتکوین دیگر یک پیگیری بسیار غیرمتمرکز و برابری طلبانه نیست و برای مشارکت موثر در آن به میلیون ها دلار سرمایه نیاز دارد. دوم، اکثر ماینرهای بیتکوین در واقع اعتبارسنج بلوک را به صورت محلی انجام نمی دهند. در عوض، آنها به یک استخر استخراج متمرکز برای ارائه هدرهای بلوک متکی هستند. این مشکل مسلماً بدتر است: تا زمان نگارش این مقاله، سه استخر استخراج برتر به طور غیرمستقیم تقریباً 50 درصد از قدرت پردازش در شبکه بیتکوین را کنترل میکنند، اگر چه اگر یک استخر یا ائتلاف حمله ای 51 درصدی انجام دهد، این امر با این واقعیت کاهش می یابد که ماینرها می توانند به استخرهای استخراج دیگر روی آورند.
+
+هدف فعلی اتریوم استفاده از یک الگوریتم استخراج است که در آن ماینرها باید دادههای تصادفی را از حالت واکشی کنند، برخی از تراکنشهای انتخابی تصادفی را از آخرین N بلوک در بلاکچین محاسبه کنند و هش نتیجه را برگردانند. این امر دو فایده مهم دارد. اول، قراردادهای اتریوم می توانند شامل هر نوع محاسباتی باشند، بنابراین یک ASIC اتریوم اساساً یک ASIC برای محاسبات عمومی خواهد بود - یعنی CPU بهتر. دوم، ماینینگ نیاز به دسترسی به کل بلاک چین دارد و ماینرها را مجبور می کند کل بلاکچین را ذخیره کنند و حداقل بتوانند هر تراکنش را تأیید کنند. این امر نیاز به استخرهای استخراج متمرکز را از بین می برد. اگرچه استخرهای ماینینگ همچنان میتوانند نقش مشروع توزیع تصادفی پاداش را ایفا کنند، این عملکرد میتواند به همان اندازه توسط استخرهای همتا به همتا و بدون کنترل مرکزی انجام شود.
+
+این مدل آزمایش نشده است و ممکن است هنگام استفاده از اجرای قرارداد به عنوان یک الگوریتم استخراج، مشکلاتی در اجتناب از بهینهسازی های هوشمندانه وجود داشته باشد. با این حال، یکی از ویژگیهای جالب توجه این الگوریتم این است که به هر کسی اجازه میدهد «در چاه آب سم بریزد»، با وارد کردن تعداد زیادی قرارداد به بلاکچینی که بهطور خاص برای جلوگیری از ASICهای خاص طراحی شدهاند. انگیزه های اقتصادی برای سازندگان ASIC وجود دارد تا از چنین ترفندی برای حمله به یکدیگر استفاده کنند. بنابراین، راه حلی که ما در حال توسعه آن هستیم، در نهایت یک راه حل اقتصادی سازگار انسانی است تا صرفاً فنی.
+
+
+
+### قابل مقیاس {#scalability}
+
+یکی از نگرانیهای رایج در مورد اتریوم مسئله مقیاسپذیری است. مانند بیتکوین، اتریوم نیز از این نقص رنج میبرد که هر تراکنش باید توسط هر گره یا نود در شبکه پردازش شود. با بیتکوین، اندازه بلاکچین فعلی در حدود 15 گیگابایت است که حدود 1 مگابایت در ساعت افزایش مییابد. اگر شبکه بیتکوین 2000 تراکنش ویزا را در ثانیه پردازش کند، 1 مگابایت در هر سه ثانیه (1 گیگابایت در ساعت، 8 ترابایت در سال) رشد میکند. اتریوم احتمالاً از الگوی رشد مشابهی رنج میبرد، که با این واقعیت بدتر شده است که برنامههای کاربردی زیادی بر روی بستر بلاکچین اتریوم به جای ارز مانند بیتکوین وجود خواهد داشت، اما با این واقعیت که گره های کامل اتریوم به جای کل تاریخچه بلاکچین، فقط وضعیت را ذخیره می کنند، بهبود یافته است.
+
+مشکل چنین اندازه بلاکچین بزرگی، ریسک تمرکزگرایی است. اگر اندازه بلاکچین به مثلاً 100 ترابایت افزایش یابد، سناریوی محتمل این خواهد بود که تنها تعداد بسیار کمی از کسبوکارهای بزرگ گرههای کامل را اجرا کنند و همه کاربران عادی از گرههای SPV سبک استفاده کنند. در چنین شرایطی، این نگرانی وجود دارد که گره یا نودهای کامل میتوانند به یکدیگر متصل شوند و همه توافق کنند که به شیوهای سودآور تقلب کنند (مثلاً پاداش بلوک را تغییر دهند، به خود بیتکوین بدهند). گره های سبک هیچ راهی برای تشخیص فوری این موضوع ندارند. البته، حداقل یک گره کامل صادقانه احتمالا وجود خواهد داشت، و پس از چند ساعت اطلاعات مربوط به کلاهبرداری از طریق کانالهایی مانند ردیت منتشر میشود، اما در آن مرحله دیگر خیلی دیر شده است: این ساماندهی بر عهده کاربران عادی است که تلاشی را برای فهرست سیاه بلوک های داده شده سازماندهی کنند، یک مشکل هماهنگی عظیم و احتمالا غیرقابل اجرا در مقیاسی مشابه با انجام یک حمله موفق 51 درصدی. در مورد بیتکوین، این در حال حاضر یک مشکل است، اما یک اصلاح بلاکچینی [پیشنهاد شده توسط پیتر تاد](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) وجود دارد که این مشکل را کاهش می دهد.
+
+در کوتاه مدت، اتریوم از دو استراتژی اضافی برای مقابله با این مشکل استفاده خواهد کرد. اولاً، به دلیل الگوریتمهای استخراج مبتنی بر بلاکچین، حداقل هر ماینر مجبور میشود که یک گره کامل باشد و یک حد پایینتر برای تعداد گرههای کامل ایجاد کند. دوم و مهمتر، با این حال، ما پس از پردازش هر تراکنش، یک ریشه درخت حالت میانی را در بلاکچین قرار می دهیم. حتی اگر اعتبار سنجی بلوک متمرکز باشد، تا زمانی که یک گره یا نود راستیآزمایی صادقانه وجود داشته باشد، مشکل متمرکزسازی را میتوان از طریق یک پروتکل تأیید دور زد. اگر یک ماینر یک بلوک نامعتبر منتشر کند، آن بلوک یا باید بد قالب باشد یا وضعیت `S[n]` نادرست است. از آنجایی که `S[0]` به عنوان صحیح شناخته شده است، باید اولین حالت `S[i]` وجود داشته باشد که در جایی که `S[i-1]> نادرست است 0> صحیح است. گره تأیید کننده شاخص i` را به همراه یک "اثبات عدم اعتبار" شامل زیرمجموعه گره های درخت پاتریشیا که نیاز به پردازش `APPLY(S[i-1],TX[i) را ارائه می کند.]) -> S[i]`. گره ها می توانند از آن گره ها برای اجرای آن قسمت از محاسبات استفاده کنند و ببینند که `S[i]` تولید شده با `S[i]` ارائه شده مطابقت ندارد.
+
+حمله دیگر، پیچیدهتر، شامل ماینرهای مخرب است که بلوکهای ناقص را منتشر میکنند، بنابراین اطلاعات کامل حتی برای تعیین معتبر بودن یا نبودن بلوکها وجود ندارد. راهحل این یک پروتکل پاسخ به چالش است: گرههای تأیید «چالشها» را در قالب شاخصهای تراکنش هدف ایجاد میکنند. و با دریافت یک گره، یک گره نوری، بلوک را تا زمانی که گره دیگری غیرقابل اعتماد است، در نظر می گیرد. چه ماینر یا تایید کننده دیگر، زیرمجموعه ای از گره های پاتریشیا را به عنوان اثبات اعتبار ارائه می دهد.
+
+
+
+## نتيجه گيری {#conclusion}
+
+پروتکل اتریوم در ابتدا به عنوان یک نسخه ارتقا یافته از یک ارز رمزنگاری شده در نظر گرفته شد که ویژگیهای پیشرفتهای مانند سپرده روی بلاکچین، محدودیتهای برداشت، قراردادهای مالی، بازارهای شرط بندی و موارد مشابه را از طریق یک زبان برنامهنویسی بسیار تعمیمیافته ارائه میدهد. پروتکل اتریوم مستقیماً از هیچ یک از برنامهها پشتیبانی نمیکند، اما وجود یک زبان برنامهنویسی کامل تورینگ به این معنی است که از نظر تئوری میتوان قراردادهای دلخواه را برای هر نوع تراکنش یا برنامهای ایجاد کرد. اما آنچه در مورد اتریوم جالبتر است این است که پروتکل اتریوم بسیار فراتر از ارز است. پروتکلهای حول ذخیرهسازی غیرمتمرکز فایل، محاسبات غیرمتمرکز و بازارهای پیشبینی غیرمتمرکز، در میان دهها مفهوم دیگر، پتانسیل افزایش قابلتوجهی کارایی صنعت محاسبات را دارند، و با افزودن برای اولین بار یک لایه اقتصادی، تقویت گسترده ای برای سایر پروتکل های همتا به همتا فراهم می کند. در نهایت، مجموعهای از برنامههای کاربردی نیز وجود دارد که اصلاً ربطی به پول ندارند.
+
+مفهوم یک تابع انتقال حالت دلخواه که توسط پروتکل اتریوم پیاده سازی شده است، یک پلتفرم با پتانسیل منحصر به فرد را فراهم می کند. به جای اینکه اتریوم یک پروتکل بسته و تک منظوره باشد که برای مجموعه ای از برنامه های کاربردی در ذخیره سازی داده ها، قمار یا امور مالی در نظر گرفته شده است، اتریوم از نظر طراحی دارای پایان باز است. و ما معتقدیم که برای خدمت به عنوان یک لایه اساسی برای تعداد بسیار زیادی از پروتکل های مالی و غیر مالی در سال های آینده بسیار مناسب است.
+
+
+
+## یادداشت ها و مطالعه بیشتر {#notes-and-further-reading}
+
+
+
+### یادداشت ها {#notes}
+
+1. یک خواننده آگاه ممکن است متوجه شود که در واقع یک آدرس بیتکوین هش کلید عمومی منحنی بیضوی است و نه خود کلید عمومی. با این حال، در واقع اصطلاحات رمزنگاری کاملاً قانونی است که به هش پابکی (pubkey) به عنوان خود کلید عمومی اشاره شود. این به این دلیل است که رمزنگاری بیتکوین را می توان یک الگوریتم امضای دیجیتال سفارشی در نظر گرفت، که در آن کلید عمومی از هش کلید pubkey ECC تشکیل شده است، امضا شامل کلید pubkey ECC است که با امضای ECC پیوند خورده است. و الگوریتم تأیید شامل بررسی ECC pubkey در امضا در برابر هش ECC pubkey ارائه شده به عنوان کلید عمومی و سپس تأیید امضای ECC در برابر کلید pubkey ECC است.
+2. از نظر فنی، میانه 11 بلوک قبلی.
+3. از نظر داخلی، 2 و "CHARLIE" هر دو اعداد هستند[fn3](#notes)، که دومی در نمایش پایه 256 بیگ ایندین قرار دارد. اعداد می توانند حداقل 0 و حداکثر 2256-1 باشند.
+
+
+
+### اطلاعات بیشتر {#further-reading}
+
+1. [ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)
+2. [دارایی هوشمند](https://en.bitcoin.it/wiki/Smart_Property)
+3. [قراردادهای هوشمند](https://en.bitcoin.it/wiki/Contracts)
+4. [B-money](http://www.weidai.com/bmoney.txt)
+5. [شواهد کار قابل استفاده مجدد](https://nakamotoinstitute.org/finney/rpow/)
+6. [عناوین ملکی را با اختیار مالک تضمین کنید](https://nakamotoinstitute.org/secure-property-titles/)
+7. [برگه سفید بیت کوین](http://bitcoin.org/bitcoin.pdf)
+8. [Namecoin](https://namecoin.org/)
+9. [مثلت زوکو](https://wikipedia.org/wiki/Zooko's_triangle)
+10. [وایت پیپر سکههای رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)
+11. [وایت پیپر مسترکوین](https://github.com/mastercoin-MSC/spec)
+12. [شرکت های مستقل غیرمتمرکز، مجله بیت کوین](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)
+13. [تأیید پرداخت ساده](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)
+14. [درختان مرکل](https://wikipedia.org/wiki/Merkle_tree)
+15. [درختان پاتریشیا](https://wikipedia.org/wiki/Patricia_tree)
+16. [GHOST](https://eprint.iacr.org/2013/881.pdf)
+17. [StorJ و ایجنت های خودمختار، جف گارزیک](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html)
+18. [مایک هرن در مورد املاک هوشمند در جشنواره تورینگ](https://www.youtube.com/watch?v=MVyv4t0OKe4)
+19. [Ethereum RLP](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP)
+20. [درخت مرکل پاتریشیا اتریوم](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree)
+21. [پیتر تاد درباره درختان مرکل](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/)
+
+_برای تاریخچه وایت پیپر، [این ویکی](https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md) را ببینید._
+
+_اتریوم، مانند بسیاری از پروژههای نرمافزاری متنباز و مبتنی بر کامیونیتی، از زمان شروع اولیه خود تکامل یافته است. برای اطلاع از آخرین پیشرفتهای اتریوم و اینکه تغییرات در پروتکل چگونه اعمال میشوند، [این راهنما](/learn/) را توصیه میکنیم._
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md
new file mode 100644
index 00000000000..2b8a0853c56
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md
@@ -0,0 +1,135 @@
+---
+title: پلها
+description: مروری بر پل زدن برای توسعهدهندگان
+lang: fa
+---
+
+با گسترش بلاکچین های L1 و راه حل های [مقیاس پذیری](/developers/docs/scaling/) L2، در کنار تعداد روزافزون برنامه های غیرمتمرکز که به صورت زنجیره ای متقابل انجام می شوند، نیاز به ارتباطات و جابجایی دارایی ها در میان زنجیره ها به بخشی ضروری از زیرساخت شبکه تبدیل شده است. انواع مختلفی از پل ها برای کمک به این وضعیت وجود دارد.
+
+## نیاز به پل ها {#need-for-bridges}
+
+پل هایی برای اتصال شبکه های بلاکچین وجود دارند. آنها اتصال و قابلیت همکاری بین بلاکچین ها را امکانپذیر می کنند.
+
+بلاکچین ها در محیط های سیلو وجود دارند، به این معنی که هیچ راهی برای تجارت و ارتباط طبیعی با بلاکچین های دیگر وجود ندارد. در نتیجه، در حالی که می تواند فعالیت و نوآوری قابل توجهی در یک اکوسیستم وجود داشته باشد، به دلیل عدم اتصال و قابلیت همکاری با سایر اکوسیستم ها محدود شده است.
+
+پل ها راهی برای ارتباط محیط های بلاکچین ایزوله با یکدیگر ارائه می دهند. آنها یک مسیر حمل و نقل بین بلاکچین ایجاد می کنند که در آن توکن ها، پیام ها، داده های دلخواه و حتی تماس های [قرارداد هوشمند](/developers/docs/smart-contracts/) می توانند از یک زنجیره به زنجیره دیگر منتقل شوند.
+
+## مزایای پل ها {#benefits-of-bridges}
+
+به زبان ساده، پل ها با اجازه دادن به شبکه های بلاکچین برای تبادل داده ها و جابجایی دارایی ها بین آنها، موارد استفاده متعدد را باز می کنند.
+
+بلاکچین ها دارای نقاط قوت، ضعف و رویکردهای منحصر به فردی برای ساخت برنامه های کاربردی هستند (مانند سرعت، توان عملیاتی، هزینه و غیره). پلها به توسعه اکوسیستم رمزنگاری کلی کمک میکنند و بلاکچینها را قادر میسازند تا از نوآوریهای یکدیگر استفاده کنند.
+
+برای توسعه دهندگان، پل ها موارد زیر را فعال می کنند:
+
+- انتقال هر گونه داده، اطلاعات و دارایی در زنجیره ها.
+- باز کردن قفل ویژگی های جدید و موارد استفاده برای پروتکل ها به عنوان پل، فضای طراحی را برای آنچه پروتکل ها می توانند ارائه دهند گسترش می دهند. به عنوان مثال، یک پروتکل برای فارمینگ بهره که در اصل در شبکه اصلی اتریوم مستقر شده است، میتواند استخرهای نقدینگی را در تمام زنجیرههای سازگار با EVM ارائه دهد.
+- فرصتی برای استفاده از نقاط قوت بلاکچین های مختلف. به عنوان مثال، توسعهدهندگان میتوانند از هزینههای کمتری که راهحلهای L2 مختلف ارائه میکنند، با استقرار دپ های خود در سرتاسر مجموعهها، بهرهمند شوند، و زنجیرههای جانبی و کاربران میتوانند روی آنها پل بزنند.
+- همکاری بین توسعه دهندگان از اکوسیستم های مختلف بلاکچین برای ساخت محصولات جدید.
+- جذب کاربران و جوامع از اکوسیستم های مختلف به برنامه های خود.
+
+## پل ها چگونه کار می کنند؟ {#how-do-bridges-work}
+
+در حالی که [انواع زیادی از طرح های پل](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) وجود دارد، سه راه برای تسهیل انتقال زنجیره ای متقابل دارایی ها برجسته است:
+
+- **قفل و ضرب کردن-** داراییها را در زنجیره مبدا قفل کنید و داراییها را در زنجیره مقصد ضرب کنید.
+- **سوزاندن و ضرب کردن –** سوزاندن دارایی ها در زنجیره مبدا و ضرب دارایی ها در زنجیره مقصد.
+- **سوآپهای اتمی –** داراییهای موجود در زنجیره مبدا را با داراییهای زنجیره مقصد با طرف دیگر مبادله کنید.
+
+## اواع پل ها {#bridge-types}
+
+پل ها را معمولاً می توان به یکی از سبد های زیر طبقه بندی کرد:
+
+- **پلهای بومی –** این پلها معمولاً برای راهاندازی نقدینگی در یک بلاکچین خاص ساخته میشوند و انتقال وجوه به اکوسیستم را برای کاربران آسانتر میکنند. به عنوان مثال، [پل آربیتروم](https://bridge.arbitrum.io/) به گونهای ساخته شده است که اتصال از شبکه اصلی اتریوم به آربیتروم را برای کاربران راحت کند. از دیگر پل های این چنینی می توان به پل Polygon PoS Bridge، [Optimism Gateway](https://app.optimism.io/bridge) و غیره اشاره کرد.
+- **پلهای مبتنی بر اعتبارسنج یا اوراکل -** این پلها برای اعتبارسنجی انتقالهای بین زنجیرهای به مجموعه یا اوراکلهای اعتبارسنج خارجی متکی هستند. مثال: Multichain و Across.
+- **پلهای ارسال پیام عمومی -** این پلها میتوانند داراییها را همراه با پیامها و دادههای دلخواه در زنجیرهها انتقال دهند. نمونه: Axelar و LayerZero و Nomad.
+- **شبکه های نقدینگی -** این پل ها در درجه اول بر انتقال دارایی ها از یک زنجیره به زنجیره دیگر از طریق سوآپ اتمی تمرکز دارند. به طور کلی، آنها از ارسال پیام بین زنجیره ای پشتیبانی نمی کنند. نمونه: Connext و Hop.
+
+## مبادلات قابل تامل {#trade-offs}
+
+با پل ها، هیچ راه حل کاملی وجود ندارد. در عوض، فقط مبادلاتی برای تحقق یک هدف وجود دارد. توسعه دهندگان و کاربران می توانند پل ها را بر اساس عوامل زیر ارزیابی کنند:
+
+- **امنیت -** چه کسی سیستم را تأیید می کند؟ پل هایی که توسط اعتبارسنجهای خارجی ایمن می شوند، معمولاً نسبت به پل هایی که به صورت محلی یا بومی توسط اعتبارسنج های بلاکچین ایمن شده اند، امنیت کمتری دارند.
+- **راحتی -** چه مدت طول می کشد تا یک تراکنش کامل شود و یک کاربر به چند تراکنش نیاز داشت تا امضا کند؟ برای یک توسعه دهنده، چقدر طول می کشد تا یک پل یکپارچه شود، و این فرآیند چقدر پیچیده است؟
+- **اتصال -** زنجیرههای مختلف مقصد که یک پل میتواند به یکدیگر متصل کند (به عنوان مثال، زنجیرههای جانبی، سایر بلاکچینهای لایه 1 و غیره) چیست و ادغام یک بلاکچین جدید چقدر سخت است؟
+- **قابلیت انتقال دادههای پیچیدهتر –** آیا پل میتواند انتقال پیامها و دادههای دلخواه پیچیدهتر را در زنجیرهها فعال کند یا فقط از انتقال داراییهای بین زنجیرهای پشتیبانی میکند؟
+- **مقرون به صرفه بودن -** هزینه انتقال دارایی ها در بین زنجیره ها از طریق یک پل چقدر است؟ به طور معمول، پل ها بسته به هزینه های گس و نقدینگی مسیرهای خاص، هزینه ثابت یا متغیری را دریافت می کنند. همچنین ارزیابی مقرون به صرفه بودن یک پل بر اساس سرمایه مورد نیاز برای اطمینان از امنیت آن بسیار مهم است.
+
+در سطح بالا، پل ها را می توان به عنوان قابل اعتماد و غیر قابل اعتماد طبقه بندی کرد.
+
+- **قابل اعتماد–** پل های قابل اعتماد به صورت خارجی تأیید می شوند. آنها از مجموعهای خارجی از تأییدکنندهها (فدراسیونهایی با سیستمهای محاسباتی چندگانه، چند حزبی، شبکه اوراکل) برای ارسال دادهها در زنجیرهها استفاده میکنند. در نتیجه، آنها می توانند اتصال عالی را ارائه دهند و امکان ارسال پیام کاملاً تعمیم یافته را از طریق زنجیره ها فراهم کنند. آنها همچنین تمایل دارند با سرعت و مقرون به صرفه عملکرد خوبی داشته باشند. این به قیمت امنیت تمام می شود، زیرا کاربران باید به امنیت پل اتکا کنند.
+- **غیر قابل اعتماد –** این پلها برای انتقال پیامها و توکن ها، به بلاکچین هایی که وصل میکنند و اعتبارسنجهای آنها متکی هستند. آنها «عیر قابل اعتماد» هستند زیرا فرضیات اعتماد جدیدی را اضافه نمی کنند (علاوه بر بلاکچین). در نتیجه، پلهای غیرقابل اعتماد نسبت به پلهای قابل اعتماد از امنیت بیشتری برخوردار هستند.
+
+برای ارزیابی پلهای غیرقابل اعتماد بر اساس عوامل دیگر، باید آنها را به پلهای انتقال پیام عمومی و شبکههای نقدینگی تقسیم کنیم.
+
+- **پل های ارسال پیام عمومی –** این پل ها از نظر امنیت و توانایی انتقال داده های پیچیده تر در زنجیره ها عالی هستند. به طور معمول، آنها همچنین از نظر مقرون به صرفه بودن خوب هستند. با این حال، این نقاط قوت عموماً با کاهش اتصال برای پلهای کلاینت سبک (مثلاً IBC) و معایب سرعت برای پلهای خوشبینانه (مثلاً: Nomad) است که از اثبات تقلب استفاده میکنند.
+- **شبکههای نقدینگی -** این پلها از مبادله اتمی برای انتقال داراییها استفاده میکنند و سیستمهای تأیید شده محلی هستند (یعنی از اعتبارسنج های بلاکچین برای تأیید تراکنشها استفاده میکنند). در نتیجه، از نظر امنیت و سرعت برتری دارند. علاوه بر این، نسبتاً مقرون به صرفه در نظر گرفته می شوند و اتصال خوبی را ارائه می دهند. با این حال، ایراد اصلی ناتوانی آنها در انتقال داده های پیچیده تر است - زیرا از ارسال پیام زنجیره ای پشتیبانی نمی کنند.
+
+## خطر استفاده از پلها {#risk-with-bridges}
+
+پل ها سه مورد از [بزرگترین هک ها در دیفای](https://rekt.news/leaderboard/) را تشکیل می دهند و هنوز در مراحل اولیه توسعه است. استفاده از هر پل خطرات زیر را به همراه دارد:
+
+- **خطر قرارداد هوشمند -** در حالی که بسیاری از پلها با موفقیت ممیزی را پشت سر گذاشتهاند، تنها یک نقص در قرارداد هوشمند لازم است تا داراییها در معرض هک قرار گیرند (مثلاً: [پل Wormhole سولانا](https://rekt.news/wormhole-rekt/)).
+- **ریسکهای مالی سیستمی** - بسیاری از پلها از داراییهای رپ شده برای ضرب کردن نسخههای متعارف دارایی اصلی در یک زنجیره جدید استفاده میکنند. این امر اکوسیستم را در معرض خطر سیستماتیک قرار می دهد، زیرا شاهد بهره برداری از نسخه های رپ شده توکن ها بودیم.
+- **خطر طرف مقابل -** برخی از پلها از طراحی قابل اعتمادی استفاده میکنند که کاربران را ملزم میکند بر این فرض تکیه کنند که اعتبارسنج ها برای سرقت وجوه کاربران تبانی نمیکنند. نیاز کاربران به اعتماد به این بازیگران طرف ثالث، آنها را در معرض خطراتی مانند راگ پول، سانسور و سایر فعالیتهای مخرب قرار میدهد.
+- **مسئلههای باز -** با توجه به اینکه پل ها در مراحل اولیه توسعه هستند، سوالات بی پاسخ بسیاری در رابطه با نحوه عملکرد پل ها در شرایط مختلف بازار وجود دارد. مانند زمان ازدحام شبکه و در طول رویدادهای پیش بینی نشده مانند حملات در سطح شبکه یا رولبکهای حالت. این عدم قطعیت خطرات خاصی را به همراه دارد که درجه آن هنوز مشخص نیست.
+
+## چگونه dapp ها می توانند از پل ها استفاده کنند؟ {#how-can-dapps-use-bridges}
+
+در اینجا چند برنامه کاربردی وجود دارد که توسعه دهندگان می توانند در مورد پل ها و استفاده از زنجیره متقابل dapp خود در نظر بگیرند:
+
+### یکپارچه سازی پل ها {#integrating-bridges}
+
+برای توسعه دهندگان، راه های زیادی برای اضافه کردن پشتیبانی برای پل ها وجود دارد:
+
+1. **ساختن پل خودتان -** ساختن پل ایمن و قابل اعتماد آسان نیست، به خصوص اگر مسیری را انتخاب کنید که اعتماد به حداقل برسد. علاوه بر این، به سالها تجربه و تخصص فنی مرتبط با مطالعات مقیاس پذیری و قابلیت همکاری نیاز دارد. علاوه بر این، به یک تیم عملی برای حفظ یک پل و جذب نقدینگی کافی برای امکانپذیر کردن آن نیاز دارد.
+
+2. **نمایش چندین گزینه پل به کاربران -** بسیاری از [دپ ها](/developers/docs/dapps/) از کاربران میخواهند توکن بومی خود را داشته باشند تا با آنها تعامل داشته باشند. برای اینکه کاربران بتوانند به توکن های خود دسترسی داشته باشند، گزینه های پل متفاوتی را در وب سایت خود ارائه می دهند. با این حال، این روش یک راه حل سریع برای این مشکل است، زیرا کاربر را از رابط dapp دور می کند و همچنان نیاز به تعامل با دیگر dapp ها و پل ها دارد. این یک تجربه حضوری دست و پا گیر با دامنه افزایش اشتباهات است.
+
+3. **یکپارچه سازی یک پل –** این راه حل نیازی به ارسال کاربران به پل خارجی و رابط های DEX ندارد. این به dapp ها اجازه می دهد تا تجربه ورود کاربر را بهبود بخشند. با این حال، این رویکرد دارای محدودیت هایی است:
+
+ - ارزیابی و نگهداری پل ها سخت و زمان بر است.
+ - انتخاب یک پل یک نقطه شکست و وابستگی ایجاد می کند.
+ - دپ، با قابلیت های پل محدود می شود.
+ - پل ها به تنهایی ممکن است کافی نباشند. Dapp ها ممکن است برای ارائه عملکردهای بیشتری مانند تبادل زنجیره ای به DEX نیاز داشته باشند.
+
+4. **یکپارچه سازی چندین پل –** این راه حل بسیاری از مشکلات مربوط به یکپارچه سازی یک پل را حل می کند. با این حال، محدودیتهایی نیز دارد، زیرا یکپارچهسازی پلهای متعدد منابع را مصرف میکند و هزینههای فنی و ارتباطی را برای توسعهدهندگان ایجاد میکند – کمیابترین منبع در دنیای رمزارز.
+
+5. **یکپارچه سازی یک پل جمع کننده –** گزینه دیگر برای dapp ها یکپارچه سازی راه حل تجمیع پل است که به آنها امکان دسترسی به پل های متعدد را می دهد. جمعکنندههای پل، نقاط قوت همه پلها را به ارث میبرند و بنابراین با قابلیتهای هیچ پل محدود نمیشوند. نکته قابل توجه، جمعکنندههای پل معمولاً ادغامهای پل را حفظ میکنند، که باعث میشود دپ از دردسر ماندن در بالای جنبههای فنی و عملیاتی یکپارچهسازی پل نجات یابد.
+
+همانطور که گفته شد، جمع کننده های پل نیز محدودیت های خود را دارند. به عنوان مثال، در حالی که آنها می توانند گزینه های پل بیشتری را ارائه دهند، پل های بسیار بیشتری به غیر از پلتفرم های ارائه شده در پلت فرم جمع کننده معمولاً در بازار موجود است. علاوه بر این، درست مانند پلها، جمعکنندههای پل نیز در معرض خطرات قرارداد هوشمند و فناوری هستند (قراردادهای هوشمند بیشتر = خطرات بیشتر).
+
+اگر یک dapp مسیر ادغام یک پل یا یک تجمیع کننده را طی کند، گزینه های مختلفی بر اساس عمق ادغام وجود دارد. به عنوان مثال، اگر این فقط یک ادغام جلویی برای بهبود تجربه ورود کاربر باشد، یک dapp ویجت را ادغام می کند. با این حال، اگر ادغام برای کاوش استراتژیهای بین زنجیرهای متقابل عمیقتر مانند سهامگذاری، ییلد فارمینگ و غیره باشد، دپ اقدام به ادغام SDK یا API میکند.
+
+### استقرار یک dapp در چندین زنجیره {#deploying-a-dapp-on-multiple-chains}
+
+برای استقرار یک dapp در چندین زنجیره، توسعهدهندگان میتوانند از پلتفرمهای توسعه مانند [Alchemy](https://www.alchemy.com/)، [Hardhat](https://hardhat.org/)، [Truffle](https://trufflesuite.com/)، [Moralis](https://moralis.io/) ، و غیره استفاده کنند. به طور معمول، این پلتفرمها با پلاگینهای قابل ترکیبی عرضه میشوند که میتوانند dappها را قادر به انجام فعالیت بین زنجیرهای کنند. به عنوان مثال، توسعه دهندگان می توانند از یک پراکسی استقرار قطعی ارائه شده توسط [افزونه hardhat-deploy](https://github.com/wighawag/hardhat-deploy) استفاده کنند.
+
+#### مثال ها:
+
+- [نحوه ساخت دپ های بین زنجیره ای](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [ساختن یک مارکتپلیس NFT بین زنجیره ای](https://youtu.be/WZWCzsB1xUE)
+- [Moralis: ساختن دپ های NFT بین زنجیره ای](https://www.youtube.com/watch?v=ehv70kE1QYo)
+
+### نظارت بر فعالیت قرارداد در سراسر زنجیره {#monitoring-contract-activity-across-chains}
+
+برای نظارت بر فعالیت قرارداد بین زنجیرهای، توسعهدهندگان میتوانند از زیرگرافها و پلتفرمهای توسعهدهنده مانند Tenderly برای مشاهده قراردادهای هوشمند در زمان واقعی استفاده کنند. چنین پلتفرمهایی همچنین دارای ابزارهایی هستند که عملکرد نظارت بیشتری بر دادهها را برای فعالیتهای زنجیرهای متقابل ارائه میکنند، مانند بررسی [رویدادهای منتشر شده توسط قراردادها](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) و غیره.
+
+#### ابزارها
+
+- [The Graph](https://thegraph.com/en/)
+- [Tenderly](https://tenderly.co/)
+
+## بیشتر بخوانید {#further-reading}
+
+- [پلهای بلاکچین](/bridges/) – ethereum.org
+- [پلهای بلاکچین: ساختن شبکههای رمزنگاری](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 8 سپتامبر 2021 – Dmitriy Berenzon
+- [قابلیت عملیات متقابل Trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 1 اکتبر 2021 – Arjun Bhuptani
+- [خوشهها: پلهای قابل اعتماد و & دارای اعتماد حداقل چگونه دورنمای مالتیچین را شکل میدهند](https://blog.celestia.org/clusters/)4 اکتبر 2021 – Mustafa Al-Bassam
+- [LI.FI: با پلها، اعتماد یک طیف است](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 28 آوریل 2022 – Arjun Chand
+
+همچنین، اینجا بعضی تعاریف پرمعنی از [James Prestwich](https://twitter.com/_prestwich) وجود دارد که میتوانند به درک عمیقتر از پلها کمک کنند:
+
+- [ساختن پلها، نه باغهای دیواردار](https://youtu.be/ZQJWMiX4hT0)
+- [فرو ریختن پلها](https://youtu.be/b0mC-ZqN8Oo)
+- [چرا پلها میسوزند](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
new file mode 100644
index 00000000000..31d737eb12a
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
@@ -0,0 +1,118 @@
+---
+title: راهکار های ذخیرهسازی داده در بلاکچین
+description: چندین راه مختلف برای ذخیرهسازی داده با استفاده از بلاکچین وجود دارد. این مقاله به مقایسه استراتژیهای مختلف، مزایا و معایب هرکدام و پیشنیازهای استفاده امن آنها میپردازد.
+lang: fa
+---
+
+راههای مختلفی وجود دارد تا دادهها را چه بهصورت مستقیم در بلاکچین و چه با روشی که امنیت آن از طریق بلاکچین تأمین شود، ذخیرهسازی کرد:
+
+- بلابهای EIP-4844
+- دادهی فراخوانی (calldata)
+- خارج از زنجیره ولی بهره گرفته از مکانیزم بلاکچین لایه 1
+- "کد" قرارداد
+- رویدادها
+- حافظه ابدی ماشین مجازی اتریوم (EVM storage)
+
+انتخاب روش مورد استفاده بر اساس چندین معیار است:
+
+- منبع اطلاعات. اطلاعات موجود در دادهی فراخوانی (calldata) مستقیماً از خود بلاکچین نشأت نمیگیرند.
+- مقصد اطلاعات. Calldata فقط در تراکنشی که شروع می کند در دسترس است. رویدادها به هیچ وجه به صورت زنجیره ای قابل دسترسی نیستند.
+- چقدر دردسر قابل قبول است؟ رایانههایی که یک گره در مقیاس کامل اجرا میکنند میتوانند پردازش بیشتری نسبت به یک کلاینت سبک در برنامهای که در مرورگر اجرا میشود انجام دهند.
+- آیا تسهیل دسترسی آسان به اطلاعات از هر گره ضروری است؟
+- الزامات امنیتی.
+
+## الزامات امنیتی {#security-requirements}
+
+به طور کلی امنیت اطلاعات شامل سه ویژگی است:
+
+- _محرمانگی، اشخاص غیر مجاز، مجاز به خواندن اطلاعات نیستند. این در بسیاری از موارد مهم است، اما در اینجا نه. _ هیچ رازی در بلاکچین وجود ندارد _. بلاک چینها کار می کنند زیرا هر کسی می تواند انتقال حالت را تأیید کند، بنابراین استفاده از آنها برای ذخیره مستقیم اسرار غیرممکن است. راههایی برای ذخیره اطلاعات محرمانه در بلاکچین وجود دارد، اما همه آنها برای ذخیره حداقل یک کلید به برخی اجزای خارج از زنجیره متکی هستند.
+
+- _یکپارچگی_، اطلاعات صحیح است، نمی توان آن را توسط نهادهای غیرمجاز یا به روش های غیرمجاز تغییر داد (به عنوان مثال، انتقال [توکن های ERC-20] (https://eips.ethereum.org/EIPS/eip-20#events) بدون یک رویداد "انتقال"). در بلاکچین، هر گره هر تغییر حالت را تأیید می کند که یکپارچگی را تضمین می کند.
+
+- _در دسترس بودن_، اطلاعات در دسترس هر نهاد مجاز است. در بلاکچین، این امر معمولاً با داشتن اطلاعات در دسترس در هر [گره کامل] (https://ethereum.org/developers/docs/nodes-and-clients#full-node) به دست می آید.
+
+راه حل های مختلف در اینجا همه یکپارچگی عالی دارند، زیرا هش ها در L1 ارسال می شوند. با این حال، آنها دارای ضمانت های مختلف در دسترس بودن هستند.
+
+## پیش نیازها {#prerequisites}
+
+شما باید درک خوبی از [اصول بلاکچین] (/developers/docs/intro-to-ethereum/) داشته باشید. این صفحه همچنین فرض میکند که خواننده با [blocks](/developers/docs/blocks/)، [تراکنش ها](/developers/docs/transactions/) و سایر موضوعات مرتبط آشنا است.
+
+## حباب های EIP-4844 {#eip-4844-blobs}
+
+در شروع با [هاردفورک دنکان] (https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md)، بلاک چین اتریوم شامل [EIP-4844] است (https:// eips.ethereum.org/EIPS/eip-4844)، که به حباب های داده اتریوم با طول عمر محدود (در ابتدا حدود [18 روز]) اضافه می کند (https://github.com/ethereum/consensus-specs/blob/dev/specs) /deneb/p2p-interface.md#configuration)). این حباب ها جدا از [گس اجرا](/developers/docs/gas) قیمت گذاری می شوند، اگرچه از مکانیزم مشابهی استفاده می کنند. آنها یک راه ارزان برای ارسال داده های موقت هستند.
+
+مورد استفاده اصلی برای حباب های EIP-4844 این است که رولآپ ها تراکنش های خود را منتشر کنند. [رولآپهای خوشبینانه](/developers/docs/scaling/optimistic-rollups) باید تراکنشها را روی بلاکچینهای خود منتشر کنند. این تراکنشها باید در طول [دوره چالش](https://docs.optimism.io/connect/resources/glossary#challenge-period) در دسترس همه باشند تا اگر [ترتیبدهنده](https://docs.optimism.io/connect/resources/glossary#sequencer) رولآپ یک ریشه وضعیت نادرست را ارسال کند، [اعتبارسنجها](https://docs.optimism.io/connect/resources/glossary#validator) را قادر میسازد تا اشتباه را برطرف کنند.
+
+با این حال، هنگامی که دوره چالش سپری شد و ریشه حالت نهایی شد، هدف باقی مانده برای دانستن این تراکنش ها تکرار وضعیت فعلی زنجیره است. این حالت از گره های زنجیره ای نیز در دسترس است و به پردازش بسیار کمتری نیاز است. بنابراین، اطلاعات تراکنش همچنان باید در چند مکان، مانند [کاوشگران بلوک] (/developers/docs/data-and-analytics/block-explorers) حفظ شود، اما نیازی به پرداخت هزینه برای سطح مقاومت سانسوری که اتریوم ارائه می کند نیست.
+
+[رولآپهای دانش-صفر](/developers/docs/scaling/zk-rollups/#data-availability) همچنین دادههای تراکنش خود را ارسال میکنند تا دیگر گرهها بتوانند وضعیت موجود را تکرار کنند و اثبات اعتبار را تأیید کنند، اما باز هم این یک نیاز کوتاه مدت است.
+
+هنگام نوشتن پست در EIP-4844 یک وی (10-18 ETH) در هر بایت هزینه دارد، که در مقایسه با [21000 گس اجرا که هر تراکنش، از جمله تراکنشی که حبابها را پست میکند، هزینه دارد، ناچیز است](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). میتوانید قیمت فعلی EIP-4844 را در [blobscan.com] (https://blobscan.com/blocks) ببینید.
+
+در اینجا آدرس هایی برای مشاهده حباب های ارسال شده توسط برخی از مجموعه های معروف وجود دارد.
+
+| رولآپ | آدرس Mailbox |
+| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) |
+| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
+| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) |
+
+## کالدیتا {#calldata}
+
+Calldata به بایت های ارسال شده به عنوان بخشی از تراکنش اشاره دارد. به عنوان بخشی از رکورد دائمی بلاکچین در بلوک که شامل آن تراکنش است، ذخیره می شود.
+
+این ارزانترین روش برای قرار دادن دائمی داده ها در بلاکچین است. هزینه هر بایت یا 4 گس اجرا (اگر بایت صفر باشد) یا 16 گس (هر مقدار دیگر) است. اگر داده ها فشرده شوند، که یک روش استاندارد است، هر مقدار بایت به یک اندازه محتمل است، بنابراین میانگین هزینه تقریباً 15.95 گس در هر بایت است.
+
+در نوشتن قیمت ها 12 جیوی/گس و 2300 دلار/اتر است، که به این معنی است که هزینه تقریباً 45 سنت در هر کیلوبایت است. از آنجایی که این ارزانترین روش قبل از EIP-4844 بود، این روشی است که برای ذخیره اطلاعات تراکنش استفاده میشود، که باید برای [چالشهای خطا] در دسترس باشد (https://docs.optimism.io/stack/protocol/overview# اثبات عیب)، اما نیازی به دسترسی مستقیم روی زنجیره نیست.
+
+در اینجا آدرس هایی برای مشاهده تراکنش های ارسال شده توسط چند مجموعه معروف وجود دارد.
+
+| رولآپ | آدرس Mailbox |
+| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
+| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) |
+| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
+| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) |
+
+## خارج از زنجیره با مکانیسم های لایه 1 {#offchain-with-l1-mechs}
+
+بسته به دوراهی های امنیتی شما، ممکن است قابل قبول باشد که اطلاعات را در جای دیگری قرار دهید و از مکانیزمی استفاده کنید که تضمین کند داده ها در صورت نیاز در دسترس هستند. دو شرط برای این کار وجود دارد:
+
+1. یک [هش] (https://en.wikipedia.org/wiki/Cryptographic_hash_function) از دادهها را روی بلاکین پست کنید، که به آن _input commitment_ میگویند. این می تواند یک کلمه 32 بایتی باشد، بنابراین گران نیست. تا زمانی که تعهد ورودی در دسترس باشد، یکپارچگی تضمین میشود، زیرا یافتن دادههای دیگری که به همان مقدار هش شوند امکانپذیر نیست. بنابراین اگر داده های نادرست ارائه شود، می توان آن را شناسایی کرد.
+
+2. مکانیزمی داشته باشید که در دسترس بودن را تضمین کند. برای مثال، در [Redstone](https://redstone.xyz/docs/what-is-redstone) هر گرهی می تواند یک چالش در دسترس بودن ارسال کند. اگر ترتیبدهنده در مهلت مقرر به زنجیره پاسخ ندهد، تعهد ورودی کنار گذاشته میشود، بنابراین در نظر گرفته میشود که اطلاعات هرگز پست نشده است.
+
+این برای یک رولآپ خوشبینانه قابل قبول است زیرا ما در حال حاضر به داشتن حداقل یک تأیید کننده صادق برای ریشه حالت تکیه می کنیم. چنین تأیید کننده صادقی همچنین مطمئن می شود که داده هایی برای پردازش بلوک ها دارد و اگر اطلاعات در خارج از زنجیره در دسترس نباشد، چالش در دسترس بودن را صادر می کند. این نوع رولآپ خوشبینانه، [پلاسما](/developers/docs/scaling/plasma/) نامیده میشود.
+
+## کد قرارداد {#contract-code}
+
+اطلاعاتی که فقط باید یک بار نوشته شوند، هرگز بازنویسی نمی شوند و باید در زنجیره در دسترس باشند، می توانند به عنوان کد قرارداد ذخیره شوند. این بدان معنی است که ما یک "قرارداد هوشمند" با داده ها ایجاد می کنیم و سپس از [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) برای خواندن اطلاعات استفاده می کنیم. مزیت این است که کپی کردن کد نسبتاً ارزان است.
+
+به غیر از هزینه گسترش حافظه، «EXTCODECOPY» برای اولین دسترسی به قرارداد 2600 گس و برای نسخه های بعدی از همان قرارداد 100 گس به همراه 3 گس در هر کلمه 32 بایتی هزینه دارد. در مقایسه با calldata که 15.95 در هر بایت هزینه دارد، در آغاز حدود 200 بایت ارزانتر است. بر اساس [فرمول هزینه های گسترش حافظه] (https://www.evm.codes/about#memoryexpansion)، تا زمانی که به بیش از 4 مگابایت حافظه نیاز ندارید، هزینه گسترش حافظه کمتر از هزینه افزودن calldata است.
+
+البته این فقط هزینه _خواندن_ داده هاست. برای ایجاد قرارداد تقریباً 32000 گس + 200 گس برای هر بایت هزینه می شود. این روش تنها زمانی مقرون به صرفه است که اطلاعات یکسان در معاملات مختلف بارها خوانده شود.
+
+کد قرارداد تا زمانی که با '0xEF' شروع نشود می تواند بی معنی باشد. قراردادهایی که با «0xEF» شروع میشوند به عنوان [فرمت شی اتریوم] (https://notes.ethereum.org/@ipsilon/evm-object-format-overview) تفسیر میشوند که الزامات بسیار سختتری دارد.
+
+## رویدادها {#events}
+
+[رویدادها] (https://docs.alchemy.com/docs/solidity-events) توسط قراردادهای هوشمند منتشر میشوند و توسط نرمافزار خارج از زنجیره خوانده میشوند.
+مزیت آنها این است که کدهای آفلاین می توانند به رویدادها گوش دهند. هزینه [گس] (https://www.evm.codes/#a0?fork=cancun)، 375 به اضافه 8 گس در هر بایت داده است. در 12 گیگاوی/گس و 2300 دلار/اتر، این به یک سنت به اضافه 22 سنت در هر کیلوبایت ترجمه میشود.
+
+## ذخیرهسازی {#storage}
+
+قراردادهای هوشمند به [حافظه های دائمی] (https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) دسترسی دارند. با این حال، بسیار گران است. نوشتن یک کلمه 32 بایتی در یک اسلات از حافظه که قبلاً خالی بود، میتواند [22100 گس هزینه داشته باشد] (https://www.evm.codes/#55?fork=cancun). در 12 گیگاوی/گس و 2300 دلار/اتر،این حدود 61 سنت در هر عملیات نوشتن یا 19.5 دلار در هر کیلوبایت است.
+
+این گرانترین شکل ذخیرهسازی در اتریوم است.
+
+## خلاصه {#summary}
+
+این جدول تفاوت گزینه ها، مزایا و معایب آنها را خلاصه می کند.
+
+| نوع ذخیرهسازی | منبع دیتا | تضمین دسترسیپذیری | دسترسیپذیری آنچین | محدودیتهای دیگر |
+| -------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
+| بلابهای EIP-4844 | آفچین | ضمانت اتریوم برای [حدود 18 روز](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | فقط هش موجود است | |
+| دادهی فراخوانی (calldata) | آفچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | فقط در صورت نوشته شدن در قرارداد و در آن معامله در دسترس است | |
+| خارج از زنجیره ولی بهره گرفته از مکانیزم بلاکچین لایه 1 | آفچین | تضمین "یک تایید کننده صادق" در طول دوره چالش | فقط هش | تضمین شده توسط مکانیسم چالش، فقط در طول دوره چالش |
+| کد قرارداد | آنچین یا آفچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | بله | نوشته شده در یک آدرس "تصادفی"، نمی تواند با "0xEF" شروع شود |
+| رویدادها | آنچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | خیر | |
+| ذخیرهسازی | آنچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین و وضعیت فعلی تا زمانی که بازنویسی شود) | بله | |
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md
new file mode 100644
index 00000000000..ca4f63135b8
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md
@@ -0,0 +1,84 @@
+---
+title: دسترسی به دادهها
+description: مروری بر مشکلات و راه حل های مربوط به در دسترس بودن داده ها در اتریوم
+lang: fa
+---
+
+«اعتماد نکن، تایید کن» یک اصل رایج در اتریوم است. ایده این است که گره شما میتواند به طور مستقل صحت اطلاعاتی را که دریافت میکند با اجرای تمام تراکنشهای موجود در بلوکهایی که از همتایان دریافت میکنند تأیید کند تا اطمینان حاصل شود که تغییرات پیشنهادی دقیقاً با تغییرات محاسبهشده مستقل توسط گره مطابقت دارند. این بدان معناست که گرهها نباید به صادق بودن فرستندگان بلوک اعتماد کنند. در صورت عدم وجود داده، این امکان پذیر نیست.
+
+**در دسترس بودن داده** به اطمینان کاربر از اینکه داده های مورد نیاز برای تأیید یک بلوک واقعاً در دسترس همه شرکت کنندگان شبکه است، اشاره دارد. برای گرههای کامل در لایه 1 اتریوم، این کار نسبتاً ساده است. گره کامل یک کپی از تمام دادههای هر بلوک را دانلود میکند - دادهها _باید_ در دسترس باشند تا امکان دانلود وجود داشته باشد. بلوکی با داده های از دست رفته به جای اضافه شدن به بلاکچین، دور انداخته می شود. این "در دسترس بودن داده های زنجیره ای" است و یکی از ویژگی های بلاک چین های یکپارچه است. گره های کامل را نمی توان فریب داد تا تراکنش های نامعتبر را بپذیرند زیرا آنها هر تراکنش را برای خود دانلود و اجرا می کنند. با این حال، برای بلاک چینهای مدولار، رولآپ های لایه 2 و کلاینت های سبک، چشمانداز در دسترس بودن دادهها پیچیدهتر است و به برخی روشهای تأیید پیچیدهتر نیاز دارد.
+
+## پیشنیازها {#prerequisites}
+
+شما باید درک خوبی از [اصول بلاک چین](/developers/docs/intro-to-ethereum/)، به خصوص [مکانیسم های اجماع](/developers/docs/consensus-mechanisms/) داشته باشید. این صفحه همچنین فرض میکند که خواننده با [بلوکها](/developers/docs/blocks/)، [تراکنش ها](/developers/docs/transactions/)، [گرهها](/developers/docs/nodes-and-clients/)، [راهحلهای مقیاسبندی](/developers/docs/scaling/) و سایر موضوعات مرتبط آشنا است.
+
+## مشکل در دسترس بودن داده ها {#the-data-availability-problem}
+
+مشکل در دسترس بودن داده ها این است که باید به کل شبکه ثابت شود که شکل خلاصه شده برخی از داده های تراکنش که به بلاک چین اضافه می شود، واقعاً مجموعه ای از تراکنش های معتبر را نشان می دهد، اما بدون نیاز به همه گره ها برای دانلود همه داده ها. دادههای کامل تراکنش برای تأیید مستقل بلوکها ضروری است، اما نیاز به تمام گرهها برای دانلود همه دادههای تراکنش، مانعی برای مقیاسپذیری است. هدف راهحلهای مشکل در دسترس بودن داده، ارائه تضمینهای کافی مبنی بر این است که دادههای کامل تراکنش برای تأیید در دسترس شرکتکنندگانی از شبکه قرار گرفته است که دادهها را برای خود دانلود و ذخیره نمیکنند.
+
+[گرههای سبک](/developers/docs/nodes-and-clients/light-clients) و [رولآپ های لایه 2](/developers/docs/scaling) نمونههای مهمی از شرکتکنندگان در شبکه هستند که به تضمینهای قوی در دسترس بودن داده نیاز دارند اما نمیتوانند دادههای تراکنش را برای خود دانلود و پردازش کنند. اجتناب از دانلود دادههای تراکنش چیزی است که گرههای سبک را سبک میکند و به رولآپ ها امکان میدهد راهحلهای مقیاسپذیری مؤثری باشند.
+
+در دسترس بودن داده ها همچنین یک نگرانی مهم برای کلاینت های [«بی حالت»](/roadmap/statelessness) اتریوم در آینده است که برای تأیید بلوک ها نیازی به دانلود و ذخیره داده های حالت ندارند. کلاینت های بی حالت هنوز باید مطمئن باشند که دادهها _جایی_ در دسترس هستند و به درستی پردازش شدهاند.
+
+## راه حل های در دسترس بودن داده ها {#data-availability-solutions}
+
+### نمونهگیری در دسترس بودن داده (DAS) {#data-availability-sampling}
+
+نمونهگیری در دسترس بودن داده (DAS) روشی برای شبکه برای بررسی در دسترس بودن دادهها بدون اعمال فشار زیاد بر هر گره منفرد است. هر گره (از جمله گرههای بدون شرطبندی) تعدادی زیرمجموعه کوچک و تصادفی انتخاب شده از کل دادهها را دانلود میکند. دانلود موفقیت آمیز نمونه ها با اطمینان بالا تأیید می کند که همه داده ها در دسترس هستند. این به کدگذاری پاک کردن دادهها متکی است، که یک مجموعه داده معین را با اطلاعات اضافی گسترش میدهد (روش انجام این کار به این صورت است که تابعی به نام _چند جملهای_ را بر روی دادهها قرار میدهد و آن چند جملهای را در نقاط اضافی ارزیابی میکند). این اجازه می دهد تا داده های اصلی در صورت لزوم از داده های اضافی بازیابی شوند. نتیجه این ایجاد داده این است که اگر _هیچ_ کدام از دادههای اصلی در دسترس نباشد، _نیمی_ از دادههای توسعهیافته از دست خواهند رفت! مقدار نمونه های داده دانلود شده توسط هر گره را می توان تنظیم کرد به طوری که _به شدت_ احتمال دارد که حداقل یکی از قطعات داده نمونه برداری شده توسط هر مشتری وجود نداشته باشد _اگر_ کمتر از نیمی از داده ها واقعاً در دسترس باشد.
+
+DAS برای اطمینان از اینکه اپراتورهای رولآپ دادههای تراکنش خود را پس از اجرای [دنکشاردینگ کامل](/roadmap/danksharding/#what-is-danksharding) در دسترس قرار میدهند، استفاده میشود. گره های اتریوم به صورت تصادفی از داده های تراکنش ارائه شده در حباب ها با استفاده از طرح افزونگی که در بالا توضیح داده شد نمونه برداری می کنند تا اطمینان حاصل شود که همه داده ها وجود دارند. همین تکنیک همچنین میتواند برای اطمینان از اینکه تولیدکنندگان بلوک تمام دادههای خود را برای ایمن کردن کلاینت های سبک در دسترس قرار میدهند، استفاده شود. به طور مشابه، تحت [جداسازی پیشنهاددهنده-سازنده](/roadmap/pbs) بلوک، فقط سازنده بلوک باید کل یک بلوک را پردازش کند - اعتبارسنج های دیگر با استفاده از نمونه گیری در دسترس بودن داده ها را تأیید می کنند.
+
+### کمیته های در دسترس بودن داده ها {#data-availability-committees}
+
+کمیته های در دسترس بودن داده ها (DACها) طرف های مورد اعتمادی هستند که در دسترس بودن داده ها را ارائه می دهند یا آن را تأیید می کنند. DAC ها را می توان به جای [یا در ترکیب با](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS استفاده کرد. ضمانتهای امنیتی که با کمیتهها ارائه میشوند به تشکیلات خاص بستگی دارد. برای مثال، اتریوم از زیرمجموعههای نمونهبرداری تصادفی اعتبارسنج ها برای تأیید در دسترس بودن دادهها برای گرههای سبک استفاده میکند.
+
+DAC ها نیز توسط برخی از ولیدیومها استفاده می شوند. DAC مجموعه ای از گره های قابل اعتماد است که نسخه هایی از داده ها را به صورت آفلاین ذخیره می کند. DAC موظف است در صورت بروز اختلاف، داده ها را در دسترس قرار دهد. اعضای DAC همچنین امضاهای آنچین را منتشر میکنند تا ثابت کنند که دادههای مذکور واقعاً در دسترس هستند. برخی ولیدیومها را با یک سیستم اعتبارسنج اثبات سهام (PoS) جایگزین می کنند. در اینجا، هر کسی میتواند اعتبارسنج شود و دادهها را خارج از زنجیره ذخیره کند. با این حال، آنها باید یک "مسیر" ارائه کنند که در یک قرارداد هوشمند سپرده می شود. در صورت رفتار مخرب، مانند مخفی نگه داشتن اطلاعات توسط اعتبارسنج، پیوند را می توان کاهش داد. کمیته های در دسترس بودن داده های اثبات سهام به طور قابل توجهی از DAC های معمولی ایمن تر هستند زیرا مستقیماً رفتار صادقانه را تشویق می کنند.
+
+## در دسترس بودن داده ها و گره های سبک {#data-availability-and-light-nodes}
+
+[گره های سبک](/developers/docs/nodes-and-clients/light-clients) باید صحت هدرهای بلوکی را که دریافت می کنند بدون بارگیری داده های بلوک تأیید کنند. هزینه این سَبُکی نیز ناتوانی در تأیید مستقل هدرهای بلوک با اجرای مجدد تراکنش ها به صورت محلی به روشی است که گره های کامل انجام می دهند.
+
+گره های سبک اتریوم به مجموعه های تصادفی 512 اعتبارسنج که به _کمیته همگام سازی_ اختصاص داده شده اند اعتماد دارند. کمیته همگامسازی بهعنوان یک DAC عمل میکند که با استفاده از یک امضای رمزنگاری به کلاینت های سبک میگوید که دادههای سر صحیح هستند. هر روز، کمیته همگام سازی رفرش می شود. هر سرصفحه بلوک به گرههای سیک هشدار میدهد که کدام اعتبارسنج ها باید بلوک _بعدی_ را امضا کنند، بنابراین نمیتوان آنها را فریب داد تا به یک گروه مخرب که وانمود میکنند کمیته همگامسازی واقعی هستند، اعتماد کنند.
+
+با این حال، چه اتفاقی میافتد اگر یک مهاجم به نحوی _موفق_ شود هدر بلوک مخرب را به کلاینت سبک ارسال کند و آنها را متقاعد کند که توسط یک کمیته همگامسازی صادقانه امضا شده است؟ در آن صورت، مهاجم میتواند تراکنشهای نامعتبر را شامل شود و کلاینت سبک کورکورانه آنها را میپذیرد، زیرا آنها بهطور مستقل تمام تغییرات حالت خلاصهشده در هدر بلوک را بررسی نمیکنند. برای محافظت در برابر این، کلاینت سبک می تواند از اثبات های تقلب استفاده کند.
+
+روش کار این اثبات های تقلب به این صورت است که یک گره کامل، با مشاهده یک انتقال حالت نامعتبر که در اطراف شبکه شایعه می شود، می تواند به سرعت یک قطعه کوچک از داده را تولید کند که نشان دهد یک انتقال حالت پیشنهادی احتمالاً نمی تواند از مجموعه معینی از تراکنش ها ناشی شود و آن داده ها را برای همتایان پخش کند. گرههای سبک میتوانند آن موارد اثبات تقلب را انتخاب کرده و از آنها برای حذف هدرهای بلوک بد استفاده کنند، و اطمینان حاصل کنند که در زنجیره صادقانه مشابه گرههای کامل باقی میمانند.
+
+این متکی بر گره های کامل است که به داده های تراکنش کامل دسترسی دارند. مهاجمی که یک هدر بلوک بد پخش میکند و همچنین نمیتواند دادههای تراکنش را در دسترس قرار دهد، میتواند از ایجاد اثبات تقلب توسط گرههای کامل جلوگیری کند. گرههای کامل ممکن است بتوانند هشداری درباره یک بلوک بد ارسال کنند، اما نمیتوانند از هشدار خود با اثبات پشتیبان بگیرند، زیرا دادهها برای تولید اثبات در دسترس نبودند!
+
+راه حل این مشکل در دسترس بودن داده ها DAS است. گره های سبک، تکه های تصادفی بسیار کوچکی از داده های حالت کامل را دانلود می کنند و از نمونه ها برای تأیید اینکه مجموعه داده کامل در دسترس است استفاده می کنند. احتمال واقعی فرض نادرست در دسترس بودن کامل داده ها پس از دانلود N قطعه تصادفی را می توان محاسبه کرد ([برای 100 تکه این شانس 10^-30 است](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)، یعنی فوقالعاده بعید است).
+
+حتی در این سناریو، حملاتی که تنها چند بایت را در خود نگه میدارند، میتوانند توسط کلاینت هایی که درخواستهای داده تصادفی میکنند مورد توجه قرار نگیرند. کدگذاری پاک کردن این مشکل را با بازسازی قطعات کوچک از دست رفته داده که می تواند برای بررسی تغییرات حالت پیشنهادی مورد استفاده قرار گیرد، برطرف می کند. سپس میتوان با استفاده از دادههای بازسازیشده، یک اثبات تقلب ایجاد کرد و از پذیرش هدرهای بد توسط گرههای سبک جلوگیری کرد.
+
+**توجه:** DAS و اثبات تقلب هنوز برای کلاینت های سبک اتریوم اثبات سهام اجرا نشده اند، اما در نقشه راه هستند و به احتمال زیاد به شکل اثبات های مبتنی بر ZK-SNARK هستند. کلاینت های سبک امروزی به شکلی از DAC متکی هستند: آنها هویت کمیته همگامسازی را تأیید میکنند و سپس به هدرهای بلوک امضا شدهای که دریافت میکنند اعتماد میکنند.
+
+## در دسترس بودن داده ها و رولآپ های لایه2 {#data-availability-and-layer-2-rollups}
+
+[راهحلهای مقیاسبندی لایه2](/layer-2/)، مانند [رولآپ ها](/glossary/#rollups)، هزینههای تراکنش را کاهش میدهند و با پردازش تراکنشهای خارج از زنجیره، توان عملیاتی اتریوم را افزایش میدهند. تراکنشهای رولآپ فشرده می شوند و به صورت دستهای در اتریوم پست میشوند. دسته ها هزاران تراکنش خارج از زنجیره فردی را در یک تراکنش در اتریوم نشان می دهند. این باعث کاهش تراکم در لایه پایه و کاهش هزینه ها برای کاربران می شود.
+
+با این حال، تنها زمانی میتوان به تراکنشهای «خلاصه» ارسالشده در اتریوم اعتماد کرد که تغییر حالت پیشنهادی بهطور مستقل تأیید شود که نتیجه اعمال همه تراکنشهای خارج از زنجیره است. اگر اپراتورهای رولآپ دادههای تراکنش را برای این راستیآزمایی در دسترس قرار ندهند، ممکن است دادههای نادرستی را به اتریوم ارسال کنند.
+
+[رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/) دادههای تراکنش فشرده را به اتریوم ارسال میکنند و برای مدتی (معمولاً 7 روز) منتظر میمانند تا به تأییدکنندگان مستقل اجازه بررسی دادهها را بدهد. اگر کسی مشکلی را شناسایی کند، می تواند یک اثبات تقلب ایجاد کند و از آن برای به چالش کشیدن رولآپ استفاده کند. این باعث می شود زنجیره به عقب برگردد و بلوک نامعتبر را حذف کند. این تنها در صورتی امکان پذیر است که داده ها در دسترس باشند. در حال حاضر، دو راه وجود دارد که رولآپ های خوشبینانه داده های تراکنش را به L1 ارسال کنند. برخی رولآپ ها دادهها را بهصورت دائمی بهعنوان `CALLDATA` در دسترس قرار میدهند که بهطور دائم در زنجیره زندگی میکنند. با اجرای EIP-4844، برخی از رولآپ ها دادههای تراکنش خود را به جای ذخیرهسازی حباب های ارزانتر ارسال میکنند. این ذخیره سازی دائمی نیست. تأییدکنندگان مستقل باید در عرض 18 روز قبل از حذف داده ها از لایه 1 اتریوم، حباب ها را استعلام کنند و چالش های خود را مطرح کنند. در دسترس بودن داده ها فقط توسط پروتکل اتریوم برای آن پنجره کوتاه ثابت تضمین شده است. پس از آن، مسئولیت سایر موجودات در اکوسیستم اتریوم می شود. هر گره می تواند در دسترس بودن داده ها را با استفاده از DAS تأیید کند، یعنی با دانلود نمونه های کوچک و تصادفی از داده های حباب.
+
+[رولآپ های دانش صفر (ZK)](/developers/docs/scaling/zk-rollups) نیازی به ارسال دادههای تراکنش ندارند زیرا [شواهد اعتبار دانش صفر](/glossary/#zk-proof) صحت انتقال حالت را تضمین میکند. با این حال، در دسترس بودن داده ها هنوز یک مشکل است زیرا ما نمی توانیم عملکرد رولآپ دانش صفر (یا تعامل با آن) را بدون دسترسی به داده های وضعیت آن تضمین کنیم. به عنوان مثال، اگر اپراتور جزئیاتی را درباره حالت رولآپ مخفی کند، کاربران نمیتوانند موجودی خود را بدانند. همچنین، آنها نمی توانند با استفاده از اطلاعات موجود در یک بلوک جدید اضافه شده، به روز رسانی حالت را انجام دهند.
+
+## در دسترس بودن داده در مقابل قابلیت بازیابی داده ها {#data-availability-vs-data-retrievability}
+
+در دسترس بودن داده ها با قابلیت بازیابی داده ها متفاوت است. در دست داشتن داده ها با قابلیت بازیابی ها متفاوت است. لزوماً به این معنی نیست که داده ها برای همیشه قابل دسترسی هستند.
+
+قابلیت بازیابی داده ها توانایی گره ها برای بازیابی _اطلاعات تاریخی_ از بلاک چین است. این داده تاریخی برای تأیید بلوک های جدید مورد نیاز نیست، فقط برای همگام سازی گره های کامل از بلوک پیدایش یا ارائه درخواست های تاریخی خاص مورد نیاز است.
+
+پروتکل اصلی اتریوم در درجه اول مربوط به در دسترس بودن داده ها است، نه قابلیت بازیابی داده ها. قابلیت بازیابی دادهها را میتوان توسط جمعیت کوچکی از گرههای بایگانی که توسط اشخاص ثالث اجرا میشوند فراهم کرد، یا میتوان آن را با استفاده از ذخیرهسازی فایل غیرمتمرکز مانند [شبکه پورتال](https://www.ethportal.net/) در سراسر شبکه توزیع کرد.
+
+## اطلاعات بیشتر {#further-reading}
+
+- [WTF قابلیت دسترسی داده است؟](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f)
+- [قابلیت دسترسی داده چیست؟](https://coinmarketcap.com/alexandria/article/what-is-data-availability)
+- [دورنمای قابلیت دسترسی داده اتریوم خارج زنجیره](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/)
+- [مقدمهای بر بررسیهای قابلیت دسترسی داده](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)
+- [شرحی بر شاردینگ + پیشنهاد DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
+- [یادداشتی بر قابلیت دسترسی داده و کدگذاری پاک شدن](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them)
+- [کمیته های در دسترس بودن داده ها.](https://medium.com/starkware/data-availability-e5564c416424)
+- [کمیته های در دسترس بودن داده های اثبات سهام.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)
+- [راه حل هایی برای مشکل بازیابی داده ها](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding)
+- [قابلیت دسترسی داده ها یا: رولآپها چطور یاد گرفتند دیگر نگران نباشند و اتریوم را دوست داشته باشند](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md
new file mode 100644
index 00000000000..7efb9db6d65
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md
@@ -0,0 +1,220 @@
+---
+title: بهترین شیوههای طراحی صرافی غیرمتمرکز (DEX)
+description: راهنمائی برای توضیح تصمیمات گرفته شده درمورد رابط کاربری و تجربه کاربری حین مبادله توکنها.
+lang: fa
+---
+
+از زمان راهاندازی یونی سواپ در سال 2018، صدها صرافی غیرمتمرکز در شبکههای مختلف راهاندازی شده است.
+بسیاری از این صرافیها یک عنصر جدید یا شیوهی مختص به خود را معرفی کردند، اما رابط کاربری بهصورت کلی به همان شکل مانده است.
+
+یکی از دلایل آن [قانون جیکوب](https://lawsofux.com/jakobs-law/) است:
+
+> کاربران بیشتر وقت خود را در وب سایتهای دیگر صرف میکنند. این بدان معناست که کاربران ترجیح میدهند تا سایت شما مشابه سایتهایی عمل کند که در حال حاضر با آنها آشنا هستند.
+
+به لطف نوآورانی همچون یونی سواپ، پنکیک سواپ و سوشی سواپ، کاربران حوزه دیفای یک ایده کلی از این دارند که صرافی غیرمتمرکز چگونه باید به نظر برسد.
+به همین دلیل، چیزهایی مثل "بهترین شیوه" هم اکنون در حال ظهور هستند. میتوان مشاهده کرد که تصمیمات طراحی در میان سایتهای مختلف بیشتر و بیشتر استانداردسازی میشود. تکامل صرافیهای غیرمتمرکز یک مثال بزرگ از تست کردن پروژه با استفاده از اجرا و انتشار آن میباشد. چیزهایی که کار کردند همانطور ماندند و چیزهایی که کار نکردند، دور انداخته شدند. هنوز جا برای شخصی سازی وجود دارد، اما استانداردهای خاصی وجود دارند که یک صرافی غیرمتمرکز باید به آنها پایبند باشد.
+
+این مقاله خلاصه ای است از:
+
+- چه چیزی را شامل شود
+- چگونه آن را تا حد امکان قابل استفاده کنیم
+- راه های اصلی برای سفارشی سازی طراحی
+
+همه وایرفریمهای نمونه بهطور خاص برای این مقاله ساخته شدهاند، اگرچه همه آنها بر اساس پروژههای واقعی هستند.
+
+کیت Figma نیز در پایین موجود است - از آن استفاده کنید و سرعت وایرفریم های خود را افزایش دهید!
+
+## آناتومی ساده یک صرافی غیرمتمرکز {#basic-anatomy-of-a-dex}
+
+رابط کاربری معمولا شامل 3 چیز است:
+
+1. فرم اصلی
+2. دکمه
+3. پنل جزئیات
+
+![Generic DEX UI، نمایش سه عنصر اصلی](./1.png)
+
+## تغییرات {#variations}
+
+این یک موضوع رایج در این مقاله خواهد بود، اما روشهای مختلفی برای سازماندهی این عناصر وجود دارد. "پنل جزئیات" می تواند بدین شکل باشد:
+
+- بالای دکمه
+- زیر دکمه
+- مخفی در پنل آکاردئونی
+- و/یا در حالت "پیش نمایش"
+
+نکته حالت "پیش نمایش" اختیاری است، اما اگر جزئیات بسیار کمی را در رابط کاربری اصلی نشان می دهید، ضروری می شود.
+
+## ساختار فرم اصلی {#structure-of-the-main-form}
+
+این کادری است که در واقع انتخاب میکنید کدام توکن را میخواهید تعویض کنید. کامپوننت شامل یک فیلد ورودی و یک دکمه کوچک در یک ردیف است.
+
+DEX ها معمولاً جزئیات اضافی را در یک ردیف بالا و یک ردیف پایین نمایش می دهند، اگرچه می توان آن را به طور متفاوت پیکربندی کرد.
+
+![ردیف ورودی، با ردیف جزئیات بالا و پایین](./2.png)
+
+## تغییرات {#variations2}
+
+دو تغییر رابط کاربری در اینجا نشان داده شده است. یکی بدون هیچ حاشیه ای، یک طرح بسیار باز ایجاد می کند، و دیگری که در آن ردیف ورودی دارای یک حاشیه است که تمرکز روی آن عنصر ایجاد می کند.
+
+![دو تغییر رابط کاربری فرم اصلی](./3.png)
+
+این ساختار اساسی به **چهار اطلاعات کلیدی** اجازه می دهد تا در طراحی نشان داده شوند: یکی در هر گوشه. اگر فقط یک ردیف بالا/پایین وجود داشته باشد، تنها دو نقطه وجود دارد.
+
+در طول تکامل دیفای، موارد مختلف زیادی در اینجا گنجانده شده است.
+
+## اطلاعات کلیدی برای درج {#key-info-to-include}
+
+- موجودی در کیف پول
+- دکمه Max
+- معادل قیمت به فیات
+- تاثیر قیمت بر مبلغ "دریافت شده"
+
+در روزهای اولیه دیفای، معادل فیات اغلب گم می شد. اگر در حال ساخت هر نوع پروژه Web3 هستید، ضروری است که معادل فیات نشان داده شود. کاربران هنوز بر حسب ارزهای محلی فکر می کنند، بنابراین برای مطابقت با مدل های ذهنی دنیای واقعی، باید این مورد لحاظ شود.
+
+در فیلد دوم (محلی که توکنی را انتخاب میکنید که با آن مبادله میکنید) میتوانید با محاسبه تفاوت بین مقدار ورودی و مقدار خروجی تخمینی، تأثیر قیمت را در کنار مقدار ارز فیات لحاظ کنید. این جزئیات کاملا مفیدی برای گنجاندن است.
+
+دکمه های درصد (مثلاً 25٪، 50٪، 75٪) می توانند یک ویژگی مفید باشند، اما فضای بیشتری را اشغال می کنند، تماس بیشتری را به اقدامات اضافه می کنند و بار ذهنی بیشتری را اضافه می کنند. در مورد لغزنده های درصد نیز همینطور است. برخی از این تصمیمات UI به برند و نوع کاربری شما بستگی دارد.
+
+جزئیات اضافی را می توان در زیر فرم اصلی نشان داد. از آنجایی که این نوع اطلاعات بیشتر برای کاربران حرفه ای است، منطقی است که:
+
+- آن را تا حد امکان مینیمال نگه دارید، یا؛
+- آن را در پنل آکاردئونی پنهان کنید
+
+![جزئیات در گوشه های آن فرم اصلی نشان داده شده است](./4.png)
+
+## اطلاعات اضافی برای درج {#extra-info-to-include}
+
+- قیمت توکن
+- افت
+- حداقل دریافتی
+- خروجی مدنظر
+- اثر قیمت
+- تخمین هزینه گس
+- باقی کارمزدها
+- مسیردهی سفارش
+
+مسلماً برخی از این جزئیات می توانند اختیاری باشند.
+
+مسیریابی سفارش جالب است، اما برای اکثر کاربران تفاوت چندانی ایجاد نمی کند.
+
+برخی جزئیات دیگر به سادگی یک چیز را به روش های مختلف بازگو می کنند. برای مثال «حداقل دریافتی» و «افت قیمت» دو روی یک سکه هستند. اگر افت قیمت را روی 1% تنظیم کردهاید، حداقل مقداری که میتوانید دریافت کنید = خروجی مدنظر - 1%. برخی از رابطهای کاربری مقدار مورد انتظار، حداقل مقدار و افت را نشان میدهند… که مفید است اما احتمالاً بیش از حد است.
+
+اکثر کاربران به هر حال افت قیمت پیش فرض را خالی می گذارند.
+
+"تأثیر قیمت" اغلب در پرانتز در کنار معادل فیات در قسمت "به" نشان داده می شود. این اطلاعات عالی درباره ux برای افزودن است، اما اگر در اینجا نشان داده شود، آیا واقعاً باید دوباره در زیر نشان داده شود؟ و سپس دوباره در یک صفحه پیش نمایش بیاید؟
+
+بسیاری از کاربران (مخصوصاً آنهایی که مقادیر کم را مبادله می کنند) به این جزئیات اهمیت نمی دهند. آنها به سادگی یک عدد وارد می کنند و swap را می زنند.
+
+![برخی جزئیات همین را نشان میدهد](./5.png)
+
+اینکه دقیقاً چه جزئیاتی نشان داده می شود به مخاطبان شما و احساسی که می خواهید برنامه داشته باشد بستگی دارد.
+
+اگر آستانه تحمل افت را در پنل جزئیات لحاظ کنید، باید آن را مستقیماً از اینجا نیز قابل ویرایش کنید. این مثال خوبی از "شتاب دهنده" است. یک ترفند ساده UX که میتواند جریان کاربران با تجربه را سرعت بخشد، بدون اینکه بر قابلیت استفاده عمومی برنامه تأثیر بگذارد.
+
+![افت قیمت را می توان از پنل جزئیات کنترل کرد](./6.png)
+
+این ایده خوبی است که نه تنها در مورد یک قطعه خاص از اطلاعات در یک صفحه، بلکه در مورد کل جریان از طریق آن به دقت فکر کنید:
+وارد کردن اعداد در فرم اصلی ← جزئیات اسکن ← کلیک کردن برای پیش نمایش صفحه (اگر صفحه پیش نمایش دارید).
+آیا پنل جزئیات باید همیشه قابل مشاهده باشد یا کاربر برای بزرگ شدن باید روی آن کلیک کند؟
+آیا باید با افزودن یک صفحه پیش نمایش اصطکاک ایجاد کنید؟ این امر کاربر را مجبور می کند تا سرعت خود را کاهش دهد و مبادله خود را در نظر بگیرد که می تواند مفید باشد. اما آیا آنها می خواهند همه همان اطلاعات را دوباره ببینند؟ چه چیزی در این مرحله برای آنها مفیدتر است؟
+
+## گزینه های طراحی {#design-options}
+
+همانطور که گفته شد، بسیاری از این موارد به سبک شخصی شما برمی گردد
+کاربر شما کیست؟
+برند شما چیست؟
+آیا یک رابط حرفه ای می خواهید که تمام جزئیات را نشان دهد یا می خواهید مینیمالیستی باشید؟
+حتی اگر به دنبال کاربران حرفهای هستید که همه اطلاعات را میخواهند، باز هم باید سخنان حکیمانه آلن کوپر را به خاطر بسپارید:
+
+> هر چقدر هم که رابط کاربری شما زیبا باشد، بهتر است کمتر از آن استفاده کنید.
+
+### ساختار {#structure}
+
+- توکن ها در سمت چپ یا توکن ها در سمت راست
+- 2 ردیف از 3
+- جزئیات بالا یا زیر دکمه
+- جزئیات گسترش یافته، حداقل شود یا نشان داده نشود
+
+### استایل کامپوننت {#component-style}
+
+- خالی
+- تاکید شده
+- پر شده
+
+از نقطه نظر UX خالص، سبک UI کمتر از آنچه فکر می کنید اهمیت دارد. روندهای بصری در چرخه می آیند و می روند و بسیاری از اولویت ها ذهنی است.
+
+ساده ترین راه برای درک این موضوع - و فکر کردن به پیکربندی های مختلف - این است که به چند نمونه نگاه کنید و سپس خودتان آزمایش کنید.
+
+کیت Figma شامل اجزای خالی، پیشفرض و پر شده است.
+
+به مثال های زیر نگاهی بیندازید تا روش های مختلفی را مشاهده کنید که می توانید همه آن ها را کنار هم قرار دهید:
+
+![3 ردیف به سبک پر شده](./7.png)
+
+![3 ردیف به سبک متن تاکید شده](./8.png)
+
+![2 ردیف به سبک خالی](./9.png)
+
+![3 ردیف به سبک متن پیشفرض، با پنل جزئیات](./10.png)
+
+![3 ردیف با ردیف ورودی به سبک متن تاکید شده](./11.png)
+
+![2 ردیف به سبک پر شده](./12.png)
+
+## اما توکن باید به کدام سمت برود؟ {#but-which-side-should-the-token-go-on}
+
+نکته اصلی این است که احتمالاً تفاوت زیادی در قابلیت استفاده ایجاد نمی کند. با این حال، چند نکته وجود دارد که باید به خاطر داشته باشید، که ممکن است شما را به یک جهت تحت تاثیر قرار دهد.
+
+دیدن تغییر مد با گذشت زمان کمی جالب است. Uniswap در ابتدا توکن را در سمت چپ داشت، اما از آن زمان آن را به سمت راست منتقل کرده است. Sushiswap نیز این تغییر را طی یک ارتقاء طراحی ایجاد کرد. بیشتر پروتکلها، اما نه همه، از همین روند پیروی کردهاند.
+
+قوانین مالی به طور سنتی نماد ارز را قبل از عدد قرار می دهد، به عنوان مثال. $50، €50، £50، اما ما _می گوییم_ 50 دلار، 50 یورو، 50 پوند.
+
+برای کاربر عمومی - به خصوص کسی که از چپ به راست، از بالا به پایین می خواند - نشانه سمت راست احتمالا طبیعی تر است.
+
+![یک رابط کاربری با توکن ها در سمت چپ](./13.png)
+
+قرار دادن توکن در سمت چپ و همه اعداد در سمت راست به طرز خوشایندی متقارن به نظر می رسند، که یک امتیاز مثبت است، اما یک نقطه ضعف دیگر در این طرح وجود دارد.
+
+قانون مجاورت بیان می کند که مواردی که نزدیک به هم هستند به عنوان مرتبط تلقی می شوند. بر همین اساس می خواهیم موارد مرتبط را در کنار یکدیگر قرار دهیم. موجودی توکن مستقیماً با خود توکن مرتبط است و هر زمان که یک توکن جدید انتخاب شود تغییر خواهد کرد. بنابراین کمی منطقی تر است که موجودی توکن در کنار دکمه انتخاب نشانه باشد. میتوان آن را به زیر نشانه منتقل کرد، اما این تقارن طرحبندی را میشکند.
+
+در نهایت، نکات مثبت و منفی برای هر دو گزینه وجود دارد، اما جالب است که به نظر می رسد چگونه روند به سمت توکن سمت راست است.
+
+# رفتار دکمه {#button-behavior}
+
+دکمه جداگانه ای برای تأیید نداشته باشید. همچنین یک کلیک جداگانه برای تأیید نداشته باشید. کاربر میخواهد Swap را انجام دهد، بنابراین فقط روی دکمه بگویید «swap» و تأیید را به عنوان اولین مرحله آغاز کنید. یک مودال میتواند پیشرفت را با یک استپر یا یک اعلان ساده "tx 1 of 2 - تایید" نشان دهد.
+
+![یک رابط کاربری با دکمههای جداگانه برای تأیید و swap](./14.png)
+
+![یک رابط کاربری با یک دکمه که تأیید میکند](./15.png)
+
+## دکمه به عنوان راهنمای متنی {#button-as-contextual-help}
+
+این دکمه می تواند به عنوان یک هشدار، وظیفه ای مضاعف را انجام دهد!
+
+این در واقع یک الگوی طراحی نسبتاً غیرعادی در خارج از Web3 است، اما در داخل آن استاندارد شده است. این یک نوآوری خوب است زیرا باعث صرفه جویی در فضا می شود و توجه را متمرکز نگه می دارد.
+
+اگر عمل اصلی - SWAP - به دلیل خطا در دسترس نیست، دلیل آن را می توان با دکمه توضیح داد، به عنوان مثال.:
+
+- تعویض شبکه
+- اتصال کیف پول
+- خطاهای متعدد
+
+این دکمه همچنین می تواند **به عملکرد** که باید انجام شود نگاشت شود. به عنوان مثال، اگر کاربر نمی تواند به دلیل اینکه در شبکه اشتباهی قرار دارد، مبادله کند، دکمه باید بگوید “switch to Ethereum” و زمانی که کاربر روی دکمه کلیک می کند، باید شبکه را به اتریوم تغییر دهد. این سرعت جریان کاربر را به میزان قابل توجهی افزایش می دهد.
+
+![عملکردهای کلیدی از CTA اصلی شروع میشوند](./16.png)
+
+![پیام خطا در CTA اصلی نشان داده میشود](./17.png)
+
+## مال خودتان را با این فایل فیگما بسازید {#build-your-own-with-this-figma-file}
+
+به لطف کار سخت پروتکل های متعدد، طراحی DEX بسیار بهبود یافته است. ما می دانیم که کاربر به چه اطلاعاتی نیاز دارد، چگونه باید آن را نشان دهیم و چگونه جریان را تا حد امکان روان کنیم.
+امیدواریم این مقاله یک نمای کلی از اصول UX ارائه دهد.
+
+اگر میخواهید آزمایش کنید، لطفاً از کیت وایرفریم فیگما استفاده کنید. تا حد امکان ساده نگه داشته می شود، اما انعطاف کافی برای ساختن ساختار اصلی به روش های مختلف دارد.
+
+[کیت وایرفریم فیگما](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
+
+دیفای به تکامل خود ادامه خواهد داد و همیشه جایی برای بهبود وجود دارد.
+
+موفق باشید!
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md
new file mode 100644
index 00000000000..5cf74c4ece5
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md
@@ -0,0 +1,138 @@
+---
+title: 7 اکتشاف برای طراحی رابط Web3
+description: اصولی برای بهبود قابلیت استفاده از Web3
+lang: fa
+---
+
+اکتشاف قابلیت استفاده "قوانین سرانگشتی" گسترده ای هستند که می توانید برای اندازه گیری قابلیت استفاده سایت خود از آنها استفاده کنید.
+این اکتشاف ها به طور خاص برای Web3 طراحی شده اند و باید در کنار Jakob Nielsen [10 اصل کلی برای طراحی تعامل] (https://www.nngroup.com/articles/ten-usability-heuristics/) استفاده شوند.
+
+## هفت اکتشاف قابلیت استفاده برای web3 {#seven-usability-heuristics-for-web3}
+
+1. بازخورد در ادامه عمل میآید
+2. امنیت و اعتماد
+3. مهمترین اطلاعات واضح است
+4. اصطلاحات قابل درک
+5. اقدامات تا حد امکان کوتاه است
+6. اتصالات شبکه قابل مشاهده و انعطاف پذیر هستند
+7. از برنامه کنترل کنید، نه کیف پول
+
+## تعاریف و مثالها {#definitions-and-examples}
+
+### 1. بازخورد به دنبال عمل میآید {#feedback-follows-action}
+
+**وقتی اتفاقی افتاده یا در حال وقوع است باید واضح باشد.**
+
+کاربران بر اساس نتیجه گام های قبلی خود در مورد مراحل بعدی خود تصمیم می گیرند. بنابراین ضروری است که آنها از وضعیت سیستم مطلع شوند. این امر به ویژه در Web3 بسیار مهم است زیرا تراکنشها گاهی اوقات ممکن است زمان کوتاهی طول بکشد تا به بلاک چین متعهد شوند. اگر بازخوردی وجود نداشته باشد که به آنها اطلاع دهد که منتظر بمانند، کاربران مطمئن نیستند که آیا اتفاقی افتاده یا خیر.
+
+**نکات:**
+
+- از طریق پیام رسانی، اعلان ها و سایر هشدارها به کاربر اطلاع دهید.
+- زمان های انتظار را به وضوح در میان بگذارید.
+- اگر قرار است عملی بیش از چند ثانیه طول بکشد، با استفاده از یک تایمر یا یک انیمیشن به کاربر اطمینان دهید تا احساس کند چیزی در حال رخ دادن است.
+- اگر چندین مرحله برای یک فرآیند وجود دارد، هر مرحله را نشان دهید.
+
+**مثال:**
+نمایش هر مرحله درگیر در یک تراکنش به کاربران کمک می کند تا بدانند در کجای فرآیند قرار دارند. آیکون های مناسب به کاربر امکان می دهند از وضعیت اقدامات خود مطلع شود.
+
+![اطلاع رسانی به کاربر در مورد هر مرحله هنگام تعویض نشانه](./Image1.png)
+
+### 2. امنیت و اعتماد ایجاد میشوند {#security-and-trust-are-backed-in}
+
+امنیت باید در اولویت قرار گیرد و این باید برای کاربر تاکید شود.
+افراد عمیقاً به داده های خود اهمیت می دهند. ایمنی اغلب یک نگرانی اولیه برای کاربران است، بنابراین باید در تمام سطوح طراحی در نظر گرفته شود. همیشه باید به دنبال جلب اعتماد کاربران خود باشید، اما روشی که این کار را انجام میدهید میتواند در اپلیکیشنهای مختلف معنای متفاوت داشته باشد. این نباید یک فکر ثانوی باشد، بلکه باید آگاهانه طراحی شود. در طول تجربه کاربر، از جمله کانالهای اجتماعی و اسناد، و همچنین رابط کاربری نهایی، اعتماد ایجاد کنید. مواردی مانند سطح غیرمتمرکز، وضعیت چند علامت خزانه، و اینکه آیا تیم از کار افتاده است یا نه، همگی بر اعتماد کاربران تأثیر میگذارند
+
+**نکات:**
+
+- ممیزی های خود را با افتخار فهرست کنید
+- ممیزی های متعدد دریافت کنید
+- هر ویژگی ایمنی که طراحی کرده اید را تبلیغ کنید
+- خطرات احتمالی، از جمله ادغام های اساسی را برجسته کنید
+- پیچیدگی استراتژی ها را به اشتراک بگذارید
+- مسائل غیر UI را در نظر بگیرید که ممکن است بر درک کاربران شما از ایمنی تأثیر بگذارد
+
+**مثال:**
+ممیزیهای خود را در پاورقی، در اندازههای برجسته بگنجانید.
+
+![به ممیزی ها در پاورقی وب سایت استناد شده است](./Image2.png)
+
+### 3. مهمترین اطلاعات واضح است {#the-most-important-info-is-obvious}
+
+برای سیستم های پیچیده، فقط مرتبط ترین داده ها را نشان دهید. تعیین کنید چه چیزی مهم است و نمایش آن را اولویت بندی کنید.
+اطلاعات بیش از حد طاقت فرسا است و کاربران معمولاً هنگام تصمیم گیری بر روی یک قطعه اطلاعات تمرکز میکنند. در DeFi، این احتمالاً APR برای برنامههای بازدهی و LTV در برنامههای وامدهی خواهد بود.
+
+**نکات:**
+
+- تحقیقات کاربر مهمترین معیار را آشکار می کند
+- اطلاعات کلیدی را بزرگ و سایر جزئیات را کوچک و محجوب کنید
+- افراد نمی خوانند، اسکن می کنند. اطمینان حاصل کنید که طرح شما قابل اسکن است
+
+**مثال:** نشانه های بزرگ به صورت تمام رنگی هنگام اسکن به راحتی پیدا می شوند. APR بزرگ است و با رنگ برجسته برجسته شده است.
+
+![یافتن نشانه و APR آسان است](./Image3.png)
+
+### 4. اصطلاحات واضح {#clear-terminology}
+
+اصطلاحات باید قابل فهم و مناسب باشند.
+اصطلاحات فنی می تواند یک مانع بزرگ باشد، زیرا نیاز به ساخت یک مدل ذهنی کاملاً جدید دارد. کاربران نمی توانند طراحی را با کلمات، عبارات و مفاهیمی که از قبل می دانند مرتبط کنند. همه چیز گیج کننده و ناآشنا به نظر می رسد، و قبل از اینکه آنها حتی بتوانند از آن استفاده کنند، یک منحنی یادگیری شیب دار وجود دارد. کاربرانی که میخواهند مقداری پول پسانداز کنند، ممکن است به DeFi نزدیک شوند، و چیزی که پیدا میکنند این است: استخراج، فارمینگ، سهامگذاری، انتشار گازهای گلخانهای، رشوه، گاوصندوق ها، قفسهها، توکنهای vetoken، واگذاری، ایپوک ها، الگوریتمهای غیرمتمرکز، نقدینگی متعلق به پروتکل…
+سعی کنید از اصطلاحات ساده ای استفاده کنید که برای گسترده ترین گروه مردم قابل درک باشد. اصطلاحات جدید را فقط برای پروژه خود اختراع نکنید.
+
+**نکات:**
+
+- از اصطلاحات ساده و ثابت استفاده کنید
+- تا حد امکان از زبان موجود استفاده کنید
+- شرایط خود را مطرح نکنید
+- قراردادها را همانطور که ظاهر می شوند دنبال کنید
+- تا حد امکان به کاربران آموزش دهید
+
+**مثال:**
+"پاداش شما" اصطلاحی است که به طور گسترده درک میشود و خنثی است و کلمه جدیدی برای این پروژه ساخته نشده است. جوایز به USD تعلق میگیرد تا با مدلهای ذهنی دنیای واقعی مطابقت داشته باشد، حتی اگر خود پاداشها با توکن دیگری باشند.
+
+![جوایز توکنی، نمایش داده شده به دلار آمریکا](./Image4.png)
+
+### 5. اقدامات تا حد امکان کوتاه هستند {#actions-are-as-short-as-possible}
+
+با گروهبندی کنشهای فرعی، تعاملات کاربر را تسریع کنید.
+این ممکن است در سطح قرارداد هوشمند و همچنین رابط کاربری انجام شود. کاربر نباید مجبور باشد از یک قسمت سیستم به قسمت دیگر حرکت کند - یا سیستم را به طور کامل ترک کند تا یک اقدام مشترک را انجام دهد.
+
+**نکات:**
+
+- در صورت امکان، «تأیید» را با سایر اقدامات ترکیب کنید
+- مراحل امضا را تا حد امکان به هم نزدیک کنید
+
+**مثال:** ترکیب «افزودن نقدینگی» و «سهام» یک مثال ساده از شتابدهندهای است که در زمان و گس کاربر صرفهجویی میکند.
+
+![Modal نشان دادن سوئیچ برای ترکیب اقدامات سپرده و سهام](./Image5.png)
+
+### 6. اتصالات شبکه قابل مشاهده و انعطاف پذیر هستند {#network-connections-are-visible-and-flexible}
+
+به کاربر اطلاع دهید که به چه شبکه ای متصل است و میانبرهای واضحی برای تغییر شبکه ارائه دهید.
+این به ویژه در برنامه های چند زنجیره ای مهم است. عملکردهای اصلی برنامه همچنان باید هنگام قطع یا اتصال به یک شبکه غیر پشتیبانی قابل مشاهده باشند.
+
+**نکات:**
+
+- تا آنجا که ممکن است برنامه را هنگام قطع ارتباط نشان دهید
+- نشان دهید که کاربر در حال حاضر به کدام شبکه متصل است
+- کاربر را مجبور نکنید برای تغییر شبکه به کیف پول مراجعه کند
+- اگر برنامه از کاربر میخواهد که شبکه را تغییر دهد، این عمل را از تماس اصلی برای اقدام درخواست کنید
+- اگر برنامه حاوی بازارها یا انبارهایی برای چندین شبکه است، به وضوح مشخص کنید که کاربر در حال حاضر به کدام مجموعه نگاه می کند
+
+**مثال:** به کاربر نشان دهید که به کدام شبکه متصل است و به او اجازه دهید آن را در نوار برنامه تغییر دهد.
+
+![دکمه کشویی شبکه متصل را نشان می دهد](./Image6.png)
+
+### 7. کنترل از برنامه، نه کیف پول {#control-from-the-app-not-the-wallet}
+
+رابط کاربری باید همه چیزهایی که کاربر باید بداند را بگوید و کنترل همه چیزهایی که باید انجام دهد را به او بدهد.
+در Web3، اقداماتی هستند که در رابط کاربری انجام می دهید و اقداماتی که در کیف پول انجام می دهید. به طور کلی، شما یک عمل را در UI آغاز می کنید و سپس آن را در کیف پول تأیید می کنید. اگر این دو رشته به دقت ادغام نشوند، کاربران ممکن است احساس ناراحتی کنند.
+
+**نکات:**
+
+- وضعیت سیستم را از طریق بازخورد در UI اعلام کنید
+- تاریخچه آنها را ثبت کنید
+- پیوندهایی برای مسدود کردن کاوشگرها برای تراکنش های قدیمی ارائه دهید
+- میانبرهایی برای تغییر شبکه ها ارائه دهید.
+
+**مثال:** یک ظرف ظریف به کاربر نشان می دهد که چه توکن های مرتبطی در کیف پول خود دارد و CTA اصلی میانبری برای تغییر شبکه ارائه می دهد.
+
+![CTA اصلی از کاربر میخواهد شبکه را تغییر دهد](./Image7.png)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md
new file mode 100644
index 00000000000..d5d609a3ded
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md
@@ -0,0 +1,85 @@
+---
+title: طراحی و UX در web3
+description: مقدمه ای بر طراحی و تحقیق UX در فضای Web3 و اتریوم
+lang: fa
+---
+
+آیا در طراحی با اتریوم تازه کار هستید؟ اینجا مکان مناسب شماست. جامعه اتریوم منابع مکتوبی برای آشنایی شما با اصول طراحی Web3 و تحقیق دارد. در مورد مفاهیم اصلی که ممکن است با سایر طرح های برنامه ای که با آنها آشنا هستید متفاوت باشد، آشنا خواهید شد.
+
+ابتدا به درک پایهای تری از web3 نیاز دارید؟ [**مرکز یادگیری**](/learn/) ما را بررسی کنید.
+
+## با تحقیقات کاربر شروع کنید {#start-with-user-research}
+
+طراحی موثر فراتر از ایجاد رابط های کاربری جذاب بصری است. این شامل کسب درک عمیق از نیازها، اهداف و عوامل محرک کاربر است. بنابراین، به شدت توصیه می کنیم که همه طراحان، یک فرآیند طراحی مانند [**فرایند الماس دوگانه**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)) را اتخاذ کنند تا اطمینان حاصل کنند که کار آنها هدفمند و آگاهانه است.
+
+- [Web3 به محققان و طراحان UX بیشتری نیاز دارد](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - مروری بر بلوغ طراحی فعلی
+- [راهنمای ساده برای تحقیقات UX در Web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - راهنمای ساده نحوه انجام تحقیق
+- [نحوه رویکرد به تصمیمات UX در Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - مروری کوتاه بر تحقیقات کمی و کیفی و تفاوتهای بین این دو (ویدئو، 6 دقیقه)
+- [محقق ux بودن در web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - دیدگاه شخصی در مورد اینکه یک محقق UX در web3 چگونه است
+
+## مطالعات پژوهشی در Web3 {#research-in-web3}
+
+این لیستی از تحقیقات کاربر انجام شده در Web3 است که ممکن است به تصمیم گیری در مورد طراحی و محصول کمک کند یا به عنوان الهام بخش برای انجام مطالعه شخصی باشد.
+
+| حوزه تمرکز | نام |
+|:------------------------------------------------------ |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ورود به رمزنگاری | [CRADL: UX رمز از](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
+| ورود به رمزنگاری | [CRADL: ورود به رمزارز](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
+| ورود به رمزنگاری | [بیت کوین در گزارش UX](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
+| ورود به رمزنگاری | [ConSensys: حالت درک Web3 درباره دنیا 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
+| ورود به رمزنگاری | [NEAR: شتاب دادن به تجربه به سوی پذیرش](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
+| سهام گذاری | [سهام گذاری: گرایش های کلیدی، و پیشبینیها - سهام گذار اتر](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
+| سهام گذاری | [سهام گذاری چندبرنامه ای](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
+| DAO | [به روز رسانی تحقیقات DAO در 2022: سازندگان DAO چه چیز لازم دارند؟](https://blog.aragon.org/2022-dao-research-update/) |
+| DeFi | [حالت Defi 2024](https://stateofdefi.org/) (نظرسنجی در حال انجام) |
+| DeFi | [استخرهای پوشش](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
+| DeFi | [ConSensys: گزارش تحقیقات کاربران DeFi در 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
+| متاورس | [Metaverse: گزارش تحقیقات کاربر](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
+| متاورس | [رفتن در سفری: تحقیق درباره کاربران در Metaverse](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (ویدیو، 27 دقیقه) |
+| آمار Ethereum.org UX | [داشبورد نظرسنجی قابلیت استفاده و رضایت کاربران - Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) |
+
+## طراحی برای web3 {#design-for-web3}
+
+- [راهنمای طراحی Web3 UX](https://web3ux.design/) - راهنمای عملی برای طراحی برنامه های Web3
+- [اصول طراحی وب 3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - چارچوبی از قوانین UX برای برنامه های مبتنی بر بلاک چین
+- [اصول طراحی بلاکچین](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - درسهایی که تیم طراحی بلاک چین در IBM آموخته است
+- [الگوهای طراحی Web3](https://www.web3designpatterns.io/) - یک کتابخانه انتخاب شده از الگوهای طراحی از محصولات واقعی Web3
+- [W3design.io](https://w3design.io/) - یک کتابخانه مدیریتشده از جریانهای رابط کاربری پروژههای مختلف در اکوسیستم
+- [Neueux.com](https://neueux.com/apps) - کتابخانه UI از جریان های کاربر با گزینه های مختلف فیلتر
+- [بحران قابلیت استفاده Web3: آنچه شما باید بدانید!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - بحث میزگرد در مورد مشکلات ساخت پروژه متمرکز بر توسعه دهنده (ویدئو، 34 دقیقه)
+
+## مطالعات موردی طراحی Web3 {#design-case-studies}
+
+- [Deep Work Studio](https://deepwork.studio/case-studies/)
+- [راهنمای Crypto UX](https://www.cryptouxhandbook.com/)
+- [فروش یک NFT در OpenSea](https://builtformars.com/case-studies/opensea)
+- [کنار گذاشتن کیف پول UX چگونه کیفهای پول باید عوض شوند](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (ویدیو، 20 دقیقه)
+
+## پاداشهای طراحی {#bounties}
+
+- [Dework](https://app.dework.xyz/bounties)
+- [گردهمآیی Buildbox](https://app.buidlbox.io/)
+- [گردهمآیی ETHGlobal](https://ethglobal.com/)
+
+## طراحی DAOها و جوامع {#design-daos-and-communities}
+
+در سازمان های حرفه ای جامعه محور شرکت کنید یا به گروه های طراحی بپیوندید تا درباره موضوعات و گرایش های مربوط به طراحی و تحقیق با سایر اعضا بحث کنید.
+
+- [Vectordao.com](https://vectordao.com/)
+- [Deepwork.studio](https://www.deepwork.studio/)
+- [Designer-dao.xyz](https://www.designer-dao.xyz/)
+- [We3.co](https://we3.co/)
+- [Openux.xyz](https://openux.xyz/)
+- [Open Source Web3Design](https://www.web3designers.org/)
+
+## سیستم طراحی {#design-systems}
+
+- [Optimism Design](https://www.figma.com/@optimism) (Figma)
+- [سیستم طراحی Ethereum.org Design](https://www.figma.com/@ethdotorg) (Figma)
+- [Finity، یک سیستم طراحی توسط پالیگان](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (فیگما)
+- [Kleros Design System](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
+- [Safe Design System](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
+- [سیستم طراحی ENS](https://thorin.ens.domains/)
+- [سیستم طراحی Mirror](https://degen-xyz.vercel.app/)
+
+**مقالات و پروژه های فهرست شده در این صفحه تاییدیه رسمی نیستند** و فقط برای اهداف اطلاع رسانی ارائه شده اند. ما لینک ها را بر اساس معیارهای [خطمشی لیستینگ](/contributing/design/adding-design-resources) خود به این صفحه اضافه میکنیم. اگر میخواهید پروژه/مقالهای اضافه کنیم، این صفحه را در [گیتهاب](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) ویرایش کنید.
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md
new file mode 100644
index 00000000000..33ef8da3222
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md
@@ -0,0 +1,221 @@
+---
+title: حداکثر ارزش قابل استخراج (MEV)
+description: مقدمهای بر حداکثر ارزش قابل استخراج (MEV)
+lang: fa
+---
+
+حداکثر ارزش قابل استخراج (MEV) به بیشترین ارزش قابل استخراج از تولید بلاک اشاره دارد که علاوه بر پاداش استاندارد بلاک شامل کارمزد تراکنشها است و این کارمزدها با وارد کردن، خارج کردن و تغییر در ترتیب تراکنشهای موجود در بلاک میتواند تغییر کند.
+
+## حداکثر ارزش قابل استخراج {#maximal-extractable-value}
+
+حداکثر ارزش قابل استخراج اولین بار در زمینه [اثبات کار](/developers/docs/consensus-mechanisms/pow/)استفاده شد و اوایل به "ارزش قابل استخراج استخراجگر" اشاره میکرد. این به این دلیل است که در اثبات کار استخراجگرها شمول، عدم شمول و ترتیب تراکنشها در بلاک را کنترل میکنند. با این حال، پس از تغییر الگوریتم اجماع به اثبات سهام با [ادغام](/roadmap/merge) اعتبارسنجها این وظایف را بر عهده دارند و استخراج دیگر بخشی از پروتکل اتریوم نیست. روشهای استخراج ارزش همچنان وجود دارند و به همین دلیل عبارت حداکثر ارزش قابل استخراج استفاده میشود.
+
+## پیشنیازها {#prerequisites}
+
+مطمئن شوید که با مفاهیم زیر آشنا هستید.[تراکنشها](/developers/docs/transactions/)، [بلاکها](/developers/docs/blocks/)، [اثبات سهام](/developers/docs/consensus-mechanisms/pos) و [گاز](/developers/docs/gas/). آشنایی با [اپلیکیشنهای غیرمتمرکز](/dapps/) و [امور مالی غیرمتمرکز](/defi/) نیز میتواند مفید باشد.
+
+## استخراج حداکثر ارزش قابل استخراج {#mev-extraction}
+
+در تئوری MEV به طور کامل به اعتبارسنجها تعلق میگیرد زیرا آنها تنها کسانی هستند که میتوانند اجرای یک فرصت سودآور MEV را تضمین کنند. اما در عمل،بیشترین نسبت MEV استخراج شده مربوط به فعالان مستقل شبکه است که با نام «جستجوگرها» (Searcher) شناخته میشوند. جستجوگرها الگوریتمهای پیچیده را بر روی داده بلاک چین اعمال میکنند تا موقعیتهای سودآور MEV را شناسایی کنند و رباتهایی دارند که به صورت خودکار تراکنشهای سودآور را به شبکه ارسال میکند.
+
+به هر حال اعتبارسنجها نیز بخشی از کل MEV را به دست میآورند زیرا جستجوگرها برای اینکه احتمال شمول تراکنش سودآور خود را در بلاک افزایش دهند کارمزد تراکنش بالاتری پرداخت میکنند (که این مبلغ به اعتبارسنج داده میشود). اگر فرض کنیم که جستجوگرها از نظر اقتصادی منطقی هستند، کارمزد تراکنشی که یک جستجوگر مایل است پرداخت کند نهایتا به اندازه 100 درصد MEV محاسبه شده است (زیرا اگر کارمزد تراکنش بالاتر باشد، جستجوگر ضرر میکند).
+
+به همین دلیل، برای برخی از موقعیتهای رقابتی MEV مثل [آربیتراژ در صرافی غیرمتمرکز](#mev-examples-dex-arbitrage)، جستجوگرها مجبورند تا 90 درصد و حتی بیشتر درآمد MEV را به صورت کارمزد تراکنش به اعتبارسنج بدهند زیرا تعداد زیادی از افراد میخواهند همان معامله سودآور آربیتراژ را اجرا کنند. این به این دلیل است که تنها راه تضمین اینکه تراکنش آربیتراژ آنها اجرایی میشود این است که آنها تراکنش را با بالاترین هزینه کارمزد ثبت کرده باشند.
+
+### بهینهسازی گاز {#mev-extraction-gas-golfing}
+
+این پدیده باعث به وجود آمدن یک مزیت رقابتی به نام خوب بودن در "مسابقه گاز" شده است - که به معنای برنامه نویسی تراکنشها به گونهای که کمترین مقدار گاز را مصرف کنند، میباشد - و چون این به جستجوگران اجازه میدهد قیمت گاز بالاتری را تعیین و پرداخت نمایند و در عین حال هزینههای کل مقدار گاز خود را ثابت نگه دارند (از آنجایی که هزینه گاز = قیمت گاز \* گاز مصرف شده میباشد).
+
+چند تکنیک معروف بهینهسازی گاز عبارتند از: استفاده از آدرسهایی که با یک رشته طولانی صفر شروع میشوند (به عنوان مثال [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)) زیرا فضای (و در نتیجه گاز) کمتری برای ذخیره میگیرند. و باقی ماندن توکن های کوچک [ERC-20](/developers/docs/standards/tokens/erc-20/) در قراردادها، از آنجا که برای مقداردهی اولیه یک اسلات ذخیره سازی گاز بیشتری نسبت به به روز رسانی اسلات ذخیره سازی دارد. یافتن تکنیکهای بیشتر برای کاهش مصرف گاز، یک حوزه تحقیقاتی فعال در میان جستجوگران است.
+
+### پیشتازان عمومی {#mev-extraction-generalized-frontrunners}
+
+به جای برنامهریزی الگوریتمهای پیچیده برای شناسایی فرصتهای سودآور MEV، برخی از جستجوگران از پیشتازان عمومی استفاده میکنند. پیشتازان عمومی، ربات هایی هستند که برای شناسایی تراکنش های سودآور، استخر حافظه را تماشا می کنند. پیشتاز کد تراکنش بالقوه سودآور را کپی میکند، آدرسها را با آدرس پیشتاز جایگزین میکند و تراکنش را به صورت محلی اجرا میکند تا دوباره بررسی کند که تراکنش اصلاحشده منجر به سود در آدرس پیشتاز شود. اگر تراکنش واقعاً سودآور باشد، پیشتاز تراکنش اصلاح شده را با آدرس جایگزین شده و گاز بالاتر ارسال میکند و تراکنش اصلی را «پیشآزمایی» میکند و MEV جستجوگر اصلی را دریافت میکند.
+
+### Flashbotها {#mev-extraction-flashbots}
+
+Flashbots یک پروژه مستقل است که کلاینت های اجرا را با سرویسی گسترش میدهد که به جستجوگران اجازه میدهد تا تراکنشهای MEV را بدون افشای آنها برای اعتبارسنج ها ارسال کنند. این کار مانع از پیشروی تراکنش ها توسط پیشتازان عمومی می شود.
+
+## نمونه های MEV {#mev-examples}
+
+MEV به چند روش در بلاک چین ظاهر می شود.
+
+### آربیتراژ DEX {#mev-examples-dex-arbitrage}
+
+آربیتراژ [صرافی غیرمتمرکز](/glossary/#dex) (DEX) ساده ترین و شناخته شده ترین فرصت MEV است. در نتیجه رقابتی ترین هم هست.
+
+این کار به این صورت است: اگر دو DEX یک توکن را با دو قیمت متفاوت ارائه دهند، یک نفر می تواند توکن را در DEX با قیمت پایین تر بخرد و آن را در DEX با قیمت بالاتر در یک تراکنش اتمی بفروشد. به لطف مکانیزم بلاک چین، این آربیتراژ واقعی و بدون ریسک است.
+
+[در اینجا مثالی است](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) از تراکنش آربیتراژ سودآور که در آن جستجوگر با استفاده از قیمتهای متفاوت جفت ETH/DAI در Uniswap در مقابل Sushiswap، 1000 ETH را به 1045 ETH تبدیل کرد.
+
+### نقد شدن ها {#mev-examples-liquidations}
+
+انحلال پروتکل وام دهی فرصت شناخته شده دیگری برای MEV است.
+
+پروتکلهای وام دهی مانند Maker و Aave از کاربران میخواهند که وثیقهای (مانند ETH) را واریز کنند. سپس این وثیقه سپرده شده برای وام دادن به سایر کاربران استفاده می شود.
+
+سپس کاربران میتوانند بسته به نیازشان داراییها و نشانهها را از دیگران قرض بگیرند (مثلاً اگر میخواهید در یک پیشنهاد حاکمیتی MakerDAO رای دهید، ممکن است MKR قرض بگیرید) تا درصد معینی از وثیقه سپردهشدهشان. به عنوان مثال، اگر مبلغ وام حداکثر 30٪ باشد، کاربری که 100 DAI را به پروتکل واریز می کند، می تواند تا 30 DAI دارایی دیگر را وام بگیرد. پروتکل درصد قدرت وام گیری دقیق را تعیین می کند.
+
+همچنان که ارزش وثیقه وام گیرنده نوسان پیدا می کند، قدرت استقراض آنها نیز تغییر می کند. اگر به دلیل نوسانات بازار، ارزش دارایی های قرض گرفته شده بیش از 30٪ ارزش وثیقه آنها باشد (باز هم، درصد دقیق آن توسط پروتکل تعیین می شود)، پروتکل معمولاً به هر کسی اجازه می دهد وثیقه را نقد کند و بلافاصله بدهی وام دهندگان را پرداخت کند (این شبیه نحوه عملکرد [مارجین کال](https://www.investopedia.com/terms/m/margincall.asp) در امور مالی سنتی است). در صورت انحلال، وام گیرنده معمولاً باید هزینه انحلال سنگینی را بپردازد، که بخشی از آن به مدیر تصفیه می رود - جایی که فرصت MEV به وجود می آید.
+
+جستجوگران برای تجزیه و تحلیل داده های بلاک چین در سریع ترین زمان ممکن رقابت می کنند تا تعیین کنند کدام وام گیرندگان می توانند منحل شوند و اولین کسانی باشند که تراکنش انحلال را ارسال می کنند و هزینه انحلال را برای خود دریافت می کنند.
+
+### معامله ساندویچی {#mev-examples-sandwich-trading}
+
+معامله ساندویچی یکی دیگر از روش های رایج استخراج MEV است.
+
+برای ساندویچ کردن، یک جستجوگر استخر حافظه را برای معاملات بزرگ DEX تماشا می کند. به عنوان مثال، فرض کنید شخصی می خواهد 10000 UNI با DAI در Uniswap بخرد. معامله ای به این بزرگی تأثیر مهمی بر جفت UNI/DAI خواهد داشت و به طور بالقوه قیمت UNI را نسبت به DAI افزایش می دهد.
+
+یک جستجوگر می تواند اثر قیمت تقریبی این معامله بزرگ را روی جفت UNI/DAI محاسبه کند و بلافاصله _قبل از_ معامله بزرگ، سفارش خرید بهینه را اجرا کند، UNI را ارزان بخرد، سپس دستور فروش را فوراً _ پس از_ تجارت بزرگ اجرا کند و آن را به قیمت بالاتر ناشی از سفارش بزرگ بفروشد.
+
+با این حال، ساندویچ کردن خطرناک تر است زیرا اتمی نیست (برخلاف آربیتراژ DEX، همانطور که در بالا توضیح داده شد) و مستعد [حمله salmonella ](https://github.com/Defi-Cartel/salmonella) است.
+
+### MEV در NFT {#mev-examples-nfts}
+
+MEV در فضای NFT یک پدیده نوظهور است و لزوماً سودآور نیست.
+
+با این حال، از آنجایی که تراکنشهای NFT روی همان بلاک چین مشترک سایر تراکنشهای اتریوم انجام میشوند، جستجوگران میتوانند از تکنیکهای مشابهی که در فرصتهای سنتی MEV در بازار NFT استفاده میشود، استفاده کنند.
+
+به عنوان مثال، اگر یک افت NFT محبوب وجود داشته باشد و یک جستجوگر یک NFT خاص یا مجموعه ای از NFT ها را بخواهد، می تواند یک تراکنش را طوری برنامه ریزی کند که اولین نفر در صف خرید NFT باشد، یا می تواند کل مجموعه NFT ها را در یک تراکنش خریداری کند. یا اگر یک NFT [به اشتباه با قیمت پایین فهرست شده باشد](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent)، جستجوگر می تواند از سایر خریداران پیشی گرفته و آن را با قیمت ارزان خریداری کند.
+
+یکی از نمونههای برجسته MEV در NFT زمانی رخ داد که یک جستجوگر 7 میلیون دلار برای [خرید](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) هر Cryptopunk در کف قیمت هزینه کرد. یک محقق بلاک چین [در توییتر توضیح داد](https://twitter.com/IvanBogatyy/status/1422232184493121538) چگونه خریدار با یک ارائه دهنده MEV کار می کرد تا خرید خود را مخفی نگه دارد.
+
+### قصه طولانی {#mev-examples-long-tail}
+
+آربیتراژ DEX، انحلال، و معامله ساندویچی همگی فرصت های MEV بسیار شناخته شده ای هستند و بعید است که برای جستجوگران جدید سودآور باشند. با این حال، قصه درازی از فرصت های کمتر شناخته شده MEV وجود دارد (MEV در NFT مسلماً یکی از این فرصت ها است).
+
+جستجوگرانی که به تازگی شروع به کار کرده اند ممکن است بتوانند با جستجوی MEV در این دقصه طولانی موفقیت بیشتری پیدا کنند. بورد کار MEV متعلق به Flashbot برخی از فرصتهای نوظهور را فهرست میکند.
+
+## اثرات MEV {#effects-of-mev}
+
+MEV کلا بد نیست - پیامدهای مثبت و منفی برای MEV روی اتریوم وجود دارد.
+
+### خوب {#effects-of-mev-the-good}
+
+بسیاری از پروژههای DeFi برای اطمینان از سودمندی و پایداری پروتکلهای خود به عوامل منطقی اقتصادی متکی هستند. به عنوان مثال، آربیتراژ DEX تضمین میکند که کاربران بهترین و صحیحترین قیمتها را برای توکنهای خود دریافت میکنند و پروتکلهای وامدهی به انحلال سریع متکی هستند، زمانی که وامگیرندگان کمتر از نسبت وثیقهگذاری میشوند تا اطمینان حاصل شود که وامدهندگان بازپرداخت میکنند.
+
+بدون جستجوگران منطقی که به دنبال و رفع ناکارآمدیهای اقتصادی باشند و از انگیزههای اقتصادی پروتکلها بهره ببرند، پروتکلهای DeFi و به طور کلی ممکن است مانند امروز قوی نباشند.
+
+### بد {#effects-of-mev-the-bad}
+
+در لایه برنامه، برخی از اشکال MEV، مانند معامله ساندویچی، منجر به یک تجربه بدتر برای کاربران می شود. کاربرانی که ساندویچ می شوند با افزایش افت قیمت و اجرای بدتر در معاملات خود مواجه می شوند.
+
+در لایه شبکه، پیشتازان تعمیم یافته و حراج های قیمت گس که اغلب در آن شرکت می کنند (زمانی که دو یا چند نفر پیشتاز برای گنجاندن تراکنش در بلوک بعدی با افزایش تدریجی قیمت گس تراکنش های خود رقابت می کنند) منجر به تراکم شبکه و قیمت بالای گس برای هر کس دیگری میشود که سعی در انجام معاملات منظم دارد.
+
+فراتر از آنچه در _در_ بلوکها اتفاق میافتد، MEV میتواند اثرات مضر _ما بین_ بلوکها داشته باشد. اگر MEV موجود در یک بلوک بهطور قابلتوجهی از پاداش بلوک استاندارد فراتر رود، اعتبارسنج ها ممکن است تشویق شوند تا بلوکها را مجددا سازماندهی کنند و MEV را برای خود بگیرند، که باعث سازماندهی مجدد بلاک چین و بیثباتی اجماع می شود.
+
+این امکان سازماندهی مجدد بلاکچین [قبلاً در بلاک چین بیتکوین بررسی شده است](https://dl.acm.org/doi/10.1145/2976749.2978408). از آنجایی که پاداش بلاک بیتکوین به نصف میرسد و کارمزد تراکنشها بخش بزرگتر و بیشتری از پاداش بلوک را تشکیل میدهند، شرایطی پیش میآید که از نظر اقتصادی منطقی میشود که استخراجکنندگان از پاداش بلوک بعدی صرفنظر کنند و در عوض بلوکهای گذشته را با کارمزد بالاتر یادآوری کنند. با رشد MEV، وضعیت مشابهی ممکن است در اتریوم رخ دهد و یکپارچگی بلاک چین را تهدید کند.
+
+## حالت MEV {#state-of-mev}
+
+استخراج MEV در اوایل سال 2021 افزایش یافت و منجر به قیمت بسیار بالای گس در چند ماه اول سال شد. ظهور رله MEV متعلق به Flashbots اثربخشی پیشتازان عمومی را کاهش داده و حراج قیمت گس را از زنجیره خارج کرده و قیمت گس را برای کاربران عادی کاهش داده است.
+
+در حالی که بسیاری از جستجوگران هنوز از MEV درآمد خوبی کسب می کنند، با شناخته شدن فرصت ها و رقابت جستجوگران بیشتر و بیشتر برای فرصت های مشابه، اعتبار سنج ها درآمد کل MEV بیشتری را به دست خواهند آورد (زیرا همان نوع حراج گس که در ابتدا در بالا توضیح داده شد. در Flashbots نیز اتفاق می افتد، البته به صورت خصوصی، و اعتبار سنج ها درآمد حاصل از گس را دریافت می کنند). MEV نیز منحصر به اتریوم نیست و با رقابتی شدن فرصت ها در اتریوم، جستجوگران به سمت بلاک چین های جایگزین مانند زنجیره هوشمند بایننس حرکت می کنند، جایی که فرصت های MEV مشابه با اتریوم با رقابت کمتری وجود دارد.
+
+از سوی دیگر، انتقال از اثبات کار به اثبات سهام و تلاش مداوم برای مقیاسبندی اتریوم با استفاده از جمعآوریها، همگی چشمانداز MEV را به روشهایی تغییر میدهند که هنوز تا حدودی نامشخص است. هنوز به خوبی شناخته نشده است که چگونه داشتن پیشنهاد دهندگان بلوک تضمین شده که از قبل کمی شناخته شده اند، دینامیک استخراج MEV را در مقایسه با مدل احتمالی در اثبات کار تغییر می دهد یا چگونه این امر هنگام [انتخاب رهبر مخفی منفرد0 مختل می شود ](https://ethresear.ch/t/secret-non-single-leader-election/11789) و [فناوری اعتبارسنج توزیع شده](/staking/dvt/) پیاده سازی می شود. به طور مشابه، باید دید چه فرصتهای MEV زمانی وجود دارد که بیشتر فعالیتهای کاربر از اتریوم خارج میشوند و روی رولآپ های لایه 2 و شاردهای آن منتقل میشوند.
+
+## MEV در اثبات سهام اتریوم (PoS) {#mev-in-ethereum-proof-of-stake}
+
+همانطور که توضیح داده شد، MEV پیامدهای منفی برای تجربه کلی کاربر و امنیت لایه اجماع دارد. اما انتقال اتریوم به اجماع اثبات سهام (معروف به "ادغام") به طور بالقوه خطرات جدید مرتبط با MEV را معرفی می کند:
+
+### تمرکزگرایی اعتبارسنج {#validator-centralization}
+
+در اتریوم پس از ادغام، اعتبارسنج ها (با سپرده گذاری امنیتی 32 اتریوم) در مورد اعتبار بلوک های اضافه شده به زنجیره بیکن اتفاق نظر دارند. از آنجایی که 32 ETH ممکن است از دسترس بسیاری خارج باشد، [پیوستن به یک استخر سهام](/staking/pools/) ممکن است گزینه عملی تری باشد. با این وجود، توزیع سالم [سهامگذاران انفرادی](/staking/solo/) ایده آل است، زیرا تمرکز اعتبارسنج ها را کاهش می دهد و امنیت اتریوم را بهبود می بخشد.
+
+با این حال، اعتقاد بر این است که استخراج MEV قادر به تسریع تمرکز اعتبارسنج است. این تا حدی به این دلیل است که اعتبارسنج ها [درآمد کمتری برای پیشنهاد بلوکها ](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) نسبت به ماینرهای قبلی دارند، استخراج MEV از زمان ادغام تا حد زیادی [درآمد اعتبارسنج ها را تحت تأثیر قرار میدهد](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb).
+
+استخرهای بزرگتر سهامگذاری احتمالاً منابع بیشتری برای سرمایه گذاری در بهینه سازی های لازم برای جذب فرصت های MEV خواهند داشت. هرچه این استخرها MEV بیشتری استخراج کنند، منابع بیشتری برای بهبود قابلیتهای استخراج MEV (و افزایش درآمد کلی) دارند، که اساساً [اقتصاد مقیاس](https://www.investopedia.com/terms/e/economiesofscale.asp#) ایجاد میکند.
+
+با منابع کمتری که در اختیار دارند، سهامداران انفرادی ممکن است نتوانند از فرصت های MEV سود ببرند. این ممکن است فشار را بر اعتبارسنج های مستقل برای پیوستن به استخرهای قدرتمند برای افزایش درآمدشان افزایش دهد و تمرکززدایی در اتریوم را کاهش دهد.
+
+### استخرهای حافظه دارای مجوز {#permissioned-mempools}
+
+در پاسخ به حملات ساندویچ و پیشتاز، معامله گران ممکن است شروع به انجام معاملات خارج از زنجیره با اعتبارسنج ها برای حفظ حریم خصوصی تراکنش کنند. معاملهگر به جای ارسال یک تراکنش بالقوه MEV به استخر حافظه عمومی، آن را مستقیماً برای اعتبارسنج ارسال میکند که آن را در یک بلوک قرار میدهد و سود را با معاملهگر تقسیم میکند.
+
+«استخرهای تاریک» نسخه بزرگتری از این ترتیب است و بهعنوان استخرهای حافظه مجاز و فقط قابل دسترسی برای کاربرانی که مایل به پرداخت هزینههای خاصی هستند، عمل میکنند. این روند بی مجوز بودن و عدم اعتماد اتریوم را کاهش می دهد و به طور بالقوه بلاک چین را به مکانیزم «پرداخت برای بازی» تبدیل می کند که به نفع بالاترین پیشنهاد دهنده است.
+
+استخرهای حافظه دارای مجوز همچنین خطرات متمرکزسازی که در بخش قبل توضیح داده شد را تسریع می کنند. استخرهای بزرگی که دارای اعتبارسنج های متعدد هستند، احتمالاً از ارائه حریم خصوصی تراکنش به معامله گران و کاربران سود می برند و درآمد MEV آنها را افزایش می دهند.
+
+مبارزه با این مشکلات مرتبط با MEV در اتریوم پس از ادغام، یک حوزه اصلی تحقیق است. تا به امروز، دو راه حل پیشنهادی برای کاهش تأثیر منفی MEV بر تمرکززدایی و امنیت اتریوم پس از ادغام، **جداسازی پیشنهاد دهنده-سازنده (PBS)** و **API Builder** هستند.
+
+### تفکیک پیشنهاد دهنده و سازنده {#proposer-builder-separation}
+
+هم در اثبات کار و هم در اثبات سهام، گرهی که یک بلوک می سازد، آن را برای اضافه کردن به زنجیره به گره های دیگر شرکت کننده در اجماع پیشنهاد می کند. یک بلوک جدید پس از ساختن یک استخراجگر دیگر در بالای آن (در PoW) یا دریافت تاییدیه از اکثر اعتبارسنج ها (در PoS) بخشی از زنجیره متعارف می شود.
+
+ترکیبی از نقش های سازنده بلوک و پیشنهاد دهنده بلوک چیزی است که بیشتر مشکلات مربوط به MEV را که قبلاً توضیح داده شد معرفی می کند. برای مثال، گرههای اجماع انگیزه ایجاد سازماندهی مجدد زنجیرهای در حملات طولانی برای به حداکثر رساندن درآمد MEV دارند.
+
+[تفکیک پیشنهاد دهنده-سازنده](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) برای کاهش تأثیر MEV، به ویژه در لایه اجماع، طراحی شده است. ویژگی اصلی PBS جداسازی قوانین سازنده بلوک و پیشنهاد دهنده بلوک است. اعتبارسنج ها همچنان مسئول پیشنهاد و رایگیری در مورد بلوکها هستند، اما دسته جدیدی از نهادهای تخصصی به نام **بلوک سازان**، وظیفه سفارش تراکنشها و ساخت بلوکها را بر عهده دارند.
+
+تحت PBS، یک سازنده بلوک یک بسته تراکنش ایجاد می کند و پیشنهادی را برای گنجاندن آن در یک بلوک بیکن چین (به عنوان "بار اجرایی") قرار می دهد. اعتبارسنج انتخاب شده برای پیشنهاد بلوک بعدی، پیشنهادات مختلف را بررسی میکند و بستهای را با بالاترین هزینه انتخاب میکند. PBS اساساً یک بازار حراج ایجاد می کند، جایی که سازندگان با اعتبارسنج هایی که فضای بلوک را می فروشند، مذاکره می کنند.
+
+طرحهای فعلی PBS از یک [طرح آشکارسازی تعهد](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) استفاده میکنند که در آن سازندگان فقط یک تعهد رمزنگاری به محتویات یک بلوک (سر بلوک) را همراه با پیشنهادات خود منتشر میکنند. پس از پذیرش پیشنهاد برنده، پیشنهاد دهنده یک پیشنهاد بلوک امضا شده ایجاد می کند که شامل سر بلوک است. انتظار میرود سازنده بلوک پس از مشاهده طرح بلوک امضاشده، متن کامل بلوک را منتشر کند، و همچنین باید قبل از نهایی شدن، [تأییدکنندههای](/glossary/#attestation) کافی از اعتبارسنج ها دریافت کند.
+
+#### چگونه جداسازی پیشنهاد دهنده و سازنده تأثیر MEV را کاهش می دهد؟ {#how-does-pbs-curb-mev-impact}
+
+جداسازی پیشنهاد دهنده-سازنده درون پروتکل، با حذف استخراج MEV از حوزه اعتبارسنج ها، اثر MEV بر اجماع را کاهش میدهد. در عوض، سازندگان بلوک که سختافزار تخصصی را اجرا میکنند، فرصتهای MEV را در آینده به دست خواهند آورد.
+
+این امر اعتبارسنج ها را بهطور کامل از درآمد مرتبط با MEV مستثنی نمیکند، زیرا سازندگان باید برای پذیرش بلوکهایشان توسط اعتبارسنج ها، قیمت بالایی داشته باشند. با این وجود، با توجه به اینکه اعتبارسنج ها دیگر مستقیماً بر روی بهینهسازی درآمد MEV تمرکز نمیکنند، تهدید حملات طولانی کاهش مییابد.
+
+جداسازی پیشنهاد دهنده-سازنده همچنین خطرات متمرکزسازی MEV را کاهش می دهد. به عنوان مثال، استفاده از یک طرح تعهد-افشا، نیاز سازندگان را به اعتماد به اعتبارسنج ها برای ربودن فرصت MEV یا افشای آن در معرض سایر سازندگان از بین میبرد. این امر مانع سود سهامداران انفرادی از MEV را کاهش می دهد، در غیر این صورت، سازندگان به طرفداری از استخرهای بزرگ با شهرت خارج از زنجیره و انجام معاملات خارج از زنجیره با آنها گرایش پیدا می کنند.
+
+به طور مشابه، اعتبارسنج ها مجبور نیستند به سازندگان بلوک اعتماد کنند که بدنه های بلوک را پس نمیکشند یا بلوک های نامعتبر را منتشر نمی کنند زیرا پرداخت بدون قید و شرط است. حتی اگر بلوک پیشنهادی در دسترس نباشد یا توسط اعتبارسنجی دیگر نامعتبر اعلام شود، هزینه اعتبارسنج همچنان پردازش میکند. در مورد دوم، بلوک به سادگی دور ریخته می شود و سازنده بلوک را مجبور می کند که تمام هزینه های تراکنش و درآمد MEV را از دست بدهد.
+
+### API سازندهی بلوک {#builder-api}
+
+در حالی که جداسازی پیشنهاد دهنده و سازنده وعده کاهش اثرات استخراج MEV را می دهد، اجرای آن نیازمند تغییراتی در پروتکل اجماع است. به طور خاص، قانون [انتخاب فورک](/developers/docs/consensus-mechanisms/pos/#fork-choice) در بیکن چین باید به روز شود. [API سازنده بلوک](https://github.com/ethereum/builder-specs) یک راه حل موقت است که با هدف ارائه پیاده سازی کاری جداسازی پیشنهاد دهنده-سازنده، البته با مفروضات اعتماد بالاتر است.
+
+API سازنده بلوک نسخه اصلاح شده [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) است که توسط کلاینت های لایه اجماع برای درخواست بارهای اجرایی از کلاینت های لایه اجرا استفاده می شود. همانطور که در [مشخصات اعتبارسنج صادق](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) مشخص شده است، اعتبارسنجی هایی که برای وظایف پیشنهادی بلوک انتخاب میشوند، یک بسته تراکنش را از یک کلاینت اجرا که متصل است درخواست میکنند که آن را در بلوک پیشنهادی بیکن چین قرار میدهند.
+
+API سازنده بلوک همچنین به عنوان یک میان افزار بین اعتبارسنج و کلاینت های لایه اجرا عمل می کند. اما متفاوت است زیرا به اعتبارسنج های موجود در بیکن چین اجازه میدهد تا بلوکها را از موجودیتهای خارجی تهیه کنند (بهجای ساختن یک بلوک به صورت محلی با استفاده از یک کلاینت اجرا).
+
+در زیر یک نمای کلی از نحوه عملکرد API سازنده بلوک آورده شده است:
+
+1. Builder API اعتبارسنج را به شبکه ای از سازنده های بلوک که کلاینت های لایه اجرا را اجرا می کنند متصل می کند. مانند PBS، سازندگان بلوک نیز طرف های تخصصی هستند که در بلوکسازی با منابع فشرده سرمایهگذاری میکنند و از استراتژیهای مختلف برای به حداکثر رساندن درآمد حاصل از MEV به علاوه ترفند های اولویت بندی استفاده میکنند.
+
+2. یک اعتبارسنج (که یک کلاینت لایه اجماع را اجرا می کند) بارهای اجرایی را به همراه پیشنهادات از شبکه سازندگان درخواست می کند. پیشنهادهای سازنده شامل سرفصل بار اجرایی - تعهد رمزنگاری به محتویات بار - و هزینه ای است که باید به اعتبارسنج پرداخت شود.
+
+3. اعتبارسنج پیشنهادهای دریافتی را بررسی میکند و بار اجرایی را با بالاترین هزینه انتخاب میکند. با استفاده از API سازنده، اعتبارسنج یک پیشنهاد بلوک "کور" در بیکن ایجاد می کند که فقط شامل امضای آنها و سر پرداخت اجرا می شود و آن را برای سازنده ارسال می کند.
+
+4. سازندهای که API سازنده را اجرا میکند، انتظار میرود که با مشاهده پیشنهاد بلوک کور، با بار اجرایی کامل پاسخ دهد. این به اعتبارسنج اجازه می دهد تا یک بلوک بیکن "امضا" شده ایجاد کند که در سراسر شبکه منتشر می شود.
+
+5. هنوز انتظار میرود که اعتبارسنج با استفاده از API سازنده، در صورتی که سازنده بلوک به سرعت پاسخ ندهد، یک بلوک را به صورت محلی بسازد، بنابراین پاداشهای پیشنهاد بلوک را از دست نمیدهند. با این حال، اعتبارسنج نمیتواند بلوک دیگری را با استفاده از تراکنشهای آشکار شده یا مجموعهای دیگر ایجاد کند، زیرا به معنای _مبهم سازی_ (امضا کردن دو بلوک در یک اسلات) است، که یک جرم قابل جریمه شدن است.
+
+یک نمونه از پیادهسازی API سازنده همین [MEV Boost](https://github.com/flashbots/mev-boost) است، یک بهینه سازی در [مکانیسم حراج فلشباتها](https://docs.flashbots.net/Flashbots-auction/overview/) که برای مهار اثرات جانبی منفی MEV در اتریوم طراحی شده است. حراج Flashbots به اعتبارسنج ها در اثبات سهام اجازه می دهد تا کار ساخت بلوک های سودآور را به طرف های تخصصی به نام **جستجوگرها** برون سپاری کنند.
+
+جستجوگران به دنبال فرصتهای سودآور MEV میگردند و بستههای تراکنش را برای مسدود کردن پیشنهادکنندگان همراه با [مناقصه با قیمت مهر و موم شده](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) برای درج در بلوک ارسال میکنند. اعتباردهندهای که mev-geth را اجرا میکند، یک نسخه فورک شده از کلاینت go-ethereum (Geth) فقط باید بستهای را انتخاب کند که بیشترین سود را دارد و آن را به عنوان بخشی از بلوک جدید قرار دهد. برای محافظت از پیشنهاد دهندگان بلوک (اعتبارسنج ها) در برابر هرزنامه و تراکنشهای نامعتبر، بستههای تراکنش قبل از رسیدن به پیشنهاددهنده از **relayerها** برای اعتبارسنجی عبور میکنند.
+
+MEV Boost همان حراج Flashbots اصلی را حفظ می کند، البته با ویژگی های جدیدی که برای تغییر اتریوم به اثبات سهام طراحی شده است. جستجوگران هنوز تراکنشهای سودآور MEV را برای گنجاندن در بلوکها پیدا میکنند، اما دسته جدیدی از طرفهای تخصصی به نام **سازندگان بلوک** مسئول جمعآوری تراکنشها و بستهها در بلوکها هستند. سازنده پیشنهادات قیمت مهر و موم شده را از جستجوگران می پذیرد و بهینه سازی هایی را برای یافتن سودآورترین سفارش اجرا می کند.
+
+رله همچنان مسئول اعتبارسنجی بسته های تراکنش قبل از ارسال آنها به پیشنهاد دهنده است. با این حال، MEV Boost در این حین **scrows** را معرفی میکند که مسئول ارائه [در دسترس بودن دادهها](/developers/docs/data-availability/) با ذخیره بدنههای بلوک ارسال شده توسط سازندهها و سرهای بلوک ارسال شده توسط اعتبارسنج ها هستند. در اینجا، یک اعتبارسنج متصل به یک رله، بارهای اجرایی موجود را میپرسد و از الگوریتم سفارش MEV Boost برای انتخاب سر بار پرداخت با بالاترین پیشنهاد + نکات MEV استفاده میکند.
+
+#### چگونه API سازنده تأثیر MEV را کاهش می دهد؟ {#how-does-builder-api-curb-mev-impact}
+
+مزیت اصلی API سازنده پتانسیل آن برای دموکراتیک کردن دسترسی به فرصت های MEV است. استفاده از طرحهای commit-reveal مفروضات اعتماد را حذف میکند و موانع ورود را برای اعتبارسنج ها که به دنبال بهرهمندی از MEV هستند کاهش میدهد. این باید فشار روی سهامگذاران انفرادی را برای ادغام با استخرهای بزرگ به منظور افزایش سود MEV کاهش دهد.
+
+اجرای گسترده API سازنده رقابت بیشتر بین سازندگان بلوک را تشویق می کند که مقاومت در برابر سانسور را افزایش می دهد. از آنجایی که اعتبارسنج ها پیشنهادهای سازندههای متعدد را بررسی میکنند، سازندهای که قصد سانسور یک یا چند تراکنش کاربر را دارد باید از همه سازندگان غیرسانسورکننده دیگر پیشی بگیرد تا موفق شود. این به طور چشمگیری هزینه سانسور کاربران را افزایش می دهد و این عمل را دلسرد می کند.
+
+برخی از پروژهها، مانند MEV Boost، از API سازنده به عنوان بخشی از ساختار کلی استفاده میکنند که برای ارائه حریم خصوصی تراکنشها به برخی از طرفها طراحی شده است، مانند معاملهگرانی که سعی میکنند از حملات پیشتازی/ ساندویچ اجتناب کنند. این با ارائه یک کانال ارتباطی خصوصی بین کاربران و سازندگان بلوک به دست می آید. برخلاف استخرهای حافظه دارای مجوز که قبلا توضیح داده شد، این رویکرد به دلایل زیر سودمند است:
+
+1. وجود سازنده های متعدد در بازار سانسور را غیرعملی می کند که به نفع کاربران است. در مقابل، وجود استخرهای تاریک متمرکز و مبتنی بر اعتماد، قدرت را در دستان معدود سازندگان بلوک متمرکز میکند و امکان سانسور را افزایش میدهد.
+
+2. نرم افزار API سازنده منبع باز است که به هر کسی اجازه می دهد خدمات سازنده بلوک را ارائه دهد. این بدان معناست که کاربران مجبور به استفاده از بلوکساز خاصی نیستند و بیطرفی و عدم مجوزمحوری اتریوم را بهبود میبخشد. علاوه بر این، معاملهگرانی که به دنبال MEV هستند، سهواً با استفاده از کانالهای تراکنش خصوصی، به متمرکزسازی کمک نمیکنند.
+
+## منابع مرتبط {#related-resources}
+
+- [اسناد Flashbotها](https://docs.flashbots.net/)
+- [گیتهاب Flashbotها](https://github.com/flashbots/pm)
+- [MEV-Explore](https://explore.flashbots.net/) - _داشبورد و کاوشگر تراکنش زنده برای تراکنشهای MEV_
+- [mevboost.org](https://www.mevboost.org/) - _ردیاب با آمار بیدرنگ برای رلههای MEV-Boost و سازندگان بلوک_
+
+## بیشتر بخوانید {#further-reading}
+
+- [ارزش قابل استخراج استخراجگر (MEV) چیست؟](https://blog.chain.link/what-is-miner-extractable-value-mev/)
+- [MEV و Me](https://www.paradigm.xyz/2021/02/mev-and-me)
+- [اتریوم یک جنگل تاریک است](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/)
+- [فرار از جنگل تاریک](https://samczsun.com/escaping-the-dark-forest/)
+- [Flashbotها: فرار رو به جلو در بحران MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752)
+- [@bertcmiller's MEV Threads](https://twitter.com/bertcmiller/status/1402665992422047747)
+- [MEV-Boost: معماری Flashbots آماده ادغام](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
+- [MEV Boost چیست؟](https://www.alchemy.com/overviews/mev-boost)
+- [چرا mev-boost را اجرا کنید؟](https://writings.flashbots.net/writings/why-run-mevboost/)
+- [راهنمای سفر به اتریوم](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md
new file mode 100644
index 00000000000..64c34080230
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md
@@ -0,0 +1,433 @@
+---
+title: Oracles
+description: اوراکلها قراردادهای هوشمند اتریوم را با دسترسی به دادههای دنیای واقعی، باز کردن موارد استفاده بیشتر و ارزش بیشتر برای کاربران فراهم میکند.
+lang: fa
+---
+
+اوراکلها برنامههایی هستند که فیدهای داده تولید میکنند که منابع داده خارج از زنجیره را برای قراردادهای هوشمند در دسترس بلاکچین قرار میدهند. این امر ضروری است زیرا قراردادهای هوشمند مبتنی بر اتریوم به طور پیش فرض نمیتوانند به اطلاعات ذخیره شده خارج از شبکه بلاکچین دسترسی داشته باشند.
+
+دادن قابلیت اجرای قراردادهای هوشمند با استفاده از دادههای خارج از زنجیره، کاربرد و ارزش برنامههای غیرمتمرکز را گسترش میدهد. به عنوان مثال، بازارهای پیشبینی زنجیرهای به اوراکلها برای ارائه اطلاعاتی درباره نتایجی که برای اعتبارسنجی پیشبینیهای کاربر استفاده میکنند، متکی هستند. فرض کنید آلیس 20 ETH بر روی این که چه کسی رئیس جمهور آینده ایالات متحده آمریکا خواهد شد، شرط ببندد. در آن صورت، پیشبینی بازار به یک اوراکل برای تأیید نتایج انتخابات و تعیین اینکه آیا آلیس (Alice) واجد شرایط پرداخت است یا خیر، نیاز دارد.
+
+## موارد مورد نیاز {#prerequisites}
+
+این صفحه فرض میکند که خواننده با مفاهیم پایه اتریوم از جمله [گرهها](/developers/docs/nodes-and-clients/)، [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) و [ماشین مجازی اتریوم یا EVM](/developers/docs/evm/) آشنا میباشد. همچنین شما باید درک خوبی از [قراردادهای هوشمند](/developers/docs/smart-contracts/) و [ساختار قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/)، مخصوصاً [رویدادها](/glossary/#events) داشته باشید.
+
+## اوراکل بلاکچین چیست؟ {#what-is-a-blockchain-oracle}
+
+اوراکلها برنامههایی هستند که اطلاعات خارجی (یعنی اطلاعات ذخیره شده خارج از زنجیره) را به قراردادهای هوشمند در حال اجرا بر روی بلاکچین منبع، تأیید و انتقال میدهند. علاوه بر «پول کردن» دادههای خارج از زنجیره و پخش آن در اتریوم، اوراکلها همچنین میتوانند اطلاعات را از بلاکچین به سیستمهای خارجی «پوش» کنند، بهعنوان مثال، زمانی که کاربر هزینهای را از طریق تراکنش اتریوم ارسال میکند، قفل هوشمند را باز کند.
+
+بدون اوراکل، یک قرارداد هوشمند به طور کامل به دادههای زنجیرهای محدود میشود.
+
+اوراکلها بر اساس منبع دادهها (یک یا چند منبع)، مدلهای قابل اعتماد (متمرکز یا غیرمتمرکز)، و معماری سیستم (خواندن فوری، انتشار، اشتراک، و درخواست-پاسخ) متفاوت هستند. ما همچنین میتوانیم بین اوراکلها تمایز قائل شویم که آیا آنها دادههای خارجی را برای استفاده توسط قراردادهای روی زنجیره (اوراکلهای ورودی) بازیابی میکنند، اطلاعات را از زنجیره بلاک به برنامههای خارج از زنجیره (اوراکلهای خروجی) ارسال میکنند یا وظایف محاسباتی را خارج از زنجیره انجام میدهند (اوراکلهای محاسباتی).
+
+## چرا قراردادهای هوشمند به اوراکل نیاز دارند؟ {#why-do-smart-contracts-need-oracles}
+
+بسیاری از توسعه دهندگان قراردادهای هوشمند را به عنوان کدی می بینند که در آدرسهای خاصی در بلاکچین اجرا میشود. با این حال، [دیدگاه کلیتر قراردادهای هوشمند](/smart-contracts/) این است که آنها برنامههای نرمافزاری خود-اجرای هستند که قادر به اجرای توافقات بین طرفین پس از برآورده شدن شرایط خاص هستند - از این رو به این اصطلاح قراردادهای هوشمند میگوییم.»
+
+اما استفاده از قراردادهای هوشمند برای اجرای توافقات بین افراد، با توجه به اینکه اتریوم قطعی است، ساده نیست. یک [سیستم قطعی](https://en.wikipedia.org/wiki/Deterministic_algorithm) سیستمی است که همیشه نتایج یکسانی را با توجه به وضعیت اولیه و یک ورودی خاص تولید میکند، به این معنی که تصادفی یا تغییر در فرآیند محاسبه خروجیها از ورودی ها وجود ندارد.
+
+برای دستیابی به اجرای قطعی، بلاک چینها گرهها را به اجماع در مورد سؤالات باینری ساده (درست/نادرست) با استفاده از _فقط_ دادههای ذخیره شده در خود بلاک چین محدود میکنند. نمونههایی از این گونه سوالات عبارتند از:
+
+- "آیا مالک حساب (که با یک کلید عمومی مشخص میشود) این تراکنش را با کلید خصوصی جفت شده امضا کرده است؟"
+- "آیا این حساب دارای وجوه کافی برای پوشش تراکنش است؟"
+- «آیا این معامله در چارچوب این قرارداد هوشمند معتبر است؟» و غیره.
+
+اگر بلاکچینها اطلاعاتی را از منابع خارجی (یعنی از دنیای واقعی) دریافت میکردند، دستیابی به جبر غیرممکن خواهد بود و از توافق گرهها در مورد اعتبار تغییرات در وضعیت بلاک چین جلوگیری میکند. به عنوان مثال یک قرارداد هوشمند را در نظر بگیرید که یک تراکنش را بر اساس نرخ ارز فعلی اتر-USD به دست آمده از یک API قیمت سنتی انجام میدهد. این رقم احتمالاً اغلب تغییر میکند (غیر از اینکه API ممکن است منسوخ یا هک شود)، به این معنی که گره یا همان نودهایی که کد قرارداد یکسانی را اجرا میکنند به نتایج متفاوتی میرسند.
+
+برای یک بلاک چین عمومی مانند اتریوم، با هزاران گره در سراسر جهان که تراکنشها را پردازش میکنند، جبرگرایی بسیار مهم است. بدون هیچ مرجع مرکزی به عنوان منبع حقیقت، گرهها به مکانیزمهایی برای رسیدن به همان حالت پس از اعمال همان تراکنشها نیاز دارند. موردی که به موجب آن گره یا نود A کد قرارداد هوشمند را اجرا میکند و در نتیجه "3" دریافت میکند، در حالی که گره یا نود B پس از اجرای همان تراکنش، "7" را دریافت میکند، باعث میشود اجماع از بین برود و ارزش اتریوم به عنوان یک پلتفرم محاسباتی غیرمتمرکز را حذف کند.
+
+این سناریو همچنین مشکل طراحی بلاکچین برای استخراج اطلاعات از منابع خارجی را مطرح میکند. با این حال، اوراکل این مشکل را با گرفتن اطلاعات از منابع خارج از زنجیره و ذخیره آن در بلاکچین برای مصرف قراردادهای هوشمند حل میکند. از آنجایی که اطلاعات ذخیره شده در زنجیره غیرقابل تغییر و در دسترس عموم است، گره یا نودهای اتریوم میتوانند با خیال راحت از دادههای خارج از زنجیره وارد شده اوراکل برای محاسبه تغییرات حالت بدون اجماع استفاده کنند.
+
+برای انجام این کار، اوراکل معمولاً از یک قرارداد هوشمند در حال اجرا بر روی زنجیره و برخی از اجزای خارج از زنجیره تشکیل شده است. قرارداد روی زنجیره درخواستهایی برای دادهها از سایر قراردادهای هوشمند دریافت میکند، که آنها را به جزء خارج از زنجیره (به نام گره اوراکل) ارسال میکند. این گره یا نود اوراکل میتواند منابع داده را جستجو کند - برای مثال با استفاده از رابطهای برنامهنویسی کاربردی (API) - و تراکنشهایی را برای ذخیره دادههای درخواستی در فضای ذخیرهسازی قرارداد هوشمند ارسال کند.
+
+اساساً یک اوراکل بلاک چین، شکاف اطلاعاتی بین بلاک چین و محیط خارجی را پر کرده و "قراردادهای هوشمند ترکیبی" ایجاد میکند. قرارداد هوشمند ترکیبی قراردادی است که بر اساس ترکیبی از کد قرارداد درون زنجیرهای و زیرساخت خارج از زنجیره عمل میکند. بازارهای پیشبینی غیرمتمرکز نمونهای عالی از قراردادهای هوشمند ترکیبی هستند. نمونههای دیگر ممکن است شامل قراردادهای هوشمند بیمه محصولات باشد که زمانی پرداخت میشوند که مجموعهای از اوراکلها تشخیص دهند که پدیدههای آب و هوایی خاصی رخ داده است.
+
+## مشکل اوراکل چیست؟ {#the-oracle-problem}
+
+اوراکلها یک مشکل مهم را حل میکنند، اما برخی از عوارض را نیز معرفی میکنند، به عنوان مثال:
+
+- چگونه بررسی کنیم که اطلاعات وارد شده از منبع صحیح استخراج شده یا دستکاری نشده است؟
+
+- چگونه اطمینان حاصل کنیم که این دادهها همیشه در دسترس هستند و به طور منظم به روز میشوند؟
+
+به اصطلاح "مشکل اوراکل" مشکلاتی را که با استفاده از اوراکلهای بلاک چین برای ارسال ورودی به قراردادهای هوشمند به وجود میآید را نشان میدهد. برای اجرای صحیح قرارداد هوشمند، دادههای اوراکل باید صحیح باشد. علاوه بر این، نیاز به «اعتماد» به اپراتورهای اوراکل برای ارائه اطلاعات دقیق، جنبه «بدون نیاز به اعتماد» قراردادهای هوشمند را تضعیف میکند.
+
+اوراکلهای مختلف راهحلهای متفاوتی برای مشکل اوراکل ارائه میکنند که در ادامه به بررسی آنها میپردازیم. اوراکلها معمولاً بر این اساس ارزیابی میشوند که چگونه میتوانند چالشهای زیر را مدیریت کنند:
+
+1. **صحت**: اوراکل نباید باعث شود که قراردادهای هوشمند تغییرات حالت را بر اساس دادههای خارج از زنجیره نامعتبر ایجاد کنند. اوراکل باید _اصالت_ و _یکپارچگی_ دادهها را تضمین کند. اصالت به این معنی است که دادهها از منبع صحیح دریافت شدهاند، در حالی که یکپارچگی به این معنی است که دادهها قبل از ارسال روی زنجیره دست نخورده باقی ماندهاند (یعنی تغییر نکردهاند).
+
+2. **در دسترس بودن**: اوراکل نباید قراردادهای هوشمند را از اجرای اقدامات و ایجاد تغییرات حالت به تاخیر بیاندازد یا از آن جلوگیری کند. این بدان معناست که دادههای یک اوراکل باید بدون وقفه _در صورت درخواست در دسترس باشد_.
+
+3. **سازگاری انگیزه**: اوراکل باید ارائه دهندگان دادههای خارج از زنجیره را تشویق کند تا اطلاعات صحیح را به قراردادهای هوشمند ارسال کنند. سازگاری انگیزه شامل _قابلیت انتساب_ و _پاسخگویی_ است. قابلیت انتساب امکان پیوند بخشی از اطلاعات خارجی را به ارائهدهنده آن فراهم میکند، در حالی که مسئولیتپذیری ارائهدهندگان دادهها را به اطلاعاتی که میدهند پیوند میدهد، بنابراین میتوانند بر اساس کیفیت اطلاعات ارائهشده پاداش یا جریمه شوند.
+
+## سرویس اوراکل بلاک چین چگونه کار میکند؟ {#how-does-a-blockchain-oracle-service-work}
+
+### کاربران {#users}
+
+کاربران موجودیتهایی (یعنی قراردادهای هوشمند) هستند که برای انجام اقدامات خاص به اطلاعات خارج از بلاک چین نیاز دارند. گردش کار اصلی یک سرویس اوراکل با ارسال درخواست داده توسط کاربر به قرارداد اوراکل شروع میشود. درخواستهای داده معمولاً به برخی یا همه سؤالات زیر پاسخ میدهند:
+
+1. گرههای خارج از زنجیره میتوانند برای اطلاعات درخواستی از چه منابعی استفاده کنند؟
+
+2. گزارشگران چگونه اطلاعات را از منابع داده پردازش میکنند و نقاط داده مفید را استخراج میکنند؟
+
+3. چه تعداد گره یا نود اوراکل میتوانند در بازیابی دادهها شرکت کنند؟
+
+4. چگونه باید مغایرتهای گزارشهای اوراکل را مدیریت کرد؟
+
+5. چه روشی باید در فیلتر کردن مطالب ارسالی و تجمیع گزارشها در یک مقدار واحد اجرا شود؟
+
+### قرارداد اوراکل {#oracle-contract}
+
+قرارداد اوراکل جزء زنجیرهای برای سرویس اوراکل است. به درخواستهای داده از قراردادهای دیگر گوش میدهد، پرس و جوهای داده را به گرههای اوراکل رله کرده و دادههای برگشتی را به قراردادهای کلاینت پخش میکند. این قرارداد همچنین ممکن است برخی از محاسبات را روی نقاط داده برگشتی انجام دهد تا یک مقدار مجموع برای ارسال به قرارداد درخواست کننده ایجاد کند.
+
+قرارداد اوراکل برخی از توابع را نشان میدهد که قراردادهای کلاینت هنگام درخواست داده آنها را فراخوانی میکنند. پس از دریافت یک درخواست جدید، قرارداد هوشمند یک [رویداد گزارش یا همان ایونت لاگ](/developers/docs/smart-contracts/anatomy/#events-and-logs) را با جزئیات درخواست داده ارسال میکند. این مورد به گرههای خارج از زنجیره مشترک در گزارش (معمولاً از چیزی مانند دستور JSON-RPC `eth_subscribe` استفاده میکند)، که به بازیابی دادههای تعریفشده در رویداد لاگ میپردازند.
+
+در زیر یک [نمونه قرارداد اوراکل](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) توسط پدرو کاستا آمده است. این یک سرویس اوراکل ساده است که میتواند در صورت درخواست سایر قراردادهای هوشمند، APIهای خارج از زنجیره را جستجو کند و اطلاعات درخواستی را در زنجیره بلوکی ذخیره کند:
+
+```solidity
+pragma solidity >=0.4.21 <0.6.0;
+
+contract Oracle {
+ Request[] requests; //list of requests made to the contract
+ uint currentId = 0; //increasing request id
+ uint minQuorum = 2; //minimum number of responses to receive before declaring final result
+ uint totalOracleCount = 3; // Hardcoded oracle count
+
+ // defines a general api request
+ struct Request {
+ uint id; //request id
+ string urlToQuery; //API url
+ string attributeToFetch; //json attribute (key) to retrieve in the response
+ string agreedValue; //value from key
+ mapping(uint => string) answers; //answers provided by the oracles
+ mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted)
+ }
+
+ //event that triggers oracle outside of the blockchain
+ event NewRequest (
+ uint id,
+ string urlToQuery,
+ string attributeToFetch
+ );
+
+ //triggered when there's a consensus on the final result
+ event UpdatedRequest (
+ uint id,
+ string urlToQuery,
+ string attributeToFetch,
+ string agreedValue
+ );
+
+ function createRequest (
+ string memory _urlToQuery,
+ string memory _attributeToFetch
+ )
+ public
+ {
+ uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
+ Request storage r = requests[length-1];
+
+ // Hardcoded oracles address
+ r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
+ r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
+ r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
+
+ // launch an event to be detected by oracle outside of blockchain
+ emit NewRequest (
+ currentId,
+ _urlToQuery,
+ _attributeToFetch
+ );
+
+ // increase request id
+ currentId++;
+ }
+
+ //called by the oracle to record its answer
+ function updateRequest (
+ uint _id,
+ string memory _valueRetrieved
+ ) public {
+
+ Request storage currRequest = requests[_id];
+
+ //check if oracle is in the list of trusted oracles
+ //and if the oracle hasn't voted yet
+ if(currRequest.quorum[address(msg.sender)] == 1){
+
+ //marking that this address has voted
+ currRequest.quorum[msg.sender] = 2;
+
+ //iterate through "array" of answers until a position if free and save the retrieved value
+ uint tmpI = 0;
+ bool found = false;
+ while(!found) {
+ //find first empty slot
+ if(bytes(currRequest.answers[tmpI]).length == 0){
+ found = true;
+ currRequest.answers[tmpI] = _valueRetrieved;
+ }
+ tmpI++;
+ }
+
+ uint currentQuorum = 0;
+
+ //iterate through oracle list and check if enough oracles(minimum quorum)
+ //have voted the same answer as the current one
+ for(uint i = 0; i < totalOracleCount; i++){
+ bytes memory a = bytes(currRequest.answers[i]);
+ bytes memory b = bytes(_valueRetrieved);
+
+ if(keccak256(a) == keccak256(b)){
+ currentQuorum++;
+ if(currentQuorum >= minQuorum){
+ currRequest.agreedValue = _valueRetrieved;
+ emit UpdatedRequest (
+ currRequest.id,
+ currRequest.urlToQuery,
+ currRequest.attributeToFetch,
+ currRequest.agreedValue
+ );
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+### گره یا نودهای اوراکل {#oracle-nodes}
+
+گره یا نود اوراکل جزء خارج از زنجیره سرویس اوراکل است. این اطلاعات را از منابع خارجی، مانند APIهای میزبانی شده در سرورهای شخص ثالث استخراج میکند و آن را برای مصرف قراردادهای هوشمند در زنجیره قرار میدهد. گره یا نودهای اوراکل به رویدادهای قرارداد اوراکل روی زنجیره گوش میدهند و به تکمیل کار توضیح داده شده در گزارش ادامه میدهند.
+
+یک کار رایج برای نودهای اوراکل ارسال یک درخواست [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) به یک سرویس API، تجزیه پاسخ برای استخراج دادههای مرتبط است. فرمت کردن به یک خروجی قابل خواندن از طریق بلاک چین و ارسال آن در زنجیره (آنچین) با گنجاندن آن در تراکنش به قرارداد اوراکل است. همچنین ممکن است به گره یا نود اوراکل نیاز باشد تا اعتبار و یکپارچگی اطلاعات ارسالی را با استفاده از «اثبات اصالت» تأیید کند، که بعداً بررسی خواهیم کرد.
+
+اوراکلهای محاسباتی همچنین به گره یا نودهای خارج از زنجیره برای انجام وظایف محاسباتی متکی هستند که با توجه به هزینههای گس و محدودیت اندازه بلوک، اجرای آنها در زنجیره غیرعملی است. به عنوان مثال، گره یا نود اوراکل ممکن است وظیفه تولید یک رقم تصادفی قابل تأیید را داشته باشد (به عنوان مثال، برای بازیهای مبتنی بر بلاکچین).
+
+## الگوهای طراحی اوراکل {#oracle-design-patterns}
+
+اوراکلها انواع مختلفی دارند، از جمله _خواندن فوری_، _publish-subscribe_، و _Request-Response_، که دو مورد اخیر محبوبترین در میان قراردادهای هوشمند اتریوم هستند. در اینجا به طور خلاصه مدلهای انتشار-اشتراک و درخواست-پاسخ را توضیح میدهیم.
+
+### اوراکلهای انتشار و اشتراک {#publish-subscribe-oracles}
+
+این نوع اوراکل یک "فید داده" را در معرض دید قرار میدهد که سایر قراردادها میتوانند به طور منظم برای اطلاعات بخوانند. انتظار میرود که دادهها در این مورد به طور مکرر تغییر کنند، بنابراین قراردادهای مشتری باید برای بهروزرسانی دادههای ذخیرهسازی اوراکل گوش (listen) (نوعی از اصطلاحات در خصوص برنامه نویسی) دهند. به عنوان مثال اوراکلی است که آخرین اطلاعات قیمت ETH-USD را در اختیار کاربران قرار میدهد.
+
+### اوراکلهای درخواست-پاسخ {#request-response-oracles}
+
+تنظیم درخواست-پاسخ به قرارداد مشتری یا کلاینت اجازه میدهد تا دادههای دلخواه را غیر از آنچه توسط یک اوراکل انتشار-اشتراک ارائه میشود، درخواست کند. اوراکلهای درخواست-پاسخ زمانی ایدهآل هستند که مجموعه داده آنقدر بزرگ است که نمیتوان آنها را در فضای ذخیرهسازی قرارداد هوشمند ذخیره کرد و/یا کاربران تنها به بخش کوچکی از دادهها در هر مقطع زمانی نیاز خواهند داشت.
+
+اگرچه پیچیدهتر از مدلهای انتشار-اشتراک است، اما اوراکلهای درخواست پاسخ اساساً همان چیزی است که در بخش قبل توضیح دادیم. اوراکل دارای یک جزء روی زنجیره خواهد بود که درخواست داده را دریافت کرده و آن را برای پردازش به یک گره یا نود خارج از زنجیره ارسال میکند.
+
+کاربرانی که درخواستهای داده را آغاز میکنند باید هزینه بازیابی اطلاعات از منبع خارج از زنجیره را پوشش دهند. همچنین قرارداد کلاینت باید وجوهی را برای پوشش هزینههای گس متحمل شده توسط قرارداد اوراکل در بازگرداندن پاسخ از طریق تابع کالبک به تماس مشخص شده در درخواست فراهم کند.
+
+## اوراکلهای متمرکز در مقابل غیرمتمرکز {#types-of-oracles}
+
+### اوراکلهای متمرکز {#centralized-oracles}
+
+یک اوراکل متمرکز توسط یک نهاد واحد کنترل میشود که مسئول جمعآوری اطلاعات خارج از زنجیره و به روز رسانی دادههای قرارداد اوراکل در صورت درخواست است. اوراکلهای متمرکز کارآمد هستند زیرا بر یک منبع حقیقی تکیه دارند. آنها ممکن است در مواردی که مجموعه دادههای اختصاصی مستقیماً توسط مالک با امضای پذیرفته شده منتشر میشود بهتر عمل کنند. با این حال، آنها جنبههای منفی نیز دارند:
+
+#### صحت کم را تضمین میکند {#low-correctness-guarantees}
+
+با اوراکلهای متمرکز، هیچ راهی برای تأیید صحت یا عدم صحت اطلاعات ارائه شده وجود ندارد. حتی ارائه دهندگان "معتبر" میتوانند سرکش یا هک شوند. اگر اوراکل فاسد شود، قراردادهای هوشمند بر اساس دادههای نامناسب اجرا میشوند.
+
+#### در دسترس بودن ضعیف {#poor-availability}
+
+اوراکلهای متمرکز تضمین نمیکنند که همیشه دادههای خارج از زنجیره را در اختیار سایر قراردادهای هوشمند قرار دهند. اگر ارائهدهنده تصمیم بگیرد سرویس را خاموش کند یا هکری مؤلفه خارج از زنجیره اوراکل را ربود، قرارداد هوشمند شما در معرض خطر حمله انکار سرویس (DoS) قرار دارد.
+
+#### سازگاری انگیزشی ضعیف {#poor-incentive-compatibility}
+
+اوراکلهای متمرکز اغلب با انگیزههای ضعیفی طراحی شده یا برای ارائهدهنده داده برای ارسال اطلاعات دقیق/بدون تغییر وجود ندارند. پرداخت به اوراکل برای صحت، صداقت را تضمین نمیکند. این مشکل با افزایش مقدار ارزش کنترل شده توسط قراردادهای هوشمند بزرگتر میشود.
+
+### اوراکلهای غیرمتمرکز {#decentralized-oracles}
+
+اوراکلهای غیرمتمرکز برای غلبه بر محدودیتهای اوراکلهای متمرکز با حذف نقاط شکست منفرد طراحی شدهاند. یک سرویس غیرمتمرکز اوراکل شامل چندین شرکتکننده در یک شبکه همتا به همتا است که قبل از ارسال آن به یک قرارداد هوشمند، روی دادههای خارج از زنجیره یا آفچین اتفاق نظر دارند.
+
+یک اوراکل غیرمتمرکز (در حالت ایده آل) باید بدون مجوز، بدون اعتماد و عاری از اداره یک حزب مرکزی باشد؛ در واقعیت، تمرکززدایی در میان اوراکل ها در یک طیف است. شبکههای اوراکل نیمه غیرمتمرکز وجود دارد که هر کسی میتواند در آن شرکت کند، اما با یک «مالک» که گرهها را بر اساس عملکرد تاریخی تأیید و حذف میکند باشد. شبکههای اوراکل کاملاً غیرمتمرکز نیز وجود دارند: این شبکهها معمولاً بهعنوان زنجیرههای بلوکی یا همان بلاکچین مستقل اجرا میشوند و مکانیزمهای اجماع مشخصی برای هماهنگ کردن گرهها و مجازات رفتارهای نادرست دارند.
+
+استفاده از اوراکلهای غیرمتمرکز دارای مزایای زیر است:
+
+### صحت بالا را تضمین میکند {#high-correctness-guarantees}
+
+اوراکلهای غیرمتمرکز تلاش میکنند تا با استفاده از رویکردهای مختلف به صحت دادهها دست یابند. این مورد شامل استفاده از شواهدی است که صحت و یکپارچگی اطلاعات بازگردانده شده را تأیید میکند و لازم است چندین نهاد به طور جمعی در مورد اعتبار دادههای خارج از زنجیره به توافق برسند.
+
+#### اثبات اصالت {#authenticity-proofs}
+
+اثبات اصالت مکانیزمهای رمزنگاری هستند که امکان تأیید مستقل اطلاعات بازیابی شده از منابع خارجی را فراهم میکنند. این شواهد میتوانند منبع اطلاعات را تایید و تغییرات احتمالی دادهها را پس از بازیابی شناسایی کنند.
+
+نمونههایی از اثبات اصالت عبارتند از:
+
+**اثبات امنیت لایه انتقال (TLS)**: گرههای اوراکل اغلب دادهها را با استفاده از یک اتصال HTTP ایمن بر اساس پروتکل امنیت لایه انتقال (TLS) از منابع خارجی بازیابی میکنند. برخی از اوراکلهای غیرمتمرکز برای تأیید جلسات TLS (یعنی تأیید تبادل اطلاعات بین یک گره و یک سرور خاص) و تأیید عدم تغییر محتویات جلسه، از اثباتهای اعتبار یا اصالت استفاده میکنند.
+
+**تأییدات محیط اجرای مورد اعتماد (TEE)**: یک [محیط اجرای مورد اعتماد](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) یک محیط محاسباتی سندباکس شده است که از فرآیندهای عملیاتی سیستم میزبان خود جدا شده است. TEEها اطمینان حاصل میکنند که هر کد برنامه یا دادهای که در محیط محاسباتی ذخیره/استفاده میشود، یکپارچگی، محرمانه بودن و تغییرناپذیری را حفظ میکند. همچنین کاربران میتوانند یک گواهی برای اثبات اینکه یک نمونه برنامه در محیط اجرای مورد اعتماد اجرا میشود، ایجاد کنند.
+
+کلاسهای خاصی از اوراکلهای غیرمتمرکز به اپراتورهای گره اوراکل برای ارائه گواهی TEE نیاز دارند. این مورد به کاربر تأیید میکند که اپراتور گره نمونهای از سرویس گیرنده اوراکل را در یک محیط اجرای مطمئن اجرا میکند. TEEها از تغییر یا خواندن کد و دادههای برنامه توسط فرآیندهای خارجی جلوگیری میکنند، از این رو، این گواهیها ثابت میکنند که گره اوراکل اطلاعات را دست نخورده و محرمانه نگه داشته است.
+
+#### اعتبارسنجی مبتنی بر اجماع اطلاعات {#consensus-based-validation-of-information}
+
+اوراکلهای متمرکز هنگام ارائه دادهها به قراردادهای هوشمند به یک منبع حقیقت تکیه میکنند که امکان انتشار اطلاعات نادرست وجود دارد. اوراکلهای غیرمتمرکز این مشکل را با تکیه بر چندین گره اوراکل برای جستجوی اطلاعات خارج از زنجیره حل میکنند. با مقایسه دادههای چند منبع، اوراکلهای غیرمتمرکز خطر انتقال اطلاعات نامعتبر به قراردادهای زنجیرهای را کاهش میدهند.
+
+با این حال، اوراکلهای غیرمتمرکز باید با اختلافات در اطلاعات بازیابی شده از چندین منبع خارج از زنجیره مقابله کنند. برای به حداقل رساندن تفاوتها در اطلاعات و اطمینان از اینکه دادههای ارسال شده به قرارداد اوراکل منعکسکننده نظر جمعی گرههای اوراکل است، اوراکلهای غیرمتمرکز از مکانیزمهای زیر استفاده میکنند:
+
+##### رای دادن/استیک کردن در مورد صحت دادهها
+
+برخی از شبکههای اوراکل غیرمتمرکز از شرکتکنندگان میخواهند که در صحت پاسخهای پرسشهای داده رای دهند یا در مورد صحت پاسخها استیک کنند (به عنوان مثال، "چه کسی در انتخابات 2020 ایالات متحده پیروز شد؟") با استفاده از توکن بومی شبکه. سپس یک پروتکل تجمیع آرا و سهام را جمع میکند و پاسخی را که اکثریت پشتیبانی میکند به عنوان پاسخ معتبر میگیرد.
+
+گرههایی که پاسخ آنها از پاسخ اکثریت منحرف میشود، با توزیع توکنهایشان به دیگرانی که مقادیر صحیحتری ارائه میدهند، جریمه میشوند. اجبار گره یا نودها برای ایجاد پیوند قبل از ارائه دادهها، انگیزه پاسخهای صادقانه را فراهم میکند، زیرا فرض میشود که آنها افراد اقتصادی منطقی هستند که قصد دارند بازده را به حداکثر برسانند.
+
+استیک/رایگیری همچنین از اوراکلهای غیرمتمرکز در برابر [حملات سبیل](/glossary/#sybil-attack) محافظت میکند که در آن عوامل مخرب چندین هویت را برای بازی با سیستم اجماع ایجاد میکنند. با این حال، استیک نمیتواند از "بارگذاری رایگان" (گرههای اوراکل که اطلاعات را از دیگران کپی میکنند) و "اعتبارسنجی تنبل" (گرههای اوراکل اکثریت را بدون تأیید اطلاعات خود دنبال میکنند) جلوگیری کند.
+
+##### مکانیزمهای نقطه هدف
+
+[نقطه هدف](https://en.wikipedia.org/wiki/Focal_point_(game_theory)) یک مفهوم تئوری است که فرض میکند چندین موجودیت همیشه به طور پیشفرض به یک راهحل مشترک برای یک مشکل در عدم وجود هرگونه ارتباط میرسند. مکانیسمهای شلینگ پوینت (Schelling-point) اغلب در شبکههای اوراکل غیرمتمرکز استفاده میشوند تا گره یا نودها را قادر میسازد در مورد پاسخ به درخواستهای داده به توافق برسند.
+
+ایده اولیه برای این [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) بود، فید داده پیشنهادی که در آن شرکتکنندگان پاسخهایی را به سؤالات «اسکالر» (سوالاتی که پاسخهای آنها با بزرگی توصیف میشود، بهعنوان مثال، «قیمت اتریوم چقدر است؟») همراه با سپرده ارسال میکنند. کاربرانی که مقادیری را بین 25 و 75 [درصد](https://en.wikipedia.org/wiki/Percentile) ارائه میکنند، پاداش میگیرند، در حالی که آنهایی که مقادیرشان تا حد زیادی از مقدار متوسط انحراف دارد، جریمه میشوند.
+
+در حالی که SchellingCoin امروزه وجود ندارد، تعدادی اوراکل غیرمتمرکز—به ویژه [پروتکل سازندگان اوراکلها](https://docs.makerdao.com/smart-contract-modules/oracle-module)—از مکانیزم نقطه هدف برای بهبود دقت دادههای اوراکل استفاده میکردند. هر Maker Oracle متشکل از یک شبکه P2P خارج از زنجیره از گرهها ("relayers" و "feed") است که قیمتهای بازار را برای داراییهای وثیقه ارسال کرده و یک قرارداد "Medianizer" درون زنجیرهای که میانگین تمام ارزشهای ارائهشده را محاسبه میکند. پس از پایان دوره تاخیر مشخص شده، این مقدار متوسط به قیمت مرجع جدید برای دارایی مرتبط تبدیل میشود.
+
+نمونههای دیگر اوراکلهایی که از مکانیزمهای نقطه هدف استفاده میکنند عبارتند از [گزارشدهی خارج از زنجیره چین لینک](https://docs.chain.link/docs/off-chain-reporting/) و [Witnet](https://witnet.io/). در هر دو سیستم، پاسخهای گره یا نودهای اوراکل در شبکه همتا به همتا در یک مقدار مجموع، مانند میانگین یا میانه، تجمیع میشوند. گره یا نودها با توجه به میزانی که پاسخ هایشان با مقدار کل همسو یا انحراف دارد، پاداش یا مجازات میشوند.
+
+مکانیسمهای شلینگ پوینت (Schelling point) جذاب هستند زیرا ردپای روی زنجیره را به حداقل میرسانند (فقط یک تراکنش باید ارسال شود) در حالی که تمرکززدایی را تضمین میکند. مورد دوم امکانپذیر است زیرا گرهها باید قبل از وارد شدن به الگوریتمی که مقدار میانگین/میانگین را تولید میکند، در لیست پاسخهای ارسالی امضا کنند.
+
+### در دسترس بودن {#availability}
+
+خدمات غیرمتمرکز اوراکل در دسترس بودن بالای دادههای خارج از زنجیره را برای قراردادهای هوشمند تضمین میکند. این امر با غیرمتمرکز کردن منبع اطلاعات خارج از زنجیره و گره یا نودهای مسئول انتقال اطلاعات در زنجیره به دست میآید.
+
+این امر تحمل خطا را تضمین میکند زیرا قرارداد اوراکل میتواند به چندین گره یا نود (که همچنین به چندین منبع داده متکی هستند) برای اجرای پرسوجو از قراردادهای دیگر متکی باشد. تمرکززدایی در سطح منبع _و_ گره-اپراتور بسیار مهم است—شبکه ای از گرههای اوراکل که اطلاعات بازیابی شده از یک منبع را ارائه میدهند، با مشکل مشابه یک اوراکل متمرکز مواجه خواهند شد.
+
+همچنین برای اوراکلهای مبتنی بر سهام میتواند اپراتورهای گره یا نودی را که نمیتوانند به سرعت به درخواستهای داده پاسخ دهند، کاهش دهند. این به طور قابل توجهی گره یا نودهای اوراکل را برای سرمایهگذاری در زیرساختهای مقاوم در برابر خطا و ارائه به موقع دادهها تشویق میکند.
+
+### سازگاری انگیزشی خوب {#good-incentive-compatibility}
+
+اوراکلهای غیرمتمرکز طرحهای تشویقی مختلفی را برای جلوگیری از رفتار [بیزانس](https://en.wikipedia.org/wiki/Byzantine_fault) در میان گرههای اوراکل اجرا میکنند. به طور خاص، آنها به _قابلیت انتساب_ و _پاسخگویی_ دست مییابند:
+
+1. گره یا نودهای اوراکل غیرمتمرکز اغلب برای امضای دادههایی که در پاسخ به درخواستهای داده ارائه میکنند مورد نیاز است. این اطلاعات به ارزیابی عملکرد تاریخی گره یا نودهای اوراکل کمک میکند، به طوری که کاربران میتوانند هنگام درخواست داده، گره یا نودهای اوراکل غیرقابل اعتماد را فیلتر کنند. یک مثال [سیستم شهرت الگوریتمی](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) Witnet است.
+
+2. اوراکلهای غیرمتمرکز - همانطور که قبلاً توضیح داده شد - ممکن است به گره یا نودهایی نیاز داشته باشند که در مورد اطمینان خود نسبت به صحت دادههایی که ارسال میکنند، سهمی داشته باشند. در صورت بررسی ادعا، این سهام میتواند همراه با پاداش برای خدمات صادقانه بازگردانده شود. اما در صورت نادرست بودن اطلاعات نیز میتوان آن را کاهش داد، که مقداری از پاسخگویی را فراهم میکند.
+
+## کاربردهای اوراکل در قراردادهای هوشمند {#applications-of-oracles-in-smart-contracts}
+
+موارد زیر موارد استفاده رایج برای اوراکلها در اتریوم است:
+
+### بازیابی اطلاعات مالی {#retrieving-financial-data}
+
+برنامههای [مالی غیرمتمرکز](/defi/) (DeFi) امکان وامدهی، استقراض و معامله داراییها را به صورت همتا به همتا فراهم میکنند. این مورد اغلب مستلزم دریافت اطلاعات مالی مختلف، از جمله دادههای نرخ مبادله (برای محاسبه ارزش فیات ارزهای دیجیتال یا مقایسه قیمتهای توکن) و دادههای بازار سرمایه (برای محاسبه ارزش داراییهای توکنشده، مانند طلا یا دلار آمریکا) است.
+
+به عنوان مثال، یک پروتکل وام دهی دیفای، نیاز به استعلام قیمتهای فعلی بازار برای داراییها (به عنوان مثال، اتر) دارد که به عنوان وثیقه سپرده شده است. این به قرارداد اجازه میدهد تا ارزش داراییهای وثیقه را تعیین کند و تعیین کند که چقدر میتواند از سیستم وام بگیرد.
+
+«اوراکلهای قیمت» محبوب (که معمولاً به آنها گفته میشود) در دیفای شامل فیدهای قیمت زنجیرهای، پروتکل ترکیبی [فید قیمت باز](https://compound.finance/docs/prices) یونی سواپ است. href="https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles">قیمتهای میانگین وزندار زمانی (TWAP) و [میکر اوراکل](https://docs.makerdao.com/smart-contract-modules/oracle-module).
+
+سازندگان باید قبل از ادغام آنها در پروژه خود، اخطارهایی را که با این اوراکلهای قیمت همراه است، درک کنند. این [مقاله](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) تجزیه و تحلیل دقیقی از مواردی که باید در برنامه ریزی برای استفاده از هر یک از اوراکلهای قیمت ذکر شده در نظر بگیرید ارائه میدهد.
+
+در زیر مثالی از نحوه بازیابی آخرین قیمت اتر در قرارداد هوشمند خود با استفاده از فید قیمت زنجیرهای آورده شده است:
+
+```solidity
+pragma solidity ^0.6.7;
+
+import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
+
+contract PriceConsumerV3 {
+
+ AggregatorV3Interface internal priceFeed;
+
+ /**
+ * Network: Kovan
+ * Aggregator: ETH/USD
+ * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
+ */
+ constructor() public {
+ priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
+ }
+
+ /**
+ * Returns the latest price
+ */
+ function getLatestPrice() public view returns (int) {
+ (
+ uint80 roundID,
+ int price,
+ uint startedAt,
+ uint timeStamp,
+ uint80 answeredInRound
+ ) = priceFeed.latestRoundData();
+ return price;
+ }
+}
+```
+
+### ایجاد تصادفی قابل تأیید {#generating-verifiable-randomness}
+
+برخی از برنامههای بلاکچین، مانند بازیهای مبتنی بر بلاکچین یا طرحهای بختآزمایی، به سطح بالایی از غیرقابل پیشبینی و تصادفی بودن نیاز دارند تا به طور مؤثر کار کنند. با این حال، اجرای قطعی بلاکچینها تصادفی بودن را از بین میبرد.
+
+رویکرد اولیه استفاده از توابع رمزنگاری شبه تصادفی، مانند `بلاک هش` بود، اما اینها ممکن [توسط ماینرها](https://ethereum.stackexchange.com/questions/3140/risk-of-using- blockhash-other-miners-preventing-attack#:~:text=است%20که%20the%20miners%20can,to%20one%20of%20the%20players.) برای حل مشکل الگوریتم اثبات کار دستکاری شوند. همچنین، [تغییر به اثبات سهام](/roadmap/merge/) اتریوم به این معنی است که توسعهدهندگان دیگر نمیتوانند برای تصادفی بودن روی زنجیره به `بلاک هش` اعتماد کنند. در عوض، [مکانیزم RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) بیکون چین یک منبع جایگزین برای تصادفی بودن فراهم میکند.
+
+امکان تولید ارزش تصادفی خارج از زنجیره و ارسال آن در زنجیره وجود دارد، اما انجام این کار الزامات اعتماد بالایی را به کاربران تحمیل میکند. آنها باید باور داشته باشند که ارزش واقعی از طریق مکانیسمهای غیرقابل پیشبینی ایجاد شده است و در حمل و نقل تغییر نکرده است.
+
+اوراکلهایی که برای محاسبات خارج از زنجیره طراحی شدهاند، این مشکل را با تولید ایمن نتایج تصادفی خارج از زنجیره که روی زنجیره پخش میکنند همراه با اثباتهای رمزنگاری که غیرقابل پیشبینی بودن فرآیند را تأیید میکنند، حل میکنند. یک مثال [چین لینک VRF](https://docs.chain.link/docs/chainlink-vrf/) (عملکرد تصادفی قابل تأیید) است که یک تولید کننده اعداد تصادفی منصفانه و بدون دستکاری است. (RNG) برای ساخت قراردادهای هوشمند قابل اعتماد برای برنامههایی که بر نتایج غیرقابل پیشبینی تکیه دارند مفید است. مثال دیگر [API3 QRNG](https://docs.api3.org/explore/qrng/) است که تولید اعداد تصادفی کوانتومی (QRNG) را ارائه میکند، یک روش عمومی وب 3 RNG مبتنی بر پدیدههای کوانتومی با هدف ارائه شده توسط دانشگاه ملی استرالیا (ANU) است.
+
+### به دست آوردن نتایج برای رویدادها {#getting-outcomes-for-events}
+
+با اوراکلها، ایجاد قراردادهای هوشمند که به رویدادهای دنیای واقعی پاسخ میدهند، آسان است. خدمات اوراکل با اجازه دادن به قراردادها برای اتصال به APIهای خارجی از طریق اجزای خارج از زنجیره و مصرف اطلاعات از آن منابع داده، این امکان را فراهم میکند. به عنوان مثال، برنامه پیشبینی که قبلاً ذکر شد ممکن است از اوراکل درخواست کند که نتایج انتخابات را از یک منبع معتبر خارج از زنجیره (مثلاً آسوشیتد پرس) بازگرداند.
+
+استفاده از اوراکلها برای بازیابی دادهها بر اساس نتایج دنیای واقعی، سایر موارد استفاده جدید را امکانپذیر میکند. به عنوان مثال، یک محصول بیمه غیرمتمرکز به اطلاعات دقیق در مورد آب و هوا، بلایا و غیره نیاز دارد تا به طور مؤثر کار کند.
+
+### خودکارسازی قراردادهای هوشمند {#automating-smart-contracts}
+
+قراردادهای هوشمند به طور خودکار اجرا نمیشوند. بلکه یک حساب متعلق به خارجی (EOA)، یا یک حساب قرارداد دیگر، باید عملکردهای مناسب را برای اجرای کد قرارداد راه اندازی کند. در بیشتر موارد، بخش عمدهای از وظایف قرارداد عمومی است و میتواند توسط EOA و سایر قراردادها مورد استناد قرار گیرد.
+
+اما همچنین _عملکردهای خصوصی_ در قرارداد وجود دارد که برای دیگران غیرقابل دسترسی است؛ اما برای عملکرد کلی یک برنامه غیرمتمرکز بسیار مهم است. مثالها عبارتند از یک تابع `mintERC721Token()` که به صورت دورهای NFTهای جدید را برای کاربران مینت میکند، تابعی برای اعطای پرداختها در بازار پیشبینی، یا تابعی برای باز کردن قفل توکنهای استیک شده در یک دکس است.
+
+توسعه دهندگان باید چنین عملکردهایی را در فواصل زمانی فعال کنند تا برنامه به خوبی اجرا شود. با این حال، این مورد ممکن است منجر به از دست دادن ساعات بیشتری در انجام کارهای روزمره برای توسعه دهندگان شود، به همین دلیل است که اجرای خودکار قراردادهای هوشمند جذاب است.
+
+برخی از شبکههای اوراکل غیرمتمرکز خدمات اتوماسیون را ارائه میکنند که به گرههای اوراکل خارج از زنجیره اجازه میدهد تا عملکردهای قرارداد هوشمند را بر اساس پارامترهای تعریف شده توسط کاربر فعال کنند. به طور معمول، این امر مستلزم «ثبت» قرارداد هدف با سرویس اوراکل، تأمین بودجه برای پرداخت به اپراتور اوراکل و مشخص کردن شرایط یا زمانهای شروع قرارداد است.
+
+[شبکه کیپر](https://chain.link/keepers) چین لینک گزینههایی را برای قراردادهای هوشمند برای برونسپاری وظایف تعمیر و نگهداری منظم به روشی به حداقل رسیده و غیرمتمرکز ارائه میدهد. [داکیومنت کیپر ](https://docs.chain.link/docs/chainlink-keepers/introduction/) را برای اطلاعات در مورد سازگار کردن قرارداد خود با کیپر و استفاده از سرویس Upkeep بخوانید.
+
+## نحوه استفاده از اوراکلهای بلاک چین {#use-blockchain-oracles}
+
+چندین برنامه اوراکل وجود دارد که میتوانید آنها را در برنامه اتریوم خود ادغام کنید:
+
+**[چین لینک](https://chain.link/)** - _شبکههای غیرمتمرکز اوراکل چین لینک ارائه میکنند ورودیها، خروجیها و محاسبات ضد دستکاری برای پشتیبانی از قراردادهای هوشمند پیشرفته در هر بلاک چین را اعمال میکند._
+
+**[کرونیکل](https://chroniclelabs.org/)** - _کرونیکل بر محدودیتهای فعلی غلبه میکند انتقال دادهها در زنجیره با توسعه اوراکلهای واقعا مقیاس پذیر، مقرون به صرفه، غیرمتمرکز و قابل تأیید را پیادهسازی میکند._
+
+**[Witnet](https://witnet.io/)** - _ویت نت بدون مجوز است، اوراکل غیرمتمرکز و مقاوم در برابر سانسور به قراردادهای هوشمند کمک میکند تا با ضمانتهای ارزی-اقتصادی قوی به رویدادهای دنیای واقعی واکنش نشان دهند._
+
+**[UMA Oracle](https://uma.xyz)** - _اوراکل آپتیمیستیک UMA به قراردادهای هوشمند اجازه میدهد قراردادهایی برای دریافت سریع و دریافت هر نوع داده برای برنامههای مختلف، از جمله بیمه، مشتقات مالی و بازارهای پیش بینی انجام دهند._
+
+**[تلور](https://tellor.io/)** - _تلور شفاف و پروتکل اوراکل بدون مجوز برای قرارداد هوشمند شما است تا به راحتی هر دادهای را هر زمان که به آن نیاز داشتید دریافت کنید._
+
+**[پروتکل باند](https://bandprotocol.com/)** - _پروتکل باند یک پلتفرم اوراکل داده متقابل زنجیرهای که دادهها و APIهای دنیای واقعی را جمعآوری و به قراردادهای هوشمند متصل میکند._
+
+**[Paralink](https://paralink.network/)** - _پارالینک یک برنامه منبع باز ارائه میکند و پلتفرم اوراکل غیرمتمرکز برای قراردادهای هوشمند در حال اجرا بر روی اتریوم و سایر بلاک چینهای محبوب است._
+
+**[شبکه Pyth](https://pyth.network/)** - _شبکه Pyth یک شبکه اوراکل مالی شخص اول که برای انتشار دادههای مستمر دنیای واقعی روی زنجیره در محیطی مقاوم در برابر دستکاری، غیرمتمرکز و خودپایدار طراحی شده است._
+
+**[API3 DAO](https://www.api3.org/)** - _API3 DAO در حال ارائه راه حلهای اوراکل شخص اول است که شفافیت منبع، امنیت و مقیاس پذیری بیشتری را در یک راه حل غیرمتمرکز برای قراردادهای هوشمند ارائه میکند_
+
+**[Supra](https://supra.com/)** - یک جعبه ابزار یکپارچه از راهحلهای زنجیرهای متقابل که همه بلاک چینها را به هم متصل میکند. (L1ها و L2ها) یا خصوصی (تشکیلات)، ارائه فیدهای غیرمتمرکز قیمت اوراکل که میتواند برای موارد استفاده در زنجیره و خارج از زنجیره استفاده شود.
+
+## بیشتر بخوانید {#further-reading}
+
+**مقالات**
+
+- [اوراکل بلاک چین چیست؟](https://chain.link/education/blockchain-oracles) — _چین لینک_
+- [اوراکل بلاک چین چیست؟](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _پاتریک کالینز< /em>
+- [اوراکلهای غیرمتمرکز: مروری جامع](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _ژولین تیونارد_
+- [اجرای اوراکل بلاک چین در اتریوم](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) - *پدرو کاستا*
+- [چرا قراردادهای هوشمند نمیتوانند تماسهای API برقرار کنند؟](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
+- [چرا به اوراکلهای غیرمتمرکز نیاز داریم](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) — _Bankless< /em>
+- [پس میخواهید از اوراکل قیمت استفاده کنید](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
+
+**ویدیوها**
+
+- [Oracles و گسترش ابزار بلاک چین](https://youtu.be/BVUZpWa8vpw) — _بخش مالی ریل ویژن_
+- [تفاوتهای اوراکلهای شخص اول و شخص ثالث](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/) - _Blockchain Oracle Summit_
+
+**آموزشها**
+
+- [نحوه واکشی قیمت فعلی اتریوم در سالیدیتی](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _چین لینک_
+- [مصرف دادههای اوراکل](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _کرونیکل_
+
+**نمونه پروژهها**
+
+- [پروژه شروع کامل چین لینک برای اتریوم در سالیدیتی](https://github.com/hackbg/chainlink-fullstack) — _HackBG_
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md
new file mode 100644
index 00000000000..8e2c02ef379
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md
@@ -0,0 +1,59 @@
+---
+title: استانداردهای توسعه اتریوم
+description:
+lang: fa
+incomplete: true
+---
+
+## مروری بر استانداردها {#standards-overview}
+
+جامعه اتریوم استانداردهای زیادی را اتخاذ کرده است تا کمک کند پروژه ها (همچون [کلاینت های اتریوم](/developers/docs/nodes-and-clients/) و کیف پول های دیجیتالی) در هنگام پیاده سازی، قابلیت اجرا داشته باشند و همچنین اطمینان حاصل می کند تا قراردادهای هوشمند و dapp ها هچنان ترکیب پذیر باقی بمانند.
+
+استانداردها عموما به صورت [پیشنهادات بهبود اتریوم](/eips/) (EIPها) معرفی می گردند که توسط اعضای جامعه از طریق یک [فرآیند استاندارد](https://eips.ethereum.org/EIPS/eip-1) مورد بحث قرار می گیرند.
+
+- [مقدمه ای بر EIPها](/eips/)
+- [لیست EIPها](https://eips.ethereum.org/)
+- [مخزن گیتهاب EIP](https://github.com/ethereum/EIPs)
+- [صفحه گفتگوی EIP](https://ethereum-magicians.org/c/eips)
+- [مقدمهای بر حاکمیت اتریوم](/governance/)
+- [مروری بر حاکمیت اتریوم](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _March 31, 2019 - Boris Mann_
+- [هماهنگسازی پروتکل توسعه پروتکل و ارتقا شبکه](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 مارس 2020 - هودسون جیمزسون_
+- [فهرست پخش تمامی جلسات توسعه هسته اتریوم](https://www.youtube.com/@EthereumProtocol) _(فهرست پخش در یوتیوب)_
+
+## انواع استانداردها {#types-of-standards}
+
+3 نوع EIP وجود دارد:
+
+- مسیر استانداردها: هر تغییری را توصیف میکند که بر اکثر یا همه نسخه های اتریوم تأثیر میگذارد
+- [مسیر ابرداده ها (Meta)](https://eips.ethereum.org/meta): پروسه های حول محور اتریوم را توصیف می کند یا تغییری را در یک پروسه پیشنهاد میکند
+- [مسیر اطلاعات](https://eips.ethereum.org/informational): یک مشکل طراحی اتریوم را شرح میدهد یا دستورالعملها یا اطلاعات کلی را در اختیار جامعه اتریوم قرار میدهد
+
+علاوه بر این، مسیر استانداردها به 4 دسته تقسیم میشود:
+
+- [هسته](https://eips.ethereum.org/core): بهبودهایی که نیاز به فورک اجماع دارند
+- [شبکهسازی](https://eips.ethereum.org/networking): بهبودهای حول محور devp2p و پروتکل های فرعی اتریوم رقیق و همچنین بهبودهای پیشنهادی برای مشخصات پروتکل شبکه whisper و swarm است.
+- [رابط](https://eips.ethereum.org/interface): بهبودهایی در مورد مشخصات و استانداردهای API/RPC کلاینت و استانداردهای خاص در سطح زبان مانند نام روشها و قراردادهای ABI است.
+- [ERC](https://eips.ethereum.org/erc): استانداردها و کنوانسیونهای سطح برنامه
+
+اطلاعات دقیقتر در مورد انواع و دستههای مختلف را میتوانید در [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) پیدا کنید
+
+### استانداردهای توکن {#token-standards}
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - یک رابط استاندارد برای توکنهای تعویضپذیر (قابل تعویض)، مانند توکنهای رایگیری، توکنهای شرطبندی یا ارزهای مجازی می باشد.
+ - [ERC-223](/developers/docs/standards/tokens/erc-223/) - نوعی استاندارد توکن تعویض پذیر است که رفتاری مشابه اتر دارد و از انتقال توکن هایی که در سمت گیرنده مدیریت می شوند، پشتیبانی می کند.
+ - [ERC-1363](https://eips.ethereum.org/EIPS/eip-1363) - یک رابط برقراری ارتباط با توکن، برای توکنهای ERC-20 توصیف میکند که از اجرای کد گیرنده پس از اجرای انتقال یا «انتقال از» و یا اجرای کد ارسال کننده پس از تایید، پشتیبانی میکند.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - یک رابط استاندارد برای توکنهای تعویض ناپذیر، مانند یک سند برای اثر هنری یا یک آهنگ است.
+ - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - یک رویداد استاندارد شده که هنگام ساخت یا انتقال یک یا چندین توکن تعویض ناپذیر، با استفاده از IDهای متوالی، اجرا و اطلاع رسانی میشود.
+ - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - افزونهای برای نقش مصرف کننده در رابط EIP-721.
+ - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - یک نقش دارای محدودیتهای دسترسی و زمانی را به توکنهای ERC-721 اضافه میکند.
+- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(توصیه نمیشود)** یک استاندارد توکن برای بهبود ERC-20.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - یک استاندارد توکنی است که میتواند دارای داراییهای تعویض پذیر و تعویض ناپذیر باشد.
+- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - یک استاندارد خزانه توکنیزه شده که برای بهینهسازی و یکسانسازی پارامترهای فنی خزانه های سودده طراحی شده است.
+
+درباره [استانداردهای توکن](/developers/docs/standards/tokens/) بیشتر بدانید.
+
+## بیشتر بخوانید {#further-reading}
+
+- [پیشنهادهای بهبود اتریوم (EIP)](/eips/)
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md
new file mode 100644
index 00000000000..54a9d121fc9
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md
@@ -0,0 +1,146 @@
+---
+title: استاندارد چند توکنی ERC-1155
+description:
+lang: fa
+---
+
+## معرفی {#introduction}
+
+یک رابط استاندارد برای قراردادهایی است که چندین نوع توکن را مدیریت می کنند. یک تک قرارداد هوشمند مستقر ممکن است شامل هر ترکیبی از توکنهای تعویض پذیر، توکنهای تعویض ناپذیر یا سایر پیکربندیها (مانند توکنهای نیمه تعویض پذیر) باشد.
+
+**منظور از استاندارد چند توکنی چیست؟**
+
+این ایده ساده است و به دنبال ایجاد یک رابط برنامه نویسی قرارداد هوشمند میباشد که می تواند هر تعداد توکن تعویض پذیر و تعویض ناپذیر را نشان دهد و کنترل کند. به این ترتیب، توکن ERC-1155 می تواند همان عملکردهای یک توکن [ERC-20](/developers/docs/standards/tokens/erc-20/) و [ERC-721](/developers/docs/standards/tokens/erc-721/) و حتی هر دو را به طور همزمان انجام دهد. این امر باعث بهبود عملکرد و کارآیی هر دو استاندارد ERC-20 و ERC-721 میشود و خطاهای واضح پیادهسازی را اصلاح میکند.
+
+توکن ERC-1155 به طور کامل در [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) توضیح داده شده است.
+
+## پیش نیاز ها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه می کنیم ابتدا در مورد [استانداردهای توکن](/developers/docs/standards/tokens/)، [ERC-20](/developers/docs/standards/tokens/erc-20/) و [ERC-721](/developers/docs/standards/tokens/erc-721/) مطالعه کنید.
+
+## توابع و ویژگی های ERC-1155: {#body}
+
+- [انتقال دستهای](#batch_transfers): چندین دارایی را در یک فراخوانی منتقل کنید.
+- [تراز دسته ای](#batch_balance): موجودی چندین دارایی را در یک فراخوانی دریافت کنید.
+- [تأیید دستهای](#batch_approval): همه توکن ها را برای یک آدرس تأیید کنید.
+- [قلابها](#receive_hook): قلاب توکنها را دریافت کنید.
+- [پشتیبانی NFT](#nft_support): اگر عرضه تنها ۱ باشد، با آن به عنوان NFT رفتار کنید.
+- [قوانین انتقال ایمن](#safe_transfer_rule): مجموعه قوانین برای انتقال ایمن.
+
+### انتقال دسته ای {#batch-transfers}
+
+عملیات انتقال دسته ای بسیار شبیه به انتقال معمولی ERC-20 است. بیایید نگاهی به تابع `transferFrom` استاندارد ERC-20 بیاندازیم:
+
+```solidity
+// ERC-20
+function transferFrom(address from, address to, uint256 value) external returns (bool);
+
+// ERC-1155
+function safeBatchTransferFrom(
+ address _from,
+ address _to,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external;
+```
+
+تنها تفاوت ERC-1155 در این است که مقادیر را به عنوان یک آرایه ارسال می کنیم و همچنین یک آرایه از id را نیز ارسال می کنیم. به عنوان مثال با توجه به `ids=[3, 6, 13]` و `values=[100, 200, 5]`، انتقالهای حاصل به صورت زیر می باشد
+
+1. 100 توکن با شناسه 3 را از `from_` به `to_` منتقل کنید.
+2. 200 توکن با شناسه 6 را از `from_` به `to_` منتقل کنید.
+3. 5 توکن با شناسه 13 را از `from_` به `to_` منتقل کنید.
+
+در ERC-1155 تنها تابع `transferFrom` را داریم و تابع `transfer` نداریم. برای استفاده از آن مانند یک `انتقال` معمولی، کافی است آدرس from را به آدرسی که تابع را فراخوانی میکند، تنظیم کنید.
+
+### موجودی دسته ای {#batch-balance}
+
+فراخوانی مربوط به ERC-20 `balanceOf` نیز به همین ترتیب تابع شریک خود را با پشتیبانی دسته ای دارد. به عنوان یک یادآوری، این نسخه ERC-20 است:
+
+```solidity
+// ERC-20
+function balanceOf(address owner) external view returns (uint256);
+
+// ERC-1155
+function balanceOfBatch(
+ address[] calldata _owners,
+ uint256[] calldata _ids
+) external view returns (uint256[] memory);
+```
+
+حتی سادهتر از فراخوانی موجودی، میتوانیم چندین موجودی را در یک فراخوانی بدست آوریم. آرایه از دارندگان حساب و به دنبال آن آرایه ای از شناسه های توکن را ارسال می کنیم.
+
+به عنوان مثال، با توجه به `_ids=[3, 6, 13]` و `_owners=[0xbeef..., 0x1337..., 0x1111...]`، مقدار بازگشتی برابر خواهد شد با
+
+```solidity
+[
+ balanceOf(0xbeef...),
+ balanceOf(0x1337...),
+ balanceOf(0x1111...)
+]
+```
+
+### تایید دسته ای {#batch-approval}
+
+```solidity
+// ERC-1155
+function setApprovalForAll(
+ address _operator,
+ bool _approved
+) external;
+
+function isApprovedForAll(
+ address _owner,
+ address _operator
+) external view returns (bool);
+```
+
+تاییدیه ها کمی با ERC-20 تفاوت دارند. به جای تأیید مبالغ خاص، یک اپراتور را از طریق `setApprovalForAll` روی تایید یا تایید نشده تنظیم می کنیم.
+
+خواندن وضعیت فعلی را می توان از طریق `isApprovedForAll` انجام داد. همانطور که مشاهده میکنید، این یک پاسخ صفر و یک است. شما نمی توانید تعیین کنید که چه تعداد توکن باید تایید شود یا حتی کدام کلاس توکن باید تایید شود.
+
+این مقوله عمدا با در نظر گرفتن سادگی طراحی شده است. شما فقط می توانید همه چیز را برای یک آدرس تایید کنید.
+
+### قلاب دریافت {#receive-hook}
+
+```solidity
+function onERC1155BatchReceived(
+ address _operator,
+ address _from,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external returns(bytes4);
+```
+
+با توجه به پشتیبانی [EIP-165](https://eips.ethereum.org/EIPS/eip-165)، پشتیبانی ERC-1155 تنها از قلابهای دریافت برای قرارداد هوشمند پشتیبانی میکند. تابع قلاب می بایست مقدار bytes4 از پیش تعریف شده جادویی را برگرداند که به صورت زیر داده می شود:
+
+```solidity
+bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
+```
+
+وقتی قرارداد دریافتکننده این مقدار را برمیگرداند، فرض بر این است که قرارداد انتقال را میپذیرد و میداند چگونه با توکنهای ERC-1155 کار کند. عالی است، دیگر هیچ توکنی در یک قرارداد گیر نمیکند!
+
+### پشتیبانی از NFT {#nft-support}
+
+وقتی عرضه فقط یک باشد، توکن اساساً یک توکن تعویض ناپذیر (NFT) است. و همانطور که برای ERC-721 استاندارد است، میتوانید یک URL اَبَرداده ای را تعریف کنید. URL را می توان توسط کلاینت ها خواند و تغییر داد، [اینجا](https://eips.ethereum.org/EIPS/eip-1155#metadata) را ببینید.
+
+### قانون انتقال ایمن {#safe-transfer-rule}
+
+ما قبلاً در توضیحات قبلی به چند قانون انتقال ایمن اشاره کردیم. اما بیایید مهم ترین قوانین را بررسی کنیم:
+
+1. تماسگیرنده می بایست برای خرج کردن توکن ها برای آدرس `from_` تأیید شود یا تماسگیرنده باید برابر با `from_` باشد.
+2. فراخوانی انتقال باید برگردانده شود اگر
+ 1. آدرس `to_` باشد.
+ 2. طول `_ids` با طول `_values` یکسان نباشد.
+ 3. هر یک از موجودی(های) دارنده(های) توکن(ها) در `_ids` کمتر از مقدار(های) مربوطه در `_values` ارسال شده به گیرنده باشد.
+ 4. هر خطای دیگری رخ دهد.
+
+_توجه_: همه توابع دستهای از جمله قلاب در نسخههای بدون دسته نیز وجود دارند. با توجه به اینکه انتقال تنها یک دارایی احتمالاً همچنان رایج ترین راه مورد استفاده خواهد بود، این کار به منظور بهره وری گاز انجام می شود. ما همگی آنها، از جمله قوانین انتقال ایمن را به خاطر سادگی در توضیحات کنار گذاشتیم. نام ها یکسان هستند، فقط "دسته ای" را حذف کنید.
+
+## بیشتر بخوانید {#further-reading}
+
+- [EIP-1155: استاندارد چند توکنی](https://eips.ethereum.org/EIPS/eip-1155)
+- [ERC-1155: مستندات Openzeppelin](https://docs.openzeppelin.com/contracts/3.x/erc1155)
+- [ERC-1155: در Repo گیت هاب](https://github.com/enjin/erc-1155)
+- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md
new file mode 100644
index 00000000000..d8e06f7dc6a
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md
@@ -0,0 +1,172 @@
+---
+title: استاندارد توکن ERC-20
+description:
+lang: fa
+---
+
+## معرفی {#introduction}
+
+**توکن چیست؟**
+
+توکن ها میتوانند هرچیزی را بصورت مجازی در اتریوم ارائه دهند:
+
+- امتیاز شهرت در یک پلتفرم آنلاین
+- مهارت های یک کاراکتر در یک بازی
+- دارایی های اقتصادی مانند سهام یک شرکت
+- یک ارز فیات مانند دلار
+- یک اونس طلا
+- و موارد دیگر...
+
+این نوع ویژگی قدرتمند اتریوم باید با یک استاندارد قوی اداره شود، اینطور نیست؟ این دقیقا همان جایی است که ERC-20 نقش خودش را اجرا میکند! این استانداردها به توسعه دهندگان این امکان را می دهد تا توکن اپلیکیشن هایی که با سایر محصولات و خدمات سازگار هستند را بسازند. همچنین این استاندارد عملکرد اضافهتری را برای اتر (واحد ارز داخلی اتریم یا ETH) فراهم میکند.
+
+**ERC-20 چیست؟**
+
+ERC-20 استانداردی را برای توکنهای تعویض پذیر معرفی می کند، به عبارت دیگر، آنها دارای خاصیتی هستند که باعث می شود هر توکن دقیقاً مشابه (از نظر نوع و مقدار) با توکن دیگر باشد. برای مثال توکن های ERC-20 دقیقا مثل اتر رفتار میکنند. به این معنی که 1 توکن همیشه با دیگر توکن ها برابر بوده و خواهد بود.
+
+## پیش نیاز ها {#prerequisites}
+
+- [حساب ها](/developers/docs/accounts)
+- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
+- [استانداردهای توکن](/developers/docs/standards/tokens/)
+
+## ساختار {#body}
+
+مفهوم توکن ERC-20 یا درخواست اتریوم برای نظرات 20 توسط فابیان ووگلستلر در نوامبر 2015 به عنوان استاندارد توکنی بیان شد که یک API برای توکن های قراردادهای هوشمند ارایه میکند.
+
+نمونه هایی از عملکردهای ERC-20 عبارتند از:
+
+- انتقال توکن ها از یک حساب به حساب دیگر
+- دریافت موجودی توکن یک حساب
+- دریافت کل عرضه توکن موجود در شبکه
+- تایید این که آیا مقداری توکن از یک حساب میتواند توسط یک حساب شخص ثالث خرج شود یا خیر
+
+اگر یک قرارداد هوشمند روشها و رویدادهای زیر را اجرا کند، میتوان آن را یک قرارداد توکن تعویض ناپذیر ERC-20 نامید و پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
+
+از [EIP-20](https://eips.ethereum.org/EIPS/eip-20):
+
+### روشها {#methods}
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
+function approve(address _spender, uint256 _value) public returns (bool success)
+function allowance(address _owner, address _spender) public view returns (uint256 remaining)
+```
+
+### رویدادها {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value)
+event Approval(address indexed _owner, address indexed _spender, uint256 _value)
+```
+
+### مثالها {#web3py-example}
+
+بیایید ببینیم سادگی یک استاندارد چقدر مهم است تا باعث شود هر گونه قرارداد توکن ERC-20 را در اتریوم بازرسی کنیم. ما برای ایجاد یک رابط در هر توکن ERC-20، فقط به رابط دوتایی برنامه قرارداد (ABI) نیاز داریم. همانطور که در زیر می بینید ما از یک ABI ساده شده استفاده می کنیم تا آن را به مثال قابل هضمی تبدیل کنیم.
+
+#### مثال Web3.py {#web3py-example}
+
+ابتدا مطمئن شوید که کتابخانه پایتون [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) را نصب کرده اید:
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
+weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
+
+acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
+
+# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract.
+# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply()
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'decimals',
+ 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi)
+symbol = dai_contract.functions.symbol().call()
+decimals = dai_contract.functions.decimals().call()
+totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# DAI
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+
+weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi)
+symbol = weth_contract.functions.symbol().call()
+decimals = weth_contract.functions.decimals().call()
+totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# WETH
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+```
+
+## مشکلات شناخته شده {#erc20-issues}
+
+### مشکل دریافت توکن ERC-20 {#reception-issue}
+
+هنگامی که توکنهای ERC-20 به یک قرارداد هوشمند ارسال میشوند که برای مدیریت توکنهای ERC-20 طراحی نشده است، توکنها برای همیشه از دست خواهند رفت. این زمانی اتفاق میافتد که قرارداد هوشمند گیرنده، عملکرد لازم برای شناسایی یا پاسخ به توکنهای دریافتی را ندارد و هیچ مکانیزمی در استاندارد ERC-20 وجود ندارد که قرارداد دریافت کننده را از توکنهای دریافتی مطلع کند. راههای اصلی شکلگیری این موضوع:
+
+1. مکانیسم انتقال توکن
+ - توکنهای ERC-20 با استفاده از تابع transfer یا transferFrom انتقال مییابند
+ - هنگامی که کاربر با استفاده از این توابع، توکنها را به آدرس یک قرارداد هوشمند ارسال میکند، توکنها بدون در نظر گرفتن این که آیا قرارداد دریافت کننده برای رسیدگی به آنها طراحی شده است یا خیر، انتقال خواهند یافت
+2. عدم اطلاع رسانی
+ - قرارداد دریافتکننده اعلان یا تماسی مبنی بر ارسال توکن به آن دریافت نمیکند
+ - اگر قرارداد دریافتکننده مکانیزمی برای مدیریت توکنها نداشته باشد (به عنوان مثال، یک تابع بازگشتی یا یک تابع اختصاصی برای مدیریت دریافت توکن)، توکنها به طور مؤثر در آدرس قرارداد گیر میکنند
+3. بدون مدیریت داخلی
+ - استاندارد ERC-20 دارای یک تابع اجباری برای اجرای دریافت قراردادها نیست، که این امر منجر به وضعیتی میشود که بسیاری از قراردادها قادر به مدیریت صحیح توکنهای دریافتی نیستند
+
+برخی استانداردهای جایگزین بر این مشکل فائق آمدهاند، مانند [ERC-223](/developers/docs/standards/tokens/erc-223)
+
+## اطلاعات بیشتر {#further-reading}
+
+- [EIP-20: استاندارد توکن ERC-20](https://eips.ethereum.org/EIPS/eip-20)
+- [OpenZeppelin - توکن ها](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
+- [OpenZeppelin - پیادهسازی ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
+- [Alchemy - راهنمایی برای توکنهای ERC-20 نوشته شده با Solidity](https://www.alchemy.com/overviews/erc20-solidity)
+
+
+## سایر استانداردهای توکن قابل تعویض {#fungible-token-standards}
+
+- [ERC-223](/developers/docs/standards/tokens/erc-223)
+- [ERC-777](/developers/docs/standards/tokens/erc-777)
+- [ERC-4626 - خزانههای توکنیزه شده](/developers/docs/standards/tokens/erc-4626)
\ No newline at end of file
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md
new file mode 100644
index 00000000000..5bfacb62270
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md
@@ -0,0 +1,209 @@
+---
+title: استاندارد توکن ERC-223
+description: مروری بر استاندارد توکن تعویض پذیر ERC-223، طرز کار آن و مقایسه آن با ERC-20.
+lang: fa
+---
+
+## مقدمه {#introduction}
+
+### ERC-223 چیست؟ {#what-is-erc223}
+
+استاندارد ERC-223 همانند ERC-20، برای توکنهای تعویض پذیر است. تفاوت کلیدی آنها این است که ERC-223 علاوه بر API (رابط کاربری برنامه نویسی)، منطق انتقال توکنها از فرستنده به گیرنده را نیز تعریف مینماید. این استاندارد یک مدل ارتباطی را معرفی میکند که اجازه میدهد انتقال توکنها در طرف گیرنده انجام شود.
+
+### تفاوتها با ERC-20{#erc20-differences}
+
+ERC-223 به یک سری از محدودیتهای استاندارد ERC-20 پاسخ میدهد و شیوهی جدیدی از ارتباط بین قرارداد هوشمند منبع توکن و قرارداد هوشمندی که ممکن است دریافت کننده توکنها باشد را معرفی میکند. اینها برخی از مواردی هستند که با ERC-223 امکان پذیرند ولی با ERC-20 نه:
+
+- انجام و پردازش انتقال توکن در سمت گیرنده: گیرندهها میتوانند تشخیص دهند که یک توکن ERC-223 برای آنها واریز میشود.
+- رد کردن توکنهایی که به درستی ارسال نشدهاند: اگر کاربری توکنهای ERC-223 را به قرارداد اشتباهی واریز نماید، آن قرارداد میتواند تراکنش را رد کند و باعث جلوگیری از دست رفتن توکنها شود.
+- ابرداده در تراکنش ها: توکنهای ERC-223 میتوانند شامل ابرداده باشند و اجازه دهند تا اطلاعات دلخواه به تراکنش توکنها الصاق شود.
+
+## پیش نیازها {#prerequisites}
+
+- [حسابها](/توسعهدهندهها/اسناد/حساب)
+- [قراردادهای هوشمند](/توسعهدهندهها/اسناد/قراردادهای هوشمند/)
+- [Token standards](/developers/docs/standards/tokens/)
+- [ERC-20](/توسعهدهندهها/اسناد/استانداردها/توکنها/erc-20/)
+
+## ساختار{#body}
+
+ERC-223 یک استاندارد مخصوص توکن است که یک API برای توکنها در داخل قراردادهای هوشمند پیادهسازی میکند. همچنین یک API هم برای قراردادهایی که قرار است توکنهای ERC-223 دریافت کنند، تعریف میکند. قراردادهایی که از API گیرندهی ERC-223 پشتیبانی نمیکنند، قادر نخواهند بود توکنهای ERC-223 دریافت کنند و این باعث جلوگیری از خطای کاربر میشود.
+
+اگر یک قرارداد هوشمند توابع و رویدادهایی که قرار است مطرح شوند را پیادهسازی نماید، میتواند بهعنوان یک قرارداد توکن سازگار با ERC-223 شناخته شود. پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
+
+قرارداد ملزم نیست فقط توابع و عملکرد زیر را داشته باشد و یک توسعه دهنده میتواند هر قابلیت دیگری را از سایر استانداردهای توکن متفاوت به این قرارداد اضافه کند. برای مثال توابع `approve` (تائید) و `transferFrom` (انتقال از) جزئی از استاندارد ERC-223 نیستند، بلکه این توابع میتوانند در صورت نیاز پیادهسازی شوند.
+
+از [EIP-223](https://eips.ethereum.org/EIPS/eip-223):
+
+### روشها {#methods}
+
+توکن ERC-223 باید روشهای زیر را پیادهسازی کند:
+
+```solidity
+// تابع اسم
+function name() public view returns (string)
+// تابع سمبل
+function symbol() public view returns (string)
+// تابع اعشار
+function decimals() public view returns (uint8)
+// تابع عرضه کل
+function totalSupply() public view returns (uint256)
+// تابع موجودی (آدرس دلخواه)
+function balanceOf(address _owner) public view returns (uint256 balance)
+// تابع انتقال توکن
+function transfer(address _to, uint256 _value) public returns (bool success)
+// تابع انتقال توکن (همراه با متغیر اضافه برای انتقال داده)
+function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
+```
+
+قراردادی که قصد دارد توکنهای ERC-223 دریافت کند، باید روش زیر را پیادهسازی کند:
+
+```solidity
+// تابع قلاب دریافت توکن برای پیادهسازی توسط قرارداد هوشمند
+function tokenReceived(address _from, uint _value, bytes calldata _data)
+```
+
+اگر توکنهای ERC-223 به قراردادی ارسال شوند که تابع `tokenReceived(..)` را پیادهسازی نکرده باشد، تراکنش باید شکست بخورد و توکنها نباید از موجودی فرستنده منتقل شوند.
+
+### رویدادها {#events}
+
+```solidity
+// رویداد انتقال
+event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data)
+```
+
+### مثالها {#examples}
+
+رابط برنامهنویسی (API) توکن ERC-223 مشابه ERC-20 میباشد، بنابراین از نظر توسعه فرانت-اند هیچ تفاوتی ایجاد نمیشود. تنها تفاوت این است که احتمال دارد توکن ERC-223 توابع `approve` + `transferFrom` را نداشته باشد، چرا که آنها در این استاندارد اختیاری هستند.
+
+#### مثالهای Solidity{#solidity-example}
+
+مثالهای زیر نشان میدهد که چگونه یک قرارداد ساده و اولیه توکن ERC-223 عمل میکند:
+
+```solidity
+pragma solidity ^0.8.19;
+abstract contract IERC223Recipient {
+ function tokenReceived(address _from, uint _value, bytes memory _data) public virtual;
+}
+contract VeryBasicERC223Token {
+ event Transfer(address indexed from, address indexed to, uint value, bytes data);
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+ uint256 private _totalSupply;
+ mapping(address => uint256) private balances;
+ function name() public view returns (string memory) { return _name; }
+ function symbol() public view returns (string memory) {return _symbol; }
+ function decimals() public view returns (uint8) { return _decimals; }
+ function totalSupply() public view returns (uint256) { return _totalSupply; }
+ function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; }
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ assembly { size := extcodesize(account) }
+ return size > 0;
+ }
+ function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);
+ }
+ emit Transfer(msg.sender, _to, _value, _data);
+ return true;
+ }
+ function transfer(address _to, uint _value) public returns (bool success){
+ bytes memory _empty = hex"00000000";
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);
+ }
+ emit Transfer(msg.sender, _to, _value, _empty);
+ return true;
+ }
+}
+```
+
+حال ما به یک قرارداد دیگر نیاز داریم تا واریز `tokenA` را بپذیرد، با فرض اینکه توکن A یک توکن ERC-223 است. این قرارداد باید فقط توکن A را بپذیرد و هر توکن دیگری را رد کند. زمانی که قرارداد توکن A را دریافت میکند، باید یک رویداد `Deposit()` را اطلاع رسانی کند و مقدار متغیر داخلی `deposits` را افزایش دهد.
+
+کد مذکور به این شکل است:
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Deposit(address whoSentTheTokens);
+ uint256 deposits = 0;
+ address tokenA; // The only token that we want to accept.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ // It is important to understand that within this function
+ // msg.sender is the address of a token that is being received,
+ // msg.value is always 0 as the token contract does not own or send Ether in most cases,
+ // _from is the sender of the token transfer,
+ // _value is the amount of tokens that was deposited.
+ require(msg.sender == tokenA);
+ deposits += _value;
+ emit Deposit(_from);
+ }
+}
+```
+
+## سوالات متداول {#faq}
+
+### اگر مقداری از توکن B به قرارداد بفرستیم، چه اتفاقی خواهد افتاد؟ {#sending-tokens}
+
+تراکنش شکست خواهد خورد و انتقال توکنها انجام نخواهد شد. توکنها به آدرس فرستنده بازگشت داده خواهند شد.
+
+### چگونه میتوانیم به این قرارداد واریز انجام دهیم؟ {#contract-deposits}
+
+تابع `transfer(address,uint256)` یا `transfer(address,uint256,bytes)` از توکن ERC-223 را با مشخص کردن آدرس `RecipientContract`، فراخوانی کنید.
+
+### اگر یک توکن ERC-20 را به این قرارداد ارسال کنیم، چه اتفاقی خواهد افتاد؟ {#erc-20-transfers}
+
+اگر یک توکن ERC-20 به `RecipientContract` ارسال کنیم، توکنها انتقال خواهند یافت اما این انتقال شناسایی نخواهد شد (هیچ رویداد `Deposit()` اجرا نخواهد شد و مقدار واریزیها تغییر نخواهد کرد). از واریزهای ERC-20 ناخواسته نمیتوان جلوگیری کرد.
+
+### چه میشود اگر بخواهیم پس از تکمیل انتقال توکن، تابع دیگری را اجرا کنیم؟ {#function-execution}
+
+برای انجام دادن این کار راههای مختلف وجود دارد. در این مثال ما روشی را دنبال خواهیم کرد که باعث میشود انتقال ERC-223 مشابه انتقال اتر شود:
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Foo();
+ event Bar(uint256 someNumber);
+ address tokenA; // The only token that we want to accept.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ require(msg.sender == tokenA);
+ address(this).call(_data); // Handle incoming transaction and perform a subsequent function call.
+ }
+ function foo() public
+ {
+ emit Foo();
+ }
+ function bar(uint256 _someNumber) public
+ {
+ emit Bar(_someNumber);
+ }
+}
+```
+
+هنگامی که `RecipientContract` یک توکن ERC-223 را دریافت میکند، درست همانطور که تراکنشهای ارسال اتر فراخوانی توابع را بعنوان `data` در تراکنش کدنگاری میکنند، قرارداد نیز تابعی را که به عنوان متغیر `_data` در تراکنش توکن کدنگاری شده است اجرا خواهد کرد. برای اطلاعات بیشتر [دیتا فیلد](https://ethereum.org/en/developers/docs/transactions/#the-data-field) را مطالعه فرمائید.
+
+در مثال بالا، توکن ERC-223 باید با استفاده از تابع `transfer(address,uin256,bytes calldata _data)` به آدرس `RecipientContract` انتقال یابد. اگر مقدار پارامتر دیتا `0xc2985578` باشد (معادل امضاء تابع `foo()`)، بعد از دریافت توکن واریزی و اجراء رویداد Foo()، تابع foo() اجرا خواهد شد.
+
+پارامترها (متغیرهای ورودی) نیز میتوانند در `data` انتقال توکن کدنگاری شوند، برای مثال ما میتوانیم تابع bar() را با مقدار 12345 برای `_someNumber` اجرا کنیم. در این حالت مقدار `data` باید
+`0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` باشد به شکلی که
+`0x0423a132` امضاء تابع `bar(uint256)` است و
+`00000000000000000000000000000000000000000000000000000000000004d2` همان 12345 است در قالب uint256.
+
+## محدودیتها {#limitations}
+
+در حالی که ERC-223 به چندین مشکل پیدا شده در استاندارد ERC-20 میپردازد، خودش محدودیتهای خاص خود را دارد:
+
+- پذیرش و سازگاری: ERC-223 هنوز به صورت فراگیر پذیرفته و پیادهسازی نشده است که باعث محدود شدن سازگاری آن با ابزارها و پلتفرمهای موجود میشود.
+- پیش سازگاری: ERC-223 با ERC-20 پیش سازگار نیست، یعنی قراردادها و ابزارهای موجود برای ERC-20، باید برای کار کردن با ERC-223 اصلاح شوند.
+- هزینه گاز: بررسیها و عملکردهای اضافه در تراکنشهای انتقال ERC-223 میتوانند منجر به هزینههای گاز بیشتر در مقایسه با تراکنشهای ERC-20 شوند.
+
+## ادامه مطلب {#further-reading}
+
+- [EIP-223: استاندارد توکن ERC-223](https://eips.ethereum.org/EIPS/eip-223)
+- [پیشنهاد اولیه ERC-223](https://github.com/ethereum/eips/issues/223)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md
new file mode 100644
index 00000000000..d63e8389c47
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md
@@ -0,0 +1,211 @@
+---
+title: ERC-4626 استاندارد خزانه توکنیزه شده
+description: استانداری برای خزانههای سودده.
+lang: fa
+---
+
+## مقدمه {#introduction}
+
+ERC-4626 استانداردی برای بهینهسازی و یکپارچهسازی متغیرهای فنی خزانههای سودده میباشد. این الگو یک API (وبسرویس) استاندارد را برای ارتباط با خزانههای سودده توکنیزه شده که نشانگر ارزش سهمی یک توکن ERC-20 پایه هستند، فراهم میکند. ERC-4626 همچنین یک افزونهی اختیاری را برای خزانههای توکنیزه شدهای که از توکنهای ERC-20 استفاده میکنند، ترسیم میکند که شامل عملکرد حداقلی برای سپردهگذاری، برداشت و نمایش موجودی توکنها است.
+
+**نقش استاندارد ERC-4626 در خزانههای سودده**
+
+بازارهای وامدهی، گردآورندگان و توکنهایی که ذاتا سودده هستند، به کاربران کمک میکنند تا با اجرای استراتژیهای متخلف، بهترین سود را برای توکنهای رمزارز پیدا کنند. این استراتژیها در انواع کم تفاوتی پیادهسازی میشوند که میتواند منجر به خطا یا هدر رفت منابع توسعه شود.
+
+استاندارد ERC-4626 با ایجاد الگوهای پیادهسازی پایدار و نبوغ آمیز، باعث کاهش زحمت یکپارچهسازی خزانههای سودده خواهد شد و امکان دسترسی به قابلیت کسب سود در اپلیکیشنهای مختلف را، با صرف کمترین دانش فنی از سوی برنامه نویسان فراهم میکند.
+
+توکن ERC-4626 به طور کامل در [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) توضیح داده شده است.
+
+## پیش نیاز ها {#prerequisites}
+
+برای درک بهتر مطالب این صفحه، به شما پیشنهاد میکنیم تا ابتدا دربارهی [استانداردهای توکن](/developers/docs/standards/tokens/) و [ERC-20](/developers/docs/standards/tokens/erc-20/) مطالعه بفرمائید.
+
+## توابع و ویژگی های ERC-4626: {#body}
+
+### روشها {#methods}
+
+#### asset {#asset}
+
+```solidity
+function asset() public view returns (address assetTokenAddress)
+```
+
+این تابع، آدرس توکن پایه را که در خزانه برای واریز، برداشت و حسابداری مورد استفاده قرار میگیرد، فراخوانی میکند.
+
+#### totalAssets {#totalassets}
+
+```solidity
+function totalAssets() public view returns (uint256)
+```
+
+این تابع، مجموع مقدار توکن پایه را که در خزانه نگهداری میشود نشان میدهد.
+
+#### convertToShares {#convertoshares}
+
+```solidity
+function convertToShares(uint256 assets) public view returns (uint256 shares)
+```
+
+این تابع مقدار `سهمی` که خزانه در ازای مقدار `دارایی` معاوضه خواهد کرد را نشان میدهد.
+
+#### convertToAssets {#convertoassets}
+
+```solidity
+function convertToAssets(uint256 shares) public view returns (uint256 assets)
+```
+
+این تابع مقدار `سهمی` که خزانه در ازای مقدار `دارایی (توکن پایه)` معاوضه خواهد کرد را نشان میدهد.
+
+#### maxDeposit {#maxdeposit}
+
+```solidity
+function maxDeposit(address receiver) public view returns (uint256 maxAssets)
+```
+
+این تابع حداکثر مقدار توکن پایه قابل واریز را که میتواند در یک تراکنش [`deposit`](#deposit) توسط `receiver` اجرا شود، نمایش میدهد.
+
+#### previewDeposit {#previewdeposit}
+
+```solidity
+function previewDeposit(uint256 assets) public view returns (uint256 shares)
+```
+
+این تابع به کاربران اجازه میدهد تاثیر تراکنش واریز خود را بر بلوک فعلی شبیهسازی کنند.
+
+#### deposit {#deposit}
+
+```solidity
+function deposit(uint256 assets, address receiver) public returns (uint256 shares)
+```
+
+این تابع `دارایی` یا همان توکن پایه را به خزانه واریز میکند و حق مالکیت `سهام (shares)` را به `گیرنده (receiver)` اعطا میکند.
+
+#### maxMint {#maxmint}
+
+```solidity
+function maxMint(address receiver) public view returns (uint256 maxShares)
+```
+
+این تابع حداکثر مقدار سهامی که در یک تراکنش [`mint`](#mint) توسط `receiver` میتواند ضرب شود را نمایش میدهد.
+
+#### previewMint {#previewmint}
+
+```solidity
+function previewMint(uint256 shares) public view returns (uint256 assets)
+```
+
+این تابع به کاربران اجازه میدهد تا تاثیر تراکنش ضرب دارایی خود را بر بلوک فعلی شبیهسازی کنند.
+
+#### ضرب سکه {#mint}
+
+```solidity
+function mint(uint256 shares, address receiver) public returns (uint256 assets)
+```
+
+این تابع با واریز مقدار `assets` از توکن پایه، دقیقاً به مقدار `shares` از سهام خزانه را برای آدرس `receiver` صادر میکند.
+
+#### maxWithdraw {#maxwithdraw}
+
+```solidity
+function maxWithdraw(address owner) public view returns (uint256 maxAssets)
+```
+
+این تابع حداکثر مقدار توکن پایه که در یک تراکنش برداشت یا [`withdraw`](#withdraw) توسط `owner` میتواند برداشت شود را نمایش میدهد.
+
+#### previewWithdraw {#previewwithdraw}
+
+```solidity
+function previewWithdraw(uint256 assets) public view returns (uint256 shares)
+```
+
+این تابع به کاربران اجازه میدهد تا تاثیر تراکنش برداشت دارایی (توکن پایه) خود را بر بلوک فعلی شبیهسازی کنند.
+
+#### عقب نشینی {#withdraw}
+
+```solidity
+function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
+```
+
+این تابع مقدار `shares` یا سهام را از آدرس `owner` میسوزاند و دقیقاً به مقدار `assets`، توکن پایه را از خزانه به آدرس `receiver` ارسال میکند.
+
+#### maxRedeem {#maxredeem}
+
+```solidity
+function maxRedeem(address owner) public view returns (uint256 maxShares)
+```
+
+این تابع حداکثر مقدار سهام را که از موجودی `owner`، از طریق اجرای تابع [`redeem`](#redeem) میتوان برداشت کرد، نشان میدهد.
+
+#### previewRedeem {#previewredeem}
+
+```solidity
+function previewRedeem(uint256 shares) public view returns (uint256 assets)
+```
+
+این تابع به کاربران اجازه میدهد تا تأثیر تراکنش بازخرید سهام (redeem) خود را بر روی بلوک فعلی شبیه سازی نمایند.
+
+#### redeem {#redeem}
+
+```solidity
+function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
+```
+
+این تابع مقدار مشخصی از `shares` را از جانب `owner` بازخرید میکند و به مقدار `assets`، توکن پایه از خزانه به آدرس `receiver` ارسال میکند.
+
+#### totalSupply {#totalsupply}
+
+```solidity
+function totalSupply() public view returns (uint256)
+```
+
+مقدار مجموع سهمهای خزانه بازخرید نشده که در گردش هستند را نشان میدهد.
+
+#### balanceOf {#balanceof}
+
+```solidity
+function balanceOf(address owner) public view returns (uint256)
+```
+
+مقدار مجموع سهمهای خزانه ای که `owner` در حال حاضر مالک آنها میباشد را نشان میدهد.
+
+### نقشه رابط برنامه نویسی {#mapOfTheInterface}
+
+![نقشه رابط برنامه نویسی ERC-4626](./map-of-erc-4626.png)
+
+### رویدادها {#events}
+
+#### رویداد واریز
+
+**باید** زمانی که توکنها از طریق توابع [`mint`](#mint) و [`deposit`](#deposit) به درون خزانه واریز میشوند، اجرا شود
+
+```solidity
+event Deposit(
+ address indexed sender,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+`sender` کاربری میباشد که مقدار `assets` را در ازای مقدار `shares` مبادله کرده و مقدار `shares` را به آدرس `owner` انتقال داده است.
+
+#### رویداد برداشت
+
+**باید** زمانی که سهمها توسط یک سپرده گذار با استفاده از توابع [`redeem`](#redeem) یا [`withdraw`](#withdraw) برداشت میشوند، اجرا شود.
+
+```solidity
+event Withdraw(
+ address indexed sender,
+ address indexed receiver,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+`sender` کاربری میباشد که تراکنش برداشت را اجرا نموده و مقدار `shares` را که `owner` مالک آن بوده، در ازای مقدار `assets` مبادله کرده است. `receiver` آدرس کاربری میباشد که مقدار `asset` را دریافت کرده است.
+
+## بیشتر بخوانید {#further-reading}
+
+- [ERC-4626 استاندارد خزانه توکنیزه شده](https://eips.ethereum.org/EIPS/eip-4626)
+- [ERC-4626: در Repo گیت هاب](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md
new file mode 100644
index 00000000000..64dda3bab51
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md
@@ -0,0 +1,244 @@
+---
+title: ERC-721 استاندارد توکن تعویض ناپذیر
+description:
+lang: fa
+---
+
+## معرفی {#introduction}
+
+**توکن تعویض ناپذیر چیست؟**
+
+از یک توکن تعویض ناپذیر (NFT) برای شناسایی چیزی یا شخصی به روشی منحصر به فرد استفاده می شود. این نوع توکن برای استفاده در پلتفرم هایی که آیتم های کلکسیونی، کلیدهای دسترسی، بلیط های بخت آزمایی، صندلی های شماره دار دارند و همچنین برای کنسرت ها و مسابقات ورزشی و غیره مناسب می باشد. این نوع خاص از توکن دارای امکانات شگفت انگیزی است، بنابراین سزاوار استانداردی مناسب است، بنابراین ERC-721 برای حل آن آمده است!
+
+**ERC-721 چیست؟**
+
+ERC-721 استانداردی را برای NFT معرفی می کند، به عبارت دیگر، شاید به دلیل قدمت، کمیاب بودن یا حتی چیز دیگری همچون ظاهر آن، این نوع توکن منحصر به فرد است و می تواند ارزش متفاوتی نسبت به توکن دیگری از همان قرارداد هوشمند را داشته باشد. صبر کنید، ظاهر؟
+
+بله! همه NFT ها دارای یک متغیر `uint256` به نام `tokenId` هستند، بنابراین برای هر قرارداد ERC-721، جفت `contract address، uint256 tokenId` باید در سطح جهانی یکتا باشد. گفته می شود، یک dapp می تواند یک "مبدل" داشته باشد که از `tokenId` به عنوان ورودی استفاده می کند و تصویری از چیز جالبی مانند زامبی ها، سلاح ها، مهارت ها یا بچه گربه های شگفت انگیز را خروجی می دهد!
+
+## پیش نیاز ها {#prerequisites}
+
+- [حساب ها](/developers/docs/accounts/)
+- [↳ قراردادهای هوشمند](/developers/docs/smart-contracts/)
+- [استانداردهای توکن](/developers/docs/standards/tokens/)
+
+## Body {#body}
+
+ERC-721 (درخواست اتریوم برای نظرات 721)، که توسط ویلیام انتریکن، دیتر شرلی، جیکوب ایوانز، ناستاسیا ساکس در ژانویه 2018 پیشنهاد شد، یک استاندارد توکن تعویض ناپذیر است که یک API برای توکنها در قراردادهای هوشمند پیادهسازی میکند.
+
+این ویژگی عملکردهایی مانند انتقال توکن ها از یک حساب به حساب دیگر، دریافت موجودی رمز فعلی یک حساب، به دست آوردن صاحب یک توکن خاص و نیز کل عرضه توکن موجود در شبکه را ارائه می دهد. علاوه بر اینها، عملکردهای دیگری همچون تأیید مقدار توکنی که از یک حساب می تواند توسط یک حساب شخص ثالث منتقل شود، را نیز در خود دارد.
+
+اگر یک قرارداد هوشمند، توابع و رویدادهای زیر را پیادهسازی کند، میتوان آن را یک قرارداد توکن تعویض ناپذیر ERC-721 نامید و پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
+
+از [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
+
+### روشها {#methods}
+
+```solidity
+ function balanceOf(address _owner) external view returns (uint256);
+ function ownerOf(uint256 _tokenId) external view returns (address);
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function approve(address _approved, uint256 _tokenId) external payable;
+ function setApprovalForAll(address _operator, bool _approved) external;
+ function getApproved(uint256 _tokenId) external view returns (address);
+ function isApprovedForAll(address _owner, address _operator) external view returns (bool);
+```
+
+### رویدادها {#events}
+
+```solidity
+ event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
+ event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
+ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
+```
+
+### مثالها {#web3py-example}
+
+بیایید ببینیم یک استاندارد چقدر مهم است که کار ما را برای بررسی قراردادهای هوشمند ERC-721 آسان میکند. ما فقط به رابط دوتایی برنامه قرارداد (ABI) برای ایجاد یک رابط برای هر توکن ERC-721 نیاز داریم. همانطور که در زیر می بینید ما از یک ABI ساده شده استفاده می کنیم تا آن را به عنوان مثالی با اصطکاک کم تبدیل کنیم.
+
+#### مثال Web3.py {#web3py-example}
+
+ابتدا مطمئن شوید که کتابخانه پایتون [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) را نصب کرده اید:
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+from web3._utils.events import get_event_data
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract
+
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction
+
+# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract.
+# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'name',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'ownerOf',
+ 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+]
+
+ck_extra_abi = [
+ {
+ 'inputs': [],
+ 'name': 'pregnantKitties',
+ 'outputs': [{'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],
+ 'name': 'isPregnant',
+ 'outputs': [{'name': '', 'type': 'bool'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
+name = ck_contract.functions.name().call()
+symbol = ck_contract.functions.symbol().call()
+kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
+print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}")
+
+pregnant_kitties = ck_contract.functions.pregnantKitties().call()
+print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}")
+
+# Using the Transfer Event ABI to get info about transferred Kitties.
+tx_event_abi = {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'from', 'type': 'address'},
+ {'indexed': False, 'name': 'to', 'type': 'address'},
+ {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'Transfer',
+ 'type': 'event'
+}
+
+# We need the event's signature to filter the logs
+event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
+
+logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [event_signature]
+})
+
+# Notes:
+# - Increase the number of blocks up from 120 if no Transfer event is returned.
+# - If you didn't find any Transfer event you can also try to get a tokenId at:
+# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
+# Click to expand the event's logs and copy its "tokenId" argument
+recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
+
+if recent_tx:
+ kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above
+ is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
+ print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}")
+```
+
+قرارداد CryptoKitties دارای رویدادهای جالبی به غیر از موارد استاندارد است.
+
+بیایید دو مورد از آنها، `حامله` و `تولد` را بررسی کنیم.
+
+```python
+# Using the Pregnant and Birth Events ABI to get info about new Kitties.
+ck_extra_events_abi = [
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],
+ 'name': 'Pregnant',
+ 'type': 'event'
+ },
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'genes', 'type': 'uint256'}],
+ 'name': 'Birth',
+ 'type': 'event'
+ }]
+
+# We need the event's signature to filter the logs
+ck_event_signatures = [
+ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
+]
+
+# Here is a Pregnant Event:
+# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
+pregnant_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[0]]
+})
+
+recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
+
+# Here is a Birth Event:
+# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
+birth_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[1]]
+})
+
+recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
+```
+
+## NFT های محبوب {#popular-nfts}
+
+- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) برترین NFT در اتریوم را بر اساس حجم نقل و انتقالات فهرست می کند.
+- [CryptoKitties](https://www.cryptokitties.co/) یک بازی حول موجودات قابل پرورش، کلکسیونی و بسیار شایان ستایش است که به آنها CryptoKitties می گوییم.
+- [Sorare](https://sorare.com/) یک بازی فوتبال فانتزی جهانی است که در آن میتوانید کلکسیونهای نسخههای محدودی را جمعآوری کنید، تیمهای خود را مدیریت کنید و برای کسب جوایز به رقابت بپردازید.
+- [سرویس نام اتریوم (ENS)](https://ens.domains/) یک & روش غیرمتمرکز برای آدرسدهی منابع هم در داخل و هم خارج از بلاک چین با استفاده از نامهای ساده و قابل خواندن برای انسان می باشد.
+- [POAP](https://poap.xyz) NFTهای رایگان را به افرادی که در رویدادها شرکت می کنند یا اقدامات خاصی را انجام می دهند ارائه می دهد. ایجاد و توزیع POAP ها رایگان است.
+- [Unstoppable Domains](https://unstoppabledomains.com/) یک شرکت مستقر در سانفرانسیسکو است که دامنههای خود را بر روی بلاک چین ها می سازد. دامنههای بلاک چین آدرسهای ارزهای دیجیتال را با نامهای قابل خواندن برای انسان جایگزین میکنند و میتوان از آنها برای فعال کردن وبسایتهای مقاوم در برابر سانسور استفاده کرد.
+- [Gods Unchained Cards](https://godsunchained.com/) یک TCG در بلاک چین اتریوم است که از NFT برای ایجاد مالکیت واقعی بر داراییهای درون بازی استفاده میکند.
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com) مجموعه ای از 10000 NFT منحصر به فرد است که علاوه بر اینکه یک اثر هنری نادر است، به عنوان نماد عضویت در باشگاه عمل می کند و امتیازات و مزایایی را برای اعضا فراهم می کند که در نتیجه تلاش های جامعه در طول زمان افزایش می یابد.
+
+## بیشتر بخوانید {#further-reading}
+
+- [EIP-721: استاندارد توکن تعویض ناپذیر ERC-721](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - مستندات ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - پیاده سازی ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..e9e07e78e33
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,77 @@
+---
+title: 'EIP-: استاندارد توکن ERC-777'
+description:
+lang: fa
+---
+
+## {#introduction}
+
+****
+
+****
+
+قلاب ها تابعی هستند که در کد یک قرارداد هوشمند توضیح داده شده است. هنگامی که توکن ها از طریق یک قرارداد ارسال یا دریافت می شوند، قلاب ها فراخوانی می شوند. این به یک قرارداد هوشمند اجازه می دهد تا به توکن های ورودی یا خروجی واکنش نشان دهد.
+
+## {#prerequisites}
+
+- []()
+- []()
+- []()
+
+## {#body}
+
+قلاب ها با استفاده از استاندارد [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)ثبت و کشف میشوند.
+
+این استاندارد همچنین ابهامی را که در مورد `اعشار` ایجاد شده در ERC-20 وجود دارد حل می کند. این شفافیت باعث بهبود تجربه توسعه دهنده می شود.
+
+می توان با قراردادهای ERC-777 به گونه ای تعامل کرد که انگار قراردادهای ERC-20 هستند.
+
+### {#methods}
+
+```solidity
+
+```
+
+### {#events}
+
+```solidity
+
+```
+
+### {#web3py-example}
+
+#### {#web3py-example}
+
+```
+
+```
+
+```python
+
+
+
+
+```
+
+```python
+
+
+```
+
+## {#popular-nfts}
+
+-
+-
+-
+-
+-
+-
+-
+-
+
+## اطلاعات بیشتر {#further-reading}
+
+- []()
+- []()
+- []()
+- []()
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md
new file mode 100644
index 00000000000..ac7c811e1a5
--- /dev/null
+++ b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md
@@ -0,0 +1,39 @@
+---
+title: استانداردهای توکن
+description:
+lang: fa
+incomplete: true
+---
+
+## معرفی {#introduction}
+
+بسیاری از استانداردهای توسعه اتریوم بر روی رابط های توکن تمرکز دارند. این استانداردها کمک میکنند تا اطمینان حاصل شود که قراردادهای هوشمند قابل تنظیم باقی میمانند، بهعنوان مثال، زمانی که یک پروژه جدید یک توکن صادر میکند که با صرافیهای غیرمتمرکز موجود سازگار باقی بماند.
+
+## پیش نیاز ها {#prerequisites}
+
+- [استانداردهای توسعه اتریوم](/developers/docs/standards/)
+- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
+
+## استانداردهای توکن {#token-standards}
+
+در اینجا برخی از محبوب ترین استانداردهای توکن در اتریوم آمده است:
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - یک رابط استاندارد برای توکنهای تعویضپذیر (قابل تعویض)، مانند توکنهای رایگیری، توکنهای شرطبندی یا ارزهای مجازی می باشد.
+
+### استانداردهای NFT {#nft-standards}
+
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - یک رابط استاندارد برای توکنهای تعویض ناپذیر، مانند یک سند برای اثر هنری یا یک آهنگ است.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 امکان معاملات کارآمدتر و بستهبندی تراکنشها را فراهم میکند - بنابراین در هزینهها صرفهجویی میشود. این استاندارد توکن امکان ایجاد توکن های کاربردی (مانند $BNB یا $BAT) و توکن های تعویض ناپذیر مانند CryptoPunks را فراهم می کند.
+
+فهرست کامل پیشنهادهای [ERC](https://eips.ethereum.org/erc).
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [چک لیست ادغام توکن ها](/developers/tutorials/token-integration-checklist/) _– چک لیستی از مواردی که باید هنگام تعامل با توکن ها در نظر بگیرید._
+- [با قرارداد هوشمند توکن ERC20 آشنا شوید](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– مقدمه ای برای استقرار اولین قرارداد هوشمندتان بر روی یک شبکه آزمایشی اتریوم._
+- [انتقال و تایید توکن های ERC20 از یک قرارداد هوشمند Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– نحوه استفاده از قرارداد هوشمند برای تعامل با توکن با استفاده از زبان Solidity._
+- [پیاده سازی یک بازار ERC721 [راهنمای نحوه انجام]](/developers/tutorials/how-to-implement-an-erc721-market/) _– چگونه اقلام توکن دار را برای فروش بر روی یک تابلوی طبقه بندی غیرمتمرکز قرار دهیم._
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md"
new file mode 100644
index 00000000000..01bbb6a1bfa
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md"
@@ -0,0 +1,114 @@
+---
+title: مقیاسپذیری
+description: مقدمهای بر گزینههای مختلف مقیاسپذیری که در حال حاضر توسط انجمن اتریوم در حال توسعه هستند.
+lang: fa
+sidebarDepth: 3
+---
+
+## نمای کلی مقیاسبندی {#scaling-overview}
+
+با افزایش تعداد افرادی که از اتریوم استفاده میکنند، بلاک چین به محدودیتهای ظرفیت خاصی رسیده است. این امر هزینه استفاده از شبکه را بالا برده و نیاز به "راهحلهای مقیاسبندی" را ایجاد کرده است راهحلهای متعددی در حال تحقیق، آزمایش و پیادهسازی هستند که رویکردهای متفاوتی برای دستیابی به اهداف مشابه دارند.
+
+هدف اصلی مقیاسپذیری افزایش سرعت تراکنش (پایانپذیری سریعتر) و توان عملیاتی تراکنش (تعداد تراکنشهای بیشتر در ثانیه) بدون به خطر انداختن تمرکززدایی یا امنیت است (اطلاعات بیشتر درباره [دورنمای اتریوم](/roadmap/vision/) الف>). در لایه 1 بلاک چین اتریوم، تقاضای بالا منجر به معاملات کندتر و [قیمتهای گس](/developers/docs/gas/) بسیار زیاد میشود. افزایش ظرفیت شبکه از نظر سرعت و توان عملیاتی برای پذیرش معنادار و انبوه اتریوم اساسی است.
+
+در حالی که سرعت و توان عملیاتی مهم هستند، ضروری است که راه حلهای مقیاسبندی که این اهداف را قادر میسازند، غیرمتمرکز و ایمن باقی بمانند. برداشتن مانع ورود برای اپراتورهای گره برای جلوگیری از پیشرفت به سمت قدرت محاسباتی متمرکز و ناامن بسیار مهم است.
+
+از لحاظ مفهومی، ما ابتدا مقیاسبندی را به عنوان مقیاسبندی روی زنجیره یا مقیاسبندی خارج از زنجیره طبقهبندی میکنیم.
+
+## پیش نیاز ها {#prerequisites}
+
+شما باید درک خوبی از تمام موضوعات اساسی داشته باشید. اجرای راهحلهای مقیاسبندی، پیشرفته است زیرا این فناوری کمتر آزمایش شده و همچنان به تحقیق و توسعه ادامه میدهد.
+
+## مقیاسبندی روی زنجیره {#on-chain-scaling}
+
+مقیاسبندی روی زنجیره به تغییراتی در پروتکل اتریوم نیاز دارد (لایه 1 [میننت یا شبکه اصلی](/glossary/#mainnet)). برای مدت طولانی انتظار میرفت که خرد یا شارد کردن، بلاک چین اتریوم را مقیاسپذیر کند. این مورد شامل تقسیم بلاک چین به قطعات گسسته (شاردها) بود تا توسط زیرمجموعههای اعتبارسنج تأیید شود. با این حال، مقیاسبندی توسط لایههای ۲ به عنوان تکنیک مقیاسبندی اولیه انتخاب شده است. این مورد با افزودن شکل ارزانتری از دادههای متصل به بلوکهای اتریوم پشتیبانی میشود که بهویژه برای ارزانتر کردن رولآپها برای کاربران طراحی شده است.
+
+### زنجیره ای سازی {#sharding}
+
+زنجیرهایسازی فرآیند تقسیم یک پایگاه داده است. زیرمجموعههای اعتبارسنجها به جای پیگیری کل اتریوم، مسئول شارد هستند. زنجیرهایسازی برای مدت طولانی در [نقشه راه](/roadmap/) اتریوم بود و زمانی قرار بود قبل از ارتقاء ادغام برای اثبات سهام انجام شود. با این حال، توسعه سریع [مجموعههای لایه 2](#layer-2-scaling) و اختراع [دنک شاردینگ](/roadmap/danksharding) (افزودن حبابهای رولآپ دادهها به بلوکهای اتریوم که میتوانند بهطور کارآمدی توسط اعتبارسنجها تأیید شوند) باعث شده که جامعه اتریوم به جای مقیاسبندی با شاردینگ، از مقیاسبندی رولآپ محور حمایت کند. این مورد همچنین به سادهتر ماندن منطق اجماع اتریوم کمک میکند.
+
+## مقیاسبندی آفچین یا خارج زنجیره {#off-chain-scaling}
+
+راه حلهای خارج از زنجیره به طور جداگانه از لایه 1 میننت یا همان شبکه اصلی پیادهسازی میشوند - آنها نیازی به تغییر در پروتکل موجود اتریوم ندارند. برخی راهحلها، که به عنوان راهحلهای "لایه 2" شناخته میشوند، امنیت خود را مستقیماً از اجماع لایه 1 اتریوم به دست میآورند، مانند [آپتیمیستیک رولآپها](/developers/docs/scaling/optimistic-rollups/)، [مجموعههای دانش صفر](/developers/docs/scaling/zk-rollups/) یا [کانالهای حالت یا استیت](/developers/docs/scaling/state-channels/). راه حلهای دیگر شامل ایجاد زنجیرههای جدید به اشکال مختلف است که امنیت خود را جدا از شبکه اصلی یا همان شبکه اصلی میگیرند، مانند [زنجیرههای جانبی](#sidechains)، [ولیدیومها](#validium) ، یا [زنجیرههای پلاسما](#plasma). این راه حلها با شبکه اصلی ارتباط برقرار میکنند، اما امنیت خود را به گونهای متفاوت برای دستیابی به اهداف مختلف دریافت میکنند.
+
+### مقیاسبندی لایه 2 {#layer-2-scaling}
+
+این دسته از راه حلهای خارج از زنجیره یا آفچین امنیت خود را از شبکه اصلی اتریوم میگیرند.
+
+لایه ۲ یک اصطلاح جمعی برای راهحلهایی است که برای کمک به مقیاسپذیری برنامه شما با مدیریت تراکنشهای خارج از شبکه اصلی اتریوم (لایه ۱) و در عین حال بهرهگیری از مدل امنیتی غیرمتمرکز قوی شبکه اصلی طراحی شدهاند. هنگامی که شبکه مشغول است، سرعت تراکنش کاهش مییابد و تجربه کاربر را برای انواع خاصی از برنامههای غیرمتمرکز ضعیف میکند. و با شلوغ شدن شبکه، قیمت گس افزایش مییابد زیرا فرستندگان تراکنش قصد دارند از یکدیگر پیشی بگیرند. این مورد میتواند استفاده از اتریوم را بسیار گران کند.
+
+اکثر راه حلهای لایه 2 حول یک سرور یا خوشهای از سرورها متمرکز شدهاند که هر یک از آنها ممکن است به عنوان یک گره، اعتبارسنج، اپراتور، ترتیبدهنده، تولید کننده بلوک یا اصطلاح مشابه نامیده شود. بسته به پیادهسازی، این گرههای لایه 2 ممکن است توسط افراد، شرکتها یا نهادهایی که از آنها استفاده میکنند، یا توسط یک اپراتور شخص ثالث، یا توسط گروه بزرگی از افراد (مشابه شبکه اصلی) اجرا شوند. به طور کلی، تراکنشها به جای ارسال مستقیم به لایه 1 (شبکه اصلی) به این گرههای لایه 2 ارسال میشوند. برای برخی از راه حلها، قبل از اینکه آنها را به لایه 1 متصل کند، نمونه لایه 2 سپس آنها را به گروهها تقسیم میکند، پس از آن توسط لایه 1 ایمن میشوند و نمیتوان آنها را تغییر داد. جزئیات نحوه انجام این کار بین فناوریها و پیادهسازیهای لایه 2 متفاوت است.
+
+یک نمونه لایه 2 خاص ممکن است باز باشد و توسط بسیاری از برنامهها به اشتراک گذاشته شود، یا ممکن است توسط یک پروژه مستقر شده و تنها به پشتیبانی از برنامه آنها اختصاص داده شود.
+
+#### چرا لایه 2 مورد نیاز است؟ {#why-is-layer-2-needed}
+
+- افزایش تراکنش در ثانیه تجربه کاربر را تا حد زیادی بهبود میبخشد و ازدحام شبکه را در شبکه اصلی اتریوم کاهش میدهد.
+- تراکنشها در یک تراکنش به شبکه اصلی اتریوم جمع میشوند و هزینههای گس را برای کاربران کاهش میدهند و اتریوم را درهرجا برای مردم فراگیرتر و در دسترستر میسازد.
+- هر گونه به روزرسانی مقیاسپذیری نباید به قیمت تمرکززدایی یا امنیت باشد - لایه 2 در بالای اتریوم ساخته میشود.
+- شبکههای لایه 2 ویژه برنامه وجود دارند که هنگام کار با داراییها در مقیاس، مجموعهای از کاراییهای خاص خود را دارند.
+
+[اطلاعات بیشتر در مورد لایه 2](/layer-2/).
+
+#### رولآپ ها {#rollups}
+
+رولآپها اجرای تراکنش را در خارج از لایه 1 انجام میدهند و سپس دادهها در لایه 1 ارسال میشوند که در آن اجماع حاصل میشود. از آنجایی که دادههای تراکنش در بلوکهای لایه 1 گنجانده شدهاند، این امکان را فراهم میکند تا رولآپها توسط امنیت بومی اتریوم ایمن شوند.
+
+دو نوع رولآپ با مدلهای امنیتی مختلف وجود دارد:
+
+- **رولآپهای آپتیمیستیک**: فرض میکند که تراکنشها به طور پیشفرض معتبر هستند و فقط محاسبات را در صورت چالش از طریق [](/glossary/#fraud-proof) اجرا میکند. [اطلاعات بیشتر در مورد آپتیمیستیک رولآپها](/developers/docs/scaling/optimistic-rollups/).
+- **رولآپ دانش-صفر**: محاسبات را خارج از زنجیره اجرا میکند و یک [ ](/glossary/#validity-proof) به زنجیره ارسال میکند. .
+
+#### عملیاتهای برون زنجیرهای {#channels}
+
+کانالهای استیت (State channels) از قراردادهای چند امضایی استفاده میکنند تا شرکتکنندگان را قادر سازد به سرعت و آزادانه خارج از زنجیره تراکنش انجام دهند، سپس نهایی شدن را با شبکه اصلی حل کنند. این کار شلوغی شبکه، هزینهها و تاخیرها را به حداقل میرساند. در حال حاضر دو نوع کانال وجود دارد که کانالهای استیت و کانالهای پرداخت هستند.
+
+.
+
+### زنجیرههای جانبی {#sidechains}
+
+زنجیره جانبی (Sidechain) یک بلاک چین مستقل سازگار با ماشین مجازی اتریوم است که به موازات شبکه اصلی اجرا میشود. این موارد از طریق پلهای دو طرفه با اتریوم سازگار هستند و تحت قوانین اجماع و پارامترهای بلوک انتخابی خودشان اجرا میشوند.
+
+درباره [زنجیرههای جانبی](/developers/docs/scaling/sidechains/) بیشتر بیاموزید.
+
+### پلاسما {#plasma}
+
+زنجیره پلاسما یک بلاک چین جداگانه است که به زنجیره اصلی اتریوم متصل است و از شواهد تقلب (مانند [آپتیمیستیک رولآپها](/developers/docs/scaling/optimistic-rollups/)) برای داوری اختلافات استفاده میکند.
+
+درباره [پلاسما](/developers/docs/scaling/plasma/) بیشتر بیاموزید.
+
+### والیدیوم (Validium) {#validium}
+
+زنجیره ولیدیوم (Validium) از اثبات اعتبار مانند رولآپهای دانش صفر استفاده میکند، اما دادهها در زنجیره اصلی لایه 1 اتریوم ذخیره نمیشوند. این مورد میتواند منجر به 10 هزار تراکنش در ثانیه در هر زنجیره ولیدیوم شود و چندین زنجیره میتوانند به صورت موازی اجرا شوند.
+
+درباره [ولیدیوم](/developers/docs/scaling/validium/) بیشتر بیاموزید.
+
+## چرا این همه راهحلهای مقیاسبندی مورد نیاز است؟ {#why-do-we-need-these}
+
+- راهحلهای متعدد میتوانند به کاهش ازدحام کلی در هر قسمت از شبکه کمک کرده و همچنین از نقاط شکست منفرد جلوگیری کنند.
+- کل، بزرگتر از مجموع اجزای آن است. راهحلهای مختلف میتوانند وجود داشته باشند و با هماهنگی کار کنند که اجازه میدهند اثری تصاعدی بر سرعت و توان عملیات آتی داشته باشند.
+- همه راهحلها به استفاده مستقیم از الگوریتم اجماع اتریوم نیاز ندارند و جایگزینها میتوانند مزایایی را ارائه دهند که اگر اینطور نباشد بهدست آوردن آنها دشوار خواهد بود.
+- برای تحقق [چشمانداز اتریوم](/roadmap/vision/)، تنها یک راهحل مقیاسپذیری کافی نیست.
+
+## با توضیحات تصویری راحتترید؟ {#visual-learner}
+
+
+
+_توجه داشته باشید که توضیح ویدیو از عبارت "لایه 2" برای اشاره به تمام راهحلهای مقیاسپذیری خارج از زنجیره استفاده میکند، در حالی که ما "لایه 2" را به عنوان یک راهحل خارج از زنجیره که امنیت خود را از طریق اجماع اصلی لایه 1 به دست میآورد متمایز میکنیم._
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [نقشه راه اتریوم با محوریت رولآپ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _ ویتالیک بوترین_
+- [تجزیه و تحلیل به روز راهحلهای مقیاسپذیری لایه 2 برای اتریوم](https://www.l2beat.com/)
+- [ارزیابی راهحلهای مقیاسپذیری لایه 2 اتریوم: یک چارچوب مقایسه](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955)
+- [راهنمای ناقص رولآپ ها](https://vitalik.eth.limo/general/2021/01/05/rollup.html)
+- [رولآپهای دانش صفر مبتنی بر اتریوم: رقبای جهانی](https://hackmd.io/@canti/rkUT0BD8K)
+- [رولآپهای آپتیمیستیک در مقابل رولآپهای دانش صفر](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/)
+- [مقیاسپذیری بلاک چین با دانش صفر](https://ethworks.io/assets/download/zero-knowledge-blockchain-scaling-ethworks.pdf)
+- [چرا رولآپ + دادههای شارد شده تنها راهحل پایدار برای مقیاسپذیری بالا هستند](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48)
+- [چه نوع لایه 3 بهتر است؟](https://vitalik.eth.limo/general/2022/09/17/layer_3.html)
+- [قابلیت دسترسی داده ها یا: رولآپها چطور یاد گرفتند دیگر نگران نباشند و اتریوم را دوست داشته باشند](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups)
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md"
new file mode 100644
index 00000000000..dabf7e143fe
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md"
@@ -0,0 +1,269 @@
+---
+title: رول آپ های خوش بینانه
+description: مقدمه ای بر رول آپهای خوش بینانه، یک راه حل مقیاس پذیری که توسط جامعه اتریوم استفاده میشود.
+lang: fa
+---
+
+رول آپهای خوش بینانه، پروتکلهای لایه دومی (L2) هستند که برای افزایش تعداد داده های ورودی لایه اصلی اتریوم طراحی شده اند. آنها محاسبات زنجیره اصلی اتریوم را با پردازش تراکنشها در خارج از زنجیره کاهش میدهند که باعث افزایش چشمگیر در سرعت پردازش میشوند. برخلاف سایر روشهای مقیاس پذیری مانند [زنجیرههای جانبی](/developers/docs/scaling/sidechains/)، رول آپهای خوش بینانه امنیت خود را از شبکه اصلی تأمین میکنند که این کار به وسیله انتشار نتیجه تراکنشها بر روی شبکه اصلی یا [زنجیرههای پلاسما](/developers/docs/scaling/plasma/) که تراکنشها را با استفاده از مکانیسم اثبات تقلب، تائید میکنند اما تراکنش را در جایی دیگر ذخیره میکنند، انجام میگیرد.
+
+از آنجایی که محسابات آهسته و پرهزینه ترین بخش از اتریوم میباشد، رول آپهای خوش بینانه میتوانند بهبود 10 الی 100 برابری را برای مقیاس پذیری ارائه دهند. همچنین رولآپ خوشبینانه تراکنشها را به صورت `calldata` یا [بلاب](/roadmap/danksharding/) در اتریوم وارد میکنند که باعث کاهش هزینه گاز مصرفی توسط کاربران میشود.
+
+## موارد مورد نیاز {#prerequisites}
+
+شما باید صفحات ما دربارهی [مقیاس پذیری اتریوم](/developers/docs/scaling/) و [لایه 2](/layer-2/) را خوانده باشید.
+
+## رولآپ خوشبینانه چیست؟ {#what-is-an-optimistic-rollup}
+
+رولآپ خوشبینانه رویکردی برای مقیاس پذیری اتریوم است که شامل انتقال محاسبات و ذخیره حالت (اطلاعات) به خارج از شبکه میشود. رولآپ خوشبینانه تراکنشها را خارج از اتریوم اجرا میکنند اما اطلاعات تراکنش را به صورت `calldata` یا [بلاب](/roadmap/danksharding/) به اتریوم ارسال میکنند.
+
+اپراتورهای رولآپ خوشبینانه، چندین تراکنش خارج زنجیرهای را در دستههای بزرگ دسته بندی میکند و سپس آنها را به اتریوم ارسال میکنند. این رویکرد باعث میشود تا هزینههای ثابت در چندین تراکنش در هر دسته توزیع شود و هزینهها برای کاربران کاهش یابد. همچنین رولآپ خوشبینانه از تکنیکهای فشرده سازی برای کاهش حجم داده ارسالی به اتریوم استفاده میکند.
+
+دلیل "خوشبین" رولآپ خوشبینانه این است که آنها فرض را بر این میگذارند که تراکنشهای خارج از زنجیره معتبر هستند و اثباتی را برای معتبر بودن دستههای تراکنش ارسالی بر روی شبکه منتشر نمیکنند. این امر باعث تمایز رولآپ خوشبینانه از [رولآپ دانش-صفر](/developers/docs/scaling/zk-rollups) که [اثبات اعتبار](/glossary/#validity-proof) را برای تراکنشهای خارج شبکه به صورت رمزنگاری شده منتشر میکند، میشود.
+
+در عوض، رولآپ خوشبینانه برای شناسائی مواردی که تراکنشها به درستی محاسبه نشدهاند، به یک طرح اثبات تقلب متکی است. پس از ارسال یک دسته رولآپ به اتریوم، یک بازه زمانی (به نام دوره چالش) وجود دارد که طی آن هرکسی میتواند با محاسبه [اثبات تقلب](/glossary/#fraud-proof)، نتایج یک رولآپ تراکنشها را به چالش بکشد.
+
+اگر اثبات تقلب با موفقیت انجام شود، پروتکل رولآپ، تراکنش(ها) را دوباره اجرا میکند و حالت رولآپهای مربوطه را بروز رسانی میکند. اثر دیگر موفقیت اثبات تقلب این میباشد که ترتیبدهندهای که مسئول گنجاندن تراکنش نادرست اجرا شده در یک بلوک است، جریمه خواهد شد.
+
+اگر یک رولآپ بدون چالش باقی بماند (برای مثال تمامی تراکنشها به درستی اجرا شده باشند)، پس گذشت دوره چالش، معتبر محسوب میشود و در اتریوم پذیرفته میشود. دیگران میتوانند بر روی یک بلوک رولآپ تائید نشده ادامه دهند اما باید این هشدار را در نظر بگیرند که: اگر براساس تراکنش نادرست اجرا شده از قبل منتشر شده باشند، نتایج آنها معکوس خواهد شد.
+
+## چگونه رولآپ خوشبینانه با اتریوم تعامل دارند؟ {#optimistic-rollups-and-Ethereum}
+
+رولآپ خوشبینانه، [راه حلهای مقیاس پذیری خارج زنجیرهای](/developers/docs/scaling/#off-chain-scaling) هستند که برای انجام عملیات در اتریوم ساخته شدند. هر رولآپ خوشبینانه توسط مجموعهای از قراردادهای هوشمند مستقر در شبکه اتریوم مدیریت میشود. رولآپ های خوشبینانه تراکنشها را خارج از شبکه اصلی اتریوم پردازش میکنند ولی این تراکنشهای خارج شبکهای را (به طور دستهای) به یک قرارداد رولآپ بر روی شبکه ارسال میکنند. همانند زنجیره اتریوم، این نتیجه ذخیره شده از تراکنش تغییرناپذیر است و "زنجیره رولآپ خوشبینانه" را شکل میدهد.
+
+ساختار یک رولآپ خوشبینانه متشکل از بخشهای زیر است:
+
+**قراردادهای هوشمند روی زنجیره**: عملیاتهای رولآپ های خوشبینانه توسط قراردادهای هوشمندی که بر روی اتریوم در حال اجرا هستند، کنترل میشوند. این شامل قراردادهایی میشود که بلوک رولآپ را ذخیره میکنند، بهروزرسانیهای حالت را در رولآپ نظارت میکنند و سپردههای کاربران را ردیابی میکنند. به این شکل، اتریوم نقش لایه پایه یا "لایه 1" را برای رولآپ های خوشبینانه دارد.
+
+**ماشین مجازی خارج از زنجیره (VM)**: اگرچه که قراردادهایی که پروتکل رولآپ خوشبینانه را مدیریت میکنند بر روی اتریوم اجرا میشوند، پروتکل رولآپ محاسبات و ذخیرهسازی حالت را در ماشین مجازی دیگری جدا از [ماشین مجازی اتریوم](/developers/docs/evm/) انجام میدهد. ماشین مجازی خارج از زنجیره جایی است که برنامهها در حال اجرا هستند و تغییرات حالت در آنجا رخ میدهند و این به عنوان لایه بالایی یا "لایه 2" برای یک رولآپ خوشبینانه عمل میکند.
+
+از آنجایی که رولآپ های خوشبینانه برای اجرای برنامههای نوشته شده یا کامپایل شده مخصوص EVM طراحی شدهاند، ماشین مجازی خارج زنجیره بسیاری از ارکان طراحی EVM را در خود به کار گرفته است. علاوه بر این، اجرا شدن مکانیسم اثبات تقلب بر روی شبکه به اتریوم اجازه میدهد تا موثق بودن تغییرات حالت محاسبه شده را در ماشین مجازی خارج از زنجیره اعمال کند.
+
+رولآپ خوشبینانه به عنوان "راه حلهای مقیاس پذیری ترکیبی" توصیف میشوند، زیرا در حالی که به عنوان پروتکلهای جداگانه وجود دارند، ویژگیهای امنیتی آنها از اتریوم مشتق شده است. از جمله موارد دیگر، اتریوم صحت محاسبات خارج از زنجیره رولآپ و در دسترس بودن داده های پشت محاسبات را تضمین میکند. این امر باعث میشود که رولآپ های خوشبینانه نسبت به پروتکلهای مقیاس پذیری کاملاً خارج از زنجیره (برای مثال [زنجیرههای جانبی](/developers/docs/scaling/sidechains/)) که برای امنیت به اتریوم متکی نیستند، امنتر باشند.
+
+رولآپ های خوشبینانه برای موارد زیر به پروتکل اصلی اتریوم متکی هستند:
+
+### دسترسی به دادهها {#data-availability}
+
+همانگونه که گفته شد، رولآپ های خوشبینانه دادههای تراکنش را به عنوان `calldata` یا [blobs](/roadmap/danksharding/) به اتریوم میفرستند. از آنجایی که اجرای زنجیرهی رولآپ براساس تراکنشهای ارسالی میباشد، هرکسی میتواند از این اطلاعات - که بر لایه پایه اتریوم لینک شده است - برای اجرای وضعیت جمعآوری و تایید صحت انتقال حالت استفاده کند.
+
+[در دسترس بودن اطلاعات](/developers/docs/data-availability/) بسیار مهم است زیرا بدون دسترسی به دادههای حالت، به چالش کشندگان نمیتوانند اثبات تقلب را برای مخالفت با عملیات رولآپ نامعتبر ایجاد نمایند. با فراهم کردن دسترسی به اطلاعات توسط اتریوم، ریسک قسر در رفتن اپراتورهای رولآپ با اعمال کثیف (مانند ارسال بلوکهای نامعتبر) کاهش میابد.
+
+### مقاومت در برابر سانسور {#censorship-resistance}
+
+همچنین، رولآپ های خوشبینانه برای مقاومت در برابر سانسور به اتریوم نیازمند هستند. در یک رولآپ خوشبینانه، یک نهاد متمرکز (اپراتور) مسئول پردازش تراکنشها و ارسال بلوکهای رولآپ به اتریوم است. این چندین پیامد احتمالی دارد:
+
+- اپراتورهای رولآپ میتوانند کاربران را با کاملاً آفلاین شدن یا با امتناع از تولید بلوکهایی که شامل تراکنشهای خاصی در آنها هستند، سانسور کنند.
+
+- اپراتورهای رولآپ میتوانند کاربران را از برداشتن وجوهی که در قرارداد رولآپ واریز کرده اند، با استفاده از نگه داشتن دادههای لازم جهت تغییر حالت درخت مرکل مالکیت، جلوگیری کنند. نگه داشتن دادههای حالت همچنین میتواند وضعیت رولآپ را از کاربران پنهان کند و مانع از تعامل آنان با رولآپ شود.
+
+رولآپ های خوشبینانه این مشکل را با مجبور کردن اپراتورها به انتشار دادههای مرتبط با بروز رسانیهای حالت در اتریوم حل میکند. انتشار اطلاعات رولآپ بر روی زنجیره اتریوم مزایای زیر را دارد:
+
+- اگر یک اپراتور رولآپ خوشبینانه آفلاین شود یا تولید دستههای تراکنش را متوقف کند، گره دیگری میتواند از دادههای موجود برای بازتولید آخرین وضعیت رولآپ برای ادامه تولید بلوک استفاده کند.
+
+- کاربران میتوانند از دادههای تراکنش برای ایجاد اثبات مالکیت دارایی در قالب درخت مرکل استفاده نمایند و داراییهای خود را از رولآپ برداشت کنند.
+
+- کاربران همچنین میتوانند تراکنشهای خود را در لایه پایه یا L1، به جای ترتیب دهنده ارسال کنند که در این صورت ترتیب دهنده باید تراکنش را در یک محدوده زمانی مشخص برای ادامه تولید بلوکهای معتبر لحاظ کند.
+
+### توافق {#settlement}
+
+نقش دیگری که اتریوم در زمینه گردآوری رولآپ های خوشبینانه ایفا میکند، لایه توافق است. لایه توافق تمامی اکوسیستم بلاکچین را به هم لینک میکند، امنیت را برقرار میکند و در صورت بروز تعارض در زنجیرهای دیگر (در این مورد رولآپ خوشبینانه) که نیاز به داوری دارد، رأی نهائی بی طرفانه را صادر میکند.
+
+شبکه اصلی اتریوم مرکزی را برای رولآپ های خوشبینانه فراهم میکند تا اثباتهای تقلب را تائید نمایند و تعارضها را حل کنند. علاوه بر این، تراکنشهای انجام شده در رولآپ، تنها _پس از_ پذیرش بلوک رولآپ در اتریوم نهائی میشوند. هنگامی که یک تراکنش رولآپ به لایه پایه اتریوم ارسال و متعهد شد، نمیتوان آن را به عقب بازگرداند (به جز در مورد بسیار غیرمحتمل سازماندهی مجدد زنجیره).
+
+## طرز کار رول آپهای خوش بینانه چگونه است؟ {#how-optimistic-rollups-work}
+
+### اجرای تراکنش وگردآوری {#transaction-execution-and-aggregation}
+
+کاربران تراکنشها را به "اپراتورها" ارسال میکنند، که گرههایی مسئول پردازش تراکنشها در جمعبندی خوشبینانه هستند. همچنین این اپراتور که بهعنوان "اعتبارسنج" یا "گردآورنده" نیز شناخته میشود، تراکنشها را گردآوری میکند، دادههای زیربنایی را فشرده سازی میکند و بلوک را در اتریوم منتشر میکند.
+
+اگرچه که هر کسی میتواند اعتبارسنج شود، اعتبارسنجهای رولآپ خوشبینانه، باید قبل از تولید بلوکها مانند [سیستم اثبات سهام](/developers/docs/consensus-mechanisms/pos/)، وثیقه ای ارائه دهند. اگر اعتبارسنج یک بلوک نامعتبر ارسال کند یا روی یک بلوک قدیمی اما نامعتبر ساخته شود (حتی اگر بلوک آنها معتبر باشد)، این وثیقه میتواند کاهش یابد یا به اصطلاح slashed شود. بدین شکل رولآپ های خوشبینانه از مشوقهای اقتصاد رمزارزی بهره میبرند تا اطمینان حاصل شود که اعتبارسنجیها صادقانه عمل میکنند.
+
+انتظار میرود سایر اعتبارسنجها در زنجیره رولآپ خوشبینانه، تراکنشهای ارائه شده را با استفاده از کپی حالت (اطلاعات/داده) رولآپ خود اجرا کنند. اگر حالت نهائی اعتبارسنجی با حالت پیشنهادی اپراتور متفاوت باشد، آنها میتوانند یک چالش را شروع کنند و یک اثبات تقلب را محاسبه نمایند.
+
+برخی رولآپ های خوشبینانه ممکن است از یک سیستم اعتبارسنجی بدون نیاز به اجازه صرف نظر کنند و از یک "ترتیب دهنده" واحد برای اجرای زنجیره استفاده کنند. مانند یک اعتبارسنج، ترتیب دهنده تراکنشها را پردازش مینماید، بلوکهای رولآپ را تولید میکند و تراکنشهای رولآپ را به شبکه L1 (اتریوم) میفرستد.
+
+ترتیب دهنده با یک اپراتور رولآپ معمولی تفاوت دارد، زیرا آنها کنترل بیشتری بر ترتیب تراکنشها دارند. همچنین، ترتیب دهنده اولویت دسترسی به زنجیره رولآپ را داراست و تنها نهاد مجاز برای ارسال تراکنشها به قرارداد روی زنجیره اصلی اتریوم میباشد. تراکنشهایی که از طرف گرههای غیر ترتیب دهنده یا کاربران عادی هستند، به سادگی در یک صندوق ورودی جداگانه در صف قرار میگیرند تا زمانی که ترتیب دهنده آنها را در یک دسته جدید قرار دهد.
+
+#### ثبت بلوکهای رولآپ در اتریوم {#submitting-blocks-to-ethereum}
+
+همان گونه که ذکر شد، اپراتور یک رولآپ خوشبینانه تراکنشهای خارج از زنجیره را در یک دسته جمع میکند و آن را برای تائید نهائی به اتریوم میفرستد. این پروسه شامل فشردهسازی دادههای مربوط به تراکنش و انتشار آن در اتریوم به عنوان `calldata` یا در داخل blobها میباشد.
+
+`calldata`یک محل تغییر ناپذیر و غیر دائمی در یک قرارداد هوشمند است که بیشتر شبیه به [حافظه مموری](/developers/docs/smart-contracts/anatomy/#memory) عمل میکند. در حالی که `calldata` در زنجیره به عنوان بخشی از [گزارشهای تاریخچه](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) بلاکچین باقی میماند، به عنوان بخشی از حافظه حالت اتریوم ذخیره نمیشود. چون که `calldata` هیچ بخشی از حالت اتریوم را لمس نمیکند، برای ذخیره دادهها در زنجیره، ارزانتر از حافظه حالت است.
+
+کلمه کلیدی `calldata` همچنین در زبان برنامه نویسی Solidity به منظور ارسال پارامترهای ورودی به یک تابع قرارداد هوشمند، در زمان آغاز اجرا، استفاده میشود. `calldata` تابعی را که در حین تراکنش فراخوانی میشود، شناسائی میکند و ورودیهای تابع را به شکل یک دنباله دلخواه در قالب Bytes نگه میدارد.
+
+در مبحث رولآپ های خوشبینانه، `calldata` برای ارسال دادههای فشرده شده تراکنش به قرارداد مستقر در شبکه اصلی، استفاده میشود. اپراتور رولآپ با فراخوانی تابع مورد نیاز در قرارداد رولآپ و ارسال دادههای فشرده شده به عنوان پارامتر ورودی تابع، یک دسته جدید تراکنش اضافه میکند. استفاده از `calldata` هزینههای کاربر را کاهش میدهد زیرا بیشتر هزینههایی که رولآپ ها متحمل میشوند از ذخیره کردن داده در شبکه اصلی اتریوم میباشد.
+
+این هم [یک مثال](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) از ارسال دسته جمعی رولآپ برای نشان دادن نحوه عملکرد این مفهوم. ترتیب دهنده، تابع `appendSequencerBatch()` را فراخوانی کرد و دادههای فشرده تراکنش را با استفاده از `calldata` به عنوان ورودی ارسال کرد.
+
+برخی رولآپها اکنون از blobها برای دسته ای ارسال کردن تراکنشها به اتریوم استفاده میکنند.
+
+blobها تغییرناپذیر و موقت اند (درست مانند `calldata`) اما پس از حدود 18 روز از تاریخچه حذف میشوند. جهت کسب اطلاعات بیشتر دربارهی blobها، [Danksharding](/roadmap/danksharding) را ببینید.
+
+### ثبت تعهد حالت {#state-commitments}
+
+در هر مقطع زمانی، حالت رولآپ خوشبینانه (حسابها، موجودیها، کد قرارداد و غیره) در قالب [درخت مرکل](/whitepaper/#merkle-trees) مرتب میشود که به آن "درخت حالت" میگویند. ریشه این درخت مرکل (ریشه حالت)، که به آخرین و بروزترین حالت رولآپ اشاره میکند، هش شده و در قرارداد رولآپ ذخیره میشود. هر تغییر حالت در زنجیره، یک حالت رولآپ جدید ایجاد میکند، که اپراتور با محاسبه یک ریشه حالت جدید به آن متعهد میشود.
+
+اپراتور موظف است که در هنگام ارسال دستهها، هم ریشههای حالت قدیمی و هم ریشههای حالت جدید را ارسال کند. اگر ریشه حالت قدیمی با ریشه حالت موجود در قرارداد روی زنجیره مطابقت داشته باشد، ریشه موجود کنار گذاشته شده و با ریشه حالت جدید جایگزین میشود.
+
+اپراتور رولآپ همچنین ملزم است که یک ریشه مرکل را برای خود دسته تراکنش تعهد دهد. این به هرکسی اجازه میدهد تا با ارائه [اثبات مرکل](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)، گنجانده شده بودن یک تراکنش در دسته (در L1) را ثابت کند.
+
+تعهدات حالت، به ویژه ریشههای حالت، برای اثبات صحیح بودن تغییرات حالت در یک رولآپ خوشبینانه ضروری است. قرارداد رولآپ، ریشههای حالت جدید را از اپراتورها بلافاصله پس از ارسال میپذیرد، اما بعداً میتواند ریشههای حالت نامعتبر را حذف کند تا رولآپ به حالت صحیح خود بازگردد.
+
+### اثبات کلاه برداری {#fraud-proving}
+
+همانگونه که توضیح دادیم هر کسی اجازه دارد که بلاک را پخش کند بدون اینکه ارزش ان را اثبات کند. هر چند، برای اطمینان از ایمن ماندن زنجیره، رولآپ خوشبینانه یک بازه زمانی را تعریف میکنند که طی آن هر کسی میتواند در مورد انتقال حالت اعتراض کند و آن را به چالش بکشد. از این رو، بلوکهای رولآپ "ادعا" نامیده میشوند، زیرا هر کسی میتواند ادعای آنها را مورد مناقشه قرار دهد.
+
+اگر کسی ادعایی را رد کند، پروتکل رولآپ محاسبات اثبات تقلب را آغاز میکند. هر نوع اثبات تقلبی تعاملی است - یک نفر باید قبل از اینکه شخص دیگری آن را به چالش بکشد، یک ادعا را ارسال کند. تفاوت در تعداد مرتبه تعامل برای محاسبه اثبات تقلب مورد نیاز نهفته است.
+
+طرحهای اثبات تعاملی تک مرتبهای، تراکنشهای مورد مناقشه را در L1 دوباره منتشر میکنند تا ادعاهای نامعتبر را شناسائی نمایند. پروتکل رولآپ اجرای مجدد تراکنش مورد مناقشه در L1 (اتریوم) را با استفاده از یک قرارداد تائید کننده، شبیهسازی میکند و ریشه حالت محاسبه شده تعیین میکند که چه کسی برنده چالش است. اگر ادعای رقیب در مورد وضعیت صحیح رول آپ درست باشد، اپراتور با قطع کردن باند خود جریمه میشود.
+
+با این حال، اجرای مجدد تراکنشها در لایه اول برای شناسایی تقلب مستلزم انتشار تعهدات استیت برای تراکنشهای فردی است و رول آپ دادهها را افزایش میدهد که باید در زنجیره منتشر شوند. بازپخش تراکنشها همچنین هزینههای گس قابل توجهی را به همراه دارد. به این دلایل، رول آپهای آپتیمیستیک به اثبات تعاملی چند دوره تغییر میکنند، که به همان هدف (یعنی تشخیص عملیات رول آپ نامعتبر) با کارایی بیشتر دست مییابد.
+
+#### اثبات چند مسیره فعال {#multi-round-interactive-proving}
+
+اثبات تعاملی چند دوره شامل یک پروتکل رفت و برگشت بین ادعا کننده و رقیب تحت نظارت یک قرارداد تأییدکننده لایه 1 است که در نهایت طرف دروغگو را تعیین میکند. پس از اینکه یک گره لایه دوم یک ادعا را به چالش میکشد، ادعا کننده باید ادعای مورد مناقشه را به دو نیمه مساوی تقسیم کند. هر ادعای منفرد در این مورد به اندازه دیگری شامل مراحل محاسباتی خواهد بود.
+
+سپس رقیب انتخاب خواهد کرد که چه ادعایی را میخواهد به چالش بکشد. فرآیند تقسیم (که "پروتکل دوگانه" نامیده میشود) ادامه مییابد تا زمانی که هر دو طرف در مورد ادعایی در مورد یک مرحله _تک_ اجرا بحث کنند. در این مرحله، قرارداد لایه اول با ارزیابی دستورالعمل (و نتیجه آن) برای دستگیری طرف متقلب، اختلاف را حل میکند.
+
+ادعاکننده ملزم به ارائه "اثبات یک مرحلهای" است که اعتبار محاسبات تک مرحلهای مورد مناقشه را تأیید میکند. اگر ادعاکننده نتواند اثبات یک مرحلهای را ارائه کند، یا تأییدکننده لایه اول اثبات را نامعتبر بداند، چالش را از دست میدهد.
+
+چند نکته در مورد این نوع اثبات تقلب:
+
+1. اثبات تقلب تعاملی چند دور کارآمد در نظر گرفته میشود زیرا کاری که زنجیره لایه اول باید در داوری اختلاف انجام دهد را به حداقل میرساند. به جای پخش مجدد کل تراکنش، زنجیره لایه اول فقط باید یک مرحله از اجرای مجموعه را دوباره اجرا کند.
+
+2. پروتکل های Bisection یا همان دو بخشی مقدار دادههای ارسال شده در زنجیره را کاهش میدهند (نیازی به انتشار commitهای حالت برای هر تراکنش نیست). همچنین، تراکنشهای رول آپ آپتیمیستیک با محدودیت گس اتریوم محدود نمیشوند. برعکس، رول آپهای آپتیمیستیک برای اجرای مجدد تراکنشها باید اطمینان حاصل کنند که تراکنش لایه دو دارای محدودیت گس کمتری برای تقلید اجرای آن در یک تراکنش واحد اتریوم است.
+
+3. بخشی از ضمانتکننده مخرب به رقیب تعلق میگیرد، در حالی که بخشی دیگر سوزانده میشود. سوزاندن از تبانی بین اعتبارسنجها جلوگیری میکند. اگر دو اعتبارسنجها با هم تبانی کنند تا چالشهای جعلی را آغاز کنند، باز هم بخش قابل توجهی از کل استیک را از دست خواهند داد.
+
+4. اثبات تعاملی چند دور به هر دو طرف (مدعیکننده و رقیب) نیاز دارد که در پنجره زمانی مشخص شده حرکت کنند. عدم اقدام قبل از انقضای مهلت مقرر باعث میشود که طرف متخلف از چالش منصرف شود.
+
+#### چرا اثبات تبهکار برای رول اپهای بهینه مهم است {#fraud-proof-benefits}
+
+اثبات تقلب مهم است، زیرا آنها _نهاییسازی بدون نیاز به اعتماد_ را در رول آپهای آپتیمیستیک تسهیل میکنند. نهاییبودن بدون اعتماد، کیفیتی از رول آپهای آپتیمیستیک است که تضمین میکند که یک تراکنش - تا زمانی که معتبر است - در نهایت تأیید شود.
+
+گرههای مخرب میتوانند با شروع چالشهای نادرست، تأیید یک بلوک رول آپ معتبر را به تأخیر بیندازند. با این حال، اثبات تقلب در نهایت اعتبار بلوک رول آپ را ثابت میکند و باعث تایید آن میشود.
+
+این همچنین به یکی دیگر از ویژگی های امنیتی رولآپ خوشبینانه مربوط می شود: اعتبار زنجیره به وجود _یک_ گره صادق بستگی دارد. گره صادق می تواند با ارسال ادعاهای معتبر یا مخالفت با ادعاهای نامعتبر، زنجیره را به درستی پیش ببرد. در هر صورت، گرههای مخربی که با گره صادق وارد اختلاف میشوند، در طول فرآیند اثبات تقلب، سهام خود را از دست خواهند داد.
+
+### نسبت L1 به L2 ، عملیات داخلی {#l1-l2-interoperability}
+
+رولآپ خوشبینانه برای قابلیت همکاری با شبکه اصلی اتریوم طراحی شدهاند و به کاربران اجازه میدهند پیامها و دادههای دلخواه را بین L1 و L2 ارسال کنند. آنها همچنین با EVM سازگار هستند، بنابراین میتوانید [دپ های](/developers/docs/dapps/) موجود را به رولآپ های خوشبینانه پورت کنید یا با استفاده از ابزارهای توسعه اتریوم، دپ های جدید ایجاد کنید.
+
+#### 1. انتقال دارایی {#asset-movement}
+
+##### ورود به رول اپ
+
+To use an optimistic rollup, users deposit ETH, ERC-20 tokens, and other accepted assets in the rollup’s [bridge](/developers/docs/bridges/) contract on L1. The bridge contract will relay the transaction to L2, where an equivalent amount of assets is minted and sent to the user’s chosen address on the optimistic rollup.
+
+User-generated transactions (like an L1 > L2 deposit) are usually queued until the sequencer re-submits them to the rollup contract. However, to preserve censorship resistance, optimistic rollups allow users to submit a transaction directly to the on-chain rollup contract if it has been delayed past the maximum time allowed.
+
+Some optimistic rollups adopt a more straightforward approach to prevent sequencers from censoring users. Here, a block is defined by all transactions submitted to the L1 contract since the previous block (e.g., deposits) in addition to the transactions processed on the rollup chain. If a sequencer ignores an L1 transaction, it will publish the (provably) wrong state root; therefore, sequencers cannot delay user-generated messages once posted on L1.
+
+##### خروج از رول اپ
+
+Withdrawing from an optimistic rollup to Ethereum is more difficult owing to the fraud proving scheme. If a user initiates an L2 > L1 transaction to withdraw funds escrowed on L1, they must wait until the challenge period—lasting roughly seven days—elapses. Nevertheless, the withdrawal process itself is fairly straightforward.
+
+After the withdrawal request is initiated on the L2 rollup, the transaction is included in the next batch, while the user’s assets on the rollup are burned. Once the batch is published on Ethereum, the user can compute a Merkle proof verifying the inclusion of their exit transaction in the block. Then it is a matter of waiting through the delay period to finalize the transaction on L1 and withdraw funds to Mainnet.
+
+To avoid waiting a week before withdrawing funds to Ethereum, optimistic rollup users can employ a **liquidity provider** (LP). A liquidity provider assumes ownership of a pending L2 withdrawal and pays the user on L1 (in exchange for a fee).
+
+Liquidity providers can check the validity of the user’s withdrawal request (by executing the chain themselves) before releasing funds. This way they have assurances that the transaction will be confirmed eventually (i.e., trustless finality).
+
+#### 2. سازگاری با EVM {#evm-compatibility}
+
+For developers, the advantage of optimistic rollups is their compatibility—or, better still, equivalence—with the [Ethereum Virtual Machine (EVM)](/developers/docs/evm/). EVM-compatible rollups comply with specifications in the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) and support the EVM at the bytecode level.
+
+EVM-compatibility in optimistic rollups has the following benefits:
+
+i. Developers can migrate existing smart contracts on Ethereum to optimistic rollup chains without having to modify codebases extensively. This can save development teams time when deploying Ethereum smart contracts on L2.
+
+ii. Developers and project teams using optimistic rollups can take advantage of Ethereum's infrastructure. This includes programming languages, code libraries, testing tools, client software, deployment infrastructure, and so on.
+
+Using existing tooling is important because these tools have been extensively audited, debugged, and improved over the years. It also removes the need for Ethereum developers to learn how to build with an entirely new development stack.
+
+#### 3. صدا زدن قرارداد از روی زنجیره های متقاطع {#cross-chain-contract-calls}
+
+Users (externally owned accounts) interact with L2 contracts by submitting a transaction to the rollup contract or having a sequencer or validator do it for them. Optimistic rollups also allow contract accounts on Ethereum to interact with L2 contracts using bridging contracts to relay messages and pass data between L1 and L2. This means you can program an L1 contract on Ethereum Mainnet to invoke functions belonging to contracts on an L2 optimistic rollup.
+
+Cross-chain contract calls happen asynchronously—meaning the call is initiated first, then executed at a later time. This is different from calls between the two contracts on Ethereum, where the call produces results immediately.
+
+An example of a cross-chain contract call is the token deposit described earlier. A contract on L1 escrows the user's tokens and sends a message to a paired L2 contract to mint an equal amount of tokens on the rollup.
+
+As cross-chain message calls result in contract execution, the sender is usually required to cover [gas costs](/developers/docs/gas/) for computation. It is advisable to set a high gas limit to prevent the transaction from failing on the target chain. The token bridging scenario is a good example; if the L1 side of the transaction (depositing the tokens) works, but the L2 side (minting new tokens) fails due to low gas, the deposit becomes irrecoverable.
+
+Finally, we should note that L2 > L1 message calls between contracts need to account for delays (L1 > L2 calls are typically executed after some minutes). This is because messages sent to Mainnet from the optimistic rollup cannot be executed until the challenge window expires.
+
+## هزینه رولاپ های بهینه چگونه کار می کند؟ {#how-do-optimistic-rollup-fees-work}
+
+Optimistic rollups use a gas fee scheme, much like Ethereum, to denote how much users pay per transaction. Fees charged on optimistic rollups depends on the following components:
+
+1. **State write**: Optimistic rollups publish transaction data and block headers (consisting of the previous block header hash, state root, batch root) to Ethereum as a `blob`, or "binary large object". [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduced a cost-effective solution for including data on-chain. A `blob` is a new transaction field that allows rollups to post compressed state transition data to Ethereum L1. Unlike `calldata`, which remains permanently on-chain, blobs are short-lived and can be pruned from clients after [4096 epochs](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (approximately 18 days). By using blobs to post batches of compressed transactions, optimistic rollups can significantly reduce the cost of writing transactions to L1.
+
+2. **Blob gas used**: Blob-carrying transactions employ a dynamic fee mechanism similar to the one introduced by [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). The gas fee for type-3 transactions takes into account the base fee for blobs, which is determined by the network based on blob-space demand and the blob-space usage of the transaction being sent.
+
+3. **L2 operator fees**: This is the amount paid to the rollup nodes as compensation for computational costs incurred in processing transactions, much like gas fees on Ethereum. Rollup nodes charge lower transaction fees since L2s have higher processing capacities and aren't faced with the network congestions that force validators on Ethereum to prioritize transactions with higher fees.
+
+Optimistic rollups apply several mechanisms to reducing fees for users, including batching transactions and compressing `calldata` to reduce data publication costs. You can check the [L2 fee tracker](https://l2fees.info/) for a real-time overview of how much it costs to use Ethereum-based optimistic rollups.
+
+## چگونه رول اپهای بهینه سرعت و مقیاسپذیری را در اتریوم افزایش می دهند؟ {#scaling-ethereum-with-optimistic-rollups}
+
+As explained, optimistic rollups publish compressed transaction data on Ethereum to guarantee data availability. The ability to compress data published on-chain is crucial to scaling throughput on Ethereum with optimistic rollups.
+
+The main Ethereum chain places limits on how much data blocks can hold, denominated in gas units (the [average block size](/developers/docs/blocks/#block-size) is 15 million gas). While this restricts how much gas each transaction can use, it also means we can increase transactions processed per block by reducing transaction-related data—directly improving scalability.
+
+Optimistic rollups use several techniques to achieve transaction data compression and improve TPS rates. For example, this [article](https://vitalik.eth.limo/general/2021/01/05/rollup.html) compares the data a basic user transaction (sending ether) generates on Mainnet vs how much data the same transaction generates on a rollup:
+
+| پارامتر | Ethereum (L1) | Rollup (L2) |
+| -------- | ---------------------- | ---------------- |
+| Nonce | ~3 | 0 |
+| Gasprice | ~8 | 0-0.5 |
+| گاز | 3 | 0-0.5 |
+| To | 21 | 4 |
+| Value | 9 | ~3 |
+| امضا | ~68 (2 + 33 + 33) | ~0.5 |
+| From | 0 (recovered from sig) | 4 |
+| **جمع** | **حدود 112 بایت** | **حدود 12 بایت** |
+
+Doing some rough calculations on these figures can help show the scalability improvements afforded by an optimistic rollup:
+
+1. The target size for every block is 15 million gas and it costs 16 gas to verify one byte of data. Dividing the average block size by 16 gas (15,000,000/16) shows the average block can hold **937,500 bytes of data**.
+2. If a basic rollup transaction uses 12 bytes, then the average Ethereum block can process **78,125 rollup transactions** (937,5000/12) or **39 rollup batches** (if each batch holds an average of 2,000 transactions).
+3. If a new block is produced on Ethereum every 15 seconds, then the rollup's processing speeds would amount to roughly **5,208 transactions per second**. This is done by dividing the number of basic rollup transactions an Ethereum block can hold (**78,125**) by the average block time (**15 seconds**).
+
+This is a fairly optimistic estimate, given that optimistic rollup transactions cannot possibly comprise an entire block on Ethereum. However, it can give a rough idea of how much scalability gains that optimistic rollups can afford Ethereum users (current implementations offer up to 2,000 TPS).
+
+The introduction of [data sharding](/roadmap/danksharding/) on Ethereum is expected to improve scalability in optimistic rollups. Because rollup transactions must share blockspace with other non-rollup transactions, their processing capacity is limited by data throughput on the main Ethereum chain. Danksharding will increase the space available to L2 chains to publish data per block, using cheaper, impermanent "blob" storage instead of expensive, permanent `CALLDATA`.
+
+### مزایا و معایب رول اپ های بهینه {#optimistic-rollups-pros-and-cons}
+
+| مزایا | معایب |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Offers massive improvements in scalability without sacrificing security or trustlessness. | Delays in transaction finality due to potential fraud challenges. |
+| Transaction data is stored on the layer 1 chain, improving transparency, security, censorship-resistance, and decentralization. | Centralized rollup operators (sequencers) can influence transaction ordering. |
+| Fraud proving guarantees trustless finality and allows honest minorities to secure the chain. | If there are no honest nodes a malicious operator can steal funds by posting invalid blocks and state commitments. |
+| Computing fraud proofs is open to regular L2 node, unlike validity proofs (used in ZK-rollups) that require special hardware. | Security model relies on at least one honest node executing rollup transactions and submitting fraud proofs to challenge invalid state transitions. |
+| Rollups benefit from "trustless liveness" (anyone can force the chain to advance by executing transactions and posting assertions) | Users must wait for the one-week challenge period to expire before withdrawing funds back to Ethereum. |
+| Optimistic rollups rely on well-designed cryptoeconomic incentives to increase security on the chain. | Rollups must post all transaction data on-chain, which can increase costs. |
+| Compatibility with EVM and Solidity allows developers to port Ethereum-native smart contracts to rollups or use existing tooling to create new dapps. | |
+
+### یک توضیح تصویری از رول اپهای بهینه {#optimistic-video}
+
+با تصویر راحتتر یاد میگیرید؟ Watch Finematics explain optimistic rollups:
+
+
+
+### استفاده ار رول اپهای بهینه {#use-optimistic-rollups}
+
+Multiple implementations of Optimistic rollups exist that you can integrate into your dapps:
+
+
+
+## مطالعات تکمیلی در خصوص رول اپهای بهینه
+
+- [How do optimistic rollups work (The Complete guide)](https://www.alchemy.com/overviews/optimistic-rollups)
+- [What is a Blockchain Rollup? A Technical Introduction](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction)
+- [The Essential Guide to Arbitrum](https://newsletter.banklesshq.com/p/the-essential-guide-to-arbitrum)
+- [How does Optimism's Rollup really work?](https://www.paradigm.xyz/2021/01/how-does-optimisms-rollup-really-work)
+- [OVM Deep Dive](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52)
+- [What is the Optimistic Virtual Machine?](https://www.alchemy.com/overviews/optimistic-virtual-machine)
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md"
new file mode 100644
index 00000000000..8de0998e26e
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md"
@@ -0,0 +1,175 @@
+---
+title: زنجیره های پلاسما
+description: مقدمهای بر زنجیرههای پلاسما بهعنوان یک راهحل مقیاسپذیر که در حال حاضر توسط جامعه اتریوم استفاده میشود.
+lang: fa
+incomplete: true
+sidebarDepth: 3
+---
+
+زنجیره پلاسما یک بلاک چین مجزا است که به شبکه اصلی اتریوم متصل است، اما تراکنشهای خارج از زنجیره را با مکانیزم خاص خود برای اعتبارسنجی بلوک اجرا میکند. زنجیرههای پلاسما گاهی اوقات به عنوان زنجیرههای «کودک» شناخته میشوند که اساساً کپیهای کوچکتری از شبکه اصلی اتریوم هستند. زنجیره های پلاسما از [اثبات تقلب](/glossary/#fraud-proof) (مانند [رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)) برای داوری اختلافات استفاده می کنند.
+
+درختان مرکل ایجاد یک پشته بی پایان از این زنجیرهها را امکانپذیر میسازند که میتوانند پهنای باند را از زنجیرههای مادر (از جمله شبکه اصلی اتریوم) تخلیه کنند. با این حال، در حالی که این زنجیرهها مقداری امنیت را از اتریوم (از طریق اثبات تقلب) میگیرند، امنیت و کارایی آنها تحت تأثیر چندین محدودیت طراحی قرار میگیرد.
+
+## موارد مورد نیاز {#prerequisites}
+
+شما باید درک خوبی از همه موضوعات اساسی و درک سطح بالایی از [مقیاسسازی اتریوم](/developers/docs/scaling/) داشته باشید.
+
+## پلاسما چیست؟
+
+پلاسما چارچوبی برای بهبود مقیاس پذیری در بلاک چین های عمومی مانند اتریوم است. همانطور که در [وایت پیپر پلاسما](http://plasma.io/plasma.pdf) اصلی توضیح داده شد، زنجیره های پلاسما بر روی زنجیره بلوکی دیگری (به نام "زنجیره ریشه") ساخته شده اند. هر "زنجیره کودک" از زنجیره ریشه گسترش می یابد و به طور کلی توسط یک قرارداد هوشمند مستقر در زنجیره والد مدیریت می شود.
+
+قرارداد پلاسما، در میان چیزهای دیگر، به عنوان یک [پل](/developers/docs/bridges/) عمل می کند که به کاربران اجازه می دهد دارایی ها را بین شبکه اصلی اتریوم و زنجیره پلاسما جابجا کنند. اگرچه این امر آنها را شبیه به [زنجیره های جانبی](/developers/docs/scaling/sidechains/) می کند، زنجیره های پلاسما حداقل تا حدی از امنیت شبکه اصلی اتریوم بهره می برند. این برخلاف زنجیرهای جانبی است که تنها مسئول امنیت آنها هستند.
+
+## پلاسما چگونه کار می کند؟
+
+اجزای اصلی چارچوب پلاسما عبارتند از:
+
+### محاسبات خارج از زنجیره {#off-chain-computation}
+
+سرعت پردازش کنونی اتریوم به 15 تا 20 تراکنش در ثانیه محدود شده است که امکان کوتاهمدت مقیاسپذیری برای رسیدگی به کاربران بیشتر را کاهش میدهد. این مشکل عمدتاً به این دلیل وجود دارد که [مکانیسم اجماع اتریوم](/developers/docs/consensus-mechanisms/) به بسیاری از گرههای همتا به همتا برای تأیید هر بهروزرسانی در وضعیت بلاک چین نیاز دارد.
+
+اگرچه مکانیسم اجماع اتریوم برای امنیت ضروری است، اما ممکن است برای همه موارد استفاده اعمال نشود. به عنوان مثال، آلیس ممکن است برای یک فنجان قهوه تأیید شده توسط کل شبکه اتریوم نیازی به پرداخت روزانه خود به باب نداشته باشد زیرا اعتماد بین هر دو طرف وجود دارد.
+
+پلاسما فرض می کند که شبکه اصلی اتریوم نیازی به تأیید همه تراکنش ها ندارد. در عوض، میتوانیم تراکنشها را خارج از شبکه اصلی پردازش کنیم و گرهها را از تأیید اعتبار هر تراکنش رها کنیم.
+
+محاسبات خارج از زنجیره ضروری است زیرا زنجیره های پلاسما می توانند برای سرعت و هزینه بهینهسازی شوند. به عنوان مثال، یک زنجیره پلاسما ممکن است - و اغلب این کار را می کند - از یک "اپراتور" واحد برای مدیریت سفارش و اجرای تراکنش ها استفاده کند. تنها با یک نهاد که تراکنشها را تأیید میکند، زمان پردازش در زنجیره پلاسما سریعتر از شبکه اصلی اتریوم است.
+
+### ثبت تعهد حالت {#state-commitments}
+
+در حالی که پلاسما تراکنشهای خارج از زنجیره را انجام میدهد، آنها در لایه اصلی اجرای اتریوم مستقر میشوند – در غیر این صورت، زنجیرههای پلاسما نمیتوانند از تضمینهای امنیتی اتریوم بهرهمند شوند. اما نهایی کردن تراکنشهای خارج از زنجیره بدون اطلاع از وضعیت زنجیره پلاسما، مدل امنیتی را شکسته و امکان گسترش تراکنشهای نامعتبر را فراهم میکند. به همین دلیل است که اپراتور، نهادی که مسئول تولید بلوکها در زنجیره پلاسما است، ملزم به انتشار دورهای «تعهدات حالت» در اتریوم است.
+
+[طرح تعهد](https://en.wikipedia.org/wiki/Commitment_scheme) یک تکنیک رمزنگاری برای تعهد به یک مقدار یا بیانیه بدون افشای آن برای طرف دیگر است. تعهدات "الزام آور" هستند به این معنا که شما نمی توانید ارزش یا بیانیه را پس از تعهد به آن تغییر دهید. تعهدات حالت در پلاسما به شکل "ریشه های مرکل" (برگرفته از [درخت مرکل](/whitepaper/#merkle-trees)) است که اپراتور در فواصل زمانی آن را به قرارداد پلاسما در زنجیره اتریوم ارسال می کند.
+
+ریشههای مرکل، مبانی رمزنگاری هستند که امکان فشردهسازی حجم زیادی از اطلاعات را فراهم میکنند. یک ریشه مرکل (که در این مورد "ریشه بلوک" نیز نامیده می شود) می تواند تمام تراکنش های یک بلوک را نشان دهد. ریشه های مرکل همچنین تأیید اینکه یک قطعه کوچک از داده بخشی از مجموعه داده بزرگتر است را آسان تر می کند. به عنوان مثال، یک کاربر می تواند یک [اثبات مرکل](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) برای اثبات گنجاندن تراکنش در یک بلوک خاص تولید کند.
+
+ریشه های مرکل برای ارائه اطلاعات در مورد وضعیت خارج از زنجیره به اتریوم مهم هستند. میتوانید ریشههای مرکل را بهعنوان «نقاط ذخیره» در نظر بگیرید: اپراتور میگوید: «این وضعیت زنجیره پلاسما در نقطه x در زمان است، و این ریشه مرکل بهعنوان اثبات است» اپراتور به _حالت فعلی_ زنجیره پلاسما با ریشه مرکل متعهد است، به همین دلیل است که به آن "تعهد حالت" میگویند.
+
+### ورودی ها و خروجی ها {#entries-and-exits}
+
+برای اینکه کاربران اتریوم از مزیت پلاسما استفاده کنند، باید مکانیزمی برای جابجایی وجوه بین زنجیره اصلی و پلاسما وجود داشته باشد. ما نمیتوانیم خودسرانه اتر را به آدرسی در زنجیره پلاسما بفرستیم - این زنجیرهها ناسازگار هستند، بنابراین تراکنش یا شکست میخورد یا منجر به از دست رفتن وجوه میشود.
+
+پلاسما از یک قرارداد اصلی در حال اجرا بر روی اتریوم برای پردازش ورودی ها و خروجی های کاربر استفاده می کند. این قرارداد اصلی همچنین مسئول ردیابی تعهدات حالت (که قبلا توضیح داده شد) و مجازات رفتار غیرصادقانه از طریق اثبات تقلب است (در ادامه در این مورد بیشتر خواهد شد).
+
+#### ورود به زنجیره پلاسما {#entering-the-plasma-chain}
+
+برای ورود به زنجیره پلاسما، آلیس (کاربر) باید ETH یا هر توکن ERC-20 را در قرارداد پلاسما واریز کند. اپراتور پلاسما، که سپردههای قراردادی را تماشا میکند، مبلغی برابر با سپرده اولیه آلیس را دوباره ایجاد میکند و آن را به آدرس او در زنجیره پلاسما میفرستد. آلیس ملزم به دریافت وجوه در زنجیره فرزند است و سپس می تواند از این وجوه برای تراکنش ها استفاده کند.
+
+#### خروج از زنجیره پلاسما {#exiting-the-plasma-chain}
+
+خروج از زنجیره پلاسما به چند دلیل پیچیده تر از ورود به آن است. بزرگترین مورد این است که در حالی که اتریوم اطلاعاتی در مورد حالت زنجیره پلاسما دارد، نمی تواند صحت یا عدم صحت این اطلاعات را تأیید کند. یک کاربر مخرب می تواند ادعای نادرستی داشته باشد (مثلا بگوید "من 1000 اتر دارم") و از ارائه شواهد جعلی برای پشتیبان گیری از ادعا خودداری کند.
+
+برای جلوگیری از برداشت های مخرب، یک "دوره چالش" معرفی شده است. در طول دوره چالش (معمولاً یک هفته)، هر کسی می تواند با استفاده از یک اثبات تقلب، درخواست برداشت را به چالش بکشد. اگر چالش با موفقیت انجام شود، درخواست برداشت رد می شود.
+
+با این حال، معمولاً اینطور است که کاربران صادق هستند و ادعاهای درستی در مورد وجوه خود دارند. در این سناریو، آلیس با ارسال یک تراکنش به قرارداد پلاسما، درخواست برداشت از زنجیره ریشه (اتریوم) را آغاز می کند.
+
+او همچنین باید یک اثبات مرکل ارائه دهد که تأیید کند تراکنشی که وجوه او را در زنجیره پلاسما ایجاد می کند در یک بلوک گنجانده شده است. این برای تکرارهای پلاسما، مانند [MVP پلاسما](https://www.learnplasma.org/en/learn/mvp.html)، که از مدل [خروجی تراکنش خرج نشده (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output) استفاده میکند، ضروری است.
+
+دیگران، مانند [وجه نقد پلاسما](https://www.learnplasma.org/en/learn/cash.html)، وجوه را بهجای UTXO به عنوان [توکنهای غیرقابل تعویض](/developers/docs/standards/tokens/erc-721/) نشان میدهند. برداشت، در این مورد، مستلزم اثبات مالکیت توکن ها در زنجیره پلاسما است. این کار با ارسال دو آخرین تراکنش شامل توکن و ارائه یک اثبات Merkle برای تأیید گنجاندن آن تراکنشها در یک بلوک انجام میشود.
+
+کاربر همچنین باید به درخواست انصراف به عنوان تضمین رفتار صادقانه یک باند اضافه کند. اگر یک رقیب ثابت کند درخواست انصراف آلیس نامعتبر است، وثیقه او قطع می شود و مقداری از آن به عنوان پاداش به رقیب می رسد.
+
+اگر دوره چالش بدون ارائه مدرک ضد تقلب بگذرد، درخواست برداشت آلیس معتبر تلقی میشود و به او اجازه میدهد تا سپردههای قرارداد پلاسما روی اتریوم را بازیابی کند.
+
+### داوری اختلاف {#dispute-arbitration}
+
+مانند هر بلاک چین، زنجیرههای پلاسما به مکانیزمی برای اعمال یکپارچگی تراکنشها در مواردی که شرکتکنندگان بهطور مخرب عمل میکنند (مثلاً بازخرج وجوه) نیاز دارند. برای این منظور، زنجیره های پلاسما از شواهد تقلب برای داوری اختلافات مربوط به اعتبار انتقال حالت و مجازات رفتار بد استفاده می کنند. اثبات تقلب بهعنوان مکانیزمی استفاده میشود که از طریق آن یک زنجیره کودک پلاسما شکایتی را به زنجیره والدین خود یا به زنجیره ریشه ارسال میکند.
+
+اثبات تقلب صرفاً ادعایی است مبنی بر اینکه یک انتقال حالت خاص نامعتبر است. به عنوان مثال، اگر یک کاربر (آلیس) سعی کند دو بار همان سرمایه را خرج کند. شاید او UTXO را در تراکنش با باب خرج کرده باشد و بخواهد همان UTXO (که اکنون باب است) را در تراکنش دیگری خرج کند.
+
+برای جلوگیری از انصراف، باب با ارائه شواهدی مبنی بر خرج کردن UTXO مذکور در تراکنش قبلی توسط آلیس و اثبات مرکل مبنی بر گنجاندن تراکنش در یک بلوک، یک اثبات تقلب ایجاد خواهد کرد. همین فرآیند در Plasma Cash نیز کار میکند. باب باید مدرکی ارائه دهد که نشان دهد آلیس قبلاً توکنهایی را که میخواهد برداشت کند، منتقل کرده است.
+
+اگر چالش باب موفقیت آمیز باشد، درخواست خروج آلیس لغو می شود. با این حال، این رویکرد بر توانایی باب برای تماشای زنجیره درخواستهای برداشت متکی است. اگر باب آفلاین باشد، آلیس می تواند پس از سپری شدن دوره چالش، برداشت مخرب را پردازش کند.
+
+## مشکل خروج جرم در پلاسما {#the-mass-exit-problem-in-plasma}
+
+مشکل خروج انبوه زمانی رخ می دهد که تعداد زیادی از کاربران همزمان سعی می کنند از زنجیره پلاسما خارج شوند. علت وجود این مشکل به یکی از بزرگترین مشکلات پلاسما مربوط می شود: **در دسترس نبودن داده ها**.
+
+در دسترس بودن داده، توانایی تأیید این است که اطلاعات یک بلوک پیشنهادی واقعاً در شبکه بلاک چین منتشر شده است. یک بلوک "در دسترس نیست" اگر سازنده خود بلوک را منتشر کند اما دادههای استفاده شده برای ایجاد بلوک را مخفی کند.
+
+اگر گرهها میخواهند بلوک را دانلود و اعتبار تراکنشها را تأیید کنند، باید بلوکها در دسترس باشند. بلاک چین ها با وادار کردن تولیدکنندگان بلاک به ارسال تمام دادههای تراکنش در زنجیره، در دسترس بودن دادهها را تضمین میکنند.
+
+در دسترس بودن دادهها همچنین به ایمنسازی پروتکلهای مقیاسپذیری خارج از زنجیره که بر روی لایه پایه اتریوم ساخته شدهاند کمک میکند. با وادار کردن اپراتورهای این زنجیرهها به انتشار دادههای تراکنش در اتریوم، هر کسی میتواند با ایجاد مدارک تقلب که به وضعیت صحیح زنجیره ارجاع میدهد، بلوکهای نامعتبر را به چالش بکشد.
+
+زنجیرههای پلاسما عمدتاً دادههای تراکنش را با اپراتور ذخیره میکنند و **هیچ دادهای را در شبکه اصلی منتشر نمیکنند** (یعنی علاوه بر تعهدات دورهای استیت). این بدان معناست که اگر کاربران نیاز به ایجاد مدارک تقلب برای به چالش کشیدن تراکنشهای نامعتبر دارند، باید به اپراتور برای ارائه دادههای بلوک اعتماد کنند. اگر این سیستم کار کند، کاربران همیشه میتوانند از شواهد تقلب برای تضمین وجوه استفاده کنند.
+
+مشکل زمانی شروع میشود که اپراتور، نه هر کاربر، طرفی باشد که به طور مخرب عمل میکند. از آنجایی که اپراتور تنها کنترل بلاک چین را در دست دارد، آنها انگیزه بیشتری برای پیشبرد انتقال حالت نامعتبر در مقیاس بزرگتر مانند سرقت وجوه متعلق به کاربران در زنجیره پلاسما دارند.
+
+در این مورد، استفاده از سیستم کلاسیک ضد تقلب کار نمیکند. اپراتور به راحتی میتواند یک تراکنش نامعتبر را انجام دهد و وجوه آلیس و باب را به کیف پول خود منتقل و دادههای لازم برای ایجاد ضد تقلب را پنهان کند. این امکانپذیر است زیرا اپراتور لازم نیست دادهها را در دسترس کاربران یا شبکه اصلی قرار دهد.
+
+بنابراین، خوش بینانه ترین راه حل تلاش برای "خروج انبوه" کاربران از زنجیره پلاسما است. خروج انبوه برنامه اپراتور مخرب برای سرقت وجوه را کند کرده و مقداری محافظت برای کاربران فراهم میکند. درخواستهای برداشت بر اساس زمان ایجاد هر UTXO (یا توکن) سفارش داده میشوند و از اپراتورهای مخرب جلوگیری میکنند که کاربران صادق پیشرو باشند.
+
+با این وجود، ما هنوز به راهی برای تأیید صحت درخواستهای برداشت برای جلوگیری از پول نقد افراد فرصتطلب از خروجهای نامعتبر پردازش نامناسب در طول یک خروج انبوه نیاز داریم. راه حل ساده است: از کاربران بخواهید که آخرین **حالت معتبر زنجیره** را برای خروج از پول خود ارسال کنند.
+
+اما این رویکرد همچنان مشکلاتی دارد. به عنوان مثال، اگر همه کاربران در یک زنجیره پلاسما نیاز به خروج داشته باشند (که در مورد یک اپراتور مخرب امکانپذیر است)، کل وضعیت معتبر زنجیره پلاسما باید به یکباره روی لایه پایه اتریوم ارسال شود. با توجه به اندازه دلخواه زنجیرههای پلاسما (بازده بالا = داده بیشتر) و محدودیت در سرعت پردازش اتریوم، این یک راه حل ایده آل نیست.
+
+اگرچه بازیهای خروج از نظر تئوری خوب به نظر میرسند، خروجهای انبوه واقعی احتمالاً باعث ازدحام شبکه در خود اتریوم میشوند. علاوه بر آسیب رساندن به عملکرد اتریوم، یک خروج انبوه با هماهنگی ضعیف به این معنی است که کاربران ممکن است نتوانند قبل از تخلیه هر حساب در زنجیره پلاسما توسط اپراتور، وجوه خود را برداشت کنند.
+
+## مزایا و معایب پلاسما {#pros-and-cons-of-plasma}
+
+| نقاط مثبت | نقاط ضعف |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| توان عملیاتی بالا و هزینه کم در هر تراکنش را ارائه میدهد. | از محاسبات عمومی پشتیبانی نمیکند (نمیتوان قراردادهای هوشمند را اجرا کرد. فقط انتقال توکنهای اولیه، سواپها و چند نوع تراکنش دیگر از طریق منطق محمول پشتیبانی میشوند. |
+| مناسب برای تراکنش بین کاربران دلخواه (اگر هر دو در زنجیره پلاسما ایجاد شده باشند بدون سربار برای هر جفت کاربر) | برای اطمینان از امنیت وجوه خود، باید به طور دوره ای شبکه را تماشا کنید (الزام زندگی) یا این مسئولیت را به شخص دیگری محول کنید. |
+| زنجیرههای پلاسما را میتوان با موارد استفاده خاص که به زنجیره اصلی مرتبط نیستند، تطبیق داد. هر کسی، از جمله مشاغل، میتواند قراردادهای هوشمند پلاسما را برای ارائه زیرساخت مقیاسپذیر که در زمینههای مختلف کار میکند، سفارشی کند. | به یک یا چند اپراتور برای ذخیره داده و ارائه آن در صورت درخواست متکی است. |
+| با انتقال محاسبات و ذخیره سازی خارج از زنجیره، بار روی شبکه اصلی اتریوم را کاهش می دهد. | برداشتها چند روز به تأخیر میافتد تا چالشها وجود داشته باشد. برای دارایی های قابل تعویض، این می تواند توسط ارائه دهندگان نقدینگی کاهش یابد، اما هزینه سرمایه مرتبطی وجود دارد. |
+| | اگر تعداد زیادی از کاربران به طور همزمان سعی کنند از آن خارج شوند، شبکه اصلی اتریوم ممکن است شلوغ شود. |
+
+## پلاسما در مقابل پروتکل های مقیاس پذیری لایه 2 {#plasma-vs-layer-2}
+
+در حالی که زمانی پلاسما به عنوان یک راه حل مقیاس پذیر مفید برای اتریوم در نظر گرفته می شد، از آن زمان به نفع [پروتکل های مقیاس پذیری لایه (L2)](/layer-2/) کنار گذاشته شد. راهکار های مقیاس پذیری L2 چندین مشکل پلاسما را برطرف می کنند:
+
+### کارایی {#efficiency}
+
+[مجموعههای دانش صفر](/developers/docs/scaling/zk-rollups) شواهد رمزنگاری از اعتبار هر دسته از تراکنشهای خارج از زنجیره پردازش میشوند. این مانع از پیشبرد انتقال وضعیت نامعتبر توسط کاربران (و اپراتورها) می شود و نیاز به دوره های چالش و بازی های خروج را از بین می برد. همچنین به این معنی است که کاربران مجبور نیستند به صورت دوره ای زنجیره را تماشا کنند تا سرمایه خود را تضمین کنند.
+
+### پشتیبانی از قراردادهای هوشمند {#support-for-smart-contracts}
+
+مشکل دیگر در چارچوب پلاسما [ناتوانی در پشتیبانی از اجرای قراردادهای هوشمند اتریوم](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4) بود. در نتیجه، بیشتر پیادهسازیهای پلاسما عمدتاً برای پرداختهای ساده یا مبادله توکنهای ERC-20 ساخته شدهاند.
+
+برعکس، مجموعههای خوشبینانه با [ماشین مجازی اتریوم](/developers/docs/evm/) سازگار هستند و میتوانند [قراردادهای هوشمند](/developers/docs/smart-contracts/) بومی اتریوم را اجرا کنند، و آنها را به یک راهحل مفید و _ایمن_ برای مقیاس بندی [برنامه های غیرمتمرکز](/developers/docs/dapps/). به طور مشابه، برنامههایی برای [ایجاد یک پیادهسازی دانش صفر از EVM (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) در حال انجام است که به رول آپ های دانش صفر اجازه میدهد منطق دلخواه را پردازش کرده و قراردادهای هوشمند را اجرا کنند.
+
+### در دسترس نبودن داده ها {#data-unavailability}
+
+همانطور که قبلا توضیح داده شد، پلاسما از مشکل در دسترس بودن داده رنج می برد. اگر یک اپراتور مخرب یک انتقال نامعتبر را در زنجیره پلاسما ایجاد کند، کاربران نمی توانند آن را به چالش بکشند زیرا اپراتور می تواند داده های مورد نیاز برای ایجاد اثبات تقلب را مخفی کند. رولآپ ها این مشکل را با مجبور کردن اپراتورها برای ارسال دادههای تراکنش در اتریوم حل میکنند و به هر کسی اجازه میدهد وضعیت زنجیره را تأیید کند و در صورت لزوم، اثبات تقلب ایجاد کند.
+
+### مشکل خروج انبوه {#mass-exit-problem}
+
+ZK-rollup ها و رول آپ های خوش بینانه هر دو مشکل خروج انبوه پلاسما را به طرق مختلف حل می کنند. برای مثال، یک رول آپ دانش صفر بر مکانیزمهای رمزنگاری تکیه میکند که تضمین میکند اپراتورها تحت هیچ سناریویی نمیتوانند وجوه کاربران را سرقت کنند.
+
+به طور مشابه، رولآپ های خوشبینانه یک دوره تاخیر را برای برداشتها تحمیل میکند که طی آن هر کسی میتواند یک چالش را آغاز کند و از درخواستهای برداشت مخرب جلوگیری کند. در حالی که این شبیه به پلاسما است، تفاوت این است که تأییدکنندگان به داده های مورد نیاز برای ایجاد اثبات تقلب دسترسی دارند. بنابراین، نیازی نیست که کاربران رول آپ در یک مهاجرت دیوانهوار و «اول به خروج» به شبکه اصلی اتریوم شرکت کنند.
+
+## پلاسما چه تفاوتی با زنجیره جانبی و شاردینگ دارد؟ {#plasma-sidechains-sharding}
+
+پلاسما، زنجیرههای جانبی و شاردینگ تقریباً شبیه به هم هستند زیرا همگی به نوعی به شبکه اصلی اتریوم متصل میشوند. با این حال، سطح و قدرت این اتصالات متفاوت است، که بر ویژگیهای امنیتی هر محلول مقیاسبندی تأثیر میگذارد.
+
+### پلاسما در مقابل زنجیره های جانبی {#plasma-vs-sidechains}
+
+یک [سایدچین](/developers/docs/scaling/sidechains/) یک بلاک چین مستقل است که از طریق یک پل دو طرفه به شبکه اصلی اتریوم متصل است. [پلها](/bridges/) به کاربران اجازه میدهد تا توکنهایی را بین دو بلاک چین مبادله کنند تا در زنجیره جانبی تراکنش کنند، ازدحام در شبکه اصلی اتریوم کاهش مییابد و مقیاسپذیری را بهبود میبخشد. زنجیره های جانبی از مکانیزم اجماع جداگانه استفاده می کنند و معمولاً بسیار کوچکتر از شبکه اصلی اتریوم هستند. در نتیجه، پل زدن دارایی ها به این زنجیره ها مستلزم افزایش ریسک است. با توجه به فقدان ضمانتهای امنیتی به ارث رسیده از شبکه اصلی اتریوم در مدل زنجیره جانبی، کاربران در حمله به زنجیره جانبی، سرمایه خود را از دست میدهند.
+
+برعکس، زنجیره های پلاسما امنیت خود را از شبکه اصلی می گیرند. این باعث می شود که آنها به طور قابل توجهی ایمن تر از زنجیره های جانبی باشند. هم زنجیرههای جانبی و هم زنجیرههای پلاسما میتوانند پروتکلهای اجماع متفاوتی داشته باشند، اما تفاوت این است که زنجیرههای پلاسما ریشههای مرکل را برای هر بلوک در شبکه اصلی اتریوم منتشر میکنند. ریشههای بلوک قطعات کوچکی از اطلاعات هستند که میتوانیم از آنها برای تأیید اطلاعات مربوط به تراکنشهایی که در زنجیره پلاسما رخ میدهند استفاده کنیم. اگر حمله ای روی یک زنجیره پلاسما اتفاق بیفتد، کاربران می توانند با خیال راحت وجوه خود را با استفاده از شواهد مناسب به شبکه اصلی برگردانند.
+
+### پلاسما در مقابل شاردینگ {#plasma-vs-sharding}
+
+هم زنجیرههای پلاسما و هم زنجیرههای خردهای بهطور دورهای مدارک رمزنگاریشده را در شبکه اصلی اتریوم منتشر میکنند. با این حال، هر دو ویژگی های امنیتی متفاوتی دارند.
+
+زنجیرههای شارد «هدرهای دستهبندی» را به شبکه اصلی ارسال میکنند که حاوی اطلاعات دقیق در مورد هر قطعه داده است. گرهها در شبکه اصلی اعتبار خردههای داده را تأیید و اجرا میکنند، احتمال انتقال خردههای نامعتبر را کاهش میدهند و از شبکه در برابر فعالیتهای مخرب محافظت میکنند.
+
+پلاسما متفاوت است زیرا شبکه اصلی فقط حداقل اطلاعات را در مورد وضعیت زنجیره های کودک دریافت می کند. این بدان معنی است که شبکه اصلی نمی تواند به طور موثر تراکنش های انجام شده در زنجیره های فرزند را تأیید کند و امنیت آنها را کاهش دهد.
+
+**توجه داشته باشید** که شاردینگ بلاک چین اتریوم دیگر در نقشه راه نیست. با مقیاسپذیری از طریق رول آپها و [دنک شاردینگ](/roadmap/danksharding) جایگزین آن شده است.
+
+### از پلاسما استفاده کنید {#use-plasma}
+
+چندین پروژه پیادهسازیهای پلاسما را ارائه میدهند که میتوانید آنها را در برنامههای غیرمتمرکز خود ادغام کنید:
+
+- [پالیگان](https://polygon.technology/) (قبلاً شبکه متیک)
+
+## اطلاعات بیشتر {#further-reading}
+
+- [پلاسما را یاد بگیرید](https://www.learnplasma.org/en/)
+- [یک یادآوری سریع از معنای "امنیت شارد شده" و چرایی اهمیت آن](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/)
+- [Sidechains vs Plasma vs Sharding](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html)
+- [درک پلاسما، قسمت 1: مبانی](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics)
+- [زندگی و مرگ پلاسما](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#)
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md"
new file mode 100644
index 00000000000..c717daa2d86
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md"
@@ -0,0 +1,73 @@
+---
+title: زنجیرههای جانبی
+description: مقدمهای بر زنجیرههای جانبی که در حال حاضر بهعنوان راهحل مقیاسپذیری توسط جامعه اتریوم استفاده میشود.
+lang: fa
+sidebarDepth: 3
+---
+
+زنجیره جانبی، یک بلاکچین جداگانه است که مستقل از اتریوم اجرا میشود و توسط یک پل دو طرفه به شبکه اصلی اتریوم متصل می شود. زنجیره های جانبی میتوانند پارامترهای بلوک و [الگوریتم های اجماع](/developers/docs/consensus-mechanisms/) جداگانهای از اتریوم داشته باشند که اغلب برای پردازش کارآمد تراکنش ها طراحی شده اند. با این حال، استفاده از زنجیره جانبی شامل معایبی نیز میباشد، زیرا آنها ویژگیهای امنیتی اتریوم را به ارث نمیبرند. برخلاف [راه حل های مقیاس بندی لایه 2](/layer-2/)، زنجیره های جانبی تغییرات حالت و دادههای تراکنش را به شبکه اصلی اتریوم ارسال نمیکنند.
+
+همچنین زنجیرههای جانبی برخی از معیارهای عدم تمرکز یا امنیت را قربانی دستیابی به توان عملیاتی و تعداد دادههای ورودی بالا میکنند ([مثلت مقیاسپذیری](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). برخلاف آن، اتریوم متعهد است بدون به خطر انداختن تمرکززدایی و امنیت، همانطور که در [بیانیه چشم انداز](/roadmap/vision/) برای ارتقاء مشخص شده است، مقیاسپذیری کند.
+
+## زنجیرههای جانبی چگونه عمل میکنند؟ {#how-do-sidechains-work}
+
+زنجیرههای جانبی، بلاکچینهای مستقلی با دادههای تاریخی، نقشه راه توسعه و ملاحظات طراحی متفاوت هستند. در حالی که یک زنجیره جانبی ممکن است شباهتهایی سطحی با اتریوم داشته باشد، چندین ویژگی متمایز دارد.
+
+### الگوریتم های اجماع {#consensus-algorithms}
+
+یکی از ویژگیهایی که زنجیرههای جانبی را منحصر به فرد میکند (یعنی متفاوت از اتریوم)، الگوریتم اجماع مورد استفاده در آن است. زنجیرههای جانبی برای اجماع به اتریوم متکی نیستند و میتوانند پروتکلهای اجماع جایگزینی را که مطابق با نیازهایشان باشد، انتخاب کنند. برخی نمونهها از الگوریتمهای اجماع مورد استفاده در زنجیرههای جانبی عبارتند از:
+
+- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
+- [اثبات سهام واگذار شده](https://en.bitcoin.it/wiki/Delegated_proof_of_stake)
+- [تحمل خطای بیزانسی](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained).
+
+مانند اتریوم، زنجیرههای جانبی دارای گرههای اعتبارسنج هستند که تراکنشها را تائید و پردازش میکنند، بلوکها را تولید میکنند و حالت بلاکچین را ذخیره میکنند. اعتبارسنجها همچنین مسئول حفظ اجماع در سراسر شبکه و ایمنسازی آن در برابر حملات مخرب هستند.
+
+#### پارامترهای بلوک {#block-parameters}
+
+اتریوم محدودیتهایی را برای [زمان بلوکها](/developers/docs/blocks/#block-time) (یعنی مدت زمانی که تولید بلوکهای جدید طول میکشد) و [اندازه بلوکها](/developers/docs/blocks/#block-size) (یعنی مقدار دادههای موجود در هر بلوک، بر حسب گاز) تعیین میکند. اما برخلاف آن، زنجیرههای جانبی اغلب پارامترهای مختلفی مانند زمان بلوکهای سریعتر و محدودیتهای گاز بیشتر را برای دستیابی به توان عملیاتی بالا، تراکنشهای سریع و کارمزدهای پایین اتخاذ میکنند.
+
+در حالی که این امر دارای مزایای مفیدی است، پیامدهای مهمی برای تمرکز زدایی و امنیت شبکه دارد. پارامترهای بلوک، مانند زمان کم برای ایجاد بلوک و اندازه بلوکهای بزرگ، دشواری اجرای یک گره کامل را افزایش میدهند و چند "ابرگره" مسئول حفظ زنجیره میشوند. در چنین سناریویی، احتمال تبانی اعتبارسنجها یا تصاحب مخرب زنجیره، افزایش مییابد.
+
+برای اینکه بلاکچینها بدون آسیب رساندن به تمرکز زدایی، مقیاسپذیر شوند، اجرای یک گره باید برای همه آزاد باشد – نه اینکه تنها نهادهایی با سختافزار تخصصی بتوانند آن را اجرا کنند. به همین دلیل تلاشهایی در حال انجام است تا اطمینان حاصل شود که همه میتوانند [یک گره کامل](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) را در شبکه اتریوم اجرا کنند.
+
+### سازگاری با EVM {#evm-compatibility}
+
+برخی از زنجیرههای جانبی با EVM سازگار هستند و میتوانند قراردادهای توسعهیافته برای [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) را اجرا کنند. زنجیرههای جانبی سازگار با EVM، از قراردادهای هوشمند [نوشته شده با زبان برنامه نویسی Solidity](/developers/docs/smart-contracts/languages/) و همچنین سایر زبانهای قرارداد هوشمند سازگار با EVM پشتیبانی میکنند، به این معنی که قراردادهای هوشمند نوشته شده برای شبکه اصلی اتریوم، روی زنجیرههای جانبی سازگار با EVM نیز کار میکنند.
+
+این به معنی آن است که اگر میخواهید از [برنامه غیرمتمرکزdapp](/developers/docs/dapps/) خود در یک زنجیره جانبی استفاده کنید، فقط باید [قرارداد هوشمند](/developers/docs/smart-contracts/) خود را در این زنجیره جانبی مستقر کنید. این ظاهر و حس مشابه شبکه اصلی اتریوم را دارد و درست مانند آن عمل میکند - شما قراردادها را با زبان Solidity می نویسید و از طریق RPC زنجیرههای جانبی، با زنجیره تعامل میکنید.
+
+از آنجایی که زنجیره های جانبی با EVM سازگار هستند، به عنوان یک [راه حل مقیاس پذیر](/developers/docs/scaling/) مفید برای برنامههای غیرمتمرکز بومی اتریوم در نظر گرفته میشوند. با استقرار برنامه شما روی یک زنجیره جانبی، کاربران میتوانند از هزینههای کمتر گاز و تراکنشهای سریعتر لذت ببرند، به خصوص اگر شبکه اصلی اتریوم شلوغ باشد.
+
+با این حال، همانطور که قبلا توضیح داده شد، استفاده از یک زنجیره جانبی شامل محدودیتهای قابل توجهی میباشد. هر زنجیره جانبی مسئول امنیت خود است و ویژگیهای امنیتی اتریوم را به ارث نمیبرد. این احتمال رفتار مخرب را افزایش میدهد که میتواند بر کاربران شما تائیر بگذارد یا سرمایه آنها را در معرض خطر قرار دهد.
+
+### انتقال دارایی {#asset-movement}
+
+برای اینکه یک بلاکچین جداگانه به یک زنجیره جانبی برای شبکه اصلی اتریوم تبدیل شود، به توانایی انتقال آسان داراییها از و به شبکه اتریوم نیاز دارد. این قابلیت سازگاری دوجانبه با اتریوم، با استفاده از یک پل بلاکچین به دست میآید. [پلها](/bridges/) از قراردادهای هوشمند مستقر در شبکه اصلی اتریوم و یک زنجیره جانبی یا زنجیره جانبی برای کنترل پل زدن وجوه بین آنها استفاده میکنند.
+
+در حالی که پلها به کاربران کمک میکنند وجوه بین اتریوم و زنجیره جانبی را جابجا کنند، داراییها به صورت فیزیکی در دو زنجیره جابجا نمیشوند. در عوض، مکانیزمهایی که معمولاً شامل ضرب کردن و سوزاندن هستند برای انتقال ارزش در زنجیرهها استفاده میشوند. اطلاعات بیشتر در مورد [نحوه عملکرد پلها](/developers/docs/bridges/#how-do-bridges-work).
+
+## مزایا و معایب زنجیرههای جانبی {#pros-and-cons-of-sidechains}
+
+| نقاط مثبت | نقاط ضعف |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| فناوری زیربنای زنجیرههای جانبی به خوبی تثبیت شده و از تحقیقات گسترده و بهبود در طراحی بهره میبرد. | زنجیره های جانبی برخی از معیارهای عدم تمرکز و عدم نیاز به اعتماد را در ازای مقیاس پذیری معاوضه می کنند. |
+| زنجیره های جانبی از محاسبات عمومی پشتیبانی می کنند و سازگاری با EVM را ارائه می دهند (آنها می توانند برنامههای غیرمتمرکز بومی اتریوم را اجرا کنند). | زنجیره جانبی از یک مکانیزم اجماع جداگانه استفاده میکند و از تضمینهای امنیتی اتریوم بهره نمیبرد. |
+| زنجیرههای جانبی از مدلهای اجماع متفاوت برای پردازش کارآمد تراکنشها و کاهش هزینه تراکنش برای کاربران استفاده میکنند. | زنجیرههای جانبی به مفروضات اعتماد بالاتری نیاز دارند (به عنوان مثال، این که چه حد نصابی از اعتبارسنجهای زنجیره جانبی مخرب میتوانند مرتکب تقلب شوند). |
+| زنجیرههای جانبی سازگار با EVM به برنامههای غیرمتمرکز یا dappها اجازه میدهند اکوسیستم خود را گسترش دهند. | |
+
+### از زنجیرههای جانبی استفاده نمایید {#use-sidechains}
+
+پروژههای متعدد زنجیرههای جانبی را پیادهسازی کرده اند که میتوانید آنها را با dappهای خود ادغام کنید:
+
+- [زنجیره پالیگان با سیستم اثبات سهام (PoS)](https://polygon.technology/solutions/polygon-pos)
+- [Skale](https://skale.network/)
+- [زنجیره Gnosis (xDai سابق)](https://www.gnosischain.com/)
+- [شبکه لوم (Loom)](https://loomx.io/)
+- [Metis Andromeda](https://www.metis.io/)
+
+## بیشتر بخوانید {#further-reading}
+
+- [مقیاسپذیری اتریوم از طریق زنجیرههای جانبی](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _ - منتشر شده در 8 فوریه 2018 توسط جورجیوس کنستانتوپولوس (Georgios Konstantopoulos)_
+
+_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md"
new file mode 100644
index 00000000000..4c0a1d3cea6
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md"
@@ -0,0 +1,67 @@
+---
+title: کانالهای حالت
+description: مقدمهای بر کانالهای استیت و کانالهای پرداخت به عنوان یک راه حل مقیاس پذیر که در حال حاضر توسط جامعه اتریوم استفاده میشود.
+lang: fa
+sidebarDepth: 3
+---
+
+کانالهای استیت به شرکتکنندگان این امکان را میدهند که به طور ایمن تراکنشهای خارج از زنجیره را انجام دهند و در عین حال تعامل با اتریوم شبکه اصلی را به حداقل میرسانند. همتایان کانال میتوانند تعداد دلخواه تراکنشهای خارج از زنجیره را انجام دهند در حالی که تنها دو تراکنش درون زنجیرهای را برای باز و بسته کردن کانال ارسال میکنند. این امکان انجام تراکنش بسیار بالا را فراهم میکند و منجر به کاهش هزینه برای کاربران میشود.
+
+## {#how-do-sidechains-work}
+
+بلاک چینهای عمومی، مانند اتریوم، به دلیل معماری توزیع شده با چالشهای مقیاسپذیری مواجه هستند: تراکنشهای روی زنجیره باید توسط همه گرهها اجرا شوند. گرهها باید بتوانند حجم تراکنشها را در یک بلوک با استفاده از سختافزار معمولی مدیریت و محدودیتی را بر روی توان عملیاتی تراکنش اعمال کنند تا شبکه را غیرمتمرکز نگه دارد.
+
+### {#consensus-algorithms}
+
+کانالها پروتکلهای همتا به همتای سادهای هستند که به دو طرف اجازه میدهند تا تراکنشهای زیادی را بین خود انجام دهند و سپس نتایج نهایی را به بلاک چین ارسال کنند. این کانال از رمزنگاری استفاده میکند تا نشان دهد که خلاصه دادههایی که تولید میکنند واقعاً نتیجه مجموعه معتبری از تراکنشهای میانی است. قرارداد هوشمند ["چندامضایی"](/developers/docs/smart-contracts/#multisig) تضمین میکند که تراکنشها توسط طرفهای صحیح امضا شدهاند.
+
+- []()
+- []()
+-
+
+با استفاده از کانالها، تغییرات حالت توسط طرفهای ذینفع اجرا و تایید میشود و محاسبات در لایه اجرای اتریوم به حداقل میرسد. این امر باعث کاهش تراکم اتریوم و همچنین افزایش سرعت پردازش تراکنش برای کاربران میشود.
+
+#### {#block-parameters}
+
+هر کانال توسط یک [قرارداد هوشمند چندامضایی](/developers/docs/smart-contracts/#multisig) مدیریت شده که روی اتریوم اجرا میشود. برای باز کردن یک کانال، شرکت کنندگان قرارداد کانال را به صورت زنجیرهای مستقر کرده و وجوه را در آن واریز میکنند.
+
+برای بستن کانال، شرکت کنندگان آخرین وضعیت توافق شده کانال را در زنجیره ارسال میکنند. پس از آن، قرارداد هوشمند وجوه قفل شده را بر اساس موجودی هر یک از شرکت کنندگان در وضعیت نهایی کانال توزیع میکند.
+
+کانالهای همتا به همتا بهویژه برای موقعیتهایی مفید هستند که برخی از شرکتکنندگان از پیش تعریفشده میخواهند با فرکانس بالا بدون تحمیل هزینههای قابل مشاهده انجام دهند. کانالهای بلاک چین در دو دسته قرار میگیرند: **کانال های پرداخت** و **کانال های استیت یا حالت**.
+
+### {#evm-compatibility}
+
+کانال پرداخت به بهترین شکل به عنوان یک "دفتر کل دو طرفه" توصیف شده که به طور جمعی توسط دو کاربر نگهداری میشود. موجودی اولیه دفتر کل، مجموع سپردههای قفل شده در قرارداد زنجیرهای در مرحله افتتاح کانال است.
+
+بهروزرسانی موجودی دفتر کل (یعنی وضعیت کانال پرداخت) به تأیید همه طرفهای کانال نیاز دارد. بهروزرسانی کانال، که توسط همه شرکتکنندگان کانال امضا شده است، مانند تراکنش در اتریوم، نهایی شده در نظر گرفته میشود.
+
+کانالهای پرداخت یکی از اولین راهحلهای مقیاسبندی بودند که برای به حداقل رساندن فعالیت زنجیرهای گرانقیمت تعاملات ساده کاربر (مانند انتقال اتر، مبادله یا سواپ اتمی، پرداختهای خرد) طراحی شدند. شرکتکنندگان کانال میتوانند تعداد نامحدودی از تراکنشهای فوری را بین یکدیگر انجام دهند تا زمانی که مجموع خالص انتقالهای آنها از توکنهای سپردهگذاری شده بیشتر نشود.
+
+جدای از پشتیبانی از پرداختهای خارج از زنجیره، کانالهای پرداخت برای مدیریت منطق انتقال حالت عمومی مفید نیستند. کانالهای حالت برای حل این مشکل و مفید ساختن کانالها برای مقیاسپذیری محاسبات همه منظوره ایجاد شدند.
+
+### {#asset-movement}
+
+کانالهای استیت هنوز اشتراکات زیادی با کانالهای پرداخت دارند. برای مثال، کاربران با مبادله پیامهای امضا شده رمزنگاری شده (تراکنشها)، که سایر شرکتکنندگان کانال نیز باید آنها را امضا کنند، تعامل دارند. اگر یک بهروزرسانی وضعیت پیشنهادی توسط همه شرکتکنندگان امضا نشود، نامعتبر تلقی میشود.
+
+## {#pros-and-cons-of-sidechains}
+
+| | |
+| | |
+| | |
+| | |
+| | |
+| | |
+
+### {#use-sidechains}
+
+- []()
+- []()
+- []()
+- []()
+- []()
+
+## {#further-reading}
+
+-
+
+_ _
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md"
new file mode 100644
index 00000000000..0f94e7f2862
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md"
@@ -0,0 +1,165 @@
+---
+title: ولیدیوم
+description: مقدمه ای بر ولیدیوم به عنوان یک راه حل مقیاس بندی که در حال حاضر توسط انجمن اتریوم استفاده می شود.
+lang: fa
+sidebarDepth: 3
+---
+
+ولیدیوم یک [راه حل مقیاسپذیری](/developers/docs/scaling/) است که یکپارچگی تراکنشها را با استفاده از اثبات اعتبار مانند [ رول آپ دانش صفر اعمال میکند](/developers/docs/scaling/zk-rollups/)، اما دادههای تراکنش را در شبکه اصلی اتریوم ذخیره نمیکند. در حالی که در دسترس بودن دادههای خارج از زنجیره باعث ایجاد مبادلات میشود، میتواند منجر به بهبودهای گسترده در مقیاس پذیری شود (ولیدیومها میتوانند ).
+
+## پیش نیازها {#prerequisites}
+
+شما باید صفحه ما را در [مقیاسسازی اتریوم](/developers/docs/scaling/) و [لایه 2](/layer-2) خوانده و درک کرده باشید.
+
+## ولیدیوم چیست؟ {#what-is-validium}
+
+ولیدیومها (Validium) راه حلهای مقیاسبندی هستند که از در دسترس بودن دادههای خارج از زنجیره و محاسبات طراحی شده برای بهبود توان عملیاتی با پردازش تراکنشهای خارج از شبکه اصلی اتریوم استفاده میکنند. مانند رول آپهای دانش صفر (ZK-rollups)، ولیدیوم[اثبات دانش صفر](/glossary/#zk-proof) را برای تأیید تراکنشهای خارج از زنجیره در اتریوم منتشر میکنند. این از انتقال حالت نامعتبر جلوگیری میکند و تضمینهای امنیتی یک زنجیره ولیدیوم را افزایش میدهد.
+
+این «اثبات اعتبار» میتواند به شکل ZK-SNARK (برهان دانش مختصر غیر تعاملی با دانش صفر) یا ZK-STARK (برهان شفاف دانش مقیاس پذیر با دانش صفر) باشد. اطلاعات بیشتر در مورد [اثبات دانش صفر](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/).
+
+وجوه متعلق به کاربران اعتباری توسط یک قرارداد هوشمند در اتریوم کنترل میشود. ولیدیومها دقیقاً مانند رول آپهای دانش صفر برداشتهای تقریباً فوری را ارائه میدهند. پس از تأیید اعتبار درخواست برداشت در شبکه اصلی، کاربران میتوانند با ارائه [مدارک Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) وجوه خود را برداشت کنند. اثبات مرکل گنجاندن تراکنش برداشت کاربر در یک دسته تراکنش تأیید شده را تأیید میکند و به قرارداد زنجیرهای اجازه میدهد تا برداشت را پردازش کند.
+
+با این حال، ممکن است وجوه کاربران ولیدیوم مسدود و برداشت محدود شود. این مورد میتواند اتفاق بیفتد اگر مدیران دسترسی داده در زنجیره ولیدیوم، دادههای حالت خارج از زنجیره را از دسترسی کاربران خارج کنند. بدون دسترسی به دادههای تراکنش، کاربران نمیتوانند اثبات مرکل مورد نیاز برای اثبات مالکیت وجوه و برداشتها را محاسبه کنند.
+
+این تفاوت اصلی بین ولیدیوم و ZK-rollupها است یعنی موقعیت آنها در طیف در دسترس بودن دادهها تفاوت دارد. هر دو راهحل به طور متفاوت به ذخیرهسازی دادهها نگاه میکنند، که پیامدهایی برای امنیت و بدون نیاز به اعتماد دارد.
+
+## ولیدیومها چگونه با اتریوم تعامل دارند؟ {#how-do-validiums-interact-with-ethereum}
+
+ولیدیومها پروتکلهای مقیاسپذیر هستند که بر روی زنجیره موجود اتریوم ساخته شدهاند. اگرچه تراکنشهای خارج از زنجیره را اجرا میکند، یک زنجیره اعتباری توسط مجموعهای از قراردادهای هوشمند مستقر در شبکه اصلی مدیریت میشود، از جمله:
+
+1. **قرارداد تأییدکننده**: قرارداد تأییدکننده اعتبار مدارک ارائه شده توسط اپراتور ولیدیوم را هنگام بهروزرسانی وضعیت تأیید میکند. این عبارت است از اثباتهای ولیدیوم که صحت تراکنشهای خارج از زنجیره را تأیید میکنند و شواهد قابلیت دسترسی دادهها که وجود دادههای تراکنش خارج از زنجیره را تأیید میکنند.
+
+2. **قرارداد اصلی**: قرارداد اصلی تعهدات دولتی (ریشههای مرکل) ارائه شده توسط تولیدکنندگان بلوک را ذخیره میکند و پس از تأیید اعتبار در زنجیره، وضعیت ولیدیوم را به روز می کند. این قرارداد همچنین سپردهها و برداشتها از زنجیره ولیدیوم را پردازش میکند.
+
+ولیدیومها همچنین برای موارد زیر به زنجیره اصلی اتریوم متکی هستند:
+
+### توافق {#settlement}
+
+تراکنشهای انجام شده بر روی یک ولیدیوم را نمیتوان به طور کامل تأیید کرد تا زمانی که زنجیره اصلی اعتبار آنها را تأیید کند. تمام معاملاتی که با ولیدیوم انجام میشوند باید در نهایت در شبکه اصلی حل و فصل شوند. همچنین بلاک چین اتریوم «ضمانتهای تسویه حساب» را برای کاربران اعتباری ارائه میکند، به این معنی که تراکنشهای خارج از زنجیره را نمیتوان پس از تعهد به روی زنجیره، معکوس یا تغییر داد.
+
+### امنیت {#security}
+
+اتریوم که به عنوان یک لایه تسویه حساب عمل میکند، اعتبار انتقال حالت در اعتبار را نیز تضمین میکند. تراکنشهای خارج از زنجیره اجرا شده در زنجیره ولیدیوم از طریق یک قرارداد هوشمند در لایه پایه اتریوم تأیید میشوند.
+
+اگر قرارداد تأییدکننده زنجیرهای، اثبات را نامعتبر بداند، معاملات رد میشوند. این بدان معناست که اپراتورها باید قبل از بهروزرسانی وضعیت ولیدیوم، شرایط اعتبار اعمال شده توسط پروتکل اتریوم را برآورده کنند.
+
+## ولیدیوم چگونه کار میکند؟ {#how-does-validium-work}
+
+### تراکنشها {#transactions}
+
+کاربران تراکنشها را به اپراتور ارسال میکنند، گرهای که مسئول اجرای تراکنشها در زنجیره ولیدیوم است. برخی از ولیدیومها ممکن است از یک اپراتور انحصاری برای اجرای زنجیره استفاده کنند یا به مکانیزم [اثبات سهام (PoS)](/developers/docs/consensus-mechanisms/pos/) برای اپراتورهای چرخشی تکیه کنند.
+
+اپراتور تراکنشها را در یک دسته جمع میکند و آن را برای اثبات به مدار اثبات میفرستد. مدار اثبات، دسته تراکنش (و سایر دادههای مربوطه) را به عنوان ورودی و خروجی میپذیرد که تأیید صحت عملیات را تأیید میکند.
+
+### ثبت تعهد حالت {#state-commitments}
+
+وضعیت اعتبار به صورت درخت مرکل با ریشه ذخیره شده در قرارداد اصلی در اتریوم هش میشود. ریشه مرکل که به عنوان ریشه حالت نیز شناخته میشود، به عنوان یک تعهد رمزنگاری به وضعیت فعلی حسابها و موجودیهای ولیدیوم عمل میکند.
+
+برای انجام یک به روز رسانی حالت، اپراتور باید یک ریشه حالت جدید (پس از اجرای تراکنشها) محاسبه کرده و آن را به قرارداد روی زنجیره ارسال کند. اگر اثبات ولیدیوم بررسی شود، حالت پیشنهادی پذیرفته میشود و ولیدیوم به ریشه حالت جدید تغییر میکند.
+
+### سپردهها و برداشتها {#deposits-and-withdrawals}
+
+کاربران با واریز اتریوم (یا هر توکن سازگار با ERC) در قرارداد روی زنجیره، وجوه را از اتریوم به ولیدیوم منتقل میکنند. این قرارداد، رویداد سپرده را به ولیدیوم خارج از زنجیره منتقل میکند، جایی که آدرس کاربر با مبلغی برابر با سپرده وی اعتبار داده میشود. اپراتور همچنین این تراکنش سپرده را در یک دسته جدید میگنجاند.
+
+برای بازگرداندن وجوه به شبکه اصلی، یک کاربر ولیدیوم تراکنش برداشت را آغاز کرده و آن را به اپراتور ارسال میکند که درخواست برداشت را تأیید کرده و آن را در یک دسته قرار میدهد. داراییهای کاربر در زنجیره ولیدیوم نیز قبل از خروج از سیستم از بین میرود. هنگامی که اثبات اعتبار مرتبط با دسته تأیید شد، کاربر میتواند با قرارداد اصلی تماس بگیرد تا باقی مانده سپرده اولیه خود را برداشت کند.
+
+به عنوان یک مکانیزم ضد سانسور، پروتکل ولیدیوم به کاربران اجازه میدهد تا مستقیماً از قرارداد ولیدیوم بدون مراجعه به اپراتور خارج شوند. در این مورد، کاربران باید مدرک مرکل را به قرارداد تأییدکننده ارائه دهند که نشان دهنده گنجاندن یک حساب در ریشه حالت باشد. در صورت پذیرفته شدن مدرک، کاربر میتواند تابع برداشت قرارداد اصلی را فراخوانی کرده تا وجوه خود را از ولیدیوم خارج کند.
+
+### ارسال دستهای {#batch-submission}
+
+پس از اجرای دستهای از تراکنشها، اپراتور اثبات اعتبار مرتبط را به قرارداد تأیید کننده ارائه میکند و یک ریشه حالت جدید را برای قرارداد اصلی پیشنهاد میکند. اگر اثبات معتبر باشد، قرارداد اصلی وضعیت ولیدیوم را به روز کرده و نتایج تراکنشها را در دسته نهایی میکند.
+
+برخلاف رول آپهای دانش صفر، تولیدکنندگان بلوک در یک ولیدیوم نیازی به انتشار دادههای تراکنش برای دستههای تراکنش ندارند (فقط سرهای بلوک). این مورد باعث میشود ولیدیوم یک پروتکل مقیاسپذیری صرفاً خارج از زنجیره باشد، برخلاف پروتکلهای مقیاسبندی «هیبریدی» (یعنی [لایه 2](/layer-2/)) که دادههای وضعیت را در زنجیره اصلی اتریوم به عنوان `کال دیتا` منتشر میکند.
+
+### دسترسی به دادهها {#data-availability}
+
+همانطور که گفته شد، ولیدیومها از یک مدل قابلیت دسترسی داده خارج از زنجیره استفاده میکنند، که در آن اپراتورها تمام دادههای تراکنش را از شبکه اصلی اتریوم ذخیره میکنند. ردپای کم دادههای زنجیرهای ولیدیوم مقیاسپذیری را بهبود میبخشد (خروجی توسط ظرفیت پردازش دادههای اتریوم محدود نمیشود) و هزینههای کاربر را کاهش میدهد (هزینه انتشار `کال دیتا` کمتر است).
+
+با این حال، در دسترس بودن دادههای خارج از زنجیره مشکلی را ایجاد میکند: ممکن است دادههای لازم برای ایجاد یا تأیید مدارک مرکل در دسترس نباشد. این بدان معنی است که اگر اپراتورها بدخواهانه عمل کنند، ممکن است کاربران نتوانند وجوه خود را از قرارداد زنجیرهای برداشت کنند.
+
+راهحلهای مختلف ولیدیوم سعی میکنند این مشکل را با غیرمتمرکز کردن ذخیرهسازی دادههای حالت حل کنند. این مورد شامل مجبور کردن تولیدکنندگان بلوک برای ارسال دادههای اساسی به "مدیران دسترسی داده" است که مسئول ذخیره دادههای خارج از زنجیره هستند و در صورت درخواست در دسترس کاربران قرار میگیرند.
+
+مدیران دسترسی دادهها در ولیدیوم، با امضای هر دسته اعتباری، در دسترس بودن دادهها را برای تراکنشهای خارج از زنجیره تأیید میکنند. این امضاها شکلی از «اثبات قابلیت دسترسی» را تشکیل میدهند که قرارداد تأییدکننده زنجیرهای، قبل از تأیید بهروزرسانیهای حالت بررسی میکند.
+
+ولیدیومها در رویکردشان به مدیریت قابلیت دسترسی دادهها متفاوت هستند. برخی برای ذخیره دادههای وضعیت به اشخاص مورد اعتماد متکی هستند، در حالی که برخی دیگر از اعتبارسنجهای اختصاص داده شده به طور تصادفی برای این کار استفاده میکنند.
+
+#### کمیته قابلیت دسترسی دادهها (DAC) {#data-availability-committee}
+
+برای تضمین قابلیت دسترسی دادههای خارج از زنجیره، برخی راهحلهای ولیدیوم گروهی از نهادهای مورد اعتماد را که در مجموع به عنوان کمیته قابلیت دسترسی دادهها (DAC) شناخته میشوند، منصوب میکنند تا کپیهایی از حالت را ذخیره و مدرکی دال بر در دسترس بودن داده ارائه کنند. اجرای DAC آسانتر است و به هماهنگی کمتری نیاز دارد زیرا عضویت پایین است.
+
+با این حال، کاربران باید به DAC اعتماد کنند تا دادهها را در صورت نیاز در دسترس قرار دهد (به عنوان مثال، برای تولید اثباتهای مرکل). این امکان وجود دارد که اعضای کمیتههای دسترسی داده [توسط یک عامل مخرب](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view) در معرض خطر قرار گیرند که میتواند دادههای خارج از زنجیره را مخفی کند.
+
+[اطلاعات بیشتر در مورد کمیتههای دسترسی داده در ولیدیوم](https://medium.com/starkware/data-availability-e5564c416424).
+
+#### در دسترس بودن دادههای مسیر {#bonded-data-availability}
+
+سایر ولیدیومها، شرکتکنندگانی را ملزم میکنند که دادههای آفلاین را ذخیره کنند تا توکنها را در یک قرارداد هوشمند به اشتراک بگذارند (یعنی قفل کنند) قبل از اینکه نقش خود را به عهده بگیرند. این سهام به عنوان یک "مسیر" برای تضمین رفتار صادقانه در میان مدیران در دسترس بودن دادهها عمل میکند و مفروضات اعتماد را کاهش میدهد. اگر این شرکت کنندگان نتوانند در دسترس بودن دادهها را اثبات کنند، مسیر مجازات میشود.
+
+در یک طرح در دسترس بودن دادههای مسیر، هر کس میتواند پس از ارائه سهام گذاری مورد نیاز، به نگهداری دادههای خارج از زنجیره اختصاص یابد. این امر مجموعه مدیران در دسترس بودن دادههای واجد شرایط را گسترش میدهد و تمرکزی را که بر کمیتههای در دسترس بودن دادهها (DAC) تأثیر میگذارد، کاهش میدهد. مهمتر از آن، این رویکرد برای جلوگیری از فعالیتهای مخرب بر انگیزههای اقتصاد رمزارزی تکیه میکند، که به طور قابل توجه ایمنتر از انتصاب اشخاص مورد اعتماد برای ایمنسازی دادههای آفلاین در ولیدیوم است.
+
+[اطلاعات بیشتر در مورد در دسترس بودن دادههای مسیر درولیدیومها](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf).
+
+## اراده و ولیدیوم {#volitions-and-validium}
+
+ولیدیومها مزایای زیادی را ارائه میدهند اما با معاوضههایی همراه هستند (به ویژه در دسترس بودن دادهها). اما، مانند بسیاری از راهحلهای مقیاسپذیری، ولیدیومها برای موارد استفاده خاص مناسب هستند - به همین دلیل است که اراده ها ایجاد شدند.
+
+اراده ها یک زنجیره رولآپ ZK و ولیدیوم را ترکیب میکند و به کاربران اجازه میدهد بین دو راه حل مقیاسپذیری جابجا شوند. با ارادهها، کاربران میتوانند از در دسترس بودن دادههای خارج از زنجیره ولیدیوم برای تراکنشهای خاص استفاده کنند، در حالی که آزادی تغییر به راهحل در دسترس بودن داده روی زنجیره (ZK-rollup) را در صورت نیاز حفظ میکنند. این مورد اساساً به کاربران این آزادی را میدهد که مطابق با شرایط منحصر به فرد خود، مبادلاتی را انتخاب کنند.
+
+یک صرافی غیرمتمرکز (DEX) ممکن است استفاده از زیرساخت مقیاسپذیر و خصوصی ولیدیوم را برای معاملات با ارزش ترجیح دهد. همچنین میتواند از ZK-rollup برای کاربرانی استفاده کند که ضمانتهای امنیتی بالاتر و بدون نیاز به اعتماد بودن ZK-rollup را میخواهند.
+
+## سازگاری ولیدیوم و ماشین مجازی اتریوم {#validiums-and-evm-compatibility}
+
+مانند ZK-rollups، اعتبارسنجها بیشتر برای برنامههای کاربردی ساده، مانند مبادله توکن و پرداخت مناسب هستند. پشتیبانی از محاسبات عمومی و اجرای قراردادهای هوشمند در میان ولیدیومها، با توجه به میزان قابلتوجه اثبات دستورالعملهای [EVM](/developers/docs/evm/) در مدار اثبات دانش صفر، دشوار است.
+
+برخی از پروژههای ولیدیوم سعی میکنند با کامپایل کردن زبانهای سازگار با EVM (مانند سالیدیتی، وایپر) برای ایجاد بایت کد سفارشی بهینهسازی شده برای اثبات کارآمد، از این مشکل دوری کنند. یک اشکال این رویکرد این است که VMهای جدید و سازگار با دانش صفر ممکن است از کدهای عملیاتی مهم EVM پشتیبانی نکنند و توسعه دهندگان برای تجربه بهینه باید مستقیماً به زبان سطح بالا بنویسند. این مورد حتی مشکلات بیشتری ایجاد میکند: توسعهدهندگان را مجبور میکند تا Dappهایی را با یک پشته یا استک توسعه کاملاً جدید و سازگاری توقفها با زیرساخت فعلی اتریوم را بسازند.
+
+با این حال، برخی از تیمها در تلاش هستند تا کدهای عملیاتی EVM موجود را برای مدارهای اثبات ZK بهینه کنند. این مورد منجر به توسعه یک ماشین مجازی اتریوم (zkEVM) با دانش صفر میشود، یک ماشین مجازی سازگار با EVM که شواهدی را برای تأیید صحت اجرای برنامه تولید میکند. با zkEVM، زنجیرههای ولیدیوم میتوانند قراردادهای هوشمند را خارج از زنجیره اجرا کنند و مدارک ولیدیوم را برای تأیید محاسبات خارج از زنجیره (بدون نیاز به اجرای مجدد آن) در اتریوم ارسال کنند.
+
+[اطلاعات بیشتر در مورد zkEVMها](https://www.alchemy.com/overviews/zkevm).
+
+## ولیدیومها چگونه اتریوم را مقیاسپذیر میکنند؟ {#scaling-ethereum-with-validiums}
+
+### 1. ذخیرهسازی دادهها خارج از زنجیره {#off-chain-data-storage}
+
+پروژههای مقیاسپذیری لایه ۲، مانند آپتیمیستیک رول آپ و رول آپهای ZK، مقیاسپذیری بینهایت پروتکلهای مقیاسپذیری خالص خارج از زنجیره را معامله میکنند (به عنوان مثال، [پلاسما](/developers/docs/scaling/plasma/)) برای امنیت با انتشار برخی از دادههای تراکنش در لایه 1 یکی از این موارد است. اما این بدان معناست که ویژگیهای مقیاسپذیری جمعآوریها توسط پهنای باند داده در شبکه اصلی اتریوم محدود میشود ([شاردینگ دادهها](/roadmap/danksharding/) به این دلیل پیشنهاد میکند ظرفیت ذخیرهسازی دادههای اتریوم را بهبود بخشد).
+
+ولیدیومها با نگه داشتن تمام دادههای تراکنش خارج از زنجیره و تنها تعهدات پس از وضعیت (و اثبات اعتبار) در هنگام انتقال به روزرسانیهای حالت به زنجیره اصلی اتریوم، به مقیاس پذیری دست مییابند. با این حال، وجود اثباتهای اعتبار، تضمینهای امنیتی بالاتری را نسبت به سایر راهحلهای مقیاسپذیری خالص خارج از زنجیره، از جمله پلاسما و [زنجیرههای جانبی](/developers/docs/scaling/sidechains/) ارائه میدهد. با کاهش حجم دادههایی که اتریوم باید قبل از اعتبارسنجی تراکنشهای خارج از زنجیره پردازش کند، طرحهای ولیدیوم تا حد زیادی توان عملیاتی شبکه اصلی را افزایش میدهند.
+
+### 2. اثبات های بازگشتی {#recursive-proofs}
+
+اثبات بازگشتی، اثبات اعتباری است که اعتبار ادله دیگر را تأیید میکند. این «اثباتها» با تجمیع چندگانه به صورت بازگشتی ایجاد میشوند تا زمانی که یک اثبات نهایی تأییدکننده همه اثبات های قبلی ایجاد شود. اثبات بازگشتی، سرعت پردازش بلاک چین را با افزایش تعداد تراکنشهایی که میتوان به ازای اثبات اعتبار تأیید کرد، افزایش میدهد.
+
+به طور معمول، هر مدرک اعتباری که اپراتور اعتبار برای تأیید به اتریوم ارسال میکند، یکپارچگی یک بلوک واحد را نیز تأیید میکند. در حالی که یک اثبات بازگشتی منفرد میتواند برای تأیید اعتبار چندین بلوک ولیدیوم به طور همزمان استفاده شود - این امکان وجود دارد زیرا مدار اثبات میتواند به صورت بازگشتی چندین اثبات بلوک را در یک اثبات نهایی جمع کند. اگر قرارداد تأییدکننده روی زنجیره، اثبات بازگشتی را بپذیرد، تمام بلوکهای زیربنایی بلافاصله نهایی میشوند.
+
+## جوانب مثبت و منفی ولیدیوم {#pros-and-cons-of-validium}
+
+| مزایا | معایب |
+| ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| اثبات اعتبار، یکپارچگی تراکنشهای خارج از زنجیره را اعمال کرده و از نهایی کردن بهروزرسانیهای وضعیت نامعتبر توسط اپراتورها جلوگیری میکند. | تولید اثبات اعتبار نیاز به سختافزار خاصی دارد که خطر تمرکز را به همراه دارد. |
+| کارایی سرمایه را برای کاربران افزایش میدهد (بدون تاخیر در برداشت وجه به اتریوم) | پشتیبانی محدود برای محاسبات عمومی/قراردادهای هوشمند؛ زبانهای تخصصی برای توسعه لازم هستند. |
+| در برابر حملات اقتصادی خاصی که سیستمهای مبتنی بر تقلب در برنامههای کاربردی با ارزش بالا با آنها مواجه میشوند، آسیبپذیر نیست. | قدرت محاسباتی بالا مورد نیاز برای تولید اثبات ZK؛ برای برنامههای کاربردی کم توان مقرون به صرفه نیست. |
+| با ارسال نکردن کال دیتا به شبکه اصلی اتریوم، هزینههای گس را برای کاربران کاهش میدهد. | زمان نهاییسازی کندتر (10-30 دقیقه برای ایجاد اثبات ZK) اما سریعتر در نهایی شدن کامل زیرا تاخیر زمانی اختلاف وجود ندارد. |
+| مناسب برای موارد استفاده خاص، مانند معامله یا بازیهای بلاک چین که حریم خصوصی تراکنشها و مقیاسپذیری را در اولویت قرار میدهند. | میتوان از برداشت وجه توسط کاربران جلوگیری کرد، زیرا برای ایجاد مدارک مالکیت مرکل نیاز است که دادههای خارج از زنجیره همیشه در دسترس باشد. |
+| در دسترس بودن دادههای خارج از زنجیره سطوح بالاتری از توان عملیاتی را فراهم میکند و مقیاسپذیری را افزایش میدهد. | مدل امنیتی بر فرضیات اعتماد و انگیزههای ارز دیجیتال متکی است، برخلاف ZK-rollupها، که صرفاً بر مکانیزمهای امنیتی رمزنگاری متکی هستند. |
+
+### از ولیدیوم/ارادهها استفاده کنید {#use-validium-and-volitions}
+
+پروژههای متعدد پیادهسازیهایی از ولیدیوم و ارادهها را ارائه میدهند که میتوانید آنها را در dappهای خود ادغام کنید:
+
+**StarkWare StarkEx** - _StarkEx یک راه حل مقیاسپذیری لایه 2 اتریوم (L2) است که بر اساس اثبات اعتبار است. میتواند در حالتهای دسترسی به داده ZK-Rollup یا ولیدیوم کار کند._
+
+- [مستندات](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium)
+- [وب سایت](https://starkware.co/starkex/)
+
+**Matter Labs zkPorter**- _zkPorter یک پروتکل مقیاسپذیری لایه 2 است که در دسترس بودن دادهها را با رویکرد ترکیبی ترکیب میکند که ایدههای zkRollup و شاردینگ را با هم ترکیب کند. میتواند بهطور دلخواه بسیاری از شاردها را پشتیبانی کند که هر کدام خطمشی در دسترس بودن دادههای خاص خود را دارند._
+
+- [بلاگ](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)
+- [مستندات](https://docs.zksync.io/zk-stack/concepts/data-availability)
+- [وب سایت](https://zksync.io/)
+
+## بیشتر بخوانید {#further-reading}
+
+- [شماره Validium And The Layer 2 Two-By-Two — 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two)
+- [ZK-rollupها در مقابل ولیدیوم](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)
+- [اراده و طیف در دسترس بودن دادههای در حال ترکیب](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb)
+- [رول آپها، ولیدیومها و اراده ها: درباره داغترین راه حلهای مقیاس پذیری اتریوم بیاموزید](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions)
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md"
new file mode 100644
index 00000000000..806f8004636
--- /dev/null
+++ "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md"
@@ -0,0 +1,259 @@
+---
+title: رولآپهای دانش-صفر
+description: مقدمه ای بر رولآپ های دانش-صفر، یک راه حل مقیاس پذیری که توسط جامعه اتریوم استفاده میشود.
+lang: fa
+---
+
+رولآپ های دانش-صفر (ZK-rollups)، [راهحلهای مقیاسپذیری](/developers/docs/scaling/) لایه دوم هستند که با جابجایی محاسبات و حالت ذخیرهسازی به خارج از زنجیره اتریوم، توان عملیاتی را در شبکه اصلی اتریوم افزایش میدهند. رولآپ های دانش-صفر میتوانند هزاران تراکنش را به صورت دستهای پردازش کنند و سپس تنها خلاصهای فشرده از دادهها را به شبکه اصلی اتریوم ارسال کنند. این خلاصهی فشرده دادهها، تغییراتی را که باید در حالت اتریوم شکل بگیرد و چند اثبات رمزنگاری که درست بودن آن تغییرات را ثابت میکند، تعریف میکند.
+
+## موارد مورد نیاز {#prerequisites}
+
+شما باید صفحه ما را در [مقیاسسازی اتریوم](/developers/docs/scaling/) و [لایه 2](/layer-2) خوانده و درک کرده باشید.
+
+## رولآپ دانش-صفر چیست؟ {#what-are-zk-rollups}
+
+**رولآپ های دانش-صفر (ZK-rollups)**، دسته های تراکنشهایی (یا همان رولآپهایی) را که خارج از زنجیره اجرا میشوند را یک دسته میکنند. محاسبات خارج از زنجیره، مقدار دادهای که باید به بلاک چین ارسال شود را کاهش میدهد. اپراتورهای رولآپ های دانش-صفر، خلاصهای را از تغییرات مورد نیاز برای نمایش تمام تراکنشها در یک دسته را به جای ارسال هر تراکنش به صورت جداگانه، میفرستند. آنها همچنین [اثبات اعتبار](/glossary/#validity-proof) را برای اثبات درستی تغییرات خود تولید می کنند.
+
+حالت رولآپ دانش-صفر توسط یک قرارداد هوشمند مستقر در شبکه اتریوم ذخیره و مدیریت می شود. برای بهروزرسانی این حالت، گرههای رولآپ دانش-صفر باید یک اثبات ادعا را برای تأیید ارسال کنند. همانطور که ذکر شد، اثبات ادعا یک تضمین رمزنگاری میباشد که اطمینان میدهد تغییر حالت پیشنهادی توسط رولآپ واقعاً نتیجه اجرای همان دسته از تراکنشهای مربوطه است. این بدان معناست که رولآپ های دانش-صفر به جای پست کردن تمام دادههای تراکنش در زنجیره مانند [رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)، تنها به ارائه اثبات ادعا برای نهایی کردن تراکنشها در اتریوم نیاز دارند.
+
+هیچ تاخیری در انتقال وجوه از رولآپ دانش-صفر به اتریوم وجود ندارد، زیرا تراکنش های خروج پس از تائید اعتبار اثبات ادعا توسط قرارداد رولآپ دانش-صفر، انجام می شوند. اما در عوض، برداشت وجوه از رولآپ های خوشبینانه با تأخیر احتمالی همراه است تا هر کسی بتواند تراکنش خروج را با [اثبات تقلب](/glossary/#fraud-proof) به چالش بکشد.
+
+رولآپ های دانش-صفر تراکنش ها را در قالب `calldata` به اتریوم می نویسند. `calldata` محلی است که دادههایی که با فراخوانهای خارجی به توابع قرارداد هوشمند همراه هستند، ذخیره میشوند. اطلاعات موجود در `calldata` در بلاکچین منتشر میشود و به هر کسی اجازه میدهد تا حالت رولآپ را بهطور مستقل بازسازی کند. رولآپ های دانش-صفر از تکنیکهای فشردهسازی برای کاهش دادههای تراکنش استفاده میکنند - برای مثال، حسابها به جای یک آدرس، با یک ایندکس نشان داده میشوند که مصرف ۲۸ بایت داده را کاهش میدهد. انتشار دادهها برو روی شبکه اصلی، هزینه قابل توجهی را برای رولآپها دارد بنابراین فشردهسازی دادهها میتواند هزینهها را برای کاربران کاهش دهد.
+
+## رولآپ های دانش-صفر چگونه با اتریوم تعامل دارند؟ {#zk-rollups-and-ethereum}
+
+زنجیره رولآپ دانش-صفر، یک پروتکل خارج از زنجیره است که در لایه بالایی بلاکچین اتریوم عمل میکند و توسط قراردادهای هوشمند اتریوم روی زنجیره اصلی اتریوم مدیریت می شود. رولآپ های دانش-صفر، تراکنشها را خارج از شبکه اصلی اجرا میکنند، اما بهطور دورهای دستههای تراکنشهای خارج از زنجیره را به یک قرارداد رولآپ مستقر در شبکه اصلی اتریوم متعهد میکنند. این ثبت تراکنش مانند بلاکچین اتریوم تغییر ناپذیر میباشد و زنجیره رولآپ دانش-صفر را تشکیل می دهد.
+
+هسته اصلی رولآپ دانش-صفر از اجزای زیر تشکیل شده است:
+
+1. **قراردادهای هوشمند مستقر در شبکه اتریوم**: همانطور که گفته شد، پروتکل رولآپ دانش-صفر توسط قراردادهای هوشمند در حال اجرا بر روی اتریوم کنترل می شود. این شامل قرارداد اصلی است که بلوکهای رولآپ را ذخیره میکند، سپردهها را ردیابی میکند و بهروزرسانیهای حالت را نظارت میکند. یکی دیگر از قراردادهای مستقر در شبکه اتریوم (قرارداد تأیید کننده) ادعاهای دانش صفر ارائه شده توسط تولیدکنندگان بلوک را تائید می کند. بنابراین، اتریوم به عنوان لایه پایه یا "لایه اول" برای رولآپ دانش-صفر عمل می کند.
+
+2. **ماشین مجازی خارج از زنجیره (VM)**: گرچه که پروتکل رولآپ دانش-صفر در اتریوم در حال اجراست، اجرای تراکنش و ذخیرهسازی حالت در یک ماشین مجازی جداگانه مستقل از [ EVM](/developers/docs/evm/) انجام میشود. این ماشین مجازی یا VM خارج از زنجیره، محیط اجرا برای تراکنشهای رولآپ دانش-صفر است و به عنوان لایه ثانویه یا "لایه دوم" برای پروتکل رولآپ دانش-صفر عمل میکند. اثبات ادعاهایی که در شبکه اتریوم تائید شدهاند، درست بودن انتقال حالت را در ماشین مجازی خارج از زنجیره تضمین می کند.
+
+رولآپ های دانش-صفر "راهحلهای مقیاسپذیری ترکیبی" هستند - پروتکلهای خارج از زنجیره که به طور مستقل عمل میکنند اما امنیت را از اتریوم میگیرند. به خصوص شبکه اتریوم اعتبار بهروزرسانیهای حالت را در رولآپ دانش-صفر اعمال میکند و در دسترس بودن دادهها در حالت رولآپ را پس از هر بهروزرسانی، تضمین میکند. در نتیجه، رولآپ های دانش-صفر بهطور قابلتوجهی امنتر از راهحلهای مقیاسپذیری کاملاً خارج از زنجیره هستند، مانند [زنجیرههای جانبی](/developers/docs/scaling/sidechains/)، که خودشان مسئول ویژگیهای امنیتی خودشان هستند، یا [ولیدیومها](/developers/docs/scaling/validium/) که همچنین تأیید میکنند تراکنشهای روی اتریوم با اثبات ادعاها انجام میشود، اما دادههای تراکنش در جای دیگری ذخیره میشوند.
+
+رولآپ های دانش-صفر برای موارد زیر به پروتکل اصلی اتریوم متکی هستند:
+
+### دسترسی به دادهها {#data-availability}
+
+رولآپ دانش-صفر، دادههای حالت را برای هر تراکنش پردازش شده خارج از زنجیره به اتریوم منتشر میکنند. با این دادهها، افراد یا کسبوکارها میتوانند حالت رولآپ را بازتولید نمایند و خودشان زنجیره را تائید کنند. اتریوم این داده ها را در قالب `calldata` در اختیار همه استفاده کنندگان و شرکت کنندگان شبکه قرار می دهد.
+
+رولآپ های دانش-صفر نیازی به انتشار دادههای تراکنش زیادی روی زنجیره اصلی ندارند، زیرا اثباتهای ادعا قبلاً صحت انتقال حالت را تأیید کرده اند. با این وجود، ذخیره دادهها در زنجیره اصلی اتریوم همچنان مهم است زیرا امکان تائید بدون اجازه و مستقل وضعیت زنجیره لایه دوم را میدهد که به نوبه خود به هر کسی اجازه میدهد دستهای از تراکنشها را ارسال کند و از سانسور یا مسدود کردن زنجیره توسط اپراتورهای بد اندیش جلوگیری میکند.
+
+تعامل کاربران بر روی شبکه اصلی با رولآپ الزامی است. کاربران بدون دسترسی به دادههای ایالتی نمیتوانند موجودی حساب خود را درخواست کنند یا تراکنشهایی (مانند برداشتها) را که به اطلاعات حالت متکی هستند، آغاز کنند.
+
+### نهائی شدن تراکنش {#transaction-finality}
+
+اتریوم به عنوان یک لایه توافق برای رولآپ های دانش-صفر عمل می کند: تراکنش های لایه 2 تنها در صورتی نهایی می شوند که قرارداد لایه 2، اثبات ادعا را بپذیرد. این کار خطر دستکاری کردن زنجیره توسط اپراتورهای مخرب (به عنوان مثال، سرقت وجوه موجود در رولآپ) را از بین میبرد زیرا هر تراکنش باید در شبکه اصلی اتریوم تائید شود. همچنین، اتریوم تضمین میکند که پس از نهائی شدن در لایه اصلی، عملیات انجام شده توسط کاربر، نمیتواند معکوس شود.
+
+### مقاومت در برابر سانسور {#censorship-resistance}
+
+اکثر رولآپ های دانش-صفر از یک "ابر گره" (اپراتور) برای اجرای تراکنش ها، تولید دسته ها و ارسال بلوکها به لایه اصلی اتریوم استفاده میکنند. در حالی که این امر کارائی را تضمین میکند، اما خطر سانسور را افزایش میدهد: اپراتورهای مخرب رولآپ دانش-صفر میتوانند با امتناع از گنجاندن تراکنشهای کاربران در دسته تراکنشها، آنها را سانسور کنند.
+
+به عنوان یک ملاحظه امنیتی، رولآپ دانش-صفر به کاربران این امکان را میدهد که اگر فکر میکنند تراکنشها توسط اپراتور سانسور میشوند، خودشان مستقیماً آن را به قرارداد رولآپ در شبکه اتریوم ارسال نمایند. این به کاربران اجازه میدهد بدون اتکا به اجازه اپراتور، از رولآپ دانش-صفر به اتریوم خارج شوند.
+
+## طرز کار رولآپ دانش-صفر چگونه است؟ {#how-do-zk-rollups-work}
+
+### تراکنشها {#transactions}
+
+کاربران در رولآپ دانش-صفر تراکنش ها را امضا می کنند و برای پردازش و گنجاندن در دسته ارسالی بعدی به اپراتورهای لایه دوم میفرستند. در برخی موارد، اپراتور یک نهاد متمرکز به نام ترتیبدهنده است که تراکنشها را اجرا میکند، آنها را در دسته تراکنشها گردآوری میکند و به لایه اصلی ارسال میکند. ترتیبدهنده در این سیستم تنها نهادی است که مجاز به تولید بلوکهای لایه دوم و افزودن تراکنشهای رولآپ به قرارداد هوشمند رولآپ دانش-صفر است.
+
+سایر رولآپ های دانش-صفر ممکن است نقش اپراتور را با استفاده از مجموعه اطلاعات اعتبارسنجی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) با یکدیگر تعویض کنند. اپراتورهای احتمالی وجوهی را به قرارداد رولآپ واریز میکنند که اندازه هر سهم در شانس انتخاب شدن سهامداران برای تولید دسته بعدی تأثیر میگذارد. اگر اپراتور بدخواهانه عمل کند، میتوان سهام اپراتور را بعنوان جریمه، قاچ کرد یا اصطلاحاً slashing کرد، که این امر آنها را تشویق میکند تا بلوکهای معتبر را ارسال کنند.
+
+#### نحوه انتشار دادههای تراکنش در اتریوم توسط رولآپ های دانش-صفر {#how-zk-rollups-publish-transaction-data-on-ethereum}
+
+همانطور که توضیح داده شد، دادههای تراکنش در اتریوم به شکل `calldata` منتشر می شوند. `calldata` محلی در یک قرارداد هوشمند است که برای ارسال پارامترهای ورودی به یک تابع استفاده میشود و رفتاری مشابه با [حافظه مموری](/developers/docs/smart-contracts/anatomy/#memory) دارد. در حالی که `calldata` بهعنوان بخشی از حالت اتریوم ذخیره نمیشود، در زنجیره اتریوم به عنوان بخشی از [گزارشهای تاریخچه](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) زنجیره اتریوم باقی خواهد ماند. `calldata` بر حالت اتریوم تأثیری نمیگذارد و آن را به راهی ارزان برای ذخیره دادهها در شبکه اتریوم تبدیل میکند.
+
+کلمه کلیدی `calldata` معمولاً تابعی از قرارداد هوشمند را که توسط یک تراکنش فراخوانی میشود، شناسایی میکند و ورودیهای تابع را در قالب یک دنباله دلخواه از بایتها نگه میدارد و به آن وارد میکند. رولآپ دانش-صفر از `calldata` برای انتشار دادههای فشرده تراکنش، در زنجیره استفاده میکنند. اپراتور رولآپ به سادگی با فراخوانی تابع مورد نیاز در قرارداد رولآپ یک دسته جدید اضافه میکند و دادههای فشرده شده را به عنوان پارامترهای ورودی تابع ارسال میکند. این به کاهش هزینهها برای کاربران کمک میکند، زیرا بخش بزرگی از هزینههای رولآپ صرف ذخیره دادههای تراکنش در شبکه اتریوم میشود.
+
+### ثبت تعهد حالت {#state-commitments}
+
+حالت رولآپ دانش-صفر که شامل حسابها و موجودیهای لایه دوم میشود، در قالب [درخت مرکل](/whitepaper/#merkle-trees) نمایش داده میشود. یک هش رمزنگاری از ریشه درخت مرکل (ریشه مرکل) در قرارداد مستقر در زنجیره اتریوم ذخیره میشود و به پروتکل رولآپ اجازه میدهد تا تغییرات در حالت رولآپ دانش-صفر را ردیابی کند.
+
+پس از اجرای مجموعهای از تراکنشهای جدید، رولآپ به حالت جدید تغییر خواهد کرد. اپراتوری که تغییر حالت را آغاز کرده است باید یک ریشه حالت جدید را محاسبه کرده و به قرارداد مستقر در زنجیره اتریوم ارسال کند. اگر اثبات ادعا مرتبط با دسته توسط قرارداد تأیید کننده، تأیید شود، ریشه مرکل جدید به ریشه کانونی حالت رولآپ دانش-صفر تبدیل می شود.
+
+علاوه بر محاسبه ریشه های حالت، اپراتور رولآپ دانش-صفر همچنین یک ریشه دسته ایجاد می کند - یک ریشه مرکل که شامل تمام تراکنشهای داخل یک دسته است. وقتی که یک دسته جدید ارسال می شود، قرارداد رولآپ ریشه دسته را ذخیره می کند و به کاربران امکان می دهد ثابت کنند که یک تراکنش (به عنوان مثال، درخواست برداشت) در دسته گنجانده شده است. کاربران باید جزئیات تراکنش، ریشهی دسته و یک [اثبات مرکل](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) را ارائه کنند که مسیر محلی که در آنجا شامل شدهاند را نشان می دهد.
+
+### اثباتهای ادعا {#validity-proofs}
+
+ریشه حالت جدیدی که اپراتور رولآپ دانش-صفر به قرارداد زنجیره اصلی اتریوم ارائه میکند، نتیجه بهروز شدن حالت رولآپ است. فرض کنید آلیس 10 توکن برای باب می فرستد، اپراتور به سادگی موجودی آلیس را به مقدار 10 واحد کاهش می دهد و موجودی باب را به مقدار 10 واحد افزایش می دهد. اپراتور سپس دادههای حساب بهروز شده را هش میکند، درخت مرکل مجموعه را بازسازی میکند و ریشه مرکل جدید را به قرارداد روی زنجیره ارسال میکند.
+
+اما تا زمانی که اپراتور ثابت نکند که ریشه مرکل جدید از بهروزرسانیهای صحیح حالت رولآپ منشأ گرفته است، قرارداد رولآپ بهطور خودکار تعهد حالت پیشنهادی را نخواهد پذیرفت. اپراتور رولآپ دانش-صفر، این کار را با ارائه یک اثبات یا گواهی ادعا، که یک تعهد رمزنگاری مختصر است که صحت تراکنشهای دستهای را تأیید میکند، انجام میدهد.
+
+گواهی ادعا به طرفین اجازه می دهد تا صحت یک گزاره را بدون افشای خود گزاره اثبات کنند - از این رو، آنها را اثبات های دانش صفر نیز مینامند. رولآپ های دانش-صفر از گواهی ادعا برای تائید صحت انتقال حالت های رخ داده خارج از زنجیره، بدون نیاز به اجرای مجدد تراکنشها در اتریوم استفاده میکنند. این گواهیها میتوانند در قالب [ZK-SNARK (اسنارک دانش-صفر)](https://arxiv.org/abs/2202.06877) (معادل حروف اول استدلال غیر تعاملی مختصر دانش صفر به انگلیسی) یا [استارک دانش-صفر یا ZK-STARK](https://eprint.iacr.org/2018/046) (معادل حروف ابتدای استدلال شفاف مقیاسپذیر دانش صفر به انگلیسی) باشند.
+
+هم SNARKها و هم STARKها به اثبات یکپارچگی محاسبات خارج از زنجیره در رولآپ های دانش-صفر کمک می کنند، اگرچه که هر نوع گواهی، ویژگی های متمایزی با نوع دیگر گواهی دارد.
+
+**اسنارکهای دانش-صفر**
+
+برای کارکرد پروتکل ZK-SNARK یا همان اسنارکهای دانش-صفر، ایجاد یک رشته مرجع مشترک (CRS) ضروری است: CRS پارامترهای عمومی را برای اثبات و تأیید گواهی ادعا ارائه می کند. امنیت سیستم اثبات بستگی به تنظیمات و ساختار CRS دارد. اگر اطلاعات مورد استفاده برای ایجاد پارامترهای عمومی در اختیار عوامل مخرب قرار گیرد، ممکن است بتوانند گواهیهای ادعا نادرست تولید کنند.
+
+برخی از رولآپ های دانش-صفر سعی میکنند این مشکل را با استفاده از [مراسم محاسباتی چند حزبی (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) که شامل افراد مورد اعتماد، برای تولید پارامترهای عمومی برای مدار ZK-SNARK میشود، حل کنند. هر یک از طرفین مقداری تصادفی (به نام "ضایعات سمی") در ساخت CRS مشارکت می دهند که باید فوراً آن را از بین ببرند.
+
+به این دلیل از افراد مورد اعتماد و تنظیمات مطمئن استفاده می شود چون امنیت ساختار CRS را افزایش می دهند. تا زمانی که فقط یک دست اندرکار صادق و مورد اعتماد، ورودی خود را از بین ببرد، امنیت سیستم ZK-SNARK تضمین می شود. اما همچنان این رویکرد مستلزم اعتماد به دست اندرکاران برای حذف تصادفی نمونه آنها و عدم تضعیف تضمینهای امنیتی سیستم است.
+
+مفروضات اعتماد به کنار، اسنارکهای دانش-صفر به دلیل اندازههای اثبات کوچک و تأیید در بازه زمانی ثابت بدون درنظر گرفتن اندازه ورودیها، دارای محبوبیت زیادی هستند. از آنجایی که اثبات ادعا در زنجیره اصلی بیشتر هزینهها را برای اجرای یک اسنارکهای دانش-صفر تشکیل می دهد، لایه دو ها از اسنارکها برای تولید اثباتهایی استفاده می کنند که می توانند به سرعت و ارزان در شبکه اصلی اتریوم تائید شوند.
+
+**استارکهای دانش-صفر**
+
+همانند اسنارکها (ZK-SNARKs)، استارکها (ZK-STARKs) نیز معتبر بودن محاسبات خارج از زنجیره را بدون آشکار کردن ورودی ها ثابت میکنند. با این وجود، استارکهای دانش-صفر به دلیل بهبود مقیاس پذیری و شفافیتی که ارائه میدهند، به عنوان پیشرفتی در اسنارکهای دانش-صفر در نظر گرفته میشوند.
+
+استارکهای دانش-صفر، "شفاف" هستند، زیرا میتوانند بدون تنظیمات قابل اعتماد یک رشته مرجع مشترک (CRS) کار کنند. در عوض، این استارکها به ارقام تصادفی قابل تائید توسط عموم، جهت تنظیم پارامترهایی که برای تولید و تأیید ادعا هستند، متکی میباشند.
+
+استارکهای دانش-صفر همچنین مقیاس پذیری بیشتری را ارائه می دهند، زیرا زمان مورد نیاز برای محاسبات پشت پرده مربوط به تائید و اثبات گواهیهای ادعا، به طور _شبه خطی_ افزایش می یابد. در اسنارکهای دانش-صفر (ZK-SNARKها)، زمان مورد نیاز برای محاسبات پشت پرده اثبات و راستیآزمایی گواهی ادعابه صورت _خطی_ افزایش مییابد. این بدان معناست که ZK-STARKها نسبت به ZK-SNARKها، به زمان کمتری برای اثبات و تائید مجموعه دادههای بزرگ نیاز دارند، و آنها را به گزینهی مناسبی برای برنامههای با حجم بالا تبدیل میکند.
+
+همچنین استارکهای دانش-صفر یا همان ZK-STARKها، در برابر رایانههای کوانتومی امنتر هستند، در حالی که اعتقاد بر این است که رمزنگاری منحنی بیضی (ECC) که در ZK-SNARKها استفاده میشود، مستعد حملات محاسباتی کوانتومی میباشد. نقطه ضعف ZK-STARKها این است که اندازه های اثبات بزرگ تری تولید می کنند که تأیید آن در اتریوم پرهزینهتر است.
+
+#### گواهیهای اثبات ادعا چگونه در رولآپهای دانش-صفر عمل میکنند؟ {#validity-proofs-in-zk-rollups}
+
+##### ساخت گواهی
+
+قبل از پذیرش تراکنشها، اپراتور بررسی های معمول را انجام می دهد. این شامل تائید موارد زیر است:
+
+- حسابهای فرستنده و گیرنده بخشی از درخت مرکل حالت هستند.
+- فرستنده دارای وجوه کافی برای پردازش تراکنش است.
+- تراکنش صحیح است و با کلید عمومی فرستنده در رولآپ مطابقت دارد.
+- Nonce (عدد یکبار مصرف تراکنش) فرستنده صحیح است و غیره.
+
+به محض این که گره رولآپ دانش-صفر تراکنشهای کافی داشته باشد، آنها را در یک دسته گردآوری میکند و ورودی ها را برای مدار اثبات کامپایل میکند تا در یک گواهی دانش-صفر مختصر کامپایل شود. این شامل:
+
+- یک ریشه درخت مرکل که شامل تمام تراکنشهای دسته است.
+- اثباتهای مرکل برای تراکنشها، جهت اثبات مشمولیت آنها در دسته تراکنشها.
+- گواهیهای مرکل برای هر جفت فرستنده و گیرنده در تراکنشها جهت اثبات این که حساب آنها بخشی از درخت حالت رولآپ میباشد.
+- مجموعهای از ریشههای حالت میانی، که از بهروزرسانی ریشه حالت پس از اعمال بهروزرسانیهای حالت برای هر تراکنش (یعنی کاهش موجودی حساب فرستنده و افزایش موجودی حساب گیرنده) به دست میآید.
+
+مدار اثبات ادعا، گواهی اعتبار ادعا را با "اجرای متوالی" یا همان عمل looping بر روی هر تراکنش و انجام همان بررسیهایی که اپراتور، قبل از پردازش تراکنش آنها انجام داده است، محاسبه می کند. ابتدا با استفاده از اثبات مرکل ارائه شده، تائید میکند که حساب فرستنده بخشی از ریشه حالت موجود است. سپس موجودی فرستنده را کاهش میدهد، nonce آن را افزایش میدهد، دادههای بهروز شده حساب را هش میکند و آن را با اثبات مرکل ترکیب میکند تا یک ریشه مرکل جدید ایجاد کند.
+
+این ریشه مرکل تنها تغییرات در حالت رولآپ دانش-صفر را منعکس میکند: یعنی تغییر در موجودی فرستنده و nonce. این امر امکانپذیر میباشد چون که اثبات مرکلی که برای اثبات وجود حساب استفاده می شود، برای استخراج ریشه حالت جدید نیز استفاده میشود.
+
+مدار اثبات ادعا همان فرآیند را بر حساب گیرنده انجام میدهد. مدار اثبات ادعا بررسی میکند که آیا حساب گیرنده تحت ریشه حالت میانی (با استفاده از گواهی اثبات مرکل) وجود دارد یا خیر، موجودی آنها را افزایش میدهد، دادههای حساب را دوباره هش میکند و آنها را با گواهی اثبات مرکل ترکیب میکند تا یک ریشه حالت جدید ایجاد نماید.
+
+این پروسه برای هر تراکنش تکرار میشود. اجرای هر "حلقه" یا loop، یک ریشه حالت جدید از بهروز رسانی حساب فرستنده و یک ریشه جدید متوالی از بهروز رسانی حساب گیرنده ایجاد میکند. همان گونه که توضیح داده شد، هر بهروز رسانی در ریشه حالت، نشان دهنده بخشی از تغییرات حالت درخت رولآپ است.
+
+مدار اثبات ZK در کل دسته تراکنش تکرار میشود و دنباله بهروزرسانیهایی را تأیید میکند که منجر به یک ریشه حالت نهایی پس از اجرای آخرین تراکنش میشود. آخرین ریشه مرکل محاسبه شده جدیدترین ریشه حالت متعارف ZK-rollup می شود.
+
+##### تایید اثبات
+
+پس از اینکه مدار اثبات صحت بهروزرسانیهای حالت را تأیید کرد، اپراتور L2 اثبات اعتبار محاسبهشده را به قرارداد تأییدکننده در L1 ارسال میکند. مدار تأیید قرارداد اعتبار اثبات را تأیید می کند و همچنین ورودی های عمومی را که بخشی از اثبات است بررسی می کند:
+
+- **ریشه Pre-state**: ریشه حالت قدیمی ZK-rollup (یعنی قبل از اجرای تراکنشهای دستهای) که آخرین وضعیت معتبر شناخته شده زنجیره L2 را منعکس میکند.
+
+- **ریشه پس از وضعیت**: ریشه وضعیت جدید ZK-rollup (یعنی پس از اجرای تراکنشهای دستهای) که منعکسکننده جدیدترین حالت زنجیره L2 است. ریشه post-state ریشه نهایی است که پس از اعمال به روز رسانی های حالت در مدار اثبات به دست می آید.
+
+- **ریشه دسته ای**: ریشه مرکل دسته، که از تراکنش های _مرکلایزینگ_ در دسته و هش کردن ریشه درخت به دست می آید.
+
+- **ورودی های تراکنش**: داده های مرتبط با تراکنش های انجام شده به عنوان بخشی از دسته ارسال شده.
+
+اگر اثبات مدار را برآورده کند (یعنی معتبر است)، به این معنی است که دنبالهای از تراکنشهای معتبر وجود دارد که جمعبندی را از حالت قبلی (از لحاظ رمزنگاری توسط ریشه پیشحالت اثرانگشت) به حالت جدید (از لحاظ رمزنگاری توسط ریشه پس از حالت اثرانگشت) انتقال میدهد. اگر ریشه pre-state با ریشه ذخیره شده در قرارداد رولآپ مطابقت داشته باشد و اثبات معتبر باشد، قرارداد رولآپ ریشه post-state را از اثبات میگیرد و درخت حالت آن را بهروزرسانی میکند تا حالت تغییر یافته رولآپ را منعکس کند.
+
+### ورودی ها و خروجی ها {#entries-and-exits}
+
+کاربران با سپرده گذاری توکن ها در قرارداد رولآپ در زنجیره L1 وارد ZK-rollup می شوند. این تراکنش در صف قرار می گیرد زیرا فقط اپراتورها می توانند تراکنش ها را به قرارداد رولآپ ارسال کنند.
+
+اگر صف سپرده معلق شروع به پر شدن کند، اپراتور ZK-rollup تراکنش های سپرده را می گیرد و آنها را به قرارداد رولآپ ارسال می کند. هنگامی که وجوه کاربر در رول آپ قرار گرفت، می تواند با ارسال تراکنش ها به اپراتور برای پردازش، تراکنش را آغاز کند. کاربران میتوانند با هش کردن دادههای حساب خود، ارسال هش به قرارداد رولآپ، و ارائه یک گواهی اثبات مرکل برای تأیید در برابر ریشه حالت فعلی، موجودیهای رولآپ را تائید کنند.
+
+برداشت کردن داراییها از رولآپ دانش-صفر به شبکه اصلی ساده است. کاربر تراکنش خروج را با ارسال داراییهای خود با رولآپ به یک حساب مشخص برای سوزاندن داراییها آغاز میکند. اگر اپراتور تراکنش را در دسته بعدی که میفرستد قرار دهد، کاربر میتواند درخواست برداشت را به قرارداد روی زنجیره اصلی ارسال کند. این درخواست برداشت شامل موارد زیر خواهد بود:
+
+- اثبات مرکل اثبات میکند که تراکنش کاربر به حساب سوختن در یک دسته تراکنش وجود دارد
+
+- دادههای تراکنش
+
+- ریشه دسته تراکنشها
+
+- آدرس شبکه اصلی یا L1 برای دریافت وجوه واریزی
+
+قرارداد رولآپ دادههای تراکنش را هش میکند، بررسی میکند که آیا ریشه دسته تراکنشها وجود دارد یا خیر، و از اثبات مرکل برای بررسی اینکه آیا هش تراکنش بخشی از ریشه دسته تراکنشها است، استفاده میکند. پس از آن، قرارداد، تراکنش خروج را اجرا میکند و وجوه را به آدرس انتخابی کاربر در L1 ارسال میکند.
+
+## سازگاری رولآپ های دانش-صفر و EVM {#zk-rollups-and-evm-compatibility}
+
+برخلاف رولآپ های خوشبینانه، رولآپ های دانش-صفر به راحتی با [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) سازگار نیستند. اثبات محاسبات همه منظوره EVM در مدارها از اثبات محاسبات ساده (مانند انتقال توکن که قبلاً توضیح داده شد) دشوارتر و با مصرف منابع بیشتر همراه است.
+
+با این حال، [پیشرفتها در فنآوری دانش-صفر](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) در حال برانگیختن علاقهمندی مجدد به قرار دادن محاسبات EVM در اثباتهای دانش-صفر است. این تلاشها برای ایجاد یک پیادهسازی از EVM دانش-صفر (zkEVM) است که میتواند صحت اجرای برنامه را بهطور مؤثر تائید کند. یک zkEVM کدهای EVM موجود را برای اثبات/تائید در مدارها بازسازی میکند و امکان اجرای قراردادهای هوشمند را فراهم میکند.
+
+همانند EVM، یک zkEVM پس از محاسبه بر روی برخی از ورودیها، بین حالتها انتقال مییابد. تفاوت این است که zkEVM برای تأیید صحت هر مرحله از اجرای برنامه، گواهی اثبات دانش-صفر ایجاد میکند. اثبات گواهی اعتبار میتواند صحت عملیاتی را که حالت ماشین مجازی (حافظه، استک، ذخیرهسازی) و خود محاسبات را لمس میکنند تائید کند (یعنی آیا عملیات کدهای عملیاتی مناسب را فراخوانی کرده و آنها را به درستی اجرا کرده است؟).
+
+انتظار میرود که معرفی رولآپ های دانش-صفر سازگار با EVM به توسعهدهندگان کمک کند تا از مقیاسپذیری و تضمینهای امنیتی گواهیهای اثبات دانش-صفر استفاده کنند. مهمتر از آن، سازگاری با زیرساختهای بومی اتریوم به این معنی است که توسعهدهندگان میتوانند با استفاده از ابزارها و زبانهای آشنا (و آزمایششده در برابر هک و باگ) dappهای سازگار با دانش-صفر بسازند.
+
+## کارمزد رولآپ های دانش-صفر چگونه است؟ {#how-do-zk-rollup-fees-work}
+
+میزان پرداختی که کاربران برای تراکنشهای روی رولآپ های دانش-صفر پرداخت میکنند، دقیقاً مانند شبکه اصلی اتریوم، به کارمزد گاز بستگی دارد. با این حال، هزینه های گاز در لایه دو ها متفاوت عمل میکند و تحت تأثیر هزینههای زیر میباشد:
+
+1. **بازنویسی حالت**: برای نوشتن در حالت اتریوم هزینه ثابتی وجود دارد (یعنی ارسال تراکنش در بلاک چین اتریوم). رولآپ های دانش-صفر این هزینه را با دستهبندی تراکنشها و توزیع هزینههای ثابت بین چندین کاربر کاهش میدهند.
+
+2. **انتشار دادهها**: رولآپ های دانش-صفر دادههای حالت هر تراکنش را به عنوان `calldata` در اتریوم منتشر میکنند. هزینههای `calldata` در حال حاضر توسط [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) کنترل میشود که به ترتیب هزینه 16 گاز را برای بایتهای غیر صفر و 4 گاز را برای بایتهای صفر موجود در `calldata` را تعیین میکند. هزینه پرداخت شده برای هر تراکنش به حجم `calldata` ارسالی در زنجیره اصلی، بستگی دارد.
+
+3. **کارمزدهای اپراتور L2**: این مبلغی است که به عنوان جبران هزینههای محاسباتی انجام شده در پردازش تراکنشها، به اپراتور رولآپ پرداخت میشود، خیلی شبیه به ["هزینههای اولویت (پاداشها)" تراکنش](/developers/docs/gas/#how-are-gas-fees-calculated) در شبکه اصلی اتریوم.
+
+4. **تولید گواهی اثبات و تائید آن**: اپراتورهای رولآپ دانش-صفر، باید برای دستههای تراکنش اثبات ادعا ارائه کنند که نیازمند منابع زیادی است. همچنین، تأیید گواهیهای دانش-صفر در شبکه اصلی اتریوم گاز (حدود 500,000 واحد گاز) مصرف میکند.
+
+جدا از دسته کردن تراکنشها، رولآپ های دانش-صفر با فشردهسازی دادههای تراکنش، هزینهها را برای کاربران کاهش میدهند. میتوانید [نمای کلی به روز](https://l2fees.info/) از هزینههای استفاده از رولآپ دانش-صفر اتریوم را ببینید.
+
+## رولآپ دانش-صفر چگونه اتریوم را مقیاسپذیر می کنند؟ {#scaling-ethereum-with-zk-rollups}
+
+### فشردهسازی دادههای تراکنش {#transaction-data-compression}
+
+رولآپ های دانش-صفر با استفاده از محاسبات خارج از زنجیره، توان عملیاتی و تعداد دادههای ورودی لایه پایه اتریوم را افزایش میدهند، اما تقویت واقعی مقیاسپذیری از فشردهسازی داده های تراکنش حاصل میشود. [اندازه بلوک](/developers/docs/blocks/#block-size) اتریوم دادههایی را که هر بلوک میتواند نگه دارد و در نتیجه تعداد تراکنشهای پردازش شده در هر بلوک را محدود میکند. با فشردهسازی داده های مربوط به تراکنش، رولآپ های دانش-صفر به طور قابل توجهی تعداد تراکنش های پردازش شده در هر بلوک را افزایش میدهند.
+
+رولآپ های دانش-صفر میتوانند دادههای تراکنش را بهتر از رولآپ های خوشبینانه فشرده کنند، زیرا نیازی به ارسال تمام دادههای مورد نیاز برای اعتبارسنجی هر تراکنش ندارند. آنها فقط باید حداقل داده های مورد نیاز برای بازسازی آخرین حالت حسابها و موجودیها را در رولآپ ارسال نمایند.
+
+### اثبات های بازگشتی {#recursive-proofs}
+
+مزیت اثباتهای دانش-صفر این است که گواهیها میتوانند گواهیهای دیگر را تأیید کنند. به عنوان مثال، یک ZK-SNARK میتواند یک ZK-SNARK دیگر را تأیید کند. چنین گواهیهای بازگشتی را "اثباتِ اثبات" مینامند و به طور چشمگیری توان عملیاتی را در رولآپ های دانش-صفر افزایش میدهند.
+
+در حال حاضر، گواهیهای اعتبار به صورت بلوک به بلوک تولید میشوند و برای تائید به قرارداد مستقر بر اتریوم ارسال میشوند. با این حال، تأیید گواهیهای تک بلوکی، توان عملیاتی که رولآپ های دانش-صفر میتوانند به دست آورند را محدود میکند، زیرا زمانی که اپراتور یک گواهی را ارائه و ثبت میکند، تنها یک بلوک نهایی میشود.
+
+در عوض، گواهیهای بازگشتی، نهایی کردن چندین بلوک را با یک گواهی اعتبار امکانپذیر میکنند. این به این دلیل است که مدار اثبات به صورت بازگشتی چندین گواهی بلوک را دستچین میکند تا زمانی که یک اثبات نهایی ایجاد شود. اپراتور لایه دو این گواهی بازگشتی را ارسال میکند و در صورت پذیرش توسط قرارداد، تمام بلوک های مربوطه بلافاصله نهایی میشوند. با گواهیهای بازگشتی، تعداد تراکنشهای رولآپ دانش-صفر که میتوانند در اتریوم در فواصل زمانی مشخص نهایی شوند، افزایش مییابند.
+
+### مزایا و معایب رولآپ دانش-صفر {#zk-rollups-pros-and-cons}
+
+| مزایا | معایب |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| گواهی اثبات اعتبار صحت تراکنشهای خارج از زنجیره را تضمین میکند و از اجرای انتقال حالت نامعتبر توسط اپراتورها جلوگیری میکند. | هزینه مربوط به محاسبات و تأیید اثبات اعتبار قابل توجه است و می تواند هزینهها را برای کاربران رولآپ افزایش دهد. |
+| نهایی شدن تراکنش سریعتر را ارائه میدهد، زیرا به محض تأیید اعتبار گواهی در شبکه اصلی اتریوم، بهروزرسانیهای حالت تأیید میشوند. | ایجاد رولآپ های دانش-صفر سازگار با EVM به دلیل پیچیدگی فناوری دانش-صفر دشوار است. |
+| برای امنیت به مکانیسمهای رمزنگاری بدون نیاز به اعتماد متکی است، نه صداقت مشارکتکنندگانی که ذینفع هستند مثل [رول آپهای خوشبینانه](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | تولید گواهی اثبات اعتبار نیاز به سختافزار تخصصی دارد که ممکن است مشوقی برای کنترل متمرکز زنجیره توسط چند نهاد باشد. |
+| داده های مورد نیاز برای بازیابی حالت خارج از زنجیره را در L1 ذخیره می کند، که امنیت، مقاومت در برابر سانسور و عدم تمرکز را تضمین میکند. | اپراتورهای متمرکز (sequencer یا ترتیبدهنده ها) میتوانند بر ترتیب تراکنشها تأثیر بگذارند. |
+| کاربران از بهرهوری بیشتر سرمایه بهره میبرند و میتوانند بدون تاخیر وجوه را از L2 برداشت نمایند. | الزامات سختافزاری ممکن است تعداد شرکتکنندگان زنجیره را کاهش دهد که میتواند زنجیره را مجبور به تغییر کند و خطر مسدود کردن حالت رولآپ توسط اپراتورهای مخرب و سانسور کاربران را افزایش میدهد. |
+| به فرضیات در حال اجرا بودن بستگی ندارد و کاربران مجبور نیستند زنجیره را برای محافظت از سرمایه خود تأیید کنند. | برخی از سیستمهای اثباتکننده (مانند ZK-SNARK) به تنظیمات قابل اعتماد نیاز دارند که در صورت عدم مدیریت صحیح، به طور بالقوه میتواند مدل امنیتی رولآپ دانش-صفر را به خطر بیندازد. |
+| فشردهسازی بهتر دادهها میتواند به کاهش هزینههای انتشار `calldata` در اتریوم و به حداقل رساندن هزینههای رولآپ برای کاربران کمک کند. | |
+
+### توضیح تصویری از رولآپ های دانش-صفر {#zk-video}
+
+ببینید Finematics چگونه درباره رولآپ دانش-صفر توضیح میدهد:
+
+
+
+### استفاده از رولآپ های دانش-صفر {#use-zk-rollups}
+
+پیاده سازی های متعددی از رولآپ های دانش-صفر وجود دارد که میتوانید آنها را در dappهای خود ادغام کنید:
+
+
+
+## چه کسی روی zkEVM کار میکند؟ {#zkevm-projects}
+
+پروژه هایی که روی zkEVM کار می کنند عبارتند از:
+
+- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM پروژهای است که توسط بنیاد اتریوم برای توسعه یک رولآپ دانش-صفر سازگار با EVM و مکانیزمی برای تولید گواهی اثبات اعتبار برای بلوکهای اتریوم، بنیانگذاری شد._
+
+- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _یک رولآپ غیرمتمرکز دانش-صفر در شبکه اصلی اتریوم است که بر روی یک ماشین مجازی اتریوم با دانش صفر (zkEVM) کار می کند که تراکنش های اتریوم را به روشی شفاف اجرا می کند، از جمله قراردادهای هوشمند با اعتبارسنجی دانش-صفر._
+
+- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll یک شرکت مبتنی بر فناوری است که بر روی ساخت یک راه حل بومی zkEVM Layer 2 برای اتریوم کار میکند._
+
+- **[Taiko](https://taiko.xyz)** - _Taiko یک رولآپ دانش-صفر غیرمتمرکز و معادل اتریوم است (یک [ZK-EVM نوع 1](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._
+
+- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era یک رولآپ دانش-صفر سازگار با EVM است که توسط Matter Labs ساخته شده است و با استفاده از zkEVM خودش اجرا میشود._
+
+- **[Starknet](https://starkware.co/starknet/)** - _StarkNet یک راه حل مقیاس پذیری لایه 2 سازگار با EVM است که توسط StarkWare ساخته شده است._
+
+- **[Morph](https://www.morphl2.io/)** - _Morph یک راهحل مقیاسپذیری ترکیبی است که از گواهی دانش-صفر برای رسیدگی به مشکل چالش حالت لایه 2 استفاده میکند._
+
+## خواندنیهای بیشتر در مورد رولآپ های دانش-صفر {#further-reading-on-zk-rollups}
+
+- [رولآپ دانش-صفر چیست؟](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups)
+- [رولآپ دانش-صفر چیست؟](https://alchemy.com/blog/zero-knowledge-rollups)
+- [STARKها در مقابل SNARKها](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)
+- [ZkEVM چیست؟](https://www.alchemy.com/overviews/zkevm)
+- [انواع ZK-EVM: معادل اتریوم، معادل ماشین مجازی اتریوم، نوع 1، نوع 4، و دیگر واژههای مرموز](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4)
+- [معرفی zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt)
+- [منابع عالی zkEVM](https://github.com/LuozhuZhang/awesome-zkevm)
+- [پشت صحنه ZK-SNARKS](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html)
+- [SNARK چگونه ممکن است؟](https://vitalik.eth.limo/general/2021/01/26/snarks.html)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md
new file mode 100644
index 00000000000..1dbed4fd9f1
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md
@@ -0,0 +1,32 @@
+---
+title: ساختار دادهها و رمزگذاری
+description: مروری بر ساختارهای داده بنیادی اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+اتریوم حجم زیادی از داده ها را ایجاد، ذخیره و انتقال می دهد. این دادهها باید به روشهای استاندارد شده و با حافظه کارآمد قالببندی شوند تا به هر کسی اجازه دهد روی سختافزار نسبتاً درجه متوسط مصرفکننده [گرهی را اجرا کند](/run-a-node/). برای رسیدن به این هدف، چندین ساختار داده خاص در پشته اتریوم استفاده می شود.
+
+## پیشنیازها {#prerequisites}
+
+شما باید با اصول اتریوم و [نرم افزار کاربر](/developers/docs/nodes-and-clients/) آشنا باشید. آشنایی با لایه شبکه و [وایت پیپر اتریوم](/whitepaper/) توصیه می شود.
+
+## ساختارهای داده {#data-structures}
+
+### درخت مرکل پاتریشیا {#patricia-merkle-tries}
+
+درخت های مرکل پاتریشیا ساختارهایی هستند که جفتهای مقدار کلید را در یک آزمون قطعی و رمزنگاری تأیید شده رمزگذاری میکنند. این ها به طور گسترده در لایه اجرایی اتریوم استفاده می شوند.
+
+[جزئیات بیشتر درباره درخت های مرکل پاتریشیا](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
+
+### پیشوند طول بازگشتی {#recursive-length-prefix}
+
+پیشوند طول بازگشتی (RLP) یک روش سریال سازی است که به طور گسترده در لایه اجرایی اتریوم استفاده می شود.
+
+[جزئیات بیشتر درباره RLP](/developers/docs/data-structures-and-encoding/rlp)
+
+### سریال سازی ساده {#simple-serialize}
+
+سریال سازی ساده (SSZ)، به دلیل سازگاری آن با مرکلیزاسیون، فرمت سریال سازی غالب در لایه اجماع اتریوم است.
+
+[جزئیات بیشتر درباره SSZ](/developers/docs/data-structures-and-encoding/ssz)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
new file mode 100644
index 00000000000..ea7754e1a20
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
@@ -0,0 +1,323 @@
+---
+title: درخت مرکل پاتریشیا
+description: مقدمه ای بر درخت مرکل پاتریشیا.
+lang: fa
+sidebarDepth: 2
+---
+
+حالت اتریوم (مجموع همه حسابها، موجودیها و قراردادهای هوشمند)، در نسخه خاصی از ساختار دادهها که عموماً در علوم کامپیوتر به عنوان درخت مرکل شناخته میشود، کدگذاری میشود. این ساختار برای بسیاری از برنامههای کاربردی در رمزنگاری مفید است، زیرا یک رابطه قابل تأیید بین تمام تکههای دادههای درهمتنیده در درخت ایجاد میکند، که منجر به یک مقدار **ریشه** میشود که میتواند برای اثبات چیزهایی در مورد دادهها استفاده شود.
+
+ساختار دادههای اتریوم یک «درخت مرکل-پاتریشیا اصلاحشده» است که به این دلیل نامگذاری شده است که برخی از ویژگیهای PATRICIA (الگوریتم عملی برای بازیابی اطلاعات کدگذاریشده به صورت الفبایی) را به عاریت گرفته و به این دلیل که برای باز**آزمایش**داده های کارآمد مواردی که حالت اتریوم را تشکیل می دهند طراحی شده است.
+
+درخت مرکل-پاتریشیا متغیر قطعی و از نظر رمزنگاری قابل تأیید است: تنها راه برای تولید ریشه حالت، محاسبه آن از تک تک تکه های حالت است، و دو حالت یکسان را می توان به راحتی با مقایسه هش ریشه و هش هایی که منجر به آن شدهاند ثابت کرد (_اثبات مرکل_). برعکس، هیچ راهی برای ایجاد دو حالت مختلف با هش ریشه یکسان وجود ندارد، و هر تلاشی برای تغییر حالت با مقادیر مختلف منجر به یک هش ریشه متفاوت خواهد شد. از نظر تئوری، این ساختار «جام مقدس» کارایی `O(log(n))` را برای درجها، جستجوها و حذفها فراهم میکند.
+
+در آینده نزدیک، اتریوم قصد دارد به ساختار [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees) مهاجرت کند، که بسیاری از فرصتهای جدید را برای بهبود پروتکلهای آینده باز خواهد کرد.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای درک بهتر این صفحه، داشتن دانش اولیه در مورد [هش](https://en.wikipedia.org/wiki/Hash_function)، [درخت مرکل](https://en.wikipedia.org/wiki/Merkle_tree)، [درخت ها](https://en.wikipedia.org/wiki/Trie) و
+سریال سازی3 مفید خواهد بود. >. این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
+
+
+
+## درختهای پایه رادیکس {#basic-radix-tries}
+
+در یک درخت پایه رادیکس، هر گره به صورت زیر به نظر می رسد:
+
+
+
+```
+ [i_0, i_1 ... i_n, value]
+```
+
+
+در حالی که `i_0 ... i_n` نمادهای الفبا (اغلب باینری یا هگزا) را نشان می دهد، `مقدار` مقدار پایانی در گره است و مقادیر در ` i_0، i_1 ... i_n` اسلاتها یا `NULL` یا اشارهگر به (در مورد ما، هشهای) گرههای دیگر هستند. این یک ذخیره پایه `(کلید، مقدار)` را تشکیل می دهد.
+
+فرض کنید میخواهید از یک ساختار داده درخت رادیکس برای تداوم سفارش روی مجموعهای از جفتهای مقدار کلیدی استفاده کنید. برای یافتن مقداری که در حال حاضر به کلید `dog` در درخت نگاشت شده است، ابتدا `dog` را به حروف الفبا تبدیل کنید (به `64 6f 67` بدهید) و سپس سعی کنید در درخت پایین بیایید تا مقدار را پیدا کنید. یعنی با جستجوی هش ریشه در یک DB کلید/مقدار مسطح برای یافتن گره ریشه درخت شروع میکنید. این امر، به صورت آرایه ای از کلیدها نشان داده می شود که به گره های دیگر اشاره می کنند. میتوانید از مقدار شاخص `6` به عنوان کلید استفاده کنید و آن را در کلید/مقدار مسطح DB جستجو کنید تا گره را یک سطح پایین بیاورید. سپس index `4` را برای جستجوی مقدار بعدی انتخاب کنید، سپس شاخص `6` را انتخاب کنید و به همین ترتیب، تا زمانی که مسیر را دنبال کردید: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`، شما مقدار گره را جستجو می کنید و نتیجه را نشان میدهید.
+
+بین جستجوی چیزی در "درخت" و کلید/مقدار مسطح زیرین "DB" تفاوت وجود دارد. هر دو ترتیبات کلید/مقدار را تعریف می کنند، اما DB زیربنایی می تواند یک جستجوی سنتی یک مرحله ای از یک کلید را انجام دهد. جستجوی یک کلید در درخت نیاز به جستجوهای متعدد DB زیربنایی برای رسیدن به مقدار نهایی شرح داده شده در بالا دارد. اجازه دهید به دومی به عنوان `مسیر` برای رفع ابهام اشاره کنیم.
+
+عملیات به روز رسانی و حذف برای درختهای radix را می توان به صورت زیر تعریف کرد:
+
+
+
+```
+ def update(node,path,value):
+ curnode = db.get(node) if node else [ NULL ] * 17
+ newnode = curnode.copy()
+ if path == '':
+ newnode[-1] = value
+ else:
+ newindex = update(curnode[path[0]],path[1:],value)
+ newnode[path[0]] = newindex
+ db.put(hash(newnode),newnode)
+ return hash(newnode)
+
+ def delete(node,path):
+ if node is NULL:
+ return NULL
+ else:
+ curnode = db.get(node)
+ newnode = curnode.copy()
+ if path == '':
+ newnode[-1] = NULL
+ else:
+ newindex = delete(curnode[path[0]],path[1:])
+ newnode[path[0]] = newindex
+
+ if all(x is NULL for x in newnode):
+ return NULL
+ else:
+ db.put(hash(newnode),newnode)
+ return hash(newnode)
+```
+
+
+درخت ریشه «مرکل» با پیوند دادن گرهها با استفاده از هش رمزنگاری ایجاد شده قطعی ساخته میشود. این آدرس دهی محتوا (در کلید/مقدار DB `key == keccak256(rlp(مقدار))`) تضمین یکپارچگی رمزنگاری داده های ذخیره شده را فراهم می کند. اگر هش ریشه یک درخت داده شده به طور عمومی شناخته شده باشد، هرکسی که به دادههای برگ زیرین دسترسی داشته باشد، میتواند با ارائه هشهای هر گره که مقدار خاصی را به ریشه درخت میپیوندد، اثبات کند که سعی میکند یک مقدار معین را در یک مسیر خاص اضافه میکند.
+
+برای یک مهاجم غیرممکن است که اثباتی برای یک جفت `(مسیر، مقدار)` ارائه دهد که وجود ندارد، زیرا هش ریشه در نهایت بر اساس همه هش های زیر آن است. هر گونه تغییر اساسی، هش ریشه را تغییر می دهد. میتوانید هش را بهعنوان نمایش فشردهای از اطلاعات ساختاری در مورد دادهها در نظر بگیرید، که با محافظت پیشتصویر تابع درهمسازی ایمن شده است.
+
+ما به یک واحد اتمی یک درخت ریشه (مثلاً یک کاراکتر هگز یا عدد باینری 4 بیتی) به عنوان "نیبل" اشاره خواهیم کرد. همانطور که در بالا توضیح داده شد، در حین پیمودن یک مسیر یک نوبت، گرهها میتوانند حداکثر به 16 فرزند اشاره داشته باشند اما یک عنصر `مقدار` را شامل میشوند. بنابراین ما آنها را به صورت آرایه ای به طول 17 نشان می دهیم. ما این آرایه های 17 عنصری را "گره های شاخه ای" می نامیم.
+
+
+
+## درخت مرکل پاتریشیا {#merkle-patricia-trees}
+
+درختهای رادیکس یک محدودیت عمده دارند: ناکارآمد هستند. اگر می خواهید یک پیوند `(مسیر، مقدار)` را در جایی که مسیر، مانند اتریوم، 64 کاراکتر طول دارد (تعداد nibble ها در `bytes32`) ذخیره کنید، به بیش از یک کیلوبایت فضای اضافی برای ذخیره یک سطح در هر کاراکتر نیاز خواهیم داشت، و هر جستجو یا حذف 64 مرحله کامل طول خواهد کشید. درخت پاتریشیا معرفی شده در ادامه این مشکل را حل می کند.
+
+
+
+### بهينه سازی {#optimization}
+
+یک گره در درخت مرکل پاتریشیا یکی از موارد زیر است:
+
+1. `NULL` (به عنوان رشته خالی نمایش داده می شود)
+2. `شاخه` یک گره 17 موردی `[ v0 ... v15, vt ]`
+3. `برگ` یک گره 2 موردی `[ encodedPath، مقدار ]`
+4. `افزونه` یک گره 2 موردی `[ encodedPath, key ]`
+
+با 64 مسیر کاراکتر، اجتناب ناپذیر است که پس از عبور از چند لایه اول سعی کنید، به گره ای برسید که در آن مسیر واگرا حداقل برای بخشی از مسیر پایین وجود نداشته باشد. برای جلوگیری از ایجاد حداکثر 15 گره `NULL` پراکنده در طول مسیر، با راهاندازی یک گره `افزونه` به شکل `[ encodedPath, key ] مسیر فرود را میانبر میکنیم`، جایی که `encodedPath` حاوی "مسیر جزئی" برای رد شدن از پیش است (با استفاده از یک رمزگذاری فشرده که در زیر توضیح داده شده است)، و `کلید` برای جستجوی DB بعدی است.
+
+برای یک گره `برگ`، که میتوان آن را با یک پرچم در اولین نیبل `encodedPath` علامتگذاری کرد، مسیر تمام قطعات مسیر گره قبلی را رمزگذاری می کند و ما می توانیم `مقدار` را مستقیماً جستجو کنیم.
+
+با این حال، این بهینهسازی بالا باعث ایجاد ابهام میشود.
+
+هنگام پیمایش مسیرها در نیبل، ممکن است در نهایت با تعداد فرد نیبل برای پیمایش مواجه شویم، اما به این دلیل که همه داده ها در قالب `بایت` ذخیره می شوند. نمی توان بین، به عنوان مثال، nibble `1` و nibbles `01` تفاوت قائل شد (هر دو باید به عنوان `<01>` ذخیره شوند). برای تعیین طول فرد، مسیر جزئی با یک پرچم پیشوند داده می شود.
+
+
+
+### مشخصات: رمزگذاری فشرده دنباله هگزا با پایان دهنده اختیاری {#specification}
+
+علامت گذاری _طول مسیر جزئی باقیمانده فرد در مقابل زوج_ و _گره برگ در مقابل پسوند_ همانطور که در بالا توضیح داده شد در اولین نوک مسیر جزئی هر گره 2 موردی قرار دارد. آنها به موارد زیر منجر می شوند:
+
+ hex char bits | node type partial path length
+ ----------------------------------------------------------
+ 0 0000 | extension even
+ 1 0001 | extension odd
+ 2 0010 | terminating (leaf) even
+ 3 0011 | terminating (leaf) odd
+
+
+حتی برای طول مسیر باقیمانده (`0` یا `2`)، یک نوک `0` "padding" دیگر همیشه در پی میآید.
+
+
+
+```
+ def compact_encode(hexarray):
+ term = 1 if hexarray[-1] == 16 else 0
+ if term: hexarray = hexarray[:-1]
+ oddlen = len(hexarray) % 2
+ flags = 2 * term + oddlen
+ if oddlen:
+ hexarray = [flags] + hexarray
+ else:
+ hexarray = [flags] + [0] + hexarray
+ // hexarray now has an even length whose first nibble is the flags.
+ o = ''
+ for i in range(0,len(hexarray),2):
+ o += chr(16 * hexarray[i] + hexarray[i+1])
+ return o
+```
+
+
+مثال ها:
+
+
+
+```
+ > [ 1, 2, 3, 4, 5, ...]
+ '11 23 45'
+ > [ 0, 1, 2, 3, 4, 5, ...]
+ '00 01 23 45'
+ > [ 0, f, 1, c, b, 8, 10]
+ '20 0f 1c b8'
+ > [ f, 1, c, b, 8, 10]
+ '3f 1c b8'
+```
+
+
+در اینجا کد توسعه یافته برای گرفتن یک گره در درخت مرکل پاتریشیا آمده است:
+
+
+
+```
+ def get_helper(node,path):
+ if path == []: return node
+ if node = '': return ''
+ curnode = rlp.decode(node if len(node) < 32 else db.get(node))
+ if len(curnode) == 2:
+ (k2, v2) = curnode
+ k2 = compact_decode(k2)
+ if k2 == path[:len(k2)]:
+ return get(v2, path[len(k2):])
+ else:
+ return ''
+ elif len(curnode) == 17:
+ return get_helper(curnode[path[0]],path[1:])
+
+ def get(node,path):
+ path2 = []
+ for i in range(len(path)):
+ path2.push(int(ord(path[i]) / 16))
+ path2.push(ord(path[i]) % 16)
+ path2.push(16)
+ return get_helper(node,path2)
+```
+
+
+
+
+### درخت نمونه {#example-trie}
+
+فرض کنید ما درختی می خواهیم حاوی چهار جفت مسیر/مقدار `('do', 'verb')`, `('dog', 'puppy')`, `(' doge، «coins»)`، `(«horse»، «stallion»)`.
+
+ابتدا، هم مسیرها و هم مقادیر را به `بایت` تبدیل می کنیم. در زیر، نمایشهای واقعی بایت برای _مسیرها_ با > نشان داده میشوند، اگرچه _مقادیر_ که برای درک آسان تر همچنان به صورت رشتهها`` نشان داده میشوند (آنها نیز در واقع `بایت` خواهند بود):
+
+
+
+```
+ <64 6f> : 'verb'
+ <64 6f 67> : 'puppy'
+ <64 6f 67 65> : 'coins'
+ <68 6f 72 73 65> : 'stallion'
+```
+
+
+اکنون، ما چنین درختی را با جفتهای کلید/مقدار زیر در DB زیرین میسازیم:
+
+
+
+```
+ rootHash: [ <16>, hashA ]
+ hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
+ hashB: [ <00 6f>, hashC ]
+ hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
+ hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
+```
+
+
+هنگامی که یک گره در داخل گره دیگری ارجاع داده می شود، آنچه شامل می شود `H(rlp.encode(node))` است، که در آن `H(x) = keccak256(x) اگر len(x) > = 32 else x` و `rlp.encode` تابع رمزگذاری [RLP](/developers/docs/data-structures-and-encoding/rlp) است.
+
+توجه داشته باشید که هنگام بهروزرسانی یک درخت، باید جفت کلید/مقدار `(keccak256(x)، x)` را در یک جدول جستجوی دائمی ذخیره کنید _اگر_ گره تازه ایجاد شده دارای طول >= 32 باشد. با این حال، اگر گره کوتاهتر از آن باشد، نیازی به ذخیره چیزی نیست، زیرا تابع f(x) = x قابل برگشت است.
+
+
+
+## درخت ها در اتریوم {#tries-in-ethereum}
+
+تمام درخت های مرکل در لایه اجرایی اتریوم از درخت مرکل پاتریشیا استفاده میکنند.
+
+از یک سر بلوک 3 ریشه از 3 مورد از این درخت ها وجود دارد.
+
+1. stateRoot
+2. transactionsRoot
+3. receiptsRoot
+
+
+
+### درخت حالت {#state-trie}
+
+یک درخت حالت جهانی وجود دارد و هر بار که کلاینت یک بلوک را پردازش می کند، به روز می شود. در آن، یک `مسیر` همیشه: `keccak256(ethereumAddress)` و یک `مقدار` همیشه: `rlp(ethereumAccount)` است. به طور خاص، `حساب` اتریوم یک آرایه 4 موردی از `[nonce,balance,storageRoot,codeHash]` است. در این مرحله، شایان ذکر است که این `storageRoot` ریشه یکی دیگر از درخت های پاتریشیا است:
+
+
+
+### درخت حافظه {#storage-trie}
+
+درخت Storage جایی است که _همه_ دادههای قرارداد زندگی میکنند. برای هر حساب یک فضای ذخیره سازی جداگانه وجود دارد. برای بازیابی مقادیر در موقعیتهای ذخیرهسازی خاص در یک آدرس معین، آدرس ذخیره، موقعیت عدد صحیح دادههای ذخیرهشده در حافظه و شناسه بلوک مورد نیاز است. سپس میتوان آنها را بهعنوان آرگومان به `eth_getStorageAt` تعریفشده در JSON-RPC API ارسال کرد، بهعنوان مثال: برای بازیابی داده ها در اسلات ذخیره سازی 0 برای آدرس `0x295a70b2de5e3953354a6a8344e616ed314d7251`:
+
+
+
+```
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
+
+{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
+
+```
+
+
+بازیابی عناصر دیگر در ذخیره سازی کمی بیشتر دخیل است زیرا ابتدا باید موقعیت در درخت حافظه محاسبه شود. موقعیت به عنوان هش `keccak256` آدرس و موقعیت ذخیره سازی محاسبه می شود که هر دو در سمت چپ با صفر تا طول 32 بایت اضافه شده اند. به عنوان مثال، موقعیت داده در شکاف ذخیره سازی 1 برای آدرس `0x391694e7e0b0cce554cb130d723a9d27458f9298` است:
+
+
+
+```
+keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))
+```
+
+
+در یک کنسول Geth، این می تواند به صورت زیر محاسبه شود:
+
+
+
+```
+> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
+undefined
+> web3.sha3(key, {"encoding": "hex"})
+"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
+```
+
+
+بنابراین `مسیر` `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` است. اکنون می توان از آن برای بازیابی داده ها از درخت حافظه مانند قبل استفاده کرد:
+
+
+
+```
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
+
+{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
+```
+
+
+توجه: `storageRoot` برای یک حساب اتریوم اگر یک حساب قراردادی نباشد به طور پیشفرض خالی است.
+
+
+
+### درخت تراکنشها {#transaction-trie}
+
+برای هر بلوک یک تراکنش جداگانه وجود دارد که دوباره جفتهای `(کلید، مقدار)` را ذخیره میکند. یک مسیر در اینجا عبارت است از: `rlp(transactionIndex)` که نشان دهنده کلیدی است که با مقدار تعیین شده از سوی این مطابقت دارد:
+
+
+
+```
+if legacyTx:
+ value = rlp(tx)
+else:
+ value = TxType | encode(tx)
+```
+
+
+اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
+
+
+
+### درخت رسیدها {#receipts-trie}
+
+هر بلوک درخت رسیدهای خود را دارد. یک `مسیر` در اینجا این است: `rlp(transactionIndex)`. `transactionIndex` شاخص آن در بلوکی است که در آن گنجانده شده است. درخت رسیدها هرگز به روز نمی شود. مشابه درخت تراکنشها، رسیدهای جاری و قدیمی وجود دارد. برای استعلام یک رسید خاص در درخت رسیدها، شاخص تراکنش در بلوک آن، بار رسید و نوع تراکنش مورد نیاز است. رسید برگشتی می تواند از نوع `رسیدی` باشد که به عنوان الحاق `TransactionType` و `ReceiptPayload` تعریف می شود یا می تواند از نوع `LegacyReceipt< باشد /0> که به صورت rlp([status, cumulativeGasUsed, logsBloom, logs])`. تعریف میشود.
+
+اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
+
+
+
+## اطلاعات بیشتر {#further-reading}
+
+- [درخت مرکل پاتریشیا اصلاح شده – چگونه اتریوم یک حالت را ذخیره می کند](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
+- [مرکلینگ در اتریوم](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
+- [فهمیدن درخت اتریوم](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md
new file mode 100644
index 00000000000..5909276a700
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md
@@ -0,0 +1,163 @@
+---
+title: سریال سازی پیشوند با طول بازگشتی (RLP)
+description: تعریف رمزگذاری rlp در لایه اجرایی اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+سریال سازی پیشوند طول بازگشتی (RLP) به طور گسترده در کلاینت های اجرایی اتریوم استفاده می شود. RLP انتقال داده ها بین گره ها را در یک فرمت فضا-کارا استاندارد می کند. هدف RLP کدگذاری آرایه های تو در تو دلخواه از داده های دوتایی است و RLP روش رمزگذاری اولیه است که برای سریال سازی اشیاء در لایه اجرای اتریوم استفاده می شود. هدف اصلی RLP کدگذاری ساختار است. به استثنای اعداد صحیح مثبت، RLP کدگذاری انواع داده های خاص (مانند رشته ها، شناورها) را به پروتکل های مرتبه بالاتر واگذار می کند. اعداد صحیح مثبت باید به شکل دوتایی با اندین بزرگ و بدون صفرهای ابتدایی نمایش داده شوند (بنابراین مقدار عدد صحیح صفر معادل آرایه بایت خالی می شود). اعداد صحیح مثبت غیر سریالی شده با صفرهای ابتدایی باید توسط هر پروتکل مرتبه بالاتر با استفاده از RLP نامعتبر تلقی شوند.
+
+اطلاعات بیشتر در [مقاله زرد اتریوم (پیوست B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19).
+
+برای استفاده از RLP برای رمزگذاری یک فرهنگ لغت، دو شکل متعارف پیشنهادی عبارتند از:
+
+- از `[[k1,v1],[k2,v2]...]` با کلیدها به ترتیب واژگان استفاده کنید
+- از رمزگذاری درخت پاتریشیا در سطح بالاتر مانند اتریوم استفاده کنید
+
+## تعریف {#definition}
+
+تابع رمزگذاری RLP یک آیتم را می گیرد. یک آیتم به صورت زیر تعریف می شود:
+
+- یک رشته (یعنی آرایه بایت) یک آیتم است
+- لیست اقلام، یک آیتم است
+- یک عدد صحیح مثبت یک آیتم است
+
+به عنوان مثال، همه موارد زیر عبارتند از:
+
+- یک رشته خالی؛
+- رشته حاوی کلمه "گربه"؛
+- لیستی حاوی هر تعداد رشته؛
+- و ساختارهای داده پیچیده تری مانند `["گربه"، ["توله سگ"، "گاو"]، "اسب"، [[]]، "خوک"، [""]، "گوسفند"]`.
+- عدد `100`
+
+توجه داشته باشید که در زمینه بقیه این صفحه، "رشته" به معنای "تعداد معینی از بایت داده های دوتایی" است. هیچ کدگذاری خاصی استفاده نمی شود، توجه داشته باشید که در زمینه بقیه این صفحه، "رشته" به معنای "تعداد معینی از بایت داده های دوتایی" است. هیچ کدگذاری خاصی استفاده نمی شود، و هیچ دانشی در مورد محتوای رشته ها وجود ندارد (به جز مواردی که توسط قانون در مورد اعداد صحیح مثبت غیر حداقلی لازم است).
+
+رمزگذاری RLP به صورت زیر تعریف می شود:
+
+- برای یک عدد صحیح مثبت، به کوتاهترین آرایه بایتی که تفسیر آن عدد صحیح است، تبدیل میشود و سپس طبق قوانین زیر به عنوان یک رشته کدگذاری میشود.
+- برای یک بایت که مقدار آن در محدوده `[0x00, 0x7f]` (اعشاری `[0, 127]`) است، آن بایت رمزگذاری RLP خودش است.
+- در غیر این صورت، اگر یک رشته 0-55 بایت طول داشته باشد، رمزگذاری RLP از یک بایت با مقدار **0x80** (اعشار 128) به اضافه طول رشته و به دنبال آن رشته تشکیل شده است. بنابراین، محدوده اولین بایت `[0x80, 0xb7]` است (dec. `[128, 183]`).
+- اگر یک رشته بیش از 55 بایت طول داشته باشد، رمزگذاری RLP شامل یک بایت منفرد با مقدار **0xb7** (اعشار 183) به اضافه طول بر حسب بایت طول رشته به صورت دوتایی است و به دنبال آن طول رشته و به دنبال آن رشته است. به عنوان مثال، یک رشته 1024 بایتی به صورت `\xb9\x04\x00` (dec. `185, 4, 0`) و به دنبال آن رشته رمزگذاری میشود. در اینجا، `0xb9` (183 + 2 = 185) به عنوان اولین بایت، به دنبال آن 2 بایت `0x0400` (اعشار 1024) که طول رشته واقعی را نشان می دهد. بنابراین، محدوده اولین بایت `[0xb8, 0xbf]` است (اعشار `[184، 191]`).
+- اگر یک رشته 2^64 بایت یا بیشتر باشد، ممکن است رمزگذاری نشود.
+- اگر مجموع بار یک لیست (یعنی طول ترکیبی همه موارد آن که با RLP کدگذاری شده اند) 0-55 بایت باشد، رمزگذاری RLP از یک بایت با مقدار **0xc0** به اضافه طول بار و به دنبال آن الحاق رمزگذاری های RLP اقلام تشکیل میشود. بنابراین، محدوده اولین بایت `[0xc0, 0xf7]` است (اعشار `[192, 247] `).
+- اگر حجم کل یک لیست بیش از 55 بایت باشد، رمزگذاری RLP شامل یک بایت منفرد با مقدار **0xf7** به اضافه طول بر حسب بایت طول بار به صورت دوتایی است و به دنبال آن طول بار، و به دنبال آن الحاق رمزگذاری های RLP اقلام است. بنابراین، محدوده اولین بایت `[0xf8, 0xff]` است (اعشار `[248, 255] `).
+
+در کد، این عبارت است از:
+
+```python
+def rlp_encode(input):
+ if isinstance(input,str):
+ if len(input) == 1 and ord(input) < 0x80:
+ return input
+ return encode_length(len(input), 0x80) + input
+ elif isinstance(input, list):
+ output = ''
+ for item in input:
+ output += rlp_encode(item)
+ return encode_length(len(output), 0xc0) + output
+
+def encode_length(L, offset):
+ if L < 56:
+ return chr(L + offset)
+ elif L < 256**8:
+ BL = to_binary(L)
+ return chr(len(BL) + offset + 55) + BL
+ raise Exception("input too long")
+
+def to_binary(x):
+ if x == 0:
+ return ''
+ return to_binary(int(x / 256)) + chr(x % 256)
+```
+
+## مثال ها {#examples}
+
+- the string "dog" = [ 0x83, 'd', 'o', 'g' ]
+- the list [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]`
+- the empty string ('null') = `[ 0x80 ]`
+- the empty list = `[ 0xc0 ]`
+- the integer 0 = `[ 0x80 ]`
+- the byte '\\x00' = `[ 0x00 ]`
+- the byte '\\x0f' = `[ 0x0f ]`
+- the bytes '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]`
+- [نمایش تئوری مجموعه](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) سه، `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
+- رشته "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]`
+
+## رمزگشایی RLP {#rlp-decoding}
+
+با توجه به قوانین و فرآیند رمزگذاری RLP، ورودی رمزگشایی RLP به عنوان آرایه ای از داده های دوتایی در نظر گرفته می شود. فرآیند رمزگشایی RLP به شرح زیر است:
+
+1. با توجه به اولین بایت (یعنی پیشوند) داده های ورودی و رمزگشایی نوع داده، طول داده واقعی و افست؛
+
+2. با توجه به نوع و افست داده، داده ها را به ترتیب رمزگشایی کنید، با رعایت حداقل قانون رمزگذاری برای اعداد صحیح مثبت.
+
+3. به رمزگشایی بقیه ورودی ادامه دهید؛
+
+در میان آنها، قوانین رمزگشایی انواع داده و افست به شرح زیر است:
+
+1. اگر محدوده اولین بایت (یعنی پیشوند) [0x00, 0x7f] باشد و رشته دقیقاً خود اولین بایت باشد، داده یک رشته است.
+
+2. اگر محدوده اولین بایت [0x80, 0xb7] باشد، و رشته ای که طول آن برابر با بایت اول منهای 0x80 است از بایت اول پیروی کند، داده یک رشته است؛
+
+3. اگر محدوده اولین بایت [0xb8, 0xbf] باشد، و طول رشته ای که طول آن بر حسب بایت برابر بایت اول منهای 0xb7 است از بایت اول پیروی می کند و رشته از طول رشته پیروی می کند، داده یک رشته است؛
+
+4. اگر محدوده اولین بایت [0xc0, 0xf7] باشد، و الحاق رمزگذاری های RLP همه آیتم های لیست که کل بار بار برابر با بایت اول منهای 0xc0 است، از بایت اول پیروی می کند، داده یک لیست است؛
+
+5. اگر محدوده اولین بایت [0xf8, 0xff] باشد، و کل محموله فهرستی که طول آن برابر با بایت اول منهای 0xf7 است، از اولین بایت پیروی می کند، و الحاق رمزگذاری های RLP همه آیتم های لیست از کل بار فهرست پیروی می کنند، داده یک لیست است؛
+
+در کد، این عبارت است از:
+
+```python
+def rlp_decode(input):
+ if len(input) == 0:
+ return
+ output = ''
+ (offset, dataLen, type) = decode_length(input)
+ if type is str:
+ output = instantiate_str(substr(input, offset, dataLen))
+ elif type is list:
+ output = instantiate_list(substr(input, offset, dataLen))
+ output += rlp_decode(substr(input, offset + dataLen))
+ return output
+
+def decode_length(input):
+ length = len(input)
+ if length == 0:
+ raise Exception("input is null")
+ prefix = ord(input[0])
+ if prefix <= 0x7f:
+ return (0, 1, str)
+ elif prefix <= 0xb7 and length > prefix - 0x80:
+ strLen = prefix - 0x80
+ return (1, strLen, str)
+ elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)):
+ lenOfStrLen = prefix - 0xb7
+ strLen = to_integer(substr(input, 1, lenOfStrLen))
+ return (1 + lenOfStrLen, strLen, str)
+ elif prefix <= 0xf7 and length > prefix - 0xc0:
+ listLen = prefix - 0xc0;
+ return (1, listLen, list)
+ elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)):
+ lenOfListLen = prefix - 0xf7
+ listLen = to_integer(substr(input, 1, lenOfListLen))
+ return (1 + lenOfListLen, listLen, list)
+ raise Exception("input does not conform to RLP encoding form")
+
+def to_integer(b):
+ length = len(b)
+ if length == 0:
+ raise Exception("input is null")
+ elif length == 1:
+ return ord(b[0])
+ return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256
+```
+
+## بیشتر بخوانید {#further-reading}
+
+- [RLP در اتریوم](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
+- [اتریوم زیر سقف: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
+- [Coglio, A. (2020). پیشوند طول مکرر اتریوم در ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769)
+
+## موضوعات مرتبط {#related-topics}
+
+- [درخت مرکل پاتریشیا](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md
new file mode 100644
index 00000000000..48bf26d8e19
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md
@@ -0,0 +1,149 @@
+---
+title: سریال سازی ساده
+description: توضیحی دربارهی فرمت SSZ اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+**سریال سازی ساده (SSZ)** روش سریال سازی مورد استفاده در زنجیره Beacon است. این سریال سازی، شیوه سریال سازی RLP مورد استفاده در لایه اجرایی در همه جای لایه اجماع، به جز پروتکل کشف همتا را جایگزین میکند. SSZ طوری طراحی شده است که قطعی باشد و همچنین به شکلی کارآمد به فرمت درخت مرکل تبدیل شود. SSZ را میتوان سیستمی در نظر گرفت که دو جزء دارد: یک طرح سریال سازی و یک طرح مرکلازیسیون (طرح مرکلازیسیون پروسه تبدیل اطلاعات به فرمت درخت مرکل را تعریف میکند) که برای افزایش کارآیی هنگام کار با ساختار دادههای سریالی (دنبالهدار) طراحی شده است.
+
+## SSZ چگونه کار میکند؟ {#how-does-ssz-work}
+
+### سریالی کردن {#serialization}
+
+SSZ یک طرح ایجاد دنباله است که خود توصیف نیست - بلکه بر طرحی تکیه دارد که باید از قبل شناخته شده باشد. هدف سریال سازی SSZ، نمایش اشیاء (objectها) با پیچیدگی دلخواه به صورت رشته هایی از بایت است. این یک فرآیند بسیار ساده برای "انواع پایه" است. عنصر به سادگی به بایت های هگزادسیمال تبدیل می شود. انواع پایه عبارتند از:
+
+- اعداد صحیح بدون علامت
+- بولین ها
+
+برای انواع پیچیده "کامپوزیت"، سریال سازی پیچیده تر است، زیرا نوع ترکیب حاوی عناصر متعددی است که ممکن است انواع مختلف یا اندازه های مختلف یا هر دو را داشته باشند. در جایی که این اشیاء همگی دارای طولهای ثابت هستند (یعنی اندازه عناصر بدون در نظر گرفتن مقادیر واقعی آنها همیشه ثابت است) سریالسازی صرفاً تبدیل هر عنصر در نوع ترکیبی است که به رشتههای بایت انددیایی کوچک مرتب شدهاند. این رشتههای بایت به هم پیوسته اند. شیء سریالسازیشده نمایش فهرست بایتی عناصر با طول ثابت را به همان ترتیبی که در شیء بیسریالشده ظاهر میشوند، دارد.
+
+برای انواع با طول های متغیر، داده های واقعی با یک مقدار "افست" در موقعیت آن عنصر در شی سریال شده جایگزین می شوند. داده های واقعی به پشته ای در انتهای شیء سریال شده اضافه می شود. مقدار افست شاخصی برای شروع داده های واقعی در پشته است که به عنوان یک اشاره گر به بایت های مربوطه عمل می کند.
+
+مثال زیر نحوه عملکرد آفستینگ برای ظرفی با عناصر دارای طول ثابت و متغیر را نشان می دهد:
+
+```Rust
+
+ struct Dummy {
+
+ number1: u64,
+ number2: u64,
+ vector: Vec,
+ number3: u64
+ }
+
+ dummy = Dummy{
+
+ number1: 37,
+ number2: 55,
+ vector: vec![1,2,3,4],
+ number3: 22,
+ }
+
+ serialized = ssz.serialize(dummy)
+
+```
+
+`serialized` ساختار زیر را خواهد داشت (در اینجا فقط به 4 بیت اضافه می شود، در واقعیت به 32 بیت اضافه می شود و نمایش `int` را برای وضوح حفظ می کند):
+
+```
+[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
+------------ ----------- ----------- ----------- ----------
+ | | | | |
+ number1 number2 offset for number 3 value for
+ vector vector
+
+```
+
+برای وضوح به خطوط تقسیم می شود:
+
+```
+[
+ 37, 0, 0, 0, # little-endian encoding of `number1`.
+ 55, 0, 0, 0, # little-endian encoding of `number2`.
+ 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16).
+ 22, 0, 0, 0, # little-endian encoding of `number3`.
+ 1, 2, 3, 4, # The actual values in `vector`.
+]
+```
+
+این هنوز یک سادهسازی است - اعداد صحیح و صفر در شماتیکهای بالا در واقع به عنوان بایتلیستها ذخیره میشوند، مانند این:
+
+```
+[
+ 10100101000000000000000000000000 # little-endian encoding of `number1`
+ 10110111000000000000000000000000 # little-endian encoding of `number2`.
+ 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16).
+ 10010110000000000000000000000000 # little-endian encoding of `number3`.
+ 10000001100000101000001110000100 # The actual value of the `bytes` field.
+]
+```
+
+بنابراین مقادیر واقعی برای انواع با طول متغیر در یک پشته در انتهای شیء سریالسازی شده با آفستهای آنها در موقعیتهای صحیح خود در فهرست مرتب شده فیلدها ذخیره میشوند.
+
+برخی موارد خاص نیز وجود دارند که نیاز به فرایند خاصی دارند، مانند نوع `BitList` که نیاز به اضافه کردن یک درپوش طول در حین سریالسازی و حذف در حین جداسازی دارد. جزئیات کامل در [مشخصات SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) موجود است.
+
+### غیرسریالی سازی {#deserialization}
+
+برای غیر سریالی کردن این شی به طرحواره نیاز است. این طرح، چیدمان دقیق دادههای سریالسازیشده را تعریف میکند، طوری که هر عنصر خاص را میتوان از یک لکه بایت به یک شی معنادار با عناصر دارای نوع، مقدار، اندازه و موقعیت مناسب غیرسریالی کرد. این طرح واره است که به غیرسریالی کننده می گوید که چه مقادیری مقادیر واقعی هستند و چه مقادیری افست هستند. همه نامهای فیلد زمانی که یک شی سریالی میشود، ناپدید میشوند، اما طبق طرحواره، پس از سریالسازی مجدداً نمونهسازی میشوند.
+
+برای توضیح تعاملی در این مورد به [ssz.dev](https://www.ssz.dev/overview) مراجعه کنید.
+
+## مرکلیزیشن {#merkleization}
+
+این شیء سریالی SSZ سپس می تواند مرکلیزه شود - که به یک نمایش درخت مرکل از همان داده ها تبدیل می شود. ابتدا تعداد تکه های 32 بایتی در شیء سریالی شده تعیین می شود. اینها "برگ"های درخت هستند. تعداد کل برگ ها باید توان 2 باشد تا هش کردن برگ ها با هم در نهایت یک ریشه درخت هش ایجاد کند. اگر به طور طبیعی اینطور نباشد، برگ های اضافی حاوی 32 بایت صفر اضافه می شود. به صورت نموداری:
+
+```
+ hash tree root
+ / \
+ / \
+ / \
+ / \
+ hash of leaves hash of leaves
+ 1 and 2 3 and 4
+ / \ / \
+ / \ / \
+ / \ / \
+ leaf1 leaf2 leaf3 leaf4
+```
+
+همچنین مواردی وجود دارد که برگ های درخت به طور طبیعی به روشی که در مثال بالا انجام می شود به طور یکنواخت توزیع نمی کنند. به عنوان مثال، برگ 4 می تواند ظرفی با عناصر متعدد باشد که نیاز به "عمق" اضافی برای افزودن به درخت مرکل دارد و یک درخت ناهموار ایجاد می کند.
+
+به جای ارجاع به این عناصر درختی به عنوان برگ X، گره X و غیره، میتوانیم به آنها شاخصهای تعمیمیافته بدهیم که با ریشه = 1 شروع میشود و در امتداد هر سطح از چپ به راست میشماریم. این شاخص کلی است که در بالا توضیح داده شد. هر عنصر در فهرست سریالسازی شده دارای یک شاخص تعمیمیافته برابر با `2**عمق + idx` است که در آن idx موقعیت صفر نمایهشده آن در شیء سریالسازیشده و عمق تعداد سطوح در درخت مرکل است، که می تواند به عنوان لگاریتم پایه دو تعداد عناصر (برگ) تعیین شود.
+
+## شاخص های تعمیم یافته {#generalized-indices}
+
+یک شاخص تعمیمیافته یک عدد صحیح است که نشاندهنده یک گره در درخت مرکل دوتایی است که در آن هر گره دارای یک شاخص تعمیمیافته `2 ** عمق + شاخص در ردیف` است.
+
+```
+ 1 --depth = 0 2**0 + 0 = 1
+ 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3
+ 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5...
+
+```
+
+این نمایش یک شاخص گره برای هر قطعه داده در درخت مرکل به دست می دهد.
+
+## اثبات چندگانه {#multiproofs}
+
+ارائه فهرستی از شاخصهای تعمیمیافته که یک عنصر خاص را نشان میدهد به ما امکان میدهد آن را نسبت به ریشه درخت هش تأیید کنیم. این ریشه نسخه پذیرفته شده ما از واقعیت است. هر داده ای که ما ارائه می کنیم را می توان با قرار دادن آن در مکان مناسب در درخت مرکل (که توسط شاخص تعمیم یافته آن تعیین می شود) و مشاهده ثابت ماندن ریشه در برابر آن واقعیت تأیید کرد. توابعی در مشخصات [اینجا](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) وجود دارد که نحوه محاسبه حداقل مجموعه گره های مورد نیاز برای تأیید محتویات یک مجموعه خاص از شاخص های تعمیم یافته را نشان می دهند.
+
+به عنوان مثال، برای تأیید داده های شاخص 9 در درخت زیر، به هش داده ها در شاخص های 8، 9، 5، 3، 1 نیاز داریم. هش (8،9) باید برابر با هش (4) باشد که با 5 هش می شود تا 2 تولید شود و هش با 3 برای تولید ریشه درخت 1 است. اگر دادههای نادرستی برای 9 ارائه شود، ریشه تغییر میکند - ما این را تشخیص میدهیم و نمیتوانیم شعبه را تأیید کنیم.
+
+```
+* = data required to generate proof
+
+ 1*
+ 2 3*
+ 4 5* 6 7
+8* 9* 10 11 12 13 14 15
+
+```
+
+## بیشتر بخوانید {#further-reading}
+
+- [ارتقا Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
+- [ارتقا Ethereum: مرکلیزاسیون](https://eth2book.info/altair/part2/building_blocks/merkleization)
+- [پیاده سازی SSZ](https://github.com/ethereum/consensus-specs/issues/2138)
+- [ماشین حساب SSZ](https://simpleserialize.com/)
+- [SSZ.dev](https://www.ssz.dev/)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
new file mode 100644
index 00000000000..d4eb95c6b09
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
@@ -0,0 +1,189 @@
+---
+title: تعریف ذخیره سازی مخفی Web3
+description: یک تعریف رسمی برای حافظه پنهان Web3
+lang: fa
+sidebarDepth: 2
+---
+
+برای اینکه اپلیکیشن شما بر روی اتریوم کار کند، میتوانید از آبجکت Web3 که توسط کتابخانه web3.js فراهم شده استفاده کنید. در پس زمینه، این کتابخانه از طریق فراخوانی RPC به یک نود محلی متصل میشود. این کتابخانه با هر نود اتریومی که لایه RPC داشته باشد کار میکند.
+
+`web3` شامل آبجکت `eth` میباشد-web3.eth
+
+```js
+var fs = require("fs")
+var recognizer = require("ethereum-keyfile-recognizer")
+
+fs.readFile("keyfile.json", (err, data) => {
+ var json = JSON.parse(data)
+ var result = recognizer(json)
+})
+
+/** result
+ * [ 'web3', 3 ] web3 (v3) keyfile
+ * [ 'ethersale', undefined ] Ethersale keyfile
+ * null invalid keyfile
+ */
+```
+
+این مستندات **ورژن سوم** تعریف حافظه پنهان Web3 میباشند.
+
+## تعریف {#definition}
+
+رمزگذاری و رمزگشایی فایل نسبت به ورژن اول تا حد زیادی تغییری نکرده است، جز این که الگوریتم رمزنگاری دیگر روی AES-128-CBC تثبیت نشده است (AES-128-CTR اکنون لازمه حداقل است). بیشتر معانی و الگوریتمها همانند ورژن اول هستند، به جز `mac`، که به عنوان SHA3 (keccak-256) از ترکیب دومین 16 بایت از چپ از کلید مشتقشده به همراه کل `ciphertext` تعریف میشود.
+
+فایلهای کلید مخفی مستقیما در `~/.web3/keystore` (برای سیستمهایی مانند Unix) و `~/AppData/Web3/keystore` (برای ویندوز) ذخیره میشوند. ممکن است هر چیزی نام گذاری شوند، اما بهترین نام گذاری میتواند `.json` باشد که `` یک UUIDی 128 بیتی است که به کلید مخفی داده میشود (یک پروکسی حفظ حریم خصوصی برای آدرس کلیدهای مخفی).
+
+همه این فایلها یک پسورد مربوط به خودشان را دارند. برای استخراج کلید مخفی یک فایل `.json`، ابتدا باید کلید رمزگذاری فایل را استخراج کرد. در واقع این کار از طریق دریافت پسورد فایلها و دادن آن پسورد به تابع استخراج همانطور که توسط کلید `kdf` تعریف شدهاست، انجام میشود. پارامترهای استاتیک و دینامیک وابسته به KDF برای تابع KDF در کلید `kdfparams` توضیح داده شده است.
+
+PBKDF2 باید توسط تمام پیادهسازیهای دارای حداقل سازگاری پشتیبانی شود، البته به این موارد اشاره شده است:
+
+- `kdf`: `pbkdf2`
+
+kdfparamها برای PBKDF2 عبارتند از:
+
+- `prf`: باید `hmac-sha256` باشد (ممکن است در آینده تمدید شود);
+- `c`: تعداد تکرارها؛
+- `سالت`: سالت به PBKDF منتقل می شود؛
+- `dklen`: طول کلید استخراج شده. باید >=32 باشد.
+
+هنگامی که کلید فایل استخراج شد، باید از طریق استخراج MAC تأیید شود. MAC باید به عنوان هش SHA3 (keccak-256) آرایه بایت محاسبه شود که به عنوان الحاقات 16 بایت دوم سمت چپ کلید استخراج شده با محتویات کلید `متن رمزی` تشکیل شده است، به عنوان مثال.:
+
+```js
+KECCAK(DK[16..31] ++ )
+```
+
+(که در آن `++` اپراتور الحاق است)
+
+این مقدار باید با محتویات کلید `mac` مقایسه شود. اگر متفاوت هستند، یک رمز عبور جایگزین باید درخواست شود (یا عملیات لغو شود).
+
+پس از تأیید کلید فایل، متن رمز (کلید `متن رمز` در فایل) ممکن است با استفاده از الگوریتم رمزگذاری متقارن مشخص شده توسط کلید `رمز` رمزگشایی شود و از طریق کلید `پارام رمز` پارامترگذاری شود. اگر اندازه کلید استخراج شده و اندازه کلید الگوریتم با هم مطابقت نداشته باشند، بایت های صفر و سمت راست کلید استخراج شده باید به عنوان کلید الگوریتم استفاده شوند.
+
+همه پیادهسازیهایی که حداقل مطابقت را دارند باید از الگوریتم AES-128-CTR پشتیبانی کنند که به این صورت مشخص میشود:
+
+- `cipher: aes-128-ctr`
+
+این رمز، پارامترهای زیر را می گیرد که به عنوان کلید برای کلید cipherparams داده می شود:
+
+- `iv`: بردار اولیه سازی 128 بیتی برای رمز.
+
+کلید رمز، 16 بایت سمت چپ کلید استخراج شده است، یعنی `DK[0..15]`
+
+ایجاد/رمزگذاری یک کلید مخفی باید اساساً برعکس این دستورالعملها باشد. مطمئن شوید که `uuid`، `salt` و `iv` واقعا تصادفی هستند.
+
+علاوه بر فیلد `نسخه`، که باید به عنوان یک شناسه "سخت" نسخه عمل کند، پیادهسازیها ممکن است از `minorversion` برای ردیابی تغییرات کوچکتر و بدون شکست در قالب استفاده کنند.
+
+## بردارهای تست {#test-vectors}
+
+جزئیات:
+
+- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
+- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
+- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6`
+- `Password`: `testpassword`
+- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
+
+### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
+
+آزمایش بردار با استفاده از `AES-128-CTR` و `PBKDF2-SHA-256`:
+
+محتوای فایل `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
+ },
+ "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
+ "kdf": "pbkdf2",
+ "kdfparams": {
+ "c": 262144,
+ "dklen": 32,
+ "prf": "hmac-sha256",
+ "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
+ },
+ "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**متوسط**:
+
+`Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5`
+
+### Scrypt {#scrypt}
+
+بردار آزمایشی با استفاده از AES-128-CTR و Scrypt:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "740770fce12ce862af21264dab25f1da"
+ },
+ "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
+ },
+ "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**متوسط**:
+
+`کلید استخراج شده`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c`
+
+## تغییرات از نسخه 1 {#alterations-from-v2}
+
+این نسخه چندین ناسازگاری را با نسخه 1 منتشر شده در [اینجا](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) برطرف می کند. آنها به طور خلاصه عبارتند از:
+
+- حروف بزرگ غیرقابل توجیه و متناقض است (حروف کوچک رمز، حروف مختلط Kdf، حروف بزرگ MAC).
+- به حریم خصوصی و ایرادات غیرضروری میپردازد.
+- `سالت` ذاتاً یک پارامتر تابع مشتق کلید است و شایسته آن است که با آن مرتبط شود، نه به طور کلی با رمزارز.
+- _SaltLen_ غیر ضروری است (فقط آن را از Salt استخراج کنید).
+- تابع استخراج کلید داده شده است، اما الگوریتم رمزنگاری به سختی مشخص شده است.
+- `نسخه` ذاتاً عددی است و در عین حال یک رشته است (نسخهسازی ساختاریافته با یک رشته امکانپذیر است، اما میتواند برای قالب فایل پیکربندی که به ندرت تغییر میکند، خارج از محدوده در نظر گرفته شود).
+- `KDF` و `رمز` به طور فکری مفاهيم خواهر و برادر هستند اما به طور متفاوت سازماندهي شده اند.
+- `MAC` از طریق یک قطعه داده آگنوستیک فضای خالی محاسبه می شود(!)
+
+برای ارائه فایل زیر، تغییراتی در قالب ایجاد شده است که از نظر عملکردی معادل مثال داده شده در صفحه پیوند قبلی است:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-cbc",
+ "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
+ "cipherparams": {
+ "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
+ },
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
+ },
+ "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
+ "version": 1
+ },
+ "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
+ "version": 2
+}
+```
+
+## تغییرات از نسخه 2 {#alterations-from-v2}
+
+نسخه 2 یک پیاده سازی اولیه ++C با تعدادی باگ بود. همه موارد ضروری بدون تغییر از آن باقی می مانند.
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md
new file mode 100644
index 00000000000..519af1b03ef
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md
@@ -0,0 +1,155 @@
+---
+title: لایهی شبکه
+description: مقدمه ای بر لایه شبکه اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+اتریوم یک شبکه همتا به همتا با هزاران گره است که باید بتوانند با استفاده از پروتکل های استاندارد شده با یکدیگر ارتباط برقرار کنند. "لایه شبکه" پشته ای از پروتکل ها است که به آن گره ها اجازه می دهد یکدیگر را پیدا کنند و اطلاعات را مبادله کنند. این شامل اطلاعات "شایعه" (ارتباطات یک به چند) در شبکه و همچنین تعویض درخواست ها و پاسخ ها بین گره های خاص (ارتباط یک به یک) است. هر گره برای اطمینان از ارسال و دریافت اطلاعات صحیح باید به قوانین شبکه خاصی پایبند باشد.
+
+نرمافزار کلاینت دارای دو بخش است (کلینتهای اجرا و کلاینتهای اجماع) که هر کدام دارای پشته شبکه مجزای خود هستند. علاوه بر برقراری ارتباط با سایر گرههای اتریوم، کلاینتهای اجرا و اجماع باید با یکدیگر ارتباط برقرار کنند. در این صفحه توضیح مقدماتی در مورد پروتکل هایی که این ارتباط را فعال می کنند ارائه می دهد.
+
+کلاینت های اجرا تراکنش ها را از طریق شبکه همتا به همتای لایه اجرا شایع می کنند. این امر نیاز به ارتباط رمزگذاری شده بین همتایان تایید شده دارد. هنگامی که یک اعتبارسنج برای پیشنهاد یک بلوک انتخاب می شود، تراکنش ها از مخزن تراکنش های محلی گره از طریق یک اتصال RPC محلی به کلاینت های اجماع منتقل می شوند که در بلوک های بیکن بسته بندی می شوند. کلاینت های اجماع سپس بلوک های بیکن را در شبکه p2p خود شایع می کنند. این به دو شبکه p2p جداگانه نیاز دارد: یکی اتصال کلاینت های اجرا برای شایعات تراکنش و دیگری اتصال کلاینت های اجماع برای شایعات بلوک.
+
+## موارد مورد نیاز {#prerequisites}
+
+مقداری دانش درباره [گره ها و کلاینت ihd](/developers/docs/nodes-and-clients/) اتریوم برای درک این صفحه مفید خواهد بود.
+
+## لایه اجرا {#execution-layer}
+
+پروتکل های شبکه لایه اجرا به دو پشته تقسیم می شوند:
+
+- پشته اکتشاف: بر روی UDP ساخته شده است و به یک گره جدید اجازه می دهد همتاهایی را برای اتصال پیدا کند
+
+- پشته DevP2P: در بالای TCP قرار می گیرد و گره ها را قادر به تبادل اطلاعات می کند
+
+هر دو پشته به صورت موازی کار می کنند. پشته اکتشاف، شرکتکنندگان جدید شبکه را به شبکه تغذیه میکند و پشته DevP2P تعاملات آنها را فعال میکند.
+
+### اکتشاف {#discovery}
+
+اکتشاف فرآیند یافتن گره های دیگر در شبکه است. این بوت استرپ با استفاده از مجموعه کوچکی از بوتنودها انجام می شود (گره هایی که آدرس آنها [هاردکد](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) در کلاینت است تا بتوان آنها را فورا پیدا کرد و کلاینت را به همتایان متصل کرد). این بوتنودها فقط برای معرفی یک گره جدید به مجموعهای از همتایان وجود دارند - این تنها هدف آنهاست، آنها در کارهای عادی کلاینت مانند همگامسازی زنجیره شرکت نمیکنند و تنها در اولین باری که کلاینت چرخانده میشود، استفاده میشوند.
+
+پروتکل مورد استفاده برای تعاملات گره-بوتنود یک شکل تغییر یافته از [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) است که از [جدول هش توزیع شده](https://en.wikipedia.org/wiki/Distributed_hash_table) برای به اشتراک گذاری لیست گره ها استفاده می کند. هر گره دارای نسخه ای از این جدول است که حاوی اطلاعات مورد نیاز برای اتصال به نزدیکترین همتایان خود است. این "نزدیک" بار جغرافیایی ندارد - بلکه در فاصله با شباهت شناسه گره تعریف می شود. جدول هر گره به عنوان یک ویژگی امنیتی به طور منظم به روز می شود. به عنوان مثال، در [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)، گرههای پروتکل اکتشاف همچنین میتوانند «تبلیغاتی» را ارسال کنند که پروتکلهای فرعی را که کلاینت پشتیبانی میکند، نمایش میدهد و به همتایان اجازه میدهد در مورد پروتکلهایی که هر دو میتوانند برای برقراری ارتباط استفاده کنند، مذاکره کنند.
+
+اکتشاف با یک بازی پینگ پنگ شروع می شود. یک پینگ پنگ موفق، گره جدید را به یک بوت نود "پیوند" می کند. پیام اولیه ای که به بوت نود از وجود گره جدیدی که وارد شبکه می شود هشدار می دهد `PING` است. این `PING` شامل اطلاعات هش شده در مورد گره جدید، بوت نود و یک مهر زمان انقضا است. بوتنود `PING` را دریافت میکند و یک `PONG` حاوی هش `PING` برمیگرداند. اگر هشهای `PING` و `PONG` مطابقت داشته باشند، ارتباط بین گره جدید و بوتنود تأیید میشود و گفته میشود که آنها "متصل" شدهاند.
+
+پس از اتصال، گره جدید می تواند یک درخواست `FIND-NEIGHBOURS` را به بوت نود ارسال کند. داده های بازگردانده شده توسط بوت نود شامل لیستی از همتایان است که گره جدید می تواند به آنها متصل شود. اگر گرهها متصل نباشند، درخواست `FIND-NEIGHBOURS` با شکست مواجه میشود، بنابراین گره جدید نمیتواند وارد شبکه شود.
+
+هنگامی که گره جدید لیستی از همسایگان را از بوت نود دریافت می کند، مبادله PING-PONG را با هر یک از آنها آغاز می کند. پینگپنگهای موفق، گره جدید را با همسایگانش پیوند میدهند و تبادل پیام را ممکن میسازند.
+
+```
+start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours
+```
+
+کلاینت های اجرا در حال حاضر از پروتکل اکتشاف [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) استفاده می کنند و تلاش فعالی برای انتقال به پروتکل [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) وجود دارد.
+
+#### ENR: رکوردهای گره اتریوم {#enr}
+
+این [رکورد گره اتریوم (ENR)](/developers/docs/networking-layer/network-addresses/) یک شی است که شامل سه عنصر اساسی است: یک امضا (هش از محتویات رکورد ساخته شده بر اساس برخی از طرح های هویت توافق شده)، یک شماره دنباله ای که تغییرات را در رکورد ردیابی می کند، و یک لیست دلخواه از جفت های کلیدهای ارزش. این یک فرمت مقاوم در برابر آینده است که امکان تبادل آسان اطلاعات شناسایی بین همتایان جدید را فراهم می کند و فرمت [آدرس شبکه](/developers/docs/networking-layer/network-addresses) ترجیحی برای گره های اتریوم است.
+
+#### چرا اکتشاف بر اساس UDP ساخته شده است؟ {#why-udp}
+
+UDP هیچ گونه بررسی خطا، ارسال مجدد بسته های ناموفق، یا باز و بسته شدن پویا اتصالات را پشتیبانی نمی کند - در عوض، صرف نظر از اینکه آیا با موفقیت دریافت شده است یا خیر، فقط یک جریان مداوم از اطلاعات را به سمت یک هدف شلیک می کند. این عملکرد حداقلی همچنین به هزینه حداقلی تبدیل می شود و این نوع اتصال را بسیار سریع می کند. برای اکتشاف، جایی که یک گره به سادگی میخواهد حضور خود را نشان دهد تا پس از آن یک ارتباط رسمی با همتا برقرار کند، UDP کافی است. با این حال، برای بقیه پشته شبکه، UDP برای هدف امورات مناسب نیست. تبادل اطلاعات بین گرهها بسیار پیچیده است و بنابراین به پروتکل کاملتری نیاز دارد که بتواند از ارسال مجدد، بررسی خطا و غیره پشتیبانی کند. سربار اضافی مرتبط با TCP ارزش عملکرد اضافی را دارد. بنابراین، اکثر پشته P2P روی TCP عمل می کند.
+
+### DevP2P {#devp2p}
+
+DevP2P خودش مجموعه کاملی از پروتکلهایی است که اتریوم برای ایجاد و نگهداری شبکه همتا به همتا پیادهسازی میکند. پس از ورود گره های جدید به شبکه، تعاملات آنها توسط پروتکل هایی در پشته [DevP2P](https://github.com/ethereum/devp2p) کنترل می شود. همه اینها در بالای TCP قرار دارند و شامل پروتکل انتقال RLPx، پروتکل سیمی و چندین پروتکل فرعی هستند. پروتکل [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) پروتکلی است که بر شروع، احراز هویت و حفظ نشست ها بین گره ها حاکم است. RLPx پیام ها را با استفاده از RLP (پیشوند طول بازگشتی) رمزگذاری می کند که یک روش بسیار کارآمد برای رمزگذاری داده ها در یک ساختار حداقلی برای ارسال بین گره ها است.
+
+یک جلسه RLPx بین دو گره با یک ارتباط گیری رمزنگاری اولیه آغاز می شود. این مرحله شامل ارسال یک پیام احراز هویت توسط گره است که سپس توسط همتا تایید می شود. در تأیید موفقیت آمیز، همتا یک پیام تأیید اعتبار برای بازگشت به گره آغازگر تولید می کند. این یک فرآیند تبادل کلید است که گره ها را قادر می سازد به صورت خصوصی و ایمن با هم ارتباط برقرار کنند. یک ارتباط گیری رمزنگاری شده موفق، سپس هر دو گره را تحریک می کند تا پیام "سلام" را به یکدیگر "روی سیم" ارسال کنند. پروتکل سیمی با تبادل موفقیت آمیز پیام های سلام آغاز می شود.
+
+پیام های سلام شامل موارد زیر است:
+
+- نسخه پروتکل
+- شناسه کلاینت
+- پورت
+- شناسه گره
+- لیستی از پروتکل های فرعی پشتیبانی شده
+
+این اطلاعات مورد نیاز برای یک تعامل موفق است زیرا مشخص می کند که چه قابلیت هایی بین هر دو گره به اشتراک گذاشته می شود و ارتباطات را پیکربندی می کند. یک فرآیند مذاکره پروتکل فرعی وجود دارد که در آن لیست های پروتکل های فرعی پشتیبانی شده توسط هر گره با هم مقایسه می شوند و مواردی که برای هر دو گره مشترک هستند می توانند در نشست استفاده شوند.
+
+همراه با پیام های سلام، پروتکل سیم همچنین می تواند یک پیام "قطع اتصال" ارسال کند که به همتایان هشدار می دهد که اتصال بسته خواهد شد. پروتکل سیمی همچنین شامل پیام های PING و PONG است که به صورت دوره ای برای باز نگه داشتن یک جلسه ارسال می شوند. بنابراین مبادلات پروتکل RLPx و سیمی پایههای ارتباط بین گرهها را ایجاد میکنند و داربستی را برای اطلاعات مفیدی که طبق یک پروتکل فرعی خاص مبادله میشوند فراهم میکنند.
+
+### پروتکل های فرعی {#sub-protocols}
+
+#### پروتکل سیمی {#wire-protocol}
+
+هنگامی که همتاها متصل می شوند و یک نشست RLPx شروع می شود، پروتکل سیمی نحوه ارتباط همتاها را مشخص می کند. در ابتدا، پروتکل سیمی سه وظیفه اصلی را تعریف کرد: همگام سازی زنجیره ای، انتشار بلوک و تبادل تراکنش. با این حال، هنگامی که اتریوم به اثبات سهام روی آورد، انتشار بلوک و همگام سازی زنجیره بخشی از لایه اجماع شد. مبادله تراکنش هنوز در اختیار کلاینت اجرا است. تبادل تراکنش به مبادله تراکنش های معلق بین گره ها اشاره دارد تا سازندگان بلوک بتوانند برخی از آنها را برای گنجاندن در بلوک بعدی انتخاب کنند. اطلاعات دقیق درباره این وظایف [اینجا](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) موجود است. کلاینت هایی که از این پروتکل های فرعی پشتیبانی می کنند، آنها را از طریق [JSON-RPC](/developers/docs/apis/json-rpc/) در معرض دید قرار می دهند.
+
+#### les (پروتکل فرعی سبک اتریوم) {#les}
+
+این یک پروتکل حداقلی برای همگام سازی کلاینت های سبک است. به طور سنتی این پروتکل به ندرت مورد استفاده قرار میگرفت زیرا گرههای کامل برای ارائه دادهها به کلاینت های سبک بدون ایجاد انگیزه مورد نیاز هستند. رفتار پیشفرض کلاینتهای اجرا این است که دادههای کلاینت سبک را روی les ارائه نمیکنند. اطلاعات بیشتر در les [جزئیات فنی](https://github.com/ethereum/devp2p/blob/master/caps/les.md) موجود است.
+
+#### Snap {#snap}
+
+[پروتکل snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) یک برنامه افزودنی اختیاری است که به همتایان اجازه میدهد تا تصاویر لحظه ای از وضعیتهای اخیر را مبادله کنند، و به همتایان اجازه میدهد تا دادههای حساب و ذخیرهسازی را بدون نیاز به دانلود گرههای میانی درخل مرکل تأیید کنند.
+
+#### Wit (پروتکل شاهد) {#wit}
+
+[پروتکل شاهد](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) یک برنامه افزودنی اختیاری است که تبادل شاهدان حالت را بین همتایان امکانپذیر میکند و به همگامسازی کلاینت ها با نوک زنجیره کمک میکند.
+
+#### Whisper {#whisper}
+
+Whisper پروتکلی بود که هدف آن ارسال پیام ایمن بین همتایان بدون نوشتن هیچ گونه اطلاعاتی در بلاکچین بود. بخشی از پروتکل سیم DevP2P بود اما اکنون منسوخ شده است. دیگر [پروژه های مرتبط](https://wakunetwork.com/) با اهداف مشابه وجود دارند.
+
+## لایه اجماع {#consensus-layer}
+
+کلاینت های اجماع در یک شبکه همتا به همتا جداگانه با مشخصات متفاوت شرکت می کنند. کلاینت های اجماع باید در شیوع بلوک شرکت کنند تا بتوانند بلوکهای جدید را از همتایان دریافت کنند و زمانی که نوبت به پیشنهاد بلوک رسید، آنها را پخش کنند. مشابه لایه اجرا، ابتدا به یک پروتکل اکتشاف نیاز است تا یک گره بتواند همتایان را پیدا کند و نشست های امنی را برای تبادل بلوک ها، گواهی ها و غیره ایجاد کند.
+
+### اکتشاف {#consensus-discovery}
+
+مشابه کلاینت های اجرا، کلاینت های اجماع از [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) روی UDP برای یافتن همتایان استفاده می کنند. پیادهسازی لایه اجماع discv5 با اجرای کلاینتهای اجرا تنها از این جهت متفاوت است که شامل مبدّلی است که discv5 را به پشته [libP2P](https://libp2p.io/) متصل میکند و DevP2P را منسوخ میکند. جلسههای RLPx لایه اجرا به نفع ارتباطگیری کانال ضد-نویز libP2P منسوخ شده است.
+
+### ENRها {#consensus-enr}
+
+ENR برای گره های اجماع شامل کلید عمومی گره، آدرس IP، پورت های UDP و TCP و دو فیلد خاص اجماع است: فیلد بیتی زیرشبکه گواهی و کلید `eth2`. مورد اول یافتن همتایان شرکت کننده در زیرشبکه های شایعات گویای گواهی را برای گره ها آسان تر می کند. کلید `eth2` نیز حاوی اطلاعاتی در مورد اینکه گره از کدام نسخه فورک اتریوم استفاده می کند، اطمینان حاصل می کند که همتایان به اتریوم مناسب متصل هستند.
+
+### libP2P {#libp2p}
+
+پشته libP2P از تمام ارتباطات پس از اکتشاف پشتیبانی می کند. کلاینت ها می توانند شماره گیری کرده و به IPv4 و/یا IPv6 همانطور که در ENR آنها تعریف شده است گوش دهند. پروتکل های لایه libP2P را می توان به دو حوزه شایعات و درخواست/پاسخ تقسیم کرد.
+
+### شایعات {#gossip}
+
+دامنه شایعات شامل تمام اطلاعاتی است که باید به سرعت در سراسر شبکه پخش شود. این شامل بلوک های بیکن، اثبات ها، امضاها، خروج و جریمه شدن است. این با استفاده از libP2P gossipsub v1 منتقل میشود و متکی به ابردادههای مختلفی است که به صورت محلی در هر گره ذخیره میشوند، از جمله حداکثر اندازه محمولههای شایعات برای دریافت و ارسال. اطلاعات دقیق در مورد دامنه شایعات [اینجا](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub) موجود است.
+
+### درخواست-پاسخ {#request-response}
+
+دامنه درخواست-پاسخ شامل پروتکل هایی برای کلاینت هایی است که اطلاعات خاصی را از همتایان خود درخواست می کنند. به عنوان مثال میتوان به درخواست بلوکهای بیکن خاص با هشهای ریشه خاص یا در محدودهای از اسلاتها اشاره کرد. پاسخ ها همیشه به صورت بایت های رمزگذاری شده SSZ فشرده شده برگردانده می شوند.
+
+## چرا کلاینت اجماع SSZ را به RLP ترجیح می دهد؟ {#ssz-vs-rlp}
+
+SSZ مخفف سریال سازی ساده است. از افست های ثابتی استفاده می کند که رمزگشایی بخش های جداگانه یک پیام رمزگذاری شده را بدون نیاز به رمزگشایی کل ساختار آسان می کند، که برای کلاینت اجماع بسیار مفید است زیرا می تواند به طور موثر بخش های خاصی از اطلاعات را از پیام های رمزگذاری شده بگیرد. همچنین به طور خاص برای ادغام با پروتکلهای مرکل، با افزایش کارایی مرتبط برای Merkleization طراحی شده است. از آنجایی که همه هش ها در لایه اجماع ریشه های مرکل هستند، این باعث بهبود قابل توجهی می شود. SSZ همچنین نمایش منحصر به فرد اعداد را تضمین می کند.
+
+## اتصال کلاینت های اجرا و اجماع {#connecting-clients}
+
+کلاینت های اجماع و اجرا به صورت موازی اجرا می شوند. آنها باید به هم متصل شوند تا کلاینت اجماع بتواند دستورالعمل هایی را برای کلاینت اجرا ارائه دهد و کلاینت اجرا بتواند بسته هایی از تراکنش ها را به کلاینت اجماع ارسال کند تا در بلوک های بیکن گنجانده شوند. ارتباط بین دو کلاینت را می توان با استفاده از یک اتصال RPC محلی به دست آورد. یک API معروف به ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) دستورالعمل های ارسال شده بین دو کلاینت را تعریف می کند. از آنجایی که هر دو کلاینت پشت یک هویت شبکه قرار دارند، یک ENR (رکورد گره اتریوم) به اشتراک می گذارند که حاوی یک کلید جداگانه برای هر کلاینت (کلید eth1 و کلید eth2) است.
+
+خلاصه ای از جریان کنترل در زیر نشان داده شده است، همراه با پشته شبکه مربوطه در پرانتز.
+
+### وقتی کلاینت اجماع یک تولیدکننده بلوک نیست: {#when-consensus-client-is-not-block-producer}
+
+- کلاینت اجماع یک بلوک را از طریق پروتکل شایعات بلوک دریافت می کند (p2p اجماع)
+- کلاینت اجماع بلوک را از قبل تأیید می کند، یعنی اطمینان حاصل می کند که از یک فرستنده معتبر با متادیتا صحیح رسیده است
+- تراکنش های موجود در بلوک به عنوان یک پیلود اجرا (اتصال RPC محلی) به لایه اجرا ارسال می شوند
+- لایه اجرا تراکنش ها را اجرا می کند و وضعیت موجود در هدر بلوک را تأیید می کند (یعنی تطابق هش ها را بررسی می کند)
+- لایه اجرا داده های اعتبارسنج را به لایه اجماع برمی گرداند، بلوک هم الان به عنوان تایید شده در نظر گرفته می شود (اتصال RPC محلی)
+- لایه اجماع، بلوک را به سر بلاکچین خود اضافه می کند و آن را تأیید می کند، تأیید را از طریق شبکه پخش می کند (p2p اجماع)
+
+### وقتی کلاینت اجماع یک تولید کننده بلوک است: {#when-consensus-client-is-block-producer}
+
+- کلاینت اجماع اطلاعیه دریافت می کند که تولید کننده بلوک بعدی است (p2p اجماع)
+- لایه اجماع روش `ایجاد بلوک` را در کلاینت اجرا فرا می خواند (RPC محلی)
+- لایه اجرا به مخزن تراکنش که توسط پروتکل شایعات تراکنش پر شده است دسترسی دارد (p2p اجرا)
+- کلاینت اجرا تراکنش ها را در یک بلوک بسته بندی می کند، تراکنش ها را اجرا می کند و یک هش بلوک ایجاد می کند
+- کلاینت اجماع تراکنش ها و هش بلوک را از کلاینت اجرا می گیرد و به بلوک بیکن اضافه می کند (RPC محلی)
+- کلاینت اجماع بلوک را از طریق پروتکل شایعات بلوک پخش می کند (p2p اجماع)
+- سایر کلاینت ها بلوک پیشنهادی را از طریق پروتکل شایعات بلوک دریافت می کنند و همانطور که در بالا توضیح داده شد اعتبارسنجی می کنند (p2p اجماع)
+
+هنگامی که بلوک توسط اعتبارسنج های کافی تأیید شد، به سر زنجیره اضافه می شود، تنظیم می شود و در نهایت نهایی می شود.
+
+![](cons_client_net_layer.png) ![](exe_client_net_layer.png)
+
+شماتیک لایه شبکه برای مشتریان اجماع و اجرا، از [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
+
+## اطلاعات بیشتر {#further-reading}
+
+[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [مشخصات شبکه لایه اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia به discv5](https://vac.dev/kademlia-to-discv5) [مقاله kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [معرفی p2p اتریوم ](https://p2p.paris/en/talks/intro-ethereum-networking/) [رابطه eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [ویدیوی مرج و جزئیات کلاینت eth2](https://www.youtube.com/watch?v=zNIrIninMgg)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md
new file mode 100644
index 00000000000..f1d459e5c81
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md
@@ -0,0 +1,38 @@
+---
+title: آدرسهای شبکه
+description: مقدمه ای بر آدرس های شبکه.
+lang: fa
+sidebarDepth: 2
+---
+
+گره های اتریوم برای اتصال به همتایان باید خود را با برخی از اطلاعات اولیه شناسایی کنند. برای اطمینان از اینکه هر همتای بالقوه می تواند این اطلاعات را تفسیر کند، در یکی از سه فرمت استاندارد شده ای که هر گره اتریوم می تواند درک کند، ارسال می شود: multiaddr، enode، یا Ethereum Node Records (ENR). ENR ها استاندارد فعلی آدرس های شبکه اتریوم هستند.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای درک این صفحه، مقداری آشنایی با [لایه شبکه](/developers/docs/networking-layer/) اتریوم لازم است.
+
+## Multiaddr {#multiaddr}
+
+قالب اصلی آدرس گره اتریوم 'multiaddr' (مخفف 'multi-addresses') بود. Multiaddr یک قالب جهانی است که برای شبکه های همتا به همتا طراحی شده است. آدرس ها به صورت جفت های کلید-مقدار با کلیدها و مقادیری که با یک اسلش رو به جلو از هم جدا شده اند نشان داده می شوند. به عنوان مثال، multiaddr برای یک گره با آدرس IPv4 `192.168.22.27` در حال گوش دادن به پورت TCP `33000` به نظر می رسد:
+
+`/ip4/192.168.22.27/tcp/33000`
+
+برای یک گره اتریوم، multiaddr شامل شناسه گره (هش کلید عمومی آنها) است:
+
+`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br`
+
+## Enode {#enode}
+
+یک Enode راهی برای شناسایی گره اتریوم با استفاده از فرمت آدرس URL است. شناسه گره هگزادسیمال در قسمت نام کاربری URL که از میزبان جدا شده است با استفاده از علامت @ کدگذاری می شود. نام میزبان فقط می تواند به عنوان یک آدرس IP داده شود. نام های DNS مجاز نیستند. پورت موجود در قسمت hostname پورت گوش دادن TCP است. اگر پورت های TCP و UDP (کشف) متفاوت باشند، پورت UDP به عنوان پارامتر پرس و جو "discport" مشخص می شود
+
+در مثال زیر، گره URL گرهای را با آدرس IP `10.3.58.6`، پورت TCP `30303` و پورت کشف UDP `30301` توصیف میکند.
+
+`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301`
+
+## سوابق گره اتریوم (ENR) {#enr}
+
+Ethereum Node Records (ENRs) یک فرمت استاندارد شده برای آدرس های شبکه در اتریوم است. آنها جایگزین multiaddr و enodes می شوند. اینها به ویژه مفید هستند زیرا اجازه تبادل اطلاعات بیشتر بین گره ها را می دهند. ENR شامل یک امضا، شماره دنباله و فیلدهایی است که طرح هویت مورد استفاده برای تولید و اعتبارسنجی امضاها را شرح می دهد. ENR همچنین می تواند با داده های دلخواه سازماندهی شده به عنوان جفتهای مقدار کلید پر شود. این جفتهای مقدار کلید حاوی آدرس IP گره و اطلاعات مربوط به پروتکلهای فرعی هستند که گره قادر به استفاده از آن است. کلاینتهای اجماع از یک [ساختار خاص ENR](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) برای شناسایی نودهای راهاندازی استفاده میکنند و همچنین یک فیلد `eth2` حاوی اطلاعات مربوط به فورک فعلی اتریوم و زیرشبکه شایعه تصدیق را در بر میگیرد (این، گره را به یک مجموعه خاصی از همتایان که گواهینامه های آنها با هم جمع شده است، وصل میکند).
+
+## اطلاعات بیشتر {#further-reading}
+
+[EIP-778: سوابق گره اتریوم (ENR)](https://eips.ethereum.org/EIPS/eip-778) [آدرسهای شبکه در اتریوم](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md
new file mode 100644
index 00000000000..aad0835e42a
--- /dev/null
+++ b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md
@@ -0,0 +1,83 @@
+---
+title: شبکه پرتال
+description: مروری بر شبکه پورتال - یک شبکه در حال توسعه که برای پشتیبانی از مشتریان با منابع کم طراحی شده است.
+lang: fa
+---
+
+اتریوم شبکه ای متشکل از رایانه هایی است که نرم افزار کاربر اتریوم را اجرا می کنند. هر یک از این کامپیوترها "گره" نامیده می شوند. نرم افزار کاربر به یک گره اجازه می دهد تا داده ها را در شبکه اتریوم ارسال و دریافت کند و داده ها را بر اساس قوانین پروتکل اتریوم تأیید می کند. گره ها داده های تاریخی زیادی را در فضای ذخیره سازی دیسک خود نگه می دارند و زمانی که بسته های جدیدی از اطلاعات را که به نام بلوک ها شناخته می شوند از سایر گره های شبکه دریافت می کنند، به آن اضافه می کنند. این برای بررسی اینکه یک گره همیشه اطلاعاتی مطابق با بقیه شبکه دارد ضروری است. این بدان معناست که اجرای یک گره می تواند به فضای دیسک زیادی نیاز داشته باشد. برخی از عملیات گره ها می توانند به مقدار زیادی RAM نیز نیاز داشته باشند.
+
+برای دور زدن این مشکل ذخیره سازی دیسک، گره های "سبک" توسعه یافته اند که به جای ذخیره کردن همه آنها، اطلاعات را از گره های کامل درخواست می کنند. با این حال، این بدان معنی است که گره سبک به طور مستقل اطلاعات را تأیید نمی کند و در عوض به گره دیگری اعتماد دارد. همچنین به این معنی است که گره های کامل باید کار اضافی را برای خدمت به آن گره های سبک انجام دهند.
+
+شبکه پورتال یک طراحی شبکه جدید برای اتریوم است که هدف آن حل مشکل در دسترس بودن داده برای گره های "سبک" بدون نیاز به اعتماد یا اعمال فشار اضافی بر گره های کامل، با اشتراک گذاری داده های لازم در قطعات کوچک در سراسر شبکه است.
+
+جزئیات بیشتر [گره ها و کاربرها](/developers/docs/nodes-and-clients/)
+
+## چرا به شبکه پورتال نیاز داریم {#why-do-we-need-portal-network}
+
+گره های اتریوم کپی کامل یا جزئی خود از بلاک چین اتریوم را ذخیره می کنند. این کپی محلی، برای اعتبارسنجی تراکنش ها و اطمینان از اینکه گره از زنجیره صحیح پیروی می کند استفاده می شود. این دادههای ذخیرهشده محلی، به گرهها اجازه میدهند تا بدون نیاز به اعتماد به هیچ نهاد دیگری، بهطور مستقل تأیید کنند که دادههای ورودی معتبر و صحیح هستند.
+
+این کپی محلی از بلاک چین و داده های مربوط به وضعیت و دریافت، فضای زیادی را در هارد دیسک گره اشغال می کند. به عنوان مثال، یک هارد دیسک 2 ترابایتی برای اجرای یک گره با استفاده از [Geth](https://geth.ethereum.org) جفت شده با یک کلاینت اجماع توصیه می شود. با استفاده از Snap Sync، که فقط داده های زنجیره ای از مجموعه نسبتاً جدید بلوک ها را ذخیره می کند، Geth معمولاً حدود 650 گیگابایت فضای دیسک را اشغال می کند اما در حدود 14 گیگابایت در هفته رشد می کند (شما می توانید گره را به صورت دوره ای به 650 گیگابایت کاهش دهید).
+
+این بدان معناست که اجرای گرهها میتواند گران باشد، زیرا مقدار زیادی از فضای دیسک باید به اتریوم اختصاص داده شود. چندین راه حل برای این مشکل در نقشه راه اتریوم وجود دارد، از جمله [انقضای تاریخچه](/roadmap/statelessness/#history-expiry)، [انقضای وضعیت](/roadmap/statelessness/#state-expiry) و [بی حالت بودن](/roadmap/statelessness/). با این حال، احتمالاً چندین سال تا اجرایی شدن فاصله دارد. همچنین [گره های سبک](/developers/docs/nodes-and-clients/light-clients/) وجود دارند که کپی خود را از داده های زنجیره ای ذخیره نمی کنند، آنها داده های مورد نیاز خود را از گره های کامل درخواست می کنند. با این حال، این بدان معناست که گرههای سبک باید به گرههای کامل اعتماد کنند تا دادههای صادقانه ارائه کنند و همچنین بر گرههای کاملی که باید دادههای مورد نیاز گرههای سبک را ارائه دهند، استرس وارد میکند.
+
+هدف شبکه پورتال ارائه روشی جایگزین برای گره های سبک برای دریافت داده های خود است که نیازی به اعتماد یا اضافه کردن قابل توجه به کاری که باید توسط گره های کامل انجام شود ندارد. روشی که این کار انجام خواهد شد، معرفی روشی جدید برای گرههای اتریوم برای به اشتراک گذاری داده ها در سراسر شبکه است.
+
+## شبکه پورتال چگونه کار می کند؟ {#how-does-portal-network-work}
+
+گره های اتریوم پروتکل های سختگیرانه ای دارند که نحوه ارتباط آنها با یکدیگر را مشخص می کند. کاربرهای اجرا با استفاده از مجموعهای از پروتکلهای فرعی به نام [DevP2P](/developers/docs/networking-layer/#devp2p) ارتباط برقرار میکنند، در حالی که کاربرهای اجماع از پشته متفاوتی از پروتکلهای فرعی به نام [libP2P](/developers/docs/networking-layer/#libp2p) استفاده میکنند. اینها انواع داده هایی را که می توانند بین گره ها ارسال شوند، تعریف می کنند.
+
+![devP2P و libP2P](portal-network-devp2p-libp2p.png)
+
+گرهها همچنین میتوانند دادههای خاصی را از طریق [JSON-RPC API](/developers/docs/apis/json-rpc/) ارائه دهند، به این ترتیب برنامهها و کیف پولها اطلاعات را با گرههای اتریوم مبادله میکنند. با این حال، هیچ یک از اینها پروتکل های ایده آلی برای ارائه داده به کاربرهای سبک نیستند.
+
+کاربرهای سبک در حال حاضر نمی توانند قطعات خاصی از داده های زنجیره ای را از طریق DevP2P یا libP2p درخواست کنند زیرا این پروتکل ها فقط برای فعال کردن همگام سازی زنجیره ای و شایعه پراکنی بلوک ها و تراکنش ها طراحی شده اند. کاربرهای سبک نمیخواهند این اطلاعات را دانلود کنند زیرا این کار باعث میشود که آنها "سبک" بودن را متوقف کنند.
+
+JSON-RPC API یک انتخاب ایدهآل برای درخواست دادههای کاربر سبک نیست، زیرا بر اتصال به یک گره کامل خاص یا ارائهدهنده RPC متمرکز است که میتواند به دادهها سرویس دهد. این بدان معناست که کاربر سبک باید به صداقت آن گره/ارائهدهنده خاص اعتماد کند، و همچنین گره کامل ممکن است مجبور باشد بسیاری از درخواستهای بسیاری از مشتریان سبک را رسیدگی کند و به پهنای باند مورد نیاز آنها بیفزاید.
+
+هدف شبکه پورتال این است که در کل طراحی، به طور خاص برای سبکی، خارج از محدودیت های طراحی مشتریان موجود اتریوم، تجدید نظر کند.
+
+ایده اصلی شبکه پورتال این است که با فعال کردن اطلاعات مورد نیاز مشتریان سبک، مانند دادههای تاریخی و هویت سر فعلی زنجیره، بهترین بیتها از پشته شبکه فعلی را دریافت کند که از طریق یک شبکه غیرمتمرکز همتا به همتا به سبک DevP2P با استفاده از [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (شبیه Bittorrent) ارائه خواهند شد.
+
+ایده این است که بخشهای کوچکی از کل دادههای تاریخی اتریوم و برخی مسئولیتهای گره خاص به هر گره اضافه شود. سپس، درخواستها با جستجوی گرههایی که دادههای خاص درخواست شده را ذخیره میکنند، و با بازیابی آنها از آنها ارائه میشوند.
+
+این مدل معمولی گرههای نوری را وارونه میکند که یک گره را پیدا میکنند و از آنها درخواست میکنند تا حجم زیادی از داده را فیلتر و ارائه کنند. در عوض، آنها به سرعت شبکه بزرگی از گرهها را فیلتر میکنند که هر کدام حجم کمی از دادهها را مدیریت میکنند.
+
+هدف این است که به شبکه غیرمتمرکز مشتریان پورتال سبک وزن اجازه دهیم تا:
+
+- سر زنجیره را دنبال کند
+- داده های زنجیره ای اخیر و گذشته را همگام کند
+- اطلاعات وضعیت را بازیابی کند
+- تراکنش ها را پخش کند
+- تراکنش ها را با استفاده از [EVM](/developers/docs/evm/) اجرا کند
+
+مزایای این طراحی شبکه عبارتند از:
+
+- کاهش وابستگی به ارائه دهندگان متمرکز
+- کاهش استفاده از پهنای باند اینترنت
+- همگام سازی حداقل یا صفر
+- قابل دسترسی برای دستگاه های دارای محدودیت منابع (<1 گیگابایت رم، <100 مگابایت فضای دیسک، 1 CPU)
+
+نمودار زیر عملکردهای کاربرهای موجود را نشان میدهد که میتواند توسط شبکه پورتال ارائه شود و کاربران را قادر میسازد تا به این عملکردها در دستگاههای با منابع بسیار کم دسترسی داشته باشند.
+
+![جدول شبکه پورتال](portal-network-table2.png)
+
+## تنوع مشتری به طور پیش فرض {#client-diversity-as-default}
+
+توسعه دهندگان شبکه پورتال همچنین طراحی را برای ساختن سه مشتری مجزای شبکه پورتال از روز اول انتخاب کردند.
+
+کاربران شبکه پورتال عبارتند از:
+
+- [Trin](https://github.com/ethereum/trin): نوشته شده در Rust
+- [Fluffy](https://nimbus.team/docs/fluffy.html): نوشته شده به زبان Nim
+- [فوق سبک](https://github.com/ethereumjs/ultralight): نوشته شده در تایپ اسکریپت
+- [Shisui](https://github.com/GrapeBaBa/shisui): نوشته شده در Go
+
+داشتن چندین پیادهسازی کاربر مستقل، انعطافپذیری و عدم تمرکز شبکه اتریوم را افزایش میدهد.
+
+اگر یک کاربر مشکلات یا آسیب پذیری هایی را تجربه کند، سایر کاربرها می توانند به آرامی به کار خود ادامه دهند و از یک نقطه شکست جلوگیری کنند. علاوه بر این، پیادهسازیهای متنوع مشتری، نوآوری و رقابت را تقویت میکند، باعث پیشرفتها و کاهش خطرات تککِشتی در اکوسیستم میشود.
+
+## بیشتر بخوانید {#futher-reading}
+
+- [شبکه پورتال (Piper Merriam در Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA).
+- [دیسکورد شبکه پورتال](https://discord.gg/CFFnmE7Hbs)
+- [وب سایت شبکه پورتال](https://www.ethportal.net/)
diff --git a/public/content/translations/fa/26) Miscellaneous/about/index.md b/public/content/translations/fa/26) Miscellaneous/about/index.md
new file mode 100644
index 00000000000..10f2e68e7fa
--- /dev/null
+++ b/public/content/translations/fa/26) Miscellaneous/about/index.md
@@ -0,0 +1,139 @@
+---
+title: درباره ما
+description: درباره تیم، جامعه و ماموریت ethereum.org
+lang: fa
+---
+
+# در ارتباط با ethereum.org {#about-ethereumorg}
+
+ethereum.org یک منبع عمومی منبع باز برای جامعه اتریوم است که هر کسی میتواند با آن همکاری کند. ما یک تیم اصلی کوچک داریم که با مشارکت هزاران نفر از اعضای جامعه در سراسر جهان به حفظ و توسعه سایت اختصاص داده شده است.
+
+## یادداشتی در مورد اسامی {#a-note-on-names}
+
+معمولاً افراد نامها را در چشمانداز اتریوم اشتباه میگیرند، که میتواند منجر به مدلهای ذهنی ضعیف در مورد نحوه عملکرد اتریوم شود. در اینجا یک توضیح سریع برای روشن کردن موارد وجود دارد:
+
+### اتریوم {#ethereum}
+
+اتریوم یک شبکه عمومی، یک بلاکچین و یک پروتکل منبع باز است متعلق به یک جامعه جهانی متشکل از ده ها هزار توسعه دهنده، اپراتورهای گره، دارندگان ETH و کاربرانی که توسط آنها عملیاتی می شود، حکمرانی می شود و مدیریت می شود.
+
+[جزئیات بیشتر اتریوم](/what-is-ethereum/)
+
+[جرئیات بیشتر حکمرانی اتریوم](/governance/)
+
+### اتر (ETH) {#ether-or-eth}
+
+اتر (همچنین با نماد علامت گذاری آن، ETH شناخته می شود) ارز بومی است که در اتریوم معامله می شود. ETH برای پرداخت هزینه استفاده از شبکه اتریوم (به شکل کارمزد تراکنش) مورد نیاز است. ETH همچنین با سهام گذاری برای ایمن سازی شبکه استفاده می شود. وقتی مردم در مورد قیمت اتریوم صحبت می کنند، به دارایی ETH اشاره می کنند.
+
+[جزئیات بیشتر درباره ETH](/eth/)
+
+[جزئیات بیشتر درباره سهامگذاری ETH](/staking/)
+
+### بنیاد اتریوم {#ethereum-foundation}
+
+یک سازمان غیر انتفاعی، که در ابتدا توسط فروش جمعی ETH تأمین مالی شد و به پشتیبانی از شبکه و اکوسیستم اتریوم اختصاص یافت.
+
+[جزئیات بیشتر درباره بنیاد اتریوم](/foundation/)
+
+### ethereum.org {#ethereum-org}
+
+یک وب سایت عمومی و منبع باز و منبع آموزشی برای جامعه اتریوم. ethereum.org توسط یک تیم اصلی کوچک، که توسط بنیاد اتریوم تامین مالی میشود، با مشارکت هزاران نفر از اعضای جامعه در سراسر جهان هدایت میشود.
+
+این صفحه اطلاعات بیشتری در مورد ethereum.org را پوشش میدهد.
+
+## ماموریت ما {#our-mission}
+
+**ماموریت وبسایت ethereum.org این است که بهترین درگاه جامعه در حال رشد اتریوم باشد**
+
+ما در تلاش هستیم تا یک منبع آموزشی قابل فهم برای همه موضوعات مرتبط با اتریوم بسازیم که به کاربران جدید کمک میکند تا با اتریوم و مفاهیم کلیدی آن آشنا شوند. ما میخواهیم:
+
+- اتریوم را با کسانی که در این تکنولوژی جدید هستند توضیح دهیم
+- به کاربران جدید کمک کنیم تا شروع به استفاده از ETH و اتریوم کنند
+- به توسعهدهندگان جدید کمک کنیم تا ساختن را شروع کنند
+- تازههای دنیای اتریوم را پوشش دهیم
+- ویترین منابعی باشیم که توسط جامعه تولید میشود
+- آموزشهای اتریوم را به هر زبان که ممکن است ارائه کنیم
+
+برای دستیابی به این ماموریت، تیم ما روی دو هدف اصلی در ethereum.org تمرکز میکند:
+
+### 1. بهبود تجربه کاربری برای بازدیدکنندگان ethereum.org {#visitors}
+
+- محتوا را گسترش دهید، بهبود دهید و به روز نگه دارید
+- قابلیت استفاده و دسترسی را از طریق بهترین شیوه های محلی سازی و توسعه وب بهبود بخشید
+- تعامل کاربر را از طریق ویژگیهایی مانند نظرسنجی، آزمونها و ادغام Web3 افزایش دهید
+- وب سایت را سبک و کارآمد نگه دارید
+
+### 2. جامعه مشارکتکنندگان ما را رشد، تقویت و توانمند سازید {#community}
+
+- تعداد کل مشارکتکنندگان در وب سایت را افزایش دهید
+- حفظ مشارکتکنندگان را از طریق مشارکت، قدردانی و پاداش بهبود بخشید
+- اعضای جامعه را توانمند کنید تا مشارکتهای چشمگیری داشته باشند
+- تسهیل تنوع بیشتر مشارکتها: کد، محتوا، طراحی، ترجمه، تعدیل
+- پایگاه کد را مدرن، تمیز و مستند نگه دارید
+
+## اصول اصلی {#core-principles}
+
+ما چند اصل اساسی داریم که به ما کمک میکنند ماموریت خود را به انجام برسانیم.
+
+### 1. ethereum.org یک درگاه برای اتریوم است 🌎 {#core-principles-1}
+
+ما میخواهیم که کاربران ما سود داشته باشند و سوالات آن ها پاسخ داده شود. به همین دلیل درگاه ما نیاز دارد تا اطلاعات، "magic moments" و لینکهای منابع جامعه را که وجود دارند، ترکیب کند. هدف ما این است که محتوای ما "پرتال جذب افراد" باشد، نه یک جایگزین برای انبوهی از اطلاعات که همین الان وجود دارند. ما به دنبال متحد کردن و پشتیبانی اطلاعات ساخته شده توسط جامعه هستیم که موجب شفافیت آن و قابل دسترس بودن آن میشود. [جامعه اتریوم](/community/) قلب تپنده آن است: ما صرفا نباید به آن ها سرویس بدهیم، بلکه با آن ها کار کنیم و بازخورد آن ها را در نظر بگیریم. این وبسایت تنها برای استفاده جامعه الان نیست، بلکه برای جامعهای است که امیدواریم رشد کند. ما باید به خاطر داشته باشیم که جامعه ما جهانی است، و تمام مردم از هر زبان، منطقه و فرهنگی را شامل میشود.
+
+### 2. ethereum.org همواره در حال تکامل است ⚒ {#core-principles-2}
+
+اتریوم و جامعه ما همواره در حال جهش هستند، و نیز ethereum.org. و به این خاطر است که سایت دارای یک طراحی ساده است& یک ساختار مدولار. ما زمانی که میفهمیم مردم چگونه از سایت استفاده میکنند تغییرات مرحلهای انجام میدهیم. ما متن باز هستیم، با یک جامعه مشارکتگر، بنابراین شما هم میتوانید پیشنهاد دهید و ما را کمک کنید. [درباره مشارکت بیاموزید](/contributing/)
+
+### 3. ethereum.org یک وبسایت معمولی نیست 🦄 {#core-principles-3}
+
+اتریوم یک چیز بزرگ است: که یک جامعه، تکنولوژی، و مجموعه ای از ایده ها و موارد دیگر است. این بدان معنی است که سایت نیاز دارد تا تجربههای کاربران مختلف را رسیدگی کند، "از یک توسعه دهنده که یک ابزار مشخص میخواهد" گرفته تا "یک تازهکار که مقداری اتر خریده و حتی معنی کیف پول را نمیداند". "بهترین وبسایت برای پلتفرم زنجیره بلوکی چیست؟" یک سؤال با جواب باز است - ما پیشرو هستیم. ساختن آن به آزمایش نیاز دارد.
+
+## نقشه راه محصول {#roadmap}
+
+تیم اصلی ethereum.org برای در دسترستر کردن کارمان و تقویت همکاری بیشتر در جامعه، یک نمای کلی از اهداف نقشه راه فصلی ما را منتشر میکند.
+
+[نقشه راه سهماهه سوم 2024 ما را ببینید](https://github.com/ethereum/ethereum-org-website/issues/13399)
+
+**چطور است؟** ما همیشه از بازخورد درباره نقشه راه مان قدردانی می کنیم - اگر چیزی وجود دارد که فکر می کنید باید روی آن کار کنیم، لطفاً به ما اطلاع دهید! ما از ایدهها و روابط عمومی هر کس در جامعه استقبال میکنیم.
+
+**میخواهید مشارکت کنید؟** [درباره مشارکت بیشتر بیاموزید](/contributing/)، [در توییتر با ما تماس بگیرید](https://twitter.com/ethdotorg)، یا به بحثهای جامعه در
+
+سرور دیسکورد ما بپیوندید< /3>.
+
+
+
+## اصول طراحی کنید {#design-principles}
+
+ما از مجموعه ای از [اصول طراحی](/contributing/design-principles/) برای پیشبرد محتوا و تصمیمات طراحی در وبسایت استفاده می کنیم.
+
+
+
+## سیستم طراحی {#design-system}
+
+ما یک [سیستم طراحی](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) ساختیم و منتشر کردیم تا ویژگیها را سریعتر ارسال کنیم و به اعضای انجمن اجازه دهیم در طراحی باز ethereum.org شرکت کنند.
+
+می خواهید شرکت کنید؟[در فیگما](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System) بخش [مشکل گیت هاب](https://github.com/ethereum/ethereum-org-website/issues/6284) را دنبال کنید و به گفتگو در [ کانال دیسکورد ما بپیوندید](https://discord.gg/ethereum-org).
+
+
+
+## راهنمای سبک {#style-guide}
+
+ما [یک راهنمای سبک](/contributing/style-guide/) برای استانداردسازی ابعاد مشخصی از محتوای نوشتاری داریم تا فرایند کار ساده و هموارتر شود.
+
+حتما [اصول طراحی](/contributing/design-principles/) و [راهنمای سبک](/contributing/style-guide/) را مطالعه کنید و اگر دوست داشتید [به سایت ما کمک کنید](/contributing/).
+
+ما از بازخورد در مورد اصول طراحی، سیستم طراحی و راهنمای سبکمان استقبال میکنیم. به یاد داشته باشید، ethereum.org برای جامعه و از طرف جامعه است.
+
+
+
+## مجوز {#license}
+
+وب سایت ethereum.org منبع باز است و تحت [مجوز MIT](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) ساخته شده است، مگر اینکه خلاف آن مشخص شده باشد. اطلاعات بیشتر در مورد [شرایط استفاده](/terms-of-use/) از ethereum.org.
+
+
+
+## شغل های موجود {#open-jobs}
+
+اگرچه این وبسایت متن باز است و همه می توانند روی آن کار کنند، تیمی مختص به ethereum.org و پروژه های دیگر وب بنیاد اتریوم داریم.
+
+مشاغل موجود را در اینجا می نویسیم. اگر نقشی در اینجا برای خود نمی بینید، به [سرور دیسکورد ما](https://discord.gg/ethereum-org) بروید و به ما اطلاع دهید که چگونه می خواهید با ما کار کنید!
+
+آیا به چیزی فراتر از تیم ethereum.org فکر می کنید؟ [سایر مشاغل مربوط به اتریوم را در اینجا چک کنید](/community/get-involved/#ethereum-jobs/).
diff --git a/public/content/translations/fa/26) Miscellaneous/enterprise/index.md b/public/content/translations/fa/26) Miscellaneous/enterprise/index.md
new file mode 100644
index 00000000000..23e1f61976a
--- /dev/null
+++ b/public/content/translations/fa/26) Miscellaneous/enterprise/index.md
@@ -0,0 +1,199 @@
+---
+title: تشکیلات سازمانی بر بستر شبکه اصلی اتریوم
+description: راهنماها، مقالات و ابزارهایی درباره برنامه های کاربردی سازمانی در بلاک چین عمومی اتریوم
+lang: fa
+---
+
+# اتریوم برای سازمان {#ethereum-for-enterprise}
+
+اتریوم میتواند به انواع مختلف شرکتها، از جمله شرکتهای بزرگ کمک کند:
+
+- افزایش اعتماد و کاهش هزینه های هماهنگی بین طرف های تجاری
+- بهبود پاسخگویی شبکه تجاری و کارایی عملیاتی
+- مدل های کسب و کار جدید و فرصت های خالق ارزش بسازید
+- سازمان آنها به طور رقابتی آینده نگر است
+
+در سالهای اولیه، بسیاری از برنامههای بلاک چین سازمانی بر روی زنجیرههای بلاک چین یا کنسرسیوم سازگار با اتریوم با مجوز خصوصی ساخته شدند. امروزه، به لطف پیشرفتهای فناوری که توان عملیاتی بیشتر، هزینه تراکنش کمتر و حفظ حریم خصوصی را ممکن میسازد، اکثر برنامههای کاربردی سازمانی که از فناوری اتریوم استفاده میکنند بر روی شبکه اصلی اتریوم یا روی
+
+زنجیره لایه 2
.
+
+
+
+
+## منابع {#enterprise-resources}
+
+
+
+### بیشتر بخوانید {#further-reading}
+
+منابع غیر فنی برای درک اینکه چگونه کسب و کارها می توانند از اتریوم بهره ببرند
+
+- [چرا بلاک چین برای تجارت و بیزینس مفید است؟](https://entethalliance.org/why-are-blockchains-useful-for-business/) - _ در خصوص ارزش بلاک چینها از طریق لنز پیشبینیپذیری بحث کنید_
+- [گزارش آمادگی تجاری سال 2023 اتحادیه اتریوم](https://entethalliance.org/eea-ethereum-business-readiness-report-2023/) - _پتانسیل و قابلیتهای اتریوم عمومی و اکوسیستم گستردهتر اتریوم برای کسبوکارها را بررسی میکند._
+- [_اتریوم برای کسب و کار_ نوشته پل برادی](https://www.uapress.com/product/ethereum-for-business/)، _یک راهنمای ساده به زبان انگلیسی برای موارد کاربردی است که بازدهی از مدیریت دارایی تا پرداختها و زنجیرههای تأمین را ایجاد میکند._
+
+
+
+### سازمانها {#organizations}
+
+برخی تلاشهای مشترک برای مورد پسند کردن اتریوم سازمانی توسط سازمانهای مختلف انجام شده است
+
+- [اتحادیه اتریوم برای کسبوکارها](https://entethalliance.org/) - اتحادیه اتریوم (EEA) به سازمانها کمک میکند تا فناوری اتریوم را در عملیات روزانه کسبوکار خود انتخاب و استفاده کنند. هدف آن، تسریع کسب و کار اتریوم از طریق پشتیبانی حرفهای و تجاری، حمایت و ترویج، تحقیقات، توسعه استانداردها و خدمات اعتماد اکوسیستم است.
+- [شورای جهانی تجارت بلاکچین (GBBC)](https://www.gbbc.io/) - اتحادیهای صنعتی برای اکوسیستم فناوری بلاکچین است. با جلب توجه سیاستگذاران و نظارتکنندگان، برگزاری رویدادها و بحثهای گسترده، و انجام تحقیقات، GBBC به ترویج بیشتر بلاکچین برای ایجاد جوامعی امنتر، عادلانهتر و کارآمدتر متعهد است.
+
+
+
+
+## منابع توسعه دهنده سازمانی {#enterprise-developer-resources}
+
+
+
+### محصولات و خدمات {#products-and-services}
+
+- [4EVERLAND](https://www.4everland.org/) - _ خدمات RPC و APIها و ابزارهایی را برای میزبانی برنامههای غیرمتمرکز و فعال کردن ذخیرهسازی غیرمتمرکز در اتریوم ارائه میدهد_
+- [Alchemy](https://www.alchemy.com/) - _خدمات و ابزارهای API را برای ساخت و نظارت بر برنامههای کاربردی در اتریوم ارائه میکند_
+- [Blast](https://blastapi.io/) - _یک پلتفرم API که APIهای RPC/WSS را برای شبکه اصلی بایگانی اتریوم و شبکههای آزمایشی فراهم میکند._
+- [Blockapps](https://blockapps.net/) - _اجرای پروتکل اتریوم سازمانی، ابزار و APIهایی که پلتفرم STRATO را تشکیل می دهند._
+- [Chainstack](https://chainstack.com/) - _شبکه اصلی و شبکه آزمایشی زیرساخت اتریوم که در ابرهای عمومی & مجزای مشتریان میزبانی میشود._
+- [ConsenSys](https://consensys.io/) - _طیف وسیعی از محصولات و ابزارها را برای ساخت بر روی اتریوم و همچنین خدمات مشاوره و توسعه سفارشی ارائه می کند._
+- [Crossmint](http://crossmint.com/) _پلتفرم توسعه Web3 درجه سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از APIها برای ایجاد، توزیع، فروش، ذخیره و ویرایش NFTها._
+- [Envision Blockchain](https://envisionblockchain.com/) - _خدمات مشاوره و توسعه متمرکز بر سازمان را با تخصص در شبکه اصلی اتریوم ارائه می دهد_
+- [EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _با صدور RFQ، قراردادها، سفارشات خرید و فاکتورها در سراسر شبکه شرکای تجاری مورد اعتماد شما، گردش کار تدارکات را فراهم می کند._
+- [Hyperledger Besu](https://www.hyperledger.org/use/besu) - _یک مشتری منبع باز اتریوم متمرکز بر سازمان که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است_
+- [Infura](https://infura.io/) - _دسترسی API مقیاس پذیر به شبکه های اتریوم و IPFS_
+- [Kaleido](https://kaleido.io/) - _یک پلتفرم توسعه متمرکز بر سازمان که برنامه های کاربردی ساده شده بلاک چین و دارایی های دیجیتال را ارائه می دهد_
+- [NodeReal](https://nodereal.io/) - _ارائه دهنده زیرساخت مقیاسپذیر بلاکچین و خدمات API برای اکوسیستم Web3_
+- [Moralis](http://moralis.io/) - _گرهها و APIهای درجه سازمانی با گواهینامه SOC2 نوع 2_
+- [Provide](https://provide.services/) - _میانافزار دانش صفر برای کسبوکارها_
+- [QuickNode](https://www.quicknode.com/) - _ارائه دهنده نودهای قابل اعتماد و سریع با API های سطح بالا مانند API NFT، API Token و غیره، همچنین ارائه مجموعهای یکپارچه از محصولات و راهکارهای متناسب با شرکتها_
+- [Tenderly](https://tenderly.co) - _یک پلت فرم توسعه Web3 که اشکال زدایی، مشاهده پذیری و بلوک های ساختمان زیرساخت را برای توسعه، آزمایش، نظارت و اجرای قراردادهای هوشمند فراهم می کند_
+- [Unbright](https://unibright.io/) - _تیمی از متخصصان، معماران، توسعه دهندگان و مشاوران بلاک چین با بیش از 20 سال تجربه در فرآیندهای تجاری و یکپارچه سازی_
+- [Zeeve](https://www.zeeve.io/) - _مجموعه ای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساخت و API برای برنامه های Web3 سازمانی ارائه می دهد._
+
+
+
+### ابزار و کتابخانه ها {#tooling-and-libraries}
+
+- [Baseline Project](https://www.baseline-protocol.org/) - _مجموعه ای از ابزارها و کتابخانه ها است که به شرکت ها کمک می کند تا فرآیندهای تجاری پیچیده و چند جانبه و گردش کار را با حفظ حریم خصوصی هماهنگ کنند و در عین حال داده ها را در سیستم های ثبت مربوطه نگهداری کنند. این استاندارد دو یا چند ماشین حالت را قادر میسازد تا با استفاده از یک شبکه بهعنوان یک چارچوب مرجع مشترک، سازگاری دادهها و تداوم گردش کار را به دست آورند و حفظ کنند._
+- [Chainlens](https://www.chainlens.com/) - _SaaS و پلتفرم داده و تجزیه و تحلیل بلاک چین اولیه از آزمایشگاههای Web3_
+- [Ernst & Young's 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _برنامه ای برای انتقال برنامه های ERC20، ERC721 و ERC1155 با دانش صفر، با استفاده از یک جمعبندی خوش بینانه_
+- [Truffle Suite](https://trufflesuite.com) - _مجموعه توسعه بلاک چین (ترافل، گاناش، دریزل)_
+
+
+
+### راه حل های مقیاس پذیری {#scalability-solutions}
+
+اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/لایه دوم) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
+
+
+
+## برنامههای کاربردی سازمانی در شبکه اصلی اتریوم فعال میشوند {#enterprise-live-on-mainnet}
+
+در اینجا برخی از برنامههای کاربردی سازمانی که بر روی شبکه عمومی اتریوم و لایه دوم توسط شرکتهای سنتی غیربلاک چین ساخته شدهاند، آورده شده است.
+
+
+
+### پرداختها {#payments}
+
+- [مرورگر بریو (Brave)](https://basicattentiontoken.org/) - _به کاربران برای توجه آنها به تبلیغات، بیسیک اتنشن توکن (BAT) پرداخت میکند و کاربران نیز میتوانند از طریق BAT برای حمایت از ناشران پرداخت انجام دهند_
+- [شهر لوگانو، سوئیس](https://bitcoinsuisse.com/news/city-of-lugano-accepts-crypto-payments) - _پرداخت مالیات و سایر خدمات شهری_
+- [اتریوم ادز](https://ethereumads.com/) - _به اپراتورهای وبسایت اجازه میدهد فضای تبلیغاتی را بفروشند و از طریق اتریوم پول دریافت کنند_
+- [hCaptcha](https://www.hcaptcha.com/) - _سیستم CAPTCHA پیشگیری از ربات که به اپراتورهای وبسایت برای کارهای انجام شده توسط کاربران برای برچسب زدن دادهها برای یادگیری ماشین پرداخت میکند. اکنون توسط Cloudflare مستقر شده است_
+- [Opera MiniPay](https://www.opera.com/products/minipay) - _پرداختهای موبایلی را برای مردم آفریقا از طریق کیف پول غیرسرپرستی در دسترستر و ایمنتر میکند و از شماره تلفنها برای تراکنش آسان_ استفاده میکند
+- [Roxpay ](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
+- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p /13560384) - _پرداختهای بین المللی با استیبل کوین_
+- [Toku](https://www.toku.com/) - _دستمزد، مدیریت کمک هزینه توکنی، رعایت مالیات، استخدام محلی، مزایا و & راهحلهای منابع انسانی توزیع شده_
+- [Xerof](https://www.xerof.com/) - _پرداختهای سریع و ارزان بینالمللی (برون مرزی) B2B را تسهیل میکند_
+
+
+
+### امور مالی {#finance}
+
+- [ABN AMRO](https://tokeny.com/tokeny-fuels-abn-amro-bank-in-tokenizing-green-bonds-on-polygon/) - _با توکنی، مسیرهای سبز توکن شده_
+- [Crowdz](https://crowdz.io/) - _پلتفرم امور مالی و فاکتورهای دریافتنیها_
+- [Mata Capital](https://consensys.io/blockchain-use-cases/finance/mata-capital) - _توکنسازی سرمایهگذاری در املاک و مستغلات_
+- [Obligate](https://www.obligate.com/) - _ اوراق قرضه زنجیرهای و اوراق تجاری تحت نظارت و احراز هویت_
+- [زیمنس](https://press.siemens.com/global/en/pressrelease/siemens-issues-first-digital-bond-blockchain) - _ صدور مسیر_
+- [سیلا](https://silamoney.com/) - _بانکداری و پرداختهای ACH به عنوان سرویس، با استفاده از یک استیبل کوین_
+- [Societe Generale FORGE](https://www.sgforge.com/product/bonds/) - _صدور مسیر_
+- [Taurus](https://www.taurushq.com/) - _ضمانتهای توکن شده صادر میکند_
+
+
+
+### توکنیزه کردن دارایی {#tokenization}
+
+- [AgroToken](https://agrotoken.io/en/) - _توکنسازی و معامله کالاهای کشاورزی_
+- [بیت باند (Bitbond)](https://www.bitbond.com/) - _صدور، تسویه و نگهداری داراییهای مالی را با توکنسازی بهبود میبخشد_
+- [بلاک اسکوئر (Blocksquare)](https://blocksquare.io/) - _زیرساخت توکنسازی برای املاک و مستغلات_
+- [سانتریفیوژ (Centrifuge)](https://centrifuge.io/) - _تامین مالی، بدهی و داراییهای دریافتنیهای توکن شده_
+- [کلیرمتیک (Clearmatics)](https://www.clearmatics.com) - _پلتفرمهای شبکه غیرمتمرکز را برای مبادله همتا به همتای ارزش توکن میسازد_
+- [dClimate](https://www.dclimate.net/) - _اکوسیستم اطلاعات آب و هوایی غیرمتمرکز_
+- [Fabrica](https://www.fabrica.land/) - _پلتفرمی برای دیجیتالی کردن داراییهای املاک و مستغلات، وامگیری دیفای و معامله دارایی_
+- [Fasset](https://www.fasset.com/) - _پلتفرمی برای پشتیبانی از زیرساختهای پایدار_
+- [نوری](https://nori.com/) - _زیرساخت بازار منبع باز برای امکان اندازهگیری و کسب درآمد از فعالیتهای پروژههای حذف کربن_
+- [پراپی (Propy)](https://propy.com/) - _پلتفرمی برای خودکارسازی معاملات املاک مسکونی با قراردادهای هوشمند_
+- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند. _
+- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد em>
+
+ - [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات< /em>
+
+ - [تالو (Thallo)](https://www.thallo.io/) - _پلتفرمی برای ادغام اعتبارات کربن دیجیتال در معاملات تجاری_
+- [Tokenchampions](https://tokenchampions.com/) - _حقوق تصویر بازیکنان فوتبال اروپا را توکنیزه میکند_
+
+
+
+### ثبت دادهها {#notarization-of-data}
+
+- [ ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _خبرگزاری ایتالیایی با اخبار جعلی مبارزه میکند و خوانندگان را قادر میسازد تا منشأ اخبار را با ضبط آنها در شبکه اصلی تأیید کنند_
+- [Breitling](https://www.coindesk.com/breitling-arianee-all-new-watches-ethereum) - _منشأ و تاریخچه تعمیر را در اتریوم ثبت میکند_
+- [BRØK](https://www.xn--brk-1na.no/) - _پلتفرم جداول کپ برای شرکتهای ثبت نشده در بورس عمومی توسط دولت نروژ ارائه شده است _
+- [گواهی](https://certifaction.com/) - _امضاهای الکترونیکی معتبر قانونی با حریم خصوصی-by-design_
+- [EthSign](https://ethsign.xyz/) - _اسناد الکترونیکی امضا شده را در بلاکچین اتریوم ثبت میکند_
+- [Stacktical](https://stacktical.com/) - _توسعه نرمافزار، صدور و امضای دیجیتالی قراردادهای سطح سرویس (SLA) را با قابلیتهای بومی فعال میکند_
+- [وریزون](https://decrypt.co/46745/verizon-news-press-releases-ethereum-full-transparency) - _گزارشهای مطبوعاتی را در اتریوم برای اطمینان از مسئولیت پذیری و اعتماد شرکت نشان میدهد_
+- [ولف تون](https://www.mef.net/edge-view-blog/automated-secure-timely-sla-reporting-is-finally-a-reality/) - _توسط MEF و مدیریت Sage گزارشدهی توافقنامه سطح خدمات بین شرکتهای مخابراتی را خودکار میکند_
+
+
+
+### زنجیره تامین {#supply-chain}
+
+- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using -ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
+- [کارگوایکس](https://cargox.io/) - _ارائهدهنده بارنامه الکترونیکی و انتقال اسناد برای حمل و نقل_
+- [Circularize](https://www.circularise.com/) - _یک راهحل ردیابی سرتاسر برای مواد خام ساخته شده در محصولات است_
+- [مدیر قرارداد EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _شرکتها را قادر میسازد تا در جریان کاری تدارکات، صدور RFQ، قراردادها، سفارشها خرید و فاکتورها در شبکهای از شرکای تجاری شرکت کنند_
+- [ماین اسپایدر](https://www.minespider.com/) - _ردیابی و منشأ زنجیره تامین و ردیابی انتشار CO2_
+- [Morpheus.network](https://morpheus.network/) - _پلتفرم اتوماسیون زنجیره تامین_
+- [StaTwig](https://statwig.com/) - _عملیات زنجیره تامین_
+- [TradeTrust](https://www.tradetrust.io/) - _بارنامههای الکترونیکی (eBLs) را برای حمل و نقل بین المللی تأیید میکند_
+- [Transmute](https://transmute.industries/) - _پلتفرم تبادل داده برای معامله جهانی؛ از تراکنشهای با هویت غیرمتمرکز در اتریوم_ پشتیبانی میکند
+
+
+
+### بیمه {#insurance}
+
+- [آربول (Arbol)](https://www.arbolmarket.com/) - _بیمه پارمتریک برای پوشش خطرات مربوط به آب و هوا_
+- [Etherisc](https://etherisc.com/) - _بیمه غیرمتمرکز برای انواع خطرات_
+- [Nayms](https://www.nayms.com/) - _یک فضای دیجیتال برای ایجاد برنامههای بیمه، افزایش و معامله سرمایه، نوشتن ریسک و ریلهای پرداخت برای تراکنشهای حق بیمه و ادعا، ساخته شده با AON_
+
+
+
+### هویت، اعتبار و گواهینامه {#credentials}
+
+- [BCdiploma](https://www.bcdiploma.com/) - _دیپلمها، گواهیها و مدارک خرد را دیجیتالی و تأیید میکند_
+- [مدارک هایلند](https://www.hylandcredentials.com) - _دیپلمهای دیجیتال و سایر مدارک تحصیلی، مجوزها و گواهینامهها_
+- [برنامه اقامت دیجیتال پالائو](https://rns.id/) - _به شهروندان جهانی این امکان را میدهد که کارت شناسایی قانونی صادر شده توسط دولت پالائو داشته باشند em>
+
+ - [Spherity](https://www.spherity.com/) - _راهحلهای مدیریت هویت دیجیتال را برای ایجاد اعتماد دیجیتال در اکوسیستمها، با تمرکز بر هویتهای غیرمتمرکز و اعتبار قابل تأیید ارائه میدهد_
+- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
+
+
+
+### سرگرمی، NFT و وفاداری
+
+- [چرخ دنده مجازی آدیداس (Adidas Virtual Gear)](https://www.adidas.com/metaverse) - _مجموعه NFT چرخ دنده مجازی_
+- [سندباکس موزه بریتانیا](https://decrypt.co/150405/british-museum-enter-metaverse-via-sandbox) - _یک مجموعه توکن غیرقابل تعویض_
+- [Fruitlab](https://fruitlab.com/) - _پلتفرمی برای گیمرها برای کسب درآمد از تماشا، اشتراکگذاری و بازیهای آنلاین_
+- [Nike Swoosh](https://www.swoosh.nike/) - _یک پلتفرم انافتی_
+- [متاورس سوثبیز](https://metaverse.sothebys.com/) - _یک بازار دیجیتال هنر NFT توسط Sothebyها_
+
+اگر میخواهید به این فهرست اضافه کنید، لطفاً به [دستورالعملهای مشارکت](/contributing/) مراجعه کنید.
diff --git a/public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md b/public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md
new file mode 100644
index 00000000000..5992f822f04
--- /dev/null
+++ b/public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md
@@ -0,0 +1,26 @@
+---
+title: اتریوم خصوصی برای تشکیلات سازمانی
+description: منابعی برای اپلیکیشن تشکیلات سازمانی بر بستر بلاک چین های خصوصی اتریوم.
+lang: fa
+---
+
+# اتریوم خصوصی برای تشکیلات سازمانی {#private-ethereum-for-enterprise}
+
+اپلیکیشن های بلاک چین تشکیلات سازمانی میتوانند بر روی شبکه اصلی اتریوم بدون مجوز عمومی یا بر روی بلاک چین های خصوصی که مبتنی بر فناوری اتریوم هستند ساخته شوند. برای اطلاعات بیشتر در مورد ساخت اپلیکیشن بر بستر شبکه عمومی اصلی اتریوم، به [شبکه اصلی اتریوم برای شرکتها](/enterprise/) مراجعه کنید.
+
+## منابع توسعه دهندگان برای تشکیلات سازمانی اتریوم {#developer-resources-private-enterprise-ethereum}
+
+### سازمانها {#organisations}
+
+برخی از تلاشهای مشترک برای مورد پسند کردن تشکیلات سازمانی اتریوم توسط سازمانهای مختلف انجام شده است:
+
+- [اتحادیه تشکیلات سازمانی اتریوم](https://entethalliance.org/) EEA سازمانها را قادر میسازد تا فناوری اتریوم را در عملیات تجاری روزانه خود بپذیرند و از آن استفاده کنند. ما اکوسیستم اتریوم را برای ایجاد فرصتهای تجاری جدید، تشویق به پذیرش صنعت، و یادگیری و همکاری با یکدیگر توانمند میکنیم.
+- [Hyperledger](https://hyperledger.org) _Hyperledger یک تلاش مشترک منبع باز است که برای پیشرفت فناوریهای بلاک چین بینصنعتی ایجاد شده است. این یک همکاری جهانی است که توسط بنیاد لینوکس میزبانی می شود، از جمله رهبران امور مالی، بانکداری، اینترنت اشیا، زنجیره تامین، تولید و فناوری. این بنیاد پروژههایی در خود دارد که با پشته اتریوم کار میکنند، از جمله [Besu](https://www.hyperledger.org/use/besu)._
+
+### پروتکل و زیرساخت {#protocol-and-infrastructure}
+
+- [Chainstack](https://chainstack.com/) _پلتفرم میان ابری و چند پروتکلی بهعنوان سرویسی که به کسبوکارها اجازه میدهد تا به سرعت، استقرار و مدیریت شبکه ها و سرویس های غیرمتمرکز را ایجاد کنند_
+- [Clearmatics Autonity](https://www.clearmatics.com/about/) _مجموعه پروتکلهایی که پروتکلهای p2p را پیادهسازی میکند و اپلیکیشن و زیرساخت کلاینت را ارائه میکند_
+- [هایپرلجر بسو](https://www.hyperledger.org/use/besu) _کاربر منبع باز اتریوم که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است که شامل چندین الگوریتم اجماع از جمله اثبات کار و اثبات قدرت است (IBFT، IBFT 2.0، Ethash و Clique). طرح های مجوز جامع آن به طور خاص برای استفاده در یک محیط کنسرسیوم طراحی شده است._
+- [Kaleido](https://kaleido.io/) _پلتفرم فول-استک برای ساخت و اجرای اکوسیستمهای تشکیلات اقتصادی ترکیبی میان ابری_
+- [Zeeve](https://www.zeeve.io/) _مجموعهای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساختها و APIهای سازمانی برنامه های Web3 ارائه میکند_
diff --git a/public/content/translations/fa/26) Miscellaneous/foundation/index.md b/public/content/translations/fa/26) Miscellaneous/foundation/index.md
new file mode 100644
index 00000000000..f79f30dff9d
--- /dev/null
+++ b/public/content/translations/fa/26) Miscellaneous/foundation/index.md
@@ -0,0 +1,40 @@
+---
+title: بنیاد اتریوم
+description: درباره بنیاد اتریوم (EF) بیشتر بدانید که یک سازمان غیرانتفاعی است که وقف حمایت از اتریوم و فن آوری های مرتبط با آن است.
+hideEditButton: true
+lang: fa
+---
+
+# درباره بنیاد اتریوم {#about-the-ethereum-foundation}
+
+
+
+[بنیاد اتریوم](http://ethereum.foundation/)(EF) یک سازمان غیرانتفاعی است که وقف حمایت از [اتریوم](/what-is-ethereum/) و فن آوری های مرتبط با آن است.
+
+بنیاد اتریوم یک شرکت و یا حتی یک سازمان غیرانتفاعی سنتی نیست. نقش بنیاد، رهبری یا کنترل اتریوم نیست، و حتی بنیاد تنها نهادی نیست که به تامین مالی توسعه فن آوری های مرتبط با اتریوم میپردازد. بنیاد اتریوم بخشی از [اکوسیستمی](/community/) بسیار بزرگتر است.
+
+## ابتکارات بنیاد اتریوم {#ethereum-foundation-initiatives}
+
+### برنامه حمایت اکوسیستم {#ecosystem-support-program}
+
+[برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/) برای شتابدهی به رشد اکوسیستم، برای پروژه ها و افراد فعال در جامعه اتریوم حمایت مالی و غیر مالی فراهم میکند. برنامه پشتیبانی اکوسیستم نسخه ای گسترش داده شده از برنامه حمایت مالی اتریوم است که بر حمایت مالی از اکوسیستم تمرکز داشت.
+
+درباره برنامه پشتیبانی اتریوم، دریافت کنندگان قبلی پشتیبانی، و روند درخواست کمک هزینه در [esp.ethereum.foundation](https://esp.ethereum.foundation/) اطلاعات بیشتر دریافت کنید. همچنین برای آگاهی از آخرین اخبار و اطلاعیه ها میتوانید [ وبلاگ برنامه پشتیبانی اکوسیستم](https://blog.ethereum.org/category/ecosystem-support-program/) و یا [@EF_ESP](https://twitter.com/EF_ESP) را دنبال کنید.
+
+### Devcon {#devcon}
+
+از سال 2014، بنیاد اتریوم کنفرانس سالانه دِوکان، را برای تمام توسعه دهندگان، محققان، اندیشمندان و سازندگان اکوسیستم اتریوم برگزار میکند.
+
+شما میتوانید در [archive.devcon.org](https://archive.devcon.org/) به تمام محتوای ویدیویی مطالب ارائه شده در هر کنفرانس از زمان پیدایش آن دسترسی پیدا کنید.
+
+برای اطلاعات بیشتر، نگاه کنید به [devcon.org](https://devcon.org/)، و نگاهی به [وبلاگ دِوکان](https://devcon.org/en/blogs/) بیندازید، یا برای اخرین اطلاعیه ها، صفحه[@efdevcon](https://twitter.com/EFDevcon) را دنبال کنید.
+
+### برنامه فلوشیپ {#fellowship-program}
+
+[برنامه فلوشیپ بنیاد اتریوم](https://fellowship.ethereum.foundation/) ابتکاری است برای از بین بردن شکاف بین فرهنگ ها، ملت ها و طبقات اقتصادی مختلف. برنامه فلوشیپ بنیاد اتریوم با شناسایی و حمایت از افراد منحصر به فرد و بااستعداد باعث کوچک کردن این شکاف طبقاتی میشود، و موانع ورود برای افراد و جوامعی را که نمایندگان کمتری دارند که آینده Web3 را بسازند، از بین میبرد.
+
+[در fellowship.ethereum.foundation مطالب بیشتر را ببینید](https://fellowship.ethereum.foundation/).
+
+
+
+برای اطلاع بیشتر در مورد بنیاد و حوزه کاری آن، سایت [ethereum.foundation](http://ethereum.foundation/) را ببینید، و یا سری به [وبلاگ بنیاد اتریوم](https://blog.ethereum.org/) بزنید تا از اخرین اخبار بنیاد آگاه شوید.
diff --git a/public/content/translations/fa/27) Contributing/contributing/design-principles/index.md b/public/content/translations/fa/27) Contributing/contributing/design-principles/index.md
new file mode 100644
index 00000000000..3c406e6ae09
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/design-principles/index.md
@@ -0,0 +1,93 @@
+---
+title: اصول طراحی
+lang: fa
+description: اصول طراحی ethereum.org و تصمیم گیری های محتوایی
+---
+
+# اصول طراحی ما {#contributing-to-ethereumorg-}
+
+ سلام، به اصول طراحی برای ethereum.org خوش آمدید. این بخشی از یک فرآیند مداوم برای تکامل و بهبود ethereum.org است.
+
+اصول ما، ظاهر و حس سایت و محتوایی که در آن وجود دارد را مشخص می کند.
+
+پیش از [عضویت در ethereum.org](/contributing/) باید این موارد را مطالعه کنید.
+
+## اصول طراحی چیست؟ {#ways-to-contribute}
+
+نگران نباشید، خیلی ساده اند! **اصول طراحی** مجموعه ای از دستورالعمل هایی هستند که ما در هنگام طراحی (یعنی ایجاد، حفظ یا به روز رسانی) چیزی به آن ها استناد می کنیم.
+
+در زمینه ethereum.org، این اصول طراحی پایه و اساس چیزی است که میخواهیم وبسایت نشان دهد و به جهان ارائه دهد. آن ها هم آرمانی هستند **و** هم کاربردی. این تنها _ظاهر_ وب سایت نیست، بلکه نحوه _کارکرد_ و حتی _احساسی_ است که در فرد ایجاد می کند. همه چیز، از رنگ ها گرفته تا چیدمان صفحه و نحوه صحبت درباره اتریوم در وب سایت باید با این اصول ارائه شود.
+
+## اصول در عمل {#how-decisions-about-the-site-are-made}
+
+به مثال زیر توجه کنید. یکی از این اصول "اعتبار" است، به این معنی که ما می خواهیم بازدیدکنندگان سایت _احساس کنند_ و _بدانند_ که سایت قابل اعتماد است - درست مانند اکوسیستم گستردهتر اتریوم. در این اصل، ما 3 "زیر اصول" کاربردی داریم که معتقدیم گام های عملی هستند که می توانیم برای معتبر کردن سایت برداریم:
+
+- _"تازه"_ یعنی محتوا را به روز نگه دارید.
+- _"اثبات اجتماعی"_ یعنی نشان دادن اندازه، تنوع و فعالیت اکوسیستم (میدانید: پیشرفت ارتقا اتریوم، دیفای (DeFi)، بازی، تمام هکاتون ها و...)
+- _"سازگار"_ یعنی ثبات در طراحی سایت و لحن و درستی نگارش.
+
+بنابراین هنگامی که ما در حال تصمیم گیری در مورد طراحی، یا تصمیم گیری در مورد کپی رایت هستیم، می توانیم به اصل "اعتبار" اشاره کنیم و بپرسیم:
+
+- _"آیا این سایت اطلاعات بهروز شده را منعکس می کند؟"_
+- _"ما چگونه و در کجا اندازه و فعالیت اکوسیستم را نشان می دهیم؟"_
+- _"آیا طرح های پیشنهادی جدید یکی از اعضای جامعه که در حال بررسی آن ها هستم، با طرح فعلی و نوشته های موجود در سایت همخوانی دارد؟"_
+
+## اصول طراحی ethereum.org {#contributors}
+
+### 1. الهام بخش {#1-inspirational}
+
+سایت باید الهام بخش کاربران باشد تا ببینند اتریوم چگونه می تواند دنیا را تغییر دهد. باید افراد را به اکتشاف، بازی و سرهم بندی با ابزارها و برنامه های اکوسیستم اتریوم ترغیب کند.
+
+- **رادیکال**: این سایت باید اهداف بلندپروازانه اتریوم را برای تغییر عمده جهان بیان کند. باید واضح باشد که Ethereum تنها یک دسته فن آوری جدید نیست - بلکه یک فن آوری تحول آفرین است.
+- **توانمندسازی از طریق آموزش:** سایت باید افراد را آموزش دهد تا بتوانند پتانسیل اتریوم را درک کنند، جایگاه خود را در اکوسیستم پیدا کنند و برای مشارکت در آن احساس قدرت کنند.
+
+هدایت بصری • محتوا
+
+### 2. جهانی {#2-universal}
+
+اتریوم یک پروژه جهانی و غیر متمرکز است و مخاطبان ما این موضوع را منعکس می کنند. سایت باید این دورنما را داشته باشد که برای همه قابل دسترس باشد و نسبت به بسیاری از فرهنگ های جهان حساس باشد.
+
+- **دسترسی پذیر:** سایت باید از دستورالعمل های دسترسی - از جمله برای افرادی که اتصالات با پهنای باند پایین دارند - پیروی کند.
+- **ساده و سرراست:** سایت باید ساده و بدون ابهام باشد. متن نباید از زبانی استفاده کند که ممکن است در ترجمه اشتباه تعبیر شود یا گم شود.
+- **اتریوم چند وجهی است:** اتریوم یک پروژه، یک مجموعه کد، یک جامعه و یک چشم انداز است. اتریوم به دلایل مختلف برای افراد مختلف ارزشمند است و راه های زیادی برای مشارکت در آن وجود دارد.
+
+سیستم های نوشتاری • استفاده از رنگ • هدایت بصری • محتوا
+
+### 3. یک داستان خوب {#3-a-good-story}
+
+وب سایت باید مانند یک داستان خوب عمل کند. بازدیدکنندگان در یک سفر هستند و محتوایی که ارائه می دهید بخشی از آن است. مشارکت های شما باید در یک روایت روشن قرار گیرند: روایتی با یک آغاز (نقطه ورود / مقدمه)، میانی (مجموعه ای از آموخته ها و بینش ها)، و پایانی (پیوند(ها) به منابع مرتبط، یا مراحل بعدی).
+
+- **سلسله مراتبی**: یک معماری اطلاعاتی واضح و سلسله مراتبی به بازدیدکنندگان سایت ethereum.org کمک می کند تا سایت را "به عنوان یک داستان" در مسیر رسیدن به اهداف خود دنبال کنند.
+- **سنگ محک:** ما سنگ محک برای هر کسی هستیم که به دنبال پاسخ است. ما نمی خواهیم جایگزین بسیاری از منابعی شویم که در حال حاضر وجود دارند. ما پاسخ میدهیم & گامهای بعدی قابلاطمینان را ارائه میدهیم.
+
+سفرهای کاربر • محتوا
+
+### 4. اعتبار {#4-credible}
+
+افراد ممکن است به دنبال معرفی خود به اکوسیستم اتریوم باشند یا ممکن است شکاک باشند. این مسئولیت را در نحوه برقراری ارتباط بپذیرید. اطمینان حاصل کنید که هر دو با اطمینان بیشتری از اکوسیستم اتریوم خارج می شوند.
+
+- **تازه:** همیشه به روز.
+- **اثبات اجتماعی:** نشان دادن اندازه، تنوع و فعالیت اکوسیستم.
+- **سازگار:** ثبات در طراحی و محتوا اعتبار را نشان میدهد.
+
+هدایت بصری • محتوا
+
+### 5. بهبود مشارکتی {#5-collaborative-improvement}
+
+وب سایت حاصل کار بسیاری از مشارکت کنندگان است، درست مانند اکوسیستم به عنوان یک کل.
+
+- **باز:** شفافیت کد منبع، فرآیندها و پروژهها را در سراسر اکوسیستم جشن می گیریم.
+- **قابل توسعه:** مدولار بودن یک تمرکز کلیدی در پشت هر کاری است که انجام میدهیم، بنابراین مشارکتها نیز باید ماژولار باشند. طراحی اصلی، کد جزء& و اجرای سایت باید امکان توسعه آسان آن را در آینده فراهم کند.
+- **تجربی:** ما دائماً در حال آزمایش، تست و تکرار هستیم.
+- ** مشارکتی:** این پروژه همه ما را گرد هم می آورد.
+- **پایدار:** آمادهسازی برای نگهداری طولانی مدت توسط جامعه
+
+شما می توانید اصول طراحی ما را در عمل [در سایت ما](/) ببینید.
+
+## بازخورد بدهید {#give-feedback}
+
+**نظرات خود را در مورد این سند با ما در میان بگذارید!** یکی از اصول پیشنهادی ما "**بهبود مشارکتی**" است، به این معنی که ما می خواهیم وب سایت، محصول بسیاری از مشارکت کنندگان باشد. بنابراین باتوجه به این اصل، می خواهیم این اصول طراحی را با جامعه اتریوم به اشتراک بگذاریم.
+
+در حالی که این اصول روی وب سایت ethereum.org متمرکز شده اند، امیدواریم که بسیاری از آن ها نماینده ارزش های کلی اکوسیستم اتریوم باشند (به عنوان مثال می توانید تاثیر [اصول وایتپیپر اتریوم](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy) را ببینید). شاید حتی بخواهید برخی از آن ها را در پروژه خود بگنجانید!
+
+نظرات خود را از طریق [سرور Discord](https://discord.gg/ethereum-org) یا به وسیله [ایجاد یک مسئله](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) با ما در میان بگذارید.
diff --git a/public/content/translations/fa/27) Contributing/contributing/design/index.md b/public/content/translations/fa/27) Contributing/contributing/design/index.md
new file mode 100644
index 00000000000..34fc9131d43
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/design/index.md
@@ -0,0 +1,77 @@
+---
+title: همکاری در طراحی
+description: همکاری طراحی با ethereum.org
+lang: fa
+---
+
+# همکاری طراحی با ethereum.org {#design-contributions}
+
+طراحی، یک بخش حیاتی هر پروژه است، و با اختصاص دادن زمان و مهارتهای طراحیتان به ethereum.org میتوانید به بهتر شدن تجربه کاربری بازدیدکنندگان ما کمک کنید. مشارکت در یک پروژه منبع باز فرصتی را برای کسب تجربه مرتبط و توسعه مهارت های خود در یک محیط مشارکتی فراهم می کند. شما این شانس را خواهید داشت که با دیگر طراحان، توسعه دهندگان و اعضای جامعه کار کنید، که همگی دیدگاه ها و بینش های منحصر به فرد خود را خواهند داشت.
+
+در نهایت، این یک راه عالی برای ایجاد یک نمونه کار متنوع و چشمگیر است که مهارت های طراحی شما را به نمایش می گذارد.
+
+## روش مشارکت؟
+
+### در مورد نمونه های اولیه طراحی بازخورد بدهید {#design-critique}
+
+ما گاهی برای آزمایش ایده های خام خود به کمک نیاز داریم. این یک راه عالی برای مشارکت بدون هیچ دانش فنی است.
+
+1. تیم طراحی یک طرح ماکت را در [Discord](https://discord.com/invite/ethereum-org) و در [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) به اشتراک خواهد گذاشت.
+2. برای ارائه بازخورد از طریق عملکرد نظرات، از طریق طرح ها راهنمایی خواهید شد.
+3. نتیجه در مسئله گیتهاب به اشتراک گذاشته می شود و سپس توسط تیم بسته می شود.
+
+### در تحقیقات نظرسنجی شرکت کنید {#answer-surveys}
+
+به این روشها در وب سایت ما بازخورد ارائه کنید:
+
+1. بازدید از ethereum.org و خواندن صفحات.
+2. کلیک بر روی ویجت بازخورد در گوشه سمت راست پایین و پاسخ به سوالات مربوط به طراحی و محتوا.
+3. روی سوالات با فرمت آزاد تمرکز کنید.
+
+### مسائل مربوط به طراحی را در وب سایت بیابید و گزارش دهید {#report-design-issues}
+
+Ethereum.org وبسایتی است با ویژگیها و محتوای زیاد که سریع در حال رشد است. برخی از UIها به راحتی می توانند منسوخ شوند یا می توانند بهبود یابند. اگر با چنین موردی مواجه شدید، لطفا گزارش دهید تا توجه ما را به خود جلب کند.
+
+1. وب سایت را مرور کنید و به طراحی آن توجه کنید.
+2. در صورت مشاهده هر گونه مشکل بصری یا UX، اسکرین شات بگیرید و یادداشت کنید.
+3. مشکلات پیدا شده را با استفاده از [گزارش باگ](https://github.com/ethereum/ethereum-org-website/issues/new/choose) گزارش دهید.
+
+### تغییرات طراحی را پیشنهاد بدهید {#propose-design-changes}
+
+اگر در چالشهای طراحی احساس راحتی میکنید، میتوانید از صفحه مسائل گیتهاب ما دیدن کنید و [مسائل مرتبط با طراحی](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) را فیلتر کنید.
+
+1. وب سایت ما را مرور کنید و به طراحی آن توجه کنید یا به مخزن گیتهاب ما بروید و مسائل دارای علامت [“Design required”](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) را بررسی کنید.
+2. در مورد راه حل ایده بگیرید و آن را طراحی کنید. (در حالت ایده آل از [سیستم طراحی](https://www.figma.com/community/file/1134414495420383395) ما استفاده کنید).
+3. راه حل را در مسئله مربوطه پیشنهاد دهید یا [یک راه حل جدید ایجاد کنید.](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)
+4. منتظر بررسی تیم طراحی باشید.
+
+### سیستم طراحی را با هم بسازیم {#Contribute-to-design-system}
+
+سیستم طراحی ما طراحی ethereum.org را سرگرم کننده و آسان می کند. اگر شما یک طراح با تجربه هستید، می توانید به ما در تهیه بسیاری از اجزای وب سایت کمک کنید.
+
+1. مشکلی را برای کار از [برد سیستم طراحی](https://github.com/ethereum/ethereum-org-website/labels/design%20system) در GitHub انتخاب کنید یا یک مورد جدید ایجاد کنید.
+2. درخواست کنید موضوع انتخاب شده به شما اختصاص داده شود.
+3. طراحی قطعه درخواست شده در فیگما را آغاز کنید.
+4. پس از نیاز به بررسی یا راهنمایی، آن را با تیم طراحی در گیتهاب به اشتراک بگذارید.
+5. تیم طراحی بررسی خواهد کرد.
+6. تیم طراحی، تغییرات را در فایل اصلی خواهد گنجاند و فایل را برای جامعه منتشر خواهد کرد.
+
+### مطالب مرتبط با طراحی را در وب سایت بنویسید {#write-design-articles}
+
+جامعه توسعه دهندگان اتریوم قوی است، اما جامعه طراحی کمی عقبتر است. اگر شما یک طراح با دانش Web3 هستید، لطفاً در نظر داشته باشید که آموخته های خود را با جامعه بزرگتر به اشتراک بگذارید تا همه با هم رشد و پیشرفت کنیم. ما [صفحه ای برای طراحی اتریوم داریم](/developers/docs/design-and-ux/) که می توانید در آن مشارکت کنید. همچنین میتوانید [خطمشیهای لیستینگ](/contributing/design/adding-design-resources) ما را بررسی کنید.
+
+1. در مورد موضوعات طراحی که باید در ethereum.org پوشش داده شود و برای طراحان در فضا میتوانند مفید باشند، فکر کنید.
+2. به مخزن گیتهاب ما بروید و [مسئلهای را مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new) که یک موضوع را پیشنهاد میدهد (فعلا محتوا را ننویسید).
+3. منتظر تایید تیم طراحی باشید.
+4. پس از تایید، محتوا را بنویسید.
+5. آن را در مسئله گیتهاب مربوطه ارائه کنید.
+
+### تصاویر جدید بکشید {#prepare-illustrations}
+
+تصویرسازیها یکی از قدرتمندترین ابزارها برای توضیح موضوعات انتزاعی هستند. با افزودن نمودارها و اینفوگرافیک ها پتانسیل بسیار زیادی وجود دارد. به هر حال، یک تصویر می تواند هزاران کلمه را بیان کند.
+
+1. به وبسایت ما بروید و صفحاتی را ببینید که در آنها میتوان اینفوگرافیکهای جدید اضافه کرد.
+2. مطمئن شوید که سبک تصویر با [داراییهای](/assets/) ما مطابقت دارد.
+3. به مخزن گیتهاب ما بروید و در مورد ارائه تصویر [یک مسئله مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new).
+4. تیم طراحی آن را بررسی خواهد کرد.
+5. ما یک مسئله جدید ایجاد می کنیم تا از یک توسعه دهنده بخواهیم تصویر جدید را اجرا کند.
diff --git a/public/content/translations/fa/27) Contributing/contributing/index.md b/public/content/translations/fa/27) Contributing/contributing/index.md
new file mode 100644
index 00000000000..2dd47a1bc41
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/index.md
@@ -0,0 +1,117 @@
+---
+title: در حال مشارکت
+description: در مورد روش های مختلفی که می توانید به ethereum.org کمک کنید، بیاموزید
+lang: fa
+---
+
+# مشارکت در ethereum.org 🦄 {#contributing-to-ethereumorg}
+
+Ethereum.org یک پروژه اجرا شده منبع باز با **بیش از 12000** مشارکت کننده است که به ترجمه، نگارش، طراحی و نگهداری وبسایت کمک می کنند.
+
+ما از جامعهای استقبال میکنیم که به شما کمک میکند در اکوسیستم اتریوم رشد کرده و آموزش ببینید و در عین حال به طور معناداری مشارکت کنید و تجربیات عملی مرتبط را کسب کنید!
+
+## روش های مشارکت {#ways-to-contribute}
+
+**ترجمه**
+- [به برنامه ترجمه بپیوندید](/contributing/translation-program/) – به ما کمک کنید ethereum.org را به زبان های جدید ترجمه کنیم
+
+**توسعه**
+- [روی یک مسئله باز کار کنید](https://github.com/ethereum/ethereum-org-website/issues) - کاری که ما تشخیص داده ایم نیاز به انجام دارد
+
+**طراحی**
+- [کمک به طراحی وب سایت](/contributing/design/) طراحان همه سطوح می توانند به بهبود وب سایت کمک کنند
+
+**محتوا**
+- [ایجاد/ویرایش محتوا](/contributing/#how-to-update-content) - صفحات جدیدی پیشنهاد دهید یا تغییراتی را در آنچه قبلاً در اینجا وجود دارد ایجاد کنید
+- [افزودن منابع جامعه](/contributing/content-resources/) - یک مقاله یا منبع مفید را به صفحه مربوطه اضافه کنید
+- [یک منبع طراحی پیشنهاد کنید](/contributing/design/adding-design-resources/) – منابع طراحی مفید را اضافه کنید، بهروزرسانی کنید و حذف کنید
+- [افزودن اصطلاح به واژه نامه](/contributing/adding-glossary-terms/) – به ما در ادامه گسترش [واژه نامه](/glossary/) اتریوم کمک کنید
+- [آزمونها](/contributing/quizzes/) - بانکهای سوالات آزمون را برای صفحه مربوطه اضافه، بهروزرسانی و حذف کنید
+
+**ایده برای ویژگیها**
+- [درخواست یک ویژگی](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – در مورد هر ایده ای که برای یک ویژگی یا طراحی جدید دارید به ما اطلاع دهید
+
+**لیستینگ های محصول**
+- [افزودن صرافی](/contributing/adding-exchanges/) – افزودن صرافی به [صرافییاب](/get-eth/#country-picker) ما
+- [افزودن محصول](/contributing/adding-products/) - یک دپ (dapp) یا کیف پول به صفحه مربوطه اضافه کنید
+- [افزودن ابزارهای توسعه دهنده](/contributing/adding-developer-tools/) – یک ابزار توسعه دهنده را به صفحه مربوطه اضافه کنید
+- [افزودن یک لایه 2](/contributing/adding-layer-2s/) - یک لایه 2 را به صفحه مربوطه اضافه کنید
+- [افزودن یک محصول یا خدمات سهامگذاری](/contributing/adding-staking-products/) – پروژه ای اضافه کنید که به تسهیل سهامگذاری انفرادی، سهامگذاری ادغام شده، یا سهامگذاری به عنوان خدمات کمک می کند
+- [افزودن کیف پول](/contributing/adding-wallets/) – افزودن کیف پول برای [صفحه جستجوی کیف پول](/wallets/find-wallet/)
+- [پیشنهاد پروژه برای صفحه DeSci ما](/contributing/adding-desci-projects/) – اضافه کردن پروژه ای بر پایه اتریوم که به دانش غیرمتمرکز کمک می کند
+
+سوال دیگری دارید؟ 🤔 عضو [سرور دیسکورد](https://discord.gg/ethereum-org) ما شوید
+
+## اولین اقدامات خوب برای شروع مشارکت
+
+اینها چند کار جاری هستند که می توانید به ما در حل آنها کمک کنید و مسئولیت آنها را بپذیرید. برای اکثر آنها به حساب گیتهاب نیاز دارید زیرا اکثر تغییرات در وب سایت از طریق گیتهاب انجام می شود.
+
+
+
+مشاهده تمام کارها
+
+## چطور میتوان در ethereum.org کار کرد {#how-to-update-content}
+
+اگر میخواهید در [برنامه ترجمه](/contributing/translation-program/) مشارکت کنید، از شما میخواهیم یک حساب در [Crowdin](https://crowdin.com/project/ethereum-org) ایجاد کنید. برای هر چیز دیگر - اضافه کردن یا ویرایش محتوا یا تصاویر به وب سایت، رفع اشکالات، کار بر روی کارهای باز - به یک حساب [GitHub](https://github.com/) نیاز دارید.
+
+تمام به روز رسانی ها از طریق فرآیند PR مربوط به GitHub انجام می شود. این بدان معنی است که شما یک نسخه محلی از وب سایت ایجاد می کنید، تغییرات خود را ایجاد می کنید و درخواست می کنید تا تغییرات خود را ادغام کنید. اگر قبلاً این کار را نکردهاید، دستورالعملهای موجود در پایین [مخزن GitHub](https://github.com/ethereum/ethereum-org-website) ما را دنبال کنید.
+
+برای کار بر روی هر چیزی به اجازه نیاز ندارید، اما همیشه بهتر است به ما اطلاع دهید که قصد انجام چه کاری را دارید. روش انجام این کار:
+
+- اظهار نظر در مورد یک مسئله یا PR در [GitHub](https://github.com/ethereum/ethereum-org-website)
+- ارسال پیام در [سرور دیسکورد](https://discord.gg/ethereum-org) ما
+
+قبل از مشارکت، مطمئن شوید که با موارد زیر آشنا هستید:
+
+- [دیدگاه ethereum.org](/about/) در حال تکامل
+- [اصول طراحی](/contributing/design-principles/) ما
+- [راهنمای سبک](/contributing/style-guide/) ما
+- [آیین رفتاری](/community/code-of-conduct) ما
+
+
+
+## نحوه تصمیم گیری در مورد سایت {#how-decisions-about-the-site-are-made}
+
+تصمیم گیری در مورد روابط عمومی فردی، تکامل طراحی و ارتقاءهای عمده توسط تیمی از سراسر اکوسیستم اتریوم گرفته می شود. این تیم شامل مدیران پروژه، توسعه دهندگان، طراحان، بازاریابی و ارتباطات و کارشناسان موضوع است. ورودی جامعه، هر تصمیم را اطلاع می دهد: بنابراین لطفاً در مسائل سؤالات خود را مطرح کنید، PR ارسال کنید یا با تیم تماس بگیرید:
+
+- [website@ethereum.org](mailto:website@ethereum.org)
+- [@ethdotorg](https://twitter.com/ethdotorg)
+- [سرور دیسکورد](https://discord.gg/ethereum-org)
+
+### یادداشتی در مورد سرقت ادبی {#plagiarism}
+
+هنگام مشارکت هر گونه محتوا یا محصول در ethereum.org فقط از اثر یا محتوای اصلی خود استفاده کنید که اجازه استفاده از آن را دارید. بسیاری از پروژههای موجود در اکوسیستم اتریوم از مجوز منبع باز استفاده میکنند که امکان اشتراکگذاری رایگان اطلاعات را فراهم میکند. با این حال، اگر نمی توانید این اطلاعات را پیدا کنید، سعی نکنید آن را به ethereum.org اضافه کنید. هر درخواست ادغام که به عنوان سرقت ادبی تلقی شود رد خواهد شد.
+
+## در فضای منبع باز تازه کار هستید؟ {#new-to-open-source}
+
+ما در مخزن GitHub خود موانع کمی برای ورود مسائل داریم که به طور خاص برای توسعه دهندگانی که به تازگی با منبع باز کار میکنند، با برچسب [اولین مسئله خوب](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) طراحی شده اند.
+
+## توکن موفقیت روی زنجیر (OAT) خود را مطالبه کنید {#oat}
+
+اگر مشارکت شما در ethereum.org ادغام شود، فرصتی برای مطالبه یک توکن ویژه در [Galxe](https://app.galxe.com/quest/ethereumorg) خواهید داشت. توکن OAT دلیلی بر این است که شما کمک کردید اکوسیستم کمی بهتر شود.
+
+[جزئیات بیشتر درباره OATها](https://help.galxe.com/en/articles/7067290-galxe-oats-reward-and-celebrate-achievements)
+
+### چگونه درخواست کنید
+1. به [سرور دیسکورد](https://discord.gg/ethereum-org) ما بپیوندید.
+2. لینک مشارکت خود را در کانال `#🥇 | اثبات مشارکت` قرار دهید
+3. منتظر بمانید تا یکی از اعضای تیم ما لینک OAT را برای شما ارسال کند.
+4. OAT خود را درخواست کنید!
+
+برای مطالبه OAT فقط باید از کیف پول های خودسرپرستی استفاده کنید. از حسابهای صرافی یا سایر حسابهایی که کلیدهای خصوصی را در اختیار ندارید، استفاده نکنید، زیرا به شما اجازه دسترسی و مدیریت OAT را نمیدهند.
+
+## GitPOAP خود را مطالبه کنید {#claim-gitpoap}
+
+GitPOAP همچنین به طور خودکار مشارکت ادغام شده شما را تشخیص می دهد و به شما امکان می دهد یک POAP مشارکت کننده منحصر به فرد جداگانه را در خود پلتفرم آنها ایجاد کنید!
+
+
+### چگونه درخواست کنیم {#how-to-claim}
+
+1. [GitPOAP](https://www.gitpoap.io) را ببینید.
+2. از طریق گزینه ورود به سیستم با کیف پول خود یا حتی با ایمیل خود ارتباط برقرار کنید.
+3. نام کاربری گیتهاب، آدرس اتر، نامهای ENS یا هرگونه GitPOAP خود را جستجو کنید تا بررسی کنید واجد شرایط هستید یا خیر.
+4. اگر حساب گیتهاب شما واجد شرایط باشد، می توانید یک GitPOAP ایجاد کنید!
+
+## مشارکت کنندگان {#contributors}
+
+
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md
new file mode 100644
index 00000000000..830700d36da
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md
@@ -0,0 +1,119 @@
+---
+title: سوالات متداول برنامه ترجمه
+lang: fa
+description: سوالات متداول درباره برنامه ترجمه ethereum.org
+---
+
+# راهنمای ترجمه ethereum.org {#translating-ethereum-guide}
+
+اگر در برنامه ترجمه تازه وارد هستید و تردید دارید که وارد شوید، در اینجا برخی از سوالات متداول هستند که میتوانند به شما کمک کنند کار را آغاز کنید. از این راهنما برای یافتن پاسخ به متداول ترین پرسش ها استفاده کنید.
+
+## آیا می توانم برای ترجمه ethereum.org دستمزد دریافت کنم؟ {#compensation}
+
+Ethereum.org یک وب سایت منبع باز است، به این معنی که هر کس می تواند مشارکت کند.
+
+برنامه ترجمه ethereum.org یک برنامه جانبی آن است و با فلسفه مشابه سازماندهی شده است.
+
+هدف برنامه ترجمه این است که محتوای اتریوم را برای همه، صرف نظر از زبان هایی که صحبت می کنند، در دسترس قرار دهد. همچنین به هر فرد دوزبانه اجازه می دهد تا با اکوسیستم اتریوم درگیر شود و به روشی قابل دسترس مشارکت کند.
+
+به همین دلیل، برنامه ترجمه آزاد و داوطلبانه است و شرکت در آن شامل پرداخت دستمزد نمی باشد. اگر می خواستیم به مترجمان بابت تعداد کلماتی که ترجمه می کنند دستمزد بدهیم، فقط می توانستیم از کسانی که تجربه ترجمه کافی دارند (مترجمان حرفه ای) دعوت کنیم تا به برنامه ترجمه بپیوندند. این امر برنامه ترجمه را انحصاری میکرد و ما را از دستیابی به اهداف مشخص شده باز میداشت، به ویژه: اجازه دادن به همه برای مشارکت و درگیر شدن با اکوسیستم.
+
+ما تمام تلاش خود را می کنیم تا مشارکت کنندگان خود را قادر به موفقیت در اکوسیستم اتریوم کنیم. بسیاری از مشوق های غیر پولی مانند: [ارائه POAP](/contributing/translation-program/acknowledgements/#poap) و [گواهی مترجم](/contributing/translation-program/acknowledgements/#certificate) و همچنین سازماندهی [ تابلوهای امتیازات ترجمه](/contributing/translation-program/acknowledgements/) و [فهرست کردن همه مترجمان ما در سایت](/contributing/translation-program/contributors/) وجود دارند.
+
+## چگونه می توانم سطرهای دارای `` را ترجمه کنم؟ {#tags}
+
+هر متن به شکل نوشته خالص نوشته نمیشود. متن هایی هستند که متشکل از اسکریپت های مختلفی مثل تگ های اچتیامال (`<0>`,`0>`) هستند.
+
+- متن داخل تگ ها را ترجمه کنید اما خود تگ ها را ترجمه نکنید. هیچ چیزی درون `<` و `>` نباید ترجمه یا حذف شود.
+- جهت امن نگه داشتن متن، پیشنهاد میکنیم روی دکمه "Copy Source" در گوشه پایین چپ کلیک کنید. این کار متن اولیه را کپی و در قسمت متن درج میکند. این به شما اجازه میدهد مشخص کنید که تگ ها کجا هستند و کمک میکند از اشتباه جلوگیری کنید.
+
+![رابط Crowdin با دکمه کپی از منبع، مشخص شده است](./html-tag-strings.png)
+
+شما میتوانید موقعیت تگ ها را درون متن تغییر داده و آنرا مطابق زبان خود طبیعی تر کنید - فقط اطمینان حاصل کنید تمام تگ جابجا شود.
+
+برای اطلاعات عمیقتر در مورد کار با تگها و اجزای کد، لطفاً به [راهنمای سبک ترجمه ethereum.org](/contributing/translation-program/translators-guide/#dealing-with-tags) مراجعه کنید.
+
+## متن ها کجا زندگی میکنند؟ {#strings}
+
+اغلب اوقات ممکن است کلمه های زبان منبع به تنهایی برای ارائه ترجمه دقیق کافی نباشد.
+
+- برای اطلاعات بیشتر به «اسکرین شات ها» و «زمینه» نگاهی بیندازید. در بخش سطر منبع، تصویر اسکرین شات پیوست شده را خواهید دید که نحوه استفاده از سطر در متن را به شما نشان می دهد.
+- هنگامی که مطمئن نیستید، یک پرچم در "بخش نظرات" قرار دهید. [نمیدانید چگونه نظر بدهید؟](#comment)
+
+![نشان دادن این که چگونه پسزمینه برای یک سطر دارای اسکرینشات قابل ارائه است](./source-string.png)
+
+![یک اسکرینشات نمونه برای زمینه اضافه شد](./source-string-2.png)
+
+## چگونه می توانم نظر بگذارم یا سوال بپرسم؟ می خواهم یک مسئله یا اشتباه تایپی را با پرچم نشان دهم... {#comment}
+
+اگر میخواهید روی متن خاصی که نیاز به توجه دارد پرچم قرار دهید، با خیالی آسوده نظر خود را بگذارید.
+
+- بر روی دکمه دوم نوار سمت راست بالا کلیک کنید. زبانه مخفی در سمت راست شما ظاهر خواهد شد. یک نظر جدید بگذارید و روی مربع "Issue" در پایین کلیک کنید. میتوانید نوع مساله را با انتخاب یکی از گزینههای منوی کرکرهای مشخص کنید.
+- پس از ارسال، این مورد به تیم ما گزارش می شود. ما مشکل را برطرف خواهیم کرد و با پاسخ دادن به نظر شما و بستن مسئله به شما اطلاع خواهیم داد.
+- اگر یک ترجمه نادرست را گزارش کنید، ترجمه و پیشنهاد شما توسط یک فرد با زبان اصلی در تجدید نظر بعدی بررسی میشود.
+
+![نشان دادن نحوه ارائه نظرات و مسائل](./comment-issue.png)
+
+## حافظه ترجمه یا TM چیست؟ {#translation-memory}
+
+حافظه ترجمه (TM) یکی از ویژگی های Crowdin است که تمام متن های ترجمه شده قبلی را در [ethereum.org](http://ethereum.org/) ذخیره می کند. هنگامی که یک متن ترجمه می شود، به طور خودکار در TM پروژه ما ذخیره می شود. این میتواند ابزاری مفید برای کمک به شما به منظور صرفهجویی در زمان باشد!
+
+- به بخش «پیشنهادات TM و MT» نگاه کنید و خواهید دید که دیگر مترجمان چگونه متن مشابه یا یکسانی را ترجمه کرده اند. اگر گزینهای با درجه تطابق بالا پیدا کردید، با خاطری آسوده با کلیک بر روی آن به ترجمه آن مراجعه کنید.
+- اگر چیزی در لیست وجود ندارد، میتوانید ترجمههای قبلی را در TM جستجو کنید و برای هماهنگی، مجددا از آنها استفاده کنید.
+
+![اسکرین شات حافظه ترجمه](./translation-memory.png)
+
+## چگونه از واژه نامه Crowdin استفاده کنم؟ {#glossary}
+
+اصطلاحات اتریوم بخش مهم دیگری از کار ترجمه ما است، زیرا اغلب اصطلاحات فناوری جدید هنوز در بسیاری از زبانها بومیسازی نشده اند. همچنین اصطلاحاتی وجود دارند که در زمینه های مختلف معانی متفاوت دارند. [درباره ترجمه اصطلاحات اتریوم بیشتر بدانید](#terminology)
+
+واژه نامه Crowdin بهترین مکان برای شفاف سازی اصطلاحات و تعاریف است. برای مراجعه به واژه نامه دو راه وجود دارد.
+
+- ابتدا، هنگامی که یک عبارت با خط زیر را در متن زیان منبع پیدا کردید، می توانید ماوس را روی آن قرار دهید و تعریف مختصری از آن را مشاهده کنید.
+
+![یک مثال از تعریف واژه نامه](./glossary-definition.png)
+
+- دوم، اگر عبارتی را دیدید که برایتان آشنا نیست اما زیر آن خط کشیده نشده است، می توانید آن را در زبانه واژه نامه (دکمه سوم ستون سمت راست) جستجو کنید. در آنجا توضیحاتی در مورد اصطلاحات خاص و مواردی که اغلب در پروژه استفاده می شود را خواهید یافت.
+
+![یک اسکرین شات که نشان می دهد کجا باید برگه واژه نامه را در Crowdin پیدا کنید](./glossary-tab.png)
+
+- اگر هنوز نتوانستید آن را پیدا کنید، فرصتی برای اضافه کردن یک عبارت جدید است! ما توصیه می کنیم آن را در یک موتور جستجو بیابید و توضیحات را به واژه نامه اضافه کنید. این کمک بزرگی به مترجمان دیگر برای درک بهتر این اصطلاح خواهد کرد.
+
+![یک اسکرین شات که نشان می دهد چگونه می توان یک اصطلاح واژه نامه را به Crowdin اضافه کرد](./add-glossary-term.png)
+
+### سیاست ترجمه اصطلاحات {#terminology}
+
+_برای نامها (برندها، شرکتها، افراد) و اصطلاحات فناوری جدید (بیکن چین، زنجیرههای شارد و غیره)_
+
+اتریوم اصطلاحات جدیدی را ارائه می کند که اخیراً ابداع شده اند. برخی اصطلاحات از مترجمی به مترجم دیگر متفاوت است زیرا هیچ ترجمه رسمی به زبان مربوطه آنها وجود ندارد. چنین ناهماهنگی هایی می تواند باعث سوء تفاهم شود و خوانا بودن را کاهش دهد.
+
+با توجه به تنوع زبانی و استانداردسازی های مختلف در هر زبان، ارائه یک سیاست یکپارچه ترجمه اصطلاحات که بتواند در همه زبان های پشتیبانی شده قابل انطباق باشد، تقریبا غیرممکن بوده است.
+
+پس از بررسی دقیق، به این تصمیم رسیدیم که پرکاربردترین اصطلاحات را به شما مترجمان بسپاریم.
+
+هنگامی که اصطلاحی را پیدا می کنید که برای شما ناآشنا است، پیشنهاد می کنیم:
+
+- به [واژه نامه اصطلاحات](#glossary) مراجعه کنید، ممکن است ببینید که مترجمان دیگر پیشتر چگونه آن را ترجمه کرده اند. اگر فکر میکنید اصطلاحی که قبلاً ترجمه شده مناسب نیست، با آسودگی یک عبارت جدید را به واژهنامه Crowdin بیافزایید و ترجمه خود را بازیابی کنید.
+- اگر چنین ترجمه قبلی در واژه نامه وجود ندارد، توصیه می کنیم آن را در یک موتور جستجو یا مقالهای در یک رسانه جستجو کنید که نشان می دهد این عبارت واقعاً چگونه در جامعه شما استفاده می شود.
+- اگر اصلاً هیچ مرجعی پیدا نکردید، با آسودگی به درک خود اعتماد کنید و ترجمه جدیدی را به زبان خود پیشنهاد دهید!
+- اگر برای انجام این کار اعتماد به نفس کمتری دارید، اصطلاح را ترجمه نشده بگذارید. گاهی اوقات، اصطلاحات انگلیسی در ارائه تعاریف دقیق بیش از اندازه کافی هستند.
+
+توصیه میکنیم نام برندها، شرکتها و کارکنان را ترجمه نشده بگذارید زیرا ممکن است ترجمه باعث سردرگمی غیر ضروری و مشکلات بهینه سازی موتور جستجو (SEO) شود.
+
+## روند ویرایش چگونه است؟ {#review-process}
+
+برای اطمینان از سطح مشخصی از کیفیت و سازگاری در ترجمههایمان، ما با [Acolad](https://www.acolad.com/)، یکی از بزرگترین ارائهدهندگان خدمات زبان در سطح جهان، کار میکنیم. Acolad دارای 20،000 کارشناس حرفه ای زبان است، به این معنی که آنها می توانند برای هر زبان و نوع محتوایی که نیاز داریم، داوران حرفه ای ارائه دهند.
+
+روند ویرایش ساده است. هنگامی که یک [سبد محتوا](/contributing/translation-program/content-buckets) 100٪ ترجمه شد، ما سفارش بررسی آن سبد محتوا را می دهیم. فرآیند ویرایش مستقیماً در Crowdin انجام می شود. پس از تکمیل ویرایش، وبسایت را با محتوای ترجمه شده به روز می کنیم.
+
+## چگونه به زبان خودم محتوا اضافه کنم؟ {#adding-foreign-language-content}
+
+هماکنون، تمام محتواهای غیر انگلیسی مستقیما از انگلیسی ترجمه میشوند و هر محتوایی که در زبانی غیر از انگلیسی موجود باشد نمیتواند به دیگر زبانها اضافه شود.
+
+برای پیشنهاد محتوای جدید به ethereum.org، میتوانید در گیتهاب [یک مسئله ثبت کنید.](https://github.com/ethereum/ethereum-org-website/issues). در صورت اضافه شدن، این محتوا به انگلیسی نوشته میشود و با استفاده از Crowdin به دیگر زبانها ترجمه میشود.
+
+ما در نظر داریم پشتیبانی برای محتواهای غیر انگلیسی را در آیندهای نزدیک اضافه کنیم.
+
+## در ارتباط باشید {#contact}
+
+متشکریم که تمام این مطالب را مطالعه کردید. امیدواریم این کار به شما کمک کند تا در برنامه ما حضور داشته باشید. به [کانال ترجمه دیسکورد](https://discord.gg/ethereum-org) ما بپیوندید و در آن از دیگر مترجمین سوال بپرسید و با آنها همکاری کنید، یا با ما با ایمیل translations@ethereum.org در ارتباط باشید!
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md
new file mode 100644
index 00000000000..994adc6f47a
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md
@@ -0,0 +1,89 @@
+---
+title: چگونه ترجمه کنیم
+lang: fa
+description: راهنمای استفاده از Crowdin جهت ترجمه ethereum.org
+---
+
+# چگونه ترجمه کنیم {#how-to-translate}
+
+## راهنمای تصویری {#visual-guide}
+
+برای افرادی که یادگیری تصویری را ترجیح میدهند، راهنمای ساخت حساب کاربری Crowdin با لوکا را تماشا کنید. همچنین میتوانید تمامی مراحل طی شده را در قالب متن، در بخش بعدی پیدا کنید.
+
+
+
+## راهنمای نوشتاری {#written-guide}
+
+### به پروژه ما در سایت Crowdin بپیوندید {#join-project}
+
+شما باید به حساب کاربری خود در Crowdin وارد شوید و یا اگر از قبل حسابی ندارید، ثبتنام کنید. برای ثبت نام تنها چیزی که لازم است یک حساب ایمیل و رمز عبور است.
+
+
+ به پروژه ما بپیوندید
+
+
+### زبان خود را انتخاب کنید {#open-language}
+
+بعد از ورود به حساب Crowdin، شما جزئیات پروژه و لیست تمامی زبانهای موجود را مشاهده خواهید کرد. همچنین، هر زبان شامل اطلاعاتی درباره تعداد کل کلمات قابل ترجمه و یک نمای کلی از مقدار محتوای ترجمه و تائید شده در آن زبان میباشد.
+
+زبانی که میخواهید ترجمه کنید را انتخاب نموده تا لیست فایلهای موجود برای ترجمه را مشاهده کنید.
+
+![فهرست زبان ها در Crowdin](./list-of-languages.png)
+
+### سندی را برای کار پیدا کنید {#find-document}
+
+محتوای وب سایت به تعدادی اسناد و سطل محتوا تقسیم می شود. می توانید پیشرفت هر سند را در سمت راست بررسی کنید - اگر پیشرفت ترجمه زیر 100٪ است، لطفا مشارکت کنید!
+
+زبان خود را در فهرست نمی بینید؟ [یک مسئله باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new/choose) یا در [دیسکورد](/discord/) ما بپرسید
+
+![فایل های ترجمه شده و ترجمه نشده در Crowdin](./crowdin-files.png)
+
+نکتهای در مورد سبد های محتوا: ما از «سبد های محتوا» در Crowdin استفاده میکنیم تا ابتدا محتوای دارای بالاترین اولویت منتشر شود. زمانی که یک زبان، برای مثال [فیلیپینی](https://crowdin.com/project/ethereum-org/fil#) را نگاه میکنید، پوشههایی برای سبد محتوا میبینید («۱. صفحه خانه»، «۲. ضروریات"، "3. اکتشاف"، و غیره).
+
+ما به شما توصیه میکنیم به ترتیب (... → ۳ → ۲ → ۱) ترجمه کنید که صفحات با بیشترین استفاده اول ترجمه شوند.
+
+[درباره سبدهای محتوای ethereum.org بیشتر بیاموزید](/contributing/translation-program/content-buckets/)
+
+### ترجمه کنید {#translate}
+
+پس از انتخاب فایلی که می خواهید ترجمه کنید، در ویرایشگر آنلاین باز خواهد شد. اگر قبلاً از Crowdin استفاده نکردهاید، میتوانید از این راهنمای سریع برای مرور اصول اولیه استفاده کنید.
+
+![ویرایشگر آنلاین Crowdin](./online-editor.png)
+
+**_1 – نوار کناری سمت چپ_**
+
+- ترجمه نشده (قرمز) – متنی که هنوز روی آن کار نشده است. اینها متن هایی هستند که باید ترجمه کنید.
+- ترجمه شده (سبز) - متنی که قبلا ترجمه شده است، اما هنوز بازبینی نشده است. میتوانید ترجمههای دیگری را پیشنهاد دهید یا با استفاده از دکمههای «+» و «-» در ویرایشگر، به ترجمههای موجود رأی دهید.
+- تایید شده (علامت تیک) - متنی که قبلاً بررسی شده و در حال حاضر در وبسایت فعال است.
+
+همچنین میتوانید از دکمههای بالای صفحه به منظور جستجوی متنی خاص، فیلتر کردن آنها بر اساس وضعیت یا تغییر نما استفاده کنید.
+
+**_2 - بخش ویرایشگر_**
+
+منطقه اصلی ترجمه - متن مبدأ در بالا با زمینه و اسکرینشات های اضافی، در صورت وجود، نمایش داده می شود. برای پیشنهاد ترجمه جدید، ترجمه خود را در قسمت "Enter translation here" وارد کنید و روی Save کلیک کنید.
+
+همچنین میتوانید ترجمههای موجود متن و ترجمهها به زبانهای دیگر و همچنین تطبیق حافظه ترجمه و پیشنهادات ترجمه ماشینی را در این بخش بیابید.
+
+**_3 - نوار کناری سمت راست_**
+
+اینجا جایی است که می توانید نظرات، گزینههای حافظه ترجمه و گزینههای واژه نامه را بیابید. نمای پیشفرض نظرات را نشان میدهد و به مترجمان اجازه میدهد با هم ارتباط برقرار کنند، مسائل را مطرح کنند یا ترجمههای نادرست را گزارش کنند.
+
+با استفاده از دکمههای بالای صفحه، میتوانید به حافظه ترجمه بروید که در آن میتوانید ترجمههای موجود را جستجو کنید، یا به واژهنامه بروید که حاوی توضیحات و ترجمههای استاندارد واژههای کلیدی است.
+
+میخواهید بیشتر بدانید؟ با خیالی راحت می توانید [اسناد نحوه استفاده از ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) را بررسی کنید
+
+### فرایند بازبینی {#review-process}
+
+هنگامی که ترجمه را کامل کردید (یعنی همه فایلهای سبد محتوا 100% را نشان میدهد)، خدمات ترجمه حرفهای ما محتوا را بررسی میکند (و احتمالاً ویرایش میکند). پس از تکمیل بررسی (یعنی وقتی پیشرفت بازبینی 100٪ شد)، آن را به وب سایت اضافه می کنیم.
+
+
+ لطفا از ترجمههای ماشینی برای ترجمه پروژه استفاده نکنید. همه ترجمهها پیش از اضافه شدن به وبسایت بررسی میشوند. اگر ترجمههای شما، ترجمه ماشینی به نظر برسند، رد میشوند و افرادی که از ترجمههای ماشینی استفاده کنند معمولا از پروژه حذف میشوند.
+
+
+### در ارتباط باشید {#get-in-touch}
+
+سوالی دارید؟ یا می خواهید با تیم ما و سایر مترجمان همکاری کنید؟ لطفاً در کانال [سرور دیسکورد ethereum.org](/discord/) ما پست کنید
+
+همچنین می توانید از طریق translations@ethereum.org با ما در تماس باشید
+
+از مشارکت شما در برنامه ترجمه ethereum.org سپاسگزاریم!
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/index.md
new file mode 100644
index 00000000000..f97ffa43681
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/translation-program/index.md
@@ -0,0 +1,90 @@
+---
+title: برنامه ترجمه
+lang: fa
+description: اطلاعاتی درباره برنامه ترجمه ethereum.org
+---
+
+# برنامه ترجمه {#translation-program}
+
+برنامه ترجمه یک تلاش مشترک برای ترجمه ethereum.org به زبان های مختلف است تا این وب سایت برای میلیاردها غیر انگلیسی زبان در سراسر جهان در دسترس تر باشد.
+
+![](./enterprise-eth.png)
+
+## در ترجمه به ما کمک کنید {#help-us-translate}
+
+برنامه ترجمه ethereum.org باز است و هر کس می تواند مشارکت کند!
+
+1. ابتدا باید وارد حساب Crowdin خود شوید یا ثبت نام کنید.
+2. زبانی را که می خواهید در آن مشارکت کنید انتخاب کنید.
+3. قبل از شروع، لطفاً راهنمای [نحوه ترجمه](/contributing/translation-program/how-to-translate/) را برای یادگیری نحوه استفاده از Crowdin و [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) را برای نکات و بهترین روش ها مطالعه کنید.
+4. ترجمههای ماشینی تایید نخواهند شد.
+5. همه ترجمهها قبل از اضافه شدن به سایت اصلی بررسی میشوند، بنابراین قبل از انتشار ترجمههای شما تأخیر کوتاهی وجود خواهد داشت.
+
+_به دیسکورد [ethereum.org Discord](/discord/) بپیوندید تا در ترجمه ها همکاری کنید، سؤال بپرسید، نظرات و ایده ها را به اشتراک بگذارید، یا به یک گروه ترجمه بپیوندید._
+
+
+ شروع به ترجمه کنید
+
+
+## درباره برنامه ترجمه {#about-us}
+
+جامعه اتریوم قصد دارد جهانی و فراگیر باشد، با این حال بسیاری از محتوای آن فقط مختص انگلیسی زبانها است و 6 میلیارد غیرانگلیسی زبان دنیا کنار گذاشته شده اند. برای اینکه ethereum.org به عنوان پورتال اتریوم برای جامعه جهانی عمل کند، ما بر این باوریم که ارائه محتوای اتریوم به زبان مادری برای غیر انگلیسی زبانان ضروری است.
+
+هدف از برنامه ترجمه ethereum.org این است که با ترجمه ethereum.org و دیگر مطالب اتریوم به تعداد زیادی از زبانها، در دسترس همگان قرار گیرد.
+
+درباره [مأموریت و چشم انداز](/contributing/translation-program/mission-and-vision) برنامه ترجمه ethereum.org بیشتر بخوانید.
+
+### پیشرفت ما تاکنون {#our-progress}
+
+- [بیش از **6,000 +** مترجم](/contributing/translation-program/contributors/)
+- **62** زبان در سایت موجود است
+- [ترجمه **3 میلیون** کلمه در سال 2023](/contributing/translation-program/acknowledgements/)
+
+
+
+### تقدیرات {#acknowledgements}
+
+Ethereum.org توسط هزاران نفر از اعضای انجمن، ترجمه شده و این جامعه بخش کلیدی برنامه ترجمه است. ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. در اینجا برخی از قدردانی های ما از مترجمان آمده است. ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. در اینجا برخی از قدردانی های ما از مترجم ها آمده است:
+
+#### گواهی {#certificate}
+
+اگر در برنامه ترجمه مشارکت کرده اید و حداقل 5000 کلمه ترجمه شده شما تایید شده است، واجد شرایط دریافت گواهی مترجم ethereum.org هستید. [جزئیات بیشتر در باره گواهیها](/contributing/translation-program/acknowledgements/#certificate)
+
+#### OATها {#oats}
+
+مشارکت کنندگان در برنامه ترجمه بر اساس تعداد کلمات ترجمه شده در سال 2024، واجد شرایط OAT های مختلف (توکن های موفقیت زنجیره ای) هستند. OATها NFTهایی هستند که مشارکت شما در برنامه ترجمه ethereum.org را ثابت می کنند. [جزئیات بیشتر درباره OATها](/contributing/translation-program/acknowledgements/#oats)
+
+#### قدردانی از مترجمها {#translator-acknowledgements}
+
+قدردانی عمومی از مترجمان برتر ما از طریق [تابلوهای امتیازات](/contributing/translation-program/acknowledgements/) و [فهرستی از همه مشارکت کنندگان در برنامه ترجمه](/contributing/translation-program/contributors/) می باشد.
+
+#### پاداشها {#rewards}
+
+در گذشته، ما به فعالترین مشارکتکنندگان خود، بلیطهایی برای کنفرانسهای اتریوم مانند [Devcon](https://devcon.org/en/) و [Devconnect](https://devconnect.org/) و همچنین کادوهای انحصاری ethereum.org پاداش دادهایم.
+
+ما دائماً به روشهای جدید و نوآورانه برای پاداش دادن به مشارکتکنندگان خود فکر میکنیم، پس با ما همراه باشید!
+
+### راهنماها و منابع {#guides-and-resources}
+
+اگر در برنامه ترجمه مشارکت می کنید یا به فکر مشارکت هستید، باید راهنمای ترجمه زیر را بررسی کنید:
+
+- [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) _– دستورالعمل ها و نکاتی برای مترجمان ethereum.org_
+- [سؤالات متداول ترجمه](/contributing/translation-program/faq/) _– پرسشها و پاسخهای متداول درباره برنامه ترجمه ethereum.org_
+- [راهنمای ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) _– یک راهنمای عمیق برای استفاده از ویرایشگر آنلاین Crowdin و برخی ویژگی های پیشرفته Crowdin_
+- [سطل های محتوا](/contributing/translation-program/content-buckets/)_ – کدام صفحات در هر سطل محتوای ethereum.org گنجانده شده است_
+
+برای بررسی دیگر ابزارهای مفید ترجمه، انجمن های مترجمین و پست های وبلاگ برنامه ترجمه، لطفاً از [صفحه منابع](/contributing/translation-program/resources/) دیدن کنید.
+
+## در ارتباط باشید {#get-in-touch}
+
+سوالی دارید؟ یا می خواهید با تیم ما و سایر مترجمان همکاری کنید؟ لطفاً در کانال [سرور دیسکورد ethereum.org](https://discord.gg/ethereum-org) ما پست کنید
+
+همچنین می توانید از طریق translations@ethereum.org با ما در تماس باشید
+
+## برنامه ترجمه خود را شروع کنید {#starting-a-translation-program}
+
+ما به ترجمه محتوای اتریوم به زبانهای هر چه بیشتر و در دسترس قرار دادن محتوای آموزشی برای همه تعهد داریم. در راستای تمرکزمان بر ترجمه، میخواهیم به سایر پروژههای اتریوم در سازماندهی، مدیریت و بهبود تلاشهای ترجمه آنها کمک کنیم.
+
+به همین دلیل، ما یک [کتابچه برنامه ترجمه](/contributing/translation-program/playbook/) تهیه کرده ایم که حاوی نکات و بهترین روش هایی است که در فرآیند ترجمه ethereum.org به کار گرفته ایم.
+
+آیا میخواهید بیشتر همکاری کنید یا از برخی منابع ترجمهمان استفاده کنید؟ آیا بازخوردی در مورد کتاب بازی دارید؟ ما دوست داریم از نظرات شما در translations@ethereum.org آگاه شویم.
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md
new file mode 100644
index 00000000000..408c60791ed
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md
@@ -0,0 +1,25 @@
+---
+title: مأموریت و چشمانداز
+lang: fa
+description: ماموریت و چشم انداز برنامه ترجمه ethereum.org
+---
+
+# مأموریت و چشمانداز {#mission-and-vision}
+
+جامعه اتریوم قصد دارد جهانی و فراگیر باشد، با این حال بسیاری از محتوای آن فقط مختص انگلیسی زبانها است و 6 میلیارد غیرانگلیسی زبان دنیا کنار گذاشته شده اند. برای اینکه ethereum.org به عنوان پورتال اتریوم برای جامعه جهانی عمل کند، ما بر این باوریم که ارائه محتوای اتریوم به زبان مادری برای غیر انگلیسی زبانان ضروری است.
+
+هدف از برنامه ترجمه ethereum.org این است که با ترجمه ethereum.org و دیگر مطالب اتریوم به تعداد زیادی از زبانها، در دسترس همگان قرار گیرد.
+
+## ماموریت ما {#our-mission}
+
+- ارائه نسخههای ترجمهشده وبسایت به بازدیدکنندگان در سراسر جهان برای یادگیری درباره اتریوم به زبان مادری شان
+- تسهیل ورود اعضای بیشتر به جامعه جهانی اتریوم
+- امکان پذیر کردن دسترسی بیشتر و فراگیرتر شدن اشتراک گذاری اطلاعات و دانش اتریوم
+- توانمند ساختن اعضای جامعه برای همکاری در زمینه ترجمه با اتریوم و ایجاد اثر خود در اکوسیستم
+- شناسایی، ایجاد ارتباط و ارائه راهنمایی برای مشارکت کنندگان پرشوری که به دنبال مشارکت در اکوسیستم هستند
+
+## چشمانداز ما {#our-vision}
+
+- ترجمه محتوای اساسی برای اعضای جامعه اتریوم از بسیاری از کشورها و بخشهای جهان تا جایی که ممکن است
+- پشتیبانی اشتراکگذاری دانش به زبانهای مختلف برای ایجاد یک جامعه آگاه و آموزش دیده
+- افزایش فراگیری و دسترسی اتریوم، با حذف موانع زبانی که از پیوستن غیرانگلیسی زبانان به اکوسیستم جلوگیری می کند
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md
new file mode 100644
index 00000000000..fa7e39d5113
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md
@@ -0,0 +1,45 @@
+---
+title: منابعی برای مترجمان
+lang: fa
+description: منابع مفید برای مترجمان ethereum.org
+---
+
+# منابع {#resources}
+
+میتوانید برخی از راهنماها و ابزارهای مفید برای مترجمان ethereum.org، و همچنین انجمنهای ترجمه و بروزرسانیها را در زیر بیابید.
+
+## راهنماییها {#guides}
+
+- [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) _– دستورالعمل ها و نکاتی برای مترجمان ethereum.org_
+- [سؤالات متداول ترجمه](/contributing/translation-program/faq/) _– پرسشها و پاسخهای متداول درباره برنامه ترجمه ethereum.org_
+- [راهنمای ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) _– یک راهنمای عمیق برای استفاده از ویرایشگر آنلاین Crowdin و برخی ویژگی های پیشرفته Crowdin_
+- [سطل های محتوا](/contributing/translation-program/content-buckets/)_ – کدام صفحات در هر سطل محتوای ethereum.org گنجانده شده است_
+
+## ابزارها {#tools}
+
+- [پورتال زبان مایکروسافت](https://www.microsoft.com/en-us/language) _– برای یافتن و بررسی ترجمههای استاندارد اصطلاحات فنی، مفید است_
+- [Linguee](https://www.linguee.com/) _– موتور جستجو برای ترجمه ها و فرهنگ لغت که امکان جستجو بر اساس کلمه یا عبارت را فراهم می کند_
+- [جستجوی عبارت Proz](https://www.proz.com/search/) _– پایگاه داده لغت نامه ها و واژه نامه های ترجمه برای اصطلاحات تخصصی_
+- [Eurotermbank](https://www.eurotermbank.com/) _– مجموعههایی از اصطلاحات اروپایی به ۴۲ زبان_
+
+## جوامع {#communities}
+
+- [گروه های ترجمه خاص زبان در دیسکورد](/discord/) _– ابتکاری برای ارتباط مترجمان ethereum.org با گروه های ترجمه_
+- [گروه مترجمان چینی](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _– صفحه ایده برای هماهنگی آسانتر میان مترجمان چینی_
+
+## آخرین به روزرسانی ها {#latest-updates}
+
+برای به روز نگه داشتن آخرین پیشرفت برنامه ترجمه، می توانید [وبلاگ بنیاد اتریوم](https://blog.ethereum.org/) را دنبال کنید:
+
+- [به روز رسانی نقاط عطف اکتبر ۲۰۲۱](https://blog.ethereum.org/2021/10/04/translation-program-update/)
+- [به روز رسانی نقاط عطف دسامبر 2020](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/)
+- [به روز رسانی نقاط عطف ژوئیه 2020](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/)
+- [راه اندازی برنامه ترجمه اوت 2019](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/)
+
+## ساعات کاری برای مترجمین {#office-hours}
+
+ما برای مترجمین، ساعات کاری را در چهارشنبه دوم هر ماه داریم. این ساعات در کانال صوتی (غیرمتنی) #office-hours در [ethereum.org Discord](/discord/) نگهداری میشوند که می توانید زمان دقیق و جزییات بیشتر را در آن بیابید.
+
+ساعات کاری به مترجمان ما امکان میدهد درباره فرآیند ترجمه سؤال بپرسند، درباره برنامه بازخورد ارائه کنند، ایدههای خود را به اشتراک بگذارند یا با تیم اصلی ethereum.org چت کنند. در نهایت، میخواهیم از این ارتباطات برای برقراری ارتباط با پیشرفتهای اخیر در برنامه ترجمه و به اشتراک گذاشتن نکات و دستورالعملهای کلیدی با همکاران مان استفاده کنیم.
+
+اگر شما یک مترجم ethereum.org هستید یا علاقه دارید باشید، میتوانیم در یکی از این جلسات به ما ملحق شوید.
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md
new file mode 100644
index 00000000000..730a2a34a0c
--- /dev/null
+++ b/public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md
@@ -0,0 +1,293 @@
+---
+title: راهنمای مترجمان
+lang: fa
+description: دستورالعمل ها و نکات برای مترجمان ethereum.org
+---
+
+# راهنمای سبک ترجمه Ethereum.org {#style-guide}
+
+راهنمای سبک ترجمه ethereum.org حاوی برخی از مهم ترین دستورالعمل ها، دستورالعمل ها و نکات برای مترجمان است که به ما کمک می کند تا وبسایت را بومی سازی کنیم.
+
+این سند به عنوان یک راهنمای کلی عمل می کند و مختص هیچ زبانی نیست.
+
+اگر سؤال، پیشنهاد یا بازخوردی دارید، میتوانید با ما در آدرس ایمیل translations@ethereum.org تماس بگیرید، به هندل @ethdotorg در Crowdin پیام ارسال کنید، یا [به دیسکورد ما بپیوندید](https://discord.gg/ethereum-org) که در آنجا میتوانید در کانال #translations به ما پیام بدهید یا با هر یک از اعضای تیم تماس بگیرید.
+
+## استفاده از Crowdin {#using-crowdin}
+
+میتوانید دستورالعملهای اساسی در مورد نحوه پیوستن به پروژه در Crowdin و نحوه استفاده از ویرایشگر آنلاین Crowdin را در [صفحه برنامه ترجمه](/contributing/translation-program/#how-to-translate) بیابید.
+
+اگر میخواهید درباره Crowdin و استفاده از برخی از ویژگیهای پیشرفته آن اطلاعات بیشتری کسب کنید، [کتابخانه Crowdin](https://support.crowdin.com/online-editor/) حاوی تعداد زیادی راهنماهای مفید و مروری بر همه عملکردهای Crowdin است.
+
+## دریافت ماهیت پیام {#capturing-the-essence}
+
+هنگام ترجمه محتوای ethereum.org، از ترجمه تحتالفظی اکیداً خودداری کنید.
+
+مهم این است که ترجمه ها جوهر پیام را در بر بگیرند. این میتواند به معنای بازنویسی عبارات خاص یا استفاده از ترجمههای توصیفی به جای ترجمه کلمه به کلمه محتوا باشد.
+
+زبان های مختلف قواعد گرامری، قراردادها و ترتیب کلمات متفاوتی دارند. هنگام ترجمه، لطفاً به نحوه ساختار جملات در زبان مقصد توجه داشته باشید و از ترجمه تحتالفظی منبع انگلیسی خودداری کنید، زیرا این کار می تواند منجر به ساختار ضعیف جمله و خوانایی آن شود.
+
+به جای ترجمه کلمه به کلمه متن مبدأ، توصیه می شود کل جمله را بخوانید و آن را با معادل های زبان مقصد مطابقت دهید.
+
+## رسمی مقابل غیررسمی {#formal-vs-informal}
+
+ما از فرم رسمی آدرس استفاده می کنیم که همیشه مودبانه و مناسب برای همه بازدیدکنندگان است.
+
+استفاده از آدرس رسمی به ما این امکان را می دهد که از به نظر رسیدن غیررسمی یا توهین آمیز جلوگیری کنیم و بدون در نظر گرفتن سن و جنسیت بازدیدکننده کار می کند.
+
+بیشتر زبان های هند و اروپایی و آفریقایی-آسیایی از ضمایر شخصی دوم شخص مخصوص جنسیت استفاده می کنند که بین مذکر و مؤنث تمایز قائل می شود. هنگام خطاب کردن کاربر یا استفاده از ضمایر ملکی، میتوانیم از فرض جنسیت بازدیدکننده خودداری کنیم، زیرا شکل رسمی آدرس، صرف نظر از نحوه شناسایی آنها، عموماً قابل اجرا و سازگار است.
+
+## واژگان و معنی ساده و واضح {#simple-vocabulary}
+
+هدف ما این است که محتوای موجود در وبسایت را برای افراد هر چه بیشتری قابل درک کنیم.
+
+در اغلب موارد، با استفاده از کلمات کوتاه و ساده که به راحتی قابل درک هستند، می توان به این امر دست یافت. اگر چندین ترجمه ممکن برای یک کلمه خاص در زبان شما با همان معنی وجود داشته باشد، بهترین گزینه اغلب کوتاهترین کلمهای است که به وضوح معنی را منعکس میکند.
+
+## سیستم نوشتاری {#writing-system}
+
+Ethereum.org به چندین زبان با استفاده از سیستم های نوشتاری جایگزین (یا اسکریپت های نوشتن) به لاتین در دسترس است.
+
+تمام محتوا باید با استفاده از سیستم نوشتاری صحیح برای زبان شما ترجمه شود و نباید شامل هیچ کلمه ای باشد که با حروف لاتین نوشته شده باشد.
+
+هنگام ترجمه محتوا، باید اطمینان حاصل کنید که ترجمه ها سازگار هستند و شامل هیچ گونه حروف لاتین نمی شوند.
+
+یک تصور غلط رایج این است که اتریوم همیشه باید به زبان لاتین نوشته شود. این بیشتر نادرست است، لطفاً از املای اتریوم بومی زبان خود استفاده کنید (به عنوان مثال 以太坊 در چینی، إيثيريوم در عربی و غیره).
+
+**موارد فوق در مورد زبانها صدق نمیکند، جایی که نامهای خاص بهعنوان قاعده نباید ترجمه شوند.**
+
+## ترجمه متادیتای صفحه {#translating-metadata}
+
+برخی از صفحات حاوی ابرداده در صفحه هستند، مانند «عنوان»، «زبان»، «توضیحات»، «نوار کناری» و غیره.
+
+ما محتوایی را که مترجمان هرگز نباید هنگام آپلود صفحات جدید در Crowdin ترجمه کنند، پنهان می کنیم، به این معنی که تمام متادیتا های قابل مشاهده برای مترجمان در Crowdin باید ترجمه شوند.
+
+لطفاً هنگام ترجمه هر رشته ای که متن مبدأ "en" است، به ویژه مراقب باشید. این نشان دهنده زبانی است که صفحه به آن در دسترس است و باید به [کد زبان ISO برای زبان شما](https://www.andiamo.co.uk/resources/iso-language-codes/) ترجمه شود. این رشته ها باید همیشه با استفاده از حروف لاتین ترجمه شوند، نه خط نوشتاری، بومی زبان مقصد.
+
+اگر مطمئن نیستید از کدام کد زبان استفاده کنید، می توانید حافظه ترجمه را در Crowdin بررسی کنید یا کد زبان خود را در URL صفحه در ویرایشگر آنلاین Crowdin پیدا کنید.
+
+چند نمونه از کدهای زبان برای رایجترین زبانها:
+
+- عربی - ar
+- چینی ساده - zh
+- فرانسه - fr
+- هندی - hi
+- اسپانیایی - es
+
+## عناوین مقالات خارجی {#external-articles}
+
+برخی رشته ها حاوی عناوین مقالات خارجی هستند. اکثر صفحات مستندات توسعه دهنده ما حاوی پیوندهایی به مقالات خارجی برای مطالعه بیشتر هستند. رشته های حاوی عناوین مقالات باید بدون توجه به زبان مقاله ترجمه شوند تا از تجربه کاربری سازگارتر بازدیدکنندگانی که صفحه را به زبان خود مشاهده می کنند اطمینان حاصل شود.
+
+میتوانید نمونههایی از شکل ظاهری این رشتهها برای مترجمان و نحوه شناسایی آنها را در زیر بیابید (پیوندهای مقالهها را میتوانید بیشتر در پایین این صفحات، در بخش «مطالعه بیشتر» پیدا کنید):
+
+![عنوان مقالات در sidebar.png](./article-titles-in-sidebar.png) ![عنوان مقالات در editor.png](./article-titles-in-editor.png)
+
+## هشدارهای Crowdin {#crowdin-warnings}
+
+Crowdin دارای یک ویژگی داخلی است که به مترجمان هنگام اشتباه کردن هشدار می دهد. اگر فراموش کنید برچسبی را از منبع اضافه کنید، عناصری را که نباید ترجمه شوند، چندین فاصله متوالی اضافه کنید، علائم نگارشی پایان را فراموش کنید و غیره را فراموش کنید، قبل از ذخیره ترجمه به طور خودکار به شما در این مورد هشدار می دهد. اگر چنین هشداری را مشاهده کردید، لطفاً به عقب برگردید و ترجمه پیشنهادی را دوباره بررسی کنید.
+
+**هرگز این اخطارها را نادیده نگیرید، زیرا معمولاً به این معنی است که چیزی اشتباه است یا اینکه ترجمه قسمتی کلیدی از متن منبع را از دست داده است.**
+
+نمونه ای از هشدار Crowdin هنگامی که فراموش می کنید یک برچسب به ترجمه خود اضافه کنید: ![نمونه ای از هشدار Crowdin](./crowdin-warning-example.png)
+
+## نحوه کار با برچسب ها و تکه های کد {#dealing-with-tags}
+
+بسیاری از محتوای منبع حاوی برچسب ها و متغیرهایی هستند که در ویرایشگر Crowdin با رنگ زرد مشخص شده اند. اینها کارکردهای مختلفی دارند و باید به درستی به آنها پرداخت.
+
+**تنظیمات Crowdin**
+
+برای سهولت در مدیریت برچسب ها و کپی مستقیم آنها از منبع، توصیه می کنیم تنظیمات خود را در ویرایشگر Crowdin تغییر دهید.
+
+1. تنظیمات را باز کنید ![نحوه باز کردن تنظیمات در ویرایشگر](./editor-settings.png)
+
+2. تا بخش «نمایش برچسبهای HTML» به پایین بروید
+
+3. گزینه 'Hide' را انتخاب کنید ![لطفاً گزینه "پنهان کردن" را انتخاب کنید](./hide-tags.png)
+
+4. روی 'Save' کلیک کنید
+
+با انتخاب این گزینه دیگر متن کامل تگ نمایش داده نمی شود و یک عدد جایگزین می شود. هنگام ترجمه، با کلیک بر روی این تگ، به طور خودکار تگ دقیق در قسمت ترجمه کپی می شود.
+
+**لینکها**
+
+ممکن است متوجه لینک های کامل به صفحات در ethereum.org یا وبسایت های دیگر شوید.
+
+این لینک ها باید با منبع یکسان باشند و تغییر یا ترجمه نشوند. اگر لینکی را ترجمه کنید یا به هر نحوی آن را تغییر دهید، حتی فقط بخشی از آن را حذف کنید، مانند اسلش (/)، منجر به شکستگی و غیرقابل استفاده شدن لینک می شود.
+
+بهترین راه برای مدیریت لینک ها این است که آنها را مستقیماً از منبع کپی کنید، یا با کلیک بر روی آنها یا با استفاده از دکمه "کپی منبع" (Alt+C).
+
+![مثال link.png](./example-of-link.png)
+
+لینک ها همچنین در متن مبدأ به شکل برچسب ظاهر می شوند (یعنی <0> 0>). اگر ماوس را روی برچسب نگه دارید، ویرایشگر محتوای کامل آن را نشان می دهد - گاهی اوقات این برچسب ها نشان دهنده لینکها هستند.
+
+بسیار مهم است که لینک ها را از منبع کپی کنید و ترتیب آنها را تغییر ندهید.
+
+اگر ترتیب تگ ها تغییر کند، لینکی که آنها نشان می دهند شکسته می شود.
+
+![نمونه ای از لینکهای داخل tags.png](./example-of-links-inside-tags.png)
+
+**برچسب ها و متغیرها**
+
+متن منبع حاوی انواع مختلفی از تگ ها است که همیشه باید از منبع کپی شوند و هرگز تغییر نکنند. مانند موارد بالا، ترتیب این برچسب ها در ترجمه نیز باید مانند منبع باقی بماند.
+
+برچسب ها همیشه حاوی یک تگ باز و بسته هستند. در بیشتر موارد، متن بین تگ های باز و بسته باید ترجمه شود.
+
+مثال: ``غیرمتمرکز``
+
+`` - _برچسب باز که متن را پررنگ می کند_
+
+غیرمتمرکز - _متن قابل ترجمه_
+
+`` - _بستن برچسب_
+
+![مثالی از tags.png 'بولد'](./example-of-strong-tags.png)
+
+تکههای کد باید کمی متفاوت از برچسبهای دیگر باشند، زیرا حاوی کدهایی هستند که نباید ترجمه شوند.
+
+مثال: ``نانس`
`
+
+`` - _برچسب باز، که حاوی یک قطعه کد است_
+
+نانس- _متن غیرقابل ترجمه_
+
+`
` - _بستن برچسب_
+
+![مثال کد snippets.png](./example-of-code-snippets.png)
+
+متن منبع همچنین حاوی برچسب های کوتاه شده است که فقط حاوی اعداد هستند، به این معنی که عملکرد آنها بلافاصله مشخص نمی شود. میتوانید ماوس را روی این برچسبها نگه دارید تا ببینید دقیقاً کدام عملکرد را انجام میدهند.
+
+در مثال زیر، میتوانید آیتم های نگه داشتن ماوس را ببینید <0> برچسب نشان می دهد که نشان دهنده `` است و حاوی یک قطعه کد است، بنابراین محتوای داخل این برچسب ها نباید ترجمه شود.
+
+![نمونه ای از تگهای مبهم.png](./example-of-ambiguous-tags.png)
+
+## فرمها/اختصارات کوتاه یا کامل {#short-vs-full-forms}
+
+اختصارات زیادی در وب سایت استفاده می شود، به عنوان مثال. dapps و NFT و DAOو DeFi و غیره این اختصارات معمولاً در زبان انگلیسی استفاده می شوند و اکثر بازدیدکنندگان وب سایت با آنها آشنا هستند.
+
+از آنجایی که آنها معمولاً ترجمههای ثابتی به زبانهای دیگر ندارند، بهترین راه برای نزدیک شدن به این عبارات و اصطلاحات مشابه، ارائه یک ترجمه تشریحی از فرم کامل، و اضافه کردن مخفف انگلیسی در پرانتز است.
+
+این اختصارات را ترجمه نکنید، زیرا اکثر مردم با آنها آشنا نیستند و نسخه های بومی سازی شده برای اکثر بازدیدکنندگان منطقی نیست.
+
+نمونه ای از نحوه ترجمه dapps:
+
+- برنامه های غیرمتمرکز (dapps) → _فرم کامل ترجمه شده (مخفف انگلیسی در پرانتز)_
+
+## واژگانی بدون معادل های معین {#terms-without-established-translations}
+
+ممکن است برخی از اصطلاحات به زبان های دیگر ترجمه نشده باشند و به طور گسترده با اصطلاح اصلی انگلیسی شناخته می شوند. چنین اصطلاحاتی عمدتاً شامل مفاهیم جدیدتری مانند اثبات کار، اثبات سهام، بیکن چین، سهامگذاری و غیره هستند.
+
+در حالی که ترجمه این اصطلاحات می تواند غیرطبیعی به نظر برسد، از آنجایی که نسخه انگلیسی معمولاً در زبان های دیگر نیز استفاده می شود، توصیه می شود که آنها ترجمه شوند.
+
+هنگام ترجمه آنها، خلاقیت به خرج دهید، از ترجمه های تشریحی استفاده کنید یا به سادگی آنها را به معنای واقعی کلمه ترجمه کنید.
+
+**دلیل اینکه بیشتر اصطلاحات باید به جای ترک برخی به انگلیسی ترجمه شوند، این واقعیت است که این اصطلاحات جدید در آینده گستردهتر خواهند شد، زیرا افراد بیشتری استفاده از اتریوم و فناوری های مرتبط را شروع می کنند. اگر میخواهیم افراد بیشتری را از سراسر جهان به این فضا بفرستیم، باید اصطلاحات قابل فهمی را به هرچه بیشتر زبانهای ممکن ارائه کنیم، حتی اگر نیاز داشته باشیم خودمان آن را ایجاد کنیم.**
+
+## دکمهها و & CTAها {#buttons-and-ctas}
+
+وب سایت حاوی دکمه های متعددی است که باید متفاوت از سایر مطالب ترجمه شوند.
+
+متن دکمه را می توان با مشاهده اسکرین شات های زمینه، که با بیشتر رشته ها متصل است، یا با بررسی زمینه در ویرایشگر، که شامل عبارت "دکمه" است، شناسایی کرد.
+
+ترجمههای دکمهها باید تا حد امکان کوتاه باشند تا از عدم تطابق قالببندی جلوگیری شود. علاوه بر این، ترجمه دکمه باید ضروری باشد، یعنی یک دستور یا درخواست ارائه کنید.
+
+![چگونه یک button.png را پیدا کنیم](./how-to-find-a-button.png)
+
+## ترجمه برای عموم مردم جهان {#translating-for-inclusivity}
+
+بازدیدکنندگان Ethereum.org از سرتاسر جهان و از زمینه های علمی مختلف می آیند. بنابراین، زبان وبسایت باید خنثی و پذیرای همه باشد و نه انحصاری.
+
+یکی از جنبه های مهم این موضوع بی طرفی جنسیتی است. این را می توان با استفاده از فرم رسمی خطاب و پرهیز از هرگونه کلمه جنسیت خاص در ترجمه ها به راحتی به دست آورد.
+
+شکل دیگری از فراگیری، تلاش برای ترجمه برای مخاطبان جهانی است، نه خاص کشور، نژاد یا منطقه.
+
+در نهایت، زبان باید برای همه مخاطبان و سنین مناسب باشد.
+
+## ترجمههای خاص زبان {#language-specific-translations}
+
+هنگام ترجمه، مهم است که قوانین گرامری، قراردادها و قالببندی استفاده شده در زبان خود را به جای کپی کردن از منبع رعایت کنید. متن مبدأ از قوانین و قراردادهای دستور زبان انگلیسی پیروی می کند که برای بسیاری از زبان های دیگر قابل اجرا نیست.
+
+شما باید از قوانین زبان خود آگاه باشید و بر این اساس ترجمه کنید. اگر به کمک نیاز دارید، با ما تماس بگیرید و ما به شما کمک می کنیم تا منابعی در مورد نحوه استفاده از این عناصر در زبان خود پیدا کنید.
+
+چند نمونه از مواردی که باید به طور خاص به آن توجه داشت:
+
+### نشانه گذاری، قالب بندی {#punctuation-and-formatting}
+
+**حروف بزرگ**
+
+- تفاوت های زیادی در حروف بزرگ در زبان های مختلف وجود دارد.
+- در زبان انگلیسی رایج است که همه کلمات را در عناوین و نام ها، ماه ها و روزها، نام زبان ها، تعطیلات و غیره با حروف بزرگ بنویسند. در بسیاری از زبان های دیگر، این از نظر گرامری نادرست است، زیرا آنها قوانین حروف بزرگ متفاوتی دارند.
+- برخی از زبان ها نیز قوانینی در مورد بزرگ کردن ضمایر شخصی، اسم ها و صفت های خاص دارند که در انگلیسی حروف بزرگ نیستند.
+
+**فاصله گذاری**
+
+- قوانین املایی، استفاده از فاصله ها را برای هر زبان تعریف می کنند. از آنجایی که فاصله ها در همه جا استفاده می شوند، این قوانین جزو برخی از متمایزترینها هستند، و فاصلهها از برخی از عناصری هستند که اشتباه ترجمه شده اند.
+- برخی از تفاوت های رایج در فاصله بین انگلیسی و سایر زبان ها:
+ - فاصله قبل از واحدهای اندازه گیری و ارزها (به عنوان مثال USD، EUR، KB، MB)
+ - فاصله قبل از علائم درجه (به عنوان مثال °C و ℉)
+ - فاصله قبل از برخی از علائم نگارشی، به ویژه بیضی (…)
+ - فاصله قبل و بعد از اسلش (/)
+
+**لیستها**
+
+- هر زبانی مجموعه ای متنوع و پیچیده از قوانین برای نوشتن لیست ها دارد. اینها می توانند تفاوت قابل توجهی با انگلیسی داشته باشند.
+- در برخی از زبان ها، اولین کلمه هر خط جدید باید با حروف بزرگ باشد، در حالی که در برخی دیگر، خطوط جدید باید با حروف کوچک شروع شوند. بسیاری از زبان ها نیز بسته به طول هر خط، قوانین متفاوتی در مورد حروف بزرگ در لیست ها دارند.
+- همین امر در مورد علامت گذاری آیتم های خطی نیز صدق می کند. نقطه نگاری پایانی در لیست ها بسته به زبان می تواند نقطه (**.**)، کاما (**،**) یا نقطه ویرگول (**;**) باشد.
+
+**علامت نقل قول**
+
+- زبان ها از علامت های نقل قول مختلف استفاده می کنند. کپی کردن ساده نقل قول انگلیسی از منبع اغلب نادرست است.
+- برخی از رایج ترین انواع علامت نقل قول عبارتند از:
+ - „example text“
+ - ‚example text’
+ - »example text«
+ - “example text”
+ - ‘example text’
+ - «example text»
+
+**خط فاصله و خط تیره**
+
+- در زبان انگلیسی، خط فاصله (-) برای پیوستن کلمات یا قسمت های مختلف یک کلمه استفاده می شود، در حالی که خط تیره (–) برای نشان دادن محدوده یا مکث استفاده می شود.
+- بسیاری از زبان ها قوانین مختلفی برای استفاده از خط فاصله و خط تیره دارند که باید رعایت شود.
+
+### قالبها {#formats}
+
+**اعداد**
+
+- تفاوت اصلی در نوشتن اعداد در زبان های مختلف جداکننده ای است که برای اعشار و هزاران استفاده می شود. برای هزارگان، این می تواند نقطه، کاما یا فاصله باشد. به طور مشابه، برخی از زبان ها از نقطه اعشار استفاده می کنند، در حالی که برخی دیگر از کاما اعشاری استفاده می کنند.
+ - چند نمونه از اعداد بزرگ:
+ - انگلیسی – **1,000.50**
+ - اسپانیایی – **1.000,50**
+ - فرانسه – **1 000,50**
+- یکی دیگر از نکات مهم در هنگام ترجمه اعداد، علامت درصد است. می توان آن را به روش های مختلفی نوشت: **100%**، **100 %** یا **%100**.
+- در نهایت، اعداد منفی را می توان بسته به زبان به صورت متفاوتی نمایش داد: -100، 100-، (100) یا [100].
+
+**تاریخ**
+
+- هنگام ترجمه تاریخ، یکسری ملاحظات و تفاوت ها بر اساس زبان وجود دارد. اینها شامل قالب تاریخ، جداکننده، حروف بزرگ و صفرهای ابتدایی است. همچنین بین تاریخ های کامل و عددی تفاوت هایی وجود دارد.
+ - چند نمونه از فرمت های مختلف تاریخ:
+ - انگلیسی بریتانیا (dd/mm/yyyy) – 1st January, 2022
+ - انگلیسی امریکا (mm/dd/yyyy) – January 1st, 2022
+ - چینی (yyyy-mm-dd) – 2022 年 1 月 1 日
+ - فرانسه (dd/mm/yyyy) – 1er janvier 2022
+ - ایتالیایی (dd/mm/yyyy) – 1º gennaio 2022
+ - آلمانی (dd/mm/yyyy) – 1. Januar 2022
+
+**ارزها**
+
+- به دلیل فرمت ها، قراردادها و تبدیل های مختلف، ترجمه ارزها می تواند چالش برانگیز باشد. به عنوان یک قاعده کلی، لطفاً ارزها را همان منبع نگه دارید. میتوانید ارز محلی و تبدیل خود را در پرانتز اضافه کنید تا خواننده به نفع خود باشد.
+- تفاوت های اصلی در نوشتن ارزها در زبان های مختلف شامل قرار دادن نمادها، کاماهای اعشاری در مقابل اعشار، فاصله و اختصارات در مقابل نمادها است.
+ - محل قرارگیری سمبلها: 100$ یا $100
+ - ویرگول به عنوان اعشار یا نقطه به عنوان اعشار: مثلاً 100,50$ یا 100.50$
+ - فاصله گذاری: مثلاً 100$ یا 100 $
+ - مخفف یا سمبل: مثلاً 100 $ یا 100 USD
+
+**واحدهای اندازهگیری**
+
+- به عنوان یک قاعده کلی، لطفاً واحدهای اندازه گیری را مطابق منبع نگه دارید. اگر کشور شما از سیستم دیگری استفاده می کند، می توانید تبدیل آن را در پرانتز قرار دهید.
+- جدای از بومی سازی واحدهای اندازه گیری، توجه به تفاوت در نحوه رویکرد زبان ها به این واحدها نیز مهم است. تفاوت اصلی فاصله بین عدد و واحد است که بر اساس زبان می تواند متفاوت باشد. نمونه هایی از این شامل 100kB در مقابل 100 kB یا 50ºF در مقابل 50 ºF هستند.
+
+## نتيجه گيری {#conclusion}
+
+ترجمه ethereum.org فرصتی عالی برای آشنایی با جنبه های مختلف اتریوم است.
+
+هنگام ترجمه سعی کنید عجله نکنید. راحت باشید و لذت ببرید!
+
+از اینکه با برنامه ترجمه مشارکت داشتید و به ما کمک میکنید تا وبسایت را برای مخاطبان بیشتری در دسترس قرار دهید، سپاسگزاریم. جامعه اتریوم یک جامعه جهانی است و ما خوشحالیم که شما بخشی از آن هستید!
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md
new file mode 100644
index 00000000000..d99215d3d21
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md
@@ -0,0 +1,44 @@
+---
+title: افزودن پروژه های DeSci
+description: سیاستی که هنگام افزودن لینک به پروژهها در صفحه DeSci در ethereum.org استفاده میکنیم
+lang: fa
+---
+
+# افزودن پروژه ها {#adding-projects}
+
+ما میخواهیم مطمئن شویم که پروژههای متنوعی را نشان میدهیم و تصویر خوبی از چشمانداز DeSci ارائه میدهیم.
+
+هر کس آزاد است پروژه ای را برای فهرست کردن در صفحه DeSci در ethereum.org پیشنهاد کند. به همین ترتیب، هر کس که متوجه پروژهای شود که دیگر مرتبط نیست یا دیگر معیارهای واجد شرایط بودن ما را برآورده نمیکند، میتواند حذف آن را پیشنهاد دهد.
+
+## چارچوب تصمیمات {#the-decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#the-must-haves}
+
+- **کد/داده منبع باز** - باز بودن کد و داده، یک اصل اصلی DeSci است، بنابراین پروژه های DeSci نباید منبع بسته باشند. پایگاه کد باید در دسترس باشد و به طور ایده آل برای PRها باز باشد.
+- **پروژههای DeSci باید غیرمتمرکز باشند** - این میتواند شامل اداره شدن توسط یک DAO یا ساختن با پشته فناوری غیرمتمرکز از جمله کیفپولهای غیرمتمرکز باشد. احتمالاً شامل قراردادهای هوشمند قابل بازرسی در اتریوم است.
+- **اطلاعات لیستینگ صادقانه و دقیق** - انتظار می رود هر فهرست پیشنهادی از پروژه ها با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات خود را تحریف کنند، مانند منبع باز اعلان کردن کد پروژه در حالی که برخلاف واقعیت باشد، حذف خواهند شد.
+- **تعهد آشکار به گسترش دسترسی به علم** - یک پروژه DeSci باید بتواند نحوه مشارکت در علم را برای عموم مردم، نه فقط برای دارندگان توکن/NFT، بیان کند.
+- **دسترسیپذیری جهانی** - پروژه شما دارای محدودیتهای جغرافیایی یا الزامات KYC نباشد که افراد خاصی را از دسترسی به خدمات شما محروم میکند.
+- **وبسایت و مستندات اطلاعاتی** - مهم است که بازدیدکنندگان وبسایت پروژه بتوانند بفهمند که پروژه واقعاً چه میکند، چگونه به تمرکززدایی زیرساختهای علمی کمک میکند و افراد چگونه مشارکت میکنند.
+- **پروژه باید بخشی از اکوسیستم اتریوم باشد** - در ethereum.org ما معتقدیم که اتریوم (و لایههای 2 آن) لایه پایه مناسب برای جنبش DeSci است.
+- **پروژه نسبتاً به خوبی تثبیت شده است** - این پروژه دارای کاربران واقعی است که چندین ماه می توانند به خدمات پروژه دسترسی داشته باشند.
+
+### امتیازات ممکن
+
+- **در چندین زبان موجود است** - پروژه شما به چندین زبان ترجمه شده و به کاربران در سراسر جهان امکان دسترسی به آن را می دهد.
+- **منابع آموزشی** - محصول شما باید برای کمک به کاربران و آموزش آنها، یک تجربه نصب خوب طراحی شده داشته باشد. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
+- **ممیزی های طرف ثالث** - محصول شما به صورت حرفه ای از نظر آسیب پذیری توسط طرف ثالث مورد اعتماد بازرسی شده است.
+- **نقطه تماس** - یک نقطه تماس برای پروژه (این ممکن است توسط نماینده ای از یک DAO یا انجمن باشد) به ما کمک زیادی می کند تا هنگام ایجاد تغییرات اطلاعات دقیق را دریافت کنیم. این امر، بروزرسانی ethereum.org را در هنگام جمعآوری اطلاعات آینده قابل مدیریت نگه می دارد.
+
+## نگهداری {#maintenance}
+
+از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
+
+- اطمینان حاصل کنید که همه پروژه های لیست شده هنوز معیارهای ما را برآورده می کنند
+- بررسی کنید هیچ محصولی پیشنهاد نشده است که معیارهای ما را بیشتر از مواردی که در حال حاضر لیست شده است برآورده می کند
+
+Ethereum.org توسط جامعه منبع باز نگهداری می شود و ما به جامعه برای کمک به بهروز نگه داشتن این موضوع متکی هستیم. اگر متوجه هر گونه اطلاعات در مورد پروژه های لیست شده شدید که نیاز به بهروزرسانی دارند، لطفاً یک مسئله یا درخواست ادغام را در مخزن گیتهاب ما باز کنید.
+
+## شرایط استفاده {#terms-of-use}
+
+لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md
new file mode 100644
index 00000000000..2201c53b86c
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md
@@ -0,0 +1,61 @@
+---
+title: افزودن ابزار های توسعهدهنده
+lang: fa
+description: معیارهای ما برای فهرست کردن ابزارهای توسعه دهنده در ethereum.org
+---
+
+# در حال افزودن ابزار های توسعهدهنده {#contributing-to-ethereumorg-}
+
+ما میخواهیم مطمئن شویم که بهترین منابع توسعهدهنده ممکن را فهرست کردهایم تا افراد بتوانند با اعتماد به نفس ایجاد کنند و پشتیبانی مورد نیاز خود را داشته باشند.
+
+اگر ابزار توسعهدهنده مفیدی وجود دارد که ما آن را فراموش کرده ایم، آن را در جایی مناسب پیشنهاد کنید.
+
+ما در حال حاضر ابزارهای توسعه دهنده را در سرتاسر [پورتال توسعه دهنده](/developers/) خود فهرست میکنیم.
+
+**به راحتی می توانید موارد اضافه شده جدید را به صفحات مناسب پیشنهاد دهید.**
+
+## چگونه تصمیم می گیریم {#ways-to-contribute}
+
+ارسالیهای ابزار توسعه دهنده با معیارهای زیر ارزیابی می شوند:
+
+**آیا به طور عمده با ابزارهایی که قبلاً فهرست شده است متمایز است؟**
+
+- دسته ها یا انواع ابزارهای جدید
+- ویژگی های جدید در مقایسه با ابزارهای مشابه موجود
+- هدف گذاری شده در یک مورد خاص که توسط ابزارهای مشابه موجود پوشش داده نشده است
+
+**آیا ابزار به خوبی مستند شده است؟**
+
+- آیا مستندات وجود دارد؟
+- آیا استفاده از ابزار کافی است؟
+- آیا به تازگی به روز شده است؟
+
+**آیا ابزار به طور گسترده استفاده می شود؟**
+
+- ما معیارهایی مانند ستاره های GitHub، آمار دانلود، و اینکه آیا توسط شرکت ها یا پروژه های شناخته شده استفاده می شود را در نظر خواهیم گرفت
+
+**آیا ابزار از کیفیت کافی برخوردار است؟**
+
+- آیا اشکالات مکرر وجود دارد؟
+- آیا ابزار قابل اعتماد است؟
+- آیا ابزار به طور فعال نگهداری می شود؟
+
+**آیا ابزار منبع باز است؟**
+
+بسیاری از پروژه ها در فضای اتریوم منبع باز هستند. به احتمال زیاد ما پروژه های منبع باز را فهرست می کنیم که به توسعه دهندگان جامعه اجازه می دهند کد را بررسی کرده و در آن مشارکت کنند.
+
+---
+
+## سفارش محصول {#product-ordering}
+
+محصولات از قدیمی ترین تا جدیدترین محصول اضافه شده به صفحه نمایش داده می شوند، مگر اینکه محصولات به طور خاص مرتب شده باشند، مثلا بر اساس حروف الفبا. به عبارت دیگر، جدیدترین محصولات به انتهای لیست اضافه می شوند.
+
+---
+
+## ابزار توسعه دهنده خود را اضافه کنید {#how-decisions-about-the-site-are-made}
+
+اگر میخواهید یک ابزار توسعهدهنده را به ethereum.org اضافه کنید و معیارها را برآورده میکند، مسئلهای در GitHub ایجاد کنید.
+
+
+ افزودن مسئله
+
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md
new file mode 100644
index 00000000000..0bfad40bb95
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md
@@ -0,0 +1,40 @@
+---
+title: افزودن صرافی
+description: ضوابطی که ما به هنگام اضافه کردن صرافیها به وبسایت ethereum.org استفاده می کنیم
+lang: fa
+---
+
+# افزودن صرافیهای شبکه اتریوم {#adding-ethereum-exchanges}
+
+هر کس آزاد است اضافه شدن صرافیهای جدید به وبسایت ethereum.org را پیشنهاد دهد.
+
+در حال حاضر ما آنها را در اینجا فهرست کردهایم:
+
+- [ethereum.org/get-eth](/get-eth/)
+
+این صفحه به کاربر اجازه میدهد محل زندگی خود را به عنوان ورودی ارائه دهد و مشاهده کند که از چه صرافیهایی میتواند استفاده نماید. این کمک میکند تا هرگونه محدودیت جغرافیایی هرچه زودتر آشکار شود.
+
+بنابر همین موضوع، زمانی که شما یک صرافی را پیشنهاد میکنید ما به اطلاعات خاصی نیاز داریم.
+
+**نکته:** اگر میخواهید که یک صرافی غیرمتمرکز را فهرست کنید، نگاهی به [ضوابط ما برای فهرست نمودن کیف پولها و برنامههای غیرمتمرکز](/contributing/adding-products/) بیاندازید.
+
+## آنچه ما نیاز داریم {#what-we-need}
+
+- محدودیتهای جغرافیایی که بر صرافی اعمال میشوند. محدودیتهای جغرافیایی مرتبط با صرافی باید در صفحه یا بخش اختصاصی وبسایت صرافی به تفصیل بیان شوند.
+- ارزهایی که کاربران میتوانند استفاده کنند تا ETH بخرند
+- مدرک اثبات این که صرافی یک شرکت تجاری قانونی میباشد
+- هرگونه اطلاعات اضافی که ممکن است داشته باشید - این اطلاعات میتواند اطلاعاتی درباره شرکت مانند سالهای فعالیت، پشتوانه مالی و غیره باشد.
+
+ما به این اطلاعات نیازمندیم تا بتوانیم به صورت دقیق [به کاربران کمک کنیم تا صرافی را که میتوانند استفاده نمایند پیدا کنند](/get-eth/#country-picker).
+
+و همچنین ethereum.org میتواند اطمینان بیشتری داشته باشد که صرافی قانونی است و خدمات امن ارائه میدهد.
+
+---
+
+## صرافی خود را اضافه کنید {#add-exchange}
+
+اگر میخواهید یک صرافی را به ethereum.org اضافه نمائید، یک مسئله در وبسایت گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md
new file mode 100644
index 00000000000..c908ba2b000
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md
@@ -0,0 +1,26 @@
+---
+title: افزودن عبارات واژه نامه
+lang: fa
+description: ضوابط ما برای اضافه کردن یک عبارت به واژه نامه اتریوم
+---
+
+# افزودن عبارات واژه نامه {#contributing-to-ethereumorg-}
+
+فضای اتریوم روز به روز در حال تغییر است. اصطلاحات جدید دائماً وارد فرهنگ لغات کاربران اتریوم می شوند و ما به کمک شما برای گردآوری یک مرجع دقیق و به روز برای همه عبارات مربوط اتریوم نیاز داریم. نگاهی به [واژه نامه](/glossary/) کنونی ما بیاندازید سپس اگر میخواهید در بهبود آن کمک کنید متن پایین را مطالعه کنید!
+
+## معیارها {#criteria}
+
+اصطلاحات جدید واژه نامه بر اساس معیار های زیر بررسی میشوند:
+
+- آیا این اصطلاح/تعریف به روز است و منسوخ نشده است؟
+- آیا در حال حاضر عبارت مشابه آن در فرهنگ لغات وجود دارد؟ (اگر بله، فواید اضافه کردن اصطلاح جدید در مقابل بروزرسانی اصطلاحات موجود در واژه نامه را مقایسه کنید)
+- آیا عبارت/تعریف جدید عاری از تبلیغات محصول یا سایر محتوای تبلیغاتی است؟
+- آیا این اصطلاح/تعریف مستقیما به اتریوم مربوط میشود؟
+- آیا عبارت جدید تعریفی عینی، دقیق و عاری از قضاوت یا نظر شخصی دارد؟
+- آیا منبع قابل اعتماد است؟ آیا آنها منابع خود را اعلام کرده اند؟
+
+---
+
+## عبارت خود را اضافه کنید {#how-decisions-about-the-site-are-made}
+
+اگر میخواهید عبارتی به واژه نامه ethereum.org اضافه کنید که شرایط بالا را دارد، [درخواستی در گیتهاب ثبت کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml).
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md
new file mode 100644
index 00000000000..6dd2e94af0d
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md
@@ -0,0 +1,97 @@
+---
+title: افزودن لایه 2ها
+description: ضوابط ما برای اضافه کردن یک لایه 2 به ethereum.org
+lang: fa
+---
+
+# افزودن لایه 2ها {#adding-layer-2}
+
+ما میخواهیم مطمئن شویم که بهترین منابع ممکن را فهرست کرده باشیم تا کاربران بتوانند با خیالی آسوده از فضای لایه 2ها استفاده کنند.
+
+هر کس آزاد است اضافه شدن یک لایه 2 جدید را به ethereum.org پیشنهاد دهد. اگر یک لایه 2 وجود دارد که ما آن را از قلم انداختهایم، **[لطفاً آن را پیشنهاد کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!**
+
+در حال حاضر ما لایه 2ها را در صفحات زیر فهرست میکنیم:
+
+- [اندوخته های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)
+- [رولآپهای دانش-صفر](/developers/docs/scaling/zk-rollups/)
+- [لایه 2](/layer-2/)
+
+لایه 2 یک مفهوم و الگوی نسبتاً جدید و هیجان انگیز برای اتریوم است. ما تلاش کردیم که یک چارچوب منصفانه برای بررسی و فهرست در ethereum.org ایجاد کنیم، اما معیارهای فهرست بندی در طول زمان تغییر می کنند و تکامل می یابند.
+
+## چارچوب تصمیمات {#decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#criteria-for-inclusion-the-must-haves}
+
+**فهرست شدن در L2BEAT**
+
+- به منظور این که پروژه جهت فهرست شدن در نظر گرفته شود، باید قبلاً در [L2BEAT](https://l2beat.com) فهرست شده باشد. L2BEAT یک سنجش ریسک برجسته از پروژههای لایه 2 انجام میدهد که ما برای ارزیابی پروژه های لایه 2 به آن متکی هستیم. **اگر پروژهای در L2BEAT نشان داده نشده باشد، ما آن را به عنوان لایه 2 در ethereum.org فهرست نخواهیم کرد.**
+- [ببینید چگونه میتوانید پروژه لایه 2 خود را به L2BEAT اضافه کنید](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md).
+
+**کد منبع باز**
+
+- کد شما باید قابل دسترسی باشد و شما باید در گیتهاب، PRهایی از جامعه گستردهتر را قبول کنید.
+
+**دسته بندی لایه 2**
+
+ما در حال حاضر دسته های زیر را به عنوان راه حل لایه 2 در نظر میگیریم:
+
+- رول آپ خوش بینانه
+- رول آپ دانش صفر
+
+_ما راه حلهای مقیاس پذیر دیگری را که از اتریم به عنوان لایه امنیت یا لایه دسترسی به اطلاعات استفاده نمیکنند، لایه 2 در نظر نمیگیریم._
+
+**اتریوم برای دسترسی به اطلاعات**
+
+- در دسترس بودن اطلاعات یک معیار متمایز کننده میان لایه 2 و سایر راه حلهای مقیاس پذیری است. یک پروژه **باید** از شبکه اصلی اتریوم برای دسترسی به اطلاعات استفاده نماید تا برای فهرست شدن در نظر گرفته شود.
+
+**پل ها**
+
+- کاربران چگونه میتوانند به فضای این لایه 2 وارد شوند؟
+
+**تاریخی که پروژه عرضه و منتشر شد**
+
+- لایه 2 حداقل باید به مدت 6 ماه در شبکه اصلی اتریوم "زنده" بوده باشد
+
+- پروژههای جدیدی که هنوز توسط کاربران آزمایش نشدهاند، شانس کمتری برای فهرست شدن دارند.
+
+**حسابرسی امنیتی**
+
+- چه از طریق حسابرسی امنیتی برون سازمانی، تیم داخلی امنیت یا هر روش دیگری، امنیت محصول شما باید به شکل قابل اطمینان مورد آزمایش قرار گرفته باشد. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
+
+**پایگاه فعال کاربران**
+
+- ما معیارهایی همچون تاریخچه موجودی کل قفل شده یا TVL، آمار تراکنشها و اینکه آیا توسط شرکتها یا پروژههای شناخته شده استفاده میشود یا نه را در نظر میگیریم
+
+**تیم توسعه فعال**
+
+- ما یک لایه 2 را که یک تیم فعال ندارد که روی پروژه کار کند، لیست نخواهیم کرد.
+
+**جستجوگر بلوک**
+
+- پروژه های لیست شده نیازمند یک جستجوگر بلاک فعال هستند تا به کاربران اجازه دهند به راحتی در شبکه کاوش نمایند.
+
+### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#nice-to-haves}
+
+**پشتیبانی پروژه با صرافیها**
+
+- آیا کابران قادر به واریز و/یا برداشت مستقیم به/از یک صرافی هستند؟
+
+**لینک به اکوسیستم برنامه های غیرمتمرکز موجود در لایه 2**
+
+- ما علاقهمندیم بتوانیم اطلاعاتی را در مورد کارهایی که کاربران میتوانند انتظار داشته باشند در این لایه 2 انجام دهند، ارائه دهیم. (برای مثال https://portal.arbitrum.io/, https://www.optimism.io/apps)
+
+**فهرست قراردادهای توکن**
+
+- از آنجا که داراییها در لایه 2 آدرس جدیدی خواهند داشت، اگر منبعی از لیست توکنها وجود دارد، لطفاً آن را به اشتراک بگذارید.
+
+**پشتیبانی از کیف پول بومی**
+
+- آیا کیف پولها بهصورت بومی از لایه 2 پشتیبانی میکنند؟
+
+## لایه 2 خود را اضافه کنید {#add-exchange}
+
+اگر میخواهید یک لایه 2 را به ethereum.org اضافه نمائید، یک مسئله در وبسایت گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md
new file mode 100644
index 00000000000..a7c0a46e2c9
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md
@@ -0,0 +1,100 @@
+---
+title: افزودن محصولات
+description: سیاست و ضوابطی که ما به هنگام اضافه کردن محصولات به ethereum.org استفاده می کنیم
+lang: fa
+---
+
+# افزودن محصولات اتریوم {#adding-products}
+
+هر کسی آزاد است تا برنامه های غیرمتمرکز جدید را پیشنهاد دهد تا به محتوای ethereum.org، در محلی که مناسب آن است، اضافه شود. **خیر، ما برنامه غیرمتمرکز شما را به صفحه اصلی خود اضافه نخواهیم کرد** 😜
+
+لیست فعلی برنامه های غیرمتمرکز:
+
+- ethereum.org/dapps
+- ethereum.org/get-eth
+
+**لطفا فقط پیشنهادهای جدید را به این صفحه اضافه کنید.**
+
+اگرچه از افزودن پیشنهادهای جدید استقبال میکنیم، اما برنامههای غیرمتمرکز فعلی را بر اساس تجربهای که میخواهیم برای کاربرانمان ایجاد کنیم، انتخاب کردهایم. این معیارها بر اساس برخی از اصول طراحی ما میباشد:
+
+- _الهام بخش_: هر چیزی در ethereum.org، باید چیز جدیدی را به کاربران ارائه دهد
+- _یک داستان خوب_: آنچه فهرست شده باید یک لحظه "آهاااا فهمیدم" را برای کاربر ایجاد کند
+- _معتبر_: همه چیز باید کسب و کار/پروژه قانونی باشد تا خطر برای کاربران به حداقل برسد
+
+در کل، **ethereum.org میخواهد یک "تجربه ورود و استفاده آسان" را برای کاربران جدید فراهم نماید**. به همین دلیل، ما برنامه های غیرمتمرکز را بر اساس ویژگیهای زیر اضافه میکنیم:
+
+- سهولت در استفاده
+- سازگاری متقابل با سایر محصولات
+- امنیت
+- ماندگاری
+
+این هم از جزئیات بیشتر درباره چارچوب تصمیم گیری ما. برای ارائه بازخورد یا پیشنهاد تغییرات، درنگ نکنید.
+
+## چارچوب تصمیمات {#decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#criteria-for-inclusion-the-must-haves}
+
+- **محصول از منظر امنیتی آزمایش شده باشد** - چه از طریق حسابرسی امنیتی خارجی، از طریق یک تیم امنیت داخلی یا هر روش دیگر، امنیت محصول شما باید به طور قابل اتکا، آزمایش شود. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
+- **محصولی که بیش از 6 ماه "عرضه و منتشر" شده باشد** - این مهر تائید دیگری بر امنیت محصول میباشد. 6 ماه بازه زمانی مناسبی برای یافتن نواقص امنیتی و راههای هک کردن، میباشد.
+- **یک تیم فعال بر روی آن کار میکنند** - این مورد کیفیت محصول را تضمین میکند و به کاربر اطمینان خاطر میدهد که برای سؤالات و مشکلاتش پشتیبانی دریافت خواهد کرد.
+- **اطلاعات فهرست شده صادقانه و دقیق** - انتظار میرود هر گونه پیشنهاد پروژه ها، با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات ارسالی برای فهرست شدن را جعل می کنند، مانند اعلام "منبع باز" بودن محصول، در حالی که اینگونه نباشد، حذف خواهند شد.
+
+### معیارهای رتبه بندی: داشتن آنها خوب است {#criteria-for-ranking-the-nice-to-haves}
+
+به دلیل معیارهای زیر ممکن است برنامه غیرمتمرکز شما به اندازه سایرین در ethereum.org، به صورت برجسته نمایش داده نشود.
+
+**برنامه های غیرمتمرکز**
+
+- **بتوانید از طریق اکثر کیف پول های فهرست شده به آن دسترسی داشته باشید** - برنامههای غیرمتمرکز، باید با اکثر کیف پول هایی که در ethereum.org فهرست شده اند کار کنند.
+- **کاربران بتوانند خودشان آن را امتحان کنند -** یک کاربر باید بتواند از نرمافزار غیرمتمرکز شما استفاده کند و به نتیجهای ملموس دست یابد.
+- **سهولت در جذب کاربر** - محصول شما باید دارای یک تجربه ساده ورود و استفاده باشد و کاربران بتوانند کمک دریافت کنند و آموزش ببینند. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
+- **غیرسرپرستی** - کاربران خودشان وجوه خود را کنترل کنند. اگر پروژه و محصول شما زمانی ناپدید شود، کاربران همچنان بتوانند به وجوه خود دسترسی داشته باشند و آن را جابجا کنند.
+- **قابل دسترسی جهانی** - محصول شما دارای محدودیتهای جغرافیایی یا الزامات KYC نباشد که افراد خاصی را از دسترسی به خدمات شما محروم کند.
+- **کد منبع باز** - کد شما باید در دسترس باشد و باید PRها را از جامعه گستردهای بپذیرید.
+- **جامعه پروژه** - شما باید یک جامعه اختصاصی داشته باشید، میتواند در برنامه Discord باشد که در آن کاربران میتوانند با تیم شما برای دریافت کمک یا پیشنهاد ویژگیهای جدید تعامل داشته باشند.
+
+## معیارهای در حال اجرا {#criteria-in-practice}
+
+هرچه تعداد بیشتری از معیارها را پر کنید، احتمال بیشتری وجود دارد که محصول شما به ethereum.org راه پیدا کند.
+
+اگر یک محصول جدید پیشنهاد شود که معیارهای ضروری و برخی از غیر ضروریها را داشته باشد، محصول فهرست شدهای که فقط معیارهای ضروری را داشته باشد ممکن است حذف شود.
+
+موارد دیگری که در این تصمیم موثر هستند:
+
+- آیا اضافه کردن محصول به فهرست به جای جایگزینی آن با محصولی دیگر، باعث به هم ریختن صفحه می شود؟
+ - سایت ما در درجه اول آموزشی است و هدف اصلی آن توضیح اتریوم و مفاهیم مربوط به آن است. با افزودن گزینه های بسیار زیاد برای کاربران، ممکن است صفحات کمتر قابل خواندن و در نتیجه کمتر مفید باشند.
+- آیا صفحه کنونی، کاربر را با انتخابهای متعدد فلج می کند؟
+ - درست مثل زمانی که ساعتها در حال مرور Netflix مینشینید زیرا نمیتوانید در مورد چیزی برای تماشا تصمیم بگیرید. بمباران کردن کاربران جدید با انتخابهای بیش از حد، یک ریسک است.
+
+این یک تصمیم در طراحی است که ethereum.org مسئول آن است.
+
+اما مطمئن باشید، **لینکهایی به وبسایتهای دیگر وجود خواهد داشت که برنامههای غیرمتمرکز بیشتری را رتبهبندی میکنند**
+
+### سفارش محصول {#product-ordering}
+
+محصولات از جدیدترین تا قدیمیترین زمان اضافه شدن نمایش داده می شوند، مگر اینکه ترتیب محصولات به طور خاصی باشد، برای مثال بر اساس حروف الفبا. به عبارت دیگر، جدیدترین محصولات به انتهای لیست اضافه می شوند.
+
+### شرایط استفاده {#terms-of-use}
+
+لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
+
+## نگهداری {#maintenance}
+
+از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
+
+- اطمینان حاصل کنیم که همه برنامههای لیست شده هنوز معیارهای ما را برآورده می کنند
+- اطمینان حاصل کنیم هیچ محصولی پیشنهاد نشده باشد که معیارهای بیشتری از محصولات فهرست شده فعلی را رعایت کند و آن را اضافه نکرده باشیم
+
+شما می توانید با بررسی و اطلاع رسانی در این مورد کمک کنید. [یک مسئله در گیتهاب ایجاد کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) یا یک ایمیل به [website@ethereum.org](mailto:website@ethereum.org) ارسال کنید
+
+_ما همچنین در حال بررسی گزینههای رأیگیری هستیم تا جامعه اتریوم بتواند اولویتهای خود را نشان دهد و بهترین محصولات موجود را برای توصیه ما برجسته کند._
+
+---
+
+## محصول خود را اضافه کنید {#add-your-product}
+
+اگر می خواهید یک برنامه غیرمتمرکز به ethereum.org اضافه کنید که معیارها را رعایت می کند، در وبسایت GitHub یک مسئله ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md
new file mode 100644
index 00000000000..79eb75fd7fd
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md
@@ -0,0 +1,176 @@
+---
+title: افزودن محصولات یا خدمات سهامگذاری
+description: سیاستی که هنگام افزودن محصولات یا سرویسهای سهامگذاری به ethereum.org استفاده میکنیم
+lang: fa
+---
+
+# افزودن محصولات یا خدمات سهامگذاری {#adding-staking-products-or-services}
+
+ما می خواهیم مطمئن شویم که بهترین منابع ممکن را فهرست می کنیم و در عین حال کاربران را ایمن و مطمئن نگه می داریم.
+
+هر کس میتواند آزادانه پیشنهاد اضافه کردن محصولات یا خدمات سهامگذاری را در ethereum.org بدهد. اگر موردی وجود دارد که از قلم افتاده است، **[لطفاً آن را پیشنهاد دهید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!**
+
+ما در حال حاضر محصولات و خدمات سهامگذاری را در صفحات زیر فهرست می کنیم:
+
+- [سهام گذاری انفرادی](/staking/solo/)
+- [سهامگذاری بهعنوان یک خدمت](/staking/saas/)
+- [استخرهای سهامگذاری](/staking/pools/)
+
+اثبات سهام از 1 دسامبر 2020 در بیکن چین فعال است. در حالی که سهامگذاری هنوز نسبتاً جدید است، ما سعی کرده ایم یک چارچوب منصفانه و شفاف برای بررسی در ethereum.org ایجاد کنیم، اما معیارهای فهرست کردن در طول زمان تغییر می کند و تکامل می یابد و در نهایت به صلاحدید تیم وب سایت ethereum.org است.
+
+## چارچوب تصمیمات {#the-decision-framework}
+
+تصمیم برای فهرست کردن یک محصول در ethereum.org به هیچ عاملی بستگی ندارد. هنگام تصمیم گیری برای فهرست کردن یک محصول یا خدمات، چندین معیار با هم در نظر گرفته می شوند. هر چه تعداد این معیارها بیشتر باشد، احتمال فهرست شدن آن بیشتر است.
+
+**اول اینکه از کدام دسته از محصولات یا خدمات است؟**
+
+- ابزار گره یا کاربر
+- مدیریت کلید
+- سهام گذاری به عنوان یک سرویس (SaaS)
+- استخر سهامگذاری
+
+در حال حاضر، ما فقط محصولات یا خدمات را در این دسته بندی ها فهرست می کنیم.
+
+### معیارهای شمول {#criteria-for-inclusion}
+
+محصولات یا خدمات سهامگذاری با معیارهای زیر ارزیابی می شوند:
+
+**پروژه یا سرویس چه زمانی راه اندازی شد؟**
+
+- آیا شواهدی وجود دارد که نشان دهد محصول یا خدمت چه زمانی در دسترس عموم قرار گرفت؟
+- این برای تعیین امتیاز "نبرد آزمایش شده" محصولات استفاده می شود.
+
+**آیا از پروژه به طور فعال نگهداری می شود؟**
+
+- آیا یک تیم فعال در حال توسعه پروژه وجود دارد؟ چه افرادی دخیل هستند؟
+- فقط محصولاتی که به طور فعال نگهداری می شوند در نظر گرفته خواهند شد.
+
+**آیا محصول یا خدمات فاقد واسطه های قابل اعتماد/انسانی است؟**
+
+- چه مراحلی در تجربه کاربران، نیازمند اعتماد به انسانها برای نگه داشتن کلیدهای سرمایهشان یا توزیع صحیح جوایز است؟
+- این برای تعیین امتیاز "بی اعتماد" محصول یا خدمات استفاده می شود.
+
+**آیا پروژه اطلاعات دقیق و قابل اعتمادی را ارائه می دهد؟**
+
+- بسیار مهم است که وب سایت محصول دارای اطلاعات به روز، دقیق و غیر گمراه کننده باشد، به خصوص اگر مربوط به پروتکل اتریوم یا سایر فناوری های مرتبط باشد.
+- موارد ارسالی حاوی اطلاعات نادرست، جزئیات قدیمی، یا اظهارات احتمالی گمراه کننده در مورد اتریوم یا سایر موضوعات مرتبط، فهرست نخواهند شد یا اگر قبلاً فهرست شده باشند حذف خواهند شد.
+
+**چه پلتفرم هایی پشتیبانی می شوند؟**
+
+- یعنی Linux, macOS, Windows, iOS, Android
+
+#### نرم افزار و قراردادهای هوشمند {#software-and-smart-contracts}
+
+برای هر نرم افزار سفارشی یا قراردادهای هوشمند درگیر:
+
+**آیا همه چیز منبع باز است؟**
+
+- پروژه های منبع باز باید یک مخزن کد منبع در دسترس عموم داشته باشند
+- این برای تعیین امتیاز "منبع باز" محصولات استفاده می شود.
+
+**آیا محصول از مرحله توسعه _بتا_ خارج شده است؟**
+
+- محصول در چرخه توسعه خود در کجا قرار دارد؟
+- محصولات در مرحله بتا برای درج در ethereum.org در نظر گرفته نمی شوند
+
+**آیا نرم افزار مورد بازرسی امنیتی خارجی قرار گرفته است؟**
+
+- اگر نه، آیا برنامه ای برای انجام ممیزی خارجی وجود دارد؟
+- این برای تعیین امتیاز "ممیزی شده" محصولات استفاده می شود.
+
+**آیا پروژه دارای برنامه پاداش باگ است؟**
+
+- اگر نه، آیا برنامهای برای ایجاد جایزه باگ امنیتی وجود دارد؟
+- از این برای تعیین امتیاز "جایزه باگ" محصولات استفاده می شود.
+
+#### ابزار گره یا کاربر {#node-or-client-tooling}
+
+برای محصولات نرم افزاری مرتبط با تنظیم، مدیریت یا مهاجرت گره یا کاربر:
+
+**کدام کاربر لایه اجماع (به عنوان مثال. Lighthouse, Teku, Nimbus, Prysm) پشتیبانی می شود؟**
+
+- کدام کاربرها پشتیبانی می شوند؟ آیا کاربر می تواند انتخاب کند؟
+- این برای تعیین امتیاز "چند کاربری" محصولات استفاده می شود.
+
+#### سهامگذاری بهعنوان یک خدمت {#staking-as-a-service}
+
+برای [فهرستهای سهامگذاری به عنوان خدمات](/staking/saas/) (به عنوان مثال عملیات گره واگذار شده):
+
+**هزینه های مربوط به استفاده از خدمات چیست؟**
+
+- ساختار هزینه چگونه است، به عنوان مثال. آیا هزینه ماهانه برای خدمات وجود دارد؟
+- آیا سهام گذاری اضافی وجود دارد؟
+
+**آیا کاربران ملزم به ثبت نام برای یک حساب کاربری هستند؟**
+
+- آیا کسی می تواند بدون اجازه یا KYC از این سرویس استفاده کند؟
+- این برای تعیین امتیاز "بدون مجوز" محصولات استفاده می شود.
+
+**چه کسی کلیدهای امضا، و کلیدهای برداشت را در اختیار دارد؟**
+
+- کاربر به چه کلیدهایی دسترسی دارد؟ سرویس به چه کلیدهایی دسترسی پیدا می کند؟
+- این برای تعیین امتیاز "بی اعتماد" محصولات استفاده می شود.
+
+**تنوع مشتری گره های در حال بهره برداری چیست؟**
+
+- چند درصد از کلیدهای اعتبارسنج توسط مشتری لایه اجماع اکثریت (CL) اجرا می شود؟
+- در آخرین ویرایش، Prysm کاربر لایه اجماع است که توسط اکثر اپراتورهای گره اجرا می شود، که برای شبکه خطرناک است. اگر هر کاربر CL در حال حاضر توسط بیش از 33٪ از شبکه استفاده می شود، ما اطلاعات مربوط به استفاده از آن را درخواست می کنیم.
+- این برای تعیین امتیاز "مشتریان متنوع" محصولات استفاده می شود.
+
+#### استخر سهامگذاری {#staking-pool}
+
+برای [خدمات سهامداری ادغام شده](/staking/pools/):
+
+**حداقل ETH مورد نیاز برای سهام گذاری چیست؟**
+
+- مثلا 0.01 ETH
+
+**کارمزدها یا الزامات مربوط به سهام گذاری چیست؟**
+
+- چند درصد از پاداش ها به عنوان کارمزد حذف می شود؟
+- آیا سهام گذاری اضافی وجود دارد؟
+
+**آیا توکن نقدینگی وجود دارد؟**
+
+- توکن ها شامل چه مواردی می شوند؟ چطور کار می کنند؟ آدرس های قرارداد چیست؟
+- این برای تعیین امتیاز "توکن نقدینگی" محصولات استفاده می شود.
+
+**آیا کاربران می توانند به عنوان یک اپراتور گره شرکت کنند؟**
+
+- برای اجرای کاربران اعتبارسنج با استفاده از وجوه ادغام شده چه چیزی لازم است؟
+- آیا این به مجوز یک فرد، شرکت یا DAO نیاز دارد؟
+- این برای تعیین امتیاز "گره های بدون مجوز" محصولات استفاده می شود.
+
+**تنوع کاربر اپراتورهای گره استخر چیست؟**
+
+- چند درصد از اپراتورهای گره کاربر لایه اجماع اکثریت (CL) را اجرا می کنند؟
+- در آخرین ویرایش، Prysm کاربر لایه اجماع است که توسط اکثر اپراتورهای گره اجرا می شود، که برای شبکه خطرناک است. اگر هر کاربر CL در حال حاضر توسط بیش از 33٪ از شبکه استفاده می شود، ما اطلاعات مربوط به استفاده از آن را درخواست می کنیم.
+- این برای تعیین امتیاز "مشتریان متنوع" محصولات استفاده می شود.
+
+### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#other-criteria}
+
+**چه رابط های کاربری پشتیبانی می شوند؟**
+
+- یعنی Browser app, desktop app, mobile app, CLI
+
+**برای ابزار گره، آیا نرم افزار راه آسانی برای جابجایی بین مشتریان ارائه می دهد؟**
+
+- آیا کاربر می تواند به راحتی و با خیال راحت مشتریان را با استفاده از ابزار تغییر دهد؟
+
+**برای SaaS، چند اعتباردهنده در حال حاضر توسط این سرویس کار میکنند؟**
+
+- این به ما ایده ای از میزان دسترسی شما تا کنون می دهد.
+
+## نحوه نمایش نتایج {#product-ordering}
+
+[معیارهای گنجاندن](#criteria-for-inclusion) بالا برای محاسبه امتیاز تجمیعی برای هر محصول یا خدمات استفاده میشود. این به عنوان وسیله ای برای مرتب سازی و نمایش محصولاتی که معیارهای عینی خاصی دارند استفاده می شود. هر چه معیارهای بیشتری برای شواهد ارائه شود، محصول در رده بالاتر مرتب می شود و پیوندها بر اساس بار تصادفی می شوند.
+
+منطق کد و وزن این معیارها در حال حاضر در [این جزء جاوا اسکریپت](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) در مخزن ما موجود است.
+
+## محصول یا سرویس خود را اضافه کنید {#add-product}
+
+اگر میخواهید محصول یا خدماتی را به ethereum.org اضافه کنید، یک مسئله در گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md
new file mode 100644
index 00000000000..8f1e1e21f81
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md
@@ -0,0 +1,80 @@
+---
+title: افزودن کیف پول
+description: سیاستی که هنگام افزودن کیفپول به ethereum.org استفاده می کنیم
+lang: fa
+---
+
+# افزودن کیف پول {#adding-wallets}
+
+ما میخواهیم مطمئن شویم که یک طیف گسترده از کیف پولهایی را که کاربران به وسیله آنها میتوانند از ویژگیهای غنی اتریوم استفاده نمایند را نشان میدهیم.
+
+هر کس میتواند اضافه شدن کیف پول جدید به سایت ethereum.org را پیشنهاد کند. اگر کیف پولی وجود دارد که آن را جا انداختیم، لطفاً آن را پیشنهاد دهید!
+
+لیست کیف پولهای فعلی:
+
+- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/)
+
+کیف پولها به سرعت در اتریوم تغییر میکنند. ما تلاش کردیم که یک چارچوب منصفانه برای بررسی و فهرست در ethereum.org ایجاد کنیم، اما معیارهای فهرست بندی در طول زمان تغییر می کنند و تکامل می یابند.
+
+## چارچوب تصمیمات {#the-decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#the-must-haves}
+
+- **امنیت محصول آزمایش شده باشد** - امنیت کیف پول شما از طریق حسابرسی امنیتی، تیم داخلی امنیت، منبع باز بودن کد یا سایر روشها، باید کاملاً تضمین شده باشد. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
+- **کیف پول حداقل به مدت شش ماه برای استفاده در دسترس بوده یا توسط یک گروه معتبر و با شهرت قابل ردیابی عرضه شده باشد** - این امر نشان دیگر امنیت است. شش ماه بازه زمانی مناسبی برای یافتن نقصهای امنیتی حیاتی میباشد. همچنین گذشت شش ماه به تمایز پروژههای معتبر با پروژههایی که صرفا فورک شدهاند کمک میکند.
+- **یک تیم فعال بر روی آن کار میکنند** - این مورد کیفیت کیف پول را تضمین میکند و به کاربر اطمینان میدهد که برای سؤالات و مشکلاتش پشتیبانی دریافت خواهد کرد.
+- **اطلاعات فهرست شده صادقانه و دقیق** - انتظار میرود هر گونه پیشنهاد پروژه ها، با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات خود را تحریف کنند، مانند منبع باز اعلان کردن کد پروژه در حالی که برخلاف واقعیت باشد، حذف خواهند شد.
+- **نقطه تعامل** - یک نقطه تعامل با کیف پول کمک بزرگی به ما میکند تا به هنگام اعمال تغییرات اطلاعات دقیقی کسب نمائیم. این امر، بروزرسانی ethereum.org را در هنگام جمعآوری اطلاعات آینده قابل مدیریت نگه می دارد.
+- **تراکنشهای EIP-1559 (نوع2)** - کیف پول شما باید از تراکنشهای EIP-1559 (نوع2) برای تراکنشهای شبکه اصلی اتریوم پشتیبانی کند.
+- **تجربه کاربری خوب** - در حالی که UX یک مفهوم ذهنی است، اگر چندین عضو اصلی تیم محصول را آزمایش کنند و استفاده از آن دشوار باشد، ما حق عدم تایید کیفپول را برای خود محفوظ می داریم و در عوض پیشنهادهای مفیدی برای بهبود ارائه می دهیم. این کار برای محافظت از پایگاه کاربرانمان که عمدتاً از مبتدیان تشکیل شده است انجام میشود.
+
+### حذف محصول {#product-removals}
+
+- **اطلاعات به روز شده** - ارائه دهندگان کیفپول مسئول ارسال مجدد اطلاعات کیفپول خود هر 6 ماه یکبار برای اطمینان از اعتبار و مرتبط بودن اطلاعات ارائه شده هستند (حتی اگر هیچ تغییری در محصول آنها وجود نداشته باشد). اگر تیم محصول نتواند این کار را انجام دهد، ethereum.org ممکن است پروژه را از صفحه حذف کند.
+
+### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#the-nice-to-haves}
+
+- **دسترسیپذیری جهانی** - کیفپول شما دارای محدودیت های جغرافیایی یا الزامات KYC نیست که افراد خاصی را از دسترسی به خدمات شما محروم می کند.
+- **به چندین زبان موجود است** - کیف پول شما به چندین زبان ترجمه شده است و به کاربران در سراسر جهان امکان دسترسی به آن را می دهد.
+- **منبع باز** - کل پایگاه کد پروژه شما (نه فقط ماژول ها) باید در دسترس باشد و باید روابط عمومی از جامعه گستردهتر را بپذیرید.
+- **غیرسرپرستی** - کاربران وجوه خود را کنترل می کنند. اگر پروژه و محصول شما زمانی ناپدید شود، کاربران همچنان بتوانند به وجوه خود دسترسی داشته باشند و آن را جابجا کنند.
+- **پشتیبانی از کیف پول سخت افزاری** - کاربران می توانند کیف پول سخت افزاری خود را برای امضای تراکنش ها متصل کنند.
+- **WalletConnect** - کاربران می توانند با استفاده از WalletConnect به دپها (dapps) متصل شوند.
+- **وارد کردن نقاط پایانی RPC اتریوم ** - کاربران میتوانند دادههای RPC گره را وارد کنند و به آنها امکان میدهد به گره مورد نظر خود یا سایر شبکههای سازگار با EVM متصل شوند.
+- **NFT ها** - کاربران می توانند NFT های خود را در کیف پول مشاهده کرده و با آنها تعامل داشته باشند.
+- **اتصال به برنامه های اتریوم** - کاربران می توانند به برنامه های اتریوم متصل شوند و از آنها استفاده کنند.
+- **سهامگذاری** - کاربران میتوانند مستقیماً از طریق کیف پول اقدام به سهامگذاری کنند.
+- **سوآپها** - کاربران میتوانند توکنها را از طریق کیف پول سوآپ کنند.
+- **شبکه های چند زنجیره ای** - کیف پول شما به طور پیش فرض از دسترسی کاربران به چندین شبکه بلاکچین پشتیبانی می کند.
+- **شبکه های لایه 2** - کیف پول شما به طور پیش فرض از دسترسی کاربران به شبکه های لایه 2 پشتیبانی می کند.
+- **سفارشی کردن کارمزدهای گس** - کیف پول شما به کاربران امکان می دهد کارمز گس تراکنش خود را سفارشی کنند (کارمزد پایه، کارمزد اولویت، حداکثر کارمزد).
+- **پشتیبانی از ENS** - کیف پول شما به کاربران امکان می دهد تراکنش ها را به نام های ENS ارسال کنند.
+- **پشتیبانی از ERC-20** - کیف پول شما به کاربران امکان می دهد آدرس قراردادهای توکن ERC-20 را وارد کنند یا به طور خودکار توکن های ERC-20 را جستجو و نمایش دهند.
+- **خرید رمزارز** - کیف پول شما از کاربرانی پشتیبانی میکند که مستقیماً رمزارز را خریداری میکنند و به آن متصل میشوند.
+- **فروش به قیمت فیات** - کیف پول شما از کاربرانی پشتیبانی میکند که مستقیماً به کارت یا حساب بانکی به فیات بفروشند و برداشت کنند.
+- **چندامضایی** - کیف پول شما از چندین امضا برای امضای تراکنش پشتیبانی می کند.
+- **بازیابی اجتماعی** - کیف پول شما از نگهبانان پشتیبانی میکند و اگر کاربر عبارت اصلی خود را با استفاده از این محافظها گم کند، میتواند کیف پول خود را بازیابی کند.
+- **تیم پشتیبانی اختصاصی** - کیف پول شما دارای یک تیم پشتیبانی اختصاصی است که کاربران می توانند در صورت بروز مشکلات به آن مراجعه کنند.
+- **منابع/اسناد آموزشی** - محصول شما باید یک تجربه نصب خوب طراحی شده برای کمک و آموزش کاربران داشته باشد. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
+
+## افزودن یک کیف پول {#adding-a-wallet}
+
+اگر میخواهید یک کیف پول به ethereum.org اضافه کنید، یک مسئله در گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
+
+## نگهداری {#maintenance}
+
+از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
+
+- اطمینان حاصل کنید که همه کیف پول ها و دپ های لیست شده هنوز معیارهای ما را برآورده می کنند.
+- اطمینان حاصل کنیم هیچ محصولی پیشنهاد نشده باشد که معیارهای بیشتری از محصولات فهرست شده فعلی را رعایت کند و آن را اضافه نکرده باشیم
+
+ethereum.org توسط جامعه منبع باز نگهداری می شود و ما به جامعه برای کمک به بهروز نگه داشتن این موضوع متکی هستیم. اگر متوجه هر گونه اطلاعاتی در مورد کیف پول های لیست شده اید که باید به روز شوند، لطفاً [یک مسئله باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) یا [درخواستهای ادغام](https://github.com/ethereum/ethereum-org-website/pulls) ارسال کنید!
+
+
+## شرایط استفاده {#terms-of-use}
+
+لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md b/public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md
new file mode 100644
index 00000000000..0788f58b182
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md
@@ -0,0 +1,32 @@
+---
+title: اضافه کردن منابع محتوا
+lang: fa
+description: معیارهای ما برای لیست کردن منابع محتوا در ethereum.org
+---
+
+# اضافه کردن منابع محتوا {#adding-content-resources}
+
+ما نمی توانیم امیدوار باشیم که همه چیز Ethereum را پوشش دهیم بنابراین سعی می کنیم برخی از مقالات، آموزش ها، خبرنامه ها، صفحه های شغلی و منابع محتوایی مختلف را که جامعه ایجاد می کند به نمایش بگذاریم. این موارد اغلب اطلاعات عمیق تری در مورد موضوعاتی که کاربران ممکن است به آن ها علاقه مند باشند، فراهم می کنند.
+
+اگر یک منبع محتوایی وجود دارد که احساس می کنید باید به یک صفحه اضافه شود، با خیال راحت آن را در جایی مناسب پیشنهاد دهید.
+
+## چگونه تصمیم می گیریم {#how-we-decide}
+
+منابع یادگیری با معیارهای زیر ارزیابی خواهند شد:
+
+- آیا محتوا به روز است?
+- آیا برای محتوا پرداخت هم هست؟
+- آیا اطلاعات دقیق هستند؟ آیا واقعی است یا مبتنی بر نظر؟
+- آیا نویسنده قابل اعتماد است؟ آیا آنها منابع خود را اعلام کرده اند؟
+- آیا این محتوا ارزش متمایزی دارد که منابع/لینک های موجود پوشش نمی دهند؟
+- آیا این محتوا به درد یکی از [شخصیت های کاربری](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c) ما می خورد؟
+
+---
+
+## منابع محتوای خود را اضافه کنید {#add-your-content-resource}
+
+اگر می خواهید یک منبع محتوا به ethereum.org اضافه کنید و معیارها را رعایت می کند، در GitHub یک مسئله ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md b/public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md
new file mode 100644
index 00000000000..c6fb9945253
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md
@@ -0,0 +1,69 @@
+---
+title: افزودن منابع طراحی
+description: دستورالعمل ها و الزامات برای اطمینان از کیفیت مواد طراحی در ethereum.org
+lang: fa
+---
+
+# افزودن منابع طراحی {#adding-design-resources}
+
+هر کسی می تواند مواد طراحی جدید را به [طراحی و تجربه کاربری در صفحه Web3](/developers/docs/design-and-ux/) پیشنهاد دهد.
+
+توجه داشته باشید که تمرکز این صفحه بر ارائه ارزش کاربری به طراحان مشتاق Web3 است. بخش طراحی، برای تبلیغ خدمات، محصولات یا پلتفرم های شما نیست.
+
+برای اطمینان از استاندارد بالای اطلاعات و ترویج بینشهای ارزشمند، ما یک خطمشی فهرستبندی ایجاد کردهایم:
+
+## مطالعات پژوهشی و داشبوردها {#Research-studies}
+
+1. روش شناسی منطقی
+
+الف. روش باید به وضوح نحوه جمع آوری داده ها را مشخص کند.
+
+ب. تعداد شرکت کنندگان در تحقیق باید ذکر شود.
+
+ج. روش های تحقیق مورد استفاده باید شرح داده شود.
+
+2. ارتباط با طراحان Web3 و موارد استفاده معمول طراحی
+
+الف. موضوع تحقیق باید با طراحان Web3 مرتبط باشد و به موارد استفاده رایج از طراحی بپردازد.
+
+3. بر ارائه دیدگاه تمرکز کنید
+
+الف. هدف اصلی متن باید به اشتراک گذاشتن دیدگاه باشد تا ترویج یک پروژه یا شرکت خاص.
+
+## مقالات {#Articles}
+
+1. ارتباط با طراحان/محققان Web3 و موارد استفاده معمول طراحی Web3
+
+الف. موضوع مقاله باید مربوط به طراحان و محققان Web3 باشد و بر موارد استفاده از طراحی Web3 متداول متمرکز باشد.
+
+2. کیفیت پایه نگارش
+
+الف. مقاله باید عاری از اشتباهات گرامری و املایی باشد.
+
+ب. باید بر ارائه دیدگاه ها و مطالب کلیدی تاکید شود.
+
+ج. نوشته باید مختصر و دقیق باشد.
+
+3. هدف مقاله
+
+الف. هدف اصلی مقاله باید به اشتراک گذاشتن دیدگاه باشد تا تبلیغ یک پروژه یا شرکت خاص.
+
+## جوامع / DAOها {#Communities-and-DAOs}
+
+1. وبسایت باید به وضوح نحوه پیوستن به DAO/جامعه را نشان دهد
+
+2. مزایای آشکار عضویت
+
+الف. مزایای عضویت باید به طور برجسته نشان داده شوند.
+
+**مثالها**: دریافت بازخورد در مورد کار، دسترسی به فرصتهای شغلی یا جوایز، اشتراکگذاری دیدگاه های طراحی و تحقیق.
+
+3. ارتباط فعال و پر جنب و جوش در دیسکورد
+
+الف. جامعه دیسکورد باید ارتباط پر جنب و جوش و فعالی را به نمایش بگذارد.
+
+ب. مدیران باید به طور فعال در حفظ جامعه و تسهیل بحث ها مشارکت داشته باشند.
+
+ج. جامعه باید سابقه مکالمات ارزشمند و سازنده را در دو هفته گذشته نشان دهد.
+
+با رعایت این معیارها، هدف ما ایجاد یک محیط پر رونق و به اشتراکگذاری دانش در جامعه است. ما معتقدیم که این خط مشی لیست مجاز تضمین می کند که کاربران ما به منابع قابل اعتماد، مرتبط و روشنگر دسترسی دارند. از درک و همکاری شما در حفظ کیفیت محتوا در بستر ما سپاسگزاریم.
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md b/public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md
new file mode 100644
index 00000000000..77c2a880896
--- /dev/null
+++ b/public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md
@@ -0,0 +1,62 @@
+---
+title: اضافه کردن یک آزمون
+description: سیاستی که هنگام اضافه کردن آزمونها به ethereum.org استفاده میکنیم
+lang: fa
+---
+
+# آزمون ها {#quizzes}
+
+آزمونها فرصتی هستند برای کاربران تا خود را امتحان کنند و ببینند آیا محتوای صفحهای که تازه خواندهاند را درک کردهاند یا نه. سؤالات باید فقط بر اساس محتوای ارائه شده در صفحه باشند و نباید درباره اطلاعاتی که در صفحه ذکر نشده است، پرسیده شوند.
+
+ساختار سؤالات باید به صورت زیر باشد. متن سؤال، یک پاسخ صحیح با توضیح دلیل صحت آن، و سه پاسخ نادرست هر کدام با توضیح درباره دلیل نادرست بودنشان.
+
+برای مشاهده برخی نمونههای آزمونهای فعلی، به اینجا مراجعه کنید:
+
+- [لایه 2](/layer-2)
+- [نیفتی](/nft/)
+- [اتریوم چیست؟](/what-is-ethereum/)
+- [اتر (ETH) چیست؟](/eth/)
+
+## اضافه کردن یک آزمون یادگیری
+
+اگر صفحهای وجود دارد که هنوز آزمون یادگیری برای آن ایجاد نشده است، لطفا [یک درخواست جدید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) برای آن ثبت کنید.
+
+لطفا اطلاعات زیر را ارائه دهید:
+
+- صفحهای که میخواهید آزمون را به آن اضافه کنید
+- 5 سؤال با اطلاعات زیر:
+ - بخشی از صفحه که سؤال بر اساس آن است
+ - عنوان سؤال
+ - یک پاسخ صحیح به همراه توضیحاتی درباره دلیل صحت آن
+ - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
+
+## اضافه کردن یک سؤال آزمون
+
+اگر سؤالی وجود دارد که می خواهید به بانک سؤالات آزمون اضافه کنید، لطفا [یک درخواست جدید باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) و اطلاعات زیر را ارائه دهید:
+
+- صفحه ای که می خواهید سؤال آزمون را به آن اضافه کنید
+- برای هر سؤال (که اضافه می شود) اطلاعات زیر را ارائه کنید:
+ - بخشی از صفحه که سؤال بر اساس آن است
+ - عنوان سؤال
+ - یک پاسخ صحیح به همراه توضیحاتی دربارهی دلیل صحت آن
+ - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
+
+## بهروز رسانی یک سؤال آزمون
+
+اگر سؤالی وجود دارد که می خواهید به بانک سؤالات آزمون اضافه کنید، لطفا [یک درخواست جدید باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) و اطلاعات زیر را ارائه دهید:
+
+- صفحه ای که می خواهید سؤال آزمون را در آن بهروز رسانی کنید
+- برای هر سؤالی که بهروز رسانی میشود، اطلاعات زیر را ارائه دهید:
+ - بخشی از صفحه که سؤال بر اساس آن است
+ - عنوان سؤالی که میخواهید بهروز رسانی کنید
+ - عنوان بهروز رسانی شده سؤال
+ - یک پاسخ صحیح به همراه توضیحاتی درباره دلیل صحت آن
+ - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
+
+## حذف یک سؤال آزمون
+
+اگر محتوا برای یک سؤال در صفحه وجود ندارد و باید حذف شود، لطفا [یک درخواست](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) برای حذف سؤال ارسال کنید و اطلاعات زیر را بدهید:
+
+- صفحه ای که می خواهید سؤال آزمون را در آن حذف کنید
+- پرسشی که می خواهید حذف کنید
+- توضیح در صورت لزوم برای دلیل حذف پرسش
diff --git a/public/content/translations/fa/about/index.md b/public/content/translations/fa/about/index.md
new file mode 100644
index 00000000000..10f2e68e7fa
--- /dev/null
+++ b/public/content/translations/fa/about/index.md
@@ -0,0 +1,139 @@
+---
+title: درباره ما
+description: درباره تیم، جامعه و ماموریت ethereum.org
+lang: fa
+---
+
+# در ارتباط با ethereum.org {#about-ethereumorg}
+
+ethereum.org یک منبع عمومی منبع باز برای جامعه اتریوم است که هر کسی میتواند با آن همکاری کند. ما یک تیم اصلی کوچک داریم که با مشارکت هزاران نفر از اعضای جامعه در سراسر جهان به حفظ و توسعه سایت اختصاص داده شده است.
+
+## یادداشتی در مورد اسامی {#a-note-on-names}
+
+معمولاً افراد نامها را در چشمانداز اتریوم اشتباه میگیرند، که میتواند منجر به مدلهای ذهنی ضعیف در مورد نحوه عملکرد اتریوم شود. در اینجا یک توضیح سریع برای روشن کردن موارد وجود دارد:
+
+### اتریوم {#ethereum}
+
+اتریوم یک شبکه عمومی، یک بلاکچین و یک پروتکل منبع باز است متعلق به یک جامعه جهانی متشکل از ده ها هزار توسعه دهنده، اپراتورهای گره، دارندگان ETH و کاربرانی که توسط آنها عملیاتی می شود، حکمرانی می شود و مدیریت می شود.
+
+[جزئیات بیشتر اتریوم](/what-is-ethereum/)
+
+[جرئیات بیشتر حکمرانی اتریوم](/governance/)
+
+### اتر (ETH) {#ether-or-eth}
+
+اتر (همچنین با نماد علامت گذاری آن، ETH شناخته می شود) ارز بومی است که در اتریوم معامله می شود. ETH برای پرداخت هزینه استفاده از شبکه اتریوم (به شکل کارمزد تراکنش) مورد نیاز است. ETH همچنین با سهام گذاری برای ایمن سازی شبکه استفاده می شود. وقتی مردم در مورد قیمت اتریوم صحبت می کنند، به دارایی ETH اشاره می کنند.
+
+[جزئیات بیشتر درباره ETH](/eth/)
+
+[جزئیات بیشتر درباره سهامگذاری ETH](/staking/)
+
+### بنیاد اتریوم {#ethereum-foundation}
+
+یک سازمان غیر انتفاعی، که در ابتدا توسط فروش جمعی ETH تأمین مالی شد و به پشتیبانی از شبکه و اکوسیستم اتریوم اختصاص یافت.
+
+[جزئیات بیشتر درباره بنیاد اتریوم](/foundation/)
+
+### ethereum.org {#ethereum-org}
+
+یک وب سایت عمومی و منبع باز و منبع آموزشی برای جامعه اتریوم. ethereum.org توسط یک تیم اصلی کوچک، که توسط بنیاد اتریوم تامین مالی میشود، با مشارکت هزاران نفر از اعضای جامعه در سراسر جهان هدایت میشود.
+
+این صفحه اطلاعات بیشتری در مورد ethereum.org را پوشش میدهد.
+
+## ماموریت ما {#our-mission}
+
+**ماموریت وبسایت ethereum.org این است که بهترین درگاه جامعه در حال رشد اتریوم باشد**
+
+ما در تلاش هستیم تا یک منبع آموزشی قابل فهم برای همه موضوعات مرتبط با اتریوم بسازیم که به کاربران جدید کمک میکند تا با اتریوم و مفاهیم کلیدی آن آشنا شوند. ما میخواهیم:
+
+- اتریوم را با کسانی که در این تکنولوژی جدید هستند توضیح دهیم
+- به کاربران جدید کمک کنیم تا شروع به استفاده از ETH و اتریوم کنند
+- به توسعهدهندگان جدید کمک کنیم تا ساختن را شروع کنند
+- تازههای دنیای اتریوم را پوشش دهیم
+- ویترین منابعی باشیم که توسط جامعه تولید میشود
+- آموزشهای اتریوم را به هر زبان که ممکن است ارائه کنیم
+
+برای دستیابی به این ماموریت، تیم ما روی دو هدف اصلی در ethereum.org تمرکز میکند:
+
+### 1. بهبود تجربه کاربری برای بازدیدکنندگان ethereum.org {#visitors}
+
+- محتوا را گسترش دهید، بهبود دهید و به روز نگه دارید
+- قابلیت استفاده و دسترسی را از طریق بهترین شیوه های محلی سازی و توسعه وب بهبود بخشید
+- تعامل کاربر را از طریق ویژگیهایی مانند نظرسنجی، آزمونها و ادغام Web3 افزایش دهید
+- وب سایت را سبک و کارآمد نگه دارید
+
+### 2. جامعه مشارکتکنندگان ما را رشد، تقویت و توانمند سازید {#community}
+
+- تعداد کل مشارکتکنندگان در وب سایت را افزایش دهید
+- حفظ مشارکتکنندگان را از طریق مشارکت، قدردانی و پاداش بهبود بخشید
+- اعضای جامعه را توانمند کنید تا مشارکتهای چشمگیری داشته باشند
+- تسهیل تنوع بیشتر مشارکتها: کد، محتوا، طراحی، ترجمه، تعدیل
+- پایگاه کد را مدرن، تمیز و مستند نگه دارید
+
+## اصول اصلی {#core-principles}
+
+ما چند اصل اساسی داریم که به ما کمک میکنند ماموریت خود را به انجام برسانیم.
+
+### 1. ethereum.org یک درگاه برای اتریوم است 🌎 {#core-principles-1}
+
+ما میخواهیم که کاربران ما سود داشته باشند و سوالات آن ها پاسخ داده شود. به همین دلیل درگاه ما نیاز دارد تا اطلاعات، "magic moments" و لینکهای منابع جامعه را که وجود دارند، ترکیب کند. هدف ما این است که محتوای ما "پرتال جذب افراد" باشد، نه یک جایگزین برای انبوهی از اطلاعات که همین الان وجود دارند. ما به دنبال متحد کردن و پشتیبانی اطلاعات ساخته شده توسط جامعه هستیم که موجب شفافیت آن و قابل دسترس بودن آن میشود. [جامعه اتریوم](/community/) قلب تپنده آن است: ما صرفا نباید به آن ها سرویس بدهیم، بلکه با آن ها کار کنیم و بازخورد آن ها را در نظر بگیریم. این وبسایت تنها برای استفاده جامعه الان نیست، بلکه برای جامعهای است که امیدواریم رشد کند. ما باید به خاطر داشته باشیم که جامعه ما جهانی است، و تمام مردم از هر زبان، منطقه و فرهنگی را شامل میشود.
+
+### 2. ethereum.org همواره در حال تکامل است ⚒ {#core-principles-2}
+
+اتریوم و جامعه ما همواره در حال جهش هستند، و نیز ethereum.org. و به این خاطر است که سایت دارای یک طراحی ساده است& یک ساختار مدولار. ما زمانی که میفهمیم مردم چگونه از سایت استفاده میکنند تغییرات مرحلهای انجام میدهیم. ما متن باز هستیم، با یک جامعه مشارکتگر، بنابراین شما هم میتوانید پیشنهاد دهید و ما را کمک کنید. [درباره مشارکت بیاموزید](/contributing/)
+
+### 3. ethereum.org یک وبسایت معمولی نیست 🦄 {#core-principles-3}
+
+اتریوم یک چیز بزرگ است: که یک جامعه، تکنولوژی، و مجموعه ای از ایده ها و موارد دیگر است. این بدان معنی است که سایت نیاز دارد تا تجربههای کاربران مختلف را رسیدگی کند، "از یک توسعه دهنده که یک ابزار مشخص میخواهد" گرفته تا "یک تازهکار که مقداری اتر خریده و حتی معنی کیف پول را نمیداند". "بهترین وبسایت برای پلتفرم زنجیره بلوکی چیست؟" یک سؤال با جواب باز است - ما پیشرو هستیم. ساختن آن به آزمایش نیاز دارد.
+
+## نقشه راه محصول {#roadmap}
+
+تیم اصلی ethereum.org برای در دسترستر کردن کارمان و تقویت همکاری بیشتر در جامعه، یک نمای کلی از اهداف نقشه راه فصلی ما را منتشر میکند.
+
+[نقشه راه سهماهه سوم 2024 ما را ببینید](https://github.com/ethereum/ethereum-org-website/issues/13399)
+
+**چطور است؟** ما همیشه از بازخورد درباره نقشه راه مان قدردانی می کنیم - اگر چیزی وجود دارد که فکر می کنید باید روی آن کار کنیم، لطفاً به ما اطلاع دهید! ما از ایدهها و روابط عمومی هر کس در جامعه استقبال میکنیم.
+
+**میخواهید مشارکت کنید؟** [درباره مشارکت بیشتر بیاموزید](/contributing/)، [در توییتر با ما تماس بگیرید](https://twitter.com/ethdotorg)، یا به بحثهای جامعه در
+
+سرور دیسکورد ما بپیوندید< /3>.
+
+
+
+## اصول طراحی کنید {#design-principles}
+
+ما از مجموعه ای از [اصول طراحی](/contributing/design-principles/) برای پیشبرد محتوا و تصمیمات طراحی در وبسایت استفاده می کنیم.
+
+
+
+## سیستم طراحی {#design-system}
+
+ما یک [سیستم طراحی](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) ساختیم و منتشر کردیم تا ویژگیها را سریعتر ارسال کنیم و به اعضای انجمن اجازه دهیم در طراحی باز ethereum.org شرکت کنند.
+
+می خواهید شرکت کنید؟[در فیگما](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System) بخش [مشکل گیت هاب](https://github.com/ethereum/ethereum-org-website/issues/6284) را دنبال کنید و به گفتگو در [ کانال دیسکورد ما بپیوندید](https://discord.gg/ethereum-org).
+
+
+
+## راهنمای سبک {#style-guide}
+
+ما [یک راهنمای سبک](/contributing/style-guide/) برای استانداردسازی ابعاد مشخصی از محتوای نوشتاری داریم تا فرایند کار ساده و هموارتر شود.
+
+حتما [اصول طراحی](/contributing/design-principles/) و [راهنمای سبک](/contributing/style-guide/) را مطالعه کنید و اگر دوست داشتید [به سایت ما کمک کنید](/contributing/).
+
+ما از بازخورد در مورد اصول طراحی، سیستم طراحی و راهنمای سبکمان استقبال میکنیم. به یاد داشته باشید، ethereum.org برای جامعه و از طرف جامعه است.
+
+
+
+## مجوز {#license}
+
+وب سایت ethereum.org منبع باز است و تحت [مجوز MIT](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) ساخته شده است، مگر اینکه خلاف آن مشخص شده باشد. اطلاعات بیشتر در مورد [شرایط استفاده](/terms-of-use/) از ethereum.org.
+
+
+
+## شغل های موجود {#open-jobs}
+
+اگرچه این وبسایت متن باز است و همه می توانند روی آن کار کنند، تیمی مختص به ethereum.org و پروژه های دیگر وب بنیاد اتریوم داریم.
+
+مشاغل موجود را در اینجا می نویسیم. اگر نقشی در اینجا برای خود نمی بینید، به [سرور دیسکورد ما](https://discord.gg/ethereum-org) بروید و به ما اطلاع دهید که چگونه می خواهید با ما کار کنید!
+
+آیا به چیزی فراتر از تیم ethereum.org فکر می کنید؟ [سایر مشاغل مربوط به اتریوم را در اینجا چک کنید](/community/get-involved/#ethereum-jobs/).
diff --git a/public/content/translations/fa/bridges/index.md b/public/content/translations/fa/bridges/index.md
index cadfb870e45..11b0c468bba 100644
--- a/public/content/translations/fa/bridges/index.md
+++ b/public/content/translations/fa/bridges/index.md
@@ -6,32 +6,32 @@ lang: fa
# پلهای زنجیرهی بلوکی {#prerequisites}
-_Web3 به راهحلهای مقیاسپذیری اكوسيستم لايه 1 و اكوسيستم لايه 2 تبدیل شدند که هركدام از اين لايه ها داراي تواناییها و قوانين منحصربهفرد هستند. در حالی كه پروتكلهاي بلاكچين افزايش مي يابند، [ تقاضا براي جابجايي دارايي روي زنجيره ها افزايش مي بايد.]() براي پاسخ به اين نياز ما به پلها نياز داريم._
+_Web3 به راهحلهای مقیاسپذیری اكوسيستم لايه 1 و اكوسيستم لايه 2 تبدیل شدند که هركدام از اين لايه ها داراي تواناییها و قوانين منحصربهفرد هستند. با افزایش تعداد پروتکلهای بلاکچین، تقاضا برای جابجایی داراییها در زنجیرهها نیز افزایش مییابد. براي پاسخ به اين نياز ما به پلها نياز داريم._
## پل ها چه هستند؟ {#what-are-bridges}
-پلهاي بلاك چين دقيقا مثل پلهاي واقعی در دنياي فيزيكي هستند. همانطور كه يك پل فيريكي دو محل فيزيكي را به هم مرتبط مي كند يك پل بلاك چين نيز دو اکوسیستم بلاكچين را به هم متصل مي كند. پلها ارتباط بين بلاكچين ها را با انتقال اطلاعات و دارايی ها امكان پذير مي كنند.
+پلهاي بلاك چين دقيقا مثل پلهاي واقعی در دنياي فيزيكي هستند. همانطور كه يك پل فيريكي دو محل فيزيكي را به هم مرتبط مي كند يك پل بلاك چين نيز دو اکوسیستم بلاكچين را به هم متصل مي كند. **پلها ارتباط بین بلاکچین ها را از طریق انتقال اطلاعات و داراییها تسهیل میکنند**.
با يك مثال مسئله را توضيح مي دهيم:
شما اهل آمريكا هستيد و می خواهيد به اروپا سفر كنيد. شما دلار داريد ولي به يورو نياز داريد. براي تبديل دلار به يورو از يك صرافي با كارمزد كم كمك مي گيريد.
-اما اگر بخواهيد يك تبديل مشابه را برای استفاده از یک بلاكچين متفاوت انجام دهید، چه کار خواهید کرد؟ فرض كنيد مي خواهيد اتريوم شبكه اصلي را با اتريوم در [آربيتروم](https://arbitrum.io/) مبادله كنيد. مثل تبديل پولي كه براي يورو انجام داديم، به يك مكانيزم نياز داريم تا بتوانيم اتر بلاك چين اصلي را به اتر بلاك چين آربیتروم تبديل كنيم. پل ها چنين انتقالي را امكان پذير مي كنند. در اين مثال [آربیتروم داراي يك پل اصلي است](https://bridge.arbitrum.io/) كه مي تواند اتر را از شبکه اصلی به آربیتروم انتقال دهد.
+اما، اگر بخواهید یک صرافی مشابه برای استفاده از یک [بلاکچین](/glossary/#blockchain) متفاوت ایجاد کنید، چه میکنید؟ فرض کنید میخواهید [اتر](/glossary/#ether) در شبکه اصلی اتریوم را با اتر در [آربیتروم](https://arbitrum.io/) مبادله کنید. مثل تبديل پولي كه براي يورو انجام داديم، به يك مكانيزم نياز داريم تا بتوانيم اتر بلاك چين اصلي را به اتر بلاك چين آربیتروم تبديل كنيم. پل ها چنين انتقالي را امكان پذير مي كنند. در اين مثال [ آربیتروم داراي يك پل اصلي است ](https://bridge.arbitrum.io/) كه مي تواند اتر را از شبکه اصلی به آربیتروم انتقال دهد.
## چرا به پلها نياز داريم؟ {#why-do-we-need-bridges}
-تمام بلاك چين ها محدوديت هاي خود را دارند. اتريوم براي مقیاسپذیری و تامين تقاضا نياز به رول آپ ها دارد. جايگزينهايي مثل Solana و Avalanche به صورت متفاوت طراحي شده اند تا دادههای ورودی بیشتر را ممکن سازند اما با قربانی کردن تمركززدایی.
+تمام بلاك چين ها محدوديت هاي خود را دارند. اتریوم برای مقیاسپذیر بودن و نگهداری سطح تقاضا به [رولآپها](/glossary/#rollups) نیاز دارد. جايگزينهايي مثل Solana و Avalanche به صورت متفاوت طراحي شده اند تا دادههای ورودی بیشتر را ممکن سازند اما با قربانی کردن تمركززدایی.
-با این حال، تمام بلاك چينها به صورت ايزوله توسعه پیدا میکنند و قوانين مربوط به خودشان و همچنين مكانيزمهاي اجماع متفاوت دارند. یعنی نمي توانند به صورت طبيعي با هم ارتباط پيدا كنند و توكنها آزادنه نمي توانند بين بلاک چینها حركت كنند.
+بااینحال، همه بلاکچینها در محیطهای ایزوله توسعه مییابند و قوانین و مکانیزمهای [اجماع](/glossary/#consensus) متفاوت دارند. یعنی نمي توانند به صورت طبيعي با هم ارتباط پيدا كنند و توكنها آزادنه نمي توانند بين بلاک چینها حركت كنند.
پلها براي اتصال بلاكچينها هستند و اجازه انتقال اطلاعات و توكنها را بين آنها مي دهند.
-پلها موارد زير را ممکن میسازند:
+**قابلیتهای پلها**:
-- انتقال دارايي و اطلاعات بين زنجيره
-- اپليكيشنهاي غير متمركز مي توانند به تواناییهای بلاكچين های مختلف دسترسي داشته باشند - به این ترتیب تواناییهای خود را افزایش میدهند (در حالی که پروتکلها اکنون فضاي طراحی بيشتري براي خلاقيت دارند).
+- انتقال بینزنجیرهای دارایی ها و اطلاعات.
+- تامین [دپها](/glossary/#dapp) برای دسترسی به نقاط قوت بلاکچینهای مختلف – بنابراین قابلیتهای آنها را افزایش میدهند (زیرا پروتکلها هماکنون فضای طراحی بیشتری برای نوآوری دارند).
- کاربران میتوانند به پلتفرمهاي جديد دسترسی پیدا کنند و از مزایای زنجيره هاي مختلف استفاده کنند.
- توسعه دهندگان اکوسیستمهای مختلف بلاك چين میتوانند همکاری کنند و پلتفرمهاي جديدي را براي كاربرها بسازند.
@@ -57,7 +57,7 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
### دارايیهای رمز ارز اصلی خود {#own-native}
-فرض كنيد مي خواهيد بيتكوين (BTC) خودتان را داشته باشيد ولي فقط در شبكه اصلي اتريوم پول داريد. براي بدست آوردن بيتكوين در اتريوم مي توانيد بيتكوين تبدیل یافته (WBTC) خريداري كنيد. با اين حال، WBTC یک توکن ERC-20 در شبكه اتريوم است که به این معنی است که یک نسخه اتريوم بیتکوین است، نه دارایی اصلی در بلاکچین يتكوين. براي داشتن بيتكوين اصلي بايد به كمك پل دارايیهای خود را از اتريوم به بيتكوين انتقال دهيد. با اين كار WBTC خود را به بيتكوين اصلي پل میزنید و تغيير مي دهيد. به شكل مشابه ممكن است شما داراي بيتكوين باشيد و بخواهيد از آن در پروتكلهاي ديفاي اتريوم بهره ببريد. اين امر نيازمند آن است كه يك پل در جهت مخالف از بيتكوين به رپد بيتكوين استفاده شود که میتوان از آن به عنوان دارایی در اتریوم استفاده کرد.
+فرض كنيد مي خواهيد بيتكوين (BTC) خودتان را داشته باشيد ولي فقط در شبكه اصلي اتريوم پول داريد. براي بدست آوردن بيتكوين در اتريوم مي توانيد بيتكوين تبدیل یافته (WBTC) خريداري كنيد. بااینحال، WBTC یک توکن [ERC-20](/glossary/#erc-20) بومی شبکه اتریوم است، به این معنی که نسخه اتریوم بیتکوین است و نه دارایی اصلی در بلاکچین بیتکوین. براي داشتن بيتكوين اصلي بايد به كمك پل دارايیهای خود را از اتريوم به بيتكوين انتقال دهيد. با اين كار WBTC خود را به بيتكوين اصلي پل میزنید و تغيير مي دهيد. از طرف دیگر، ممکن است صاحب بیتکوین باشید و بخواهید از آن در پروتکلهای [دیفای](/glossary/#defi) اتریوم استفاده کنید. اين امر نيازمند آن است كه يك پل در جهت مخالف از بيتكوين به رپد بيتكوين استفاده شود که میتوان از آن به عنوان دارایی در اتریوم استفاده کرد.
البته مي توانيد تمام كارهاي فوق را توسط صرافي متمركز انجام دهيد. با این حال، در این صورت با انجام چند مرحله می توانید بهتر از پل مورد نظر استفاده کنید، مگر آن که پولهایتان از قبل در صرافی باشد.
@@ -69,27 +69,27 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
پلها انواع مختلفی از نظر طرح و پیچیدگی دارند. به طور کلی پلها به دو گروه تقسیم می شوند: بدون نیاز به اعتماد و نیازمند به اعتماد.
-| پلهای با نیاز به اعتماد | پل های بدون نیاز به اعتماد |
-| --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
-| پلهای نیازمند به اعتماد به یک سیستم یا نهاد مرکزی برای استفاده از آنها وابسته هستند. | پلهای بدون اعتماد، با استفاده از قراردادهای هوشمند و الگوریتمها کار میکنند. |
-| آنها فرض اعتماد پذیر بودن را در رابطه با سرپرستی دارایی و امنیت پل دارا می باشند. کابران بیشتر به شهرت اپراتور پل اعتماد میکنند. | آنها بدون نیاز به اعتماد هستند این به این معنی است که امنیت پل مشابه امنیت بلاک چین مورد نظر است. |
-| کاربران باید کنترل دارایی های خود را واگذار کنند. | از طریق قرار داد هوشمند، با پلهای بدون اعتماد کاربران می توانند کنترل دارایی خود را در اختیار داشته باشند. |
+| پلهای با نیاز به اعتماد | پل های بدون نیاز به اعتماد |
+| --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| پلهای نیازمند به اعتماد به یک سیستم یا نهاد مرکزی برای استفاده از آنها وابسته هستند. | پلهای بدون اعتماد، با استفاده از قراردادهای هوشمند و الگوریتمها کار میکنند. |
+| آنها فرض اعتماد پذیر بودن را در رابطه با سرپرستی دارایی و امنیت پل دارا می باشند. کابران بیشتر به شهرت اپراتور پل اعتماد میکنند. | آنها بدون نیاز به اعتماد هستند این به این معنی است که امنیت پل مشابه امنیت بلاک چین مورد نظر است. |
+| کاربران باید کنترل دارایی های خود را واگذار کنند. | از طریق [قراردادهای هوشمند](/glossary/#smart-contract)، پلهای بیواسطه کاربران را قادر میسازند تا کنترل سرمایه خود را حفظ کنند. |
به طور مشخص می توان گفت که در پلهایی که نیاز به اعتماد می باشد شما به پلتفرم مورد نظر اعتماد می کنید در حالی که در پلهای بدون اعتماد با حداقل اعتماد کردن و صرفا با فرض درست بودن دامنه های زیر ساخت کار انجام می شود. این اصطلاحات در زیر توضیح داده شده است:
-- بدون اعتماد\*\*: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط آرجون بوپتانی در این مقاله توضیح داده شده است
-
- - در مدل دارای اعتماد:\*\* با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
-
+- بدون اعتماد**: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط آرجون بوپتانی در این مقاله
+ توضیح داده شده است
+
+ - در مدل دارای اعتماد:** با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
+
برای این که تفاوت های اساسی بین دو روش بهتر جا بیفتد یک مثال ارائه می شود:
-
+
فرض کنید شما داخل گیت امنیتی فرودگاه هستید. دو روش برای گیت کنترل وجود دارد:
-
+
1. روش دستی - که تمام جزئیات بلیت و کارت شناسایی توسط افسران مربوطه قبل از دادن کارت پرواز انجام می شود.
-
2. کنترل توسط خودتان - با دستگاه انجام می شود که در آن اطلاعات پروازتان را وارد میکنید و اگر همه چیز درست باشد، کارت پرواز را دریافت میکنید.
-نقاط کنترل دستی، شبیه به حالتی است که برای مثال افسران به عنوان شخص سوم مدارک شما را بررسی می کند. به عنوان کاربر به مراکز معتبر اعتماد می کنید تا تصمیم درست را بگیرند و از اطلاعات خصوصی شما به درستی استفاده کنند.
+یک پست بازرسی دستی، شبیه یک مدل مورد اعتماد است زیرا برای عملیات خود به شخص ثالث یعنی مقامات رسمی وابسته است. به عنوان کاربر به مراکز معتبر اعتماد می کنید تا تصمیم درست را بگیرند و از اطلاعات خصوصی شما به درستی استفاده کنند.
مدلی که توسط خود کاربر چک می شود مشابه مدل بدون نیاز به اعتماد می باشد، چون نقش اپراتور حذف می شود و با کمک تکنولوژی امور مربوطه را انجام می دهد. کاربر همیشه کنترل اطلاعات شخصی خود را بدون اعتماد به شخص ثالث در اختیار دارد.
@@ -97,22 +97,25 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
-## خطر استفاده از پلها {#bridge-risk}
-پلها در مرحله ابتدایی توسعه می باشند. به عبارتی طراحی بهینه پلها هنوز به صورت کامل کشف نشده است. استفاده از هر کدام از پلها خطر مربوط به خود را دارد:
-- خطر قرارداد هوشمند —\*\* وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
+## خطر استفاده از پلها {#bridge-risk}
- - خطر تکنولوژی—\*\* خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
+پلها در مرحله ابتدایی توسعه می باشند. به عبارتی طراحی بهینه پلها هنوز به صورت کامل کشف نشده است. استفاده از هر کدام از پلها خطر مربوط به خود را دارد:
+- خطر قرارداد هوشمند —** وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
+
+ - خطر تکنولوژی—** خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
+
با این حال پلهای نیازمند به اعتماد از آنجا که تصورهای اعتماد را افزایش میدهند، می توانند خطرات مضاعفی را به همراه داشته باشند، مثل:
-
- - خطر سانسور—\*\* کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
-
- - خطر سرپرستی—\*\* کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند دارایی های کابرها در خطر هستند اگر:
-
+
+ - خطر سانسور—** کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
+
+ - خطر سرپرستی—** کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند
+
+ دارایی های کابرها در خطر هستند اگر:
+
- یک باگ در قرارداد هوشمند باشد
-
- کاربر مرتکب خطا شود
- بلاکچین مورد استفاده هک شود
- اپارتورهای پل در پلهای نیاز به اعتماد صادق نباشند
@@ -124,14 +127,10 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
+
+
## بیشتر بخوانید {#further-reading}
- [EIP-5164: اجرای کراسچین](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658)_تاریخ 18 ژوئن 2022 - برندان اسلتاین_
- [چارچوب ریسک L2Bridge](https://gov.l2beat.com/t/l2bridge-risk-framework/31)_تاریخ 5 ژوئیه 2022 - بارتک کیپوسوسکی_
- [«چرا در آینده به سمت چند زنجیرهای پیش می رویم نه کراس چین.»](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/)_تاریخ 8 ژانویه 2022 - ویتالیک بوترین_
-- [پلهای بلاک چینی چه هستند و چگونه آنها را دسته بندی کنیم؟](https://blog.li.finance/what-are-blockchain-bridges-and-how-can-we-classify-them-560dc6ec05fa)_تاریخ 18 فوریه 2021 - آرجون چاند_
-- [کراس چینها چه هستند؟](https://www.alchemy.com/overviews/cross-chain-bridges)_تاریخ 10 می 2022 - الکمی_
-- پلهای بلاکچین:ساختن شبکههای رمز ارز*8 سپتامبر 2021 - دیمیتری برنزون*
-- [پل ها در فضای کریپو](https://medium.com/chainsafe-systems/bridges-in-crypto-space-12e158f5fd1e)_تاریخ 23 اوت 2021 - بن آدار هیمان_
-- [انتخاب سخت قابلیت استفاده متقابل](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17)_تاریخ 1 اکتبر 2021 - آرجون بوپتانی_
-- [امنیت پلها: انجام درست ارتباط بین زنجیرهای](https://medium.com/dragonfly-research/secure-the-bridge-cross-chain-communication-done-right-part-i-993f76ffed5d)_تاریخ 23 اوت 2021 - سلیا وان_
diff --git a/public/content/translations/fa/contributing/adding-desci-projects/index.md b/public/content/translations/fa/contributing/adding-desci-projects/index.md
new file mode 100644
index 00000000000..d99215d3d21
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-desci-projects/index.md
@@ -0,0 +1,44 @@
+---
+title: افزودن پروژه های DeSci
+description: سیاستی که هنگام افزودن لینک به پروژهها در صفحه DeSci در ethereum.org استفاده میکنیم
+lang: fa
+---
+
+# افزودن پروژه ها {#adding-projects}
+
+ما میخواهیم مطمئن شویم که پروژههای متنوعی را نشان میدهیم و تصویر خوبی از چشمانداز DeSci ارائه میدهیم.
+
+هر کس آزاد است پروژه ای را برای فهرست کردن در صفحه DeSci در ethereum.org پیشنهاد کند. به همین ترتیب، هر کس که متوجه پروژهای شود که دیگر مرتبط نیست یا دیگر معیارهای واجد شرایط بودن ما را برآورده نمیکند، میتواند حذف آن را پیشنهاد دهد.
+
+## چارچوب تصمیمات {#the-decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#the-must-haves}
+
+- **کد/داده منبع باز** - باز بودن کد و داده، یک اصل اصلی DeSci است، بنابراین پروژه های DeSci نباید منبع بسته باشند. پایگاه کد باید در دسترس باشد و به طور ایده آل برای PRها باز باشد.
+- **پروژههای DeSci باید غیرمتمرکز باشند** - این میتواند شامل اداره شدن توسط یک DAO یا ساختن با پشته فناوری غیرمتمرکز از جمله کیفپولهای غیرمتمرکز باشد. احتمالاً شامل قراردادهای هوشمند قابل بازرسی در اتریوم است.
+- **اطلاعات لیستینگ صادقانه و دقیق** - انتظار می رود هر فهرست پیشنهادی از پروژه ها با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات خود را تحریف کنند، مانند منبع باز اعلان کردن کد پروژه در حالی که برخلاف واقعیت باشد، حذف خواهند شد.
+- **تعهد آشکار به گسترش دسترسی به علم** - یک پروژه DeSci باید بتواند نحوه مشارکت در علم را برای عموم مردم، نه فقط برای دارندگان توکن/NFT، بیان کند.
+- **دسترسیپذیری جهانی** - پروژه شما دارای محدودیتهای جغرافیایی یا الزامات KYC نباشد که افراد خاصی را از دسترسی به خدمات شما محروم میکند.
+- **وبسایت و مستندات اطلاعاتی** - مهم است که بازدیدکنندگان وبسایت پروژه بتوانند بفهمند که پروژه واقعاً چه میکند، چگونه به تمرکززدایی زیرساختهای علمی کمک میکند و افراد چگونه مشارکت میکنند.
+- **پروژه باید بخشی از اکوسیستم اتریوم باشد** - در ethereum.org ما معتقدیم که اتریوم (و لایههای 2 آن) لایه پایه مناسب برای جنبش DeSci است.
+- **پروژه نسبتاً به خوبی تثبیت شده است** - این پروژه دارای کاربران واقعی است که چندین ماه می توانند به خدمات پروژه دسترسی داشته باشند.
+
+### امتیازات ممکن
+
+- **در چندین زبان موجود است** - پروژه شما به چندین زبان ترجمه شده و به کاربران در سراسر جهان امکان دسترسی به آن را می دهد.
+- **منابع آموزشی** - محصول شما باید برای کمک به کاربران و آموزش آنها، یک تجربه نصب خوب طراحی شده داشته باشد. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
+- **ممیزی های طرف ثالث** - محصول شما به صورت حرفه ای از نظر آسیب پذیری توسط طرف ثالث مورد اعتماد بازرسی شده است.
+- **نقطه تماس** - یک نقطه تماس برای پروژه (این ممکن است توسط نماینده ای از یک DAO یا انجمن باشد) به ما کمک زیادی می کند تا هنگام ایجاد تغییرات اطلاعات دقیق را دریافت کنیم. این امر، بروزرسانی ethereum.org را در هنگام جمعآوری اطلاعات آینده قابل مدیریت نگه می دارد.
+
+## نگهداری {#maintenance}
+
+از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
+
+- اطمینان حاصل کنید که همه پروژه های لیست شده هنوز معیارهای ما را برآورده می کنند
+- بررسی کنید هیچ محصولی پیشنهاد نشده است که معیارهای ما را بیشتر از مواردی که در حال حاضر لیست شده است برآورده می کند
+
+Ethereum.org توسط جامعه منبع باز نگهداری می شود و ما به جامعه برای کمک به بهروز نگه داشتن این موضوع متکی هستیم. اگر متوجه هر گونه اطلاعات در مورد پروژه های لیست شده شدید که نیاز به بهروزرسانی دارند، لطفاً یک مسئله یا درخواست ادغام را در مخزن گیتهاب ما باز کنید.
+
+## شرایط استفاده {#terms-of-use}
+
+لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
diff --git a/public/content/translations/fa/contributing/adding-developer-tools/index.md b/public/content/translations/fa/contributing/adding-developer-tools/index.md
new file mode 100644
index 00000000000..2201c53b86c
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-developer-tools/index.md
@@ -0,0 +1,61 @@
+---
+title: افزودن ابزار های توسعهدهنده
+lang: fa
+description: معیارهای ما برای فهرست کردن ابزارهای توسعه دهنده در ethereum.org
+---
+
+# در حال افزودن ابزار های توسعهدهنده {#contributing-to-ethereumorg-}
+
+ما میخواهیم مطمئن شویم که بهترین منابع توسعهدهنده ممکن را فهرست کردهایم تا افراد بتوانند با اعتماد به نفس ایجاد کنند و پشتیبانی مورد نیاز خود را داشته باشند.
+
+اگر ابزار توسعهدهنده مفیدی وجود دارد که ما آن را فراموش کرده ایم، آن را در جایی مناسب پیشنهاد کنید.
+
+ما در حال حاضر ابزارهای توسعه دهنده را در سرتاسر [پورتال توسعه دهنده](/developers/) خود فهرست میکنیم.
+
+**به راحتی می توانید موارد اضافه شده جدید را به صفحات مناسب پیشنهاد دهید.**
+
+## چگونه تصمیم می گیریم {#ways-to-contribute}
+
+ارسالیهای ابزار توسعه دهنده با معیارهای زیر ارزیابی می شوند:
+
+**آیا به طور عمده با ابزارهایی که قبلاً فهرست شده است متمایز است؟**
+
+- دسته ها یا انواع ابزارهای جدید
+- ویژگی های جدید در مقایسه با ابزارهای مشابه موجود
+- هدف گذاری شده در یک مورد خاص که توسط ابزارهای مشابه موجود پوشش داده نشده است
+
+**آیا ابزار به خوبی مستند شده است؟**
+
+- آیا مستندات وجود دارد؟
+- آیا استفاده از ابزار کافی است؟
+- آیا به تازگی به روز شده است؟
+
+**آیا ابزار به طور گسترده استفاده می شود؟**
+
+- ما معیارهایی مانند ستاره های GitHub، آمار دانلود، و اینکه آیا توسط شرکت ها یا پروژه های شناخته شده استفاده می شود را در نظر خواهیم گرفت
+
+**آیا ابزار از کیفیت کافی برخوردار است؟**
+
+- آیا اشکالات مکرر وجود دارد؟
+- آیا ابزار قابل اعتماد است؟
+- آیا ابزار به طور فعال نگهداری می شود؟
+
+**آیا ابزار منبع باز است؟**
+
+بسیاری از پروژه ها در فضای اتریوم منبع باز هستند. به احتمال زیاد ما پروژه های منبع باز را فهرست می کنیم که به توسعه دهندگان جامعه اجازه می دهند کد را بررسی کرده و در آن مشارکت کنند.
+
+---
+
+## سفارش محصول {#product-ordering}
+
+محصولات از قدیمی ترین تا جدیدترین محصول اضافه شده به صفحه نمایش داده می شوند، مگر اینکه محصولات به طور خاص مرتب شده باشند، مثلا بر اساس حروف الفبا. به عبارت دیگر، جدیدترین محصولات به انتهای لیست اضافه می شوند.
+
+---
+
+## ابزار توسعه دهنده خود را اضافه کنید {#how-decisions-about-the-site-are-made}
+
+اگر میخواهید یک ابزار توسعهدهنده را به ethereum.org اضافه کنید و معیارها را برآورده میکند، مسئلهای در GitHub ایجاد کنید.
+
+
+ افزودن مسئله
+
diff --git a/public/content/translations/fa/contributing/adding-exchanges/index.md b/public/content/translations/fa/contributing/adding-exchanges/index.md
new file mode 100644
index 00000000000..0bfad40bb95
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-exchanges/index.md
@@ -0,0 +1,40 @@
+---
+title: افزودن صرافی
+description: ضوابطی که ما به هنگام اضافه کردن صرافیها به وبسایت ethereum.org استفاده می کنیم
+lang: fa
+---
+
+# افزودن صرافیهای شبکه اتریوم {#adding-ethereum-exchanges}
+
+هر کس آزاد است اضافه شدن صرافیهای جدید به وبسایت ethereum.org را پیشنهاد دهد.
+
+در حال حاضر ما آنها را در اینجا فهرست کردهایم:
+
+- [ethereum.org/get-eth](/get-eth/)
+
+این صفحه به کاربر اجازه میدهد محل زندگی خود را به عنوان ورودی ارائه دهد و مشاهده کند که از چه صرافیهایی میتواند استفاده نماید. این کمک میکند تا هرگونه محدودیت جغرافیایی هرچه زودتر آشکار شود.
+
+بنابر همین موضوع، زمانی که شما یک صرافی را پیشنهاد میکنید ما به اطلاعات خاصی نیاز داریم.
+
+**نکته:** اگر میخواهید که یک صرافی غیرمتمرکز را فهرست کنید، نگاهی به [ضوابط ما برای فهرست نمودن کیف پولها و برنامههای غیرمتمرکز](/contributing/adding-products/) بیاندازید.
+
+## آنچه ما نیاز داریم {#what-we-need}
+
+- محدودیتهای جغرافیایی که بر صرافی اعمال میشوند. محدودیتهای جغرافیایی مرتبط با صرافی باید در صفحه یا بخش اختصاصی وبسایت صرافی به تفصیل بیان شوند.
+- ارزهایی که کاربران میتوانند استفاده کنند تا ETH بخرند
+- مدرک اثبات این که صرافی یک شرکت تجاری قانونی میباشد
+- هرگونه اطلاعات اضافی که ممکن است داشته باشید - این اطلاعات میتواند اطلاعاتی درباره شرکت مانند سالهای فعالیت، پشتوانه مالی و غیره باشد.
+
+ما به این اطلاعات نیازمندیم تا بتوانیم به صورت دقیق [به کاربران کمک کنیم تا صرافی را که میتوانند استفاده نمایند پیدا کنند](/get-eth/#country-picker).
+
+و همچنین ethereum.org میتواند اطمینان بیشتری داشته باشد که صرافی قانونی است و خدمات امن ارائه میدهد.
+
+---
+
+## صرافی خود را اضافه کنید {#add-exchange}
+
+اگر میخواهید یک صرافی را به ethereum.org اضافه نمائید، یک مسئله در وبسایت گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/contributing/adding-glossary-terms/index.md b/public/content/translations/fa/contributing/adding-glossary-terms/index.md
new file mode 100644
index 00000000000..c908ba2b000
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-glossary-terms/index.md
@@ -0,0 +1,26 @@
+---
+title: افزودن عبارات واژه نامه
+lang: fa
+description: ضوابط ما برای اضافه کردن یک عبارت به واژه نامه اتریوم
+---
+
+# افزودن عبارات واژه نامه {#contributing-to-ethereumorg-}
+
+فضای اتریوم روز به روز در حال تغییر است. اصطلاحات جدید دائماً وارد فرهنگ لغات کاربران اتریوم می شوند و ما به کمک شما برای گردآوری یک مرجع دقیق و به روز برای همه عبارات مربوط اتریوم نیاز داریم. نگاهی به [واژه نامه](/glossary/) کنونی ما بیاندازید سپس اگر میخواهید در بهبود آن کمک کنید متن پایین را مطالعه کنید!
+
+## معیارها {#criteria}
+
+اصطلاحات جدید واژه نامه بر اساس معیار های زیر بررسی میشوند:
+
+- آیا این اصطلاح/تعریف به روز است و منسوخ نشده است؟
+- آیا در حال حاضر عبارت مشابه آن در فرهنگ لغات وجود دارد؟ (اگر بله، فواید اضافه کردن اصطلاح جدید در مقابل بروزرسانی اصطلاحات موجود در واژه نامه را مقایسه کنید)
+- آیا عبارت/تعریف جدید عاری از تبلیغات محصول یا سایر محتوای تبلیغاتی است؟
+- آیا این اصطلاح/تعریف مستقیما به اتریوم مربوط میشود؟
+- آیا عبارت جدید تعریفی عینی، دقیق و عاری از قضاوت یا نظر شخصی دارد؟
+- آیا منبع قابل اعتماد است؟ آیا آنها منابع خود را اعلام کرده اند؟
+
+---
+
+## عبارت خود را اضافه کنید {#how-decisions-about-the-site-are-made}
+
+اگر میخواهید عبارتی به واژه نامه ethereum.org اضافه کنید که شرایط بالا را دارد، [درخواستی در گیتهاب ثبت کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml).
diff --git a/public/content/translations/fa/contributing/adding-layer-2s/index.md b/public/content/translations/fa/contributing/adding-layer-2s/index.md
new file mode 100644
index 00000000000..6dd2e94af0d
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-layer-2s/index.md
@@ -0,0 +1,97 @@
+---
+title: افزودن لایه 2ها
+description: ضوابط ما برای اضافه کردن یک لایه 2 به ethereum.org
+lang: fa
+---
+
+# افزودن لایه 2ها {#adding-layer-2}
+
+ما میخواهیم مطمئن شویم که بهترین منابع ممکن را فهرست کرده باشیم تا کاربران بتوانند با خیالی آسوده از فضای لایه 2ها استفاده کنند.
+
+هر کس آزاد است اضافه شدن یک لایه 2 جدید را به ethereum.org پیشنهاد دهد. اگر یک لایه 2 وجود دارد که ما آن را از قلم انداختهایم، **[لطفاً آن را پیشنهاد کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!**
+
+در حال حاضر ما لایه 2ها را در صفحات زیر فهرست میکنیم:
+
+- [اندوخته های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)
+- [رولآپهای دانش-صفر](/developers/docs/scaling/zk-rollups/)
+- [لایه 2](/layer-2/)
+
+لایه 2 یک مفهوم و الگوی نسبتاً جدید و هیجان انگیز برای اتریوم است. ما تلاش کردیم که یک چارچوب منصفانه برای بررسی و فهرست در ethereum.org ایجاد کنیم، اما معیارهای فهرست بندی در طول زمان تغییر می کنند و تکامل می یابند.
+
+## چارچوب تصمیمات {#decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#criteria-for-inclusion-the-must-haves}
+
+**فهرست شدن در L2BEAT**
+
+- به منظور این که پروژه جهت فهرست شدن در نظر گرفته شود، باید قبلاً در [L2BEAT](https://l2beat.com) فهرست شده باشد. L2BEAT یک سنجش ریسک برجسته از پروژههای لایه 2 انجام میدهد که ما برای ارزیابی پروژه های لایه 2 به آن متکی هستیم. **اگر پروژهای در L2BEAT نشان داده نشده باشد، ما آن را به عنوان لایه 2 در ethereum.org فهرست نخواهیم کرد.**
+- [ببینید چگونه میتوانید پروژه لایه 2 خود را به L2BEAT اضافه کنید](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md).
+
+**کد منبع باز**
+
+- کد شما باید قابل دسترسی باشد و شما باید در گیتهاب، PRهایی از جامعه گستردهتر را قبول کنید.
+
+**دسته بندی لایه 2**
+
+ما در حال حاضر دسته های زیر را به عنوان راه حل لایه 2 در نظر میگیریم:
+
+- رول آپ خوش بینانه
+- رول آپ دانش صفر
+
+_ما راه حلهای مقیاس پذیر دیگری را که از اتریم به عنوان لایه امنیت یا لایه دسترسی به اطلاعات استفاده نمیکنند، لایه 2 در نظر نمیگیریم._
+
+**اتریوم برای دسترسی به اطلاعات**
+
+- در دسترس بودن اطلاعات یک معیار متمایز کننده میان لایه 2 و سایر راه حلهای مقیاس پذیری است. یک پروژه **باید** از شبکه اصلی اتریوم برای دسترسی به اطلاعات استفاده نماید تا برای فهرست شدن در نظر گرفته شود.
+
+**پل ها**
+
+- کاربران چگونه میتوانند به فضای این لایه 2 وارد شوند؟
+
+**تاریخی که پروژه عرضه و منتشر شد**
+
+- لایه 2 حداقل باید به مدت 6 ماه در شبکه اصلی اتریوم "زنده" بوده باشد
+
+- پروژههای جدیدی که هنوز توسط کاربران آزمایش نشدهاند، شانس کمتری برای فهرست شدن دارند.
+
+**حسابرسی امنیتی**
+
+- چه از طریق حسابرسی امنیتی برون سازمانی، تیم داخلی امنیت یا هر روش دیگری، امنیت محصول شما باید به شکل قابل اطمینان مورد آزمایش قرار گرفته باشد. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
+
+**پایگاه فعال کاربران**
+
+- ما معیارهایی همچون تاریخچه موجودی کل قفل شده یا TVL، آمار تراکنشها و اینکه آیا توسط شرکتها یا پروژههای شناخته شده استفاده میشود یا نه را در نظر میگیریم
+
+**تیم توسعه فعال**
+
+- ما یک لایه 2 را که یک تیم فعال ندارد که روی پروژه کار کند، لیست نخواهیم کرد.
+
+**جستجوگر بلوک**
+
+- پروژه های لیست شده نیازمند یک جستجوگر بلاک فعال هستند تا به کاربران اجازه دهند به راحتی در شبکه کاوش نمایند.
+
+### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#nice-to-haves}
+
+**پشتیبانی پروژه با صرافیها**
+
+- آیا کابران قادر به واریز و/یا برداشت مستقیم به/از یک صرافی هستند؟
+
+**لینک به اکوسیستم برنامه های غیرمتمرکز موجود در لایه 2**
+
+- ما علاقهمندیم بتوانیم اطلاعاتی را در مورد کارهایی که کاربران میتوانند انتظار داشته باشند در این لایه 2 انجام دهند، ارائه دهیم. (برای مثال https://portal.arbitrum.io/, https://www.optimism.io/apps)
+
+**فهرست قراردادهای توکن**
+
+- از آنجا که داراییها در لایه 2 آدرس جدیدی خواهند داشت، اگر منبعی از لیست توکنها وجود دارد، لطفاً آن را به اشتراک بگذارید.
+
+**پشتیبانی از کیف پول بومی**
+
+- آیا کیف پولها بهصورت بومی از لایه 2 پشتیبانی میکنند؟
+
+## لایه 2 خود را اضافه کنید {#add-exchange}
+
+اگر میخواهید یک لایه 2 را به ethereum.org اضافه نمائید، یک مسئله در وبسایت گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/contributing/adding-products/index.md b/public/content/translations/fa/contributing/adding-products/index.md
new file mode 100644
index 00000000000..a7c0a46e2c9
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-products/index.md
@@ -0,0 +1,100 @@
+---
+title: افزودن محصولات
+description: سیاست و ضوابطی که ما به هنگام اضافه کردن محصولات به ethereum.org استفاده می کنیم
+lang: fa
+---
+
+# افزودن محصولات اتریوم {#adding-products}
+
+هر کسی آزاد است تا برنامه های غیرمتمرکز جدید را پیشنهاد دهد تا به محتوای ethereum.org، در محلی که مناسب آن است، اضافه شود. **خیر، ما برنامه غیرمتمرکز شما را به صفحه اصلی خود اضافه نخواهیم کرد** 😜
+
+لیست فعلی برنامه های غیرمتمرکز:
+
+- ethereum.org/dapps
+- ethereum.org/get-eth
+
+**لطفا فقط پیشنهادهای جدید را به این صفحه اضافه کنید.**
+
+اگرچه از افزودن پیشنهادهای جدید استقبال میکنیم، اما برنامههای غیرمتمرکز فعلی را بر اساس تجربهای که میخواهیم برای کاربرانمان ایجاد کنیم، انتخاب کردهایم. این معیارها بر اساس برخی از اصول طراحی ما میباشد:
+
+- _الهام بخش_: هر چیزی در ethereum.org، باید چیز جدیدی را به کاربران ارائه دهد
+- _یک داستان خوب_: آنچه فهرست شده باید یک لحظه "آهاااا فهمیدم" را برای کاربر ایجاد کند
+- _معتبر_: همه چیز باید کسب و کار/پروژه قانونی باشد تا خطر برای کاربران به حداقل برسد
+
+در کل، **ethereum.org میخواهد یک "تجربه ورود و استفاده آسان" را برای کاربران جدید فراهم نماید**. به همین دلیل، ما برنامه های غیرمتمرکز را بر اساس ویژگیهای زیر اضافه میکنیم:
+
+- سهولت در استفاده
+- سازگاری متقابل با سایر محصولات
+- امنیت
+- ماندگاری
+
+این هم از جزئیات بیشتر درباره چارچوب تصمیم گیری ما. برای ارائه بازخورد یا پیشنهاد تغییرات، درنگ نکنید.
+
+## چارچوب تصمیمات {#decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#criteria-for-inclusion-the-must-haves}
+
+- **محصول از منظر امنیتی آزمایش شده باشد** - چه از طریق حسابرسی امنیتی خارجی، از طریق یک تیم امنیت داخلی یا هر روش دیگر، امنیت محصول شما باید به طور قابل اتکا، آزمایش شود. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
+- **محصولی که بیش از 6 ماه "عرضه و منتشر" شده باشد** - این مهر تائید دیگری بر امنیت محصول میباشد. 6 ماه بازه زمانی مناسبی برای یافتن نواقص امنیتی و راههای هک کردن، میباشد.
+- **یک تیم فعال بر روی آن کار میکنند** - این مورد کیفیت محصول را تضمین میکند و به کاربر اطمینان خاطر میدهد که برای سؤالات و مشکلاتش پشتیبانی دریافت خواهد کرد.
+- **اطلاعات فهرست شده صادقانه و دقیق** - انتظار میرود هر گونه پیشنهاد پروژه ها، با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات ارسالی برای فهرست شدن را جعل می کنند، مانند اعلام "منبع باز" بودن محصول، در حالی که اینگونه نباشد، حذف خواهند شد.
+
+### معیارهای رتبه بندی: داشتن آنها خوب است {#criteria-for-ranking-the-nice-to-haves}
+
+به دلیل معیارهای زیر ممکن است برنامه غیرمتمرکز شما به اندازه سایرین در ethereum.org، به صورت برجسته نمایش داده نشود.
+
+**برنامه های غیرمتمرکز**
+
+- **بتوانید از طریق اکثر کیف پول های فهرست شده به آن دسترسی داشته باشید** - برنامههای غیرمتمرکز، باید با اکثر کیف پول هایی که در ethereum.org فهرست شده اند کار کنند.
+- **کاربران بتوانند خودشان آن را امتحان کنند -** یک کاربر باید بتواند از نرمافزار غیرمتمرکز شما استفاده کند و به نتیجهای ملموس دست یابد.
+- **سهولت در جذب کاربر** - محصول شما باید دارای یک تجربه ساده ورود و استفاده باشد و کاربران بتوانند کمک دریافت کنند و آموزش ببینند. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
+- **غیرسرپرستی** - کاربران خودشان وجوه خود را کنترل کنند. اگر پروژه و محصول شما زمانی ناپدید شود، کاربران همچنان بتوانند به وجوه خود دسترسی داشته باشند و آن را جابجا کنند.
+- **قابل دسترسی جهانی** - محصول شما دارای محدودیتهای جغرافیایی یا الزامات KYC نباشد که افراد خاصی را از دسترسی به خدمات شما محروم کند.
+- **کد منبع باز** - کد شما باید در دسترس باشد و باید PRها را از جامعه گستردهای بپذیرید.
+- **جامعه پروژه** - شما باید یک جامعه اختصاصی داشته باشید، میتواند در برنامه Discord باشد که در آن کاربران میتوانند با تیم شما برای دریافت کمک یا پیشنهاد ویژگیهای جدید تعامل داشته باشند.
+
+## معیارهای در حال اجرا {#criteria-in-practice}
+
+هرچه تعداد بیشتری از معیارها را پر کنید، احتمال بیشتری وجود دارد که محصول شما به ethereum.org راه پیدا کند.
+
+اگر یک محصول جدید پیشنهاد شود که معیارهای ضروری و برخی از غیر ضروریها را داشته باشد، محصول فهرست شدهای که فقط معیارهای ضروری را داشته باشد ممکن است حذف شود.
+
+موارد دیگری که در این تصمیم موثر هستند:
+
+- آیا اضافه کردن محصول به فهرست به جای جایگزینی آن با محصولی دیگر، باعث به هم ریختن صفحه می شود؟
+ - سایت ما در درجه اول آموزشی است و هدف اصلی آن توضیح اتریوم و مفاهیم مربوط به آن است. با افزودن گزینه های بسیار زیاد برای کاربران، ممکن است صفحات کمتر قابل خواندن و در نتیجه کمتر مفید باشند.
+- آیا صفحه کنونی، کاربر را با انتخابهای متعدد فلج می کند؟
+ - درست مثل زمانی که ساعتها در حال مرور Netflix مینشینید زیرا نمیتوانید در مورد چیزی برای تماشا تصمیم بگیرید. بمباران کردن کاربران جدید با انتخابهای بیش از حد، یک ریسک است.
+
+این یک تصمیم در طراحی است که ethereum.org مسئول آن است.
+
+اما مطمئن باشید، **لینکهایی به وبسایتهای دیگر وجود خواهد داشت که برنامههای غیرمتمرکز بیشتری را رتبهبندی میکنند**
+
+### سفارش محصول {#product-ordering}
+
+محصولات از جدیدترین تا قدیمیترین زمان اضافه شدن نمایش داده می شوند، مگر اینکه ترتیب محصولات به طور خاصی باشد، برای مثال بر اساس حروف الفبا. به عبارت دیگر، جدیدترین محصولات به انتهای لیست اضافه می شوند.
+
+### شرایط استفاده {#terms-of-use}
+
+لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
+
+## نگهداری {#maintenance}
+
+از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
+
+- اطمینان حاصل کنیم که همه برنامههای لیست شده هنوز معیارهای ما را برآورده می کنند
+- اطمینان حاصل کنیم هیچ محصولی پیشنهاد نشده باشد که معیارهای بیشتری از محصولات فهرست شده فعلی را رعایت کند و آن را اضافه نکرده باشیم
+
+شما می توانید با بررسی و اطلاع رسانی در این مورد کمک کنید. [یک مسئله در گیتهاب ایجاد کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) یا یک ایمیل به [website@ethereum.org](mailto:website@ethereum.org) ارسال کنید
+
+_ما همچنین در حال بررسی گزینههای رأیگیری هستیم تا جامعه اتریوم بتواند اولویتهای خود را نشان دهد و بهترین محصولات موجود را برای توصیه ما برجسته کند._
+
+---
+
+## محصول خود را اضافه کنید {#add-your-product}
+
+اگر می خواهید یک برنامه غیرمتمرکز به ethereum.org اضافه کنید که معیارها را رعایت می کند، در وبسایت GitHub یک مسئله ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/contributing/adding-staking-products/index.md b/public/content/translations/fa/contributing/adding-staking-products/index.md
new file mode 100644
index 00000000000..79eb75fd7fd
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-staking-products/index.md
@@ -0,0 +1,176 @@
+---
+title: افزودن محصولات یا خدمات سهامگذاری
+description: سیاستی که هنگام افزودن محصولات یا سرویسهای سهامگذاری به ethereum.org استفاده میکنیم
+lang: fa
+---
+
+# افزودن محصولات یا خدمات سهامگذاری {#adding-staking-products-or-services}
+
+ما می خواهیم مطمئن شویم که بهترین منابع ممکن را فهرست می کنیم و در عین حال کاربران را ایمن و مطمئن نگه می داریم.
+
+هر کس میتواند آزادانه پیشنهاد اضافه کردن محصولات یا خدمات سهامگذاری را در ethereum.org بدهد. اگر موردی وجود دارد که از قلم افتاده است، **[لطفاً آن را پیشنهاد دهید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!**
+
+ما در حال حاضر محصولات و خدمات سهامگذاری را در صفحات زیر فهرست می کنیم:
+
+- [سهام گذاری انفرادی](/staking/solo/)
+- [سهامگذاری بهعنوان یک خدمت](/staking/saas/)
+- [استخرهای سهامگذاری](/staking/pools/)
+
+اثبات سهام از 1 دسامبر 2020 در بیکن چین فعال است. در حالی که سهامگذاری هنوز نسبتاً جدید است، ما سعی کرده ایم یک چارچوب منصفانه و شفاف برای بررسی در ethereum.org ایجاد کنیم، اما معیارهای فهرست کردن در طول زمان تغییر می کند و تکامل می یابد و در نهایت به صلاحدید تیم وب سایت ethereum.org است.
+
+## چارچوب تصمیمات {#the-decision-framework}
+
+تصمیم برای فهرست کردن یک محصول در ethereum.org به هیچ عاملی بستگی ندارد. هنگام تصمیم گیری برای فهرست کردن یک محصول یا خدمات، چندین معیار با هم در نظر گرفته می شوند. هر چه تعداد این معیارها بیشتر باشد، احتمال فهرست شدن آن بیشتر است.
+
+**اول اینکه از کدام دسته از محصولات یا خدمات است؟**
+
+- ابزار گره یا کاربر
+- مدیریت کلید
+- سهام گذاری به عنوان یک سرویس (SaaS)
+- استخر سهامگذاری
+
+در حال حاضر، ما فقط محصولات یا خدمات را در این دسته بندی ها فهرست می کنیم.
+
+### معیارهای شمول {#criteria-for-inclusion}
+
+محصولات یا خدمات سهامگذاری با معیارهای زیر ارزیابی می شوند:
+
+**پروژه یا سرویس چه زمانی راه اندازی شد؟**
+
+- آیا شواهدی وجود دارد که نشان دهد محصول یا خدمت چه زمانی در دسترس عموم قرار گرفت؟
+- این برای تعیین امتیاز "نبرد آزمایش شده" محصولات استفاده می شود.
+
+**آیا از پروژه به طور فعال نگهداری می شود؟**
+
+- آیا یک تیم فعال در حال توسعه پروژه وجود دارد؟ چه افرادی دخیل هستند؟
+- فقط محصولاتی که به طور فعال نگهداری می شوند در نظر گرفته خواهند شد.
+
+**آیا محصول یا خدمات فاقد واسطه های قابل اعتماد/انسانی است؟**
+
+- چه مراحلی در تجربه کاربران، نیازمند اعتماد به انسانها برای نگه داشتن کلیدهای سرمایهشان یا توزیع صحیح جوایز است؟
+- این برای تعیین امتیاز "بی اعتماد" محصول یا خدمات استفاده می شود.
+
+**آیا پروژه اطلاعات دقیق و قابل اعتمادی را ارائه می دهد؟**
+
+- بسیار مهم است که وب سایت محصول دارای اطلاعات به روز، دقیق و غیر گمراه کننده باشد، به خصوص اگر مربوط به پروتکل اتریوم یا سایر فناوری های مرتبط باشد.
+- موارد ارسالی حاوی اطلاعات نادرست، جزئیات قدیمی، یا اظهارات احتمالی گمراه کننده در مورد اتریوم یا سایر موضوعات مرتبط، فهرست نخواهند شد یا اگر قبلاً فهرست شده باشند حذف خواهند شد.
+
+**چه پلتفرم هایی پشتیبانی می شوند؟**
+
+- یعنی Linux, macOS, Windows, iOS, Android
+
+#### نرم افزار و قراردادهای هوشمند {#software-and-smart-contracts}
+
+برای هر نرم افزار سفارشی یا قراردادهای هوشمند درگیر:
+
+**آیا همه چیز منبع باز است؟**
+
+- پروژه های منبع باز باید یک مخزن کد منبع در دسترس عموم داشته باشند
+- این برای تعیین امتیاز "منبع باز" محصولات استفاده می شود.
+
+**آیا محصول از مرحله توسعه _بتا_ خارج شده است؟**
+
+- محصول در چرخه توسعه خود در کجا قرار دارد؟
+- محصولات در مرحله بتا برای درج در ethereum.org در نظر گرفته نمی شوند
+
+**آیا نرم افزار مورد بازرسی امنیتی خارجی قرار گرفته است؟**
+
+- اگر نه، آیا برنامه ای برای انجام ممیزی خارجی وجود دارد؟
+- این برای تعیین امتیاز "ممیزی شده" محصولات استفاده می شود.
+
+**آیا پروژه دارای برنامه پاداش باگ است؟**
+
+- اگر نه، آیا برنامهای برای ایجاد جایزه باگ امنیتی وجود دارد؟
+- از این برای تعیین امتیاز "جایزه باگ" محصولات استفاده می شود.
+
+#### ابزار گره یا کاربر {#node-or-client-tooling}
+
+برای محصولات نرم افزاری مرتبط با تنظیم، مدیریت یا مهاجرت گره یا کاربر:
+
+**کدام کاربر لایه اجماع (به عنوان مثال. Lighthouse, Teku, Nimbus, Prysm) پشتیبانی می شود؟**
+
+- کدام کاربرها پشتیبانی می شوند؟ آیا کاربر می تواند انتخاب کند؟
+- این برای تعیین امتیاز "چند کاربری" محصولات استفاده می شود.
+
+#### سهامگذاری بهعنوان یک خدمت {#staking-as-a-service}
+
+برای [فهرستهای سهامگذاری به عنوان خدمات](/staking/saas/) (به عنوان مثال عملیات گره واگذار شده):
+
+**هزینه های مربوط به استفاده از خدمات چیست؟**
+
+- ساختار هزینه چگونه است، به عنوان مثال. آیا هزینه ماهانه برای خدمات وجود دارد؟
+- آیا سهام گذاری اضافی وجود دارد؟
+
+**آیا کاربران ملزم به ثبت نام برای یک حساب کاربری هستند؟**
+
+- آیا کسی می تواند بدون اجازه یا KYC از این سرویس استفاده کند؟
+- این برای تعیین امتیاز "بدون مجوز" محصولات استفاده می شود.
+
+**چه کسی کلیدهای امضا، و کلیدهای برداشت را در اختیار دارد؟**
+
+- کاربر به چه کلیدهایی دسترسی دارد؟ سرویس به چه کلیدهایی دسترسی پیدا می کند؟
+- این برای تعیین امتیاز "بی اعتماد" محصولات استفاده می شود.
+
+**تنوع مشتری گره های در حال بهره برداری چیست؟**
+
+- چند درصد از کلیدهای اعتبارسنج توسط مشتری لایه اجماع اکثریت (CL) اجرا می شود؟
+- در آخرین ویرایش، Prysm کاربر لایه اجماع است که توسط اکثر اپراتورهای گره اجرا می شود، که برای شبکه خطرناک است. اگر هر کاربر CL در حال حاضر توسط بیش از 33٪ از شبکه استفاده می شود، ما اطلاعات مربوط به استفاده از آن را درخواست می کنیم.
+- این برای تعیین امتیاز "مشتریان متنوع" محصولات استفاده می شود.
+
+#### استخر سهامگذاری {#staking-pool}
+
+برای [خدمات سهامداری ادغام شده](/staking/pools/):
+
+**حداقل ETH مورد نیاز برای سهام گذاری چیست؟**
+
+- مثلا 0.01 ETH
+
+**کارمزدها یا الزامات مربوط به سهام گذاری چیست؟**
+
+- چند درصد از پاداش ها به عنوان کارمزد حذف می شود؟
+- آیا سهام گذاری اضافی وجود دارد؟
+
+**آیا توکن نقدینگی وجود دارد؟**
+
+- توکن ها شامل چه مواردی می شوند؟ چطور کار می کنند؟ آدرس های قرارداد چیست؟
+- این برای تعیین امتیاز "توکن نقدینگی" محصولات استفاده می شود.
+
+**آیا کاربران می توانند به عنوان یک اپراتور گره شرکت کنند؟**
+
+- برای اجرای کاربران اعتبارسنج با استفاده از وجوه ادغام شده چه چیزی لازم است؟
+- آیا این به مجوز یک فرد، شرکت یا DAO نیاز دارد؟
+- این برای تعیین امتیاز "گره های بدون مجوز" محصولات استفاده می شود.
+
+**تنوع کاربر اپراتورهای گره استخر چیست؟**
+
+- چند درصد از اپراتورهای گره کاربر لایه اجماع اکثریت (CL) را اجرا می کنند؟
+- در آخرین ویرایش، Prysm کاربر لایه اجماع است که توسط اکثر اپراتورهای گره اجرا می شود، که برای شبکه خطرناک است. اگر هر کاربر CL در حال حاضر توسط بیش از 33٪ از شبکه استفاده می شود، ما اطلاعات مربوط به استفاده از آن را درخواست می کنیم.
+- این برای تعیین امتیاز "مشتریان متنوع" محصولات استفاده می شود.
+
+### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#other-criteria}
+
+**چه رابط های کاربری پشتیبانی می شوند؟**
+
+- یعنی Browser app, desktop app, mobile app, CLI
+
+**برای ابزار گره، آیا نرم افزار راه آسانی برای جابجایی بین مشتریان ارائه می دهد؟**
+
+- آیا کاربر می تواند به راحتی و با خیال راحت مشتریان را با استفاده از ابزار تغییر دهد؟
+
+**برای SaaS، چند اعتباردهنده در حال حاضر توسط این سرویس کار میکنند؟**
+
+- این به ما ایده ای از میزان دسترسی شما تا کنون می دهد.
+
+## نحوه نمایش نتایج {#product-ordering}
+
+[معیارهای گنجاندن](#criteria-for-inclusion) بالا برای محاسبه امتیاز تجمیعی برای هر محصول یا خدمات استفاده میشود. این به عنوان وسیله ای برای مرتب سازی و نمایش محصولاتی که معیارهای عینی خاصی دارند استفاده می شود. هر چه معیارهای بیشتری برای شواهد ارائه شود، محصول در رده بالاتر مرتب می شود و پیوندها بر اساس بار تصادفی می شوند.
+
+منطق کد و وزن این معیارها در حال حاضر در [این جزء جاوا اسکریپت](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) در مخزن ما موجود است.
+
+## محصول یا سرویس خود را اضافه کنید {#add-product}
+
+اگر میخواهید محصول یا خدماتی را به ethereum.org اضافه کنید، یک مسئله در گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/contributing/adding-wallets/index.md b/public/content/translations/fa/contributing/adding-wallets/index.md
new file mode 100644
index 00000000000..8f1e1e21f81
--- /dev/null
+++ b/public/content/translations/fa/contributing/adding-wallets/index.md
@@ -0,0 +1,80 @@
+---
+title: افزودن کیف پول
+description: سیاستی که هنگام افزودن کیفپول به ethereum.org استفاده می کنیم
+lang: fa
+---
+
+# افزودن کیف پول {#adding-wallets}
+
+ما میخواهیم مطمئن شویم که یک طیف گسترده از کیف پولهایی را که کاربران به وسیله آنها میتوانند از ویژگیهای غنی اتریوم استفاده نمایند را نشان میدهیم.
+
+هر کس میتواند اضافه شدن کیف پول جدید به سایت ethereum.org را پیشنهاد کند. اگر کیف پولی وجود دارد که آن را جا انداختیم، لطفاً آن را پیشنهاد دهید!
+
+لیست کیف پولهای فعلی:
+
+- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/)
+
+کیف پولها به سرعت در اتریوم تغییر میکنند. ما تلاش کردیم که یک چارچوب منصفانه برای بررسی و فهرست در ethereum.org ایجاد کنیم، اما معیارهای فهرست بندی در طول زمان تغییر می کنند و تکامل می یابند.
+
+## چارچوب تصمیمات {#the-decision-framework}
+
+### معیارهای گنجانده شدن: موارد ضروری {#the-must-haves}
+
+- **امنیت محصول آزمایش شده باشد** - امنیت کیف پول شما از طریق حسابرسی امنیتی، تیم داخلی امنیت، منبع باز بودن کد یا سایر روشها، باید کاملاً تضمین شده باشد. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
+- **کیف پول حداقل به مدت شش ماه برای استفاده در دسترس بوده یا توسط یک گروه معتبر و با شهرت قابل ردیابی عرضه شده باشد** - این امر نشان دیگر امنیت است. شش ماه بازه زمانی مناسبی برای یافتن نقصهای امنیتی حیاتی میباشد. همچنین گذشت شش ماه به تمایز پروژههای معتبر با پروژههایی که صرفا فورک شدهاند کمک میکند.
+- **یک تیم فعال بر روی آن کار میکنند** - این مورد کیفیت کیف پول را تضمین میکند و به کاربر اطمینان میدهد که برای سؤالات و مشکلاتش پشتیبانی دریافت خواهد کرد.
+- **اطلاعات فهرست شده صادقانه و دقیق** - انتظار میرود هر گونه پیشنهاد پروژه ها، با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات خود را تحریف کنند، مانند منبع باز اعلان کردن کد پروژه در حالی که برخلاف واقعیت باشد، حذف خواهند شد.
+- **نقطه تعامل** - یک نقطه تعامل با کیف پول کمک بزرگی به ما میکند تا به هنگام اعمال تغییرات اطلاعات دقیقی کسب نمائیم. این امر، بروزرسانی ethereum.org را در هنگام جمعآوری اطلاعات آینده قابل مدیریت نگه می دارد.
+- **تراکنشهای EIP-1559 (نوع2)** - کیف پول شما باید از تراکنشهای EIP-1559 (نوع2) برای تراکنشهای شبکه اصلی اتریوم پشتیبانی کند.
+- **تجربه کاربری خوب** - در حالی که UX یک مفهوم ذهنی است، اگر چندین عضو اصلی تیم محصول را آزمایش کنند و استفاده از آن دشوار باشد، ما حق عدم تایید کیفپول را برای خود محفوظ می داریم و در عوض پیشنهادهای مفیدی برای بهبود ارائه می دهیم. این کار برای محافظت از پایگاه کاربرانمان که عمدتاً از مبتدیان تشکیل شده است انجام میشود.
+
+### حذف محصول {#product-removals}
+
+- **اطلاعات به روز شده** - ارائه دهندگان کیفپول مسئول ارسال مجدد اطلاعات کیفپول خود هر 6 ماه یکبار برای اطمینان از اعتبار و مرتبط بودن اطلاعات ارائه شده هستند (حتی اگر هیچ تغییری در محصول آنها وجود نداشته باشد). اگر تیم محصول نتواند این کار را انجام دهد، ethereum.org ممکن است پروژه را از صفحه حذف کند.
+
+### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#the-nice-to-haves}
+
+- **دسترسیپذیری جهانی** - کیفپول شما دارای محدودیت های جغرافیایی یا الزامات KYC نیست که افراد خاصی را از دسترسی به خدمات شما محروم می کند.
+- **به چندین زبان موجود است** - کیف پول شما به چندین زبان ترجمه شده است و به کاربران در سراسر جهان امکان دسترسی به آن را می دهد.
+- **منبع باز** - کل پایگاه کد پروژه شما (نه فقط ماژول ها) باید در دسترس باشد و باید روابط عمومی از جامعه گستردهتر را بپذیرید.
+- **غیرسرپرستی** - کاربران وجوه خود را کنترل می کنند. اگر پروژه و محصول شما زمانی ناپدید شود، کاربران همچنان بتوانند به وجوه خود دسترسی داشته باشند و آن را جابجا کنند.
+- **پشتیبانی از کیف پول سخت افزاری** - کاربران می توانند کیف پول سخت افزاری خود را برای امضای تراکنش ها متصل کنند.
+- **WalletConnect** - کاربران می توانند با استفاده از WalletConnect به دپها (dapps) متصل شوند.
+- **وارد کردن نقاط پایانی RPC اتریوم ** - کاربران میتوانند دادههای RPC گره را وارد کنند و به آنها امکان میدهد به گره مورد نظر خود یا سایر شبکههای سازگار با EVM متصل شوند.
+- **NFT ها** - کاربران می توانند NFT های خود را در کیف پول مشاهده کرده و با آنها تعامل داشته باشند.
+- **اتصال به برنامه های اتریوم** - کاربران می توانند به برنامه های اتریوم متصل شوند و از آنها استفاده کنند.
+- **سهامگذاری** - کاربران میتوانند مستقیماً از طریق کیف پول اقدام به سهامگذاری کنند.
+- **سوآپها** - کاربران میتوانند توکنها را از طریق کیف پول سوآپ کنند.
+- **شبکه های چند زنجیره ای** - کیف پول شما به طور پیش فرض از دسترسی کاربران به چندین شبکه بلاکچین پشتیبانی می کند.
+- **شبکه های لایه 2** - کیف پول شما به طور پیش فرض از دسترسی کاربران به شبکه های لایه 2 پشتیبانی می کند.
+- **سفارشی کردن کارمزدهای گس** - کیف پول شما به کاربران امکان می دهد کارمز گس تراکنش خود را سفارشی کنند (کارمزد پایه، کارمزد اولویت، حداکثر کارمزد).
+- **پشتیبانی از ENS** - کیف پول شما به کاربران امکان می دهد تراکنش ها را به نام های ENS ارسال کنند.
+- **پشتیبانی از ERC-20** - کیف پول شما به کاربران امکان می دهد آدرس قراردادهای توکن ERC-20 را وارد کنند یا به طور خودکار توکن های ERC-20 را جستجو و نمایش دهند.
+- **خرید رمزارز** - کیف پول شما از کاربرانی پشتیبانی میکند که مستقیماً رمزارز را خریداری میکنند و به آن متصل میشوند.
+- **فروش به قیمت فیات** - کیف پول شما از کاربرانی پشتیبانی میکند که مستقیماً به کارت یا حساب بانکی به فیات بفروشند و برداشت کنند.
+- **چندامضایی** - کیف پول شما از چندین امضا برای امضای تراکنش پشتیبانی می کند.
+- **بازیابی اجتماعی** - کیف پول شما از نگهبانان پشتیبانی میکند و اگر کاربر عبارت اصلی خود را با استفاده از این محافظها گم کند، میتواند کیف پول خود را بازیابی کند.
+- **تیم پشتیبانی اختصاصی** - کیف پول شما دارای یک تیم پشتیبانی اختصاصی است که کاربران می توانند در صورت بروز مشکلات به آن مراجعه کنند.
+- **منابع/اسناد آموزشی** - محصول شما باید یک تجربه نصب خوب طراحی شده برای کمک و آموزش کاربران داشته باشد. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
+
+## افزودن یک کیف پول {#adding-a-wallet}
+
+اگر میخواهید یک کیف پول به ethereum.org اضافه کنید، یک مسئله در گیتهاب ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
+
+## نگهداری {#maintenance}
+
+از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
+
+- اطمینان حاصل کنید که همه کیف پول ها و دپ های لیست شده هنوز معیارهای ما را برآورده می کنند.
+- اطمینان حاصل کنیم هیچ محصولی پیشنهاد نشده باشد که معیارهای بیشتری از محصولات فهرست شده فعلی را رعایت کند و آن را اضافه نکرده باشیم
+
+ethereum.org توسط جامعه منبع باز نگهداری می شود و ما به جامعه برای کمک به بهروز نگه داشتن این موضوع متکی هستیم. اگر متوجه هر گونه اطلاعاتی در مورد کیف پول های لیست شده اید که باید به روز شوند، لطفاً [یک مسئله باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) یا [درخواستهای ادغام](https://github.com/ethereum/ethereum-org-website/pulls) ارسال کنید!
+
+
+## شرایط استفاده {#terms-of-use}
+
+لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
diff --git a/public/content/translations/fa/contributing/content-resources/index.md b/public/content/translations/fa/contributing/content-resources/index.md
new file mode 100644
index 00000000000..0788f58b182
--- /dev/null
+++ b/public/content/translations/fa/contributing/content-resources/index.md
@@ -0,0 +1,32 @@
+---
+title: اضافه کردن منابع محتوا
+lang: fa
+description: معیارهای ما برای لیست کردن منابع محتوا در ethereum.org
+---
+
+# اضافه کردن منابع محتوا {#adding-content-resources}
+
+ما نمی توانیم امیدوار باشیم که همه چیز Ethereum را پوشش دهیم بنابراین سعی می کنیم برخی از مقالات، آموزش ها، خبرنامه ها، صفحه های شغلی و منابع محتوایی مختلف را که جامعه ایجاد می کند به نمایش بگذاریم. این موارد اغلب اطلاعات عمیق تری در مورد موضوعاتی که کاربران ممکن است به آن ها علاقه مند باشند، فراهم می کنند.
+
+اگر یک منبع محتوایی وجود دارد که احساس می کنید باید به یک صفحه اضافه شود، با خیال راحت آن را در جایی مناسب پیشنهاد دهید.
+
+## چگونه تصمیم می گیریم {#how-we-decide}
+
+منابع یادگیری با معیارهای زیر ارزیابی خواهند شد:
+
+- آیا محتوا به روز است?
+- آیا برای محتوا پرداخت هم هست؟
+- آیا اطلاعات دقیق هستند؟ آیا واقعی است یا مبتنی بر نظر؟
+- آیا نویسنده قابل اعتماد است؟ آیا آنها منابع خود را اعلام کرده اند؟
+- آیا این محتوا ارزش متمایزی دارد که منابع/لینک های موجود پوشش نمی دهند؟
+- آیا این محتوا به درد یکی از [شخصیت های کاربری](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c) ما می خورد؟
+
+---
+
+## منابع محتوای خود را اضافه کنید {#add-your-content-resource}
+
+اگر می خواهید یک منبع محتوا به ethereum.org اضافه کنید و معیارها را رعایت می کند، در GitHub یک مسئله ایجاد کنید.
+
+
+ یک مسئله ایجاد کنید
+
diff --git a/public/content/translations/fa/contributing/design-principles/index.md b/public/content/translations/fa/contributing/design-principles/index.md
new file mode 100644
index 00000000000..3c406e6ae09
--- /dev/null
+++ b/public/content/translations/fa/contributing/design-principles/index.md
@@ -0,0 +1,93 @@
+---
+title: اصول طراحی
+lang: fa
+description: اصول طراحی ethereum.org و تصمیم گیری های محتوایی
+---
+
+# اصول طراحی ما {#contributing-to-ethereumorg-}
+
+ سلام، به اصول طراحی برای ethereum.org خوش آمدید. این بخشی از یک فرآیند مداوم برای تکامل و بهبود ethereum.org است.
+
+اصول ما، ظاهر و حس سایت و محتوایی که در آن وجود دارد را مشخص می کند.
+
+پیش از [عضویت در ethereum.org](/contributing/) باید این موارد را مطالعه کنید.
+
+## اصول طراحی چیست؟ {#ways-to-contribute}
+
+نگران نباشید، خیلی ساده اند! **اصول طراحی** مجموعه ای از دستورالعمل هایی هستند که ما در هنگام طراحی (یعنی ایجاد، حفظ یا به روز رسانی) چیزی به آن ها استناد می کنیم.
+
+در زمینه ethereum.org، این اصول طراحی پایه و اساس چیزی است که میخواهیم وبسایت نشان دهد و به جهان ارائه دهد. آن ها هم آرمانی هستند **و** هم کاربردی. این تنها _ظاهر_ وب سایت نیست، بلکه نحوه _کارکرد_ و حتی _احساسی_ است که در فرد ایجاد می کند. همه چیز، از رنگ ها گرفته تا چیدمان صفحه و نحوه صحبت درباره اتریوم در وب سایت باید با این اصول ارائه شود.
+
+## اصول در عمل {#how-decisions-about-the-site-are-made}
+
+به مثال زیر توجه کنید. یکی از این اصول "اعتبار" است، به این معنی که ما می خواهیم بازدیدکنندگان سایت _احساس کنند_ و _بدانند_ که سایت قابل اعتماد است - درست مانند اکوسیستم گستردهتر اتریوم. در این اصل، ما 3 "زیر اصول" کاربردی داریم که معتقدیم گام های عملی هستند که می توانیم برای معتبر کردن سایت برداریم:
+
+- _"تازه"_ یعنی محتوا را به روز نگه دارید.
+- _"اثبات اجتماعی"_ یعنی نشان دادن اندازه، تنوع و فعالیت اکوسیستم (میدانید: پیشرفت ارتقا اتریوم، دیفای (DeFi)، بازی، تمام هکاتون ها و...)
+- _"سازگار"_ یعنی ثبات در طراحی سایت و لحن و درستی نگارش.
+
+بنابراین هنگامی که ما در حال تصمیم گیری در مورد طراحی، یا تصمیم گیری در مورد کپی رایت هستیم، می توانیم به اصل "اعتبار" اشاره کنیم و بپرسیم:
+
+- _"آیا این سایت اطلاعات بهروز شده را منعکس می کند؟"_
+- _"ما چگونه و در کجا اندازه و فعالیت اکوسیستم را نشان می دهیم؟"_
+- _"آیا طرح های پیشنهادی جدید یکی از اعضای جامعه که در حال بررسی آن ها هستم، با طرح فعلی و نوشته های موجود در سایت همخوانی دارد؟"_
+
+## اصول طراحی ethereum.org {#contributors}
+
+### 1. الهام بخش {#1-inspirational}
+
+سایت باید الهام بخش کاربران باشد تا ببینند اتریوم چگونه می تواند دنیا را تغییر دهد. باید افراد را به اکتشاف، بازی و سرهم بندی با ابزارها و برنامه های اکوسیستم اتریوم ترغیب کند.
+
+- **رادیکال**: این سایت باید اهداف بلندپروازانه اتریوم را برای تغییر عمده جهان بیان کند. باید واضح باشد که Ethereum تنها یک دسته فن آوری جدید نیست - بلکه یک فن آوری تحول آفرین است.
+- **توانمندسازی از طریق آموزش:** سایت باید افراد را آموزش دهد تا بتوانند پتانسیل اتریوم را درک کنند، جایگاه خود را در اکوسیستم پیدا کنند و برای مشارکت در آن احساس قدرت کنند.
+
+هدایت بصری • محتوا
+
+### 2. جهانی {#2-universal}
+
+اتریوم یک پروژه جهانی و غیر متمرکز است و مخاطبان ما این موضوع را منعکس می کنند. سایت باید این دورنما را داشته باشد که برای همه قابل دسترس باشد و نسبت به بسیاری از فرهنگ های جهان حساس باشد.
+
+- **دسترسی پذیر:** سایت باید از دستورالعمل های دسترسی - از جمله برای افرادی که اتصالات با پهنای باند پایین دارند - پیروی کند.
+- **ساده و سرراست:** سایت باید ساده و بدون ابهام باشد. متن نباید از زبانی استفاده کند که ممکن است در ترجمه اشتباه تعبیر شود یا گم شود.
+- **اتریوم چند وجهی است:** اتریوم یک پروژه، یک مجموعه کد، یک جامعه و یک چشم انداز است. اتریوم به دلایل مختلف برای افراد مختلف ارزشمند است و راه های زیادی برای مشارکت در آن وجود دارد.
+
+سیستم های نوشتاری • استفاده از رنگ • هدایت بصری • محتوا
+
+### 3. یک داستان خوب {#3-a-good-story}
+
+وب سایت باید مانند یک داستان خوب عمل کند. بازدیدکنندگان در یک سفر هستند و محتوایی که ارائه می دهید بخشی از آن است. مشارکت های شما باید در یک روایت روشن قرار گیرند: روایتی با یک آغاز (نقطه ورود / مقدمه)، میانی (مجموعه ای از آموخته ها و بینش ها)، و پایانی (پیوند(ها) به منابع مرتبط، یا مراحل بعدی).
+
+- **سلسله مراتبی**: یک معماری اطلاعاتی واضح و سلسله مراتبی به بازدیدکنندگان سایت ethereum.org کمک می کند تا سایت را "به عنوان یک داستان" در مسیر رسیدن به اهداف خود دنبال کنند.
+- **سنگ محک:** ما سنگ محک برای هر کسی هستیم که به دنبال پاسخ است. ما نمی خواهیم جایگزین بسیاری از منابعی شویم که در حال حاضر وجود دارند. ما پاسخ میدهیم & گامهای بعدی قابلاطمینان را ارائه میدهیم.
+
+سفرهای کاربر • محتوا
+
+### 4. اعتبار {#4-credible}
+
+افراد ممکن است به دنبال معرفی خود به اکوسیستم اتریوم باشند یا ممکن است شکاک باشند. این مسئولیت را در نحوه برقراری ارتباط بپذیرید. اطمینان حاصل کنید که هر دو با اطمینان بیشتری از اکوسیستم اتریوم خارج می شوند.
+
+- **تازه:** همیشه به روز.
+- **اثبات اجتماعی:** نشان دادن اندازه، تنوع و فعالیت اکوسیستم.
+- **سازگار:** ثبات در طراحی و محتوا اعتبار را نشان میدهد.
+
+هدایت بصری • محتوا
+
+### 5. بهبود مشارکتی {#5-collaborative-improvement}
+
+وب سایت حاصل کار بسیاری از مشارکت کنندگان است، درست مانند اکوسیستم به عنوان یک کل.
+
+- **باز:** شفافیت کد منبع، فرآیندها و پروژهها را در سراسر اکوسیستم جشن می گیریم.
+- **قابل توسعه:** مدولار بودن یک تمرکز کلیدی در پشت هر کاری است که انجام میدهیم، بنابراین مشارکتها نیز باید ماژولار باشند. طراحی اصلی، کد جزء& و اجرای سایت باید امکان توسعه آسان آن را در آینده فراهم کند.
+- **تجربی:** ما دائماً در حال آزمایش، تست و تکرار هستیم.
+- ** مشارکتی:** این پروژه همه ما را گرد هم می آورد.
+- **پایدار:** آمادهسازی برای نگهداری طولانی مدت توسط جامعه
+
+شما می توانید اصول طراحی ما را در عمل [در سایت ما](/) ببینید.
+
+## بازخورد بدهید {#give-feedback}
+
+**نظرات خود را در مورد این سند با ما در میان بگذارید!** یکی از اصول پیشنهادی ما "**بهبود مشارکتی**" است، به این معنی که ما می خواهیم وب سایت، محصول بسیاری از مشارکت کنندگان باشد. بنابراین باتوجه به این اصل، می خواهیم این اصول طراحی را با جامعه اتریوم به اشتراک بگذاریم.
+
+در حالی که این اصول روی وب سایت ethereum.org متمرکز شده اند، امیدواریم که بسیاری از آن ها نماینده ارزش های کلی اکوسیستم اتریوم باشند (به عنوان مثال می توانید تاثیر [اصول وایتپیپر اتریوم](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy) را ببینید). شاید حتی بخواهید برخی از آن ها را در پروژه خود بگنجانید!
+
+نظرات خود را از طریق [سرور Discord](https://discord.gg/ethereum-org) یا به وسیله [ایجاد یک مسئله](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) با ما در میان بگذارید.
diff --git a/public/content/translations/fa/contributing/design/adding-design-resources/index.md b/public/content/translations/fa/contributing/design/adding-design-resources/index.md
new file mode 100644
index 00000000000..c6fb9945253
--- /dev/null
+++ b/public/content/translations/fa/contributing/design/adding-design-resources/index.md
@@ -0,0 +1,69 @@
+---
+title: افزودن منابع طراحی
+description: دستورالعمل ها و الزامات برای اطمینان از کیفیت مواد طراحی در ethereum.org
+lang: fa
+---
+
+# افزودن منابع طراحی {#adding-design-resources}
+
+هر کسی می تواند مواد طراحی جدید را به [طراحی و تجربه کاربری در صفحه Web3](/developers/docs/design-and-ux/) پیشنهاد دهد.
+
+توجه داشته باشید که تمرکز این صفحه بر ارائه ارزش کاربری به طراحان مشتاق Web3 است. بخش طراحی، برای تبلیغ خدمات، محصولات یا پلتفرم های شما نیست.
+
+برای اطمینان از استاندارد بالای اطلاعات و ترویج بینشهای ارزشمند، ما یک خطمشی فهرستبندی ایجاد کردهایم:
+
+## مطالعات پژوهشی و داشبوردها {#Research-studies}
+
+1. روش شناسی منطقی
+
+الف. روش باید به وضوح نحوه جمع آوری داده ها را مشخص کند.
+
+ب. تعداد شرکت کنندگان در تحقیق باید ذکر شود.
+
+ج. روش های تحقیق مورد استفاده باید شرح داده شود.
+
+2. ارتباط با طراحان Web3 و موارد استفاده معمول طراحی
+
+الف. موضوع تحقیق باید با طراحان Web3 مرتبط باشد و به موارد استفاده رایج از طراحی بپردازد.
+
+3. بر ارائه دیدگاه تمرکز کنید
+
+الف. هدف اصلی متن باید به اشتراک گذاشتن دیدگاه باشد تا ترویج یک پروژه یا شرکت خاص.
+
+## مقالات {#Articles}
+
+1. ارتباط با طراحان/محققان Web3 و موارد استفاده معمول طراحی Web3
+
+الف. موضوع مقاله باید مربوط به طراحان و محققان Web3 باشد و بر موارد استفاده از طراحی Web3 متداول متمرکز باشد.
+
+2. کیفیت پایه نگارش
+
+الف. مقاله باید عاری از اشتباهات گرامری و املایی باشد.
+
+ب. باید بر ارائه دیدگاه ها و مطالب کلیدی تاکید شود.
+
+ج. نوشته باید مختصر و دقیق باشد.
+
+3. هدف مقاله
+
+الف. هدف اصلی مقاله باید به اشتراک گذاشتن دیدگاه باشد تا تبلیغ یک پروژه یا شرکت خاص.
+
+## جوامع / DAOها {#Communities-and-DAOs}
+
+1. وبسایت باید به وضوح نحوه پیوستن به DAO/جامعه را نشان دهد
+
+2. مزایای آشکار عضویت
+
+الف. مزایای عضویت باید به طور برجسته نشان داده شوند.
+
+**مثالها**: دریافت بازخورد در مورد کار، دسترسی به فرصتهای شغلی یا جوایز، اشتراکگذاری دیدگاه های طراحی و تحقیق.
+
+3. ارتباط فعال و پر جنب و جوش در دیسکورد
+
+الف. جامعه دیسکورد باید ارتباط پر جنب و جوش و فعالی را به نمایش بگذارد.
+
+ب. مدیران باید به طور فعال در حفظ جامعه و تسهیل بحث ها مشارکت داشته باشند.
+
+ج. جامعه باید سابقه مکالمات ارزشمند و سازنده را در دو هفته گذشته نشان دهد.
+
+با رعایت این معیارها، هدف ما ایجاد یک محیط پر رونق و به اشتراکگذاری دانش در جامعه است. ما معتقدیم که این خط مشی لیست مجاز تضمین می کند که کاربران ما به منابع قابل اعتماد، مرتبط و روشنگر دسترسی دارند. از درک و همکاری شما در حفظ کیفیت محتوا در بستر ما سپاسگزاریم.
diff --git a/public/content/translations/fa/contributing/design/index.md b/public/content/translations/fa/contributing/design/index.md
new file mode 100644
index 00000000000..34fc9131d43
--- /dev/null
+++ b/public/content/translations/fa/contributing/design/index.md
@@ -0,0 +1,77 @@
+---
+title: همکاری در طراحی
+description: همکاری طراحی با ethereum.org
+lang: fa
+---
+
+# همکاری طراحی با ethereum.org {#design-contributions}
+
+طراحی، یک بخش حیاتی هر پروژه است، و با اختصاص دادن زمان و مهارتهای طراحیتان به ethereum.org میتوانید به بهتر شدن تجربه کاربری بازدیدکنندگان ما کمک کنید. مشارکت در یک پروژه منبع باز فرصتی را برای کسب تجربه مرتبط و توسعه مهارت های خود در یک محیط مشارکتی فراهم می کند. شما این شانس را خواهید داشت که با دیگر طراحان، توسعه دهندگان و اعضای جامعه کار کنید، که همگی دیدگاه ها و بینش های منحصر به فرد خود را خواهند داشت.
+
+در نهایت، این یک راه عالی برای ایجاد یک نمونه کار متنوع و چشمگیر است که مهارت های طراحی شما را به نمایش می گذارد.
+
+## روش مشارکت؟
+
+### در مورد نمونه های اولیه طراحی بازخورد بدهید {#design-critique}
+
+ما گاهی برای آزمایش ایده های خام خود به کمک نیاز داریم. این یک راه عالی برای مشارکت بدون هیچ دانش فنی است.
+
+1. تیم طراحی یک طرح ماکت را در [Discord](https://discord.com/invite/ethereum-org) و در [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) به اشتراک خواهد گذاشت.
+2. برای ارائه بازخورد از طریق عملکرد نظرات، از طریق طرح ها راهنمایی خواهید شد.
+3. نتیجه در مسئله گیتهاب به اشتراک گذاشته می شود و سپس توسط تیم بسته می شود.
+
+### در تحقیقات نظرسنجی شرکت کنید {#answer-surveys}
+
+به این روشها در وب سایت ما بازخورد ارائه کنید:
+
+1. بازدید از ethereum.org و خواندن صفحات.
+2. کلیک بر روی ویجت بازخورد در گوشه سمت راست پایین و پاسخ به سوالات مربوط به طراحی و محتوا.
+3. روی سوالات با فرمت آزاد تمرکز کنید.
+
+### مسائل مربوط به طراحی را در وب سایت بیابید و گزارش دهید {#report-design-issues}
+
+Ethereum.org وبسایتی است با ویژگیها و محتوای زیاد که سریع در حال رشد است. برخی از UIها به راحتی می توانند منسوخ شوند یا می توانند بهبود یابند. اگر با چنین موردی مواجه شدید، لطفا گزارش دهید تا توجه ما را به خود جلب کند.
+
+1. وب سایت را مرور کنید و به طراحی آن توجه کنید.
+2. در صورت مشاهده هر گونه مشکل بصری یا UX، اسکرین شات بگیرید و یادداشت کنید.
+3. مشکلات پیدا شده را با استفاده از [گزارش باگ](https://github.com/ethereum/ethereum-org-website/issues/new/choose) گزارش دهید.
+
+### تغییرات طراحی را پیشنهاد بدهید {#propose-design-changes}
+
+اگر در چالشهای طراحی احساس راحتی میکنید، میتوانید از صفحه مسائل گیتهاب ما دیدن کنید و [مسائل مرتبط با طراحی](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) را فیلتر کنید.
+
+1. وب سایت ما را مرور کنید و به طراحی آن توجه کنید یا به مخزن گیتهاب ما بروید و مسائل دارای علامت [“Design required”](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) را بررسی کنید.
+2. در مورد راه حل ایده بگیرید و آن را طراحی کنید. (در حالت ایده آل از [سیستم طراحی](https://www.figma.com/community/file/1134414495420383395) ما استفاده کنید).
+3. راه حل را در مسئله مربوطه پیشنهاد دهید یا [یک راه حل جدید ایجاد کنید.](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)
+4. منتظر بررسی تیم طراحی باشید.
+
+### سیستم طراحی را با هم بسازیم {#Contribute-to-design-system}
+
+سیستم طراحی ما طراحی ethereum.org را سرگرم کننده و آسان می کند. اگر شما یک طراح با تجربه هستید، می توانید به ما در تهیه بسیاری از اجزای وب سایت کمک کنید.
+
+1. مشکلی را برای کار از [برد سیستم طراحی](https://github.com/ethereum/ethereum-org-website/labels/design%20system) در GitHub انتخاب کنید یا یک مورد جدید ایجاد کنید.
+2. درخواست کنید موضوع انتخاب شده به شما اختصاص داده شود.
+3. طراحی قطعه درخواست شده در فیگما را آغاز کنید.
+4. پس از نیاز به بررسی یا راهنمایی، آن را با تیم طراحی در گیتهاب به اشتراک بگذارید.
+5. تیم طراحی بررسی خواهد کرد.
+6. تیم طراحی، تغییرات را در فایل اصلی خواهد گنجاند و فایل را برای جامعه منتشر خواهد کرد.
+
+### مطالب مرتبط با طراحی را در وب سایت بنویسید {#write-design-articles}
+
+جامعه توسعه دهندگان اتریوم قوی است، اما جامعه طراحی کمی عقبتر است. اگر شما یک طراح با دانش Web3 هستید، لطفاً در نظر داشته باشید که آموخته های خود را با جامعه بزرگتر به اشتراک بگذارید تا همه با هم رشد و پیشرفت کنیم. ما [صفحه ای برای طراحی اتریوم داریم](/developers/docs/design-and-ux/) که می توانید در آن مشارکت کنید. همچنین میتوانید [خطمشیهای لیستینگ](/contributing/design/adding-design-resources) ما را بررسی کنید.
+
+1. در مورد موضوعات طراحی که باید در ethereum.org پوشش داده شود و برای طراحان در فضا میتوانند مفید باشند، فکر کنید.
+2. به مخزن گیتهاب ما بروید و [مسئلهای را مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new) که یک موضوع را پیشنهاد میدهد (فعلا محتوا را ننویسید).
+3. منتظر تایید تیم طراحی باشید.
+4. پس از تایید، محتوا را بنویسید.
+5. آن را در مسئله گیتهاب مربوطه ارائه کنید.
+
+### تصاویر جدید بکشید {#prepare-illustrations}
+
+تصویرسازیها یکی از قدرتمندترین ابزارها برای توضیح موضوعات انتزاعی هستند. با افزودن نمودارها و اینفوگرافیک ها پتانسیل بسیار زیادی وجود دارد. به هر حال، یک تصویر می تواند هزاران کلمه را بیان کند.
+
+1. به وبسایت ما بروید و صفحاتی را ببینید که در آنها میتوان اینفوگرافیکهای جدید اضافه کرد.
+2. مطمئن شوید که سبک تصویر با [داراییهای](/assets/) ما مطابقت دارد.
+3. به مخزن گیتهاب ما بروید و در مورد ارائه تصویر [یک مسئله مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new).
+4. تیم طراحی آن را بررسی خواهد کرد.
+5. ما یک مسئله جدید ایجاد می کنیم تا از یک توسعه دهنده بخواهیم تصویر جدید را اجرا کند.
diff --git a/public/content/translations/fa/contributing/index.md b/public/content/translations/fa/contributing/index.md
new file mode 100644
index 00000000000..2dd47a1bc41
--- /dev/null
+++ b/public/content/translations/fa/contributing/index.md
@@ -0,0 +1,117 @@
+---
+title: در حال مشارکت
+description: در مورد روش های مختلفی که می توانید به ethereum.org کمک کنید، بیاموزید
+lang: fa
+---
+
+# مشارکت در ethereum.org 🦄 {#contributing-to-ethereumorg}
+
+Ethereum.org یک پروژه اجرا شده منبع باز با **بیش از 12000** مشارکت کننده است که به ترجمه، نگارش، طراحی و نگهداری وبسایت کمک می کنند.
+
+ما از جامعهای استقبال میکنیم که به شما کمک میکند در اکوسیستم اتریوم رشد کرده و آموزش ببینید و در عین حال به طور معناداری مشارکت کنید و تجربیات عملی مرتبط را کسب کنید!
+
+## روش های مشارکت {#ways-to-contribute}
+
+**ترجمه**
+- [به برنامه ترجمه بپیوندید](/contributing/translation-program/) – به ما کمک کنید ethereum.org را به زبان های جدید ترجمه کنیم
+
+**توسعه**
+- [روی یک مسئله باز کار کنید](https://github.com/ethereum/ethereum-org-website/issues) - کاری که ما تشخیص داده ایم نیاز به انجام دارد
+
+**طراحی**
+- [کمک به طراحی وب سایت](/contributing/design/) طراحان همه سطوح می توانند به بهبود وب سایت کمک کنند
+
+**محتوا**
+- [ایجاد/ویرایش محتوا](/contributing/#how-to-update-content) - صفحات جدیدی پیشنهاد دهید یا تغییراتی را در آنچه قبلاً در اینجا وجود دارد ایجاد کنید
+- [افزودن منابع جامعه](/contributing/content-resources/) - یک مقاله یا منبع مفید را به صفحه مربوطه اضافه کنید
+- [یک منبع طراحی پیشنهاد کنید](/contributing/design/adding-design-resources/) – منابع طراحی مفید را اضافه کنید، بهروزرسانی کنید و حذف کنید
+- [افزودن اصطلاح به واژه نامه](/contributing/adding-glossary-terms/) – به ما در ادامه گسترش [واژه نامه](/glossary/) اتریوم کمک کنید
+- [آزمونها](/contributing/quizzes/) - بانکهای سوالات آزمون را برای صفحه مربوطه اضافه، بهروزرسانی و حذف کنید
+
+**ایده برای ویژگیها**
+- [درخواست یک ویژگی](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – در مورد هر ایده ای که برای یک ویژگی یا طراحی جدید دارید به ما اطلاع دهید
+
+**لیستینگ های محصول**
+- [افزودن صرافی](/contributing/adding-exchanges/) – افزودن صرافی به [صرافییاب](/get-eth/#country-picker) ما
+- [افزودن محصول](/contributing/adding-products/) - یک دپ (dapp) یا کیف پول به صفحه مربوطه اضافه کنید
+- [افزودن ابزارهای توسعه دهنده](/contributing/adding-developer-tools/) – یک ابزار توسعه دهنده را به صفحه مربوطه اضافه کنید
+- [افزودن یک لایه 2](/contributing/adding-layer-2s/) - یک لایه 2 را به صفحه مربوطه اضافه کنید
+- [افزودن یک محصول یا خدمات سهامگذاری](/contributing/adding-staking-products/) – پروژه ای اضافه کنید که به تسهیل سهامگذاری انفرادی، سهامگذاری ادغام شده، یا سهامگذاری به عنوان خدمات کمک می کند
+- [افزودن کیف پول](/contributing/adding-wallets/) – افزودن کیف پول برای [صفحه جستجوی کیف پول](/wallets/find-wallet/)
+- [پیشنهاد پروژه برای صفحه DeSci ما](/contributing/adding-desci-projects/) – اضافه کردن پروژه ای بر پایه اتریوم که به دانش غیرمتمرکز کمک می کند
+
+سوال دیگری دارید؟ 🤔 عضو [سرور دیسکورد](https://discord.gg/ethereum-org) ما شوید
+
+## اولین اقدامات خوب برای شروع مشارکت
+
+اینها چند کار جاری هستند که می توانید به ما در حل آنها کمک کنید و مسئولیت آنها را بپذیرید. برای اکثر آنها به حساب گیتهاب نیاز دارید زیرا اکثر تغییرات در وب سایت از طریق گیتهاب انجام می شود.
+
+
+
+مشاهده تمام کارها
+
+## چطور میتوان در ethereum.org کار کرد {#how-to-update-content}
+
+اگر میخواهید در [برنامه ترجمه](/contributing/translation-program/) مشارکت کنید، از شما میخواهیم یک حساب در [Crowdin](https://crowdin.com/project/ethereum-org) ایجاد کنید. برای هر چیز دیگر - اضافه کردن یا ویرایش محتوا یا تصاویر به وب سایت، رفع اشکالات، کار بر روی کارهای باز - به یک حساب [GitHub](https://github.com/) نیاز دارید.
+
+تمام به روز رسانی ها از طریق فرآیند PR مربوط به GitHub انجام می شود. این بدان معنی است که شما یک نسخه محلی از وب سایت ایجاد می کنید، تغییرات خود را ایجاد می کنید و درخواست می کنید تا تغییرات خود را ادغام کنید. اگر قبلاً این کار را نکردهاید، دستورالعملهای موجود در پایین [مخزن GitHub](https://github.com/ethereum/ethereum-org-website) ما را دنبال کنید.
+
+برای کار بر روی هر چیزی به اجازه نیاز ندارید، اما همیشه بهتر است به ما اطلاع دهید که قصد انجام چه کاری را دارید. روش انجام این کار:
+
+- اظهار نظر در مورد یک مسئله یا PR در [GitHub](https://github.com/ethereum/ethereum-org-website)
+- ارسال پیام در [سرور دیسکورد](https://discord.gg/ethereum-org) ما
+
+قبل از مشارکت، مطمئن شوید که با موارد زیر آشنا هستید:
+
+- [دیدگاه ethereum.org](/about/) در حال تکامل
+- [اصول طراحی](/contributing/design-principles/) ما
+- [راهنمای سبک](/contributing/style-guide/) ما
+- [آیین رفتاری](/community/code-of-conduct) ما
+
+
+
+## نحوه تصمیم گیری در مورد سایت {#how-decisions-about-the-site-are-made}
+
+تصمیم گیری در مورد روابط عمومی فردی، تکامل طراحی و ارتقاءهای عمده توسط تیمی از سراسر اکوسیستم اتریوم گرفته می شود. این تیم شامل مدیران پروژه، توسعه دهندگان، طراحان، بازاریابی و ارتباطات و کارشناسان موضوع است. ورودی جامعه، هر تصمیم را اطلاع می دهد: بنابراین لطفاً در مسائل سؤالات خود را مطرح کنید، PR ارسال کنید یا با تیم تماس بگیرید:
+
+- [website@ethereum.org](mailto:website@ethereum.org)
+- [@ethdotorg](https://twitter.com/ethdotorg)
+- [سرور دیسکورد](https://discord.gg/ethereum-org)
+
+### یادداشتی در مورد سرقت ادبی {#plagiarism}
+
+هنگام مشارکت هر گونه محتوا یا محصول در ethereum.org فقط از اثر یا محتوای اصلی خود استفاده کنید که اجازه استفاده از آن را دارید. بسیاری از پروژههای موجود در اکوسیستم اتریوم از مجوز منبع باز استفاده میکنند که امکان اشتراکگذاری رایگان اطلاعات را فراهم میکند. با این حال، اگر نمی توانید این اطلاعات را پیدا کنید، سعی نکنید آن را به ethereum.org اضافه کنید. هر درخواست ادغام که به عنوان سرقت ادبی تلقی شود رد خواهد شد.
+
+## در فضای منبع باز تازه کار هستید؟ {#new-to-open-source}
+
+ما در مخزن GitHub خود موانع کمی برای ورود مسائل داریم که به طور خاص برای توسعه دهندگانی که به تازگی با منبع باز کار میکنند، با برچسب [اولین مسئله خوب](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) طراحی شده اند.
+
+## توکن موفقیت روی زنجیر (OAT) خود را مطالبه کنید {#oat}
+
+اگر مشارکت شما در ethereum.org ادغام شود، فرصتی برای مطالبه یک توکن ویژه در [Galxe](https://app.galxe.com/quest/ethereumorg) خواهید داشت. توکن OAT دلیلی بر این است که شما کمک کردید اکوسیستم کمی بهتر شود.
+
+[جزئیات بیشتر درباره OATها](https://help.galxe.com/en/articles/7067290-galxe-oats-reward-and-celebrate-achievements)
+
+### چگونه درخواست کنید
+1. به [سرور دیسکورد](https://discord.gg/ethereum-org) ما بپیوندید.
+2. لینک مشارکت خود را در کانال `#🥇 | اثبات مشارکت` قرار دهید
+3. منتظر بمانید تا یکی از اعضای تیم ما لینک OAT را برای شما ارسال کند.
+4. OAT خود را درخواست کنید!
+
+برای مطالبه OAT فقط باید از کیف پول های خودسرپرستی استفاده کنید. از حسابهای صرافی یا سایر حسابهایی که کلیدهای خصوصی را در اختیار ندارید، استفاده نکنید، زیرا به شما اجازه دسترسی و مدیریت OAT را نمیدهند.
+
+## GitPOAP خود را مطالبه کنید {#claim-gitpoap}
+
+GitPOAP همچنین به طور خودکار مشارکت ادغام شده شما را تشخیص می دهد و به شما امکان می دهد یک POAP مشارکت کننده منحصر به فرد جداگانه را در خود پلتفرم آنها ایجاد کنید!
+
+
+### چگونه درخواست کنیم {#how-to-claim}
+
+1. [GitPOAP](https://www.gitpoap.io) را ببینید.
+2. از طریق گزینه ورود به سیستم با کیف پول خود یا حتی با ایمیل خود ارتباط برقرار کنید.
+3. نام کاربری گیتهاب، آدرس اتر، نامهای ENS یا هرگونه GitPOAP خود را جستجو کنید تا بررسی کنید واجد شرایط هستید یا خیر.
+4. اگر حساب گیتهاب شما واجد شرایط باشد، می توانید یک GitPOAP ایجاد کنید!
+
+## مشارکت کنندگان {#contributors}
+
+
diff --git a/public/content/translations/fa/contributing/quizzes/index.md b/public/content/translations/fa/contributing/quizzes/index.md
new file mode 100644
index 00000000000..77c2a880896
--- /dev/null
+++ b/public/content/translations/fa/contributing/quizzes/index.md
@@ -0,0 +1,62 @@
+---
+title: اضافه کردن یک آزمون
+description: سیاستی که هنگام اضافه کردن آزمونها به ethereum.org استفاده میکنیم
+lang: fa
+---
+
+# آزمون ها {#quizzes}
+
+آزمونها فرصتی هستند برای کاربران تا خود را امتحان کنند و ببینند آیا محتوای صفحهای که تازه خواندهاند را درک کردهاند یا نه. سؤالات باید فقط بر اساس محتوای ارائه شده در صفحه باشند و نباید درباره اطلاعاتی که در صفحه ذکر نشده است، پرسیده شوند.
+
+ساختار سؤالات باید به صورت زیر باشد. متن سؤال، یک پاسخ صحیح با توضیح دلیل صحت آن، و سه پاسخ نادرست هر کدام با توضیح درباره دلیل نادرست بودنشان.
+
+برای مشاهده برخی نمونههای آزمونهای فعلی، به اینجا مراجعه کنید:
+
+- [لایه 2](/layer-2)
+- [نیفتی](/nft/)
+- [اتریوم چیست؟](/what-is-ethereum/)
+- [اتر (ETH) چیست؟](/eth/)
+
+## اضافه کردن یک آزمون یادگیری
+
+اگر صفحهای وجود دارد که هنوز آزمون یادگیری برای آن ایجاد نشده است، لطفا [یک درخواست جدید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) برای آن ثبت کنید.
+
+لطفا اطلاعات زیر را ارائه دهید:
+
+- صفحهای که میخواهید آزمون را به آن اضافه کنید
+- 5 سؤال با اطلاعات زیر:
+ - بخشی از صفحه که سؤال بر اساس آن است
+ - عنوان سؤال
+ - یک پاسخ صحیح به همراه توضیحاتی درباره دلیل صحت آن
+ - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
+
+## اضافه کردن یک سؤال آزمون
+
+اگر سؤالی وجود دارد که می خواهید به بانک سؤالات آزمون اضافه کنید، لطفا [یک درخواست جدید باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) و اطلاعات زیر را ارائه دهید:
+
+- صفحه ای که می خواهید سؤال آزمون را به آن اضافه کنید
+- برای هر سؤال (که اضافه می شود) اطلاعات زیر را ارائه کنید:
+ - بخشی از صفحه که سؤال بر اساس آن است
+ - عنوان سؤال
+ - یک پاسخ صحیح به همراه توضیحاتی دربارهی دلیل صحت آن
+ - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
+
+## بهروز رسانی یک سؤال آزمون
+
+اگر سؤالی وجود دارد که می خواهید به بانک سؤالات آزمون اضافه کنید، لطفا [یک درخواست جدید باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) و اطلاعات زیر را ارائه دهید:
+
+- صفحه ای که می خواهید سؤال آزمون را در آن بهروز رسانی کنید
+- برای هر سؤالی که بهروز رسانی میشود، اطلاعات زیر را ارائه دهید:
+ - بخشی از صفحه که سؤال بر اساس آن است
+ - عنوان سؤالی که میخواهید بهروز رسانی کنید
+ - عنوان بهروز رسانی شده سؤال
+ - یک پاسخ صحیح به همراه توضیحاتی درباره دلیل صحت آن
+ - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
+
+## حذف یک سؤال آزمون
+
+اگر محتوا برای یک سؤال در صفحه وجود ندارد و باید حذف شود، لطفا [یک درخواست](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) برای حذف سؤال ارسال کنید و اطلاعات زیر را بدهید:
+
+- صفحه ای که می خواهید سؤال آزمون را در آن حذف کنید
+- پرسشی که می خواهید حذف کنید
+- توضیح در صورت لزوم برای دلیل حذف پرسش
diff --git a/public/content/translations/fa/contributing/translation-program/faq/index.md b/public/content/translations/fa/contributing/translation-program/faq/index.md
new file mode 100644
index 00000000000..830700d36da
--- /dev/null
+++ b/public/content/translations/fa/contributing/translation-program/faq/index.md
@@ -0,0 +1,119 @@
+---
+title: سوالات متداول برنامه ترجمه
+lang: fa
+description: سوالات متداول درباره برنامه ترجمه ethereum.org
+---
+
+# راهنمای ترجمه ethereum.org {#translating-ethereum-guide}
+
+اگر در برنامه ترجمه تازه وارد هستید و تردید دارید که وارد شوید، در اینجا برخی از سوالات متداول هستند که میتوانند به شما کمک کنند کار را آغاز کنید. از این راهنما برای یافتن پاسخ به متداول ترین پرسش ها استفاده کنید.
+
+## آیا می توانم برای ترجمه ethereum.org دستمزد دریافت کنم؟ {#compensation}
+
+Ethereum.org یک وب سایت منبع باز است، به این معنی که هر کس می تواند مشارکت کند.
+
+برنامه ترجمه ethereum.org یک برنامه جانبی آن است و با فلسفه مشابه سازماندهی شده است.
+
+هدف برنامه ترجمه این است که محتوای اتریوم را برای همه، صرف نظر از زبان هایی که صحبت می کنند، در دسترس قرار دهد. همچنین به هر فرد دوزبانه اجازه می دهد تا با اکوسیستم اتریوم درگیر شود و به روشی قابل دسترس مشارکت کند.
+
+به همین دلیل، برنامه ترجمه آزاد و داوطلبانه است و شرکت در آن شامل پرداخت دستمزد نمی باشد. اگر می خواستیم به مترجمان بابت تعداد کلماتی که ترجمه می کنند دستمزد بدهیم، فقط می توانستیم از کسانی که تجربه ترجمه کافی دارند (مترجمان حرفه ای) دعوت کنیم تا به برنامه ترجمه بپیوندند. این امر برنامه ترجمه را انحصاری میکرد و ما را از دستیابی به اهداف مشخص شده باز میداشت، به ویژه: اجازه دادن به همه برای مشارکت و درگیر شدن با اکوسیستم.
+
+ما تمام تلاش خود را می کنیم تا مشارکت کنندگان خود را قادر به موفقیت در اکوسیستم اتریوم کنیم. بسیاری از مشوق های غیر پولی مانند: [ارائه POAP](/contributing/translation-program/acknowledgements/#poap) و [گواهی مترجم](/contributing/translation-program/acknowledgements/#certificate) و همچنین سازماندهی [ تابلوهای امتیازات ترجمه](/contributing/translation-program/acknowledgements/) و [فهرست کردن همه مترجمان ما در سایت](/contributing/translation-program/contributors/) وجود دارند.
+
+## چگونه می توانم سطرهای دارای `` را ترجمه کنم؟ {#tags}
+
+هر متن به شکل نوشته خالص نوشته نمیشود. متن هایی هستند که متشکل از اسکریپت های مختلفی مثل تگ های اچتیامال (`<0>`,`0>`) هستند.
+
+- متن داخل تگ ها را ترجمه کنید اما خود تگ ها را ترجمه نکنید. هیچ چیزی درون `<` و `>` نباید ترجمه یا حذف شود.
+- جهت امن نگه داشتن متن، پیشنهاد میکنیم روی دکمه "Copy Source" در گوشه پایین چپ کلیک کنید. این کار متن اولیه را کپی و در قسمت متن درج میکند. این به شما اجازه میدهد مشخص کنید که تگ ها کجا هستند و کمک میکند از اشتباه جلوگیری کنید.
+
+![رابط Crowdin با دکمه کپی از منبع، مشخص شده است](./html-tag-strings.png)
+
+شما میتوانید موقعیت تگ ها را درون متن تغییر داده و آنرا مطابق زبان خود طبیعی تر کنید - فقط اطمینان حاصل کنید تمام تگ جابجا شود.
+
+برای اطلاعات عمیقتر در مورد کار با تگها و اجزای کد، لطفاً به [راهنمای سبک ترجمه ethereum.org](/contributing/translation-program/translators-guide/#dealing-with-tags) مراجعه کنید.
+
+## متن ها کجا زندگی میکنند؟ {#strings}
+
+اغلب اوقات ممکن است کلمه های زبان منبع به تنهایی برای ارائه ترجمه دقیق کافی نباشد.
+
+- برای اطلاعات بیشتر به «اسکرین شات ها» و «زمینه» نگاهی بیندازید. در بخش سطر منبع، تصویر اسکرین شات پیوست شده را خواهید دید که نحوه استفاده از سطر در متن را به شما نشان می دهد.
+- هنگامی که مطمئن نیستید، یک پرچم در "بخش نظرات" قرار دهید. [نمیدانید چگونه نظر بدهید؟](#comment)
+
+![نشان دادن این که چگونه پسزمینه برای یک سطر دارای اسکرینشات قابل ارائه است](./source-string.png)
+
+![یک اسکرینشات نمونه برای زمینه اضافه شد](./source-string-2.png)
+
+## چگونه می توانم نظر بگذارم یا سوال بپرسم؟ می خواهم یک مسئله یا اشتباه تایپی را با پرچم نشان دهم... {#comment}
+
+اگر میخواهید روی متن خاصی که نیاز به توجه دارد پرچم قرار دهید، با خیالی آسوده نظر خود را بگذارید.
+
+- بر روی دکمه دوم نوار سمت راست بالا کلیک کنید. زبانه مخفی در سمت راست شما ظاهر خواهد شد. یک نظر جدید بگذارید و روی مربع "Issue" در پایین کلیک کنید. میتوانید نوع مساله را با انتخاب یکی از گزینههای منوی کرکرهای مشخص کنید.
+- پس از ارسال، این مورد به تیم ما گزارش می شود. ما مشکل را برطرف خواهیم کرد و با پاسخ دادن به نظر شما و بستن مسئله به شما اطلاع خواهیم داد.
+- اگر یک ترجمه نادرست را گزارش کنید، ترجمه و پیشنهاد شما توسط یک فرد با زبان اصلی در تجدید نظر بعدی بررسی میشود.
+
+![نشان دادن نحوه ارائه نظرات و مسائل](./comment-issue.png)
+
+## حافظه ترجمه یا TM چیست؟ {#translation-memory}
+
+حافظه ترجمه (TM) یکی از ویژگی های Crowdin است که تمام متن های ترجمه شده قبلی را در [ethereum.org](http://ethereum.org/) ذخیره می کند. هنگامی که یک متن ترجمه می شود، به طور خودکار در TM پروژه ما ذخیره می شود. این میتواند ابزاری مفید برای کمک به شما به منظور صرفهجویی در زمان باشد!
+
+- به بخش «پیشنهادات TM و MT» نگاه کنید و خواهید دید که دیگر مترجمان چگونه متن مشابه یا یکسانی را ترجمه کرده اند. اگر گزینهای با درجه تطابق بالا پیدا کردید، با خاطری آسوده با کلیک بر روی آن به ترجمه آن مراجعه کنید.
+- اگر چیزی در لیست وجود ندارد، میتوانید ترجمههای قبلی را در TM جستجو کنید و برای هماهنگی، مجددا از آنها استفاده کنید.
+
+![اسکرین شات حافظه ترجمه](./translation-memory.png)
+
+## چگونه از واژه نامه Crowdin استفاده کنم؟ {#glossary}
+
+اصطلاحات اتریوم بخش مهم دیگری از کار ترجمه ما است، زیرا اغلب اصطلاحات فناوری جدید هنوز در بسیاری از زبانها بومیسازی نشده اند. همچنین اصطلاحاتی وجود دارند که در زمینه های مختلف معانی متفاوت دارند. [درباره ترجمه اصطلاحات اتریوم بیشتر بدانید](#terminology)
+
+واژه نامه Crowdin بهترین مکان برای شفاف سازی اصطلاحات و تعاریف است. برای مراجعه به واژه نامه دو راه وجود دارد.
+
+- ابتدا، هنگامی که یک عبارت با خط زیر را در متن زیان منبع پیدا کردید، می توانید ماوس را روی آن قرار دهید و تعریف مختصری از آن را مشاهده کنید.
+
+![یک مثال از تعریف واژه نامه](./glossary-definition.png)
+
+- دوم، اگر عبارتی را دیدید که برایتان آشنا نیست اما زیر آن خط کشیده نشده است، می توانید آن را در زبانه واژه نامه (دکمه سوم ستون سمت راست) جستجو کنید. در آنجا توضیحاتی در مورد اصطلاحات خاص و مواردی که اغلب در پروژه استفاده می شود را خواهید یافت.
+
+![یک اسکرین شات که نشان می دهد کجا باید برگه واژه نامه را در Crowdin پیدا کنید](./glossary-tab.png)
+
+- اگر هنوز نتوانستید آن را پیدا کنید، فرصتی برای اضافه کردن یک عبارت جدید است! ما توصیه می کنیم آن را در یک موتور جستجو بیابید و توضیحات را به واژه نامه اضافه کنید. این کمک بزرگی به مترجمان دیگر برای درک بهتر این اصطلاح خواهد کرد.
+
+![یک اسکرین شات که نشان می دهد چگونه می توان یک اصطلاح واژه نامه را به Crowdin اضافه کرد](./add-glossary-term.png)
+
+### سیاست ترجمه اصطلاحات {#terminology}
+
+_برای نامها (برندها، شرکتها، افراد) و اصطلاحات فناوری جدید (بیکن چین، زنجیرههای شارد و غیره)_
+
+اتریوم اصطلاحات جدیدی را ارائه می کند که اخیراً ابداع شده اند. برخی اصطلاحات از مترجمی به مترجم دیگر متفاوت است زیرا هیچ ترجمه رسمی به زبان مربوطه آنها وجود ندارد. چنین ناهماهنگی هایی می تواند باعث سوء تفاهم شود و خوانا بودن را کاهش دهد.
+
+با توجه به تنوع زبانی و استانداردسازی های مختلف در هر زبان، ارائه یک سیاست یکپارچه ترجمه اصطلاحات که بتواند در همه زبان های پشتیبانی شده قابل انطباق باشد، تقریبا غیرممکن بوده است.
+
+پس از بررسی دقیق، به این تصمیم رسیدیم که پرکاربردترین اصطلاحات را به شما مترجمان بسپاریم.
+
+هنگامی که اصطلاحی را پیدا می کنید که برای شما ناآشنا است، پیشنهاد می کنیم:
+
+- به [واژه نامه اصطلاحات](#glossary) مراجعه کنید، ممکن است ببینید که مترجمان دیگر پیشتر چگونه آن را ترجمه کرده اند. اگر فکر میکنید اصطلاحی که قبلاً ترجمه شده مناسب نیست، با آسودگی یک عبارت جدید را به واژهنامه Crowdin بیافزایید و ترجمه خود را بازیابی کنید.
+- اگر چنین ترجمه قبلی در واژه نامه وجود ندارد، توصیه می کنیم آن را در یک موتور جستجو یا مقالهای در یک رسانه جستجو کنید که نشان می دهد این عبارت واقعاً چگونه در جامعه شما استفاده می شود.
+- اگر اصلاً هیچ مرجعی پیدا نکردید، با آسودگی به درک خود اعتماد کنید و ترجمه جدیدی را به زبان خود پیشنهاد دهید!
+- اگر برای انجام این کار اعتماد به نفس کمتری دارید، اصطلاح را ترجمه نشده بگذارید. گاهی اوقات، اصطلاحات انگلیسی در ارائه تعاریف دقیق بیش از اندازه کافی هستند.
+
+توصیه میکنیم نام برندها، شرکتها و کارکنان را ترجمه نشده بگذارید زیرا ممکن است ترجمه باعث سردرگمی غیر ضروری و مشکلات بهینه سازی موتور جستجو (SEO) شود.
+
+## روند ویرایش چگونه است؟ {#review-process}
+
+برای اطمینان از سطح مشخصی از کیفیت و سازگاری در ترجمههایمان، ما با [Acolad](https://www.acolad.com/)، یکی از بزرگترین ارائهدهندگان خدمات زبان در سطح جهان، کار میکنیم. Acolad دارای 20،000 کارشناس حرفه ای زبان است، به این معنی که آنها می توانند برای هر زبان و نوع محتوایی که نیاز داریم، داوران حرفه ای ارائه دهند.
+
+روند ویرایش ساده است. هنگامی که یک [سبد محتوا](/contributing/translation-program/content-buckets) 100٪ ترجمه شد، ما سفارش بررسی آن سبد محتوا را می دهیم. فرآیند ویرایش مستقیماً در Crowdin انجام می شود. پس از تکمیل ویرایش، وبسایت را با محتوای ترجمه شده به روز می کنیم.
+
+## چگونه به زبان خودم محتوا اضافه کنم؟ {#adding-foreign-language-content}
+
+هماکنون، تمام محتواهای غیر انگلیسی مستقیما از انگلیسی ترجمه میشوند و هر محتوایی که در زبانی غیر از انگلیسی موجود باشد نمیتواند به دیگر زبانها اضافه شود.
+
+برای پیشنهاد محتوای جدید به ethereum.org، میتوانید در گیتهاب [یک مسئله ثبت کنید.](https://github.com/ethereum/ethereum-org-website/issues). در صورت اضافه شدن، این محتوا به انگلیسی نوشته میشود و با استفاده از Crowdin به دیگر زبانها ترجمه میشود.
+
+ما در نظر داریم پشتیبانی برای محتواهای غیر انگلیسی را در آیندهای نزدیک اضافه کنیم.
+
+## در ارتباط باشید {#contact}
+
+متشکریم که تمام این مطالب را مطالعه کردید. امیدواریم این کار به شما کمک کند تا در برنامه ما حضور داشته باشید. به [کانال ترجمه دیسکورد](https://discord.gg/ethereum-org) ما بپیوندید و در آن از دیگر مترجمین سوال بپرسید و با آنها همکاری کنید، یا با ما با ایمیل translations@ethereum.org در ارتباط باشید!
diff --git a/public/content/translations/fa/contributing/translation-program/how-to-translate/index.md b/public/content/translations/fa/contributing/translation-program/how-to-translate/index.md
new file mode 100644
index 00000000000..994adc6f47a
--- /dev/null
+++ b/public/content/translations/fa/contributing/translation-program/how-to-translate/index.md
@@ -0,0 +1,89 @@
+---
+title: چگونه ترجمه کنیم
+lang: fa
+description: راهنمای استفاده از Crowdin جهت ترجمه ethereum.org
+---
+
+# چگونه ترجمه کنیم {#how-to-translate}
+
+## راهنمای تصویری {#visual-guide}
+
+برای افرادی که یادگیری تصویری را ترجیح میدهند، راهنمای ساخت حساب کاربری Crowdin با لوکا را تماشا کنید. همچنین میتوانید تمامی مراحل طی شده را در قالب متن، در بخش بعدی پیدا کنید.
+
+
+
+## راهنمای نوشتاری {#written-guide}
+
+### به پروژه ما در سایت Crowdin بپیوندید {#join-project}
+
+شما باید به حساب کاربری خود در Crowdin وارد شوید و یا اگر از قبل حسابی ندارید، ثبتنام کنید. برای ثبت نام تنها چیزی که لازم است یک حساب ایمیل و رمز عبور است.
+
+
+ به پروژه ما بپیوندید
+
+
+### زبان خود را انتخاب کنید {#open-language}
+
+بعد از ورود به حساب Crowdin، شما جزئیات پروژه و لیست تمامی زبانهای موجود را مشاهده خواهید کرد. همچنین، هر زبان شامل اطلاعاتی درباره تعداد کل کلمات قابل ترجمه و یک نمای کلی از مقدار محتوای ترجمه و تائید شده در آن زبان میباشد.
+
+زبانی که میخواهید ترجمه کنید را انتخاب نموده تا لیست فایلهای موجود برای ترجمه را مشاهده کنید.
+
+![فهرست زبان ها در Crowdin](./list-of-languages.png)
+
+### سندی را برای کار پیدا کنید {#find-document}
+
+محتوای وب سایت به تعدادی اسناد و سطل محتوا تقسیم می شود. می توانید پیشرفت هر سند را در سمت راست بررسی کنید - اگر پیشرفت ترجمه زیر 100٪ است، لطفا مشارکت کنید!
+
+زبان خود را در فهرست نمی بینید؟ [یک مسئله باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new/choose) یا در [دیسکورد](/discord/) ما بپرسید
+
+![فایل های ترجمه شده و ترجمه نشده در Crowdin](./crowdin-files.png)
+
+نکتهای در مورد سبد های محتوا: ما از «سبد های محتوا» در Crowdin استفاده میکنیم تا ابتدا محتوای دارای بالاترین اولویت منتشر شود. زمانی که یک زبان، برای مثال [فیلیپینی](https://crowdin.com/project/ethereum-org/fil#) را نگاه میکنید، پوشههایی برای سبد محتوا میبینید («۱. صفحه خانه»، «۲. ضروریات"، "3. اکتشاف"، و غیره).
+
+ما به شما توصیه میکنیم به ترتیب (... → ۳ → ۲ → ۱) ترجمه کنید که صفحات با بیشترین استفاده اول ترجمه شوند.
+
+[درباره سبدهای محتوای ethereum.org بیشتر بیاموزید](/contributing/translation-program/content-buckets/)
+
+### ترجمه کنید {#translate}
+
+پس از انتخاب فایلی که می خواهید ترجمه کنید، در ویرایشگر آنلاین باز خواهد شد. اگر قبلاً از Crowdin استفاده نکردهاید، میتوانید از این راهنمای سریع برای مرور اصول اولیه استفاده کنید.
+
+![ویرایشگر آنلاین Crowdin](./online-editor.png)
+
+**_1 – نوار کناری سمت چپ_**
+
+- ترجمه نشده (قرمز) – متنی که هنوز روی آن کار نشده است. اینها متن هایی هستند که باید ترجمه کنید.
+- ترجمه شده (سبز) - متنی که قبلا ترجمه شده است، اما هنوز بازبینی نشده است. میتوانید ترجمههای دیگری را پیشنهاد دهید یا با استفاده از دکمههای «+» و «-» در ویرایشگر، به ترجمههای موجود رأی دهید.
+- تایید شده (علامت تیک) - متنی که قبلاً بررسی شده و در حال حاضر در وبسایت فعال است.
+
+همچنین میتوانید از دکمههای بالای صفحه به منظور جستجوی متنی خاص، فیلتر کردن آنها بر اساس وضعیت یا تغییر نما استفاده کنید.
+
+**_2 - بخش ویرایشگر_**
+
+منطقه اصلی ترجمه - متن مبدأ در بالا با زمینه و اسکرینشات های اضافی، در صورت وجود، نمایش داده می شود. برای پیشنهاد ترجمه جدید، ترجمه خود را در قسمت "Enter translation here" وارد کنید و روی Save کلیک کنید.
+
+همچنین میتوانید ترجمههای موجود متن و ترجمهها به زبانهای دیگر و همچنین تطبیق حافظه ترجمه و پیشنهادات ترجمه ماشینی را در این بخش بیابید.
+
+**_3 - نوار کناری سمت راست_**
+
+اینجا جایی است که می توانید نظرات، گزینههای حافظه ترجمه و گزینههای واژه نامه را بیابید. نمای پیشفرض نظرات را نشان میدهد و به مترجمان اجازه میدهد با هم ارتباط برقرار کنند، مسائل را مطرح کنند یا ترجمههای نادرست را گزارش کنند.
+
+با استفاده از دکمههای بالای صفحه، میتوانید به حافظه ترجمه بروید که در آن میتوانید ترجمههای موجود را جستجو کنید، یا به واژهنامه بروید که حاوی توضیحات و ترجمههای استاندارد واژههای کلیدی است.
+
+میخواهید بیشتر بدانید؟ با خیالی راحت می توانید [اسناد نحوه استفاده از ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) را بررسی کنید
+
+### فرایند بازبینی {#review-process}
+
+هنگامی که ترجمه را کامل کردید (یعنی همه فایلهای سبد محتوا 100% را نشان میدهد)، خدمات ترجمه حرفهای ما محتوا را بررسی میکند (و احتمالاً ویرایش میکند). پس از تکمیل بررسی (یعنی وقتی پیشرفت بازبینی 100٪ شد)، آن را به وب سایت اضافه می کنیم.
+
+
+ لطفا از ترجمههای ماشینی برای ترجمه پروژه استفاده نکنید. همه ترجمهها پیش از اضافه شدن به وبسایت بررسی میشوند. اگر ترجمههای شما، ترجمه ماشینی به نظر برسند، رد میشوند و افرادی که از ترجمههای ماشینی استفاده کنند معمولا از پروژه حذف میشوند.
+
+
+### در ارتباط باشید {#get-in-touch}
+
+سوالی دارید؟ یا می خواهید با تیم ما و سایر مترجمان همکاری کنید؟ لطفاً در کانال [سرور دیسکورد ethereum.org](/discord/) ما پست کنید
+
+همچنین می توانید از طریق translations@ethereum.org با ما در تماس باشید
+
+از مشارکت شما در برنامه ترجمه ethereum.org سپاسگزاریم!
diff --git a/public/content/translations/fa/contributing/translation-program/index.md b/public/content/translations/fa/contributing/translation-program/index.md
new file mode 100644
index 00000000000..f97ffa43681
--- /dev/null
+++ b/public/content/translations/fa/contributing/translation-program/index.md
@@ -0,0 +1,90 @@
+---
+title: برنامه ترجمه
+lang: fa
+description: اطلاعاتی درباره برنامه ترجمه ethereum.org
+---
+
+# برنامه ترجمه {#translation-program}
+
+برنامه ترجمه یک تلاش مشترک برای ترجمه ethereum.org به زبان های مختلف است تا این وب سایت برای میلیاردها غیر انگلیسی زبان در سراسر جهان در دسترس تر باشد.
+
+![](./enterprise-eth.png)
+
+## در ترجمه به ما کمک کنید {#help-us-translate}
+
+برنامه ترجمه ethereum.org باز است و هر کس می تواند مشارکت کند!
+
+1. ابتدا باید وارد حساب Crowdin خود شوید یا ثبت نام کنید.
+2. زبانی را که می خواهید در آن مشارکت کنید انتخاب کنید.
+3. قبل از شروع، لطفاً راهنمای [نحوه ترجمه](/contributing/translation-program/how-to-translate/) را برای یادگیری نحوه استفاده از Crowdin و [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) را برای نکات و بهترین روش ها مطالعه کنید.
+4. ترجمههای ماشینی تایید نخواهند شد.
+5. همه ترجمهها قبل از اضافه شدن به سایت اصلی بررسی میشوند، بنابراین قبل از انتشار ترجمههای شما تأخیر کوتاهی وجود خواهد داشت.
+
+_به دیسکورد [ethereum.org Discord](/discord/) بپیوندید تا در ترجمه ها همکاری کنید، سؤال بپرسید، نظرات و ایده ها را به اشتراک بگذارید، یا به یک گروه ترجمه بپیوندید._
+
+
+ شروع به ترجمه کنید
+
+
+## درباره برنامه ترجمه {#about-us}
+
+جامعه اتریوم قصد دارد جهانی و فراگیر باشد، با این حال بسیاری از محتوای آن فقط مختص انگلیسی زبانها است و 6 میلیارد غیرانگلیسی زبان دنیا کنار گذاشته شده اند. برای اینکه ethereum.org به عنوان پورتال اتریوم برای جامعه جهانی عمل کند، ما بر این باوریم که ارائه محتوای اتریوم به زبان مادری برای غیر انگلیسی زبانان ضروری است.
+
+هدف از برنامه ترجمه ethereum.org این است که با ترجمه ethereum.org و دیگر مطالب اتریوم به تعداد زیادی از زبانها، در دسترس همگان قرار گیرد.
+
+درباره [مأموریت و چشم انداز](/contributing/translation-program/mission-and-vision) برنامه ترجمه ethereum.org بیشتر بخوانید.
+
+### پیشرفت ما تاکنون {#our-progress}
+
+- [بیش از **6,000 +** مترجم](/contributing/translation-program/contributors/)
+- **62** زبان در سایت موجود است
+- [ترجمه **3 میلیون** کلمه در سال 2023](/contributing/translation-program/acknowledgements/)
+
+
+
+### تقدیرات {#acknowledgements}
+
+Ethereum.org توسط هزاران نفر از اعضای انجمن، ترجمه شده و این جامعه بخش کلیدی برنامه ترجمه است. ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. در اینجا برخی از قدردانی های ما از مترجمان آمده است. ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. در اینجا برخی از قدردانی های ما از مترجم ها آمده است:
+
+#### گواهی {#certificate}
+
+اگر در برنامه ترجمه مشارکت کرده اید و حداقل 5000 کلمه ترجمه شده شما تایید شده است، واجد شرایط دریافت گواهی مترجم ethereum.org هستید. [جزئیات بیشتر در باره گواهیها](/contributing/translation-program/acknowledgements/#certificate)
+
+#### OATها {#oats}
+
+مشارکت کنندگان در برنامه ترجمه بر اساس تعداد کلمات ترجمه شده در سال 2024، واجد شرایط OAT های مختلف (توکن های موفقیت زنجیره ای) هستند. OATها NFTهایی هستند که مشارکت شما در برنامه ترجمه ethereum.org را ثابت می کنند. [جزئیات بیشتر درباره OATها](/contributing/translation-program/acknowledgements/#oats)
+
+#### قدردانی از مترجمها {#translator-acknowledgements}
+
+قدردانی عمومی از مترجمان برتر ما از طریق [تابلوهای امتیازات](/contributing/translation-program/acknowledgements/) و [فهرستی از همه مشارکت کنندگان در برنامه ترجمه](/contributing/translation-program/contributors/) می باشد.
+
+#### پاداشها {#rewards}
+
+در گذشته، ما به فعالترین مشارکتکنندگان خود، بلیطهایی برای کنفرانسهای اتریوم مانند [Devcon](https://devcon.org/en/) و [Devconnect](https://devconnect.org/) و همچنین کادوهای انحصاری ethereum.org پاداش دادهایم.
+
+ما دائماً به روشهای جدید و نوآورانه برای پاداش دادن به مشارکتکنندگان خود فکر میکنیم، پس با ما همراه باشید!
+
+### راهنماها و منابع {#guides-and-resources}
+
+اگر در برنامه ترجمه مشارکت می کنید یا به فکر مشارکت هستید، باید راهنمای ترجمه زیر را بررسی کنید:
+
+- [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) _– دستورالعمل ها و نکاتی برای مترجمان ethereum.org_
+- [سؤالات متداول ترجمه](/contributing/translation-program/faq/) _– پرسشها و پاسخهای متداول درباره برنامه ترجمه ethereum.org_
+- [راهنمای ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) _– یک راهنمای عمیق برای استفاده از ویرایشگر آنلاین Crowdin و برخی ویژگی های پیشرفته Crowdin_
+- [سطل های محتوا](/contributing/translation-program/content-buckets/)_ – کدام صفحات در هر سطل محتوای ethereum.org گنجانده شده است_
+
+برای بررسی دیگر ابزارهای مفید ترجمه، انجمن های مترجمین و پست های وبلاگ برنامه ترجمه، لطفاً از [صفحه منابع](/contributing/translation-program/resources/) دیدن کنید.
+
+## در ارتباط باشید {#get-in-touch}
+
+سوالی دارید؟ یا می خواهید با تیم ما و سایر مترجمان همکاری کنید؟ لطفاً در کانال [سرور دیسکورد ethereum.org](https://discord.gg/ethereum-org) ما پست کنید
+
+همچنین می توانید از طریق translations@ethereum.org با ما در تماس باشید
+
+## برنامه ترجمه خود را شروع کنید {#starting-a-translation-program}
+
+ما به ترجمه محتوای اتریوم به زبانهای هر چه بیشتر و در دسترس قرار دادن محتوای آموزشی برای همه تعهد داریم. در راستای تمرکزمان بر ترجمه، میخواهیم به سایر پروژههای اتریوم در سازماندهی، مدیریت و بهبود تلاشهای ترجمه آنها کمک کنیم.
+
+به همین دلیل، ما یک [کتابچه برنامه ترجمه](/contributing/translation-program/playbook/) تهیه کرده ایم که حاوی نکات و بهترین روش هایی است که در فرآیند ترجمه ethereum.org به کار گرفته ایم.
+
+آیا میخواهید بیشتر همکاری کنید یا از برخی منابع ترجمهمان استفاده کنید؟ آیا بازخوردی در مورد کتاب بازی دارید؟ ما دوست داریم از نظرات شما در translations@ethereum.org آگاه شویم.
diff --git a/public/content/translations/fa/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/fa/contributing/translation-program/mission-and-vision/index.md
new file mode 100644
index 00000000000..408c60791ed
--- /dev/null
+++ b/public/content/translations/fa/contributing/translation-program/mission-and-vision/index.md
@@ -0,0 +1,25 @@
+---
+title: مأموریت و چشمانداز
+lang: fa
+description: ماموریت و چشم انداز برنامه ترجمه ethereum.org
+---
+
+# مأموریت و چشمانداز {#mission-and-vision}
+
+جامعه اتریوم قصد دارد جهانی و فراگیر باشد، با این حال بسیاری از محتوای آن فقط مختص انگلیسی زبانها است و 6 میلیارد غیرانگلیسی زبان دنیا کنار گذاشته شده اند. برای اینکه ethereum.org به عنوان پورتال اتریوم برای جامعه جهانی عمل کند، ما بر این باوریم که ارائه محتوای اتریوم به زبان مادری برای غیر انگلیسی زبانان ضروری است.
+
+هدف از برنامه ترجمه ethereum.org این است که با ترجمه ethereum.org و دیگر مطالب اتریوم به تعداد زیادی از زبانها، در دسترس همگان قرار گیرد.
+
+## ماموریت ما {#our-mission}
+
+- ارائه نسخههای ترجمهشده وبسایت به بازدیدکنندگان در سراسر جهان برای یادگیری درباره اتریوم به زبان مادری شان
+- تسهیل ورود اعضای بیشتر به جامعه جهانی اتریوم
+- امکان پذیر کردن دسترسی بیشتر و فراگیرتر شدن اشتراک گذاری اطلاعات و دانش اتریوم
+- توانمند ساختن اعضای جامعه برای همکاری در زمینه ترجمه با اتریوم و ایجاد اثر خود در اکوسیستم
+- شناسایی، ایجاد ارتباط و ارائه راهنمایی برای مشارکت کنندگان پرشوری که به دنبال مشارکت در اکوسیستم هستند
+
+## چشمانداز ما {#our-vision}
+
+- ترجمه محتوای اساسی برای اعضای جامعه اتریوم از بسیاری از کشورها و بخشهای جهان تا جایی که ممکن است
+- پشتیبانی اشتراکگذاری دانش به زبانهای مختلف برای ایجاد یک جامعه آگاه و آموزش دیده
+- افزایش فراگیری و دسترسی اتریوم، با حذف موانع زبانی که از پیوستن غیرانگلیسی زبانان به اکوسیستم جلوگیری می کند
diff --git a/public/content/translations/fa/contributing/translation-program/resources/index.md b/public/content/translations/fa/contributing/translation-program/resources/index.md
new file mode 100644
index 00000000000..fa7e39d5113
--- /dev/null
+++ b/public/content/translations/fa/contributing/translation-program/resources/index.md
@@ -0,0 +1,45 @@
+---
+title: منابعی برای مترجمان
+lang: fa
+description: منابع مفید برای مترجمان ethereum.org
+---
+
+# منابع {#resources}
+
+میتوانید برخی از راهنماها و ابزارهای مفید برای مترجمان ethereum.org، و همچنین انجمنهای ترجمه و بروزرسانیها را در زیر بیابید.
+
+## راهنماییها {#guides}
+
+- [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) _– دستورالعمل ها و نکاتی برای مترجمان ethereum.org_
+- [سؤالات متداول ترجمه](/contributing/translation-program/faq/) _– پرسشها و پاسخهای متداول درباره برنامه ترجمه ethereum.org_
+- [راهنمای ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) _– یک راهنمای عمیق برای استفاده از ویرایشگر آنلاین Crowdin و برخی ویژگی های پیشرفته Crowdin_
+- [سطل های محتوا](/contributing/translation-program/content-buckets/)_ – کدام صفحات در هر سطل محتوای ethereum.org گنجانده شده است_
+
+## ابزارها {#tools}
+
+- [پورتال زبان مایکروسافت](https://www.microsoft.com/en-us/language) _– برای یافتن و بررسی ترجمههای استاندارد اصطلاحات فنی، مفید است_
+- [Linguee](https://www.linguee.com/) _– موتور جستجو برای ترجمه ها و فرهنگ لغت که امکان جستجو بر اساس کلمه یا عبارت را فراهم می کند_
+- [جستجوی عبارت Proz](https://www.proz.com/search/) _– پایگاه داده لغت نامه ها و واژه نامه های ترجمه برای اصطلاحات تخصصی_
+- [Eurotermbank](https://www.eurotermbank.com/) _– مجموعههایی از اصطلاحات اروپایی به ۴۲ زبان_
+
+## جوامع {#communities}
+
+- [گروه های ترجمه خاص زبان در دیسکورد](/discord/) _– ابتکاری برای ارتباط مترجمان ethereum.org با گروه های ترجمه_
+- [گروه مترجمان چینی](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _– صفحه ایده برای هماهنگی آسانتر میان مترجمان چینی_
+
+## آخرین به روزرسانی ها {#latest-updates}
+
+برای به روز نگه داشتن آخرین پیشرفت برنامه ترجمه، می توانید [وبلاگ بنیاد اتریوم](https://blog.ethereum.org/) را دنبال کنید:
+
+- [به روز رسانی نقاط عطف اکتبر ۲۰۲۱](https://blog.ethereum.org/2021/10/04/translation-program-update/)
+- [به روز رسانی نقاط عطف دسامبر 2020](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/)
+- [به روز رسانی نقاط عطف ژوئیه 2020](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/)
+- [راه اندازی برنامه ترجمه اوت 2019](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/)
+
+## ساعات کاری برای مترجمین {#office-hours}
+
+ما برای مترجمین، ساعات کاری را در چهارشنبه دوم هر ماه داریم. این ساعات در کانال صوتی (غیرمتنی) #office-hours در [ethereum.org Discord](/discord/) نگهداری میشوند که می توانید زمان دقیق و جزییات بیشتر را در آن بیابید.
+
+ساعات کاری به مترجمان ما امکان میدهد درباره فرآیند ترجمه سؤال بپرسند، درباره برنامه بازخورد ارائه کنند، ایدههای خود را به اشتراک بگذارند یا با تیم اصلی ethereum.org چت کنند. در نهایت، میخواهیم از این ارتباطات برای برقراری ارتباط با پیشرفتهای اخیر در برنامه ترجمه و به اشتراک گذاشتن نکات و دستورالعملهای کلیدی با همکاران مان استفاده کنیم.
+
+اگر شما یک مترجم ethereum.org هستید یا علاقه دارید باشید، میتوانیم در یکی از این جلسات به ما ملحق شوید.
diff --git a/public/content/translations/fa/contributing/translation-program/translators-guide/index.md b/public/content/translations/fa/contributing/translation-program/translators-guide/index.md
new file mode 100644
index 00000000000..730a2a34a0c
--- /dev/null
+++ b/public/content/translations/fa/contributing/translation-program/translators-guide/index.md
@@ -0,0 +1,293 @@
+---
+title: راهنمای مترجمان
+lang: fa
+description: دستورالعمل ها و نکات برای مترجمان ethereum.org
+---
+
+# راهنمای سبک ترجمه Ethereum.org {#style-guide}
+
+راهنمای سبک ترجمه ethereum.org حاوی برخی از مهم ترین دستورالعمل ها، دستورالعمل ها و نکات برای مترجمان است که به ما کمک می کند تا وبسایت را بومی سازی کنیم.
+
+این سند به عنوان یک راهنمای کلی عمل می کند و مختص هیچ زبانی نیست.
+
+اگر سؤال، پیشنهاد یا بازخوردی دارید، میتوانید با ما در آدرس ایمیل translations@ethereum.org تماس بگیرید، به هندل @ethdotorg در Crowdin پیام ارسال کنید، یا [به دیسکورد ما بپیوندید](https://discord.gg/ethereum-org) که در آنجا میتوانید در کانال #translations به ما پیام بدهید یا با هر یک از اعضای تیم تماس بگیرید.
+
+## استفاده از Crowdin {#using-crowdin}
+
+میتوانید دستورالعملهای اساسی در مورد نحوه پیوستن به پروژه در Crowdin و نحوه استفاده از ویرایشگر آنلاین Crowdin را در [صفحه برنامه ترجمه](/contributing/translation-program/#how-to-translate) بیابید.
+
+اگر میخواهید درباره Crowdin و استفاده از برخی از ویژگیهای پیشرفته آن اطلاعات بیشتری کسب کنید، [کتابخانه Crowdin](https://support.crowdin.com/online-editor/) حاوی تعداد زیادی راهنماهای مفید و مروری بر همه عملکردهای Crowdin است.
+
+## دریافت ماهیت پیام {#capturing-the-essence}
+
+هنگام ترجمه محتوای ethereum.org، از ترجمه تحتالفظی اکیداً خودداری کنید.
+
+مهم این است که ترجمه ها جوهر پیام را در بر بگیرند. این میتواند به معنای بازنویسی عبارات خاص یا استفاده از ترجمههای توصیفی به جای ترجمه کلمه به کلمه محتوا باشد.
+
+زبان های مختلف قواعد گرامری، قراردادها و ترتیب کلمات متفاوتی دارند. هنگام ترجمه، لطفاً به نحوه ساختار جملات در زبان مقصد توجه داشته باشید و از ترجمه تحتالفظی منبع انگلیسی خودداری کنید، زیرا این کار می تواند منجر به ساختار ضعیف جمله و خوانایی آن شود.
+
+به جای ترجمه کلمه به کلمه متن مبدأ، توصیه می شود کل جمله را بخوانید و آن را با معادل های زبان مقصد مطابقت دهید.
+
+## رسمی مقابل غیررسمی {#formal-vs-informal}
+
+ما از فرم رسمی آدرس استفاده می کنیم که همیشه مودبانه و مناسب برای همه بازدیدکنندگان است.
+
+استفاده از آدرس رسمی به ما این امکان را می دهد که از به نظر رسیدن غیررسمی یا توهین آمیز جلوگیری کنیم و بدون در نظر گرفتن سن و جنسیت بازدیدکننده کار می کند.
+
+بیشتر زبان های هند و اروپایی و آفریقایی-آسیایی از ضمایر شخصی دوم شخص مخصوص جنسیت استفاده می کنند که بین مذکر و مؤنث تمایز قائل می شود. هنگام خطاب کردن کاربر یا استفاده از ضمایر ملکی، میتوانیم از فرض جنسیت بازدیدکننده خودداری کنیم، زیرا شکل رسمی آدرس، صرف نظر از نحوه شناسایی آنها، عموماً قابل اجرا و سازگار است.
+
+## واژگان و معنی ساده و واضح {#simple-vocabulary}
+
+هدف ما این است که محتوای موجود در وبسایت را برای افراد هر چه بیشتری قابل درک کنیم.
+
+در اغلب موارد، با استفاده از کلمات کوتاه و ساده که به راحتی قابل درک هستند، می توان به این امر دست یافت. اگر چندین ترجمه ممکن برای یک کلمه خاص در زبان شما با همان معنی وجود داشته باشد، بهترین گزینه اغلب کوتاهترین کلمهای است که به وضوح معنی را منعکس میکند.
+
+## سیستم نوشتاری {#writing-system}
+
+Ethereum.org به چندین زبان با استفاده از سیستم های نوشتاری جایگزین (یا اسکریپت های نوشتن) به لاتین در دسترس است.
+
+تمام محتوا باید با استفاده از سیستم نوشتاری صحیح برای زبان شما ترجمه شود و نباید شامل هیچ کلمه ای باشد که با حروف لاتین نوشته شده باشد.
+
+هنگام ترجمه محتوا، باید اطمینان حاصل کنید که ترجمه ها سازگار هستند و شامل هیچ گونه حروف لاتین نمی شوند.
+
+یک تصور غلط رایج این است که اتریوم همیشه باید به زبان لاتین نوشته شود. این بیشتر نادرست است، لطفاً از املای اتریوم بومی زبان خود استفاده کنید (به عنوان مثال 以太坊 در چینی، إيثيريوم در عربی و غیره).
+
+**موارد فوق در مورد زبانها صدق نمیکند، جایی که نامهای خاص بهعنوان قاعده نباید ترجمه شوند.**
+
+## ترجمه متادیتای صفحه {#translating-metadata}
+
+برخی از صفحات حاوی ابرداده در صفحه هستند، مانند «عنوان»، «زبان»، «توضیحات»، «نوار کناری» و غیره.
+
+ما محتوایی را که مترجمان هرگز نباید هنگام آپلود صفحات جدید در Crowdin ترجمه کنند، پنهان می کنیم، به این معنی که تمام متادیتا های قابل مشاهده برای مترجمان در Crowdin باید ترجمه شوند.
+
+لطفاً هنگام ترجمه هر رشته ای که متن مبدأ "en" است، به ویژه مراقب باشید. این نشان دهنده زبانی است که صفحه به آن در دسترس است و باید به [کد زبان ISO برای زبان شما](https://www.andiamo.co.uk/resources/iso-language-codes/) ترجمه شود. این رشته ها باید همیشه با استفاده از حروف لاتین ترجمه شوند، نه خط نوشتاری، بومی زبان مقصد.
+
+اگر مطمئن نیستید از کدام کد زبان استفاده کنید، می توانید حافظه ترجمه را در Crowdin بررسی کنید یا کد زبان خود را در URL صفحه در ویرایشگر آنلاین Crowdin پیدا کنید.
+
+چند نمونه از کدهای زبان برای رایجترین زبانها:
+
+- عربی - ar
+- چینی ساده - zh
+- فرانسه - fr
+- هندی - hi
+- اسپانیایی - es
+
+## عناوین مقالات خارجی {#external-articles}
+
+برخی رشته ها حاوی عناوین مقالات خارجی هستند. اکثر صفحات مستندات توسعه دهنده ما حاوی پیوندهایی به مقالات خارجی برای مطالعه بیشتر هستند. رشته های حاوی عناوین مقالات باید بدون توجه به زبان مقاله ترجمه شوند تا از تجربه کاربری سازگارتر بازدیدکنندگانی که صفحه را به زبان خود مشاهده می کنند اطمینان حاصل شود.
+
+میتوانید نمونههایی از شکل ظاهری این رشتهها برای مترجمان و نحوه شناسایی آنها را در زیر بیابید (پیوندهای مقالهها را میتوانید بیشتر در پایین این صفحات، در بخش «مطالعه بیشتر» پیدا کنید):
+
+![عنوان مقالات در sidebar.png](./article-titles-in-sidebar.png) ![عنوان مقالات در editor.png](./article-titles-in-editor.png)
+
+## هشدارهای Crowdin {#crowdin-warnings}
+
+Crowdin دارای یک ویژگی داخلی است که به مترجمان هنگام اشتباه کردن هشدار می دهد. اگر فراموش کنید برچسبی را از منبع اضافه کنید، عناصری را که نباید ترجمه شوند، چندین فاصله متوالی اضافه کنید، علائم نگارشی پایان را فراموش کنید و غیره را فراموش کنید، قبل از ذخیره ترجمه به طور خودکار به شما در این مورد هشدار می دهد. اگر چنین هشداری را مشاهده کردید، لطفاً به عقب برگردید و ترجمه پیشنهادی را دوباره بررسی کنید.
+
+**هرگز این اخطارها را نادیده نگیرید، زیرا معمولاً به این معنی است که چیزی اشتباه است یا اینکه ترجمه قسمتی کلیدی از متن منبع را از دست داده است.**
+
+نمونه ای از هشدار Crowdin هنگامی که فراموش می کنید یک برچسب به ترجمه خود اضافه کنید: ![نمونه ای از هشدار Crowdin](./crowdin-warning-example.png)
+
+## نحوه کار با برچسب ها و تکه های کد {#dealing-with-tags}
+
+بسیاری از محتوای منبع حاوی برچسب ها و متغیرهایی هستند که در ویرایشگر Crowdin با رنگ زرد مشخص شده اند. اینها کارکردهای مختلفی دارند و باید به درستی به آنها پرداخت.
+
+**تنظیمات Crowdin**
+
+برای سهولت در مدیریت برچسب ها و کپی مستقیم آنها از منبع، توصیه می کنیم تنظیمات خود را در ویرایشگر Crowdin تغییر دهید.
+
+1. تنظیمات را باز کنید ![نحوه باز کردن تنظیمات در ویرایشگر](./editor-settings.png)
+
+2. تا بخش «نمایش برچسبهای HTML» به پایین بروید
+
+3. گزینه 'Hide' را انتخاب کنید ![لطفاً گزینه "پنهان کردن" را انتخاب کنید](./hide-tags.png)
+
+4. روی 'Save' کلیک کنید
+
+با انتخاب این گزینه دیگر متن کامل تگ نمایش داده نمی شود و یک عدد جایگزین می شود. هنگام ترجمه، با کلیک بر روی این تگ، به طور خودکار تگ دقیق در قسمت ترجمه کپی می شود.
+
+**لینکها**
+
+ممکن است متوجه لینک های کامل به صفحات در ethereum.org یا وبسایت های دیگر شوید.
+
+این لینک ها باید با منبع یکسان باشند و تغییر یا ترجمه نشوند. اگر لینکی را ترجمه کنید یا به هر نحوی آن را تغییر دهید، حتی فقط بخشی از آن را حذف کنید، مانند اسلش (/)، منجر به شکستگی و غیرقابل استفاده شدن لینک می شود.
+
+بهترین راه برای مدیریت لینک ها این است که آنها را مستقیماً از منبع کپی کنید، یا با کلیک بر روی آنها یا با استفاده از دکمه "کپی منبع" (Alt+C).
+
+![مثال link.png](./example-of-link.png)
+
+لینک ها همچنین در متن مبدأ به شکل برچسب ظاهر می شوند (یعنی <0> 0>). اگر ماوس را روی برچسب نگه دارید، ویرایشگر محتوای کامل آن را نشان می دهد - گاهی اوقات این برچسب ها نشان دهنده لینکها هستند.
+
+بسیار مهم است که لینک ها را از منبع کپی کنید و ترتیب آنها را تغییر ندهید.
+
+اگر ترتیب تگ ها تغییر کند، لینکی که آنها نشان می دهند شکسته می شود.
+
+![نمونه ای از لینکهای داخل tags.png](./example-of-links-inside-tags.png)
+
+**برچسب ها و متغیرها**
+
+متن منبع حاوی انواع مختلفی از تگ ها است که همیشه باید از منبع کپی شوند و هرگز تغییر نکنند. مانند موارد بالا، ترتیب این برچسب ها در ترجمه نیز باید مانند منبع باقی بماند.
+
+برچسب ها همیشه حاوی یک تگ باز و بسته هستند. در بیشتر موارد، متن بین تگ های باز و بسته باید ترجمه شود.
+
+مثال: ``غیرمتمرکز``
+
+`` - _برچسب باز که متن را پررنگ می کند_
+
+غیرمتمرکز - _متن قابل ترجمه_
+
+`` - _بستن برچسب_
+
+![مثالی از tags.png 'بولد'](./example-of-strong-tags.png)
+
+تکههای کد باید کمی متفاوت از برچسبهای دیگر باشند، زیرا حاوی کدهایی هستند که نباید ترجمه شوند.
+
+مثال: ``نانس`
`
+
+`` - _برچسب باز، که حاوی یک قطعه کد است_
+
+نانس- _متن غیرقابل ترجمه_
+
+`
` - _بستن برچسب_
+
+![مثال کد snippets.png](./example-of-code-snippets.png)
+
+متن منبع همچنین حاوی برچسب های کوتاه شده است که فقط حاوی اعداد هستند، به این معنی که عملکرد آنها بلافاصله مشخص نمی شود. میتوانید ماوس را روی این برچسبها نگه دارید تا ببینید دقیقاً کدام عملکرد را انجام میدهند.
+
+در مثال زیر، میتوانید آیتم های نگه داشتن ماوس را ببینید <0> برچسب نشان می دهد که نشان دهنده `` است و حاوی یک قطعه کد است، بنابراین محتوای داخل این برچسب ها نباید ترجمه شود.
+
+![نمونه ای از تگهای مبهم.png](./example-of-ambiguous-tags.png)
+
+## فرمها/اختصارات کوتاه یا کامل {#short-vs-full-forms}
+
+اختصارات زیادی در وب سایت استفاده می شود، به عنوان مثال. dapps و NFT و DAOو DeFi و غیره این اختصارات معمولاً در زبان انگلیسی استفاده می شوند و اکثر بازدیدکنندگان وب سایت با آنها آشنا هستند.
+
+از آنجایی که آنها معمولاً ترجمههای ثابتی به زبانهای دیگر ندارند، بهترین راه برای نزدیک شدن به این عبارات و اصطلاحات مشابه، ارائه یک ترجمه تشریحی از فرم کامل، و اضافه کردن مخفف انگلیسی در پرانتز است.
+
+این اختصارات را ترجمه نکنید، زیرا اکثر مردم با آنها آشنا نیستند و نسخه های بومی سازی شده برای اکثر بازدیدکنندگان منطقی نیست.
+
+نمونه ای از نحوه ترجمه dapps:
+
+- برنامه های غیرمتمرکز (dapps) → _فرم کامل ترجمه شده (مخفف انگلیسی در پرانتز)_
+
+## واژگانی بدون معادل های معین {#terms-without-established-translations}
+
+ممکن است برخی از اصطلاحات به زبان های دیگر ترجمه نشده باشند و به طور گسترده با اصطلاح اصلی انگلیسی شناخته می شوند. چنین اصطلاحاتی عمدتاً شامل مفاهیم جدیدتری مانند اثبات کار، اثبات سهام، بیکن چین، سهامگذاری و غیره هستند.
+
+در حالی که ترجمه این اصطلاحات می تواند غیرطبیعی به نظر برسد، از آنجایی که نسخه انگلیسی معمولاً در زبان های دیگر نیز استفاده می شود، توصیه می شود که آنها ترجمه شوند.
+
+هنگام ترجمه آنها، خلاقیت به خرج دهید، از ترجمه های تشریحی استفاده کنید یا به سادگی آنها را به معنای واقعی کلمه ترجمه کنید.
+
+**دلیل اینکه بیشتر اصطلاحات باید به جای ترک برخی به انگلیسی ترجمه شوند، این واقعیت است که این اصطلاحات جدید در آینده گستردهتر خواهند شد، زیرا افراد بیشتری استفاده از اتریوم و فناوری های مرتبط را شروع می کنند. اگر میخواهیم افراد بیشتری را از سراسر جهان به این فضا بفرستیم، باید اصطلاحات قابل فهمی را به هرچه بیشتر زبانهای ممکن ارائه کنیم، حتی اگر نیاز داشته باشیم خودمان آن را ایجاد کنیم.**
+
+## دکمهها و & CTAها {#buttons-and-ctas}
+
+وب سایت حاوی دکمه های متعددی است که باید متفاوت از سایر مطالب ترجمه شوند.
+
+متن دکمه را می توان با مشاهده اسکرین شات های زمینه، که با بیشتر رشته ها متصل است، یا با بررسی زمینه در ویرایشگر، که شامل عبارت "دکمه" است، شناسایی کرد.
+
+ترجمههای دکمهها باید تا حد امکان کوتاه باشند تا از عدم تطابق قالببندی جلوگیری شود. علاوه بر این، ترجمه دکمه باید ضروری باشد، یعنی یک دستور یا درخواست ارائه کنید.
+
+![چگونه یک button.png را پیدا کنیم](./how-to-find-a-button.png)
+
+## ترجمه برای عموم مردم جهان {#translating-for-inclusivity}
+
+بازدیدکنندگان Ethereum.org از سرتاسر جهان و از زمینه های علمی مختلف می آیند. بنابراین، زبان وبسایت باید خنثی و پذیرای همه باشد و نه انحصاری.
+
+یکی از جنبه های مهم این موضوع بی طرفی جنسیتی است. این را می توان با استفاده از فرم رسمی خطاب و پرهیز از هرگونه کلمه جنسیت خاص در ترجمه ها به راحتی به دست آورد.
+
+شکل دیگری از فراگیری، تلاش برای ترجمه برای مخاطبان جهانی است، نه خاص کشور، نژاد یا منطقه.
+
+در نهایت، زبان باید برای همه مخاطبان و سنین مناسب باشد.
+
+## ترجمههای خاص زبان {#language-specific-translations}
+
+هنگام ترجمه، مهم است که قوانین گرامری، قراردادها و قالببندی استفاده شده در زبان خود را به جای کپی کردن از منبع رعایت کنید. متن مبدأ از قوانین و قراردادهای دستور زبان انگلیسی پیروی می کند که برای بسیاری از زبان های دیگر قابل اجرا نیست.
+
+شما باید از قوانین زبان خود آگاه باشید و بر این اساس ترجمه کنید. اگر به کمک نیاز دارید، با ما تماس بگیرید و ما به شما کمک می کنیم تا منابعی در مورد نحوه استفاده از این عناصر در زبان خود پیدا کنید.
+
+چند نمونه از مواردی که باید به طور خاص به آن توجه داشت:
+
+### نشانه گذاری، قالب بندی {#punctuation-and-formatting}
+
+**حروف بزرگ**
+
+- تفاوت های زیادی در حروف بزرگ در زبان های مختلف وجود دارد.
+- در زبان انگلیسی رایج است که همه کلمات را در عناوین و نام ها، ماه ها و روزها، نام زبان ها، تعطیلات و غیره با حروف بزرگ بنویسند. در بسیاری از زبان های دیگر، این از نظر گرامری نادرست است، زیرا آنها قوانین حروف بزرگ متفاوتی دارند.
+- برخی از زبان ها نیز قوانینی در مورد بزرگ کردن ضمایر شخصی، اسم ها و صفت های خاص دارند که در انگلیسی حروف بزرگ نیستند.
+
+**فاصله گذاری**
+
+- قوانین املایی، استفاده از فاصله ها را برای هر زبان تعریف می کنند. از آنجایی که فاصله ها در همه جا استفاده می شوند، این قوانین جزو برخی از متمایزترینها هستند، و فاصلهها از برخی از عناصری هستند که اشتباه ترجمه شده اند.
+- برخی از تفاوت های رایج در فاصله بین انگلیسی و سایر زبان ها:
+ - فاصله قبل از واحدهای اندازه گیری و ارزها (به عنوان مثال USD، EUR، KB، MB)
+ - فاصله قبل از علائم درجه (به عنوان مثال °C و ℉)
+ - فاصله قبل از برخی از علائم نگارشی، به ویژه بیضی (…)
+ - فاصله قبل و بعد از اسلش (/)
+
+**لیستها**
+
+- هر زبانی مجموعه ای متنوع و پیچیده از قوانین برای نوشتن لیست ها دارد. اینها می توانند تفاوت قابل توجهی با انگلیسی داشته باشند.
+- در برخی از زبان ها، اولین کلمه هر خط جدید باید با حروف بزرگ باشد، در حالی که در برخی دیگر، خطوط جدید باید با حروف کوچک شروع شوند. بسیاری از زبان ها نیز بسته به طول هر خط، قوانین متفاوتی در مورد حروف بزرگ در لیست ها دارند.
+- همین امر در مورد علامت گذاری آیتم های خطی نیز صدق می کند. نقطه نگاری پایانی در لیست ها بسته به زبان می تواند نقطه (**.**)، کاما (**،**) یا نقطه ویرگول (**;**) باشد.
+
+**علامت نقل قول**
+
+- زبان ها از علامت های نقل قول مختلف استفاده می کنند. کپی کردن ساده نقل قول انگلیسی از منبع اغلب نادرست است.
+- برخی از رایج ترین انواع علامت نقل قول عبارتند از:
+ - „example text“
+ - ‚example text’
+ - »example text«
+ - “example text”
+ - ‘example text’
+ - «example text»
+
+**خط فاصله و خط تیره**
+
+- در زبان انگلیسی، خط فاصله (-) برای پیوستن کلمات یا قسمت های مختلف یک کلمه استفاده می شود، در حالی که خط تیره (–) برای نشان دادن محدوده یا مکث استفاده می شود.
+- بسیاری از زبان ها قوانین مختلفی برای استفاده از خط فاصله و خط تیره دارند که باید رعایت شود.
+
+### قالبها {#formats}
+
+**اعداد**
+
+- تفاوت اصلی در نوشتن اعداد در زبان های مختلف جداکننده ای است که برای اعشار و هزاران استفاده می شود. برای هزارگان، این می تواند نقطه، کاما یا فاصله باشد. به طور مشابه، برخی از زبان ها از نقطه اعشار استفاده می کنند، در حالی که برخی دیگر از کاما اعشاری استفاده می کنند.
+ - چند نمونه از اعداد بزرگ:
+ - انگلیسی – **1,000.50**
+ - اسپانیایی – **1.000,50**
+ - فرانسه – **1 000,50**
+- یکی دیگر از نکات مهم در هنگام ترجمه اعداد، علامت درصد است. می توان آن را به روش های مختلفی نوشت: **100%**، **100 %** یا **%100**.
+- در نهایت، اعداد منفی را می توان بسته به زبان به صورت متفاوتی نمایش داد: -100، 100-، (100) یا [100].
+
+**تاریخ**
+
+- هنگام ترجمه تاریخ، یکسری ملاحظات و تفاوت ها بر اساس زبان وجود دارد. اینها شامل قالب تاریخ، جداکننده، حروف بزرگ و صفرهای ابتدایی است. همچنین بین تاریخ های کامل و عددی تفاوت هایی وجود دارد.
+ - چند نمونه از فرمت های مختلف تاریخ:
+ - انگلیسی بریتانیا (dd/mm/yyyy) – 1st January, 2022
+ - انگلیسی امریکا (mm/dd/yyyy) – January 1st, 2022
+ - چینی (yyyy-mm-dd) – 2022 年 1 月 1 日
+ - فرانسه (dd/mm/yyyy) – 1er janvier 2022
+ - ایتالیایی (dd/mm/yyyy) – 1º gennaio 2022
+ - آلمانی (dd/mm/yyyy) – 1. Januar 2022
+
+**ارزها**
+
+- به دلیل فرمت ها، قراردادها و تبدیل های مختلف، ترجمه ارزها می تواند چالش برانگیز باشد. به عنوان یک قاعده کلی، لطفاً ارزها را همان منبع نگه دارید. میتوانید ارز محلی و تبدیل خود را در پرانتز اضافه کنید تا خواننده به نفع خود باشد.
+- تفاوت های اصلی در نوشتن ارزها در زبان های مختلف شامل قرار دادن نمادها، کاماهای اعشاری در مقابل اعشار، فاصله و اختصارات در مقابل نمادها است.
+ - محل قرارگیری سمبلها: 100$ یا $100
+ - ویرگول به عنوان اعشار یا نقطه به عنوان اعشار: مثلاً 100,50$ یا 100.50$
+ - فاصله گذاری: مثلاً 100$ یا 100 $
+ - مخفف یا سمبل: مثلاً 100 $ یا 100 USD
+
+**واحدهای اندازهگیری**
+
+- به عنوان یک قاعده کلی، لطفاً واحدهای اندازه گیری را مطابق منبع نگه دارید. اگر کشور شما از سیستم دیگری استفاده می کند، می توانید تبدیل آن را در پرانتز قرار دهید.
+- جدای از بومی سازی واحدهای اندازه گیری، توجه به تفاوت در نحوه رویکرد زبان ها به این واحدها نیز مهم است. تفاوت اصلی فاصله بین عدد و واحد است که بر اساس زبان می تواند متفاوت باشد. نمونه هایی از این شامل 100kB در مقابل 100 kB یا 50ºF در مقابل 50 ºF هستند.
+
+## نتيجه گيری {#conclusion}
+
+ترجمه ethereum.org فرصتی عالی برای آشنایی با جنبه های مختلف اتریوم است.
+
+هنگام ترجمه سعی کنید عجله نکنید. راحت باشید و لذت ببرید!
+
+از اینکه با برنامه ترجمه مشارکت داشتید و به ما کمک میکنید تا وبسایت را برای مخاطبان بیشتری در دسترس قرار دهید، سپاسگزاریم. جامعه اتریوم یک جامعه جهانی است و ما خوشحالیم که شما بخشی از آن هستید!
diff --git a/public/content/translations/fa/decentralized-identity/index.md b/public/content/translations/fa/decentralized-identity/index.md
index 8517d9b2885..5c9214d1e3d 100644
--- a/public/content/translations/fa/decentralized-identity/index.md
+++ b/public/content/translations/fa/decentralized-identity/index.md
@@ -13,7 +13,7 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
هویت امروزه تقریباً زیربنای همه جنبه های زندگی شماست. استفاده از خدمات آنلاین، افتتاح حساب بانکی، رای دادن در انتخابات، خرید ملک، تضمین شغل - همه این موارد مستلزم اثبات هویت شماست.
-با این حال، سیستمهای مدیریت هویت سنتی مدتهاست که به واسطههای متمرکزی که شناسهها و [تأییدات](#what-are-attestations) شما را صادر، نگهداری و کنترل میکنند، متکی بودهاند. این بدان معنی است که شما نمی توانید اطلاعات مربوط به هویت خود را کنترل کنید یا تصمیم بگیرید که چه کسی به اطلاعات هویتی شخصی (PII) و میزان دسترسی این افراد دسترسی دارد.
+با این حال، سیستمهای مدیریت هویت سنتی مدتها به واسطههای متمرکز که شناسهها و [تأییدات](/glossary/#attestation) شما را صادر، نگهداری و کنترل میکنند، متکی بودهاند. این بدان معنی است که شما نمی توانید اطلاعات مربوط به هویت خود را کنترل کنید یا تصمیم بگیرید که چه کسی به اطلاعات هویتی شخصی (PII) و میزان دسترسی این افراد دسترسی دارد.
برای حل این مشکلات، سیستمهای هویت غیرمتمرکز ساخته شده بر روی بلاک چینهای عمومی مانند اتریوم را داریم. هویت غیرمتمرکز به افراد اجازه می دهد تا اطلاعات مربوط به هویت خود را مدیریت کنند. با راهحلهای هویت غیرمتمرکز، _شما_ میتوانید شناسه ایجاد کنید و بدون تکیه بر مقامات مرکزی، مانند ارائهدهندگان خدمات یا دولتها، گواهینامههای خود را ادعا و نگهداری کنید.
@@ -21,9 +21,11 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
هویت به معنای احساس یک فرد از خود است که با ویژگی های منحصر به فرد تعریف می شود. هویت به _فرد_ بودن اشاره دارد، یعنی یک موجود انسانی متمایز. هویت همچنین می تواند به سایر نهادهای غیرانسانی مانند یک سازمان یا مقام اشاره کند.
+
+
## شناسه ها چیست? {#what-are-identifiers}
-شناسه قطعه ای از اطلاعات است که به عنوان نشانگر هویت یا هویت های خاص عمل می کند. شناسه های رایج عبارتند از:
+شناسه قطعه ای اطلاعات است که به عنوان نشانگر هویت یا هویت های خاص عمل می کند. شناسه های رایج عبارتند از:
- نام
- شماره تامین اجتماعی/شماره شناسه مالیاتی
@@ -31,7 +33,47 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
- تاریخ و محل تولد
- مدارک شناسایی دیجیتال، به عنوان مثال، آدرس های ایمیل، نام های کاربری، آواتارها
-این نمونه های سنتی از شناسه ها توسط نهادهای مرکزی صادر، نگهداری و کنترل می شوند. برای تغییر نام خود یا از یک پلتفرم رسانه اجتماعی برای تغییر دسته خود به اجازه دولت خود نیاز دارید.
+این نمونه های سنتی شناسه ها توسط نهادهای مرکزی صادر، نگهداری و کنترل می شوند. برای تغییر نام تان، به اجازه دولت یا اجازه یک پلتفرم رسانه اجتماعی برای تغییر نام کاربری تان نیاز دارید.
+
+## مزایای هویت غیرمتمرکز {#benefits-of-decentralized-identity}
+
+1. هویت غیرمتمرکز کنترل فردی اطلاعات شناسایی را افزایش می دهد. شناسه ها و تصدیق های غیرمتمرکز را می توان بدون اتکا به مقامات متمرکز و خدمات شخص ثالث تأیید کرد.
+
+2. راهحلهای هویت غیرمتمرکز، روشی بدون نیاز به اعتماد، بدون درز و حفاظت از حریم خصوصی را برای تأیید و مدیریت هویت کاربر تسهیل میکند.
+
+3. هویت غیرمتمرکز از فناوری بلاک چین استفاده میکند که اعتماد بین طرفهای مختلف ایجاد میکند و تضمینهای رمزنگاری را برای اثبات اعتبار تصدیقها ارائه میکند.
+
+4. هویت غیرمتمرکز داده های هویت را قابل حمل می کند. کاربران گواهیها و شناسهها را در کیف پول موبایل ذخیره میکنند و میتوانند با هر طرفی که انتخاب میکنند به اشتراک بگذارند. شناسه ها و تصدیقهای غیرمتمرکز در پایگاه داده سازمان صادر کننده قفل نمی شوند.
+
+5. هویت غیرمتمرکز باید با فناوریهای نوظهور [دانش صفر](/glossary/#zk-proof) به خوبی کار کند که افراد را قادر خواهند ساخت ثابت کنند مالک یک چیز هستند یا یک کار را انجام داده اند، بدون افشای ماهیت آن. این می تواند راهی قدرتمند برای ترکیب اعتماد و حریم خصوصی برای برنامه هایی مانند رای دادن باشد.
+
+6. هویت غیرمتمرکز مکانیزمهای [ضد سیبیل](/glossary/#anti-sybil) را قادر میسازد زمانی که یک نفر، برای بازی کردن یا ارسال هرزنامه به یک سیستم، تظاهر میکند چند نفر است، تشخیص دهد.
+
+## موارد استفاده هویت غیرمتمرکز {#decentralized-identity-use-cases}
+
+هویت غیرمتمرکز موارد استفاده بالقوه زیادی دارد:
+
+### 1. لاگین های همگانی {#universal-dapp-logins}
+
+هویت غیرمتمرکز میتواند به جایگزینی ورودهای مبتنی بر رمز عبور با احراز هویت غیرمتمرکز کمک کند. ارائه دهندگان خدمات می توانند تصدیق هایی را برای کاربران صادر کنند که می توانند در کیف پول اتریوم ذخیره شوند. یک تایید نمونه، می تواند یک [NFT](/glossary/#nft) باشد که به دارنده اجازه دسترسی به یک انجمن آنلاین را می دهد.
+
+سپس یک تابع [Sign-In with Ethereum](https://login.xyz/) سرورها را قادر میسازد تا حساب اتریوم کاربر را تأیید کنند و گواهی لازم را از آدرس حساب خود دریافت کنند. این بدان معناست که کاربران می توانند بدون نیاز به حفظ رمزهای عبور طولانی به پلتفرم ها و وب سایت ها دسترسی داشته باشند و این تجربه آنلاین را برای کاربران بهبود می بخشد.
+
+### 2. احراز هویت KYC {#kyc-authentication}
+
+استفاده از بسیاری از خدمات آنلاین، افراد را ملزم به ارائه تصدیق ها و اعتبارنامه هایی مانند گواهینامه رانندگی یا پاسپورت ملی می کند. اما این رویکرد مشکل ساز است زیرا اطلاعات خصوصی کاربر می تواند به خطر بیفتد و ارائه دهندگان خدمات نمی توانند صحت تصدیق را تأیید کنند.
+
+هویت غیرمتمرکز به شرکتها این امکان را میدهد که از فرآیندهای معمول [Know-Your-Customer (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) صرفنظر کنند و هویت کاربر را از طریق اعتبارنامههای قابل تأیید احراز هویت کنند. این امر هزینه مدیریت هویت را کاهش می دهد و از استفاده از اسناد جعلی جلوگیری می کند.
+
+### 3. رای گیری و کامیونیتیهای آنلاین {#voting-and-online-communities}
+
+رای گیری آنلاین و سوشال مدیا دو کاربرد جدید برای هویت غیرمتمرکز هستند. طرحهای رایگیری آنلاین مستعد دستکاری هستند، بهویژه اگر بازیگران بدخواه برای رای دادن هویتهای جعلی ایجاد کنند. درخواست از افراد برای ارائه تصدیق های آنچین می تواند یکپارچگی فرآیندهای رای گیری آنلاین را بهبود بخشد.
+
+هویت غیرمتمرکز می تواند به ایجاد کامیونیتیهای آنلاینی که عاری از حساب های جعلی هستند کمک کند. به عنوان مثال، هر کاربر ممکن است مجبور باشد هویت خود را با استفاده از یک سیستم هویت آنچین، مانند سرویس نام اتریوم، احراز هویت کند، که احتمال وجود ربات ها را کاهش می دهد.
+
+### 4. محافظت ضد سیبیل {#sybil-protection}
+
+برنامههای اعطای کمک هزینه که از [رایگیری درجه دوم](/glossary/#quadratic-voting) استفاده میکنند در برابر [حملات سیبیل](/glossary/#sybil-attack) آسیبپذیر هستند، زیرا ارزش کمک هزینه زمانی افزایش مییابد که افراد بیشتری به آن رأی میدهند و کاربران را تشویق میکند تا مشارکتهای خود را در بسیاری از هویتها تقسیم کنند. هویتهای غیرمتمرکز با بالا بردن بار روی دوش هر شرکتکننده برای اثبات اینکه واقعاً انسان هستند، به جلوگیری از این امر کمک میکند، هرچند اغلب بدون نیاز به افشای اطلاعات خصوصی خاص.
## گواهینامه ها چیست? {#what-are-attestations}
@@ -43,17 +85,17 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
شناسههای سنتی مانند نام قانونی یا آدرس ایمیل شما متکی به اشخاص ثالث - دولتها و ارائهدهندگان ایمیل هستند. شناسه های غیرمتمرکز (DID) متفاوت هستند - آنها توسط هیچ نهاد مرکزی صادر، مدیریت یا کنترل نمی شوند.
-شناسه های غیرمتمرکز توسط افراد صادر، نگهداری و کنترل می شوند. یک [حساب اتریوم](/developers/docs/accounts/) نمونهای از یک شناسه غیرمتمرکز است. شما می توانید هر تعداد حساب که می خواهید بدون اجازه کسی و بدون نیاز به ذخیره آنها در یک رجیستری مرکزی ایجاد کنید.
+شناسه های غیرمتمرکز توسط افراد صادر، نگهداری و کنترل می شوند. یک [حساب اتریوم](/glossary/#account) نمونهای از یک شناسه غیرمتمرکز است. شما می توانید هر تعداد حساب که می خواهید بدون اجازه کسی و بدون نیاز به ذخیره آنها در یک رجیستری مرکزی ایجاد کنید.
-شناسه های غیرمتمرکز در دفتر کل توزیع شده (بلاک چین) یا شبکه های همتا به همتا ذخیره می شوند. این باعث میشود DIDها [در سطح جهانی منحصربهفرد، قابل حل با در دسترس بودن بالا، و از نظر رمزنگاری قابل تأیید](https://w3c-ccg.github.io/did-primer/) باشند. یک شناسه غیرمتمرکز میتواند با نهادهای مختلف، از جمله افراد، سازمانها یا مؤسسات دولتی مرتبط باشد.
+شناسههای غیرمتمرکز در دفاتر کل توزیع شده ([بلاکچینها](/glossary/#blockchain)) یا [شبکههای همتا به همتا](/glossary/#peer-to-peer-network) ذخیره میشوند. این باعث میشود DIDها [در سطح جهانی منحصربهفرد، قابل حل با در دسترس بودن بالا، و از نظر رمزنگاری قابل تأیید](https://w3c-ccg.github.io/did-primer/) باشند. یک شناسه غیرمتمرکز میتواند با نهادهای مختلف، از جمله افراد، سازمانها یا مؤسسات دولتی مرتبط باشد.
## چه چیزی شناسه های غیرمتمرکز را ممکن می کند? {#what-makes-decentralized-identifiers-possible}
-### 1. زیرساخت کلید عمومی (PKI) {#public-key-cryptography}
+### 1. رمزنگاری کلید عمومی {#public-key-cryptography}
-زیرساخت کلید عمومی (PKI) یک اقدام امنیتی اطلاعاتی است که یک [کلید عمومی](/glossary/#public-key) و [ ایجاد میکند. کلید خصوصی](/glossary/#private-key) برای یک موجودیت. رمزنگاری کلید عمومی در شبکه های بلاک چین برای احراز هویت کاربران و اثبات مالکیت دارایی های دیجیتال استفاده می شود.
+رمزنگاری کلید عمومی یک اقدام امنیتی اطلاعاتی است که یک [کلید عمومی](/glossary/#public-key) و [کلید خصوصی](/glossary/#private-key) را برای یک نهاد ایجاد میکند. [رمزنگاری](/glossary/#cryptography) کلید عمومی در شبکههای بلاکچین برای احراز هویت کاربران و اثبات مالکیت داراییهای دیجیتال استفاده میشود.
-برخی از شناسه های غیرمتمرکز، مانند حساب اتریوم، دارای کلیدهای عمومی و خصوصی هستند. کلید عمومی کنترل کننده حساب را شناسایی می کند، در حالی که کلیدهای خصوصی می توانند پیام های این حساب را امضا و رمزگشایی کنند. PKI با استفاده از [امضاهای رمزنگاری](https://andersbrownworth.com/blockchain/public-private-keys/) برای تأیید همه ادعاها، شواهد مورد نیاز برای احراز هویت و جلوگیری از جعل هویت و استفاده از هویتهای جعلی را ارائه میکند.
+برخی از شناسه های غیرمتمرکز، مانند حساب اتریوم، دارای کلیدهای عمومی و خصوصی هستند. کلید عمومی کنترل کننده حساب را شناسایی می کند، در حالی که کلیدهای خصوصی می توانند پیام های این حساب را امضا و رمزگشایی کنند. رمزنگاری کلید عمومی با استفاده از [امضای رمزنگاری](https://andersbrownworth.com/blockchain/public-private-keys/) برای تأیید همه مطالبات، شواهد مورد نیاز برای احراز هویت، جلوگیری از جعل هویت، و استفاده از هویتهای جعلی را فراهم میسازد.
### 2. داده های غیرمتمرکز {#decentralized-datastores}
@@ -97,7 +139,7 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
### تصدیقهای آنچین {#onchain-attestations}
-تصدیقهای آنچین در [قراردادهای هوشمند](/developers/docs/smart-contracts/) در بلاکچین اتریوم برگزار میشود. قرارداد هوشمند (که به عنوان یک رجیستری عمل می کند) یک تصدیق را به یک شناسه غیرمتمرکز آنچین مربوطه (یک کلید عمومی) متصل می کند.
+تصدیقهای روی زنجیره در [قراردادهای هوشمند](/glossary/#smart-contract) در بلاکچین اتریوم نگهداری میشوند. قرارداد هوشمند (که به عنوان یک رجیستری عمل می کند) یک تصدیق را به یک شناسه غیرمتمرکز آنچین مربوطه (یک کلید عمومی) متصل می کند.
در اینجا یک مثال برای نشان دادن نحوه عملکرد تصدیقهای آنچین در عمل آورده شده است:
@@ -109,47 +151,7 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
### توکنهای Soulbound و هویت {#soulbound}
-[توکنهای Soulbound](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) (NFTهای غیرقابل انتقال) میتوانند برای جمعآوری اطلاعات منحصر به فرد برای یک کیف پول خاص استفاده شوند. این به طور مؤثر یک هویت آنچین منحصر به فرد ایجاد می کند که به یک آدرس اتریوم خاص متصل می شود که می تواند شامل توکن هایی باشد که دستاوردها را نشان می دهد (به عنوان مثال اتمام یک دوره آنلاین خاص یا گذراندن یک امتیاز آستانه در یک بازی) یا مشارکت کامیونیتی.
-
-## مزایای هویت غیرمتمرکز {#benefits-of-decentralized-identity}
-
-1. هویت غیرمتمرکز کنترل فردی اطلاعات شناسایی را افزایش می دهد. شناسه ها و تصدیق های غیرمتمرکز را می توان بدون اتکا به مقامات متمرکز و خدمات شخص ثالث تأیید کرد.
-
-2. راهحلهای هویت غیرمتمرکز، روشی بدون نیاز به اعتماد، بدون درز و حفاظت از حریم خصوصی را برای تأیید و مدیریت هویت کاربر تسهیل میکند.
-
-3. هویت غیرمتمرکز از فناوری بلاک چین استفاده میکند که اعتماد بین طرفهای مختلف ایجاد میکند و تضمینهای رمزنگاری را برای اثبات اعتبار تصدیقها ارائه میکند.
-
-4. هویت غیرمتمرکز داده های هویت را قابل حمل می کند. کاربران گواهیها و شناسهها را در کیف پول موبایل ذخیره میکنند و میتوانند با هر طرفی که انتخاب میکنند به اشتراک بگذارند. شناسه ها و تصدیقهای غیرمتمرکز در پایگاه داده سازمان صادر کننده قفل نمی شوند.
-
-5. هویت غیرمتمرکز باید با فناوریهای نوظهور دانش صفر به خوبی کار کند که افراد را قادر میسازد ثابت کنند که مالک چیزی یا انجام دهنده کاری بدون افشای آن چیز هستند. این می تواند راهی قدرتمند برای ترکیب اعتماد و حریم خصوصی برای برنامه هایی مانند رای دادن باشد.
-
-6. هویت غیرمتمرکز، مکانیسمهای ضد Sybil را قادر میسازد تا زمانی که یک انسان وانمود میکند چند انسان برای بازی کردن یا اسپم کردن برخی از سیستمها، شناسایی کند.
-
-## موارد استفاده هویت غیرمتمرکز {#decentralized-identity-use-cases}
-
-هویت غیرمتمرکز موارد استفاده بالقوه زیادی دارد:
-
-### 1. لاگین های همگانی {#universal-dapp-logins}
-
-هویت غیرمتمرکز میتواند به جایگزینی ورودهای مبتنی بر رمز عبور با [احراز هویت غیرمتمرکز](https://www.ibm.com/blogs/blockchain/2018/10/decentralized-identity-an-alternative-to-password-based-authentication/). ارائه دهندگان خدمات می توانند تصدیق هایی را برای کاربران صادر کنند که می توانند در کیف پول اتریوم ذخیره شوند. یک تصدیق بعنوان نمونه می تواند یک [NFT](/nft/) باشد که به دارنده اجازه دسترسی به یک انجمن آنلاین را می دهد.
-
-سپس یک تابع [Sign-In with Ethereum](https://login.xyz/) سرورها را قادر میسازد تا حساب اتریوم کاربر را تأیید کنند و گواهی لازم را از آدرس حساب خود دریافت کنند. این بدان معناست که کاربران می توانند بدون نیاز به حفظ رمزهای عبور طولانی به پلتفرم ها و وب سایت ها دسترسی داشته باشند و این تجربه آنلاین را برای کاربران بهبود می بخشد.
-
-### 2. احراز هویت KYC {#kyc-authentication}
-
-استفاده از بسیاری از خدمات آنلاین، افراد را ملزم به ارائه تصدیق ها و اعتبارنامه هایی مانند گواهینامه رانندگی یا پاسپورت ملی می کند. اما این رویکرد مشکل ساز است زیرا اطلاعات خصوصی کاربر می تواند به خطر بیفتد و ارائه دهندگان خدمات نمی توانند صحت تصدیق را تأیید کنند.
-
-هویت غیرمتمرکز به شرکتها این امکان را میدهد که از فرآیندهای معمول [Know-Your-Customer (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) صرفنظر کنند و هویت کاربر را از طریق اعتبارنامههای قابل تأیید احراز هویت کنند. این امر هزینه مدیریت هویت را کاهش می دهد و از استفاده از اسناد جعلی جلوگیری می کند.
-
-### 3. رای گیری و کامیونیتیهای آنلاین {#voting-and-online-communities}
-
-رای گیری آنلاین و سوشال مدیا دو کاربرد جدید برای هویت غیرمتمرکز هستند. طرحهای رایگیری آنلاین مستعد دستکاری هستند، بهویژه اگر بازیگران بدخواه برای رای دادن هویتهای جعلی ایجاد کنند. درخواست از افراد برای ارائه تصدیق های آنچین می تواند یکپارچگی فرآیندهای رای گیری آنلاین را بهبود بخشد.
-
-هویت غیرمتمرکز می تواند به ایجاد کامیونیتیهای آنلاینی که عاری از حساب های جعلی هستند کمک کند. به عنوان مثال، هر کاربر ممکن است مجبور باشد هویت خود را با استفاده از یک سیستم هویت آنچین، مانند سرویس نام اتریوم، احراز هویت کند، که احتمال وجود ربات ها را کاهش می دهد.
-
-### 4. محافظت ضد سیبیل {#sybil-protection}
-
-حملات Sybil به افراد فردی اشاره دارد که یک سیستم را فریب می دهند تا فکر کنند چندین نفر هستند تا نفوذ خود را افزایش دهند. [برنامه های کمک هزینه](https://gitcoin.co/grants/) که از [رأی درجه](https://www.radicalxchange.org/concepts/plural-voting/) استفاده می کنند در برابر این حملات Sybil آسیب پذیر هستند زیرا ارزش کمک هزینه زمانی افزایش می یابد که افراد بیشتری به آن رأی می دهند و کاربران را تشویق می کند تا مشارکت های خود را در بسیاری از هویت ها تقسیم کنند. هویتهای غیرمتمرکز با بالا بردن بار روی دوش هر شرکتکننده برای اثبات اینکه واقعاً انسان هستند، به جلوگیری از این امر کمک میکند، هرچند اغلب بدون نیاز به افشای اطلاعات خصوصی خاص.
+[توکنهای انحصاری](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([NFTهای غیرقابل انتقال](/glossary/#nft)) میتوانند برای جمعآوری اطلاعاتِ انحصاری یک کیفپول خاص استفاده شوند. این به طور مؤثر یک هویت آنچین منحصر به فرد ایجاد می کند که به یک آدرس اتریوم خاص متصل می شود که می تواند شامل توکن هایی باشد که دستاوردها را نشان می دهد (به عنوان مثال اتمام یک دوره آنلاین خاص یا گذراندن یک امتیاز آستانه در یک بازی) یا مشارکت کامیونیتی.
## از هویت غیرمتمرکز استفاده کنید {#use-decentralized-identity}
@@ -160,7 +162,8 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
- **[خدمات گواهی اتریوم (EAS)](https://attest.sh/)** - _یک دفتر کل/پروتکل غیرمتمرکز برای ایجاد گواهیهای زنجیرهای یا خارج از زنجیره درباره هر چیزی._
- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (یا PoH) یک سیستم تأیید هویت اجتماعی است که بر روی اتریوم ساخته شده است._
- **[BrightID](https://www.brightid.org/)** - _یک شبکه هویت اجتماعی غیرمتمرکز و منبع باز که به دنبال اصلاح تأیید هویت از طریق ایجاد و تجزیه و تحلیل یک نمودار اجتماعی است._
-- **[گذرنامه اثبات شخصیت](https://proofofpersonhood.com/)** - _یک جمع کننده هویت دیجیتال غیرمتمرکز._
+- **[walt.id](https://walt.id)** — _هویت و زیرساخت کیفپول غیرمتمرکز منبع باز که به توسعهدهندگان و سازمانها این امکان را میدهد تا از هویت مستقل و NFT/SBT استفاده کنند._
+- **[Veramo](https://veramo.io/)** - _یک چارچوب جاوا اسکریپت است که استفاده از داده های قابل تأیید از لحاظ رمزنگاری را در برنامههای خود برای هر کس آسان میسازد._
## بیشتر بخوانید {#further-reading}
@@ -170,6 +173,7 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
- [اتریوم ERC725 چیست؟ مدیریت هویت خودمختار در بلاک چین](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _سام تاون_
- [چگونه بلاک چین می تواند مشکل هویت دیجیتال را حل کند](https://time.com/6142810/proof-of-humanity/) — _اندرو آر. چاو_
- [هویت غیرمتمرکز چیست و چرا باید به آن اهمیت دهید؟](https://web3.hashnode.com/what-is-decentralized-identity) _آووسیکا_
+- [مقدمهای بر هویت غیرمتمرکز](https://walt.id/white-paper/digital-identity) - به قلم _دومینیک برون_
### ویدیوها {#videos}
@@ -177,9 +181,11 @@ summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزا
- [ورود با اتریوم و هویت غیرمتمرکز با Ceramic، IDX، React و 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _آموزش YouTube در مورد ایجاد یک سیستم مدیریت هویت برای ایجاد، خواندن و به روز رسانی نمایه کاربر با استفاده از کیف پول اتریوم توسط نادر دبیت_
- [BrightID - هویت غیرمتمرکز در اتریوم](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _قسمت پادکست بدون بانک در مورد BrightID، یک راه حل هویت غیرمتمرکز برای اتریوم_
- [اینترنت خارج از زنجیره: هویت غیرمتمرکز & اعتبار قابل تأیید](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — ارائه EthDenver 2022 توسط Evin McMullen
+- [تشریح اعتبارنامه های قابلاحراز](https://www.youtube.com/watch?v=ce1IdSr-Kig) - ویدیو توضیحی یوتیوب همراه با نسخه آزمایشی از تامینو باومن
### جوامع {#communities}
- [اتحاد ERC-725 در GitHub](https://github.com/erc725alliance) — _حامی استاندارد ERC725 برای مدیریت هویت در بلاک چین اتریوم_
-- [سرور SpruceID Discord](https://discord.com/invite/Sf9tSFzrnt) — *انجمن برای علاقه مندان و توسعه دهندگانی که روی ورود به سیستم با اتریوم*کار می کنند
+- [سرور SpruceID Discord](https://discord.com/invite/Sf9tSFzrnt) — _انجمن برای علاقه مندان و توسعه دهندگانی که روی ورود به سیستم با اتریوم_کار می کنند
- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _جامعه ای از توسعه دهندگان که در ساخت چارچوبی برای داده های قابل تأیید برای برنامه ها مشارکت دارند_
+- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _جامعهای از توسعهدهندگان و سازندگان که بر روی موارد استفاده از هویت غیرمتمرکز در صنایع مختلف کار میکنند_
diff --git a/public/content/translations/fa/defi/index.md b/public/content/translations/fa/defi/index.md
index ff483a6c1b5..d3e480e6b52 100644
--- a/public/content/translations/fa/defi/index.md
+++ b/public/content/translations/fa/defi/index.md
@@ -55,7 +55,7 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
از خیلی جهات بیتکوین اولین برنامهی DeFi محسوب میشود. بیتکوین به شما اجازه میدهد که ارزش را واقعاً در اختیار داشته باشید و کنترل کنید و برای هر کسی در هر کجای جهان بفرستید. بیتکوین این کار را با فراهم کردن راهی برای توافق بر یک دفترکل حاوی حسابهای کاربری بدون نیاز به اعتماد به یک میانجی سوم برای تعداد زیادی آدم که به یکدیگر اعتماد ندارند انجام میدهد. بیتکوین برای همه آزاد است و هیچکس نمیتواند برای آن قانون وضع کند. قوانین بیتکوین، مثل کمیابی و باز بودنش، در فناوری آن نهادینه شدهاند. مانند امور مالی سنتی نیست که دولتها بتوانند پول چاپ کنند که ارزش پساندازهای شما کم شود و شرکتها بتوانند بازارها را ببندند.
-اتریوم بر همین اساس ساخته شدهاست. همانند بیتکوین، قوانین برای شما و هر کسی که به آن دسترسی دارد تغییر نمیکند. اما با استفاده از [قراردادهای هوشمند](/glossary#smart-contract) این پول دیجیتال قابلبرنامهنویسی شدهاست تا بتوانید کارهایی فراتر از نگهداری و انتقال ارزش انجام دهید.
+اتریوم بر همین اساس ساخته شدهاست. همانند بیتکوین، قوانین برای شما و هر کسی که به آن دسترسی دارد تغییر نمیکند. ولی همچنین این پول دیجیتال را با استفاده از [قراردادهای هوشمند](/glossary/#smart-contract) قابلبرنامهنویسی نیز می کند تا بتوانید کارهایی فراتر از نگهداری و انتقال ارزش انجام دهید.
@@ -90,7 +90,7 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
### ارسال سریع پول به اقصی نقاط جهان {#send-money}
-اتریوم به عنوان یک زنجیرهی بلوکی، برای ارسال تراکنشها به شکلی ایمن و در تمام جهان ساخته شده است. همانند بیتکوین، فرستادن پول به تمام نقاط جهان از طریق اتریوم بهسادگی فرستادن یک ایمیل انجام میشود. تنها کافی است که [نام ENS](/nft/#nft-domains) دریافتکنندهی خود ( مثل bob.eth) یا آدرس حسابشان را در کیفپول خود وارد کنید و پرداخت شما ظرف چند دقیقه (بهطور معمول) به دست آنها میرسد. برای دریافت و پرداخت پول شما نیاز به یک [کیف پول](/wallets/) دارید.
+اتریوم به عنوان یک زنجیرهی بلوکی، برای ارسال تراکنشها به شکلی ایمن و در تمام جهان ساخته شده است. همانند بیتکوین، فرستادن پول به تمام نقاط جهان از طریق اتریوم بهسادگی فرستادن یک ایمیل انجام میشود. تنها کافی است که [نام ENS متعلق](/glossary/#ens) به دریافتکننده (مثل bob.eth) یا آدرس حساب او را در کیفپول خود وارد کنید و پول شما ظرف چند دقیقه (بهطور معمول) به دست او خواهد رسید. برای دریافت و پرداخت پول شما نیاز به یک [کیف پول](/wallets/) دارید.
مشاهدهی برنامههای غیرمتمرکز پرداخت
@@ -100,7 +100,7 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
شما همچنین میتوانید پول را در اتریوم به جریان بیاندازید. با این ویژگی میتوانید حقوق ماهانهی هر فرد را در لحظه واریز کنید تا هر زمان که لازمش داشتند به پولشان دسترسی داشته باشند. یا چیزی مثل قفسهی نگهداری وسایل یا اسکوتر برقی را در لحظه اجاره کنید.
-و اگر نمیخواهید که [ETH](/eth/) را به دلیل بالا بودن نوسانات قیمتش ارسال کنید یا به جریان بیاندازید، ارزهای جایگزینی روی اتریوم وجود دارند: پایدارز.
+و اگر نمیخواهید [اتر](/glossary/#ether) را ارسال یا استریم کنید چون ارزش آن ممکن است تغییر کند، ارزهای جایگزینی نیز در اتریوم وجود دارند: [استیبلکوینها](/glossary/#stablecoin).
@@ -133,7 +133,7 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
امروزه قرض گرفتن و قرض دادن پول بهکلی به افراد دخیل در آن مربوط است. بانکها پیش از وام دادن به شما مطمئن میشوند که آیا وام را بازپرداخت میکنید یا خیر.
-قرض دادن غیرمتمرکز به احراز هویت هیچیک از طرفین نیاز ندارد. در عوض، قرضگیرنده باید وثیقهای بگذارد که قرضدهنده در صورت عدم بازپرداخت بهصورت خودکار دریافتش خواهد کرد. برخی قرضدهندگان حتی NFTها را به عنوان وثیقه میپذیرند. NFT سندی برای یک دارایی یکتا است؛ مثلاً یک نقاشی. [اطلاعات بیشتر دربارهی NFT](/nft/)
+قرض دادن غیرمتمرکز به احراز هویت هیچیک از طرفین نیاز ندارد. در عوض، قرضگیرنده باید وثیقهای بگذارد که قرضدهنده در صورت عدم بازپرداخت بهصورت خودکار دریافتش خواهد کرد. برخی قرضدهندگان حتی [NFTها](/glossary/#nft) را به عنوان وثیقه میپذیرند. NFT سندی برای یک دارایی یکتا است؛ مثلاً یک نقاشی. [اطلاعات بیشتر دربارهی NFT](/nft/)
این ویژگی به شما امکان میدهد که بدون چک اعتباری یا دادن اطلاعات خصوصی، پول قرض بگیرید.
@@ -168,7 +168,9 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
برای این که بتوانید مثال پیشگفته را در نظام مالی سنتی دنیا انجام دهید، به مقدار بسیار زیادی پول نیاز دارید. این راهبردهای پولسازی تنها در دسترس افرادی هستند که سرمایهی بسیار زیادی دارند. وامهای لحظهای نمونهای از آیندهای هستند که داشتن پول از ملزومات پول درآوردن نخواهد بود.
-[اطلاعات بیشتر دربارهی وامهای لحظهای](https://aave.com/flash-loans/)
+
+ اطلاعات بیشتر دربارهی وامهای لحظهای
+
@@ -180,7 +182,7 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
- شما 100 Dai، یک [پایدارز](/stablecoins/)، را به یک محصول مثل Aave قرض میدهید.
- شما 100 Aave Dai (aDai) میگیرید. این توکن نمایشدهندهی Dai قرضدادهشدهی شما است.
-- aDai شما بر اساس نرخ بهره زیاد میشود و میتوانید شاهد افزایش میزان موجودی خود در کیف پولتان باشید. بسته به نرخ درصدی سالانه، موجودی کیفپول شما پس از چند روز یا حتی چند ساعت چیزی شبیه 100.1234 خواهد بود!
+- aDai شما بر اساس نرخ بهره زیاد میشود و میتوانید شاهد افزایش میزان موجودی خود در کیف پولتان باشید. بسته به [نرخ درصدی سالیانه](/glossary/#apr)، موجودی کیفپول شما پس از چند روز یا حتی چند ساعت چیزی شبیه به 100.1234 خواهد بود!
- شما میتوانید بهاندازهی aDaiهای موجودی خود در هر زمانی از حساب خود Dai برداشت کنید.
@@ -233,7 +235,7 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
محصولات مدیریت سرمایهای روی اتریوم وجود دارد که سعی میکنند سبد سرمایهای شما را بر اساس راهبرد انتخابیتان بزرگ کنند. این کار بهصورت خودکار انجام میشود، برای همه آزاد است و نیازی به مدیریت انسانی ندارد که بخشی از سود را از آن خود کند.
-یک مثال خوب برای این موضوع [صندوق مبتنی بر شاخص DeFi Pulse (DPI)](https://defipulse.com/blog/defi-pulse-index/) است. این صندوق بهطور خودکار در موجودی خود تغییر ایجاد میکند تا مطمئن شود که سبد داراییهای شما همواره شامل [بهترین توکنهای DeFi از نظر ارزش بازار](https://www.coingecko.com/en/defi) است. شما هیچ گاه نیاز به مدیریت هیچ یک از جزییات ندارید و هر زمان بخواهید میتوانید سرمایهی خود را خارج کنید.
+یک مثال خوب برای این موضوع [صندوق مبتنی بر شاخص DeFi Pulse (DPI)](https://defipulse.com/blog/defi-pulse-index/) است. این صندوق بهطور خودکار در موجودی خود تغییر ایجاد میکند تا مطمئن شود که سبد داراییهای شما همواره شامل بهترین توکنهای DeFi از نظر ارزش بازار است. شما هیچ گاه نیاز به مدیریت هیچ یک از جزییات ندارید و هر زمان بخواهید میتوانید سرمایهی خود را خارج کنید.
مشاهدهی برنامههای غیرمتمرکز سرمایهگذاری
@@ -266,7 +268,9 @@ DeFi یک واژهی کلی برای محصولات و خدمات مالی د
این بدین معنا است که پروژهی A با 100 اهدای 1 دلاری میتواند سرمایهی بیشتری از پروژهی B با یک اهدای 10,000 دلاری جذب کند (بسته به این که ابعاد استخر تطابقی چه قدر باشد).
-[اطلاعات بیشتر دربارهی تأمین مالی درجه دوم](https://wtfisqf.com)
+
+ اطلاعات بیشتر دربارهی تأمین مالی درجه دوم
+
@@ -320,6 +324,8 @@ DeFi از ارزهای رمزنگاری شده و قرارداد هوشمند ا
3. پروتکلها – [قراردادهای هوشمندی](/glossary/#smart-contract) که عملکرد را امکانپذیر میکنند؛ مثلاً خدمتی که امکان قرض دادن داراییها را به صورت غیرمتمرکز فراهم میکند.
4. [برنامههای کاربردی](/dapps/) – محصولاتی که برای مدیریت و دسترسی به پروتکلها استفاده میکنیم.
+توجه: بیشتر دیفای از [استاندارد ERC-20](/glossary/#erc-20) استفاده میکنند. اپلیکیشنها در دیفای از یک ارز همسان برای اتر به نام رپد اتر (WETH) استفاده میکنند. [درباره رپد اتر بیشتر بدانید](/wrapped-eth).
+
## DeFi را بسازید {#build-defi}
DeFi یک جنبش متنباز است. پروتکلها و برنامههای کاربردی DeFi همگی به روی شما باز هستند تا آنها را بررسی کنید، فورک کنید، و روی آنها خلاقیت به خرج دهید. به دلیل این ساختار لایهای (که همگی از زنجیرهی بلوکی و داراییهای پایه یکسان استفاده میکنند)، پروتکلها میتوانند با یکدیگر ترکیب شده و تطبیق دادهشوند تا فرصتهای ترکیبی منحصربهفردی را ایجاد کنند.
@@ -328,13 +334,12 @@ DeFi یک جنبش متنباز است. پروتکلها و برنامه
اطلاعات بیشتر دربارهی ساختن برنامههای غیرمتمرکز
-## بیشتر بخوانید {#futher-reading}
+## بیشتر بخوانید {#further-reading}
### دادههای DeFi {#defi-data}
- [DeFi Prime](https://defiprime.com/)
- [DeFi Llama](https://defillama.com/)
-- [نرخ DeFi](https://defirate.com/)
### مقالههای DeFi {#defi-articles}
@@ -348,5 +353,5 @@ DeFi یک جنبش متنباز است. پروتکلها و برنامه
### جوامع {#communities}
-- [سرور دیسکورد DeFi Llama](https://discord.gg/buPFYXzDDd)
+- [سرور دیسکورد DeFi Llama](https://discord.defillama.com/)
- [سرور دیسکورد DeFi Pulse](https://discord.gg/Gx4TCTk)
diff --git a/public/content/translations/fa/desci/index.md b/public/content/translations/fa/desci/index.md
index 2a9471e7ec0..9e0160ec762 100644
--- a/public/content/translations/fa/desci/index.md
+++ b/public/content/translations/fa/desci/index.md
@@ -1,5 +1,5 @@
---
-title: دانش نامتمرکز (دیسای)
+title: دانش غیرمتمرکز (DeSci)
description: مروری بر علم غیرمتمرکز در اتریوم
lang: fa
template: use-cases
@@ -14,11 +14,11 @@ summaryPoint3: بر اساس جنبش علم باز است.
## علم غیرمتمرکز (DeSci) چیست؟ {#what-is-desci}
-علم غیرمتمرکز (DeSci) جنبشی است که هدف آن ایجاد زیرساخت عمومی برای تأمین مالی، ایجاد، بررسی، اعتباردهی، ذخیره و انتشار دانش علمی به طور عادلانه و عادلانه با استفاده از پشته Web3 است.
+دانش غیرمتمرکز (DeSci) جنبشی است که هدف آن ایجاد زیرساخت عمومی برای تأمین مالی، ایجاد، بررسی، اعتباردهی، ذخیره و انتشار دانش علمی به طور عادلانه و مساوی با استفاده از پشته [Web3](/glossary/#web3) است.
هدف DeSci ایجاد اکوسیستمی است که در آن دانشمندان تشویق می شوند تا تحقیقات خود را آشکارا به اشتراک بگذارند و اعتبار کار خود را دریافت کنند و در عین حال به هر کسی اجازه دهد به راحتی به تحقیق دسترسی داشته باشد و در آن مشارکت کند. DeSci از این ایده استفاده می کند که دانش علمی باید در دسترس همه باشد و روند تحقیقات علمی باید شفاف باشد. DeSci در حال ایجاد یک مدل تحقیقات علمی غیرمتمرکز و توزیعشدهتر است و آن را در برابر سانسور و کنترل مقامات مرکزی مقاومتر میکند. DeSci امیدوار است با غیرمتمرکز کردن دسترسی به بودجه، ابزارهای علمی و کانال های ارتباطی، محیطی ایجاد کند که در آن ایده های جدید و غیر متعارف شکوفا شوند.
-علم غیرمتمرکز به منابع مالی متنوعتر (از [DAO](/dao/)، [کمک مالی درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) تا تأمین مالی جمعی و بیشتر)، دادهها و روشهای دسترسی بیشتر، و با ارائه انگیزههایی برای تکرارپذیری، اجازه میدهد.
+علم غیرمتمرکز، امکان منابع مالی متنوعتر (از [DAO](/glossary/#dao), [اعانه های درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) تا تأمین مالی جمعی و غیره)، دادهها و روشهای قابل دسترس تر، و همراه با ارائه انگیزههایی برای تکثیرپذیری را فراهم می سازد.
### خوان بنت - جنبش DeSci
@@ -28,30 +28,30 @@ summaryPoint3: بر اساس جنبش علم باز است.
فهرست ناقصی از مشکلات کلیدی در علم و اینکه چگونه علم غیرمتمرکز می تواند به رفع این مسائل کمک کند
-| **علم غیرمتمرکز** | **علم سنتی** |
-| ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| توزیع وجوه توسط مردم با استفاده از مکانیسم هایی مانند کمک های مالی درجه دوم یا DAO ها تعیین می شود. | گروه های کوچک، بسته و متمرکز، توزیع وجوه را کنترل می کنند. |
-| شما با همتایان خود از سراسر جهان در تیم های پویا همکاری می کنید. | سازمان های تامین مالی و موسسات خانگی همکاری های شما را محدود می کنند. |
-| تصمیمات مالی به صورت آنلاین و شفاف گرفته می شود. مکانیسم های تامین مالی جدید بررسی شده است. | تصمیمات تامین مالی با مدت زمان طولانی و شفافیت محدود اتخاذ می شود. مکانیسم های مالی کمی وجود دارد. |
-| اشتراکگذاری خدمات آزمایشگاهی با استفاده از Web3 اولیه آسانتر و شفافتر شده است. | به اشتراک گذاری منابع آزمایشگاهی اغلب آهسته و مبهم است. |
-| می توان مدل های جدیدی برای انتشار ایجاد کرد که از Web3 اولیه برای اعتماد، شفافیت و دسترسی جهانی استفاده می کنند. | شما از طریق مسیرهای مشخصی که اغلب به عنوان ناکارآمد، جانبدارانه و استثمارگر شناخته می شوند، منتشر می کنید. |
-| شما می توانید نشانه ها و شهرت را برای کار بررسی همتا کسب کنید. | کار بازبینی شما بدون دستمزد است و به نفع ناشران سودآور است. |
-| شما مالک مالکیت معنوی (IP) هستید که تولید می کنید و آن را طبق شرایط شفاف توزیع می کنید. | مؤسسه خانگی شما مالک IP تولید شده شما است. دسترسی به IP شفاف نیست. |
-| به اشتراک گذاشتن تمام تحقیقات، از جمله دادههای حاصل از تلاشهای ناموفق، با داشتن تمام مراحل در زنجیره. | سوگیری انتشار به این معنی است که محققان احتمال بیشتری برای به اشتراک گذاشتن آزمایش هایی دارند که نتایج موفقیت آمیزی داشته اند. |
+| **علم غیرمتمرکز** | **علم سنتی** |
+| ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| توزیع وجوه **توسط عموم** و با استفاده از مکانیسم هایی مانند اعانه های درجه دوم یا DAO ها تعیین می شود. | گروه های کوچک، بسته و **متمرکز** توزیع وجوه را کنترل می کنند. |
+| شما با همتایانی از **سراسر جهان** در تیمهای پویا همکاری میکنید. | سازمانهای تأمین مالی و مؤسسات خانگی همکاریهای شما را **محدود میکنند**. |
+| تصمیمات تامین مالی به صورت آنلاین و **شفاف** اتخاذ میشوند. مکانیسم های تامین مالی جدید بررسی شده است. | تصمیمات تامین مالی با مدت زمان طولانی و **شفافیت محدود** اتخاذ میشوند. مکانیسم های مالی کمی وجود دارد. |
+| اشتراکگذاری خدمات آزمایشگاهی با استفاده از فناوری [Web3](/glossary/#web3) آسانتر و شفافتر شده است. | اشتراکگذاری منابع آزمایشگاهی اغلب **کُند و مبهم** است. |
+| **مدلهای جدیدی برای انتشار** میتوانند ایجاد شوند که از اصول اولیه Web3 برای اعتماد، شفافیت و دسترسی جهانی استفاده میکنند. | شما از طریق مسیرهای مشخصی که اغلب به عنوان **ناکارآمد، مغرضانه و استثمارگر** شناخته می شوند منتشر میکنید. |
+| میتوانید برای کار **بررسی همتایان، توکن و شهرت کسب کنید**. | **کار بررسی همتایان بدون دستمزد**، و به نفع ناشران انتفاعی است. |
+| **شما دارای مالکیت معنوی (IP) هستید** که بر اساس شرایط شفاف، تولید و توزیع میکنید. | **موسسه خانگی شما مالک IP است** که ایجاد میکنید. دسترسی به IP شفاف نیست. |
+| **اشتراکگذاری همه تحقیقات**، از جمله دیتای حاصل از تلاشهای ناموفق، با انجام تمام مراحل روی زنجیره. | **سوگیری انتشار** به این معنی است که محققان غالباً آزمایشهایی را به اشتراک میگذارند که نتایج موفقیتآمیزی داشتهاند. |
## اتریوم و DeSci {#ethereum-and-desci}
-یک سیستم علمی غیرمتمرکز به امنیت قوی، حداقل هزینه های پولی و معاملاتی و یک اکوسیستم غنی برای توسعه برنامه نیاز دارد. اتریوم همه چیز مورد نیاز برای ایجاد یک پشته علمی غیرمتمرکز را فراهم می کند.
+یک سیستم علمی غیرمتمرکز به امنیت قوی، حداقل هزینه های پولی و معاملاتی و یک اکوسیستم غنی برای توسعه برنامه نیاز دارد. اتریوم همه چیز مورد نیاز برای ساخت یک فناوری دانش غیرمتمرکز را فراهم میکند.
## موارد استفاده DeSci {#use-cases}
-DeSci در حال ساخت مجموعه ابزار علمی برای ورود دانشگاه Web2 به دنیای دیجیتال است. در زیر نمونهای از موارد استفاده است که Web3 میتواند به جامعه علمی ارائه دهد.
+DeSci در حال ساخت مجموعه ابزارهای علمی برای ورود آکادمی های سنتی به دنیای دیجیتال است. در زیر نمونهای از موارد استفاده است که Web3 میتواند به جامعه علمی ارائه دهد.
### انتشار {#publishing}
-انتشار علم بسیار مشکل ساز است زیرا توسط مؤسسات انتشاراتی مدیریت می شود که برای تولید مقالات به نیروی کار رایگان دانشمندان، داوران و ویراستاران متکی هستند اما پس از آن هزینه های گزافی برای انتشار دریافت می کنند. عموم مردم که معمولاً به طور غیرمستقیم برای اثر و هزینه های انتشار از طریق مالیات پرداخت کرده اند، اغلب نمی توانند بدون پرداخت مجدد به ناشر به همان اثر دسترسی داشته باشند. مجموع هزینههای انتشار مقالات علمی منفرد اغلب پنج رقمی است ($USD) که کل مفهوم دانش علمی بهعنوان [کالای عمومی را تضعیف میکند](https://www.econlib.org/library/Enc/PublicGoods.html) در عین حال سود زیادی را برای گروه کوچکی از ناشران ایجاد میکند.
+انتشار علم بسیار مشکل ساز است زیرا توسط مؤسسات انتشاراتی مدیریت می شود که برای تولید مقالات به نیروی کار رایگان دانشمندان، داوران و ویراستاران متکی هستند اما پس از آن هزینه های گزافی برای انتشار دریافت می کنند. عموم مردم که معمولاً به طور غیرمستقیم برای اثر و هزینه های انتشار از طریق مالیات پرداخت کرده اند، اغلب نمی توانند بدون پرداخت مجدد به ناشر به همان اثر دسترسی داشته باشند. مجموع هزینههای انتشار مقالات علمی منفرد اغلب پنج رقمی است ($USD) که کل مفهوم دانش علمی بهعنوان [کالای عمومی](/glossary/#public-goods) را تضعیف میکند، در عین حال سود زیادی را برای گروه کوچکی از ناشران ایجاد میکند.
-پلتفرمهای رایگان و دسترسی آزاد به شکل سرورهای پیش چاپ، [مانند ArXiv](https://arxiv.org/)وجود دارند. با این حال، این پلتفرمها فاقد کنترل کیفیت، [مکانیسمهای ضد سیبیل](https://csrc.nist.gov/glossary/term/sybil_attack)هستند و معمولاً معیارهای سطح مقاله را ردیابی نمیکنند، به این معنی که معمولاً فقط برای تبلیغ کار قبل از ارسال به یک ناشر سنتی استفاده میشوند. SciHub همچنین دسترسی به مقالات منتشر شده را رایگان می کند، اما نه به صورت قانونی، و تنها پس از اینکه ناشران قبلاً پرداخت خود را دریافت کرده و اثر را در قوانین سخت گیرانه حق چاپ قرار داده باشند. این یک شکاف مهم برای مقالات و داده های علمی قابل دسترس با مکانیزم مشروعیت تعبیه شده و مدل انگیزشی باقی می گذارد. ابزار ساخت چنین سیستمی در Web3 وجود دارد.
+پلتفرمهای رایگان و دسترسی آزاد به شکل سرورهای پیش چاپ، [مانند ArXiv](https://arxiv.org/)وجود دارند. با این حال، این پلتفرمها فاقد کنترل کیفیت، [مکانیسمهای ضد سیبیل](/glossary/#anti-sybil)هستند و معمولاً معیارهای سطح مقاله را ردیابی نمیکنند، به این معنی که معمولاً فقط برای تبلیغ کار قبل از ارسال به یک ناشر سنتی استفاده میشوند. SciHub همچنین دسترسی به مقالات منتشر شده را رایگان می کند، اما نه به صورت قانونی، و تنها پس از اینکه ناشران قبلاً پرداخت خود را دریافت کرده و اثر را در قوانین سخت گیرانه حق چاپ قرار داده باشند. این یک شکاف مهم برای مقالات و داده های علمی قابل دسترس با مکانیزم مشروعیت تعبیه شده و مدل انگیزشی باقی می گذارد. ابزار ساخت چنین سیستمی در Web3 وجود دارد.
### تکرارپذیری و تکرارپذیری {#reproducibility-and-replicability}
@@ -60,23 +60,23 @@ DeSci در حال ساخت مجموعه ابزار علمی برای ورود د
- نتایج قابل تکرار را می توان چندین بار متوالی توسط یک تیم با استفاده از روش یکسان به دست آورد.
- نتایج قابل تکرار را می توان توسط گروهی متفاوت با استفاده از تنظیمات آزمایشی یکسان به دست آورد.
-ابزارهای جدید وب 3 می توانند اطمینان حاصل کنند که تکرارپذیری و تکرارپذیری اساس کشف هستند. ما میتوانیم علم با کیفیت را در تار و پود فناوری دانشگاه ببافیم. Web3 توانایی ایجاد گواهی برای هر جزء تجزیه و تحلیل را ارائه می دهد: داده های خام، موتور محاسباتی، و نتیجه برنامه. زیبایی سیستمهای اجماع در این است که وقتی یک شبکه قابل اعتماد برای حفظ این اجزا ایجاد میشود، هر یک از شرکتکنندگان شبکه میتوانند مسئول بازتولید محاسبات و اعتبارسنجی هر نتیجه باشند.
+ابزارهای جدید وب 3 می توانند اطمینان حاصل کنند که تکرارپذیری و تکرارپذیری اساس کشف هستند. ما میتوانیم علم با کیفیت را در تار و پود فناوری دانشگاه ببافیم. Web3 توانایی ایجاد [تاییدها](/glossary/#attestation) برای هر جزئی از تجزیه و تحلیل را ارائه میکند: داده خام، موتور محاسباتی، و نتیجه برنامه. زیبایی سیستمهای اجماع در این است که وقتی یک شبکه قابل اعتماد برای حفظ این اجزا ایجاد میشود، هر یک از شرکتکنندگان شبکه میتوانند مسئول بازتولید محاسبات و اعتبارسنجی هر نتیجه باشند.
### منابع مالی {#funding}
-مدل استاندارد فعلی برای تأمین مالی علم این است که افراد یا گروههایی از دانشمندان درخواستهای کتبی برای یک آژانس تأمین مالی میکنند. گروه کوچکی از افراد مورد اعتماد درخواست ها را نمره گذاری می کنند و سپس با نامزدها قبل از اعطای بودجه به بخش کوچکی از متقاضیان مصاحبه می کنند. گذشته از ایجاد تنگناهایی که منجر به گاهی اوقات سالها انتظار بین درخواست و دریافت کمک هزینه میشود، این مدل به شدت در برابر سوگیریها، منافع شخصی و سیاستهای هیئت بررسی آسیبپذیر است.
+مدل استاندارد فعلی برای تأمین مالی علم این است که افراد یا گروههایی از دانشمندان درخواستهای کتبی برای یک آژانس تأمین مالی میکنند. گروه کوچکی از افراد مورد اعتماد درخواست ها را نمره گذاری می کنند و سپس با نامزدها قبل از اعطای بودجه به بخش کوچکی از متقاضیان مصاحبه می کنند. گذشته از ایجاد تنگناهایی که گاهی اوقات منجر به **سالها انتظار** بین درخواست و دریافت کمک هزینه میشود، این مدل به شدت در برابر **سوگیریها، منافع شخصی و سیاستهای** هیئت بررسی آسیبپذیر است.
مطالعات نشان داده اند که پانل های بررسی کمک هزینه در انتخاب پیشنهادهای با کیفیت بالا کار ضعیفی انجام می دهند، زیرا همان پیشنهادات ارائه شده به پانل های مختلف نتایج بسیار متفاوتی دارند. از آنجایی که بودجه کمیابتر شده است، این بودجه در مجموعه کوچکتری از محققان ارشد با پروژههای محافظهکارانهتر متمرکز شده است. این اثر یک چشم انداز سرمایه گذاری بیش از حد رقابتی ایجاد کرده است، انگیزه های انحرافی را تقویت می کند و نوآوری را خفه می کند.
-Web3 این پتانسیل را دارد که با آزمایش مدلهای انگیزشی مختلف که توسط DAOs و Web3 به طور گسترده ایجاد شدهاند، این مدل بودجه شکسته را مختل کند. [تأمین مالی ماسبق برای کالاهای عمومی](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)، [تأمین مالی درجه](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531)، [حاکمیت DAO](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) و [ساختارهای تشویقی نمادین](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) برخی از ابزارهای Web3 هستند که می توانند تأمین مالی علمی را متحول کنند.
+Web3 این پتانسیل را دارد که با آزمایش مدلهای انگیزشی مختلف که توسط DAOs و Web3 به طور گسترده ایجاد شدهاند، این مدل بودجه شکسته را مختل کند. [تأمین مالی ماسبق برای کالاهای عمومی](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) و [تأمین مالی درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) و [حاکمیت DAO](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) و [ساختارهای تشویقی توکنیزه شده](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) ساختارهای تشویقی توکنیزه شده، برخی از ابزارهای Web3 هستند که می توانند تأمین مالی علمی را متحول کنند.
### مالکیت و توسعه IP {#ip-ownership}
-مالکیت فکری (IP) یک مشکل بزرگ در علم سنتی است: از گیر افتادن در دانشگاه ها یا استفاده نشدن در بیوتکنولوژی گرفته تا ارزش گذاری بسیار سخت. با این حال، مالکیت داراییهای دیجیتال (مانند دادههای علمی یا مقالات) چیزی است که Web3 با استفاده از [توکن غیرقابل تعویض (NFT)](/nft/)خوبی انجام میدهد.
+مالکیت فکری (IP) یک مشکل بزرگ در علم سنتی است: از گیر افتادن در دانشگاه ها یا استفاده نشدن در بیوتکنولوژی گرفته تا ارزش گذاری بسیار سخت. با این حال، مالکیت داراییهای دیجیتال (مانند دادههای علمی یا مقالات) چیزی است که Web3 با استفاده از [توکنهای غیرقابل معاوضه (NFT)](/glossary/#nft) به خوبی انجام میدهد.
همانطور که NFTها می توانند درآمد معاملات آتی را به سازنده اصلی بازگردانند، شما می توانید زنجیره های انتساب ارزش شفاف را برای پاداش دادن به محققان، نهادهای حاکم (مانند DAO) یا حتی افرادی که داده های آنها جمع آوری شده است ایجاد کنید.
-[IP-NFTs](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) همچنین می تواند به عنوان کلیدی برای مخزن داده های غیرمتمرکز آزمایش های تحقیقاتی در حال انجام عمل کند و به NFT و [DeFi](/defi/) مالی (از تقسیم بندی تا استخرهای وام دهی و ارزیابی ارزش) متصل شود. همچنین به نهادهای داخلی زنجیره ای مانند DAO مانند [VitaDAO](https://www.vitadao.com/) اجازه می دهد تا تحقیقات را مستقیماً روی زنجیره انجام دهند. ظهور توکنهای غیرقابل انتقال ["soulbound"](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) نیز ممکن است نقش مهمی در DeSci ایفا کند و به افراد اجازه میدهد تا تجربه و اعتبار خود را در ارتباط با آدرس اتریوم خود ثابت کنند.
+[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) همچنین می تواند به عنوان کلیدی برای مخزن داده های غیرمتمرکز آزمایش های تحقیقاتی در حال انجام عمل کند و به NFT و [DeFi](/glossary/#defi) مالی (از تقسیم بندی تا استخرهای وام دهی و ارزشیابی) متصل شود. همچنین به نهادهای داخلی زنجیره ای مانند DAO مانند [VitaDAO](https://www.vitadao.com/) اجازه می دهد تا تحقیقات را مستقیماً روی زنجیره انجام دهند. ظهور [توکنهای «انحصاری»](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) غیرقابل انتقال نیز ممکن است نقش مهمی در DeSci ایفا کند و به افراد اجازه میدهد تا تجربه و اعتبار خود مرتبط با آدرس اتریوم خود را ثابت کنند.
### ذخیره سازی داده ها، دسترسی و معماری {#data-storage}
@@ -92,27 +92,25 @@ Web3 این پتانسیل را دارد که با آزمایش مدلهای
- [DeSci.Global: رویدادهای جهانی و تقویم ملاقات](https://desci.global)
- [بلاک چین برای علم تلگرام](https://t.me/BlockchainForScience)
-- [Molecule: برای پروژه های تحقیقاتی خود بودجه و بودجه دریافت کنید](https://discover.molecule.to/)
+- [Molecule: برای پروژه های تحقیقاتی خود بودجه و بودجه دریافت کنید](https://www.molecule.xyz/)
- [VitaDAO: دریافت بودجه از طریق توافقنامه های تحقیقاتی حمایت شده برای تحقیقات طول عمر](https://www.vitadao.com/)
- [ResearchHub: یک نتیجه علمی را ارسال کنید و با همتایان خود گفتگو کنید](https://www.researchhub.com/)
- [LabDAO: یک پروتئین را در سیلیکو تا کنید](https://alphafodl.vercel.app/)
- [dClimate API: دادههای آب و هوایی را که توسط یک جامعه غیرمتمرکز جمعآوری شده است، جستجو کنید](https://api.dclimate.net/)
- [DeSci Foundation: سازنده ابزار انتشارات DeSci](https://descifoundation.org/)
- [DeSci.World: فروشگاه تک مرحله ای برای مشاهده کاربران، درگیر شدن با علم غیرمتمرکز](https://desci.world)
-- [پروتکل فلمینگ: اقتصاد داده منبع باز که به کشف مشترک زیست پزشکی کمک می کند](https://medium.com/@FlemingProtocol/a-data-economy-for-patient-driven-biomedical-innovation-9d56bf63d3dd)
-- [OceanDAO: DAO بر تأمین مالی علوم مرتبط با داده نظارت می کرد](https://oceanprotocol.com/dao)
+- [OceanDAO: DAO بر تأمین مالی علوم مرتبط با داده نظارت می کرد](https://oceanprotocol.com/)
- [Opscientia: باز کردن گردش کار علمی غیرمتمرکز](https://opsci.io/research/)
-- [LabDAO: یک پروتئین را در سیلیکو تا کنید](https://alphafodl.vercel.app/)
-- [Bio.xyz: برای پروژه بیوتکنولوژی DAO یا desci خود بودجه دریافت کنید](https://www.molecule.to/)
-- [ResearchHub: یک نتیجه علمی را ارسال کنید و با همتایان خود گفتگو کنید](https://www.researchhub.com/)
-- [VitaDAO: دریافت بودجه از طریق توافقنامه های تحقیقاتی حمایت شده برای تحقیقات طول عمر](https://www.vitadao.com/)
-- [پروتکل فلمینگ: اقتصاد داده منبع باز که به کشف مشترک زیست پزشکی کمک می کند](https://medium.com/@FlemingProtocol/a-data-economy-for-patient-driven-biomedical-innovation-9d56bf63d3dd)
-- [آزمایشگاه استنتاج فعال](https://www.activeinference.org/)
-- [CureDAO: پلتفرم سلامت دقیق متعلق به جامعه](https://docs.curedao.org/)
+- [Bio.xyz: برای پروژه بیوتکنولوژی DAO یا desci خود بودجه دریافت کنید](https://www.bio.xyz/)
+- [پروتکل فلمینگ: اقتصاد داده منبع باز که به کشف مشترک زیست پزشکی کمک می کند](http://flemingprotocol.io/)
+- [موسسه استنتاج فعال](https://www.activeinference.org/)
- [IdeaMarkets: امکان اعتبار علمی غیرمتمرکز](https://ideamarket.io/)
- [DeSci Labs](https://www.desci.com/)
+- [ValleyDAO : یک اجتماع جهانی و باز که سرمایه گذاری و حمایت های انتقالی (قابل انتقال) برای تحقیقات زیستی (بیولوژی) ترکیبی ارئه می دهد](https://www.valleydao.bio)
+- [Cerebrum DAO : منبع یابی و راه حل های مفید برای سلامت مغز پیشرفته و جلوگیری از عصب تباهی (تخریب نورونی)](https://www.cerebrumdao.com/)
+- [CryoDAO: سرمایه گذاری پروژه های بلندپروازانه در حوزه ارز های دیجیتال](https://www.cryodao.org)
-ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط مشی فهرست [سیاست فهرستبندی](/contributing/adding-desci-projects/) ما نگاه کنید!
+ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط مشی فهرست [](/contributing/adding-desci-projects/) ما نگاه کنید!
## بیشتر بخوانید {#further-reading}
@@ -121,9 +119,8 @@ Web3 این پتانسیل را دارد که با آزمایش مدلهای
- [مورد برای DeSci](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
- [راهنمای DeSci](https://future.com/what-is-decentralized-science-aka-desci/)
- [منابع علمی غیرمتمرکز](https://www.vincentweisser.com/decentralized-science)
-- [Molecule's Biopharma IP-NFTs - توضیحات فنی](https://molecule.to/blog/molecules-biopharma-ip-nfts-a-technical-description)
+- [Molecule's Biopharma IP-NFTs - توضیحات فنی](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
- [ساختن سیستم های بی اعتماد علم توسط جان استار](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [ظهور DAOهای بیوتکنولوژی](https://molecule.to/blog/the-emergence-of-biotech-daos)
- [Paul Kohlhaas - DeSci: The Future of Science Decentralized (پادکست)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
- [هستیشناسی استنتاج فعال برای علم غیرمتمرکز: از حسسازی موقعیتیافته تا عوام معرفتی](https://zenodo.org/record/6320575)
- [DeSci: The Future of Research اثر ساموئل آکینوشو](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
diff --git a/public/content/translations/fa/developers/docs/accounts/index.md b/public/content/translations/fa/developers/docs/accounts/index.md
index 8c75af133f6..9613b68f342 100644
--- a/public/content/translations/fa/developers/docs/accounts/index.md
+++ b/public/content/translations/fa/developers/docs/accounts/index.md
@@ -51,7 +51,7 @@ lang: fa
## حسابهای دارای مالکیت خارجی و جفت کلیدها {#externally-owned-accounts-and-key-pairs}
-هر حساب به وسیلهی دو کلید ساخته می شود: عمومی و خصوصی. به کمک این دو کلید میتوان ثابت کرد که یک تراکنش از طریق فرستنده بوده و از جعل جلوگیری میکند. کلید خصوصی شما همان چیزی است که برای امضای تراکنش از آن استفاده میکنید، پس اختیار شما بر وجوه مرتبط با حسابتان را تأیید میکند. بنابراین در واقع شما رمزارزی نگهداری نمیکنید، شما کلید خصوصی را نگه میدارید - سرمایهی شما همیشه در دفتر کل اتریوم نگهداری میشود.
+یک حساب کاربری از یک جفت کلید رمزنگاری تشکیل شده است: عمومی و خصوصی. به کمک این دو کلید میتوان ثابت کرد که یک تراکنش از طریق فرستنده بوده و از جعل جلوگیری میکند. کلید خصوصی شما همان چیزی است که برای امضای تراکنش از آن استفاده میکنید، پس اختیار شما بر وجوه مرتبط با حسابتان را تأیید میکند. بنابراین در واقع شما رمزارزی نگهداری نمیکنید، شما کلید خصوصی را نگه میدارید - سرمایهی شما همیشه در دفتر کل اتریوم نگهداری میشود.
و با این کار جلوی عاملان بداندیشی که میخواهند اطلاعات تقلبی بفرستند را میگیرد، زیرا شما میتوانید اثبات کنید چه کسی فرستندهی تراکنش بوده است.
@@ -59,7 +59,7 @@ lang: fa
## ساختن حساب {#account-creation}
-هنگام ساختن حساب، بیشتر کتابخانهها یک کلید خصوصی تصادفی برای شما میسازند.
+هنگامی که میخواهید یک حساب بسازید، اکثر کتابخانهها یک کلید خصوصی تصادفی برای شما تولید می کنند.
یک کلید خصوصی از 64 کاراکتر هگز تشکیل شده است که میتواند به وسیلهی یک گذرواژه رمزنگاری شود.
@@ -69,6 +69,12 @@ lang: fa
کلید عمومی با استفاده از [الگوریتم امضای دیجیتال منحنی بیضوی](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) از کلید خصوصی ساخته میشود. شما با حذف 20 بایت انتهایی هش keccak-256 کلید عمومی خود و افزودن `0X` در ابتدای آن یک آدرس عمومی برای حسابتان خواهید داشت.
+این بدان معناست که یک حساب دارای مالکیت خارجی (EOA) دارای یک آدرس 42 کاراکتری است (بخش 20 بایتی که 40 کاراکتر هگزا دسیمال به اضافه پیشوند `0x` است).
+
+مثال:
+
+`0x5e97870f263700f46aa00d967821199b9bc5a120`
+
مثال زیر نحوه استفاده از ابزار امضا به نام [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) را برای ایجاد یک حساب جدید نشان می دهد. Clef یک ابزار مدیریت و امضای حساب است که همراه با مشتری اتریوم، [Geth](https://geth.ethereum.org) ارائه میشود. دستور `clef newaccount` یک جفت کلید جدید ایجاد می کند و آنها را در یک فروشگاه کلید رمزگذاری شده ذخیره می کند.
```
@@ -86,9 +92,9 @@ WARN [10-28|16:19:09.306] لطفاً از مسیر فایل کلید خود نس
[مستندات Geth](https://geth.ethereum.org/docs)
-شما میتوانید از کلید خصوصی خود کلیدهای عمومی جدید به دست بیاورید، اما نمیتوانید از کلیدهای عمومی کلید خصوصی به دست بیاورید. این یعنی شما باید کلید خصوصی خود را امن، و همانطور که اسمش میگوید، **خصوصی** نگه دارید.
+شما میتوانید از کلید خصوصی خود کلیدهای عمومی جدید به دست بیاورید، اما نمیتوانید از کلیدهای عمومی کلید خصوصی به دست بیاورید. ایمن و همانطور که از نام آن پیداست یعنی **خصوصی** نگه داشتن کلیدهای خصوصی، حیاتی است.
-شما برای امضای پیامها و تراکنشهایی را که خروجی امضا دارند به کلید خصوصی نیاز دارید. دیگران متعاقباً میتوانند امضای شما را دریافت کنند و به وسیلهی آن از کلید عمومی شما مشتق بگیرند، و نویسندهی پیام را ثابت کنند. در فرم درخواست خود، میتوانید برای ارسال تراکنشها به شبکه از کتابخانهی جاوا اسکریپت استفاده کنید.
+شما برای امضای پیامها و تراکنشهایی را که خروجی امضا دارند به کلید خصوصی نیاز دارید. دیگران متعاقباً میتوانند امضای شما را دریافت کنند و به وسیلهی آن از کلید عمومی شما مشتق بگیرند، و نویسندهی پیام را ثابت کنند. در برنامهتان، می توانید از کتابخانه جاوا اسکریپت برای ارسال تراکنش ها به شبکه استفاده کنید.
## حسابهای قرارداد {#contract-accounts}
@@ -108,7 +114,7 @@ WARN [10-28|16:19:09.306] لطفاً از مسیر فایل کلید خود نس
## یادداشتی درباره کیف پولها {#a-note-on-wallets}
-حساب با کیف پول متفاوت است. یک حساب، یک جفت کلید برای یک حساب اتریوم تحت مالکیت کاربر است. یک کیف پول، یک رابط یا اپلیکیشن است که به شما اجازه میدهد با حساب اتریومتان ارتباط برقرار کنید.
+حساب با کیف پول متفاوت است. کیفپول یک رابط یا برنامه ای است که به شما امکان می دهد با حساب اتریوم خود، چه یک حساب خارجی یا یک حساب قراردادی، تعامل داشته باشید.
## یک نسخهی آزمایشی تصویری {#a-visual-demo}
diff --git a/public/content/translations/fa/developers/docs/blocks/index.md b/public/content/translations/fa/developers/docs/blocks/index.md
index b37356fc272..77c0b1a2d76 100644
--- a/public/content/translations/fa/developers/docs/blocks/index.md
+++ b/public/content/translations/fa/developers/docs/blocks/index.md
@@ -55,7 +55,7 @@ lang: fa
| `eth1_data` | اطلاعاتی در مورد قرارداد سپرده |
| `graffiti` | داده اختیاری که برای تگ بلاکها استفاده می شود |
| `proposer_slashings` | لیست اعتبارسنجهایی که قرار است اسلش شوند |
-| `attester_slashings` | لیست اعتبارسنجهایی که قرار است اسلش شوند |
+| `attester_slashings` | لیست گواهیدهندگانی که باید اسلش یا جریمه شوند |
| `تصدیقها` | لیست تصدیقهایی که بلاک فعلی را تایید میکنند |
| `سپرده` | لیست سپردههای جدید مربوط به قرارداد سپرده |
| `voluntary_exits` | لیست اعتبارسنجهای در حال خروج از شبکه |
@@ -127,7 +127,7 @@ lang: fa
| میدان | توضیح |
|:---------------- |:------------------------------- |
| `آدرس` | آدرس حسابی که که برداشت شده است |
-| `amount` | مقدار برداشت شده |
+| `مقدار` | مقدار برداشت شده |
| `index` | مقدار شاخص برداشت |
| `validatorIndex` | مقدار شاخص اعتبارسنج |
@@ -139,11 +139,11 @@ lang: fa
## اندازهی بلوک {#block-size}
-یک نکته مهم نهایی این است که خود بلوکها از نظر اندازه محدود هستند. هر بلوک یک اندازه هدف به میزان 15 میلیون گاز دارد، اما اندازه بلوکها میتواند بسته به تقاضای شبکه بیشتر یا کمتر شود و بیشترین حد آن 30 میلیون گاز است (2 برابر اندازه هدف بلوک). مجموع کل گاز خرجشده توسط همه تراکنشها در بلوک باید کمتر از حد گاز بلوک باشد. این نکته مهمی است، چون تضمین میکند که یک بلوک نمیتواند بهاندازه دلخواه بزرگ باشد. اگر بلوکها بتوانند به اندازه دلخواه بزرگ باشند، آنگاه گرههای کاملی که اندکی قدرت کمتری دارند با توجه به سرعت و فضای مورد نیاز به تدریج نمیتوانند با شبکه پیش بیایند. هر چه بلوک بزرگتر باشد، توان محاسبه بیشتری برای پردازش به موقع آن در بلوک بعدی لازم است. این یک نیروی متمرکز کننده است، که با محدود کردن سایز بلوک محدود میشود.
+یک نکته مهم نهایی این است که خود بلوکها از نظر اندازه محدود هستند. هر بلوک یک اندازه هدف به میزان 15 میلیون گاز دارد، اما اندازه بلوکها میتواند بسته به تقاضای شبکه بیشتر یا کمتر شود و بیشترین حد آن 30 میلیون گاز است (2 برابر اندازه هدف بلوک). حد گس بلوک را میتوان با ضریب 1 به 1024 از حد گس بلوک قبلی به سمت بالا یا پایین تنظیم کرد. در نتیجه، اعتبار سنجها می توانند حد گس بلوک را از طریق اجماع تغییر دهند. مجموع کل گاز خرجشده توسط همه تراکنشها در بلوک باید کمتر از حد گاز بلوک باشد. این نکته مهمی است، چون تضمین میکند که یک بلوک نمیتواند بهاندازه دلخواه بزرگ باشد. اگر بلوکها بتوانند به اندازه دلخواه بزرگ باشند، آنگاه گرههای کاملی که اندکی قدرت کمتری دارند با توجه به سرعت و فضای مورد نیاز به تدریج نمیتوانند با شبکه پیش بیایند. هر چه بلوک بزرگتر باشد، توان محاسبه بیشتری برای پردازش به موقع آن در بلوک بعدی لازم است. این یک نیروی متمرکز کننده است، که با محدود کردن سایز بلوک محدود میشود.
## بیشتر بدانید {#further-reading}
-_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
## موضوعات مرتبط {#related-topics}
diff --git a/public/content/translations/fa/developers/docs/bridges/index.md b/public/content/translations/fa/developers/docs/bridges/index.md
new file mode 100644
index 00000000000..2b8a0853c56
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/bridges/index.md
@@ -0,0 +1,135 @@
+---
+title: پلها
+description: مروری بر پل زدن برای توسعهدهندگان
+lang: fa
+---
+
+با گسترش بلاکچین های L1 و راه حل های [مقیاس پذیری](/developers/docs/scaling/) L2، در کنار تعداد روزافزون برنامه های غیرمتمرکز که به صورت زنجیره ای متقابل انجام می شوند، نیاز به ارتباطات و جابجایی دارایی ها در میان زنجیره ها به بخشی ضروری از زیرساخت شبکه تبدیل شده است. انواع مختلفی از پل ها برای کمک به این وضعیت وجود دارد.
+
+## نیاز به پل ها {#need-for-bridges}
+
+پل هایی برای اتصال شبکه های بلاکچین وجود دارند. آنها اتصال و قابلیت همکاری بین بلاکچین ها را امکانپذیر می کنند.
+
+بلاکچین ها در محیط های سیلو وجود دارند، به این معنی که هیچ راهی برای تجارت و ارتباط طبیعی با بلاکچین های دیگر وجود ندارد. در نتیجه، در حالی که می تواند فعالیت و نوآوری قابل توجهی در یک اکوسیستم وجود داشته باشد، به دلیل عدم اتصال و قابلیت همکاری با سایر اکوسیستم ها محدود شده است.
+
+پل ها راهی برای ارتباط محیط های بلاکچین ایزوله با یکدیگر ارائه می دهند. آنها یک مسیر حمل و نقل بین بلاکچین ایجاد می کنند که در آن توکن ها، پیام ها، داده های دلخواه و حتی تماس های [قرارداد هوشمند](/developers/docs/smart-contracts/) می توانند از یک زنجیره به زنجیره دیگر منتقل شوند.
+
+## مزایای پل ها {#benefits-of-bridges}
+
+به زبان ساده، پل ها با اجازه دادن به شبکه های بلاکچین برای تبادل داده ها و جابجایی دارایی ها بین آنها، موارد استفاده متعدد را باز می کنند.
+
+بلاکچین ها دارای نقاط قوت، ضعف و رویکردهای منحصر به فردی برای ساخت برنامه های کاربردی هستند (مانند سرعت، توان عملیاتی، هزینه و غیره). پلها به توسعه اکوسیستم رمزنگاری کلی کمک میکنند و بلاکچینها را قادر میسازند تا از نوآوریهای یکدیگر استفاده کنند.
+
+برای توسعه دهندگان، پل ها موارد زیر را فعال می کنند:
+
+- انتقال هر گونه داده، اطلاعات و دارایی در زنجیره ها.
+- باز کردن قفل ویژگی های جدید و موارد استفاده برای پروتکل ها به عنوان پل، فضای طراحی را برای آنچه پروتکل ها می توانند ارائه دهند گسترش می دهند. به عنوان مثال، یک پروتکل برای فارمینگ بهره که در اصل در شبکه اصلی اتریوم مستقر شده است، میتواند استخرهای نقدینگی را در تمام زنجیرههای سازگار با EVM ارائه دهد.
+- فرصتی برای استفاده از نقاط قوت بلاکچین های مختلف. به عنوان مثال، توسعهدهندگان میتوانند از هزینههای کمتری که راهحلهای L2 مختلف ارائه میکنند، با استقرار دپ های خود در سرتاسر مجموعهها، بهرهمند شوند، و زنجیرههای جانبی و کاربران میتوانند روی آنها پل بزنند.
+- همکاری بین توسعه دهندگان از اکوسیستم های مختلف بلاکچین برای ساخت محصولات جدید.
+- جذب کاربران و جوامع از اکوسیستم های مختلف به برنامه های خود.
+
+## پل ها چگونه کار می کنند؟ {#how-do-bridges-work}
+
+در حالی که [انواع زیادی از طرح های پل](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) وجود دارد، سه راه برای تسهیل انتقال زنجیره ای متقابل دارایی ها برجسته است:
+
+- **قفل و ضرب کردن-** داراییها را در زنجیره مبدا قفل کنید و داراییها را در زنجیره مقصد ضرب کنید.
+- **سوزاندن و ضرب کردن –** سوزاندن دارایی ها در زنجیره مبدا و ضرب دارایی ها در زنجیره مقصد.
+- **سوآپهای اتمی –** داراییهای موجود در زنجیره مبدا را با داراییهای زنجیره مقصد با طرف دیگر مبادله کنید.
+
+## اواع پل ها {#bridge-types}
+
+پل ها را معمولاً می توان به یکی از سبد های زیر طبقه بندی کرد:
+
+- **پلهای بومی –** این پلها معمولاً برای راهاندازی نقدینگی در یک بلاکچین خاص ساخته میشوند و انتقال وجوه به اکوسیستم را برای کاربران آسانتر میکنند. به عنوان مثال، [پل آربیتروم](https://bridge.arbitrum.io/) به گونهای ساخته شده است که اتصال از شبکه اصلی اتریوم به آربیتروم را برای کاربران راحت کند. از دیگر پل های این چنینی می توان به پل Polygon PoS Bridge، [Optimism Gateway](https://app.optimism.io/bridge) و غیره اشاره کرد.
+- **پلهای مبتنی بر اعتبارسنج یا اوراکل -** این پلها برای اعتبارسنجی انتقالهای بین زنجیرهای به مجموعه یا اوراکلهای اعتبارسنج خارجی متکی هستند. مثال: Multichain و Across.
+- **پلهای ارسال پیام عمومی -** این پلها میتوانند داراییها را همراه با پیامها و دادههای دلخواه در زنجیرهها انتقال دهند. نمونه: Axelar و LayerZero و Nomad.
+- **شبکه های نقدینگی -** این پل ها در درجه اول بر انتقال دارایی ها از یک زنجیره به زنجیره دیگر از طریق سوآپ اتمی تمرکز دارند. به طور کلی، آنها از ارسال پیام بین زنجیره ای پشتیبانی نمی کنند. نمونه: Connext و Hop.
+
+## مبادلات قابل تامل {#trade-offs}
+
+با پل ها، هیچ راه حل کاملی وجود ندارد. در عوض، فقط مبادلاتی برای تحقق یک هدف وجود دارد. توسعه دهندگان و کاربران می توانند پل ها را بر اساس عوامل زیر ارزیابی کنند:
+
+- **امنیت -** چه کسی سیستم را تأیید می کند؟ پل هایی که توسط اعتبارسنجهای خارجی ایمن می شوند، معمولاً نسبت به پل هایی که به صورت محلی یا بومی توسط اعتبارسنج های بلاکچین ایمن شده اند، امنیت کمتری دارند.
+- **راحتی -** چه مدت طول می کشد تا یک تراکنش کامل شود و یک کاربر به چند تراکنش نیاز داشت تا امضا کند؟ برای یک توسعه دهنده، چقدر طول می کشد تا یک پل یکپارچه شود، و این فرآیند چقدر پیچیده است؟
+- **اتصال -** زنجیرههای مختلف مقصد که یک پل میتواند به یکدیگر متصل کند (به عنوان مثال، زنجیرههای جانبی، سایر بلاکچینهای لایه 1 و غیره) چیست و ادغام یک بلاکچین جدید چقدر سخت است؟
+- **قابلیت انتقال دادههای پیچیدهتر –** آیا پل میتواند انتقال پیامها و دادههای دلخواه پیچیدهتر را در زنجیرهها فعال کند یا فقط از انتقال داراییهای بین زنجیرهای پشتیبانی میکند؟
+- **مقرون به صرفه بودن -** هزینه انتقال دارایی ها در بین زنجیره ها از طریق یک پل چقدر است؟ به طور معمول، پل ها بسته به هزینه های گس و نقدینگی مسیرهای خاص، هزینه ثابت یا متغیری را دریافت می کنند. همچنین ارزیابی مقرون به صرفه بودن یک پل بر اساس سرمایه مورد نیاز برای اطمینان از امنیت آن بسیار مهم است.
+
+در سطح بالا، پل ها را می توان به عنوان قابل اعتماد و غیر قابل اعتماد طبقه بندی کرد.
+
+- **قابل اعتماد–** پل های قابل اعتماد به صورت خارجی تأیید می شوند. آنها از مجموعهای خارجی از تأییدکنندهها (فدراسیونهایی با سیستمهای محاسباتی چندگانه، چند حزبی، شبکه اوراکل) برای ارسال دادهها در زنجیرهها استفاده میکنند. در نتیجه، آنها می توانند اتصال عالی را ارائه دهند و امکان ارسال پیام کاملاً تعمیم یافته را از طریق زنجیره ها فراهم کنند. آنها همچنین تمایل دارند با سرعت و مقرون به صرفه عملکرد خوبی داشته باشند. این به قیمت امنیت تمام می شود، زیرا کاربران باید به امنیت پل اتکا کنند.
+- **غیر قابل اعتماد –** این پلها برای انتقال پیامها و توکن ها، به بلاکچین هایی که وصل میکنند و اعتبارسنجهای آنها متکی هستند. آنها «عیر قابل اعتماد» هستند زیرا فرضیات اعتماد جدیدی را اضافه نمی کنند (علاوه بر بلاکچین). در نتیجه، پلهای غیرقابل اعتماد نسبت به پلهای قابل اعتماد از امنیت بیشتری برخوردار هستند.
+
+برای ارزیابی پلهای غیرقابل اعتماد بر اساس عوامل دیگر، باید آنها را به پلهای انتقال پیام عمومی و شبکههای نقدینگی تقسیم کنیم.
+
+- **پل های ارسال پیام عمومی –** این پل ها از نظر امنیت و توانایی انتقال داده های پیچیده تر در زنجیره ها عالی هستند. به طور معمول، آنها همچنین از نظر مقرون به صرفه بودن خوب هستند. با این حال، این نقاط قوت عموماً با کاهش اتصال برای پلهای کلاینت سبک (مثلاً IBC) و معایب سرعت برای پلهای خوشبینانه (مثلاً: Nomad) است که از اثبات تقلب استفاده میکنند.
+- **شبکههای نقدینگی -** این پلها از مبادله اتمی برای انتقال داراییها استفاده میکنند و سیستمهای تأیید شده محلی هستند (یعنی از اعتبارسنج های بلاکچین برای تأیید تراکنشها استفاده میکنند). در نتیجه، از نظر امنیت و سرعت برتری دارند. علاوه بر این، نسبتاً مقرون به صرفه در نظر گرفته می شوند و اتصال خوبی را ارائه می دهند. با این حال، ایراد اصلی ناتوانی آنها در انتقال داده های پیچیده تر است - زیرا از ارسال پیام زنجیره ای پشتیبانی نمی کنند.
+
+## خطر استفاده از پلها {#risk-with-bridges}
+
+پل ها سه مورد از [بزرگترین هک ها در دیفای](https://rekt.news/leaderboard/) را تشکیل می دهند و هنوز در مراحل اولیه توسعه است. استفاده از هر پل خطرات زیر را به همراه دارد:
+
+- **خطر قرارداد هوشمند -** در حالی که بسیاری از پلها با موفقیت ممیزی را پشت سر گذاشتهاند، تنها یک نقص در قرارداد هوشمند لازم است تا داراییها در معرض هک قرار گیرند (مثلاً: [پل Wormhole سولانا](https://rekt.news/wormhole-rekt/)).
+- **ریسکهای مالی سیستمی** - بسیاری از پلها از داراییهای رپ شده برای ضرب کردن نسخههای متعارف دارایی اصلی در یک زنجیره جدید استفاده میکنند. این امر اکوسیستم را در معرض خطر سیستماتیک قرار می دهد، زیرا شاهد بهره برداری از نسخه های رپ شده توکن ها بودیم.
+- **خطر طرف مقابل -** برخی از پلها از طراحی قابل اعتمادی استفاده میکنند که کاربران را ملزم میکند بر این فرض تکیه کنند که اعتبارسنج ها برای سرقت وجوه کاربران تبانی نمیکنند. نیاز کاربران به اعتماد به این بازیگران طرف ثالث، آنها را در معرض خطراتی مانند راگ پول، سانسور و سایر فعالیتهای مخرب قرار میدهد.
+- **مسئلههای باز -** با توجه به اینکه پل ها در مراحل اولیه توسعه هستند، سوالات بی پاسخ بسیاری در رابطه با نحوه عملکرد پل ها در شرایط مختلف بازار وجود دارد. مانند زمان ازدحام شبکه و در طول رویدادهای پیش بینی نشده مانند حملات در سطح شبکه یا رولبکهای حالت. این عدم قطعیت خطرات خاصی را به همراه دارد که درجه آن هنوز مشخص نیست.
+
+## چگونه dapp ها می توانند از پل ها استفاده کنند؟ {#how-can-dapps-use-bridges}
+
+در اینجا چند برنامه کاربردی وجود دارد که توسعه دهندگان می توانند در مورد پل ها و استفاده از زنجیره متقابل dapp خود در نظر بگیرند:
+
+### یکپارچه سازی پل ها {#integrating-bridges}
+
+برای توسعه دهندگان، راه های زیادی برای اضافه کردن پشتیبانی برای پل ها وجود دارد:
+
+1. **ساختن پل خودتان -** ساختن پل ایمن و قابل اعتماد آسان نیست، به خصوص اگر مسیری را انتخاب کنید که اعتماد به حداقل برسد. علاوه بر این، به سالها تجربه و تخصص فنی مرتبط با مطالعات مقیاس پذیری و قابلیت همکاری نیاز دارد. علاوه بر این، به یک تیم عملی برای حفظ یک پل و جذب نقدینگی کافی برای امکانپذیر کردن آن نیاز دارد.
+
+2. **نمایش چندین گزینه پل به کاربران -** بسیاری از [دپ ها](/developers/docs/dapps/) از کاربران میخواهند توکن بومی خود را داشته باشند تا با آنها تعامل داشته باشند. برای اینکه کاربران بتوانند به توکن های خود دسترسی داشته باشند، گزینه های پل متفاوتی را در وب سایت خود ارائه می دهند. با این حال، این روش یک راه حل سریع برای این مشکل است، زیرا کاربر را از رابط dapp دور می کند و همچنان نیاز به تعامل با دیگر dapp ها و پل ها دارد. این یک تجربه حضوری دست و پا گیر با دامنه افزایش اشتباهات است.
+
+3. **یکپارچه سازی یک پل –** این راه حل نیازی به ارسال کاربران به پل خارجی و رابط های DEX ندارد. این به dapp ها اجازه می دهد تا تجربه ورود کاربر را بهبود بخشند. با این حال، این رویکرد دارای محدودیت هایی است:
+
+ - ارزیابی و نگهداری پل ها سخت و زمان بر است.
+ - انتخاب یک پل یک نقطه شکست و وابستگی ایجاد می کند.
+ - دپ، با قابلیت های پل محدود می شود.
+ - پل ها به تنهایی ممکن است کافی نباشند. Dapp ها ممکن است برای ارائه عملکردهای بیشتری مانند تبادل زنجیره ای به DEX نیاز داشته باشند.
+
+4. **یکپارچه سازی چندین پل –** این راه حل بسیاری از مشکلات مربوط به یکپارچه سازی یک پل را حل می کند. با این حال، محدودیتهایی نیز دارد، زیرا یکپارچهسازی پلهای متعدد منابع را مصرف میکند و هزینههای فنی و ارتباطی را برای توسعهدهندگان ایجاد میکند – کمیابترین منبع در دنیای رمزارز.
+
+5. **یکپارچه سازی یک پل جمع کننده –** گزینه دیگر برای dapp ها یکپارچه سازی راه حل تجمیع پل است که به آنها امکان دسترسی به پل های متعدد را می دهد. جمعکنندههای پل، نقاط قوت همه پلها را به ارث میبرند و بنابراین با قابلیتهای هیچ پل محدود نمیشوند. نکته قابل توجه، جمعکنندههای پل معمولاً ادغامهای پل را حفظ میکنند، که باعث میشود دپ از دردسر ماندن در بالای جنبههای فنی و عملیاتی یکپارچهسازی پل نجات یابد.
+
+همانطور که گفته شد، جمع کننده های پل نیز محدودیت های خود را دارند. به عنوان مثال، در حالی که آنها می توانند گزینه های پل بیشتری را ارائه دهند، پل های بسیار بیشتری به غیر از پلتفرم های ارائه شده در پلت فرم جمع کننده معمولاً در بازار موجود است. علاوه بر این، درست مانند پلها، جمعکنندههای پل نیز در معرض خطرات قرارداد هوشمند و فناوری هستند (قراردادهای هوشمند بیشتر = خطرات بیشتر).
+
+اگر یک dapp مسیر ادغام یک پل یا یک تجمیع کننده را طی کند، گزینه های مختلفی بر اساس عمق ادغام وجود دارد. به عنوان مثال، اگر این فقط یک ادغام جلویی برای بهبود تجربه ورود کاربر باشد، یک dapp ویجت را ادغام می کند. با این حال، اگر ادغام برای کاوش استراتژیهای بین زنجیرهای متقابل عمیقتر مانند سهامگذاری، ییلد فارمینگ و غیره باشد، دپ اقدام به ادغام SDK یا API میکند.
+
+### استقرار یک dapp در چندین زنجیره {#deploying-a-dapp-on-multiple-chains}
+
+برای استقرار یک dapp در چندین زنجیره، توسعهدهندگان میتوانند از پلتفرمهای توسعه مانند [Alchemy](https://www.alchemy.com/)، [Hardhat](https://hardhat.org/)، [Truffle](https://trufflesuite.com/)، [Moralis](https://moralis.io/) ، و غیره استفاده کنند. به طور معمول، این پلتفرمها با پلاگینهای قابل ترکیبی عرضه میشوند که میتوانند dappها را قادر به انجام فعالیت بین زنجیرهای کنند. به عنوان مثال، توسعه دهندگان می توانند از یک پراکسی استقرار قطعی ارائه شده توسط [افزونه hardhat-deploy](https://github.com/wighawag/hardhat-deploy) استفاده کنند.
+
+#### مثال ها:
+
+- [نحوه ساخت دپ های بین زنجیره ای](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [ساختن یک مارکتپلیس NFT بین زنجیره ای](https://youtu.be/WZWCzsB1xUE)
+- [Moralis: ساختن دپ های NFT بین زنجیره ای](https://www.youtube.com/watch?v=ehv70kE1QYo)
+
+### نظارت بر فعالیت قرارداد در سراسر زنجیره {#monitoring-contract-activity-across-chains}
+
+برای نظارت بر فعالیت قرارداد بین زنجیرهای، توسعهدهندگان میتوانند از زیرگرافها و پلتفرمهای توسعهدهنده مانند Tenderly برای مشاهده قراردادهای هوشمند در زمان واقعی استفاده کنند. چنین پلتفرمهایی همچنین دارای ابزارهایی هستند که عملکرد نظارت بیشتری بر دادهها را برای فعالیتهای زنجیرهای متقابل ارائه میکنند، مانند بررسی [رویدادهای منتشر شده توسط قراردادها](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) و غیره.
+
+#### ابزارها
+
+- [The Graph](https://thegraph.com/en/)
+- [Tenderly](https://tenderly.co/)
+
+## بیشتر بخوانید {#further-reading}
+
+- [پلهای بلاکچین](/bridges/) – ethereum.org
+- [پلهای بلاکچین: ساختن شبکههای رمزنگاری](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 8 سپتامبر 2021 – Dmitriy Berenzon
+- [قابلیت عملیات متقابل Trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 1 اکتبر 2021 – Arjun Bhuptani
+- [خوشهها: پلهای قابل اعتماد و & دارای اعتماد حداقل چگونه دورنمای مالتیچین را شکل میدهند](https://blog.celestia.org/clusters/)4 اکتبر 2021 – Mustafa Al-Bassam
+- [LI.FI: با پلها، اعتماد یک طیف است](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 28 آوریل 2022 – Arjun Chand
+
+همچنین، اینجا بعضی تعاریف پرمعنی از [James Prestwich](https://twitter.com/_prestwich) وجود دارد که میتوانند به درک عمیقتر از پلها کمک کنند:
+
+- [ساختن پلها، نه باغهای دیواردار](https://youtu.be/ZQJWMiX4hT0)
+- [فرو ریختن پلها](https://youtu.be/b0mC-ZqN8Oo)
+- [چرا پلها میسوزند](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/fa/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/fa/developers/docs/consensus-mechanisms/poa/index.md
new file mode 100644
index 00000000000..fc0777409a0
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/consensus-mechanisms/poa/index.md
@@ -0,0 +1,79 @@
+---
+title: اثبات صلاحیت (PoA)
+description: توضیح پروتکل اجماع اثبات صلاحیت و نقش آن در اکوسیستم بلاکچین.
+lang: fa
+---
+
+**اثبات صلاحیت (PoA)** یک الگوریتم اجماع مبتنی بر شهرت است که یک نسخه اصلاح شده از [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) است. بیشتر در زنجیرههای خصوصی، تستنتها و شبکههای توسعه محلی مورد استفاده قرار میگیرد. PoA یک الگوریتم اجماع مبتنی بر اعتبار است که به جای یک مکانیسم مبتنی بر سهام در PoS، نیاز به اعتماد به یک مجموعه از امضاکنندگان مجاز برای تولید بلوکها دارد.
+
+## پیش نیازها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/)، و [مکانیسمهای اجماع](/developers/docs/) سازوکارهای اجماع را مطالعه کنید.
+
+## اثبات صلاحیت (PoA) چیست؟ {#what-is-poa}
+
+اثبات صلاحیت یک نسخه اصلاح شده از \*\*[اثبات سهام](/developers/docs/consensus-mechanisms/pos/) (PoS) است که یک الگوریتم اجماع مبتنی بر اعتبار به جای مکانیسم مبتنی بر سهام در PoS است. این اصطلاح برای اولین بار در سال 2017 توسط گاوین وود معرفی شد و این الگوریتم اجماع بیشتر توسط زنجیرههای خصوصی، شبکههای آزمایشی و شبکههای توسعه محلی استفاده شده است، زیرا مانند PoW بر نیاز به منابع با کیفیت بالا غلبه میکند و بر مقیاسپذیری غلبه میکند. با داشتن زیرمجموعه کوچکی از گرهها که بلاکچین را ذخیره میکنند و بلوکها را تولید میکنند، بر مشکلات مقیاسپذیری با PoS غلبه میکند.
+
+اثبات صلاحیت مستلزم اعتماد به مجموعهای از امضاکنندگان مجاز است که در [بلوک پیدایش] (/ واژهنامه/#genesis-block) تنظیم شدهاند. در اکثر اجراهای فعلی، همه امضاکنندگان مجاز هنگام تعیین اجماع زنجیره، از قدرت و امتیازات برابر برخوردار هستند. ایده مبنای سهام گذاری شهرت این است که هر اعتبارسنج مجاز از طریق مواردی مانند شناخت مشتری خود (KYC)، یا داشتن یک سازمان شناخته شده که تنها اعتباردهنده است، برای همه شناخته شده است - به این ترتیب اگر اعتبارسنج کار اشتباهی انجام دهد، هویت او مشخص می شود.
+
+چندین اجرای PoA وجود دارد، اما اجرای استاندارد اتریوم **کلیک** است که [EIP-225] (https://eips.ethereum.org/EIPS/eip-225) را اجرا میکند. کلیک یک استاندارد توسعهدهندهپسند و آسان برای اجرا است که از همه انواع همگامسازیهای کاربر پشتیبانی میکند. اجراهای دیگر عبارتند از [IBFT 2.0](https://besu.hyperledger.org/stable/private-networks/concepts/poa) و [Aura](https://openethereum.github.io/Chain-specification).
+
+## چگونه کار میکند {#how-it-works}
+
+در PoA، مجموعه ای از امضاکنندگان مجاز برای ایجاد بلوک های جدید انتخاب می شوند. امضاکنندگان بر اساس شهرت خود انتخاب می شوند و آنها تنها کسانی هستند که اجازه ایجاد بلوک های جدید را دارند. امضاکنندگان به صورت چرخشی انتخاب می شوند و هر امضاکننده مجاز است در یک بازه زمانی خاص یک بلوک ایجاد کند. زمان ایجاد بلوک ثابت است و امضاکنندگان ملزم به ایجاد بلوک در آن چارچوب زمانی هستند.
+
+اعتبار در این زمینه یک چیز کمّی نیست بلکه اعتبار شرکتهای شناخته شدهای مانند مایکروسافت و گوگل است، از این رو روش انتخاب امضاکنندگان مورد اعتماد الگوریتمی نیست بلکه یک عمل انسانی معمولی اعتماد است که در آن یک نهاد مثلاً مایکروسافت یک شبکه خصوصی PoA را بین صدها یا هزاران استارتاپ ایجاد میکند و نقش خود را به عنوان تنها امضاکننده مورد اعتماد با امکان افزودن سایر امضاکنندگان شناخته شده مانند گوگل در آینده ایفا میکند. استارتاپها بدون شک به مایکروسافت اعتماد میکنند که همیشه صادقانه عمل کند و از شبکه استفاده کند. این امر نیاز به مشارکت در شبکههای کوچک/خصوصی مختلف را که برای اهداف مختلف ساخته شدهاند تا غیرمتمرکز بودن و کارکرد آنها را حفظ کند، همراه با نیاز به استخراجگرها که انرژی و منابع زیادی صرف میکنند، برطرف میکند. برخی از شبکه های خصوصی از استاندارد PoA مانند VeChain استفاده می کنند و برخی آن را تغییر می دهند مانند Binance که از [PoSA] استفاده می کند (https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) که یک نسخه تغییر یافته سفارشی از PoA و PoS است.
+
+فرآیند رای گیری توسط خود امضا کنندگان انجام می شود. هر امضاکننده هنگام ایجاد بلوک جدید به اضافه یا حذف یک امضاکننده در بلوک خود رأی میدهد. آرا توسط گرهها جمعآوری میشوند و امضاکنندگان بر اساس آرایی که به آستانه معین `SIGNER_LIMIT` میرسند، اضافه یا حذف میشوند.
+
+ممکن است موقعیتی وجود داشته باشد که فورک های کوچک رخ دهد. سختی یک بلوک به این بستگی دارد که آیا بلوک به نوبت امضا شده است یا خارج از نوبت. بلوک های "نوبتی" سختی 2 دارند و بلوک های "خارج از نوبت" سختی 1 دارند. در مورد فورکهای کوچک، زنجیرهای که اکثر امضاکنندگان آن بلوکها را "نوبتی" مهر و موم میکنند، بیشترین سختی را جمع میکند و برنده میشود.
+
+## بردارهای حمله {#attack-vectors}
+
+### امضاکنندگان مخرب {#malicious-signers}
+
+ممکن است یک کاربر مخرب به لیست امضاکنندگان اضافه شود، یا ممکن است کلید/ماشین امضا در خطر باشد. در چنین سناریویی، پروتکل باید بتواند از خود در برابر سازماندهی مجدد و ارسال اسپم دفاع کند. راهکار پیشنهادی این است که با توجه به لیستی از N امضاکننده مجاز، هر امضاکننده تنها میتواند 1 بلوک از هر K بلوک را ایجاد کند. این تضمین میکند که خسارت محدود شده و باقی اعتبارسنجها میتوانند کاربر مخرب را اخراج کنند.
+
+### سانسور {#censorship-attack}
+
+یکی دیگر از بردارهای جالب حمله این است که یک امضاکننده (یا گروهی از امضاکنندگان) سعی کند بلوک هایی را که به حذف آنها از لیست مجوز رأی می دهند، سانسور کند. برای حل این مشکل، فرکانس ضرب مجاز امضاکنندگان به 1 از N/2 محدود شده است. این امر تضمین می کند که امضاکنندگان مخرب باید حداقل 51٪ از حساب های امضا را کنترل کنند، در این مرحله آنها به طور مؤثر منبع جدیدی از حقیقت برای زنجیره خواهند بود.
+
+### اسپم {#spam-attack}
+
+یکی دیگر از بردارهای کوچک حمله، امضاکنندگان مخربی است که پیشنهادات رای جدید را در داخل هر بلوکی که ضرب میکنند، تزریق میکنند. از آنجا که گره ها برای ایجاد لیست واقعی امضاکنندگان مجاز باید همه آرا را جمعآوری کنند، باید تمام آرا را در طول زمان ثبت کنند. بدون محدود کردن پنجره رأیگیری، این مقدار میتواند به آرامی اما بدون محدودیت افزایش یابد. راه حل این است که یک پنجره متحرک بلوک های W ایجاد کنیم که پس از آن آرا منسوخ در نظر گرفته میشوند. _یک پنجره معقول ممکن است 1-2 ایپوک باشد._
+
+### بلوک های همزمان {#concurrent-blocks}
+
+در یک شبکه PoA، زمانی که N امضاکننده مجاز وجود دارد، هر امضاکننده مجاز به ایجاد یک بلوک از هر K بلوک است که به این معنی است که N-K+1 اعتبارسنج در هر لحظه مجاز به ایجاد بلوک هستند. برای جلوگیری از رقابت این اعتبارسنجها برای ایجاد بلوک، هر امضاکننده باید یک "جابجایی" تصادفی کوچک به زمان انتشار بلوک جدید خود اضافه کند. اگرچه این فرآیند تضمین می کند که فورکهای کوچک نادر هستند، فورکهای گاه به گاه هنوز هم می توانند اتفاق بیفتند، درست مانند شبکه اصلی. اگر مشخص شود که یک امضاکننده از قدرت خود سوء استفاده کرده و باعث ایجاد آشفتگی شده است، امضاکنندگان دیگر میتوانند او را اخراج کنند.
+
+به عنوان مثال، اگر 10 امضاکننده مجاز وجود داشته باشد و هر امضاکننده مجاز باشد از 20 بلوک، 1 بلوک ایجاد کند، در هر زمان، 11 اعتبارسنج می توانند بلوک ایجاد کنند. برای جلوگیری از رقابت آنها برای ایجاد بلوک، هر امضاکننده یک "جابجایی" تصادفی کوچک به زمانی که یک بلوک جدید را منتشر می کند اضافه می کند. این امر احتمال وقوع فورکهای کوچک را کاهش میدهد اما همچنان به فورکهای گاه به گاه مانند آنچه در شبکه اصلی اتریوم دیده میشود اجازه میدهد. اگر یک امضاکننده از صلاحیت خود سوء استفاده کرده و باعث اختلال شود، ممکن است از شبکه حذف شود.
+
+## مزایا و معایب {#pros-and-cons}
+
+| نقاط مثبت | نقاط منفی |
+| ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| مقیاس پذیرتر از مکانیسم های محبوب دیگر مانند PoS و PoW، زیرا بر اساس تعداد محدودی از امضاکنندگان بلوک است | شبکههای PoA معمولاً تعداد نسبتاً کمی گره اعتبارسنج دارند. این، شبکه PoA را متمرکزتر می کند. |
+| بلاک چین های PoA برای اجرا و نگهداری بسیار ارزان هستند | معمولاً برای یک فرد عادی تبدیل شدن به یک امضاکننده مجاز غیرقابل دسترس است، زیرا بلاک چین به نهادهایی با شهرت اثبات شده نیاز دارد. |
+| تراکنشها خیلی سریع تأیید میشوند، زیرا ممکن است به کمتر از ۱ ثانیه برسد، زیرا فقط تعداد محدودی امضاکننده برای اعتبارسنج بلوکهای جدید لازم است | امضاکنندگان مخرب می توانند دوباره سازماندهی کنند، دو برابر هزینه کنند، و تراکنش ها را در شبکه سانسور کنند. این حملات کاهش می یابد، اما همچنان ممکن است |
+
+## ادامه مطلب {#further-reading}
+
+- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique standard_
+- [مطالعه اثبات صلاحیت](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_
+- [اثبات صلاحیت چیست](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_
+- [شرح اثبات صلاحیت](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_
+- [PoA در بلاک چین](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba)
+- [شرح دسته](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d)
+- [PoA منسوخ شده، مشخصات Aura] (https://openethereum.github.io/Chain-specification)
+- [IBFT 2.0، اجرای دیگر PoA](https://besu.hyperledger.org/stable/private-networks/concepts/poa)
+
+### با توضیحات تصویری راحتترید؟ {#visual-learner}
+
+توضیح تصویری اثبات صلاحیت را تماشا کنید:
+
+
+
+## موضوعات مرتبط {#related-topics}
+
+- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
+- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
diff --git a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/index.md
index de9e87b1a7d..f031539aaee 100644
--- a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/index.md
+++ b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/index.md
@@ -2,12 +2,13 @@
title: اثبات کار (PoW)
description: توضیحی دربارهی پروتکل اجماع اثبات کار و نقشش در اتریوم.
lang: fa
-incomplete: true
---
-اتریوم همچون بیتکوین از پروتکل اجماعی به نام **[اثبات کار (PoW)](https://wikipedia.org/wiki/Proof_of_work)** استفاده میکند. این پروتکل به گرههای اتریوم اجازه میدهد که روی وضعیت تمام اطلاعات ثبتشده روی زنجیرهی بلوکی اتریوم توافق کنند و از برخی انواع حملات اقتصادی ممانعت میکند.
+شبکه اتریوم با استفاده از یک مکانیزم اجماعی که شامل **[اثبات کار (PoW)](/developers/docs/consensus-mechanisms/pow)** بود، شروع به کار کرد. این موضوع به گره های شبکه اتریوم اجازه داد روی وضعیت تمام اطلاعات ثبت شده روی زنجیره بلوکی اتریوم به توافق برسند و از انواع خاصی از حملات اقتصادی جلوگیری کنند. با این حال، اتریوم اثبات کار را در سال 2022 خاموش کرد و به جای آن شروع به استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos) کرد.
-سال آینده، اثبات کار جای خود را به **[اثبات سهام (PoS)](/developers/docs/consensus-mechanisms/pos)** خواهد داد. تغییر به اثبات سهام باعث میشود که استخراج از اتریوم رخت بربندد. [اطلاعات بیشتر در مورد ادغام](/roadmap/merge/)
+
+ در حال حاضر اثبات کار منسوخ شده است. اتریوم دیگر از اثبات کار به عنوان بخشی از مکانیزم اجماع خود استفاده نمی کند. در عوض، از اثبات سهام استفاده می کند. در مورد اثبات سهام و سهام گذاری بیشتر بخوانید.
+
## پیشنیازها {#prerequisites}
@@ -15,75 +16,71 @@ incomplete: true
## اثبات کار (PoW) چیست؟ {#what-is-pow}
-اثبات کار مکانیزمی است که اجازه میدهد شبکهی غیرمتمرکز اتریوم به اجماع برسد یا در مورد موجودی حسابها و ترتیب تراکنشها توافق کند. این کار جلوی «خرج دوباره» کوینها را میگیرد و باعث حصول اطمینان از این موضوع میشود که حمله و خرابکاری در زنجیرهی اتریوم فوقالعاده سخت است.
+اجماع ناکاموتو، که از اثبات کار استفاده می کند، مکانیزمی است که زمانی به شبکه غیرمتمرکز اتریوم اجازه می داد در مورد چیزهایی مانند موجودی حساب و ترتیب تراکنش ها به اجماع برسد (یعنی همه گرهها توافق کنند). این کار جلوی «خرج کردن دوباره» کوینهای کاربران را گرفت و باعث حصول اطمینان از این موضوع شد که حمله و خرابکاری در زنجیره اتریوم فوقالعاده سخت است. این ویژگی های امنیتی اکنون به جای استفاده از مکانیزم اجماع معروف به [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)، از اثبات سهام به دست می آیند.
## اثبات کار و استخراج {#pow-and-mining}
-اثبات کار الگوریتم پایهای است که سختی و قوانین کاری که استخراجگران باید انجام دهند را مشخص میکند. استخراج خودِ «کار» است. این همان عمل اضافه کردن بلوکهای معتبر به زنجیره است. این نکتهی مهمی است چرا که طول زنجیره کمک میکند که شبکه زنجیرهی درست اتریوم را بداند و وضعیت فعلی اتریوم را بفهمد. هر چه «کار» بیشتری انجام شود، زنجیره طولانیتر میشود و هر چه شمارهی بلوک بیشتر شود، شبکه از وضعیت فعلی مطمئنتر میشود.
+اثبات کار الگوریتمی اساسی است که دشواری و قوانین کاری که استخراجگران باید انجام دهند را در زنجیره های بلوکی اثبات کار تعیین می کند. استخراج، خودِ «کار» است. این همان عمل اضافه کردن بلوکهای معتبر به زنجیره است. این موضوع از آن جهت اهمیت دارد که طول زنجیره به شبکه کمک می کند تا از فورک صحیح زنجیره بلوکی پیروی کند. هر چه «کار» بیشتری انجام شود، زنجیره طولانیتر میشود و هر چه شماره بلوک بیشتر شود، شبکه از وضعیت فعلی مطمئنتر میشود.
[اطلاعات بیشتر دربارهی استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
-## اثبات کار اتریوم چگونه کار میکند؟ {#how-it-works}
+## اثبات کار اتریوم چگونه کار می کرد؟ {#how-it-works}
-تراکنشهای اتریوم در بلوکها پردازش میشوند. هر بلوک شامل چیزهای زیر است:
+تراکنشهای اتریوم به بلوکها پردازش میشوند. در اتریوم اثبات کار که اکنون منسوخ شده است، هر بلوک شامل موارد زیر بود:
- سختی بلوک - برای مثال: 3,324,092,183,262,715
- mixHash - برای مثال: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
- نانس (Nonce) - برای مثال: `0xd3ee432b4fb3d26b`
-این اطلاعات بلوک مستقیماً به اثبات کار مرتبط است.
+این داده بلوکی ارتباط مستقیمی با اثبات کار داشت.
### کار در اثبات کار {#the-work}
-پروتکل اثبات کار، Ethash، نیاز دارد که استخراجگران برای پیدا کردن نانس به روش آزمون و خطا به رقابت شدید بپردازند. تنها بلوک دارای نانس (Nonce) معتبر میتوانند به زنجیره اضافه شوند.
+پروتکل اثبات کار، Ethash، نیاز داشت که استخراجگران برای پیدا کردن نانس به روش آزمون و خطا به رقابت شدید بپردازند. تنها بلوک های دارای نانس (Nonce) معتبر میتوانستند به زنجیره اضافه شوند.
-استخراجگر در هنگام مسابقه برای ساخت بلوک، به طور منظم و تکراری یک مجموعهداده را، که فقط با دانلود و اجرای همهی زنجیره به دست میآید (همان طور که استخراجگر هم دانلود و اجرا میکند)، از یک تابع ریاضی عبور میدهد. این مجموعهداده برای ساختن mixHash و رسیدن به نانس (Nonce) هدف که توسط سختی بلوک مشخص میشود، استفاده میشود. بهترین راه برای انجام این کار آزمون و خطاست.
+استخراجگر در هنگام مسابقه برای ساخت بلوک، به طور منظم و تکراری یک مجموعهداده را، که فقط با دانلود و اجرای همه زنجیره به دست میآید (همان طور که استخراجگر هم دانلود و اجرا میکند)، از یک تابع ریاضی عبور میدهد. مجموعه داده ها برای ایجاد mixHash در زیر یک هدف که توسط سختی بلوک دیکته شده است، استفاده شد. بهترین راه برای انجام این کار آزمون و خطاست.
-سختی برای هش یک هدف تعیین میکند. هر چه هدف کمتر باشد، مجموعهی هشهای معتبر کوچکتر است. وقتی ساخته شد، اعتبارسنجی آن برای دیگر استخراجگران و کلاینتها بسیار ساده خواهد بود. حتی اگر یک تراکش تغییر کند، هش کاملاً متفاوت خواهد بود و سیگنال تقلب خواهد داد.
+سختی برای هش یک هدف تعیین کرد. هر چه هدف کمتر باشد، مجموعه هشهای معتبر کوچکتر است. وقتی ساخته شد، راستی آزمایی آن برای دیگر استخراجگران و کاربرها بسیار ساده بود. حتی اگر یک تراکش تغییر کند، هش کاملاً متفاوت خواهد بود و سیگنال تقلب خواهد داد.
-هش کردن باعث میشود که بسیار ساده بتوان تقلبها را کشف کرد. اما اثبات کار در مقام یک فرایند، یک بازدارندهی مهم از حملات به زنجیره هم است.
+هش کردن باعث میشود که به آسانی بتوان تقلبها را کشف کرد. اما اثبات کار در مقام یک فرایند، یک بازدارنده مهم حملات به زنجیره هم بود.
### اثبات کار و امنیت {#security}
-استخراجگران برای انجام این کار روی شبکهی اصلی اتریوم تشویق میگیرند. مشوق کمی برای زیرمجموعهای از استخراجگران که زنجیرهی خودشان را بسازند وجود دارد - که سیستم را تضعیف میکند. زنجیرههای بلوکی بر یک وضعیت بهعنوان منبع حقیقت متکی هستند. و کاربران همواره بلندترین یا «سنگینترین» زنجیره را انتخاب میکنند.
+استخراجگران برای انجام این کار روی شبکه اصلی اتریوم تشویق شدند. مشوق کمی برای زیرمجموعهای از استخراجگران که زنجیره خودشان را بسازند وجود داشت - که سیستم را تضعیف میکند. زنجیرههای بلوکی بر یک وضعیت بهعنوان منبع حقیقت متکی هستند.
-هدف اثبات کار افزایش زنجیره است. بلندترین زنجیره قابل قبولترین زنجیرهی معتبر است، چرا که بیشترین میزان کار پردازشی را داشته است. در سیستم اثبات کار اتریوم، ساخت بلوکهای جدیدی که تراکنشها را پاک کند، تراکنشهای جعلی بسازد یا یک زنجیرهی دوم را نگهداری کند، تقریباً غیرممکن است. دلیل این موضوع آن است که استخراجگر بداندیش نیاز دارد که نانس (Nonce) بلوک را همواره زودتر از هر کس دیگری پیدا کند.
+هدف اثبات کار افزایش زنجیره بود. بلندترین زنجیره قابل قبولترین زنجیره به عنوان زنجیره معتبر است، چرا که بیشترین میزان کار پردازشی برای تولید آن انجام شده بود. در سیستم اثبات کار اتریوم، ساخت بلوکهای جدیدی که تراکنشها را پاک کند، تراکنشهای جعلی بسازد یا یک زنجیره دوم را نگهداری کند، تقریباً غیرممکن بود. دلیل این موضوع آن است که استخراجگر بداندیش نیاز خواهد داشت که نانس (Nonce) بلوک را همواره زودتر از هر کس دیگر پیدا کند.
-برای این که بهطور مداوم بتوانید بلوکهای معتبر اما بداندیش بسازید نیاز دارید که بیش از 51% توان استخراج شبکه را داشته باشید تا از بقیه جلو بیفتید. شما به توان پردازشی بسیار زیادی برای انجام این میزان از «کار» نیاز دارید. و انرژی استفاده شده ممکن است از سودی که شما از این حمله به دست میآورید فراتر رود.
+استخراجگر بد اندیش برای این که بهطور مداوم بتواند بلوکهای معتبر اما بداندیش بسازد نیاز دارد بیش از 51% توان استخراج شبکه را داشته باشد تا از بقیه جلو بیفتد. این مقدار "کار" به قدرت محاسباتی بسیار گران قیمت نیاز دارد و انرژی صرف شده حتی ممکن است از سود حاصل از یک حمله بیشتر باشد.
### اقتصاد اثبات کار {#economics}
-اثبات کار همچنین مسئول صدور ارز جدید به درون سیستم و تشویق استخراجگران به انجام کار است.
+اثبات کار همچنین مسئول صدور ارز جدید به درون سیستم و تشویق استخراجگران به انجام کار بود.
-Miners who successfully create a block get rewarded with two freshly minted ETH but no longer receive all the transaction fees, as the base fee gets burned, while the tip and block reward goes to the miner. استخراجگران همچنین برای ساخت بلوکهای عمو معادل 1.75 اتر دریافت میکنند. بلوکهای عمو بلوکهای معتبری هستند که توسط یک استخراجگر عملاً همزمان با استخراجگر دیگری که بلوک را بهطور موفق استخراج کرده است ساخته میشوند. بلوکهای عمو معمولا به علت تأخیر شبکه رخ میدهند.
+از زمان [ارتقا Constantinopld](/history/#constantinople)، استخراج گرانی که با موفقیت بلوک میساختند پاداشی برابر با دو اتر و بخشی از کارمزد تراکنش ها دریافت میکردند. بابت ساخت بلوک های عمو همچنین ۱٫۷۵ اتر پرداخت میشود. بلوک های عمو، بلوک های معتبری بودند که یک استخراجگر همزمان با اسخراجگر دیگر آن را به موازات زنجیره ابتدایی ساخته است، که در نهایت با این تصمیم که روی کدام بلوک زنجیره ادامه پیدا میکند مشخص میشوند. بلوکهای عمو معمولا به علت تأخیر شبکه رخ میدادند.
## قطعیت {#finality}
یک تراکنش روی اتریوم زمانی «قطعیت» دارد که عضوی از بلوکی باشد که نتواند عوض شود.
-از آنجا که استخراجگران به شکل غیر متمرکز کار میکنند دو بلوک معتبر نمیتوانند در یک زمان استخراج شوند. این کار یک فورک موقت ایجاد میکند. در نهایت، یکی از این زنجیرهها، پس از آنکه بلوکی متعاقباً استخراج شده و به آن اضافه میشود و در نتیجه بلندتر میشود، زنجیرهی پذیرفتهشده خواهد شد.
+از آنجا که استخراجگران به شکل غیر متمرکز کار کرده اند، دو بلوک معتبر میتوانند در یک زمان استخراج شوند. این کار یک فورک موقت ایجاد میکند. در نهایت، یکی از این زنجیرهها، پس از آنکه بلوک های بعدی استخراج شده به آن اضافه شد و در نتیجه بلندتر شد، زنجیره پذیرفتهشده خواهد شد.
-برای پیچیدهتر کردن موضوع، تراکنشهایی که در فورک موقتی رد شدهاند ممکن است در زنجیرهی پذیرفتهشده وجود داشته باشند. این به این معنا است که شرایط میتواند معکوس شود. پس قطعیت به زمانی گفته میشود که یک تراکنش غیرقابل معکوس شدن باشد. برای اتریوم، زمان پیشنهاد شده شش بلوک یا کمی بیشتر از 1 دقیقه است. بعد از شش بلوک با اعتماد نسبی میتوان گفت که تراکنش موفقیتآمیز بوده است. شما میتوانید برای اطمینان بیشتر زمان بیشتری منتظر بمانید.
-
-هنگام ساخت برنامههای غیرمتمرکز قطعیت چیزی است که باید در ذهن داشت. اشتباه نشان دادن اطلاعات تراکنش میتواند تجربهی کاربری بسیار ضیعفی باشد، بهویژه اگر ارزش آن تراکنش زیاد باشد.
-
-به یاد داشته باشید که این موضوع زمان شامل زمانی که تراکنش منتظر برداشته شدن توسط یک استخراجگر است نمیشود.
+برای پیچیدهتر کردن بیشتر موضوع، تراکنشهایی که در فورک موقت رد شدهاند ممکن است در زنجیره پذیرفتهشده وجود نداشته باشند. این به این معنا است که شرایط میتواند معکوس شود. پس قطعیت به زمانی گفته میشود که یک تراکنش غیرقابل معکوس شدن باشد. زمانی که اتریوم از مکانیزم اجماع اثبات-کار استفاده میکرد، هر چه تعداد بلوک بیشتری روی بلوک `N` استخراج می شد، اطمینان بیشتری حاصل میشد که تراکنش های بلوک`N` موفق بوده اند و بازگردانده نمی شوند. حالا، با اثبات سهم، نهایی شدن، یک دارایی صریح بلوک است تا احتمالی.
## استفاده از انرژی اثبات کار {#energy}
-یکی از بزرگترین انتقادها به اثبات کار، میزان مصرف انرژی مورد نیاز برای ایمن نگه داشتن شبکه است. برای حفظ امنیت و غیر متمرکز بودن، اتریوم روی اثبات کار سالانه 73.2 تراوات ساعت انرژی مصرف میکند که به اندازهی یک کشوری با ابعاد متوسط همانند اتریش است.
+یکی از بزرگترین انتقادها به اثبات کار، میزان مصرف انرژی مورد نیاز برای ایمن نگه داشتن شبکه است. برای حفظ امینت و عدم تمرکز شبکه، اتریوم با اثبات کار انرژی زیادی صرف میکرد. پیش از گذار به اثبات سهام، استخراج گران اتریوم رو هم دیگر حدود ۷۰ تراوات ساعت برق سالانه مصرف میکردند (حدودا برابر با مصرف برق جمهوری چک طبق امار[digieconomist](https://digiconomist.net/)در ۱۸ جولای ۲۰۲۲).
## نقاط مثبت و منفی {#pros-and-cons}
| نقاط مثبت | نقاط منفی |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| اثبات کار خنثی است. شما برای شروع و گرفتن پاداش بلوکها و حرکت از 0 اتر به موجودی مثبت، نیازی به اتر ندارید. با [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)، شما برای شروع نیاز به اتر دارید. | اثبات کار به حدی انرژی مصرف میکند که برای محیط زیست بد است. |
-| اثبات کار یک مکانیزم اجماع آزمودهشده است که بیتکوین و اتریوم را برای سالها ایمن و غیرمتمرکز نگه داشته است. | اگر میخواهید استخراج کنید، نیاز به دستگاههای مخصوصی دارید که برای شروع سرمایهگذاری گرانی است. |
+| اثبات کار یک مکانیزم اجماع آزمودهشده است که بیتکوین و اتریوم را برای سالها ایمن و غیرمتمرکز نگه داشته است. | اگر میخواهید استخراج کنید، نیاز به دستگاههای مخصوصی دارید که برای شروع، سرمایهگذاری گرانی است. |
| در مقایسه با اثبات سهام، پیادهسازی راحتتری دارد. | با توجه به پردازش موردنیاز روزافزون، استخرهای استخراج احتمالاً تبدیل به غولهای بازی استخراج میشوند و این به ریسک متمرکز شدن و عدم امنیت منجر میشود. |
## در مقایسه با اثبات سهام {#compared-to-pos}
-در سطح بالا، اثبات سهام همان هدفی را دارد که اثبات کار دارد: کمک به شبکهی غیرمتمرکز برای رسیدن به اجماع بهطور امن. اما تفاوتهایی در فرایند و شمایل دارد:
+در سطح بالا، اثبات سهام همان هدفی را دارد که اثبات کار دارد: کمک به شبکه غیرمتمرکز برای رسیدن به اجماع بهطور امن. اما تفاوتهایی در فرایند و پرسنل دارد:
- اثبات سهام بهجای توان پردازشی به اتر سهامگذاری شده اهمیت میدهد.
- اثبات سهام استخراجگرها را با اعتبارسنجها جایگزین میکند. اعتبارسنجها اتر خود را سهامگذاری میکنند تا توانایی ساختن بلوک جدید را فعال کنند.
@@ -109,3 +106,4 @@ Miners who successfully create a block get rewarded with two freshly minted ETH
- [استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
+- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/index.md
index e205f6590e0..501b8ba675c 100644
--- a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/index.md
+++ b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/index.md
@@ -1,71 +1,78 @@
---
title: استخراج
-description: توضیحی در مورد نحوه کار استخراج در اتریوم و اینکه چگونه اتریوم را امن و غیرمتمرکز نگه میدارد.
+description: توضیحی درباره نحوه کار استخراج روی اتریوم.
lang: fa
-incomplete: true
---
+
+اثبات-کار دیگر مکانیزم اجماع اتریوم نیست، و در نتیجه استخراج اتریوم متوفف شده است. در عوض، اتریوم توسط اعتبارسنجهایی که اتریوم را سهام گذاری میکنند، ایمن میشود. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. درباره ادغام، اثبات سهام و سهامگذاری بیشتر بخوانید. این صفحه تنها برای علاقمندان به تاریخچه پروژه است.
+
+
## پیشنیازها {#prerequisites}
برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/) و [اثبات کار](/developers/docs/consensus-mechanisms/pow/) را مطالعه کنید.
## استخراج اتریوم چیست؟ {#what-is-ethereum-mining}
-استخراج فرhیند ایجاد بلوکی از تراکنشها برای اضافه شدن به زنجیرهی بلوکی اتریوم است.
+استخراج، فرآیند ایجاد بلوکی از تراکنش ها است که در معماری اثبات کار اتریوم که اکنون منسوخ شده است، به زنجیره بلوکی اتریوم اضافه میشود.
-در حال حاضر اتریوم همانند بیتکوین از مکانیزم اجماع [اثبات کار (PoW)](/developers/docs/consensus-mechanisms/pow/) استفاده میکند. اسخراج رگ حیات اثبات کار است. استخراجکنندگان اتریوم - رایانههایی که نرمافزار را اجرا میکنند - از زمان و قدرت محاسباتی خود برای پردازش تراکنشها و تولید بلوکها استفاده میکنند.
+کلمه «استخراج» ریشه در قیاس رمزارزها با طلا دارد. طلا یا فلزات گرانبها کمیاب هستند. توکنهای دیجیتال هم چنین هستند، تنها راه افزایش حجم کل در یک سیستم اثبات کار، استخراج است. در اثبات کار اتریوم، تنها روش صدور از طریق استخراج بود. با این حال، بر خلاف طلا یا فلزات گران بها، استخراج اتریوم راهی برای ایمن کردن شبکه از طریق ساختن، تأیید کردن، منتشر کردن و پخش کردن بلوکها در زنجیره بلوکی نیز بود.
-
- اثبات سهام در سال آینده جایگزین استخراج و اثبات کار خواهد شد. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. اطلاعات بیشتر در مورد سهامگذاری
-
+استخراج اتر = ایمنسازی شبکه
+
+استخراج رگ حیاتی هر زنجیره بلوکی اثبات کار است. استخراجکنندگان اتریوم - رایانههایی که نرمافزار را اجرا میکنند - از زمان و قدرت محاسباتی خود برای پردازش تراکنشها و تولید بلوکها پیش از انتقال به اثبات سهام استفاده میکردند.
## چرا استخراجکنندگان وجود دارند؟ {#why-do-miners-exist}
-در سیستمهای غیرمتمرکز مانند اتریوم، باید اطمینان حاصل کنیم که همه در مورد ترتیب تراکنشها توافق دارند. استخراجکنندگان با حل پازلهای محاسباتی دشوار برای تولید بلوکها به این امر کمک میکنند و شبکه را از حملات ایمن نگه میدارند.
+در سیستمهای غیرمتمرکز مانند اتریوم، باید اطمینان حاصل کنیم که همه در مورد ترتیب تراکنشها توافق دارند. استخراجکنندگان با حل پازلهای محاسباتی دشوار برای تولید بلوکها به این امر کمک میکردند و شبکه را در مقابل حملات ایمن نگه میداشتند.
[اطلاعات بیشتر در مورد اثبات کار](/developers/docs/consensus-mechanisms/pow/)
-## چه کسی میتواند در اتریوم استخراجکننده شود؟ {#who-can-become-a-miner}
-
-از نظر فنی، هر کسی میتواند با استفاده از رایانه خود در شبکه اتریوم استخراج کند. با این حال، همه نمیتوانند اتر (ETH) را به طور سودآور استخراج کنند. در بیشتر موارد، استخراجکنندگان برای سودآوری باید سختافزار کامپیوتری اختصاصی خریداری کنند. درست است که هر کس میتواند نرمافزار استخراج را بر روی کامپیوتر خود اجرا کند، اما بعید است که یک کامپیوتر متوسط به اندازهی کافی پاداش برای پوشش هزینههای مرتبط با استخراج را کسب کند.
+هر کس قبلا می توانست با استفاده از کامپیوتر خود در شبکه اتریوم استخراج کند. با این حال، همه نمیتوانستند اتر (ETH) را بهطور سودآور استخراج کنند. در بیشتر موارد، ماینرها مجبور به خرید سختافزار کامپیوتری اختصاصی و دسترسی به منابع انرژی ارزان قیمت بودند. بعید به نظر می رسید که یک کامپیوتر معمولی به اندازه کافی پاداش بلوک دریافت کند تا هزینه های مربوط به استخراج را پوشش دهد.
### هزینهی استخراج {#cost-of-mining}
- هزینههای بالقوهی سختافزاری لازم جهت ساخت و نگهداری ریگ استخراج
- هزینهی برق لازم برای تأمین انرژی ریگ استخراج
-- اگر در یک استخر استخراج میکنید، استخرهای استخراج معمولاً یک درصد هزینهی ثابت از هر بلوک تولیدشده توسط استخر را دریافت میکنند
+- اگر در یک استخر استخراج میکردید، این استخرها معمولاً درصدی هزینه ثابت از هر بلوک تولیدشده توسط استخر را دریافت میکردند
- هزینهی احتمالی تجهیزات برای پشتیبانی از ریگ استخراج (تهویه، نظارت بر انرژی، سیمکشی برق و غیره)
برای بررسی بیشتر سودآوری استخراج، از یک ماشینحساب استخراج مانند آنچه که [Etherscan](https://etherscan.io/ether-mining-calculator) ارائه میدهد، استفاده کنید.
-## تراکنشهای اتریوم چگونه استخراج میشوند {#how-ethereum-transactions-are-mined}
+## تراکنشهای اتریوم چگونه استخراج میشدند {#how-ethereum-transactions-were-mined}
+
+در ادامه مروری بر نحوه استخراج تراکنش ها در اثبات کار اتریوم ارائه میشود. توصیف مشابهی از این فرآیند برای اثبات سهام اتریوم را می توانید در [اینجا](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) بیابید.
1. یک کاربر یک درخواست [تراکنش](/developers/docs/transactions/) را با کلید خصوصی یک [حساب](/developers/docs/accounts/) مینویسد و امضا میکند.
2. کاربر درخواست تراکنش را از یک [گره](/developers/docs/nodes-and-clients/) به کل شبکه اتریوم ارسال میکند.
3. پس از شنیدن درخواست تراکنش جدید، هر گره در شبکه اتریوم درخواست را به استخر حافظهای محلی خود اضافه میکند. استخر حافظه لیستی است از تمام درخواستهای تراکنش که در مورد آنها شنیده است و هنوز به زنجیرهی بلوکی در یک بلوک وابسته نشده است.
-4. در برخی مواقع، یک گره استخراج چند ده یا صد درخواست تراکنش را در یک [بلوک](/developers/docs/blocks/) بالقوه تجمیع میکند، به گونهای که [کارمزد تراکنش](/developers/docs/gas/) کسبشدهی آنها به حداکثر میرساند، در حالی که همچنان زیر حد گاز بلوک باقی میمانند. سپس گرهی استخراج:
+4. در برخی مواقع، یک گره استخراج چند ده یا صد درخواست تراکنش را در یک [بلوک](/developers/docs/blocks/) بالقوه تجمیع میکند، به گونهای که [کارمزد تراکنش](/developers/docs/gas/) کسبشدهی آنها را به حداکثر میرساند، در حالی که همچنان زیر حد گاز بلوک باقی میمانند. سپس گرهی استخراج:
1. اعتبار هر درخواست تراکنش را تأیید میکند (یعنی هیچکس سعی نمیکند اتر را از حسابی که برای آن امضا تولید نکرده است منتقل کند، درخواست بدفرم نشده است و غیره)، و سپس کد درخواست را اجرا میکند و حالت نسخهی EVM محلی آن را تغییر میدهد. استخراجگر کارمزد تراکنش را برای هر درخواست تراکنش به حساب خود واریز میکند.
2. زمانی که تمام درخواستهای تراکنش در بلوک تأیید شده و در نسخه EVM محلی اجرا شد، فرایند تولید «گواهی مشروعیت» اثبات کار برای بلوک بالقوه را آغاز میکند.
5. در نهایت، یک استخراجگر تولید یک گواهی را برای بلوکی که شامل درخواست تراکنش خاص ما میشود، به پایان میرساند. سپس استخراجگر بلوک تکمیلشده را که شامل گواهینامه و چک تجمیع وضعیت جدید EVM ادعا شده است ارسال میکند.
6. سایر گرهها در مورد بلوک جدید میشنوند. آنها گواهی را اعتبارسنجی میکنند، همه تراکنشهای روی بلوک را خودشان اجرا میکنند (از جمله تراکنشی که در ابتدا توسط کاربر ما ارسال شد)، و اعتبارسنجی میکنند که بررسی تجمیع وضعیت جدید ماشین مجازی اتریوم (EVM) بعد از اجرای همه تراکنشها، با بررسی تجمیع وضعیت ادعا شده توسط بلوک استخراجگر مطابقت داشته باشد. تنها در این صورت است که این گرهها این بلوک را به انتهای زنجیرهی بلوک خود اضافه میکنند و حالت جدید ماشین مجازی اتریوم (EVM) را بهعنوان حالت متعارف میپذیرند.
7. هر گره تمام تراکنشهای موجود در بلوک جدید را از استخر حافظهی محلی درخواستهای تراکنش انجامنشدهی خود حذف میکند.
-8. گرههای جدیدی که به شبکه میپیوندند همه بلوکها را به ترتیب دانلود میکنند، از جمله بلوکی که شامل تراکنش مورد علاقه ما است. آنها یک کپی محلی از ماشین مجازی اتریوم (EVM) محلی را راهاندازی میکنند (که بهعنوان یک ماشین مجازی اتریوم حالت خالی شروع میشود)، و سپس فرایند اجرای هر تراکنش در هر بلوک را در بالای کپی ماشین مجازی اتریوم محلی خود انجام میدهند، و بررسی چک تجمیع را در هر بلوک در طول مسیر تأیید میکنند.
+8. گرههای جدیدی که به شبکه میپیوندند همه بلوکها را به ترتیب دانلود میکنند، از جمله بلوکی که شامل تراکنش مورد علاقه ما است. آنها یک کپی EVM محلی را راه اندازی می کنند (که به عنوان یک EVM حالت خالی شروع می شود)، و سپس فرآیند اجرای هر تراکنش در هر بلوک را در بالای کپی EVM محلی خود انجام می دهند، و بررسی تجمیع وضعیت را در هر بلوک در طول مسیر تأیید می کنند.
+
+هر تراکنش یک بار استخراج میشود (در یک بلوک جدید گنجانده میشود و برای اولین بار منتشر میشود) اما توسط هر شرکتکننده در فرایند پیشرفت حالت متعارف EVM اجرا و تأیید میشود. این نکته یکی از شعارهای اصلی زنجیره بلوکی را خاطرنشان میکند: **اعتماد نکنید، تأیید کنید**.
+
+## بلوک های (عمو) Ommer {#ommer-blocks}
+
+در استخراج بلوک ها در اثبات-کار احتمال دخیل بود، که یعنی به دلیل تاخیر در شبکه احتمال انتشار دو بلوک معتبر همزمان وجود داشت. در این حالت، پروتکل باید طولانیترین زنجیره (و بنابراین زنجیره «معتبر») را تعیین میکرد و همزمان با اعطای بلوک معتبر اضافه نشده، عدالت را در میان استخراجگرها تضمین میکرد. این امر تمرکززدایی بیشتر شبکه را تشویق کرد زیرا ماینرهای کوچکتر، که ممکن است با تأخیر بیشتری مواجه شوند، همچنان میتوانند از طریق پاداشهای بلوک [ommer](/glossary/#ommer) بازدهی ایجاد کنند.
-هر تراکنش یک بار استخراج میشود (در یک بلوک جدید گنجانده میشود و برای اولین بار منتشر میشود) اما توسط هر شرکتکننده در فرایند پیشرفت حالت EVM متعارف اجرا و تأیید میشود. این نکته یکی از سخنان تکراری اصلی زنجیرهی بلوکی را برجسته میکند: **اعتماد نکنید، تأیید کنید**.
+اصطلاح "ommer" اصطلاح ترجیحی از نظر جنسیتی خنثی برای سیبلینگ و بلوک والد است، اما گاهی اوقات به آن عمو (uncle) نیز گفته میشود. **پس از گذر اتریوم به اثبات-کار،هیچ بلوک عمویی استخراج نشده**زیرا تنها یک پیشنهاد دهنده در هر اسلات انتخاب میشود. شما میتوانید این تغییر را در[چارت تاریخی](https://ycharts.com/indicators/ethereum_uncle_rate) بلوک های عموی استخراج شده مشاهده کنید.
## یک نسخهی آزمایشی تصویری {#a-visual-demo}
-آستین را مشاهده کنید که در راه استخراج و اثبات کار زنجیرهی بلوکی شما را راهنمایی میکند.
+آستین را تماشا کنید که شما را در راه استخراج و اثبات کار زنجیره بلوکی راهنمایی میکند.
-## بیشتر بخوانید {#further-reading}
+## الگوریتم استخراج {#mining-algorithm}
-## ابزارهای مرتبط {#related-tools}
+شبکه اصلی اتریوم تنها از یک الگوریتم استخراج، یعنی -['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/) استفاده کرده است. Ethash جانشین یک الگوریتم تحقیق و توسعه اصلی شناخته شده به عنوان ["دگر هاشیموتو (Dagger-Hashimoto)"](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) بود.
-- [برترین استخراجکنندگان اتریوم](https://etherscan.io/stat/miner?range=7&blocktype=blocks)
-- [ماشینحساب استخراج Etherscan](https://etherscan.io/ether-mining-calculator)
-- [Minerstat mining calculator](https://minerstat.com/coin/ETH)
+[اطلاعات بیشتر در مورد الگوریتم های استخراج](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/).
## موضوعات مرتبط {#related-topics}
diff --git a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
new file mode 100644
index 00000000000..3b3f45e7086
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
@@ -0,0 +1,334 @@
+---
+title: Dagger-Hashamoto
+description: نگاهی دقیق به الگوریتم Dagger-Hashimoto.
+lang: fa
+---
+
+Dagger-Hashimoto زیرساخت و مشخصات اولیه تحقیقاتی برای الگوریتم استخراج اتریوم بود. Dagger-Hashimoto به [Ethash](#ethash) تغییر نام داده شد. استخراج به طور کامل در [ادغام](/roadmap/merge/) در 15 سپتامبر 2022 خاموش شد. از آن زمان، اتریوم با استفاده از مکانیزم [اثبات سهام](/developers/docs/consensus-mechanisms/pos) ایمن شده است. این صفحه برای رجوع تاریخی است - اطلاعات اینجا دیگر مرتبط به اتریوم پس از ادغام نیست.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای فهم بهتر این مقاله، پیشنهاد می کنیم ابتدا [اجماع اثبات کار](/developers/docs/consensus-mechanisms/pow)،[استخراج](/developers/docs/consensus-mechanisms/pow/mining) و [الگوریتم استخراج](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) را مطالعه کنید.
+
+## Dagger-Hashamoto {#dagger-hashimoto}
+
+Dagger-Hashamato دو هدف را برآورده می کند:
+
+1. **مقاومت در برابر اسیک**: مزیت حاصل از ایجاد سخت افزار تخصصی برای الگوریتم باید تا حد امکان کم باشد
+2. **تأیید پذیری کاربر سبک**: یک بلوک باید به طور مؤثر توسط کاربر سبک قابل تأیید باشد.
+
+با یک تغییر اضافی، همچنین مشخص می کنیم که چگونه می توان یک هدف سوم را در صورت تمایل برآورده کرد، هر چند با بهای افزایش پیچیدگی همراه باشد:
+
+**ذخیرهسازی زنجیره کامل**: استخراج باید به ذخیرهسازی حالت بلاک چین کامل نیاز داشته باشد (به دلیل ساختار نامنظم درخت حالت اتریوم، پیشبینی میکنیم برخی هرسها امکانپذیر باشد، به ویژه در بعضی قراردادهای پرمصرف، ولی می خواهیم این را به حداقل برسانیم).
+
+## تولید DAG {#dag-generation}
+
+کد الگوریتم در Python در زیر تعریف خواهد شد. ابتدا، `encode_int` را برای مارشال کردن اینت های بدون علامت با دقت مشخص به سطرها می دهیم. معکوس آن نیز داده می شود:
+
+```python
+NUM_BITS = 512
+
+def encode_int(x):
+ "Encode an integer x as a string of 64 characters using a big-endian scheme"
+ o = ''
+ for _ in range(NUM_BITS / 8):
+ o = chr(x % 256) + o
+ x //= 256
+ return o
+
+def decode_int(s):
+ "Unencode an integer x from a string using a big-endian scheme"
+ x = 0
+ for c in s:
+ x *= 256
+ x += ord(c)
+ return x
+```
+
+در مرحله بعد فرض می کنیم `sha3` تابعی است که یک عدد صحیح می گیرد و یک عدد صحیح را خروجی می دهد و `dbl_sha3` یک تابع double-sha3 است. اگر این کد مرجع را به یک اجرا تبدیل کنید:
+
+```python
+from pyethereum import utils
+def sha3(x):
+ if isinstance(x, (int, long)):
+ x = encode_int(x)
+ return decode_int(utils.sha3(x))
+
+def dbl_sha3(x):
+ if isinstance(x, (int, long)):
+ x = encode_int(x)
+ return decode_int(utils.sha3(utils.sha3(x)))
+```
+
+### پارامترها {#parameters}
+
+پارامتر هایی که برای الگوریتم مورد استفاده قرار می گیرند:
+
+```python
+SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512
+
+params = {
+ "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536
+ "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536
+ # with epochtime=20000 gives 882 MB growth per year
+ "cache_size": 2500, # Size of the light client's cache (can be chosen by light
+ # client; not part of the algo spec)
+ "diff": 2**14, # Difficulty (adjusted during block evaluation)
+ "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated)
+ "k": 1, # Number of parents of a node
+ "w": w, # Used for modular exponentiation hashing
+ "accesses": 200, # Number of dataset accesses during hashimoto
+ "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation
+}
+```
+
+`P` در این حالت یک عدد اول انتخاب شده است، طوری که `log₂(P)` فقط کمی کمتر از 512 است، که متناسب با 512 بیتی است که برای نشان دادن اعدادمان استفاده کردهایم. توجه داشته باشید که تنها نیمه دوم DAG در واقع باید ذخیره شود، بنابراین نیاز واقعی RAM از 1 گیگابایت شروع می شود و 441 مگابایت در سال افزایش می یابد.
+
+### ساختار نمودار Dagger {#dagger-graph-building}
+
+ساختار اولیه نمودار Dagger به صورت زیر تعریف می شود:
+
+```python
+def produce_dag(params, seed, length):
+ P = params["P"]
+ picker = init = pow(sha3(seed), params["w"], P)
+ o = [init]
+ for i in range(1, length):
+ x = picker = (picker * init) % P
+ for _ in range(params["k"]):
+ x ^= o[x % i]
+ o.append(pow(x, params["w"], P))
+ return o
+```
+
+اساساً، از یک نمودار به عنوان یک گره منفرد، `sha3(seed)` شروع می شود، و از آنجا شروع به اضافه کردن متوالی گره های دیگر بر اساس گره های تصادفی قبلی می کند. هنگامی که یک گره جدید ایجاد می شود، یک توان مدولار از بذر محاسبه می شود تا به طور تصادفی برخی از شاخص های کمتر از `i` (با استفاده از `x % i` بالا) انتخاب شود، و مقادیر گرهها در آن شاخصها در یک محاسبه برای ایجاد یک مقدار جدید برای `x` استفاده میشوند، که سپس به یک تابع کوچک اثبات کار (بر اساس XOR) وارد میشود تا در نهایت مقدار نمودار در فهرست `i` را ایجاد کند. منطق پشت این طراحی خاص، اجبار به دسترسی متوالی به DAG است. تا زمانی که مقدار فعلی مشخص نشود، مقدار بعدی DAG قابل دسترسی نیست. در نهایت، توان مدولار نتیجه را بیشتر هش می کند.
+
+این الگوریتم بر چندین نتیجه از نظریه اعداد متکی است. برای ادامه بحث به پیوست زیر مراجعه کنید.
+
+## ارزیابی کاربر سبک {#light-client-evaluation}
+
+ساختار نمودار بالا تمایل دارد به هر گره در نمودار اجازه دهد با محاسبه زیردرختی از تعداد کمی گره و نیاز به مقدار کمی حافظه کمکی، بازسازی شود. توجه داشته باشید که با k=1، زیردرخت فقط زنجیره ای از مقادیر است که تا اولین عنصر در DAG بالا می رود.
+
+تابع محاسبات کاربر سبک برای DAG به صورت زیر عمل می کند:
+
+```python
+def quick_calc(params, seed, p):
+ w, P = params["w"], params["P"]
+ cache = {}
+
+ def quick_calc_cached(p):
+ if p in cache:
+ pass
+ elif p == 0:
+ cache[p] = pow(sha3(seed), w, P)
+ else:
+ x = pow(sha3(seed), (p + 1) * w, P)
+ for _ in range(params["k"]):
+ x ^= quick_calc_cached(x % p)
+ cache[p] = pow(x, w, P)
+ return cache[p]
+
+ return quick_calc_cached(p)
+```
+
+اساساً، این به سادگی بازنویسی الگوریتم فوق است که حلقه محاسبه مقادیر کل DAG را حذف می کند و جستجوی گره قبلی را با یک فراخوان بازگشتی یا جستجوی حافظه پنهان جایگزین می کند. توجه داشته باشید که برای `k=1` حافظه نهان ضروری نیست، اگرچه یک بهینه سازی بیشتر در واقع چند هزار مقدار اول DAG را از قبل محاسبه می کند و آن را به عنوان یک حافظه نهان ثابت برای محاسبات نگه می دارد. برای اجرای کد این مورد به پیوست مراجعه کنید.
+
+## بافر دوگانه DAGها {#double-buffer}
+
+در یک کاربر کامل، یک [_بافر دوگانه_](https://wikipedia.org/wiki/Multiple_buffering) از 2 DAG تولید شده توسط فرمول بالا استفاده می شود. ایده این است که DAG ها در هر تعداد `زمان ایپوک` بلوک، مطابق با پارامترهای بالا تولید می شوند. به جای اینکه مشتری از آخرین DAG تولید شده استفاده کند، از DAG قبلی استفاده می کند. مزیت این کار این است که اجازه می دهد DAG ها در طول زمان بدون نیاز به ترکیب مرحله ای جایگزین شوند که در آن استخراجگرها باید به طور ناگهانی همه داده ها را دوباره محاسبه کنند. در غیر این صورت، پتانسیل کاهش ناگهانی و موقتی در پردازش زنجیره ای در فواصل زمانی منظم و افزایش چشمگیر تمرکز وجود دارد. بنابراین 51 درصد خطر حمله ظرف چند دقیقه قبل از محاسبه مجدد همه داده ها، وجود دارد.
+
+الگوریتم مورد استفاده برای تولید مجموعه ای از DAGهای مورد استفاده برای محاسبه کار برای یک بلوک به شرح زیر است:
+
+```python
+def get_prevhash(n):
+ from pyethereum.blocks import GENESIS_PREVHASH
+ from pyethereum import chain_manager
+ if n <= 0:
+ return hash_to_int(GENESIS_PREVHASH)
+ else:
+ prevhash = chain_manager.index.get_block_by_number(n - 1)
+ return decode_int(prevhash)
+
+def get_seedset(params, block):
+ seedset = {}
+ seedset["back_number"] = block.number - (block.number % params["epochtime"])
+ seedset["back_hash"] = get_prevhash(seedset["back_number"])
+ seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0)
+ seedset["front_hash"] = get_prevhash(seedset["front_number"])
+ return seedset
+
+def get_dagsize(params, block):
+ return params["n"] + (block.number // params["epochtime"]) * params["n_inc"]
+
+def get_daggerset(params, block):
+ dagsz = get_dagsize(params, block)
+ seedset = get_seedset(params, block)
+ if seedset["front_hash"] <= 0:
+ # No back buffer is possible, just make front buffer
+ return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
+ "block_number": 0}}
+ else:
+ return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
+ "block_number": seedset["front_number"]},
+ "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz),
+ "block_number": seedset["back_number"]}}
+```
+
+## هاشیموتو {#hashimoto}
+
+ایده پشت هاشیموتو اصلی استفاده از بلاک چین به عنوان مجموعه داده، انجام محاسباتی است که N شاخص را از زنجیره بلوکی انتخاب میکند، تراکنشها را در آن شاخصها جمعآوری میکند، XOR این دادهها را انجام میدهد و هشِ نتیجه را برمیگرداند. الگوریتم اصلی Thaddeus Dryja که برای سازگاری به Python ترجمه شده است به شرح زیر است:
+
+```python
+def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce):
+ hash_output_A = sha256(prev_hash + merkle_root + nonce)
+ txid_mix = 0
+ for i in range(64):
+ shifted_A = hash_output_A >> i
+ transaction = shifted_A % len(list_of_transactions)
+ txid_mix ^= list_of_transactions[transaction] << i
+ return txid_mix ^ (nonce << 192)
+```
+
+متأسفانه، در حالی که هاشیموتو برای RAM سخت در نظر گرفته می شود، بر محاسبات 256 بیتی متکی است که سربار محاسباتی قابل توجهی دارد. با این حال، Dagger-Hashimoto هنگام نمایه سازی مجموعه داده های خود برای رسیدگی به این مشکل، تنها از حداقل 64 بیت استفاده می کند.
+
+```python
+def hashimoto(dag, dagsize, params, header, nonce):
+ m = dagsize / 2
+ mix = sha3(encode_int(nonce) + header)
+ for _ in range(params["accesses"]):
+ mix ^= dag[m + (mix % 2**64) % m]
+ return dbl_sha3(mix)
+```
+
+استفاده از SHA3 مضاعف امکان پیشآزمایی فوری و بدون داده را فراهم میکند و فقط تأیید میکند که یک مقدار متوسط صحیح ارائه شده است. این لایه بیرونی اثبات کار بسیار ASIC-پسند و نسبتاً ضعیف است، اما وجود دارد تا DDoS را حتی دشوارتر کند زیرا آن مقدار کم کار باید انجام شود تا بلوکی تولید شود که فوراً رد نشود. این نسخه کاربر سبک است:
+
+```python
+def quick_hashimoto(seed, dagsize, params, header, nonce):
+ m = dagsize // 2
+ mix = sha3(nonce + header)
+ for _ in range(params["accesses"]):
+ mix ^= quick_calc(params, seed, m + (mix % 2**64) % m)
+ return dbl_sha3(mix)
+```
+
+## استخراج و راستی آزمایی {#mining-and-verifying}
+
+حال، برای االگوریتم استخراج، همه را در کنار یکدیگر قرار می دهیم:
+
+```python
+def mine(daggerset, params, block):
+ from random import randint
+ nonce = randint(0, 2**64)
+ while 1:
+ result = hashimoto(daggerset, get_dagsize(params, block),
+ params, decode_int(block.prevhash), nonce)
+ if result * params["diff"] < 2**256:
+ break
+ nonce += 1
+ if nonce >= 2**64:
+ nonce = 0
+ return nonce
+```
+
+این الگوریتم تایید است:
+
+```python
+def verify(daggerset, params, block, nonce):
+ result = hashimoto(daggerset, get_dagsize(params, block),
+ params, decode_int(block.prevhash), nonce)
+ return result * params["diff"] < 2**256
+```
+
+راستی آزمایی کاربر سبک:
+
+```python
+def light_verify(params, header, nonce):
+ seedset = get_seedset(params, block)
+ result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block),
+ params, decode_int(block.prevhash), nonce)
+ return result * params["diff"] < 2**256
+```
+
+همچنین، توجه داشته باشید که Dagger-Hashimoto الزامات اضافی را بر روی سر بلوک اعمال می کند:
+
+- برای اینکه تأیید دو لایه کار کند، یک سر بلوک باید هم مقدار نانس و هم مقدار میانی pre-sha3 را داشته باشد
+- در جایی، یک سر بلوک باید sha3 مجموعه seedset فعلی را ذخیره کند
+
+## اطلاعات بیشتر {#further-reading}
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
+
+## پیوست {#appendix}
+
+همانطور که در بالا ذکر شد، RNG مورد استفاده برای تولید DAG به برخی نتایج نظریه اعداد متکی است. اول، ما اطمینان می دهیم که Lehmer RNG که مبنایی برای متغیر `picker` است دارای یک دوره گسترده است. دوم، نشان میدهیم که `pow(x,3,P)` `x` را به `1` یا `P-10 نگاشت نمیکند. > x ∈ [2,P-2]` برای شروع ارائه شده است. در نهایت، نشان میدهیم که `pow(x,3,P)` وقتی به عنوان یک تابع هش در نظر گرفته میشود، نرخ برخورد پایینی دارد.
+
+### مولد اعداد تصادفی Lehmer {#lehmer-random-number}
+
+در حالی که تابع `produce_dag` نیازی به تولید اعداد تصادفی بی طرفانه ندارد، یک تهدید بالقوه این است که `seed**i % P` فقط تعداد انگشت شماری از مقادیر را دریافت کند. این می تواند مزیتی برای استخراجگرها ایجاد کند که الگو را نسبت به کسانی که این کار را نمی شناسند، تشخیص دهند.
+
+برای جلوگیری از این امر، از یک نتیجه نظریه اعداد استفاده می شود. [_Safe Prime_](https://en.wikipedia.org/wiki/Safe_prime) به صورت اول `P` تعریف شده است، طوری که `(P-1)/2` نیز اول باشد. _ترتیب_ یک عضو `x` از [گروه ضربی](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` حداقل `m` تعریف شده است، طوری که xᵐ mod P ≡ 1
+با توجه به این تعاریف داریم:
+
+> مشاهده 1. اجازه دهید `x` عضوی از گروه ضربی `ℤ/Pℤ` برای عدد اول امن `P` باشد. اگر `x mod P ≠ 1 mod P` و `x mod P ≠ P-1 mod P`، آنگاه ترتیب `x` یا ` است P-1` یا `(P-1)/2`.
+
+_اثبات_. از آنجا که `P` یک عدد اول امن است، پس با \[قضیه لاگرانژ\] \[لاگرانژ\] میبینیم که ترتیب `x` یا `1` است یا `2` یا `(P-1)/2` یا `P-1`.
+
+ترتیب `x` نمی تواند `1` باشد، زیرا با قضیه کوچک فرما داریم:
+
+xP-1 mod P ≡ 1
+
+بنابراین `x` باید یک هویت ضربی از `ℤ/nℤ` باشد، که منحصر به فرد است. از آنجا که فرض کردیم `x ≠ 1`، بر اساس فرض، این امکان پذیر نیست.
+
+ترتیب `x` نمی تواند `2` باشد مگر اینکه `x = P-1` باشد، زیرا این امر ناقض اصلی بودن `P` است.
+
+از گزاره بالا، می توانیم تشخیص دهیم که تکرار `( picker * init) % P` دارای طول چرخه حداقل `(P-1)/2` خواهد بود. این به این دلیل است که ما `P` را به عنوان یک عدد اول امن تقریباً برابر با توان بالاتر از دو انتخاب کردیم و `init` در بازه `[2,2**256+1]` است. با توجه به بزرگی `P`، هرگز نباید انتظار چرخه ای از توان مدولار داشته باشیم.
+
+هنگامی که اولین سلول را در DAG اختصاص می دهیم (متغیر با برچسب `init`)، `pow(sha3(seed) + 2, 3, P)` را محاسبه می کنیم. در نگاه اول، این تضمین نمی کند که نتیجه نه `1` و نه `P-1` باشد. با این حال، از آنجا که `P-1` یک عدد اول امن است، ما تضمین اضافی زیر را داریم که نتیجه مشاهده 1 است:
+
+> مشاهده 2. اجازه دهید `x` عضوی از گروه ضربی `ℤ/Pℤ` برای عدد اول امن `P` باشد، و اجازه دهید `w` یک عدد طبیعی باشد. اگر `x mod P ≠ 1 mod P` و `x mod P ≠ P-1 mod P`، و همچنین `w mod P ≠ P-1 mod P 0> و w mod P ≠ 0 mod P`، سپس `xʷ mod P ≠ 1 mod P` و `xʷ mod P ≠ P-1 mod P`
+
+### توان مدولار به عنوان یک تابع هش {#modular-exponentiation}
+
+برای مقادیر معینی از `P` و `w`، تابع `pow(x، w، P)` ممکن است برخوردهای زیادی داشته باشد. برای مثال، `pow(x,9,19)` فقط مقادیر `{1,18}` را می گیرد.
+
+با توجه به اینکه `P` اول است، میتوان با استفاده از نتیجه زیر، یک `w` مناسب برای یک تابع درهمسازی توان مدولار انتخاب کرد:
+
+> مشاهده 3. بگذارید `P` عدد اول باشد. `w` و `P-1` نسبتاً اول هستند اگر و فقط اگر برای همه `a` و `b` در `ℤ /Pℤ`:
+>
+>
+> «aʷ mod P ≡ bʷ mod P» اگر و فقط اگر «a mod P ≡ b mod P»
+>
+
+بنابراین، با توجه به اینکه `P` اول است و `w` نسبتاً اول نسبت به `P-1`، داریم که `|{pow(x, w, P) : x ∈ ℤ}| = P`، به این معنی است که تابع هش حداقل نرخ برخورد ممکن را دارد.
+
+در حالت خاصی که `P` همانطور که انتخاب کردهایم یک عدد اول امن است، پس `P-1` فقط فاکتورهای 1، 2، `(P-1)/2` و `P-1` را دارد. از آنجا که `P` > 7، می دانیم که 3 نسبتاً اول نسبت به `P-1` است، بنابراین `w=3` گزاره فوق را برآورده می کند.
+
+## الگوریتم کارآمدتر ارزیابی مبتنی بر حافظه پنهان {#cache-based-evaluation}
+
+```python
+def quick_calc(params, seed, p):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_calc_cached(cache, params, p)
+
+def quick_calc_cached(cache, params, p):
+ P = params["P"]
+ if p < len(cache):
+ return cache[p]
+ else:
+ x = pow(cache[0], p + 1, P)
+ for _ in range(params["k"]):
+ x ^= quick_calc_cached(cache, params, x % p)
+ return pow(x, params["w"], P)
+
+def quick_hashimoto(seed, dagsize, params, header, nonce):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_hashimoto_cached(cache, dagsize, params, header, nonce)
+
+def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
+ m = dagsize // 2
+ mask = 2**64 - 1
+ mix = sha3(encode_int(nonce) + header)
+ for _ in range(params["accesses"]):
+ mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
+ return dbl_sha3(mix)
+```
diff --git a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
new file mode 100644
index 00000000000..1f40853bfd7
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
@@ -0,0 +1,1014 @@
+---
+title: یک الگوریتم اثبات انجام کار برای اتریوم ۱. ۰
+description: نگاهی دقیق به الگوریتم Ethash.
+lang: fa
+---
+
+
+ Ethash الگوریتم استخراج اثبات کار اتریوم بود. اثبات کار اکنون **به طور کامل خاموش شده** و اتریوم اکنون با استفاده از اثبات سهام امن شده است. درباره ادغام و اثبات سهام و سهام گذاری بیشتر بخوانید. این صفحه صرفاً برای علاقهمندان به تاریخ است!
+
+
+[Ethash](https://github.com/ethereum/wiki/wiki/Ethash) نسخه اصلاح شده الگوریتم [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) است. اثبات کار Ethash نیازمند [حافظه سخت](https://wikipedia.org/wiki/Memory-hard_function) است که تصور میشد این الگوریتم را در برابر دستگاههای ASIC مقاوم میکند. در نهایت، دستگاههای Ethash ASIC توسعه یافتند، اما تا زمانی که اثبات کار خاموش شد، استخراج با GPU همچنان یک گزینه قابل اجرا بود. Ethash هنوز برای استخراج سکه های دیگر در سایر شبکه های اثبات کار غیر اتریوم استفاده می شود.
+
+## Ethash چگونه کار می کند؟ {#how-does-ethash-work}
+
+سختی حافظه با الگوریتم اثبات کار به دست می آید که مستلزم انتخاب زیر مجموعه های یک منبع ثابت وابسته به سر نانس و بلوک است. این منبع (به اندازه چند گیگابایت) DAG نامیده می شود. DAG هر 30000 بلوک تغییر می کند، یعنی یک پنجره حدودا 125 ساعته به نام ایپوک (تقریباً 5.2 روز) و مدتی طول می کشد تا تولید شود. از آنجا که DAG فقط به ارتفاع بلوک بستگی دارد، میتوان آن را از پیش تولید کرد، اما اگر تولید نشده باشد، کاربر باید تا پایان این فرآیند منتظر بماند تا بتواند بلوک تولید کند. اگر کاربرها DAGها را از قبل تولید و ذخیره نکنند، ممکن است شبکه در هر انتقال دوره با تأخیر عظیم در بلوک مواجه شود. توجه داشته باشید که برای تأیید اثبات کار نیازی به تولید DAG نیست و این امکان را میدهد که تأیید با پردازنده کم مصرف و حافظه کم انجام شود.
+
+مسیر کلی که الگوریتم طی می کند به شرح زیر است:
+
+1. برای هر بلوک یک **بذر** وجود دارد که با اسکن کردن سرهای بلوک تا آن نقطه قابل محاسبه است.
+2. از روی این بذر، میتوان یک **حافظه پنهان شبهتصادفی ۱۶ مگابایتی** محاسبه کرد. کاربرهای سبک، حافظه پنهان را ذخیره میکنند.
+3. از حافظه پنهان، میتوانیم یک مجموعه داده **یک گیگابایتی** تولید کنیم، طوری که هر آیتم در این مجموعه داده فقط به تعداد کمی از آیتمهای حافظه پنهان وابسته است. کاربرهای کامل و استخراجگرها مجموعه داده را ذخیره میکنند. مجموعه داده به صورت خطی با زمان رشد می کند.
+4. استخراج شامل گرفتن برشهای تصادفی از مجموعه داده و هش کردن آنها با هم است. تأیید را میتوان با استفاده از حافظه پنهان برای بازسازی قطعات خاص مجموعه داده مورد نیاز با حافظه کم انجام داد، بنابراین فقط نیاز به ذخیره حافظه پنهان دارید.
+
+مجموعه داده بزرگ هر 30000 بلوک یک بار بهروزرسانی میشود، بنابراین اکثر تلاشهای یک استخراجگر صرف خواندن مجموعه داده میشود، نه ایجاد تغییر در آن.
+
+## تعاریف {#definitions}
+
+ما از تعاریف زیر استفاده می کنیم:
+
+```
+WORD_BYTES = 4 # bytes in word
+DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis
+DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch
+CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis
+CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch
+CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache
+EPOCH_LENGTH = 30000 # blocks per epoch
+MIX_BYTES = 128 # width of mix
+HASH_BYTES = 64 # hash length in bytes
+DATASET_PARENTS = 256 # number of parents of each dataset element
+CACHE_ROUNDS = 3 # number of rounds in cache production
+ACCESSES = 64 # number of accesses in hashimoto loop
+```
+
+### استفاده از 'SHA3' {#sha3}
+
+توسعه اتریوم همزمان با توسعه استاندارد SHA3 انجام شد و فرآیند استانداردسازی تغییری دیرهنگام در پرکردن الگوریتم هش نهایی ایجاد کرد، طوری که هشهای "sha3_256" و "sha3_512" اتریوم هشهای استاندارد sha3 نیستند، بلکه نوعی متفاوت هستند که اغلب در زمینههای دیگر به عنوان "Keccak-256" و "Keccak-512" شناخته میشوند. برای اطلاعات بیشتر، به بحثهای انجام شده در [اینجا](https://eips.ethereum.org/EIPS/eip-1803)، [اینجا](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)، یا [اینجا](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057) مراجعه کنید.
+
+لطفا این نکته را در نظر داشته باشید که در توضیحات الگوریتم زیر به هشهای "sha3" اشاره شده است.
+
+## پارامترها {#parameters}
+
+پارامترهای حافظه پنهان و مجموعه داده Ethash وابسته به شماره بلوک هستند. اندازه حافظه پنهان و اندازه مجموعه داده هر دو به صورت خطی رشد میکنند؛ با این حال، برای کاهش خطر ایجاد الگوهای تکراری منجر به رفتار چرخهای، همیشه بزرگترین عدد اول کمتر از آستانه رشد خطی را انتخاب میکنیم.
+
+```python
+def get_cache_size(block_number):
+ sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= HASH_BYTES
+ while not isprime(sz / HASH_BYTES):
+ sz -= 2 * HASH_BYTES
+ return sz
+
+def get_full_size(block_number):
+ sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= MIX_BYTES
+ while not isprime(sz / MIX_BYTES):
+ sz -= 2 * MIX_BYTES
+ return sz
+```
+
+جدولهای مقادیر اندازه حافظه پنهان و مجموعه داده در ضمیمه ارائه شده است.
+
+## تولید حافظه پنهان {#cache-generation}
+
+اکنون تابع تولید حافظه پنهان را مشخص می کنیم:
+
+```python
+def mkcache(cache_size, seed):
+ n = cache_size // HASH_BYTES
+
+ # Sequentially produce the initial dataset
+ o = [sha3_512(seed)]
+ for i in range(1, n):
+ o.append(sha3_512(o[-1]))
+
+ # Use a low-round version of randmemohash
+ for _ in range(CACHE_ROUNDS):
+ for i in range(n):
+ v = o[i][0] % n
+ o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v]))
+
+ return o
+```
+
+فرآیند تولید حافظه پنهان شامل پر کردن متوالی 32 مگابایت حافظه میشود، سپس دو پاس از الگوریتم _RandMemoHash_ سرجیو دمیان لرنر از [_Strict Memory Hard Hashing Functions_ (2014) انجام میشود](http://www.hashcash.org/papers/memohash.pdf). خروجی، یک مجموعه شامل ۵۲۴۲۸۸ مقدار ۶۴ بایتی است.
+
+## تابع تجمیع داده ها {#date-aggregation-function}
+
+در برخی موارد از یک الگوریتم الهام گرفته از [هش FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) به عنوان جایگزینی غیر تداعی برای XOR استفاده میکنیم. توجه داشته باشید که ما عدد اول را در کل ورودی ۳۲ بیتی ضرب میکنیم، برخلاف مشخصات FNV-1 که عدد اول را با هر بایت (octet) به نوبت ضرب میکند.
+
+```python
+FNV_PRIME = 0x01000193
+
+def fnv(v1, v2):
+ return ((v1 * FNV_PRIME) ^ v2) % 2**32
+```
+
+لطفا توجه داشته باشید که حتی وایتپیپر نیز fnv را به عنوان v1*(FNV_PRIME ^ v2) مشخص میکند، اما تمام اجراهای فعلی به طور مداوم از تعریف بالا استفاده میکنند.
+
+## محاسبه کامل مجموعه داده {#full-dataset-calculation}
+
+هر آیتم ۶۴ بایتی در کل مجموعه داده ۱ گیگابایتی به شرح زیر محاسبه میشود:
+
+```python
+def calc_dataset_item(cache, i):
+ n = len(cache)
+ r = HASH_BYTES // WORD_BYTES
+ # initialize the mix
+ mix = copy.copy(cache[i % n])
+ mix[0] ^= i
+ mix = sha3_512(mix)
+ # fnv it with a lot of random cache nodes based on i
+ for j in range(DATASET_PARENTS):
+ cache_index = fnv(i ^ j, mix[j % r])
+ mix = map(fnv, mix, cache[cache_index % n])
+ return sha3_512(mix)
+```
+
+در اصل، ما دادهها را از ۲۵۶ گره حافظه پنهان انتخاب شده به صورت شبهتصادفی ترکیب میکنیم و آن را هش میکنیم تا گره مجموعه داده را محاسبه کنیم. کل مجموعه داده سپس با استفاده از روش زیر تولید میشود:
+
+```python
+def calc_dataset(full_size, cache):
+ return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
+```
+
+## حلقه اصلی {#main-loop}
+
+حالا حلقه اصلی شبیه به "hashimoto" را مشخص میکنیم که در آن دادهها را از کل مجموعه داده جمعآوری میکنیم تا مقدار نهایی خود را برای یک سر و نانسِ خاص تولید کنیم. در کد زیر، `header` نشان دهنده _هش SHA3-256_ از نمایش RLP یک سر بلوک _بریده شده_ است، یعنی سر بدون فیلدهای **mixHash** و **nonce**. `نانس` هشت بایت از یک عدد صحیح بدون علامت ۶۴ بیتی با ترتیب بزرگ به کوچک است. پس `nonce[::-1]` نمایش هشت بایتی با ترتیب کوچک به بزرگ little-endian از آن مقدار است:
+
+```python
+def hashimoto(header, nonce, full_size, dataset_lookup):
+ n = full_size / HASH_BYTES
+ w = MIX_BYTES // WORD_BYTES
+ mixhashes = MIX_BYTES / HASH_BYTES
+ # combine header+nonce into a 64 byte seed
+ s = sha3_512(header + nonce[::-1])
+ # start the mix with replicated s
+ mix = []
+ for _ in range(MIX_BYTES / HASH_BYTES):
+ mix.extend(s)
+ # mix in random dataset nodes
+ for i in range(ACCESSES):
+ p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
+ newdata = []
+ for j in range(MIX_BYTES / HASH_BYTES):
+ newdata.extend(dataset_lookup(p + j))
+ mix = map(fnv, mix, newdata)
+ # compress mix
+ cmix = []
+ for i in range(0, len(mix), 4):
+ cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
+ return {
+ "mix digest": serialize_hash(cmix),
+ "result": serialize_hash(sha3_256(s+cmix))
+ }
+
+def hashimoto_light(full_size, cache, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))
+
+def hashimoto_full(full_size, dataset, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: dataset[x])
+```
+
+در اصل، ما یک "میکس" ۱۲۸ بایتی را حفظ میکنیم و به طور متوالی ۱۲۸ بایت را از کل مجموعه داده دریافت کرده و از تابع `fnv` برای ترکیب آن با میکس استفاده میکنیم. از ۱۲۸ بایت دسترسی متوالی استفاده میشود تا هر دور از الگوریتم همیشه یک صفحه کامل را از رم دریافت کند و خطای حافظه پنهان ترجمه را به حداقل برساند که از نظر تئوری ASICها میتوانند از آن جلوگیری کنند.
+
+اگر خروجی این الگوریتم کمتر از هدف مورد نظر باشد، پس نانس معتبر است. توجه داشته باشید که اعمال اضافی `sha3_256` در انتها تضمین میکند که یک نانس میانی وجود دارد که میتواند برای اثبات انجام حداقل مقدار کار ارائه شود؛ این تأیید سریع PoW خارجی میتواند برای اهداف ضد DDoS استفاده شود. همچنین برای ارائه اطمینان آماری از اینکه نتیجه یک عدد ۲۵۶ بیتی بدون سوگیری است، عمل میکند.
+
+## استخراج {#mining}
+
+الگوریتم استخراج به صورت زیر تعریف شده است:
+
+```python
+def mine(full_size, dataset, header, difficulty):
+ # zero-pad target to compare with hash on the same digit
+ target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
+ from random import randint
+ nonce = randint(0, 2**64)
+ while hashimoto_full(full_size, dataset, header, nonce) > target:
+ nonce = (nonce + 1) % 2**64
+ return nonce
+```
+
+## تعریف هش بذر {#seed-hash}
+
+برای محاسبه هش بذر که برای استخراج در بالای یک بلوک مورد استفاده قرار می گیرد، از الگوریتم زیر استفاده می کنیم:
+
+```python
+ def get_seedhash(block):
+ s = '\x00' * 32
+ for i in range(block.number // EPOCH_LENGTH):
+ s = serialize_hash(sha3_256(s))
+ return s
+```
+
+توجه داشته باشید که برای استخراج و تأیید روان، توصیه میشود که seedhashها و مجموعه دادههای آینده را در یک رشته جداگانه از قبل محاسبه کنید.
+
+## بیشتر بخوانید {#further-reading}
+
+_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
+
+## پیوست {#appendix}
+
+در صورتی که علاقهمند به اجرای مشخصات پایتون بالا به عنوان کد هستید، باید کد زیر را در ابتدای آن قرار دهید.
+
+```python
+import sha3, copy
+
+# Assumes little endian bit ordering (same as Intel architectures)
+def decode_int(s):
+ return int(s[::-1].encode('hex'), 16) if s else 0
+
+def encode_int(s):
+ a = "%x" % s
+ return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1]
+
+def zpad(s, length):
+ return s + '\x00' * max(0, length - len(s))
+
+def serialize_hash(h):
+ return ''.join([zpad(encode_int(x), 4) for x in h])
+
+def deserialize_hash(h):
+ return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)]
+
+def hash_words(h, sz, x):
+ if isinstance(x, list):
+ x = serialize_hash(x)
+ y = h(x)
+ return deserialize_hash(y)
+
+def serialize_cache(ds):
+ return ''.join([serialize_hash(h) for h in ds])
+
+serialize_dataset = serialize_cache
+
+# sha3 hash function, outputs 64 bytes
+def sha3_512(x):
+ return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
+
+def sha3_256(x):
+ return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x)
+
+def xor(a, b):
+ return a ^ b
+
+def isprime(x):
+ for i in range(2, int(x**0.5)):
+ if x % i == 0:
+ return False
+ return True
+```
+
+### اندازه داده ها {#data-sizes}
+
+جدولهای جستجوی زیر تقریباً ۲۰۴۸ دوره محاسباتی جدولبندی شده از اندازههای دادهها و اندازههای کش را ارائه میدهند.
+
+```python
+def get_datasize(block_number):
+ return data_sizes[block_number // EPOCH_LENGTH]
+
+def get_cachesize(block_number):
+ return cache_sizes[block_number // EPOCH_LENGTH]
+
+data_sizes = [
+1073739904, 1082130304, 1090514816, 1098906752, 1107293056,
+1115684224, 1124070016, 1132461952, 1140849536, 1149232768,
+1157627776, 1166013824, 1174404736, 1182786944, 1191180416,
+1199568512, 1207958912, 1216345216, 1224732032, 1233124736,
+1241513344, 1249902464, 1258290304, 1266673792, 1275067264,
+1283453312, 1291844992, 1300234112, 1308619904, 1317010048,
+1325397376, 1333787776, 1342176128, 1350561664, 1358954368,
+1367339392, 1375731584, 1384118144, 1392507008, 1400897408,
+1409284736, 1417673344, 1426062464, 1434451072, 1442839168,
+1451229056, 1459615616, 1468006016, 1476394112, 1484782976,
+1493171584, 1501559168, 1509948032, 1518337664, 1526726528,
+1535114624, 1543503488, 1551892096, 1560278656, 1568669056,
+1577056384, 1585446272, 1593831296, 1602219392, 1610610304,
+1619000192, 1627386752, 1635773824, 1644164224, 1652555648,
+1660943488, 1669332608, 1677721216, 1686109312, 1694497664,
+1702886272, 1711274624, 1719661184, 1728047744, 1736434816,
+1744829056, 1753218944, 1761606272, 1769995904, 1778382464,
+1786772864, 1795157888, 1803550592, 1811937664, 1820327552,
+1828711552, 1837102976, 1845488768, 1853879936, 1862269312,
+1870656896, 1879048064, 1887431552, 1895825024, 1904212096,
+1912601216, 1920988544, 1929379456, 1937765504, 1946156672,
+1954543232, 1962932096, 1971321728, 1979707264, 1988093056,
+1996487552, 2004874624, 2013262208, 2021653888, 2030039936,
+2038430848, 2046819968, 2055208576, 2063596672, 2071981952,
+2080373632, 2088762752, 2097149056, 2105539712, 2113928576,
+2122315136, 2130700672, 2139092608, 2147483264, 2155872128,
+2164257664, 2172642176, 2181035392, 2189426048, 2197814912,
+2206203008, 2214587264, 2222979712, 2231367808, 2239758208,
+2248145024, 2256527744, 2264922752, 2273312128, 2281701248,
+2290086272, 2298476672, 2306867072, 2315251072, 2323639168,
+2332032128, 2340420224, 2348808064, 2357196416, 2365580416,
+2373966976, 2382363008, 2390748544, 2399139968, 2407530368,
+2415918976, 2424307328, 2432695424, 2441084288, 2449472384,
+2457861248, 2466247808, 2474637184, 2483026816, 2491414144,
+2499803776, 2508191872, 2516582272, 2524970368, 2533359232,
+2541743488, 2550134144, 2558525056, 2566913408, 2575301504,
+2583686528, 2592073856, 2600467328, 2608856192, 2617240448,
+2625631616, 2634022016, 2642407552, 2650796416, 2659188352,
+2667574912, 2675965312, 2684352896, 2692738688, 2701130624,
+2709518464, 2717907328, 2726293376, 2734685056, 2743073152,
+2751462016, 2759851648, 2768232832, 2776625536, 2785017728,
+2793401984, 2801794432, 2810182016, 2818571648, 2826959488,
+2835349376, 2843734144, 2852121472, 2860514432, 2868900992,
+2877286784, 2885676928, 2894069632, 2902451584, 2910843008,
+2919234688, 2927622784, 2936011648, 2944400768, 2952789376,
+2961177728, 2969565568, 2977951616, 2986338944, 2994731392,
+3003120256, 3011508352, 3019895936, 3028287104, 3036675968,
+3045063808, 3053452928, 3061837696, 3070228352, 3078615424,
+3087003776, 3095394944, 3103782272, 3112173184, 3120562048,
+3128944768, 3137339264, 3145725056, 3154109312, 3162505088,
+3170893184, 3179280256, 3187669376, 3196056704, 3204445568,
+3212836736, 3221224064, 3229612928, 3238002304, 3246391168,
+3254778496, 3263165824, 3271556224, 3279944576, 3288332416,
+3296719232, 3305110912, 3313500032, 3321887104, 3330273152,
+3338658944, 3347053184, 3355440512, 3363827072, 3372220288,
+3380608384, 3388997504, 3397384576, 3405774208, 3414163072,
+3422551936, 3430937984, 3439328384, 3447714176, 3456104576,
+3464493952, 3472883584, 3481268864, 3489655168, 3498048896,
+3506434432, 3514826368, 3523213952, 3531603584, 3539987072,
+3548380288, 3556763264, 3565157248, 3573545344, 3581934464,
+3590324096, 3598712704, 3607098752, 3615488384, 3623877248,
+3632265856, 3640646528, 3649043584, 3657430144, 3665821568,
+3674207872, 3682597504, 3690984832, 3699367808, 3707764352,
+3716152448, 3724541056, 3732925568, 3741318016, 3749706368,
+3758091136, 3766481536, 3774872704, 3783260032, 3791650432,
+3800036224, 3808427648, 3816815488, 3825204608, 3833592704,
+3841981568, 3850370432, 3858755968, 3867147904, 3875536256,
+3883920512, 3892313728, 3900702592, 3909087872, 3917478784,
+3925868416, 3934256512, 3942645376, 3951032192, 3959422336,
+3967809152, 3976200064, 3984588416, 3992974976, 4001363584,
+4009751168, 4018141312, 4026530432, 4034911616, 4043308928,
+4051695488, 4060084352, 4068472448, 4076862848, 4085249408,
+4093640576, 4102028416, 4110413696, 4118805632, 4127194496,
+4135583104, 4143971968, 4152360832, 4160746112, 4169135744,
+4177525888, 4185912704, 4194303616, 4202691968, 4211076736,
+4219463552, 4227855488, 4236246656, 4244633728, 4253022848,
+4261412224, 4269799808, 4278184832, 4286578048, 4294962304,
+4303349632, 4311743104, 4320130432, 4328521088, 4336909184,
+4345295488, 4353687424, 4362073472, 4370458496, 4378852736,
+4387238528, 4395630208, 4404019072, 4412407424, 4420790656,
+4429182848, 4437571456, 4445962112, 4454344064, 4462738048,
+4471119232, 4479516544, 4487904128, 4496289664, 4504682368,
+4513068416, 4521459584, 4529846144, 4538232704, 4546619776,
+4555010176, 4563402112, 4571790208, 4580174464, 4588567936,
+4596957056, 4605344896, 4613734016, 4622119808, 4630511488,
+4638898816, 4647287936, 4655675264, 4664065664, 4672451968,
+4680842624, 4689231488, 4697620352, 4706007424, 4714397056,
+4722786176, 4731173248, 4739562368, 4747951744, 4756340608,
+4764727936, 4773114496, 4781504384, 4789894784, 4798283648,
+4806667648, 4815059584, 4823449472, 4831835776, 4840226176,
+4848612224, 4857003392, 4865391488, 4873780096, 4882169728,
+4890557312, 4898946944, 4907333248, 4915722368, 4924110976,
+4932499328, 4940889728, 4949276032, 4957666432, 4966054784,
+4974438016, 4982831488, 4991221376, 4999607168, 5007998848,
+5016386432, 5024763776, 5033164672, 5041544576, 5049941888,
+5058329728, 5066717056, 5075107456, 5083494272, 5091883904,
+5100273536, 5108662144, 5117048192, 5125436032, 5133827456,
+5142215296, 5150605184, 5158993024, 5167382144, 5175769472,
+5184157568, 5192543872, 5200936064, 5209324928, 5217711232,
+5226102656, 5234490496, 5242877312, 5251263872, 5259654016,
+5268040832, 5276434304, 5284819328, 5293209728, 5301598592,
+5309986688, 5318374784, 5326764416, 5335151488, 5343542144,
+5351929472, 5360319872, 5368706944, 5377096576, 5385484928,
+5393871232, 5402263424, 5410650496, 5419040384, 5427426944,
+5435816576, 5444205952, 5452594816, 5460981376, 5469367936,
+5477760896, 5486148736, 5494536832, 5502925952, 5511315328,
+5519703424, 5528089984, 5536481152, 5544869504, 5553256064,
+5561645696, 5570032768, 5578423936, 5586811264, 5595193216,
+5603585408, 5611972736, 5620366208, 5628750464, 5637143936,
+5645528192, 5653921408, 5662310272, 5670694784, 5679082624,
+5687474048, 5695864448, 5704251008, 5712641408, 5721030272,
+5729416832, 5737806208, 5746194304, 5754583936, 5762969984,
+5771358592, 5779748224, 5788137856, 5796527488, 5804911232,
+5813300608, 5821692544, 5830082176, 5838468992, 5846855552,
+5855247488, 5863636096, 5872024448, 5880411008, 5888799872,
+5897186432, 5905576832, 5913966976, 5922352768, 5930744704,
+5939132288, 5947522432, 5955911296, 5964299392, 5972688256,
+5981074304, 5989465472, 5997851008, 6006241408, 6014627968,
+6023015552, 6031408256, 6039796096, 6048185216, 6056574848,
+6064963456, 6073351808, 6081736064, 6090128768, 6098517632,
+6106906496, 6115289216, 6123680896, 6132070016, 6140459648,
+6148849024, 6157237376, 6165624704, 6174009728, 6182403712,
+6190792064, 6199176064, 6207569792, 6215952256, 6224345216,
+6232732544, 6241124224, 6249510272, 6257899136, 6266287744,
+6274676864, 6283065728, 6291454336, 6299843456, 6308232064,
+6316620928, 6325006208, 6333395584, 6341784704, 6350174848,
+6358562176, 6366951296, 6375337856, 6383729536, 6392119168,
+6400504192, 6408895616, 6417283456, 6425673344, 6434059136,
+6442444672, 6450837376, 6459223424, 6467613056, 6476004224,
+6484393088, 6492781952, 6501170048, 6509555072, 6517947008,
+6526336384, 6534725504, 6543112832, 6551500672, 6559888768,
+6568278656, 6576662912, 6585055616, 6593443456, 6601834112,
+6610219648, 6618610304, 6626999168, 6635385472, 6643777408,
+6652164224, 6660552832, 6668941952, 6677330048, 6685719424,
+6694107776, 6702493568, 6710882176, 6719274112, 6727662976,
+6736052096, 6744437632, 6752825984, 6761213824, 6769604224,
+6777993856, 6786383488, 6794770816, 6803158144, 6811549312,
+6819937664, 6828326528, 6836706176, 6845101696, 6853491328,
+6861880448, 6870269312, 6878655104, 6887046272, 6895433344,
+6903822208, 6912212864, 6920596864, 6928988288, 6937377152,
+6945764992, 6954149248, 6962544256, 6970928768, 6979317376,
+6987709312, 6996093824, 7004487296, 7012875392, 7021258624,
+7029652352, 7038038912, 7046427776, 7054818944, 7063207808,
+7071595136, 7079980928, 7088372608, 7096759424, 7105149824,
+7113536896, 7121928064, 7130315392, 7138699648, 7147092352,
+7155479168, 7163865728, 7172249984, 7180648064, 7189036672,
+7197424768, 7205810816, 7214196608, 7222589824, 7230975104,
+7239367552, 7247755904, 7256145536, 7264533376, 7272921472,
+7281308032, 7289694848, 7298088832, 7306471808, 7314864512,
+7323253888, 7331643008, 7340029568, 7348419712, 7356808832,
+7365196672, 7373585792, 7381973888, 7390362752, 7398750592,
+7407138944, 7415528576, 7423915648, 7432302208, 7440690304,
+7449080192, 7457472128, 7465860992, 7474249088, 7482635648,
+7491023744, 7499412608, 7507803008, 7516192384, 7524579968,
+7532967296, 7541358464, 7549745792, 7558134656, 7566524032,
+7574912896, 7583300992, 7591690112, 7600075136, 7608466816,
+7616854912, 7625244544, 7633629824, 7642020992, 7650410368,
+7658794112, 7667187328, 7675574912, 7683961984, 7692349568,
+7700739712, 7709130368, 7717519232, 7725905536, 7734295424,
+7742683264, 7751069056, 7759457408, 7767849088, 7776238208,
+7784626816, 7793014912, 7801405312, 7809792128, 7818179968,
+7826571136, 7834957184, 7843347328, 7851732352, 7860124544,
+7868512384, 7876902016, 7885287808, 7893679744, 7902067072,
+7910455936, 7918844288, 7927230848, 7935622784, 7944009344,
+7952400256, 7960786048, 7969176704, 7977565312, 7985953408,
+7994339968, 8002730368, 8011119488, 8019508096, 8027896192,
+8036285056, 8044674688, 8053062272, 8061448832, 8069838464,
+8078227328, 8086616704, 8095006592, 8103393664, 8111783552,
+8120171392, 8128560256, 8136949376, 8145336704, 8153726848,
+8162114944, 8170503296, 8178891904, 8187280768, 8195669632,
+8204058496, 8212444544, 8220834176, 8229222272, 8237612672,
+8246000768, 8254389376, 8262775168, 8271167104, 8279553664,
+8287944064, 8296333184, 8304715136, 8313108352, 8321497984,
+8329885568, 8338274432, 8346663296, 8355052928, 8363441536,
+8371828352, 8380217984, 8388606592, 8396996224, 8405384576,
+8413772672, 8422161536, 8430549376, 8438939008, 8447326592,
+8455715456, 8464104832, 8472492928, 8480882048, 8489270656,
+8497659776, 8506045312, 8514434944, 8522823808, 8531208832,
+8539602304, 8547990656, 8556378752, 8564768384, 8573154176,
+8581542784, 8589933952, 8598322816, 8606705024, 8615099264,
+8623487872, 8631876992, 8640264064, 8648653952, 8657040256,
+8665430656, 8673820544, 8682209152, 8690592128, 8698977152,
+8707374464, 8715763328, 8724151424, 8732540032, 8740928384,
+8749315712, 8757704576, 8766089344, 8774480768, 8782871936,
+8791260032, 8799645824, 8808034432, 8816426368, 8824812928,
+8833199488, 8841591424, 8849976448, 8858366336, 8866757248,
+8875147136, 8883532928, 8891923328, 8900306816, 8908700288,
+8917088384, 8925478784, 8933867392, 8942250368, 8950644608,
+8959032704, 8967420544, 8975809664, 8984197504, 8992584064,
+9000976256, 9009362048, 9017752448, 9026141312, 9034530688,
+9042917504, 9051307904, 9059694208, 9068084864, 9076471424,
+9084861824, 9093250688, 9101638528, 9110027648, 9118416512,
+9126803584, 9135188096, 9143581312, 9151969664, 9160356224,
+9168747136, 9177134464, 9185525632, 9193910144, 9202302848,
+9210690688, 9219079552, 9227465344, 9235854464, 9244244864,
+9252633472, 9261021824, 9269411456, 9277799296, 9286188928,
+9294574208, 9302965888, 9311351936, 9319740032, 9328131968,
+9336516736, 9344907392, 9353296768, 9361685888, 9370074752,
+9378463616, 9386849408, 9395239808, 9403629184, 9412016512,
+9420405376, 9428795008, 9437181568, 9445570688, 9453960832,
+9462346624, 9470738048, 9479121536, 9487515008, 9495903616,
+9504289664, 9512678528, 9521067904, 9529456256, 9537843584,
+9546233728, 9554621312, 9563011456, 9571398784, 9579788672,
+9588178304, 9596567168, 9604954496, 9613343104, 9621732992,
+9630121856, 9638508416, 9646898816, 9655283584, 9663675776,
+9672061312, 9680449664, 9688840064, 9697230464, 9705617536,
+9714003584, 9722393984, 9730772608, 9739172224, 9747561088,
+9755945344, 9764338816, 9772726144, 9781116544, 9789503872,
+9797892992, 9806282624, 9814670464, 9823056512, 9831439232,
+9839833984, 9848224384, 9856613504, 9865000576, 9873391232,
+9881772416, 9890162816, 9898556288, 9906940544, 9915333248,
+9923721088, 9932108672, 9940496512, 9948888448, 9957276544,
+9965666176, 9974048384, 9982441088, 9990830464, 9999219584,
+10007602816, 10015996544, 10024385152, 10032774016, 10041163648,
+10049548928, 10057940096, 10066329472, 10074717824, 10083105152,
+10091495296, 10099878784, 10108272256, 10116660608, 10125049216,
+10133437312, 10141825664, 10150213504, 10158601088, 10166991232,
+10175378816, 10183766144, 10192157312, 10200545408, 10208935552,
+10217322112, 10225712768, 10234099328, 10242489472, 10250876032,
+10259264896, 10267656064, 10276042624, 10284429184, 10292820352,
+10301209472, 10309598848, 10317987712, 10326375296, 10334763392,
+10343153536, 10351541632, 10359930752, 10368318592, 10376707456,
+10385096576, 10393484672, 10401867136, 10410262144, 10418647424,
+10427039104, 10435425664, 10443810176, 10452203648, 10460589952,
+10468982144, 10477369472, 10485759104, 10494147712, 10502533504,
+10510923392, 10519313536, 10527702656, 10536091264, 10544478592,
+10552867712, 10561255808, 10569642368, 10578032768, 10586423168,
+10594805632, 10603200128, 10611588992, 10619976064, 10628361344,
+10636754048, 10645143424, 10653531776, 10661920384, 10670307968,
+10678696832, 10687086464, 10695475072, 10703863168, 10712246144,
+10720639616, 10729026688, 10737414784, 10745806208, 10754190976,
+10762581376, 10770971264, 10779356288, 10787747456, 10796135552,
+10804525184, 10812915584, 10821301888, 10829692288, 10838078336,
+10846469248, 10854858368, 10863247232, 10871631488, 10880023424,
+10888412032, 10896799616, 10905188992, 10913574016, 10921964672,
+10930352768, 10938742912, 10947132544, 10955518592, 10963909504,
+10972298368, 10980687488, 10989074816, 10997462912, 11005851776,
+11014241152, 11022627712, 11031017344, 11039403904, 11047793024,
+11056184704, 11064570752, 11072960896, 11081343872, 11089737856,
+11098128256, 11106514816, 11114904448, 11123293568, 11131680128,
+11140065152, 11148458368, 11156845696, 11165236864, 11173624192,
+11182013824, 11190402688, 11198790784, 11207179136, 11215568768,
+11223957376, 11232345728, 11240734592, 11249122688, 11257511296,
+11265899648, 11274285952, 11282675584, 11291065472, 11299452544,
+11307842432, 11316231296, 11324616832, 11333009024, 11341395584,
+11349782656, 11358172288, 11366560384, 11374950016, 11383339648,
+11391721856, 11400117376, 11408504192, 11416893568, 11425283456,
+11433671552, 11442061184, 11450444672, 11458837888, 11467226752,
+11475611776, 11484003968, 11492392064, 11500780672, 11509169024,
+11517550976, 11525944448, 11534335616, 11542724224, 11551111808,
+11559500672, 11567890304, 11576277376, 11584667008, 11593056128,
+11601443456, 11609830016, 11618221952, 11626607488, 11634995072,
+11643387776, 11651775104, 11660161664, 11668552576, 11676940928,
+11685330304, 11693718656, 11702106496, 11710496128, 11718882688,
+11727273088, 11735660416, 11744050048, 11752437376, 11760824704,
+11769216128, 11777604736, 11785991296, 11794381952, 11802770048,
+11811157888, 11819548544, 11827932544, 11836324736, 11844713344,
+11853100928, 11861486464, 11869879936, 11878268032, 11886656896,
+11895044992, 11903433088, 11911822976, 11920210816, 11928600448,
+11936987264, 11945375872, 11953761152, 11962151296, 11970543488,
+11978928512, 11987320448, 11995708288, 12004095104, 12012486272,
+12020875136, 12029255552, 12037652096, 12046039168, 12054429568,
+12062813824, 12071206528, 12079594624, 12087983744, 12096371072,
+12104759936, 12113147264, 12121534592, 12129924992, 12138314624,
+12146703232, 12155091584, 12163481216, 12171864704, 12180255872,
+12188643968, 12197034112, 12205424512, 12213811328, 12222199424,
+12230590336, 12238977664, 12247365248, 12255755392, 12264143488,
+12272531584, 12280920448, 12289309568, 12297694592, 12306086528,
+12314475392, 12322865024, 12331253632, 12339640448, 12348029312,
+12356418944, 12364805248, 12373196672, 12381580928, 12389969024,
+12398357632, 12406750592, 12415138432, 12423527552, 12431916416,
+12440304512, 12448692352, 12457081216, 12465467776, 12473859968,
+12482245504, 12490636672, 12499025536, 12507411584, 12515801728,
+12524190592, 12532577152, 12540966272, 12549354368, 12557743232,
+12566129536, 12574523264, 12582911872, 12591299456, 12599688064,
+12608074624, 12616463488, 12624845696, 12633239936, 12641631616,
+12650019968, 12658407296, 12666795136, 12675183232, 12683574656,
+12691960192, 12700350592, 12708740224, 12717128576, 12725515904,
+12733906816, 12742295168, 12750680192, 12759071872, 12767460736,
+12775848832, 12784236928, 12792626816, 12801014656, 12809404288,
+12817789312, 12826181504, 12834568832, 12842954624, 12851345792,
+12859732352, 12868122496, 12876512128, 12884901248, 12893289088,
+12901672832, 12910067584, 12918455168, 12926842496, 12935232896,
+12943620736, 12952009856, 12960396928, 12968786816, 12977176192,
+12985563776, 12993951104, 13002341504, 13010730368, 13019115392,
+13027506304, 13035895168, 13044272512, 13052673152, 13061062528,
+13069446272, 13077838976, 13086227072, 13094613632, 13103000192,
+13111393664, 13119782528, 13128157568, 13136559232, 13144945024,
+13153329536, 13161724288, 13170111872, 13178502784, 13186884736,
+13195279744, 13203667072, 13212057472, 13220445824, 13228832128,
+13237221248, 13245610624, 13254000512, 13262388352, 13270777472,
+13279166336, 13287553408, 13295943296, 13304331904, 13312719488,
+13321108096, 13329494656, 13337885824, 13346274944, 13354663808,
+13363051136, 13371439232, 13379825024, 13388210816, 13396605056,
+13404995456, 13413380224, 13421771392, 13430159744, 13438546048,
+13446937216, 13455326848, 13463708288, 13472103808, 13480492672,
+13488875648, 13497269888, 13505657728, 13514045312, 13522435712,
+13530824576, 13539210112, 13547599232, 13555989376, 13564379008,
+13572766336, 13581154432, 13589544832, 13597932928, 13606320512,
+13614710656, 13623097472, 13631477632, 13639874944, 13648264064,
+13656652928, 13665041792, 13673430656, 13681818496, 13690207616,
+13698595712, 13706982272, 13715373184, 13723762048, 13732150144,
+13740536704, 13748926592, 13757316224, 13765700992, 13774090112,
+13782477952, 13790869376, 13799259008, 13807647872, 13816036736,
+13824425344, 13832814208, 13841202304, 13849591424, 13857978752,
+13866368896, 13874754688, 13883145344, 13891533184, 13899919232,
+13908311168, 13916692096, 13925085056, 13933473152, 13941866368,
+13950253696, 13958643584, 13967032192, 13975417216, 13983807616,
+13992197504, 14000582272, 14008973696, 14017363072, 14025752192,
+14034137984, 14042528384, 14050918016, 14059301504, 14067691648,
+14076083584, 14084470144, 14092852352, 14101249664, 14109635968,
+14118024832, 14126407552, 14134804352, 14143188608, 14151577984,
+14159968384, 14168357248, 14176741504, 14185127296, 14193521024,
+14201911424, 14210301824, 14218685056, 14227067264, 14235467392,
+14243855488, 14252243072, 14260630144, 14269021568, 14277409408,
+14285799296, 14294187904, 14302571392, 14310961792, 14319353728,
+14327738752, 14336130944, 14344518784, 14352906368, 14361296512,
+14369685376, 14378071424, 14386462592, 14394848128, 14403230848,
+14411627392, 14420013952, 14428402304, 14436793472, 14445181568,
+14453569664, 14461959808, 14470347904, 14478737024, 14487122816,
+14495511424, 14503901824, 14512291712, 14520677504, 14529064832,
+14537456768, 14545845632, 14554234496, 14562618496, 14571011456,
+14579398784, 14587789184, 14596172672, 14604564608, 14612953984,
+14621341312, 14629724288, 14638120832, 14646503296, 14654897536,
+14663284864, 14671675264, 14680061056, 14688447616, 14696835968,
+14705228416, 14713616768, 14722003328, 14730392192, 14738784128,
+14747172736, 14755561088, 14763947648, 14772336512, 14780725376,
+14789110144, 14797499776, 14805892736, 14814276992, 14822670208,
+14831056256, 14839444352, 14847836032, 14856222848, 14864612992,
+14872997504, 14881388672, 14889775744, 14898165376, 14906553472,
+14914944896, 14923329664, 14931721856, 14940109696, 14948497024,
+14956887424, 14965276544, 14973663616, 14982053248, 14990439808,
+14998830976, 15007216768, 15015605888, 15023995264, 15032385152,
+15040768384, 15049154944, 15057549184, 15065939072, 15074328448,
+15082715008, 15091104128, 15099493504, 15107879296, 15116269184,
+15124659584, 15133042304, 15141431936, 15149824384, 15158214272,
+15166602368, 15174991232, 15183378304, 15191760512, 15200154496,
+15208542592, 15216931712, 15225323392, 15233708416, 15242098048,
+15250489216, 15258875264, 15267265408, 15275654528, 15284043136,
+15292431488, 15300819584, 15309208192, 15317596544, 15325986176,
+15334374784, 15342763648, 15351151744, 15359540608, 15367929728,
+15376318336, 15384706432, 15393092992, 15401481856, 15409869952,
+15418258816, 15426649984, 15435037568, 15443425664, 15451815296,
+15460203392, 15468589184, 15476979328, 15485369216, 15493755776,
+15502146944, 15510534272, 15518924416, 15527311232, 15535699072,
+15544089472, 15552478336, 15560866688, 15569254528, 15577642624,
+15586031488, 15594419072, 15602809472, 15611199104, 15619586432,
+15627975296, 15636364928, 15644753792, 15653141888, 15661529216,
+15669918848, 15678305152, 15686696576, 15695083136, 15703474048,
+15711861632, 15720251264, 15728636288, 15737027456, 15745417088,
+15753804928, 15762194048, 15770582656, 15778971008, 15787358336,
+15795747712, 15804132224, 15812523392, 15820909696, 15829300096,
+15837691264, 15846071936, 15854466944, 15862855808, 15871244672,
+15879634816, 15888020608, 15896409728, 15904799104, 15913185152,
+15921577088, 15929966464, 15938354816, 15946743424, 15955129472,
+15963519872, 15971907968, 15980296064, 15988684928, 15997073024,
+16005460864, 16013851264, 16022241152, 16030629248, 16039012736,
+16047406976, 16055794816, 16064181376, 16072571264, 16080957824,
+16089346688, 16097737856, 16106125184, 16114514816, 16122904192,
+16131292544, 16139678848, 16148066944, 16156453504, 16164839552,
+16173236096, 16181623424, 16190012032, 16198401152, 16206790528,
+16215177344, 16223567744, 16231956352, 16240344704, 16248731008,
+16257117824, 16265504384, 16273898624, 16282281856, 16290668672,
+16299064192, 16307449216, 16315842176, 16324230016, 16332613504,
+16341006464, 16349394304, 16357783168, 16366172288, 16374561664,
+16382951296, 16391337856, 16399726208, 16408116352, 16416505472,
+16424892032, 16433282176, 16441668224, 16450058624, 16458448768,
+16466836864, 16475224448, 16483613056, 16492001408, 16500391808,
+16508779648, 16517166976, 16525555328, 16533944192, 16542330752,
+16550719616, 16559110528, 16567497088, 16575888512, 16584274816,
+16592665472, 16601051008, 16609442944, 16617832064, 16626218624,
+16634607488, 16642996096, 16651385728, 16659773824, 16668163712,
+16676552576, 16684938112, 16693328768, 16701718144, 16710095488,
+16718492288, 16726883968, 16735272832, 16743661184, 16752049792,
+16760436608, 16768827008, 16777214336, 16785599104, 16793992832,
+16802381696, 16810768768, 16819151744, 16827542656, 16835934848,
+16844323712, 16852711552, 16861101952, 16869489536, 16877876864,
+16886265728, 16894653056, 16903044736, 16911431296, 16919821696,
+16928207488, 16936592768, 16944987776, 16953375616, 16961763968,
+16970152832, 16978540928, 16986929536, 16995319168, 17003704448,
+17012096896, 17020481152, 17028870784, 17037262208, 17045649536,
+17054039936, 17062426496, 17070814336, 17079205504, 17087592064,
+17095978112, 17104369024, 17112759424, 17121147776, 17129536384,
+17137926016, 17146314368, 17154700928, 17163089792, 17171480192,
+17179864192, 17188256896, 17196644992, 17205033856, 17213423488,
+17221811072, 17230198912, 17238588032, 17246976896, 17255360384,
+17263754624, 17272143232, 17280530048, 17288918912, 17297309312,
+17305696384, 17314085504, 17322475136, 17330863744, 17339252096,
+17347640192, 17356026496, 17364413824, 17372796544, 17381190016,
+17389583488, 17397972608, 17406360704, 17414748544, 17423135872,
+17431527296, 17439915904, 17448303232, 17456691584, 17465081728,
+17473468288, 17481857408, 17490247552, 17498635904, 17507022464,
+17515409024, 17523801728, 17532189824, 17540577664, 17548966016,
+17557353344, 17565741184, 17574131584, 17582519168, 17590907008,
+17599296128, 17607687808, 17616076672, 17624455808, 17632852352,
+17641238656, 17649630848, 17658018944, 17666403968, 17674794112,
+17683178368, 17691573376, 17699962496, 17708350592, 17716739968,
+17725126528, 17733517184, 17741898112, 17750293888, 17758673024,
+17767070336, 17775458432, 17783848832, 17792236928, 17800625536,
+17809012352, 17817402752, 17825785984, 17834178944, 17842563968,
+17850955648, 17859344512, 17867732864, 17876119424, 17884511872,
+17892900224, 17901287296, 17909677696, 17918058112, 17926451072,
+17934843776, 17943230848, 17951609216, 17960008576, 17968397696,
+17976784256, 17985175424, 17993564032, 18001952128, 18010339712,
+18018728576, 18027116672, 18035503232, 18043894144, 18052283264,
+18060672128, 18069056384, 18077449856, 18085837184, 18094225792,
+18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
+18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
+18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
+18228444544, 18236833408, 18245220736]
+
+cache_sizes = [
+16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
+17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088,
+18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208,
+19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968,
+20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216,
+21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104,
+22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096,
+23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112,
+24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488,
+25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096,
+25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472,
+26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744,
+27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504,
+28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752,
+29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976,
+30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248,
+31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392,
+32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768,
+33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992,
+34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984,
+35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976,
+36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656,
+36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904,
+37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672,
+38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632,
+39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032,
+40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304,
+41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912,
+42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696,
+43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432,
+44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448,
+45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208,
+46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328,
+47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936,
+47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312,
+48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712,
+49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472,
+50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848,
+51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968,
+52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576,
+53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744,
+54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248,
+55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856,
+56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488,
+57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632,
+58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984,
+58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512,
+59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968,
+60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752,
+61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512,
+62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656,
+63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392,
+64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792,
+65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296,
+66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672,
+67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304,
+68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912,
+69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184,
+69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816,
+70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168,
+71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568,
+72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944,
+73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832,
+74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544,
+75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072,
+76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832,
+77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336,
+78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664,
+79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472,
+80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848,
+81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304,
+81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984,
+82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464,
+83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608,
+84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496,
+85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112,
+86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632,
+87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264,
+88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384,
+89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376,
+90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776,
+91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384,
+92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912,
+92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136,
+93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896,
+94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016,
+95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544,
+96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536,
+97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168,
+98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928,
+99352384, 99482816, 99614272, 99745472, 99876416, 100007104,
+100138048, 100267072, 100401088, 100529984, 100662592, 100791872,
+100925248, 101056064, 101187392, 101317952, 101449408, 101580608,
+101711296, 101841728, 101973824, 102104896, 102235712, 102366016,
+102498112, 102628672, 102760384, 102890432, 103021888, 103153472,
+103284032, 103415744, 103545152, 103677248, 103808576, 103939648,
+104070976, 104201792, 104332736, 104462528, 104594752, 104725952,
+104854592, 104988608, 105118912, 105247808, 105381184, 105511232,
+105643072, 105774784, 105903296, 106037056, 106167872, 106298944,
+106429504, 106561472, 106691392, 106822592, 106954304, 107085376,
+107216576, 107346368, 107478464, 107609792, 107739712, 107872192,
+108003136, 108131392, 108265408, 108396224, 108527168, 108657344,
+108789568, 108920384, 109049792, 109182272, 109312576, 109444928,
+109572928, 109706944, 109837888, 109969088, 110099648, 110230976,
+110362432, 110492992, 110624704, 110755264, 110886208, 111017408,
+111148864, 111279296, 111410752, 111541952, 111673024, 111803456,
+111933632, 112066496, 112196416, 112328512, 112457792, 112590784,
+112715968, 112852672, 112983616, 113114944, 113244224, 113376448,
+113505472, 113639104, 113770304, 113901376, 114031552, 114163264,
+114294592, 114425536, 114556864, 114687424, 114818624, 114948544,
+115080512, 115212224, 115343296, 115473472, 115605184, 115736128,
+115867072, 115997248, 116128576, 116260288, 116391488, 116522944,
+116652992, 116784704, 116915648, 117046208, 117178304, 117308608,
+117440192, 117569728, 117701824, 117833024, 117964096, 118094656,
+118225984, 118357312, 118489024, 118617536, 118749632, 118882112,
+119012416, 119144384, 119275328, 119406016, 119537344, 119668672,
+119798464, 119928896, 120061376, 120192832, 120321728, 120454336,
+120584512, 120716608, 120848192, 120979136, 121109056, 121241408,
+121372352, 121502912, 121634752, 121764416, 121895744, 122027072,
+122157632, 122289088, 122421184, 122550592, 122682944, 122813888,
+122945344, 123075776, 123207488, 123338048, 123468736, 123600704,
+123731264, 123861952, 123993664, 124124608, 124256192, 124386368,
+124518208, 124649024, 124778048, 124911296, 125041088, 125173696,
+125303744, 125432896, 125566912, 125696576, 125829056, 125958592,
+126090304, 126221248, 126352832, 126483776, 126615232, 126746432,
+126876608, 127008704, 127139392, 127270336, 127401152, 127532224,
+127663552, 127794752, 127925696, 128055232, 128188096, 128319424,
+128449856, 128581312, 128712256, 128843584, 128973632, 129103808,
+129236288, 129365696, 129498944, 129629888, 129760832, 129892288,
+130023104, 130154048, 130283968, 130416448, 130547008, 130678336,
+130807616, 130939456, 131071552, 131202112, 131331776, 131464384,
+131594048, 131727296, 131858368, 131987392, 132120256, 132250816,
+132382528, 132513728, 132644672, 132774976, 132905792, 133038016,
+133168832, 133299392, 133429312, 133562048, 133692992, 133823296,
+133954624, 134086336, 134217152, 134348608, 134479808, 134607296,
+134741056, 134872384, 135002944, 135134144, 135265472, 135396544,
+135527872, 135659072, 135787712, 135921472, 136052416, 136182848,
+136313792, 136444864, 136576448, 136707904, 136837952, 136970048,
+137099584, 137232064, 137363392, 137494208, 137625536, 137755712,
+137887424, 138018368, 138149824, 138280256, 138411584, 138539584,
+138672832, 138804928, 138936128, 139066688, 139196864, 139328704,
+139460032, 139590208, 139721024, 139852864, 139984576, 140115776,
+140245696, 140376512, 140508352, 140640064, 140769856, 140902336,
+141032768, 141162688, 141294016, 141426496, 141556544, 141687488,
+141819584, 141949888, 142080448, 142212544, 142342336, 142474432,
+142606144, 142736192, 142868288, 142997824, 143129408, 143258944,
+143392448, 143523136, 143653696, 143785024, 143916992, 144045632,
+144177856, 144309184, 144440768, 144570688, 144701888, 144832448,
+144965056, 145096384, 145227584, 145358656, 145489856, 145620928,
+145751488, 145883072, 146011456, 146144704, 146275264, 146407232,
+146538176, 146668736, 146800448, 146931392, 147062336, 147193664,
+147324224, 147455936, 147586624, 147717056, 147848768, 147979456,
+148110784, 148242368, 148373312, 148503232, 148635584, 148766144,
+148897088, 149028416, 149159488, 149290688, 149420224, 149551552,
+149683136, 149814976, 149943616, 150076352, 150208064, 150338624,
+150470464, 150600256, 150732224, 150862784, 150993088, 151125952,
+151254976, 151388096, 151519168, 151649728, 151778752, 151911104,
+152042944, 152174144, 152304704, 152435648, 152567488, 152698816,
+152828992, 152960576, 153091648, 153222976, 153353792, 153484096,
+153616192, 153747008, 153878336, 154008256, 154139968, 154270912,
+154402624, 154533824, 154663616, 154795712, 154926272, 155057984,
+155188928, 155319872, 155450816, 155580608, 155712064, 155843392,
+155971136, 156106688, 156237376, 156367424, 156499264, 156630976,
+156761536, 156892352, 157024064, 157155008, 157284416, 157415872,
+157545536, 157677248, 157810496, 157938112, 158071744, 158203328,
+158334656, 158464832, 158596288, 158727616, 158858048, 158988992,
+159121216, 159252416, 159381568, 159513152, 159645632, 159776192,
+159906496, 160038464, 160169536, 160300352, 160430656, 160563008,
+160693952, 160822208, 160956352, 161086784, 161217344, 161349184,
+161480512, 161611456, 161742272, 161873216, 162002752, 162135872,
+162266432, 162397888, 162529216, 162660032, 162790976, 162922048,
+163052096, 163184576, 163314752, 163446592, 163577408, 163707968,
+163839296, 163969984, 164100928, 164233024, 164364224, 164494912,
+164625856, 164756672, 164887616, 165019072, 165150016, 165280064,
+165412672, 165543104, 165674944, 165805888, 165936832, 166067648,
+166198336, 166330048, 166461248, 166591552, 166722496, 166854208,
+166985408, 167116736, 167246656, 167378368, 167508416, 167641024,
+167771584, 167903168, 168034112, 168164032, 168295744, 168427456,
+168557632, 168688448, 168819136, 168951616, 169082176, 169213504,
+169344832, 169475648, 169605952, 169738048, 169866304, 169999552,
+170131264, 170262464, 170393536, 170524352, 170655424, 170782016,
+170917696, 171048896, 171179072, 171310784, 171439936, 171573184,
+171702976, 171835072, 171966272, 172097216, 172228288, 172359232,
+172489664, 172621376, 172747712, 172883264, 173014208, 173144512,
+173275072, 173407424, 173539136, 173669696, 173800768, 173931712,
+174063424, 174193472, 174325696, 174455744, 174586816, 174718912,
+174849728, 174977728, 175109696, 175242688, 175374272, 175504832,
+175636288, 175765696, 175898432, 176028992, 176159936, 176291264,
+176422592, 176552512, 176684864, 176815424, 176946496, 177076544,
+177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
+177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
+178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
+179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
+180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
+181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
+181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
+182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
+183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
+184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
+185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
+185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
+186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
+187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
+188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
+189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
+189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
+190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
+191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
+192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
+192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
+193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
+194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
+195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
+196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
+196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
+197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
+198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
+199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
+200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
+200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
+201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
+202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
+203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
+203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
+204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
+205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
+206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
+207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
+207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
+208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
+209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
+210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
+211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
+211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
+212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
+213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
+214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
+214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
+215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
+216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
+217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
+218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
+218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
+219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
+220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
+221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
+222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
+222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
+223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
+224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
+225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
+225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
+226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
+227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
+228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
+229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
+229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
+230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
+231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
+232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
+233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
+233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
+234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
+235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
+236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
+236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
+237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
+238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
+239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
+240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
+240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
+241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
+242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
+243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
+244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
+244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
+245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
+246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
+247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
+247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
+248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
+249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
+250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
+251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
+251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
+252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
+253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
+254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
+255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
+255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
+256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
+257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
+258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
+258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
+259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
+260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
+261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
+262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
+262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
+263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
+264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
+265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
+266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
+266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
+267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
+268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
+269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
+270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
+270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
+271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
+272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
+273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
+273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
+274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
+275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
+276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
+277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
+277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
+278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
+279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
+280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
+281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
+281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
+282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
+283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
+284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
+284950208, 285081536]
+```
diff --git a/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
new file mode 100644
index 00000000000..0d659e167c5
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
@@ -0,0 +1,37 @@
+---
+title: الگوریتم های استخراج
+description: نگاه دقیق تر به الگوریتمهای استفاده شده برای استخراج اتریوم.
+lang: fa
+---
+
+
+اثبات-کار دیگر مکانیزم اجماع اتریوم نیست، و در نتیجه استخراج اتریوم متوفف شده است. در عوض، اتریوم توسط اعتبارسنجهایی که اتریوم را سهام گذاری میکنند، ایمن میشود. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. درباره ادغام، اثبات سهام و سهامگذاری بیشتر بخوانید. این صفحه تنها برای علاقمندان به تاریخچه پروژه است.
+
+
+استخراج اتریوم با استفاده از الگوریتمی به نام Ethash انجام میشد. ایده بنیادی این الگوریتم این است که ماینر تلاش میکند با محاسبات جستجوی فراگیر (brute force)، عدد منحصربفرد (nonce) ورودی را پیدا کند که نتیجه استفاده از آن، تولید هش کوچکتر از حد آستانه تعیین شده توسط سختی محاسبه شده است. سطح سختی به طور دینامیک قابل تنظیم است تا بدین وسیله ساخت بلوک در بازههای زمانی منظم اتفاق بیفتد.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای درک بهتر این قسمت پیشنهاد میکنیم ابتدا مقالات [الگوریتم اجماع اثبات کار](/developers/docs/consensus-mechanisms/pow) و [استخراج](/developers/docs/consensus-mechanisms/pow/mining) را مطالعه کنید.
+
+## الگوریتم دگر هشیموتو (Dagger Hashimoto) {#dagger-hashimoto}
+
+Dagger Hashimoto یک الگوریتم تحقیقاتی پیشرو برای استخراج اتریوم بود که الگوریتم Ethhash جایگزین آن شد. این الگوریتم از ادغام دو الگوریتم Dagger و Hashimoto ایجاد شده بود. این الگوریتم تنها یک پیادهسازی تحقیقاتی بود و در زمان راهاندازی شبکه اصلی اتریوم توسط Ethash جایگزین شد.
+
+[Dagger](http://www.hashcash.org/papers/dagger.html) شامل تولید یک [گراف جهتدار غیرمدور](https://en.wikipedia.org/wiki/Directed_acyclic_graph) است که برش های تصادفی آن باهم هش شدهاند. مولفه اصلی این است که هر نانس فقط به بخش کوچکی از درخت داده کل بزرگ نیاز دارد. محاسبه مجدد زیردرخت برای هر نانس در استخراج ممنوع است - و بنابراین نیاز به ذخیره درخت - اما برای تایید ارزش یک نانس مشکلی وجود ندارد. Dagger طراحی شده بود تا یک جایگزین برای الگوریتمهای موجود مثل Scrypt باشد، الگوریتمهایی که حافظه سختی دارند اما زمانی که سختی حافظه آنها به سطوح ایمن اصل افزایش مییابد، تأیید آن دشوار است. با این حال، Dagger در برابر شتاب سختافزار حافظه مشترک آسیبپذیر بود و به نفع سایر روشهای تحقیق کنار گذاشته شد.
+
+[هشیموتو](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) الگوریتمی است که با محدود بودن به I/O، ویژگی مقاوم بودن در برابر ASIC را به الگوریتم اضافه میکند (یعنی خواندن حافظه، عامل محدود کننده در فرآیند استخراج است). تئوری این است که RAM بیشتر از محاسبات در دسترس است؛ میلیاردها دلار تحقیق در حال حاضر بهینهسازی RAM را برای موارد استفاده مختلف بررسی کردهاند، که اغلب شامل الگوهای دسترسی تقریبا تصادفی است (از این رو به آن حافظه دسترسی تصادفی گفته میشود). در نتیجه، RAM موجود احتمالاً برای ارزیابی الگوریتم نسبتاً نزدیک به حالت بهینه است. هاشیموتو بلاک چین را به عنوان منبع داده استفاده کرده و همزمان مورد 1 و 3 در بالا را برآورده میکند.
+
+Dagger-Hashimoto از نسخههای اصلاح یافته الگوریتمهای Dagger و Hashimoto استفاده کرد. تفاوت بین Dagger Hashimoto و Hashimoto این است که به جای استفاده از بلاک چین به عنوان منبع داده Dagger Hashimoto از یک مجموعه داده سفارشی تولید شده استفاده میکند که این مچموعه داده بر اساس دادههای موجود در بلوکها در هر N بلوک به روز میشود. این مجموعه دادهها با استفاده از الگوریتم Dagger تولید میشود، که امکان محاسبه مؤثر زیرمجموعهای خاص برای هر نانس را برای الگوریتم تأیید کاربر سبک فراهم میکند. تفاوت بین Dagger Hashimoto و Dagger این است که برخلاف Dagger اصلی، مجموعه داده استفاده شده برای استعلام از بلوک نیمه دائمی است و فقط در فواصل زمانی گاه به گاه (به عنوان مثال یک بار در هفته) به روز میشود. این بدان معناست که بخشی از تلاش برای تولید مجموعه داده نزدیک به صفر است، بنابراین استدلالهای سرجیو لرنر در مورد افزایش سرعت حافظه مشترک قابل چشمپوشی میشود.
+
+اطلاعات بیشتر درباره [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto).
+
+## یک الگوریتم اثبات انجام کار برای اتریوم ۱. ۰ {#ethash}
+
+Ethash در واقع همان الگوریتم استخراج بود که در الگوریتم اثبات کار استخراج شبکه اصلی اتریوم که اکنون منسوخ شده، استفاده شده بود. Ethash در واقع نام جدیدی بود که به نسخه خاصی از الگوریتم Dagger-Hashimoto و پس از به روز رسانی قابل توجه آن داده شد، در حالی که هنوز اصول اساسی نسخه قبلی خود را به ارث میبرد. شبکه اصلی اتریوم تاکنون تنها از Ethash استفاده کرده است - Dagger Hashimoto یک نسخه در حال &توسعه از الگوریتم استخراج بود که قبل از شروع استخراج در شبکه اصلی اتریوم، جایگزین شد.
+
+[مطالب بیشتر درباره Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
+
+## بیشتر بخوانید {#further-reading}
+
+_در مورد جامعه منابعی که به شما کمک می کنند بدانید? این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git a/public/content/translations/fa/developers/docs/dapps/index.md b/public/content/translations/fa/developers/docs/dapps/index.md
index 50ac61c74ad..5ff228dde35 100644
--- a/public/content/translations/fa/developers/docs/dapps/index.md
+++ b/public/content/translations/fa/developers/docs/dapps/index.md
@@ -59,7 +59,7 @@ lang: fa
- [گیتهاب](https://github.com/paulrberg/create-eth-app)
**One Click Dapp _- ابزار FOSS برای تولید صفحات فرانت dapp از
-ABI._**
+ABI.
- [oneclickdapp.com](https://oneclickdapp.com)
- [گیت هاب](https://github.com/oneclickdapp/oneclickdapp-v1)
@@ -75,17 +75,23 @@ ABI._**
- [اسناد](https://portal.thirdweb.com/)
- [گیت هاب](https://github.com/thirdweb-dev/)
+**پلتفرم Crossmint _- پلتفرم توسعه Web3 در سطح سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از API برای ایجاد، توزیع، فروش، ذخیره و ویرایش NFTها است._**
+
+- [crossmint.com](https://www.crossmint.com)
+- [اسناد](https://docs.crossmint.com)
+- [دیسکورد](https://discord.com/invite/crossmint)
+
## بیشتر بخوانید {#further-reading}
-- [کاوش در صرافیهای غیرمتمرکز](/dapps)
+- [کاوش در برنامههای غیرمتمرکز](/dapps)
- [معماری یک اپلیکیشن Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _پریتی کسیردی_
- [راهنمای 2021 برای اپلیکیشنهای غیرمتمرکز](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_
- [اپلیکیشنهای غیرمتمرکز چه هستند؟](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_
- [اپلیکیشنهای غیرمتمرکز پرطرفدار](https://www.alchemy.com/dapps) - _Alchemy_
-_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git a/public/content/translations/fa/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/fa/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
new file mode 100644
index 00000000000..31d737eb12a
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
@@ -0,0 +1,118 @@
+---
+title: راهکار های ذخیرهسازی داده در بلاکچین
+description: چندین راه مختلف برای ذخیرهسازی داده با استفاده از بلاکچین وجود دارد. این مقاله به مقایسه استراتژیهای مختلف، مزایا و معایب هرکدام و پیشنیازهای استفاده امن آنها میپردازد.
+lang: fa
+---
+
+راههای مختلفی وجود دارد تا دادهها را چه بهصورت مستقیم در بلاکچین و چه با روشی که امنیت آن از طریق بلاکچین تأمین شود، ذخیرهسازی کرد:
+
+- بلابهای EIP-4844
+- دادهی فراخوانی (calldata)
+- خارج از زنجیره ولی بهره گرفته از مکانیزم بلاکچین لایه 1
+- "کد" قرارداد
+- رویدادها
+- حافظه ابدی ماشین مجازی اتریوم (EVM storage)
+
+انتخاب روش مورد استفاده بر اساس چندین معیار است:
+
+- منبع اطلاعات. اطلاعات موجود در دادهی فراخوانی (calldata) مستقیماً از خود بلاکچین نشأت نمیگیرند.
+- مقصد اطلاعات. Calldata فقط در تراکنشی که شروع می کند در دسترس است. رویدادها به هیچ وجه به صورت زنجیره ای قابل دسترسی نیستند.
+- چقدر دردسر قابل قبول است؟ رایانههایی که یک گره در مقیاس کامل اجرا میکنند میتوانند پردازش بیشتری نسبت به یک کلاینت سبک در برنامهای که در مرورگر اجرا میشود انجام دهند.
+- آیا تسهیل دسترسی آسان به اطلاعات از هر گره ضروری است؟
+- الزامات امنیتی.
+
+## الزامات امنیتی {#security-requirements}
+
+به طور کلی امنیت اطلاعات شامل سه ویژگی است:
+
+- _محرمانگی، اشخاص غیر مجاز، مجاز به خواندن اطلاعات نیستند. این در بسیاری از موارد مهم است، اما در اینجا نه. _ هیچ رازی در بلاکچین وجود ندارد _. بلاک چینها کار می کنند زیرا هر کسی می تواند انتقال حالت را تأیید کند، بنابراین استفاده از آنها برای ذخیره مستقیم اسرار غیرممکن است. راههایی برای ذخیره اطلاعات محرمانه در بلاکچین وجود دارد، اما همه آنها برای ذخیره حداقل یک کلید به برخی اجزای خارج از زنجیره متکی هستند.
+
+- _یکپارچگی_، اطلاعات صحیح است، نمی توان آن را توسط نهادهای غیرمجاز یا به روش های غیرمجاز تغییر داد (به عنوان مثال، انتقال [توکن های ERC-20] (https://eips.ethereum.org/EIPS/eip-20#events) بدون یک رویداد "انتقال"). در بلاکچین، هر گره هر تغییر حالت را تأیید می کند که یکپارچگی را تضمین می کند.
+
+- _در دسترس بودن_، اطلاعات در دسترس هر نهاد مجاز است. در بلاکچین، این امر معمولاً با داشتن اطلاعات در دسترس در هر [گره کامل] (https://ethereum.org/developers/docs/nodes-and-clients#full-node) به دست می آید.
+
+راه حل های مختلف در اینجا همه یکپارچگی عالی دارند، زیرا هش ها در L1 ارسال می شوند. با این حال، آنها دارای ضمانت های مختلف در دسترس بودن هستند.
+
+## پیش نیازها {#prerequisites}
+
+شما باید درک خوبی از [اصول بلاکچین] (/developers/docs/intro-to-ethereum/) داشته باشید. این صفحه همچنین فرض میکند که خواننده با [blocks](/developers/docs/blocks/)، [تراکنش ها](/developers/docs/transactions/) و سایر موضوعات مرتبط آشنا است.
+
+## حباب های EIP-4844 {#eip-4844-blobs}
+
+در شروع با [هاردفورک دنکان] (https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md)، بلاک چین اتریوم شامل [EIP-4844] است (https:// eips.ethereum.org/EIPS/eip-4844)، که به حباب های داده اتریوم با طول عمر محدود (در ابتدا حدود [18 روز]) اضافه می کند (https://github.com/ethereum/consensus-specs/blob/dev/specs) /deneb/p2p-interface.md#configuration)). این حباب ها جدا از [گس اجرا](/developers/docs/gas) قیمت گذاری می شوند، اگرچه از مکانیزم مشابهی استفاده می کنند. آنها یک راه ارزان برای ارسال داده های موقت هستند.
+
+مورد استفاده اصلی برای حباب های EIP-4844 این است که رولآپ ها تراکنش های خود را منتشر کنند. [رولآپهای خوشبینانه](/developers/docs/scaling/optimistic-rollups) باید تراکنشها را روی بلاکچینهای خود منتشر کنند. این تراکنشها باید در طول [دوره چالش](https://docs.optimism.io/connect/resources/glossary#challenge-period) در دسترس همه باشند تا اگر [ترتیبدهنده](https://docs.optimism.io/connect/resources/glossary#sequencer) رولآپ یک ریشه وضعیت نادرست را ارسال کند، [اعتبارسنجها](https://docs.optimism.io/connect/resources/glossary#validator) را قادر میسازد تا اشتباه را برطرف کنند.
+
+با این حال، هنگامی که دوره چالش سپری شد و ریشه حالت نهایی شد، هدف باقی مانده برای دانستن این تراکنش ها تکرار وضعیت فعلی زنجیره است. این حالت از گره های زنجیره ای نیز در دسترس است و به پردازش بسیار کمتری نیاز است. بنابراین، اطلاعات تراکنش همچنان باید در چند مکان، مانند [کاوشگران بلوک] (/developers/docs/data-and-analytics/block-explorers) حفظ شود، اما نیازی به پرداخت هزینه برای سطح مقاومت سانسوری که اتریوم ارائه می کند نیست.
+
+[رولآپهای دانش-صفر](/developers/docs/scaling/zk-rollups/#data-availability) همچنین دادههای تراکنش خود را ارسال میکنند تا دیگر گرهها بتوانند وضعیت موجود را تکرار کنند و اثبات اعتبار را تأیید کنند، اما باز هم این یک نیاز کوتاه مدت است.
+
+هنگام نوشتن پست در EIP-4844 یک وی (10-18 ETH) در هر بایت هزینه دارد، که در مقایسه با [21000 گس اجرا که هر تراکنش، از جمله تراکنشی که حبابها را پست میکند، هزینه دارد، ناچیز است](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). میتوانید قیمت فعلی EIP-4844 را در [blobscan.com] (https://blobscan.com/blocks) ببینید.
+
+در اینجا آدرس هایی برای مشاهده حباب های ارسال شده توسط برخی از مجموعه های معروف وجود دارد.
+
+| رولآپ | آدرس Mailbox |
+| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
+| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) |
+| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
+| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) |
+
+## کالدیتا {#calldata}
+
+Calldata به بایت های ارسال شده به عنوان بخشی از تراکنش اشاره دارد. به عنوان بخشی از رکورد دائمی بلاکچین در بلوک که شامل آن تراکنش است، ذخیره می شود.
+
+این ارزانترین روش برای قرار دادن دائمی داده ها در بلاکچین است. هزینه هر بایت یا 4 گس اجرا (اگر بایت صفر باشد) یا 16 گس (هر مقدار دیگر) است. اگر داده ها فشرده شوند، که یک روش استاندارد است، هر مقدار بایت به یک اندازه محتمل است، بنابراین میانگین هزینه تقریباً 15.95 گس در هر بایت است.
+
+در نوشتن قیمت ها 12 جیوی/گس و 2300 دلار/اتر است، که به این معنی است که هزینه تقریباً 45 سنت در هر کیلوبایت است. از آنجایی که این ارزانترین روش قبل از EIP-4844 بود، این روشی است که برای ذخیره اطلاعات تراکنش استفاده میشود، که باید برای [چالشهای خطا] در دسترس باشد (https://docs.optimism.io/stack/protocol/overview# اثبات عیب)، اما نیازی به دسترسی مستقیم روی زنجیره نیست.
+
+در اینجا آدرس هایی برای مشاهده تراکنش های ارسال شده توسط چند مجموعه معروف وجود دارد.
+
+| رولآپ | آدرس Mailbox |
+| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
+| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) |
+| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
+| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) |
+
+## خارج از زنجیره با مکانیسم های لایه 1 {#offchain-with-l1-mechs}
+
+بسته به دوراهی های امنیتی شما، ممکن است قابل قبول باشد که اطلاعات را در جای دیگری قرار دهید و از مکانیزمی استفاده کنید که تضمین کند داده ها در صورت نیاز در دسترس هستند. دو شرط برای این کار وجود دارد:
+
+1. یک [هش] (https://en.wikipedia.org/wiki/Cryptographic_hash_function) از دادهها را روی بلاکین پست کنید، که به آن _input commitment_ میگویند. این می تواند یک کلمه 32 بایتی باشد، بنابراین گران نیست. تا زمانی که تعهد ورودی در دسترس باشد، یکپارچگی تضمین میشود، زیرا یافتن دادههای دیگری که به همان مقدار هش شوند امکانپذیر نیست. بنابراین اگر داده های نادرست ارائه شود، می توان آن را شناسایی کرد.
+
+2. مکانیزمی داشته باشید که در دسترس بودن را تضمین کند. برای مثال، در [Redstone](https://redstone.xyz/docs/what-is-redstone) هر گرهی می تواند یک چالش در دسترس بودن ارسال کند. اگر ترتیبدهنده در مهلت مقرر به زنجیره پاسخ ندهد، تعهد ورودی کنار گذاشته میشود، بنابراین در نظر گرفته میشود که اطلاعات هرگز پست نشده است.
+
+این برای یک رولآپ خوشبینانه قابل قبول است زیرا ما در حال حاضر به داشتن حداقل یک تأیید کننده صادق برای ریشه حالت تکیه می کنیم. چنین تأیید کننده صادقی همچنین مطمئن می شود که داده هایی برای پردازش بلوک ها دارد و اگر اطلاعات در خارج از زنجیره در دسترس نباشد، چالش در دسترس بودن را صادر می کند. این نوع رولآپ خوشبینانه، [پلاسما](/developers/docs/scaling/plasma/) نامیده میشود.
+
+## کد قرارداد {#contract-code}
+
+اطلاعاتی که فقط باید یک بار نوشته شوند، هرگز بازنویسی نمی شوند و باید در زنجیره در دسترس باشند، می توانند به عنوان کد قرارداد ذخیره شوند. این بدان معنی است که ما یک "قرارداد هوشمند" با داده ها ایجاد می کنیم و سپس از [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) برای خواندن اطلاعات استفاده می کنیم. مزیت این است که کپی کردن کد نسبتاً ارزان است.
+
+به غیر از هزینه گسترش حافظه، «EXTCODECOPY» برای اولین دسترسی به قرارداد 2600 گس و برای نسخه های بعدی از همان قرارداد 100 گس به همراه 3 گس در هر کلمه 32 بایتی هزینه دارد. در مقایسه با calldata که 15.95 در هر بایت هزینه دارد، در آغاز حدود 200 بایت ارزانتر است. بر اساس [فرمول هزینه های گسترش حافظه] (https://www.evm.codes/about#memoryexpansion)، تا زمانی که به بیش از 4 مگابایت حافظه نیاز ندارید، هزینه گسترش حافظه کمتر از هزینه افزودن calldata است.
+
+البته این فقط هزینه _خواندن_ داده هاست. برای ایجاد قرارداد تقریباً 32000 گس + 200 گس برای هر بایت هزینه می شود. این روش تنها زمانی مقرون به صرفه است که اطلاعات یکسان در معاملات مختلف بارها خوانده شود.
+
+کد قرارداد تا زمانی که با '0xEF' شروع نشود می تواند بی معنی باشد. قراردادهایی که با «0xEF» شروع میشوند به عنوان [فرمت شی اتریوم] (https://notes.ethereum.org/@ipsilon/evm-object-format-overview) تفسیر میشوند که الزامات بسیار سختتری دارد.
+
+## رویدادها {#events}
+
+[رویدادها] (https://docs.alchemy.com/docs/solidity-events) توسط قراردادهای هوشمند منتشر میشوند و توسط نرمافزار خارج از زنجیره خوانده میشوند.
+مزیت آنها این است که کدهای آفلاین می توانند به رویدادها گوش دهند. هزینه [گس] (https://www.evm.codes/#a0?fork=cancun)، 375 به اضافه 8 گس در هر بایت داده است. در 12 گیگاوی/گس و 2300 دلار/اتر، این به یک سنت به اضافه 22 سنت در هر کیلوبایت ترجمه میشود.
+
+## ذخیرهسازی {#storage}
+
+قراردادهای هوشمند به [حافظه های دائمی] (https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) دسترسی دارند. با این حال، بسیار گران است. نوشتن یک کلمه 32 بایتی در یک اسلات از حافظه که قبلاً خالی بود، میتواند [22100 گس هزینه داشته باشد] (https://www.evm.codes/#55?fork=cancun). در 12 گیگاوی/گس و 2300 دلار/اتر،این حدود 61 سنت در هر عملیات نوشتن یا 19.5 دلار در هر کیلوبایت است.
+
+این گرانترین شکل ذخیرهسازی در اتریوم است.
+
+## خلاصه {#summary}
+
+این جدول تفاوت گزینه ها، مزایا و معایب آنها را خلاصه می کند.
+
+| نوع ذخیرهسازی | منبع دیتا | تضمین دسترسیپذیری | دسترسیپذیری آنچین | محدودیتهای دیگر |
+| -------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
+| بلابهای EIP-4844 | آفچین | ضمانت اتریوم برای [حدود 18 روز](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | فقط هش موجود است | |
+| دادهی فراخوانی (calldata) | آفچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | فقط در صورت نوشته شدن در قرارداد و در آن معامله در دسترس است | |
+| خارج از زنجیره ولی بهره گرفته از مکانیزم بلاکچین لایه 1 | آفچین | تضمین "یک تایید کننده صادق" در طول دوره چالش | فقط هش | تضمین شده توسط مکانیسم چالش، فقط در طول دوره چالش |
+| کد قرارداد | آنچین یا آفچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | بله | نوشته شده در یک آدرس "تصادفی"، نمی تواند با "0xEF" شروع شود |
+| رویدادها | آنچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | خیر | |
+| ذخیرهسازی | آنچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین و وضعیت فعلی تا زمانی که بازنویسی شود) | بله | |
diff --git a/public/content/translations/fa/developers/docs/data-availability/index.md b/public/content/translations/fa/developers/docs/data-availability/index.md
new file mode 100644
index 00000000000..ca4f63135b8
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-availability/index.md
@@ -0,0 +1,84 @@
+---
+title: دسترسی به دادهها
+description: مروری بر مشکلات و راه حل های مربوط به در دسترس بودن داده ها در اتریوم
+lang: fa
+---
+
+«اعتماد نکن، تایید کن» یک اصل رایج در اتریوم است. ایده این است که گره شما میتواند به طور مستقل صحت اطلاعاتی را که دریافت میکند با اجرای تمام تراکنشهای موجود در بلوکهایی که از همتایان دریافت میکنند تأیید کند تا اطمینان حاصل شود که تغییرات پیشنهادی دقیقاً با تغییرات محاسبهشده مستقل توسط گره مطابقت دارند. این بدان معناست که گرهها نباید به صادق بودن فرستندگان بلوک اعتماد کنند. در صورت عدم وجود داده، این امکان پذیر نیست.
+
+**در دسترس بودن داده** به اطمینان کاربر از اینکه داده های مورد نیاز برای تأیید یک بلوک واقعاً در دسترس همه شرکت کنندگان شبکه است، اشاره دارد. برای گرههای کامل در لایه 1 اتریوم، این کار نسبتاً ساده است. گره کامل یک کپی از تمام دادههای هر بلوک را دانلود میکند - دادهها _باید_ در دسترس باشند تا امکان دانلود وجود داشته باشد. بلوکی با داده های از دست رفته به جای اضافه شدن به بلاکچین، دور انداخته می شود. این "در دسترس بودن داده های زنجیره ای" است و یکی از ویژگی های بلاک چین های یکپارچه است. گره های کامل را نمی توان فریب داد تا تراکنش های نامعتبر را بپذیرند زیرا آنها هر تراکنش را برای خود دانلود و اجرا می کنند. با این حال، برای بلاک چینهای مدولار، رولآپ های لایه 2 و کلاینت های سبک، چشمانداز در دسترس بودن دادهها پیچیدهتر است و به برخی روشهای تأیید پیچیدهتر نیاز دارد.
+
+## پیشنیازها {#prerequisites}
+
+شما باید درک خوبی از [اصول بلاک چین](/developers/docs/intro-to-ethereum/)، به خصوص [مکانیسم های اجماع](/developers/docs/consensus-mechanisms/) داشته باشید. این صفحه همچنین فرض میکند که خواننده با [بلوکها](/developers/docs/blocks/)، [تراکنش ها](/developers/docs/transactions/)، [گرهها](/developers/docs/nodes-and-clients/)، [راهحلهای مقیاسبندی](/developers/docs/scaling/) و سایر موضوعات مرتبط آشنا است.
+
+## مشکل در دسترس بودن داده ها {#the-data-availability-problem}
+
+مشکل در دسترس بودن داده ها این است که باید به کل شبکه ثابت شود که شکل خلاصه شده برخی از داده های تراکنش که به بلاک چین اضافه می شود، واقعاً مجموعه ای از تراکنش های معتبر را نشان می دهد، اما بدون نیاز به همه گره ها برای دانلود همه داده ها. دادههای کامل تراکنش برای تأیید مستقل بلوکها ضروری است، اما نیاز به تمام گرهها برای دانلود همه دادههای تراکنش، مانعی برای مقیاسپذیری است. هدف راهحلهای مشکل در دسترس بودن داده، ارائه تضمینهای کافی مبنی بر این است که دادههای کامل تراکنش برای تأیید در دسترس شرکتکنندگانی از شبکه قرار گرفته است که دادهها را برای خود دانلود و ذخیره نمیکنند.
+
+[گرههای سبک](/developers/docs/nodes-and-clients/light-clients) و [رولآپ های لایه 2](/developers/docs/scaling) نمونههای مهمی از شرکتکنندگان در شبکه هستند که به تضمینهای قوی در دسترس بودن داده نیاز دارند اما نمیتوانند دادههای تراکنش را برای خود دانلود و پردازش کنند. اجتناب از دانلود دادههای تراکنش چیزی است که گرههای سبک را سبک میکند و به رولآپ ها امکان میدهد راهحلهای مقیاسپذیری مؤثری باشند.
+
+در دسترس بودن داده ها همچنین یک نگرانی مهم برای کلاینت های [«بی حالت»](/roadmap/statelessness) اتریوم در آینده است که برای تأیید بلوک ها نیازی به دانلود و ذخیره داده های حالت ندارند. کلاینت های بی حالت هنوز باید مطمئن باشند که دادهها _جایی_ در دسترس هستند و به درستی پردازش شدهاند.
+
+## راه حل های در دسترس بودن داده ها {#data-availability-solutions}
+
+### نمونهگیری در دسترس بودن داده (DAS) {#data-availability-sampling}
+
+نمونهگیری در دسترس بودن داده (DAS) روشی برای شبکه برای بررسی در دسترس بودن دادهها بدون اعمال فشار زیاد بر هر گره منفرد است. هر گره (از جمله گرههای بدون شرطبندی) تعدادی زیرمجموعه کوچک و تصادفی انتخاب شده از کل دادهها را دانلود میکند. دانلود موفقیت آمیز نمونه ها با اطمینان بالا تأیید می کند که همه داده ها در دسترس هستند. این به کدگذاری پاک کردن دادهها متکی است، که یک مجموعه داده معین را با اطلاعات اضافی گسترش میدهد (روش انجام این کار به این صورت است که تابعی به نام _چند جملهای_ را بر روی دادهها قرار میدهد و آن چند جملهای را در نقاط اضافی ارزیابی میکند). این اجازه می دهد تا داده های اصلی در صورت لزوم از داده های اضافی بازیابی شوند. نتیجه این ایجاد داده این است که اگر _هیچ_ کدام از دادههای اصلی در دسترس نباشد، _نیمی_ از دادههای توسعهیافته از دست خواهند رفت! مقدار نمونه های داده دانلود شده توسط هر گره را می توان تنظیم کرد به طوری که _به شدت_ احتمال دارد که حداقل یکی از قطعات داده نمونه برداری شده توسط هر مشتری وجود نداشته باشد _اگر_ کمتر از نیمی از داده ها واقعاً در دسترس باشد.
+
+DAS برای اطمینان از اینکه اپراتورهای رولآپ دادههای تراکنش خود را پس از اجرای [دنکشاردینگ کامل](/roadmap/danksharding/#what-is-danksharding) در دسترس قرار میدهند، استفاده میشود. گره های اتریوم به صورت تصادفی از داده های تراکنش ارائه شده در حباب ها با استفاده از طرح افزونگی که در بالا توضیح داده شد نمونه برداری می کنند تا اطمینان حاصل شود که همه داده ها وجود دارند. همین تکنیک همچنین میتواند برای اطمینان از اینکه تولیدکنندگان بلوک تمام دادههای خود را برای ایمن کردن کلاینت های سبک در دسترس قرار میدهند، استفاده شود. به طور مشابه، تحت [جداسازی پیشنهاددهنده-سازنده](/roadmap/pbs) بلوک، فقط سازنده بلوک باید کل یک بلوک را پردازش کند - اعتبارسنج های دیگر با استفاده از نمونه گیری در دسترس بودن داده ها را تأیید می کنند.
+
+### کمیته های در دسترس بودن داده ها {#data-availability-committees}
+
+کمیته های در دسترس بودن داده ها (DACها) طرف های مورد اعتمادی هستند که در دسترس بودن داده ها را ارائه می دهند یا آن را تأیید می کنند. DAC ها را می توان به جای [یا در ترکیب با](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS استفاده کرد. ضمانتهای امنیتی که با کمیتهها ارائه میشوند به تشکیلات خاص بستگی دارد. برای مثال، اتریوم از زیرمجموعههای نمونهبرداری تصادفی اعتبارسنج ها برای تأیید در دسترس بودن دادهها برای گرههای سبک استفاده میکند.
+
+DAC ها نیز توسط برخی از ولیدیومها استفاده می شوند. DAC مجموعه ای از گره های قابل اعتماد است که نسخه هایی از داده ها را به صورت آفلاین ذخیره می کند. DAC موظف است در صورت بروز اختلاف، داده ها را در دسترس قرار دهد. اعضای DAC همچنین امضاهای آنچین را منتشر میکنند تا ثابت کنند که دادههای مذکور واقعاً در دسترس هستند. برخی ولیدیومها را با یک سیستم اعتبارسنج اثبات سهام (PoS) جایگزین می کنند. در اینجا، هر کسی میتواند اعتبارسنج شود و دادهها را خارج از زنجیره ذخیره کند. با این حال، آنها باید یک "مسیر" ارائه کنند که در یک قرارداد هوشمند سپرده می شود. در صورت رفتار مخرب، مانند مخفی نگه داشتن اطلاعات توسط اعتبارسنج، پیوند را می توان کاهش داد. کمیته های در دسترس بودن داده های اثبات سهام به طور قابل توجهی از DAC های معمولی ایمن تر هستند زیرا مستقیماً رفتار صادقانه را تشویق می کنند.
+
+## در دسترس بودن داده ها و گره های سبک {#data-availability-and-light-nodes}
+
+[گره های سبک](/developers/docs/nodes-and-clients/light-clients) باید صحت هدرهای بلوکی را که دریافت می کنند بدون بارگیری داده های بلوک تأیید کنند. هزینه این سَبُکی نیز ناتوانی در تأیید مستقل هدرهای بلوک با اجرای مجدد تراکنش ها به صورت محلی به روشی است که گره های کامل انجام می دهند.
+
+گره های سبک اتریوم به مجموعه های تصادفی 512 اعتبارسنج که به _کمیته همگام سازی_ اختصاص داده شده اند اعتماد دارند. کمیته همگامسازی بهعنوان یک DAC عمل میکند که با استفاده از یک امضای رمزنگاری به کلاینت های سبک میگوید که دادههای سر صحیح هستند. هر روز، کمیته همگام سازی رفرش می شود. هر سرصفحه بلوک به گرههای سیک هشدار میدهد که کدام اعتبارسنج ها باید بلوک _بعدی_ را امضا کنند، بنابراین نمیتوان آنها را فریب داد تا به یک گروه مخرب که وانمود میکنند کمیته همگامسازی واقعی هستند، اعتماد کنند.
+
+با این حال، چه اتفاقی میافتد اگر یک مهاجم به نحوی _موفق_ شود هدر بلوک مخرب را به کلاینت سبک ارسال کند و آنها را متقاعد کند که توسط یک کمیته همگامسازی صادقانه امضا شده است؟ در آن صورت، مهاجم میتواند تراکنشهای نامعتبر را شامل شود و کلاینت سبک کورکورانه آنها را میپذیرد، زیرا آنها بهطور مستقل تمام تغییرات حالت خلاصهشده در هدر بلوک را بررسی نمیکنند. برای محافظت در برابر این، کلاینت سبک می تواند از اثبات های تقلب استفاده کند.
+
+روش کار این اثبات های تقلب به این صورت است که یک گره کامل، با مشاهده یک انتقال حالت نامعتبر که در اطراف شبکه شایعه می شود، می تواند به سرعت یک قطعه کوچک از داده را تولید کند که نشان دهد یک انتقال حالت پیشنهادی احتمالاً نمی تواند از مجموعه معینی از تراکنش ها ناشی شود و آن داده ها را برای همتایان پخش کند. گرههای سبک میتوانند آن موارد اثبات تقلب را انتخاب کرده و از آنها برای حذف هدرهای بلوک بد استفاده کنند، و اطمینان حاصل کنند که در زنجیره صادقانه مشابه گرههای کامل باقی میمانند.
+
+این متکی بر گره های کامل است که به داده های تراکنش کامل دسترسی دارند. مهاجمی که یک هدر بلوک بد پخش میکند و همچنین نمیتواند دادههای تراکنش را در دسترس قرار دهد، میتواند از ایجاد اثبات تقلب توسط گرههای کامل جلوگیری کند. گرههای کامل ممکن است بتوانند هشداری درباره یک بلوک بد ارسال کنند، اما نمیتوانند از هشدار خود با اثبات پشتیبان بگیرند، زیرا دادهها برای تولید اثبات در دسترس نبودند!
+
+راه حل این مشکل در دسترس بودن داده ها DAS است. گره های سبک، تکه های تصادفی بسیار کوچکی از داده های حالت کامل را دانلود می کنند و از نمونه ها برای تأیید اینکه مجموعه داده کامل در دسترس است استفاده می کنند. احتمال واقعی فرض نادرست در دسترس بودن کامل داده ها پس از دانلود N قطعه تصادفی را می توان محاسبه کرد ([برای 100 تکه این شانس 10^-30 است](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)، یعنی فوقالعاده بعید است).
+
+حتی در این سناریو، حملاتی که تنها چند بایت را در خود نگه میدارند، میتوانند توسط کلاینت هایی که درخواستهای داده تصادفی میکنند مورد توجه قرار نگیرند. کدگذاری پاک کردن این مشکل را با بازسازی قطعات کوچک از دست رفته داده که می تواند برای بررسی تغییرات حالت پیشنهادی مورد استفاده قرار گیرد، برطرف می کند. سپس میتوان با استفاده از دادههای بازسازیشده، یک اثبات تقلب ایجاد کرد و از پذیرش هدرهای بد توسط گرههای سبک جلوگیری کرد.
+
+**توجه:** DAS و اثبات تقلب هنوز برای کلاینت های سبک اتریوم اثبات سهام اجرا نشده اند، اما در نقشه راه هستند و به احتمال زیاد به شکل اثبات های مبتنی بر ZK-SNARK هستند. کلاینت های سبک امروزی به شکلی از DAC متکی هستند: آنها هویت کمیته همگامسازی را تأیید میکنند و سپس به هدرهای بلوک امضا شدهای که دریافت میکنند اعتماد میکنند.
+
+## در دسترس بودن داده ها و رولآپ های لایه2 {#data-availability-and-layer-2-rollups}
+
+[راهحلهای مقیاسبندی لایه2](/layer-2/)، مانند [رولآپ ها](/glossary/#rollups)، هزینههای تراکنش را کاهش میدهند و با پردازش تراکنشهای خارج از زنجیره، توان عملیاتی اتریوم را افزایش میدهند. تراکنشهای رولآپ فشرده می شوند و به صورت دستهای در اتریوم پست میشوند. دسته ها هزاران تراکنش خارج از زنجیره فردی را در یک تراکنش در اتریوم نشان می دهند. این باعث کاهش تراکم در لایه پایه و کاهش هزینه ها برای کاربران می شود.
+
+با این حال، تنها زمانی میتوان به تراکنشهای «خلاصه» ارسالشده در اتریوم اعتماد کرد که تغییر حالت پیشنهادی بهطور مستقل تأیید شود که نتیجه اعمال همه تراکنشهای خارج از زنجیره است. اگر اپراتورهای رولآپ دادههای تراکنش را برای این راستیآزمایی در دسترس قرار ندهند، ممکن است دادههای نادرستی را به اتریوم ارسال کنند.
+
+[رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/) دادههای تراکنش فشرده را به اتریوم ارسال میکنند و برای مدتی (معمولاً 7 روز) منتظر میمانند تا به تأییدکنندگان مستقل اجازه بررسی دادهها را بدهد. اگر کسی مشکلی را شناسایی کند، می تواند یک اثبات تقلب ایجاد کند و از آن برای به چالش کشیدن رولآپ استفاده کند. این باعث می شود زنجیره به عقب برگردد و بلوک نامعتبر را حذف کند. این تنها در صورتی امکان پذیر است که داده ها در دسترس باشند. در حال حاضر، دو راه وجود دارد که رولآپ های خوشبینانه داده های تراکنش را به L1 ارسال کنند. برخی رولآپ ها دادهها را بهصورت دائمی بهعنوان `CALLDATA` در دسترس قرار میدهند که بهطور دائم در زنجیره زندگی میکنند. با اجرای EIP-4844، برخی از رولآپ ها دادههای تراکنش خود را به جای ذخیرهسازی حباب های ارزانتر ارسال میکنند. این ذخیره سازی دائمی نیست. تأییدکنندگان مستقل باید در عرض 18 روز قبل از حذف داده ها از لایه 1 اتریوم، حباب ها را استعلام کنند و چالش های خود را مطرح کنند. در دسترس بودن داده ها فقط توسط پروتکل اتریوم برای آن پنجره کوتاه ثابت تضمین شده است. پس از آن، مسئولیت سایر موجودات در اکوسیستم اتریوم می شود. هر گره می تواند در دسترس بودن داده ها را با استفاده از DAS تأیید کند، یعنی با دانلود نمونه های کوچک و تصادفی از داده های حباب.
+
+[رولآپ های دانش صفر (ZK)](/developers/docs/scaling/zk-rollups) نیازی به ارسال دادههای تراکنش ندارند زیرا [شواهد اعتبار دانش صفر](/glossary/#zk-proof) صحت انتقال حالت را تضمین میکند. با این حال، در دسترس بودن داده ها هنوز یک مشکل است زیرا ما نمی توانیم عملکرد رولآپ دانش صفر (یا تعامل با آن) را بدون دسترسی به داده های وضعیت آن تضمین کنیم. به عنوان مثال، اگر اپراتور جزئیاتی را درباره حالت رولآپ مخفی کند، کاربران نمیتوانند موجودی خود را بدانند. همچنین، آنها نمی توانند با استفاده از اطلاعات موجود در یک بلوک جدید اضافه شده، به روز رسانی حالت را انجام دهند.
+
+## در دسترس بودن داده در مقابل قابلیت بازیابی داده ها {#data-availability-vs-data-retrievability}
+
+در دسترس بودن داده ها با قابلیت بازیابی داده ها متفاوت است. در دست داشتن داده ها با قابلیت بازیابی ها متفاوت است. لزوماً به این معنی نیست که داده ها برای همیشه قابل دسترسی هستند.
+
+قابلیت بازیابی داده ها توانایی گره ها برای بازیابی _اطلاعات تاریخی_ از بلاک چین است. این داده تاریخی برای تأیید بلوک های جدید مورد نیاز نیست، فقط برای همگام سازی گره های کامل از بلوک پیدایش یا ارائه درخواست های تاریخی خاص مورد نیاز است.
+
+پروتکل اصلی اتریوم در درجه اول مربوط به در دسترس بودن داده ها است، نه قابلیت بازیابی داده ها. قابلیت بازیابی دادهها را میتوان توسط جمعیت کوچکی از گرههای بایگانی که توسط اشخاص ثالث اجرا میشوند فراهم کرد، یا میتوان آن را با استفاده از ذخیرهسازی فایل غیرمتمرکز مانند [شبکه پورتال](https://www.ethportal.net/) در سراسر شبکه توزیع کرد.
+
+## اطلاعات بیشتر {#further-reading}
+
+- [WTF قابلیت دسترسی داده است؟](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f)
+- [قابلیت دسترسی داده چیست؟](https://coinmarketcap.com/alexandria/article/what-is-data-availability)
+- [دورنمای قابلیت دسترسی داده اتریوم خارج زنجیره](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/)
+- [مقدمهای بر بررسیهای قابلیت دسترسی داده](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)
+- [شرحی بر شاردینگ + پیشنهاد DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
+- [یادداشتی بر قابلیت دسترسی داده و کدگذاری پاک شدن](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them)
+- [کمیته های در دسترس بودن داده ها.](https://medium.com/starkware/data-availability-e5564c416424)
+- [کمیته های در دسترس بودن داده های اثبات سهام.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)
+- [راه حل هایی برای مشکل بازیابی داده ها](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding)
+- [قابلیت دسترسی داده ها یا: رولآپها چطور یاد گرفتند دیگر نگران نباشند و اتریوم را دوست داشته باشند](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/index.md
new file mode 100644
index 00000000000..1dbed4fd9f1
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/index.md
@@ -0,0 +1,32 @@
+---
+title: ساختار دادهها و رمزگذاری
+description: مروری بر ساختارهای داده بنیادی اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+اتریوم حجم زیادی از داده ها را ایجاد، ذخیره و انتقال می دهد. این دادهها باید به روشهای استاندارد شده و با حافظه کارآمد قالببندی شوند تا به هر کسی اجازه دهد روی سختافزار نسبتاً درجه متوسط مصرفکننده [گرهی را اجرا کند](/run-a-node/). برای رسیدن به این هدف، چندین ساختار داده خاص در پشته اتریوم استفاده می شود.
+
+## پیشنیازها {#prerequisites}
+
+شما باید با اصول اتریوم و [نرم افزار کاربر](/developers/docs/nodes-and-clients/) آشنا باشید. آشنایی با لایه شبکه و [وایت پیپر اتریوم](/whitepaper/) توصیه می شود.
+
+## ساختارهای داده {#data-structures}
+
+### درخت مرکل پاتریشیا {#patricia-merkle-tries}
+
+درخت های مرکل پاتریشیا ساختارهایی هستند که جفتهای مقدار کلید را در یک آزمون قطعی و رمزنگاری تأیید شده رمزگذاری میکنند. این ها به طور گسترده در لایه اجرایی اتریوم استفاده می شوند.
+
+[جزئیات بیشتر درباره درخت های مرکل پاتریشیا](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
+
+### پیشوند طول بازگشتی {#recursive-length-prefix}
+
+پیشوند طول بازگشتی (RLP) یک روش سریال سازی است که به طور گسترده در لایه اجرایی اتریوم استفاده می شود.
+
+[جزئیات بیشتر درباره RLP](/developers/docs/data-structures-and-encoding/rlp)
+
+### سریال سازی ساده {#simple-serialize}
+
+سریال سازی ساده (SSZ)، به دلیل سازگاری آن با مرکلیزاسیون، فرمت سریال سازی غالب در لایه اجماع اتریوم است.
+
+[جزئیات بیشتر درباره SSZ](/developers/docs/data-structures-and-encoding/ssz)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
new file mode 100644
index 00000000000..ea7754e1a20
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
@@ -0,0 +1,323 @@
+---
+title: درخت مرکل پاتریشیا
+description: مقدمه ای بر درخت مرکل پاتریشیا.
+lang: fa
+sidebarDepth: 2
+---
+
+حالت اتریوم (مجموع همه حسابها، موجودیها و قراردادهای هوشمند)، در نسخه خاصی از ساختار دادهها که عموماً در علوم کامپیوتر به عنوان درخت مرکل شناخته میشود، کدگذاری میشود. این ساختار برای بسیاری از برنامههای کاربردی در رمزنگاری مفید است، زیرا یک رابطه قابل تأیید بین تمام تکههای دادههای درهمتنیده در درخت ایجاد میکند، که منجر به یک مقدار **ریشه** میشود که میتواند برای اثبات چیزهایی در مورد دادهها استفاده شود.
+
+ساختار دادههای اتریوم یک «درخت مرکل-پاتریشیا اصلاحشده» است که به این دلیل نامگذاری شده است که برخی از ویژگیهای PATRICIA (الگوریتم عملی برای بازیابی اطلاعات کدگذاریشده به صورت الفبایی) را به عاریت گرفته و به این دلیل که برای باز**آزمایش**داده های کارآمد مواردی که حالت اتریوم را تشکیل می دهند طراحی شده است.
+
+درخت مرکل-پاتریشیا متغیر قطعی و از نظر رمزنگاری قابل تأیید است: تنها راه برای تولید ریشه حالت، محاسبه آن از تک تک تکه های حالت است، و دو حالت یکسان را می توان به راحتی با مقایسه هش ریشه و هش هایی که منجر به آن شدهاند ثابت کرد (_اثبات مرکل_). برعکس، هیچ راهی برای ایجاد دو حالت مختلف با هش ریشه یکسان وجود ندارد، و هر تلاشی برای تغییر حالت با مقادیر مختلف منجر به یک هش ریشه متفاوت خواهد شد. از نظر تئوری، این ساختار «جام مقدس» کارایی `O(log(n))` را برای درجها، جستجوها و حذفها فراهم میکند.
+
+در آینده نزدیک، اتریوم قصد دارد به ساختار [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees) مهاجرت کند، که بسیاری از فرصتهای جدید را برای بهبود پروتکلهای آینده باز خواهد کرد.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای درک بهتر این صفحه، داشتن دانش اولیه در مورد [هش](https://en.wikipedia.org/wiki/Hash_function)، [درخت مرکل](https://en.wikipedia.org/wiki/Merkle_tree)، [درخت ها](https://en.wikipedia.org/wiki/Trie) و
+سریال سازی3 مفید خواهد بود. >. این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
+
+
+
+## درختهای پایه رادیکس {#basic-radix-tries}
+
+در یک درخت پایه رادیکس، هر گره به صورت زیر به نظر می رسد:
+
+
+
+```
+ [i_0, i_1 ... i_n, value]
+```
+
+
+در حالی که `i_0 ... i_n` نمادهای الفبا (اغلب باینری یا هگزا) را نشان می دهد، `مقدار` مقدار پایانی در گره است و مقادیر در ` i_0، i_1 ... i_n` اسلاتها یا `NULL` یا اشارهگر به (در مورد ما، هشهای) گرههای دیگر هستند. این یک ذخیره پایه `(کلید، مقدار)` را تشکیل می دهد.
+
+فرض کنید میخواهید از یک ساختار داده درخت رادیکس برای تداوم سفارش روی مجموعهای از جفتهای مقدار کلیدی استفاده کنید. برای یافتن مقداری که در حال حاضر به کلید `dog` در درخت نگاشت شده است، ابتدا `dog` را به حروف الفبا تبدیل کنید (به `64 6f 67` بدهید) و سپس سعی کنید در درخت پایین بیایید تا مقدار را پیدا کنید. یعنی با جستجوی هش ریشه در یک DB کلید/مقدار مسطح برای یافتن گره ریشه درخت شروع میکنید. این امر، به صورت آرایه ای از کلیدها نشان داده می شود که به گره های دیگر اشاره می کنند. میتوانید از مقدار شاخص `6` به عنوان کلید استفاده کنید و آن را در کلید/مقدار مسطح DB جستجو کنید تا گره را یک سطح پایین بیاورید. سپس index `4` را برای جستجوی مقدار بعدی انتخاب کنید، سپس شاخص `6` را انتخاب کنید و به همین ترتیب، تا زمانی که مسیر را دنبال کردید: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`، شما مقدار گره را جستجو می کنید و نتیجه را نشان میدهید.
+
+بین جستجوی چیزی در "درخت" و کلید/مقدار مسطح زیرین "DB" تفاوت وجود دارد. هر دو ترتیبات کلید/مقدار را تعریف می کنند، اما DB زیربنایی می تواند یک جستجوی سنتی یک مرحله ای از یک کلید را انجام دهد. جستجوی یک کلید در درخت نیاز به جستجوهای متعدد DB زیربنایی برای رسیدن به مقدار نهایی شرح داده شده در بالا دارد. اجازه دهید به دومی به عنوان `مسیر` برای رفع ابهام اشاره کنیم.
+
+عملیات به روز رسانی و حذف برای درختهای radix را می توان به صورت زیر تعریف کرد:
+
+
+
+```
+ def update(node,path,value):
+ curnode = db.get(node) if node else [ NULL ] * 17
+ newnode = curnode.copy()
+ if path == '':
+ newnode[-1] = value
+ else:
+ newindex = update(curnode[path[0]],path[1:],value)
+ newnode[path[0]] = newindex
+ db.put(hash(newnode),newnode)
+ return hash(newnode)
+
+ def delete(node,path):
+ if node is NULL:
+ return NULL
+ else:
+ curnode = db.get(node)
+ newnode = curnode.copy()
+ if path == '':
+ newnode[-1] = NULL
+ else:
+ newindex = delete(curnode[path[0]],path[1:])
+ newnode[path[0]] = newindex
+
+ if all(x is NULL for x in newnode):
+ return NULL
+ else:
+ db.put(hash(newnode),newnode)
+ return hash(newnode)
+```
+
+
+درخت ریشه «مرکل» با پیوند دادن گرهها با استفاده از هش رمزنگاری ایجاد شده قطعی ساخته میشود. این آدرس دهی محتوا (در کلید/مقدار DB `key == keccak256(rlp(مقدار))`) تضمین یکپارچگی رمزنگاری داده های ذخیره شده را فراهم می کند. اگر هش ریشه یک درخت داده شده به طور عمومی شناخته شده باشد، هرکسی که به دادههای برگ زیرین دسترسی داشته باشد، میتواند با ارائه هشهای هر گره که مقدار خاصی را به ریشه درخت میپیوندد، اثبات کند که سعی میکند یک مقدار معین را در یک مسیر خاص اضافه میکند.
+
+برای یک مهاجم غیرممکن است که اثباتی برای یک جفت `(مسیر، مقدار)` ارائه دهد که وجود ندارد، زیرا هش ریشه در نهایت بر اساس همه هش های زیر آن است. هر گونه تغییر اساسی، هش ریشه را تغییر می دهد. میتوانید هش را بهعنوان نمایش فشردهای از اطلاعات ساختاری در مورد دادهها در نظر بگیرید، که با محافظت پیشتصویر تابع درهمسازی ایمن شده است.
+
+ما به یک واحد اتمی یک درخت ریشه (مثلاً یک کاراکتر هگز یا عدد باینری 4 بیتی) به عنوان "نیبل" اشاره خواهیم کرد. همانطور که در بالا توضیح داده شد، در حین پیمودن یک مسیر یک نوبت، گرهها میتوانند حداکثر به 16 فرزند اشاره داشته باشند اما یک عنصر `مقدار` را شامل میشوند. بنابراین ما آنها را به صورت آرایه ای به طول 17 نشان می دهیم. ما این آرایه های 17 عنصری را "گره های شاخه ای" می نامیم.
+
+
+
+## درخت مرکل پاتریشیا {#merkle-patricia-trees}
+
+درختهای رادیکس یک محدودیت عمده دارند: ناکارآمد هستند. اگر می خواهید یک پیوند `(مسیر، مقدار)` را در جایی که مسیر، مانند اتریوم، 64 کاراکتر طول دارد (تعداد nibble ها در `bytes32`) ذخیره کنید، به بیش از یک کیلوبایت فضای اضافی برای ذخیره یک سطح در هر کاراکتر نیاز خواهیم داشت، و هر جستجو یا حذف 64 مرحله کامل طول خواهد کشید. درخت پاتریشیا معرفی شده در ادامه این مشکل را حل می کند.
+
+
+
+### بهينه سازی {#optimization}
+
+یک گره در درخت مرکل پاتریشیا یکی از موارد زیر است:
+
+1. `NULL` (به عنوان رشته خالی نمایش داده می شود)
+2. `شاخه` یک گره 17 موردی `[ v0 ... v15, vt ]`
+3. `برگ` یک گره 2 موردی `[ encodedPath، مقدار ]`
+4. `افزونه` یک گره 2 موردی `[ encodedPath, key ]`
+
+با 64 مسیر کاراکتر، اجتناب ناپذیر است که پس از عبور از چند لایه اول سعی کنید، به گره ای برسید که در آن مسیر واگرا حداقل برای بخشی از مسیر پایین وجود نداشته باشد. برای جلوگیری از ایجاد حداکثر 15 گره `NULL` پراکنده در طول مسیر، با راهاندازی یک گره `افزونه` به شکل `[ encodedPath, key ] مسیر فرود را میانبر میکنیم`، جایی که `encodedPath` حاوی "مسیر جزئی" برای رد شدن از پیش است (با استفاده از یک رمزگذاری فشرده که در زیر توضیح داده شده است)، و `کلید` برای جستجوی DB بعدی است.
+
+برای یک گره `برگ`، که میتوان آن را با یک پرچم در اولین نیبل `encodedPath` علامتگذاری کرد، مسیر تمام قطعات مسیر گره قبلی را رمزگذاری می کند و ما می توانیم `مقدار` را مستقیماً جستجو کنیم.
+
+با این حال، این بهینهسازی بالا باعث ایجاد ابهام میشود.
+
+هنگام پیمایش مسیرها در نیبل، ممکن است در نهایت با تعداد فرد نیبل برای پیمایش مواجه شویم، اما به این دلیل که همه داده ها در قالب `بایت` ذخیره می شوند. نمی توان بین، به عنوان مثال، nibble `1` و nibbles `01` تفاوت قائل شد (هر دو باید به عنوان `<01>` ذخیره شوند). برای تعیین طول فرد، مسیر جزئی با یک پرچم پیشوند داده می شود.
+
+
+
+### مشخصات: رمزگذاری فشرده دنباله هگزا با پایان دهنده اختیاری {#specification}
+
+علامت گذاری _طول مسیر جزئی باقیمانده فرد در مقابل زوج_ و _گره برگ در مقابل پسوند_ همانطور که در بالا توضیح داده شد در اولین نوک مسیر جزئی هر گره 2 موردی قرار دارد. آنها به موارد زیر منجر می شوند:
+
+ hex char bits | node type partial path length
+ ----------------------------------------------------------
+ 0 0000 | extension even
+ 1 0001 | extension odd
+ 2 0010 | terminating (leaf) even
+ 3 0011 | terminating (leaf) odd
+
+
+حتی برای طول مسیر باقیمانده (`0` یا `2`)، یک نوک `0` "padding" دیگر همیشه در پی میآید.
+
+
+
+```
+ def compact_encode(hexarray):
+ term = 1 if hexarray[-1] == 16 else 0
+ if term: hexarray = hexarray[:-1]
+ oddlen = len(hexarray) % 2
+ flags = 2 * term + oddlen
+ if oddlen:
+ hexarray = [flags] + hexarray
+ else:
+ hexarray = [flags] + [0] + hexarray
+ // hexarray now has an even length whose first nibble is the flags.
+ o = ''
+ for i in range(0,len(hexarray),2):
+ o += chr(16 * hexarray[i] + hexarray[i+1])
+ return o
+```
+
+
+مثال ها:
+
+
+
+```
+ > [ 1, 2, 3, 4, 5, ...]
+ '11 23 45'
+ > [ 0, 1, 2, 3, 4, 5, ...]
+ '00 01 23 45'
+ > [ 0, f, 1, c, b, 8, 10]
+ '20 0f 1c b8'
+ > [ f, 1, c, b, 8, 10]
+ '3f 1c b8'
+```
+
+
+در اینجا کد توسعه یافته برای گرفتن یک گره در درخت مرکل پاتریشیا آمده است:
+
+
+
+```
+ def get_helper(node,path):
+ if path == []: return node
+ if node = '': return ''
+ curnode = rlp.decode(node if len(node) < 32 else db.get(node))
+ if len(curnode) == 2:
+ (k2, v2) = curnode
+ k2 = compact_decode(k2)
+ if k2 == path[:len(k2)]:
+ return get(v2, path[len(k2):])
+ else:
+ return ''
+ elif len(curnode) == 17:
+ return get_helper(curnode[path[0]],path[1:])
+
+ def get(node,path):
+ path2 = []
+ for i in range(len(path)):
+ path2.push(int(ord(path[i]) / 16))
+ path2.push(ord(path[i]) % 16)
+ path2.push(16)
+ return get_helper(node,path2)
+```
+
+
+
+
+### درخت نمونه {#example-trie}
+
+فرض کنید ما درختی می خواهیم حاوی چهار جفت مسیر/مقدار `('do', 'verb')`, `('dog', 'puppy')`, `(' doge، «coins»)`، `(«horse»، «stallion»)`.
+
+ابتدا، هم مسیرها و هم مقادیر را به `بایت` تبدیل می کنیم. در زیر، نمایشهای واقعی بایت برای _مسیرها_ با > نشان داده میشوند، اگرچه _مقادیر_ که برای درک آسان تر همچنان به صورت رشتهها`` نشان داده میشوند (آنها نیز در واقع `بایت` خواهند بود):
+
+
+
+```
+ <64 6f> : 'verb'
+ <64 6f 67> : 'puppy'
+ <64 6f 67 65> : 'coins'
+ <68 6f 72 73 65> : 'stallion'
+```
+
+
+اکنون، ما چنین درختی را با جفتهای کلید/مقدار زیر در DB زیرین میسازیم:
+
+
+
+```
+ rootHash: [ <16>, hashA ]
+ hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
+ hashB: [ <00 6f>, hashC ]
+ hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
+ hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
+```
+
+
+هنگامی که یک گره در داخل گره دیگری ارجاع داده می شود، آنچه شامل می شود `H(rlp.encode(node))` است، که در آن `H(x) = keccak256(x) اگر len(x) > = 32 else x` و `rlp.encode` تابع رمزگذاری [RLP](/developers/docs/data-structures-and-encoding/rlp) است.
+
+توجه داشته باشید که هنگام بهروزرسانی یک درخت، باید جفت کلید/مقدار `(keccak256(x)، x)` را در یک جدول جستجوی دائمی ذخیره کنید _اگر_ گره تازه ایجاد شده دارای طول >= 32 باشد. با این حال، اگر گره کوتاهتر از آن باشد، نیازی به ذخیره چیزی نیست، زیرا تابع f(x) = x قابل برگشت است.
+
+
+
+## درخت ها در اتریوم {#tries-in-ethereum}
+
+تمام درخت های مرکل در لایه اجرایی اتریوم از درخت مرکل پاتریشیا استفاده میکنند.
+
+از یک سر بلوک 3 ریشه از 3 مورد از این درخت ها وجود دارد.
+
+1. stateRoot
+2. transactionsRoot
+3. receiptsRoot
+
+
+
+### درخت حالت {#state-trie}
+
+یک درخت حالت جهانی وجود دارد و هر بار که کلاینت یک بلوک را پردازش می کند، به روز می شود. در آن، یک `مسیر` همیشه: `keccak256(ethereumAddress)` و یک `مقدار` همیشه: `rlp(ethereumAccount)` است. به طور خاص، `حساب` اتریوم یک آرایه 4 موردی از `[nonce,balance,storageRoot,codeHash]` است. در این مرحله، شایان ذکر است که این `storageRoot` ریشه یکی دیگر از درخت های پاتریشیا است:
+
+
+
+### درخت حافظه {#storage-trie}
+
+درخت Storage جایی است که _همه_ دادههای قرارداد زندگی میکنند. برای هر حساب یک فضای ذخیره سازی جداگانه وجود دارد. برای بازیابی مقادیر در موقعیتهای ذخیرهسازی خاص در یک آدرس معین، آدرس ذخیره، موقعیت عدد صحیح دادههای ذخیرهشده در حافظه و شناسه بلوک مورد نیاز است. سپس میتوان آنها را بهعنوان آرگومان به `eth_getStorageAt` تعریفشده در JSON-RPC API ارسال کرد، بهعنوان مثال: برای بازیابی داده ها در اسلات ذخیره سازی 0 برای آدرس `0x295a70b2de5e3953354a6a8344e616ed314d7251`:
+
+
+
+```
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
+
+{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
+
+```
+
+
+بازیابی عناصر دیگر در ذخیره سازی کمی بیشتر دخیل است زیرا ابتدا باید موقعیت در درخت حافظه محاسبه شود. موقعیت به عنوان هش `keccak256` آدرس و موقعیت ذخیره سازی محاسبه می شود که هر دو در سمت چپ با صفر تا طول 32 بایت اضافه شده اند. به عنوان مثال، موقعیت داده در شکاف ذخیره سازی 1 برای آدرس `0x391694e7e0b0cce554cb130d723a9d27458f9298` است:
+
+
+
+```
+keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))
+```
+
+
+در یک کنسول Geth، این می تواند به صورت زیر محاسبه شود:
+
+
+
+```
+> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
+undefined
+> web3.sha3(key, {"encoding": "hex"})
+"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
+```
+
+
+بنابراین `مسیر` `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` است. اکنون می توان از آن برای بازیابی داده ها از درخت حافظه مانند قبل استفاده کرد:
+
+
+
+```
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
+
+{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
+```
+
+
+توجه: `storageRoot` برای یک حساب اتریوم اگر یک حساب قراردادی نباشد به طور پیشفرض خالی است.
+
+
+
+### درخت تراکنشها {#transaction-trie}
+
+برای هر بلوک یک تراکنش جداگانه وجود دارد که دوباره جفتهای `(کلید، مقدار)` را ذخیره میکند. یک مسیر در اینجا عبارت است از: `rlp(transactionIndex)` که نشان دهنده کلیدی است که با مقدار تعیین شده از سوی این مطابقت دارد:
+
+
+
+```
+if legacyTx:
+ value = rlp(tx)
+else:
+ value = TxType | encode(tx)
+```
+
+
+اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
+
+
+
+### درخت رسیدها {#receipts-trie}
+
+هر بلوک درخت رسیدهای خود را دارد. یک `مسیر` در اینجا این است: `rlp(transactionIndex)`. `transactionIndex` شاخص آن در بلوکی است که در آن گنجانده شده است. درخت رسیدها هرگز به روز نمی شود. مشابه درخت تراکنشها، رسیدهای جاری و قدیمی وجود دارد. برای استعلام یک رسید خاص در درخت رسیدها، شاخص تراکنش در بلوک آن، بار رسید و نوع تراکنش مورد نیاز است. رسید برگشتی می تواند از نوع `رسیدی` باشد که به عنوان الحاق `TransactionType` و `ReceiptPayload` تعریف می شود یا می تواند از نوع `LegacyReceipt< باشد /0> که به صورت rlp([status, cumulativeGasUsed, logsBloom, logs])`. تعریف میشود.
+
+اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
+
+
+
+## اطلاعات بیشتر {#further-reading}
+
+- [درخت مرکل پاتریشیا اصلاح شده – چگونه اتریوم یک حالت را ذخیره می کند](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
+- [مرکلینگ در اتریوم](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
+- [فهمیدن درخت اتریوم](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/rlp/index.md
new file mode 100644
index 00000000000..5909276a700
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/rlp/index.md
@@ -0,0 +1,163 @@
+---
+title: سریال سازی پیشوند با طول بازگشتی (RLP)
+description: تعریف رمزگذاری rlp در لایه اجرایی اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+سریال سازی پیشوند طول بازگشتی (RLP) به طور گسترده در کلاینت های اجرایی اتریوم استفاده می شود. RLP انتقال داده ها بین گره ها را در یک فرمت فضا-کارا استاندارد می کند. هدف RLP کدگذاری آرایه های تو در تو دلخواه از داده های دوتایی است و RLP روش رمزگذاری اولیه است که برای سریال سازی اشیاء در لایه اجرای اتریوم استفاده می شود. هدف اصلی RLP کدگذاری ساختار است. به استثنای اعداد صحیح مثبت، RLP کدگذاری انواع داده های خاص (مانند رشته ها، شناورها) را به پروتکل های مرتبه بالاتر واگذار می کند. اعداد صحیح مثبت باید به شکل دوتایی با اندین بزرگ و بدون صفرهای ابتدایی نمایش داده شوند (بنابراین مقدار عدد صحیح صفر معادل آرایه بایت خالی می شود). اعداد صحیح مثبت غیر سریالی شده با صفرهای ابتدایی باید توسط هر پروتکل مرتبه بالاتر با استفاده از RLP نامعتبر تلقی شوند.
+
+اطلاعات بیشتر در [مقاله زرد اتریوم (پیوست B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19).
+
+برای استفاده از RLP برای رمزگذاری یک فرهنگ لغت، دو شکل متعارف پیشنهادی عبارتند از:
+
+- از `[[k1,v1],[k2,v2]...]` با کلیدها به ترتیب واژگان استفاده کنید
+- از رمزگذاری درخت پاتریشیا در سطح بالاتر مانند اتریوم استفاده کنید
+
+## تعریف {#definition}
+
+تابع رمزگذاری RLP یک آیتم را می گیرد. یک آیتم به صورت زیر تعریف می شود:
+
+- یک رشته (یعنی آرایه بایت) یک آیتم است
+- لیست اقلام، یک آیتم است
+- یک عدد صحیح مثبت یک آیتم است
+
+به عنوان مثال، همه موارد زیر عبارتند از:
+
+- یک رشته خالی؛
+- رشته حاوی کلمه "گربه"؛
+- لیستی حاوی هر تعداد رشته؛
+- و ساختارهای داده پیچیده تری مانند `["گربه"، ["توله سگ"، "گاو"]، "اسب"، [[]]، "خوک"، [""]، "گوسفند"]`.
+- عدد `100`
+
+توجه داشته باشید که در زمینه بقیه این صفحه، "رشته" به معنای "تعداد معینی از بایت داده های دوتایی" است. هیچ کدگذاری خاصی استفاده نمی شود، توجه داشته باشید که در زمینه بقیه این صفحه، "رشته" به معنای "تعداد معینی از بایت داده های دوتایی" است. هیچ کدگذاری خاصی استفاده نمی شود، و هیچ دانشی در مورد محتوای رشته ها وجود ندارد (به جز مواردی که توسط قانون در مورد اعداد صحیح مثبت غیر حداقلی لازم است).
+
+رمزگذاری RLP به صورت زیر تعریف می شود:
+
+- برای یک عدد صحیح مثبت، به کوتاهترین آرایه بایتی که تفسیر آن عدد صحیح است، تبدیل میشود و سپس طبق قوانین زیر به عنوان یک رشته کدگذاری میشود.
+- برای یک بایت که مقدار آن در محدوده `[0x00, 0x7f]` (اعشاری `[0, 127]`) است، آن بایت رمزگذاری RLP خودش است.
+- در غیر این صورت، اگر یک رشته 0-55 بایت طول داشته باشد، رمزگذاری RLP از یک بایت با مقدار **0x80** (اعشار 128) به اضافه طول رشته و به دنبال آن رشته تشکیل شده است. بنابراین، محدوده اولین بایت `[0x80, 0xb7]` است (dec. `[128, 183]`).
+- اگر یک رشته بیش از 55 بایت طول داشته باشد، رمزگذاری RLP شامل یک بایت منفرد با مقدار **0xb7** (اعشار 183) به اضافه طول بر حسب بایت طول رشته به صورت دوتایی است و به دنبال آن طول رشته و به دنبال آن رشته است. به عنوان مثال، یک رشته 1024 بایتی به صورت `\xb9\x04\x00` (dec. `185, 4, 0`) و به دنبال آن رشته رمزگذاری میشود. در اینجا، `0xb9` (183 + 2 = 185) به عنوان اولین بایت، به دنبال آن 2 بایت `0x0400` (اعشار 1024) که طول رشته واقعی را نشان می دهد. بنابراین، محدوده اولین بایت `[0xb8, 0xbf]` است (اعشار `[184، 191]`).
+- اگر یک رشته 2^64 بایت یا بیشتر باشد، ممکن است رمزگذاری نشود.
+- اگر مجموع بار یک لیست (یعنی طول ترکیبی همه موارد آن که با RLP کدگذاری شده اند) 0-55 بایت باشد، رمزگذاری RLP از یک بایت با مقدار **0xc0** به اضافه طول بار و به دنبال آن الحاق رمزگذاری های RLP اقلام تشکیل میشود. بنابراین، محدوده اولین بایت `[0xc0, 0xf7]` است (اعشار `[192, 247] `).
+- اگر حجم کل یک لیست بیش از 55 بایت باشد، رمزگذاری RLP شامل یک بایت منفرد با مقدار **0xf7** به اضافه طول بر حسب بایت طول بار به صورت دوتایی است و به دنبال آن طول بار، و به دنبال آن الحاق رمزگذاری های RLP اقلام است. بنابراین، محدوده اولین بایت `[0xf8, 0xff]` است (اعشار `[248, 255] `).
+
+در کد، این عبارت است از:
+
+```python
+def rlp_encode(input):
+ if isinstance(input,str):
+ if len(input) == 1 and ord(input) < 0x80:
+ return input
+ return encode_length(len(input), 0x80) + input
+ elif isinstance(input, list):
+ output = ''
+ for item in input:
+ output += rlp_encode(item)
+ return encode_length(len(output), 0xc0) + output
+
+def encode_length(L, offset):
+ if L < 56:
+ return chr(L + offset)
+ elif L < 256**8:
+ BL = to_binary(L)
+ return chr(len(BL) + offset + 55) + BL
+ raise Exception("input too long")
+
+def to_binary(x):
+ if x == 0:
+ return ''
+ return to_binary(int(x / 256)) + chr(x % 256)
+```
+
+## مثال ها {#examples}
+
+- the string "dog" = [ 0x83, 'd', 'o', 'g' ]
+- the list [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]`
+- the empty string ('null') = `[ 0x80 ]`
+- the empty list = `[ 0xc0 ]`
+- the integer 0 = `[ 0x80 ]`
+- the byte '\\x00' = `[ 0x00 ]`
+- the byte '\\x0f' = `[ 0x0f ]`
+- the bytes '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]`
+- [نمایش تئوری مجموعه](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) سه، `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
+- رشته "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]`
+
+## رمزگشایی RLP {#rlp-decoding}
+
+با توجه به قوانین و فرآیند رمزگذاری RLP، ورودی رمزگشایی RLP به عنوان آرایه ای از داده های دوتایی در نظر گرفته می شود. فرآیند رمزگشایی RLP به شرح زیر است:
+
+1. با توجه به اولین بایت (یعنی پیشوند) داده های ورودی و رمزگشایی نوع داده، طول داده واقعی و افست؛
+
+2. با توجه به نوع و افست داده، داده ها را به ترتیب رمزگشایی کنید، با رعایت حداقل قانون رمزگذاری برای اعداد صحیح مثبت.
+
+3. به رمزگشایی بقیه ورودی ادامه دهید؛
+
+در میان آنها، قوانین رمزگشایی انواع داده و افست به شرح زیر است:
+
+1. اگر محدوده اولین بایت (یعنی پیشوند) [0x00, 0x7f] باشد و رشته دقیقاً خود اولین بایت باشد، داده یک رشته است.
+
+2. اگر محدوده اولین بایت [0x80, 0xb7] باشد، و رشته ای که طول آن برابر با بایت اول منهای 0x80 است از بایت اول پیروی کند، داده یک رشته است؛
+
+3. اگر محدوده اولین بایت [0xb8, 0xbf] باشد، و طول رشته ای که طول آن بر حسب بایت برابر بایت اول منهای 0xb7 است از بایت اول پیروی می کند و رشته از طول رشته پیروی می کند، داده یک رشته است؛
+
+4. اگر محدوده اولین بایت [0xc0, 0xf7] باشد، و الحاق رمزگذاری های RLP همه آیتم های لیست که کل بار بار برابر با بایت اول منهای 0xc0 است، از بایت اول پیروی می کند، داده یک لیست است؛
+
+5. اگر محدوده اولین بایت [0xf8, 0xff] باشد، و کل محموله فهرستی که طول آن برابر با بایت اول منهای 0xf7 است، از اولین بایت پیروی می کند، و الحاق رمزگذاری های RLP همه آیتم های لیست از کل بار فهرست پیروی می کنند، داده یک لیست است؛
+
+در کد، این عبارت است از:
+
+```python
+def rlp_decode(input):
+ if len(input) == 0:
+ return
+ output = ''
+ (offset, dataLen, type) = decode_length(input)
+ if type is str:
+ output = instantiate_str(substr(input, offset, dataLen))
+ elif type is list:
+ output = instantiate_list(substr(input, offset, dataLen))
+ output += rlp_decode(substr(input, offset + dataLen))
+ return output
+
+def decode_length(input):
+ length = len(input)
+ if length == 0:
+ raise Exception("input is null")
+ prefix = ord(input[0])
+ if prefix <= 0x7f:
+ return (0, 1, str)
+ elif prefix <= 0xb7 and length > prefix - 0x80:
+ strLen = prefix - 0x80
+ return (1, strLen, str)
+ elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)):
+ lenOfStrLen = prefix - 0xb7
+ strLen = to_integer(substr(input, 1, lenOfStrLen))
+ return (1 + lenOfStrLen, strLen, str)
+ elif prefix <= 0xf7 and length > prefix - 0xc0:
+ listLen = prefix - 0xc0;
+ return (1, listLen, list)
+ elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)):
+ lenOfListLen = prefix - 0xf7
+ listLen = to_integer(substr(input, 1, lenOfListLen))
+ return (1 + lenOfListLen, listLen, list)
+ raise Exception("input does not conform to RLP encoding form")
+
+def to_integer(b):
+ length = len(b)
+ if length == 0:
+ raise Exception("input is null")
+ elif length == 1:
+ return ord(b[0])
+ return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256
+```
+
+## بیشتر بخوانید {#further-reading}
+
+- [RLP در اتریوم](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
+- [اتریوم زیر سقف: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
+- [Coglio, A. (2020). پیشوند طول مکرر اتریوم در ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769)
+
+## موضوعات مرتبط {#related-topics}
+
+- [درخت مرکل پاتریشیا](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/ssz/index.md
new file mode 100644
index 00000000000..48bf26d8e19
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/ssz/index.md
@@ -0,0 +1,149 @@
+---
+title: سریال سازی ساده
+description: توضیحی دربارهی فرمت SSZ اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+**سریال سازی ساده (SSZ)** روش سریال سازی مورد استفاده در زنجیره Beacon است. این سریال سازی، شیوه سریال سازی RLP مورد استفاده در لایه اجرایی در همه جای لایه اجماع، به جز پروتکل کشف همتا را جایگزین میکند. SSZ طوری طراحی شده است که قطعی باشد و همچنین به شکلی کارآمد به فرمت درخت مرکل تبدیل شود. SSZ را میتوان سیستمی در نظر گرفت که دو جزء دارد: یک طرح سریال سازی و یک طرح مرکلازیسیون (طرح مرکلازیسیون پروسه تبدیل اطلاعات به فرمت درخت مرکل را تعریف میکند) که برای افزایش کارآیی هنگام کار با ساختار دادههای سریالی (دنبالهدار) طراحی شده است.
+
+## SSZ چگونه کار میکند؟ {#how-does-ssz-work}
+
+### سریالی کردن {#serialization}
+
+SSZ یک طرح ایجاد دنباله است که خود توصیف نیست - بلکه بر طرحی تکیه دارد که باید از قبل شناخته شده باشد. هدف سریال سازی SSZ، نمایش اشیاء (objectها) با پیچیدگی دلخواه به صورت رشته هایی از بایت است. این یک فرآیند بسیار ساده برای "انواع پایه" است. عنصر به سادگی به بایت های هگزادسیمال تبدیل می شود. انواع پایه عبارتند از:
+
+- اعداد صحیح بدون علامت
+- بولین ها
+
+برای انواع پیچیده "کامپوزیت"، سریال سازی پیچیده تر است، زیرا نوع ترکیب حاوی عناصر متعددی است که ممکن است انواع مختلف یا اندازه های مختلف یا هر دو را داشته باشند. در جایی که این اشیاء همگی دارای طولهای ثابت هستند (یعنی اندازه عناصر بدون در نظر گرفتن مقادیر واقعی آنها همیشه ثابت است) سریالسازی صرفاً تبدیل هر عنصر در نوع ترکیبی است که به رشتههای بایت انددیایی کوچک مرتب شدهاند. این رشتههای بایت به هم پیوسته اند. شیء سریالسازیشده نمایش فهرست بایتی عناصر با طول ثابت را به همان ترتیبی که در شیء بیسریالشده ظاهر میشوند، دارد.
+
+برای انواع با طول های متغیر، داده های واقعی با یک مقدار "افست" در موقعیت آن عنصر در شی سریال شده جایگزین می شوند. داده های واقعی به پشته ای در انتهای شیء سریال شده اضافه می شود. مقدار افست شاخصی برای شروع داده های واقعی در پشته است که به عنوان یک اشاره گر به بایت های مربوطه عمل می کند.
+
+مثال زیر نحوه عملکرد آفستینگ برای ظرفی با عناصر دارای طول ثابت و متغیر را نشان می دهد:
+
+```Rust
+
+ struct Dummy {
+
+ number1: u64,
+ number2: u64,
+ vector: Vec,
+ number3: u64
+ }
+
+ dummy = Dummy{
+
+ number1: 37,
+ number2: 55,
+ vector: vec![1,2,3,4],
+ number3: 22,
+ }
+
+ serialized = ssz.serialize(dummy)
+
+```
+
+`serialized` ساختار زیر را خواهد داشت (در اینجا فقط به 4 بیت اضافه می شود، در واقعیت به 32 بیت اضافه می شود و نمایش `int` را برای وضوح حفظ می کند):
+
+```
+[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
+------------ ----------- ----------- ----------- ----------
+ | | | | |
+ number1 number2 offset for number 3 value for
+ vector vector
+
+```
+
+برای وضوح به خطوط تقسیم می شود:
+
+```
+[
+ 37, 0, 0, 0, # little-endian encoding of `number1`.
+ 55, 0, 0, 0, # little-endian encoding of `number2`.
+ 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16).
+ 22, 0, 0, 0, # little-endian encoding of `number3`.
+ 1, 2, 3, 4, # The actual values in `vector`.
+]
+```
+
+این هنوز یک سادهسازی است - اعداد صحیح و صفر در شماتیکهای بالا در واقع به عنوان بایتلیستها ذخیره میشوند، مانند این:
+
+```
+[
+ 10100101000000000000000000000000 # little-endian encoding of `number1`
+ 10110111000000000000000000000000 # little-endian encoding of `number2`.
+ 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16).
+ 10010110000000000000000000000000 # little-endian encoding of `number3`.
+ 10000001100000101000001110000100 # The actual value of the `bytes` field.
+]
+```
+
+بنابراین مقادیر واقعی برای انواع با طول متغیر در یک پشته در انتهای شیء سریالسازی شده با آفستهای آنها در موقعیتهای صحیح خود در فهرست مرتب شده فیلدها ذخیره میشوند.
+
+برخی موارد خاص نیز وجود دارند که نیاز به فرایند خاصی دارند، مانند نوع `BitList` که نیاز به اضافه کردن یک درپوش طول در حین سریالسازی و حذف در حین جداسازی دارد. جزئیات کامل در [مشخصات SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) موجود است.
+
+### غیرسریالی سازی {#deserialization}
+
+برای غیر سریالی کردن این شی به طرحواره نیاز است. این طرح، چیدمان دقیق دادههای سریالسازیشده را تعریف میکند، طوری که هر عنصر خاص را میتوان از یک لکه بایت به یک شی معنادار با عناصر دارای نوع، مقدار، اندازه و موقعیت مناسب غیرسریالی کرد. این طرح واره است که به غیرسریالی کننده می گوید که چه مقادیری مقادیر واقعی هستند و چه مقادیری افست هستند. همه نامهای فیلد زمانی که یک شی سریالی میشود، ناپدید میشوند، اما طبق طرحواره، پس از سریالسازی مجدداً نمونهسازی میشوند.
+
+برای توضیح تعاملی در این مورد به [ssz.dev](https://www.ssz.dev/overview) مراجعه کنید.
+
+## مرکلیزیشن {#merkleization}
+
+این شیء سریالی SSZ سپس می تواند مرکلیزه شود - که به یک نمایش درخت مرکل از همان داده ها تبدیل می شود. ابتدا تعداد تکه های 32 بایتی در شیء سریالی شده تعیین می شود. اینها "برگ"های درخت هستند. تعداد کل برگ ها باید توان 2 باشد تا هش کردن برگ ها با هم در نهایت یک ریشه درخت هش ایجاد کند. اگر به طور طبیعی اینطور نباشد، برگ های اضافی حاوی 32 بایت صفر اضافه می شود. به صورت نموداری:
+
+```
+ hash tree root
+ / \
+ / \
+ / \
+ / \
+ hash of leaves hash of leaves
+ 1 and 2 3 and 4
+ / \ / \
+ / \ / \
+ / \ / \
+ leaf1 leaf2 leaf3 leaf4
+```
+
+همچنین مواردی وجود دارد که برگ های درخت به طور طبیعی به روشی که در مثال بالا انجام می شود به طور یکنواخت توزیع نمی کنند. به عنوان مثال، برگ 4 می تواند ظرفی با عناصر متعدد باشد که نیاز به "عمق" اضافی برای افزودن به درخت مرکل دارد و یک درخت ناهموار ایجاد می کند.
+
+به جای ارجاع به این عناصر درختی به عنوان برگ X، گره X و غیره، میتوانیم به آنها شاخصهای تعمیمیافته بدهیم که با ریشه = 1 شروع میشود و در امتداد هر سطح از چپ به راست میشماریم. این شاخص کلی است که در بالا توضیح داده شد. هر عنصر در فهرست سریالسازی شده دارای یک شاخص تعمیمیافته برابر با `2**عمق + idx` است که در آن idx موقعیت صفر نمایهشده آن در شیء سریالسازیشده و عمق تعداد سطوح در درخت مرکل است، که می تواند به عنوان لگاریتم پایه دو تعداد عناصر (برگ) تعیین شود.
+
+## شاخص های تعمیم یافته {#generalized-indices}
+
+یک شاخص تعمیمیافته یک عدد صحیح است که نشاندهنده یک گره در درخت مرکل دوتایی است که در آن هر گره دارای یک شاخص تعمیمیافته `2 ** عمق + شاخص در ردیف` است.
+
+```
+ 1 --depth = 0 2**0 + 0 = 1
+ 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3
+ 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5...
+
+```
+
+این نمایش یک شاخص گره برای هر قطعه داده در درخت مرکل به دست می دهد.
+
+## اثبات چندگانه {#multiproofs}
+
+ارائه فهرستی از شاخصهای تعمیمیافته که یک عنصر خاص را نشان میدهد به ما امکان میدهد آن را نسبت به ریشه درخت هش تأیید کنیم. این ریشه نسخه پذیرفته شده ما از واقعیت است. هر داده ای که ما ارائه می کنیم را می توان با قرار دادن آن در مکان مناسب در درخت مرکل (که توسط شاخص تعمیم یافته آن تعیین می شود) و مشاهده ثابت ماندن ریشه در برابر آن واقعیت تأیید کرد. توابعی در مشخصات [اینجا](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) وجود دارد که نحوه محاسبه حداقل مجموعه گره های مورد نیاز برای تأیید محتویات یک مجموعه خاص از شاخص های تعمیم یافته را نشان می دهند.
+
+به عنوان مثال، برای تأیید داده های شاخص 9 در درخت زیر، به هش داده ها در شاخص های 8، 9، 5، 3، 1 نیاز داریم. هش (8،9) باید برابر با هش (4) باشد که با 5 هش می شود تا 2 تولید شود و هش با 3 برای تولید ریشه درخت 1 است. اگر دادههای نادرستی برای 9 ارائه شود، ریشه تغییر میکند - ما این را تشخیص میدهیم و نمیتوانیم شعبه را تأیید کنیم.
+
+```
+* = data required to generate proof
+
+ 1*
+ 2 3*
+ 4 5* 6 7
+8* 9* 10 11 12 13 14 15
+
+```
+
+## بیشتر بخوانید {#further-reading}
+
+- [ارتقا Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
+- [ارتقا Ethereum: مرکلیزاسیون](https://eth2book.info/altair/part2/building_blocks/merkleization)
+- [پیاده سازی SSZ](https://github.com/ethereum/consensus-specs/issues/2138)
+- [ماشین حساب SSZ](https://simpleserialize.com/)
+- [SSZ.dev](https://www.ssz.dev/)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
new file mode 100644
index 00000000000..d4eb95c6b09
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
@@ -0,0 +1,189 @@
+---
+title: تعریف ذخیره سازی مخفی Web3
+description: یک تعریف رسمی برای حافظه پنهان Web3
+lang: fa
+sidebarDepth: 2
+---
+
+برای اینکه اپلیکیشن شما بر روی اتریوم کار کند، میتوانید از آبجکت Web3 که توسط کتابخانه web3.js فراهم شده استفاده کنید. در پس زمینه، این کتابخانه از طریق فراخوانی RPC به یک نود محلی متصل میشود. این کتابخانه با هر نود اتریومی که لایه RPC داشته باشد کار میکند.
+
+`web3` شامل آبجکت `eth` میباشد-web3.eth
+
+```js
+var fs = require("fs")
+var recognizer = require("ethereum-keyfile-recognizer")
+
+fs.readFile("keyfile.json", (err, data) => {
+ var json = JSON.parse(data)
+ var result = recognizer(json)
+})
+
+/** result
+ * [ 'web3', 3 ] web3 (v3) keyfile
+ * [ 'ethersale', undefined ] Ethersale keyfile
+ * null invalid keyfile
+ */
+```
+
+این مستندات **ورژن سوم** تعریف حافظه پنهان Web3 میباشند.
+
+## تعریف {#definition}
+
+رمزگذاری و رمزگشایی فایل نسبت به ورژن اول تا حد زیادی تغییری نکرده است، جز این که الگوریتم رمزنگاری دیگر روی AES-128-CBC تثبیت نشده است (AES-128-CTR اکنون لازمه حداقل است). بیشتر معانی و الگوریتمها همانند ورژن اول هستند، به جز `mac`، که به عنوان SHA3 (keccak-256) از ترکیب دومین 16 بایت از چپ از کلید مشتقشده به همراه کل `ciphertext` تعریف میشود.
+
+فایلهای کلید مخفی مستقیما در `~/.web3/keystore` (برای سیستمهایی مانند Unix) و `~/AppData/Web3/keystore` (برای ویندوز) ذخیره میشوند. ممکن است هر چیزی نام گذاری شوند، اما بهترین نام گذاری میتواند `.json` باشد که `` یک UUIDی 128 بیتی است که به کلید مخفی داده میشود (یک پروکسی حفظ حریم خصوصی برای آدرس کلیدهای مخفی).
+
+همه این فایلها یک پسورد مربوط به خودشان را دارند. برای استخراج کلید مخفی یک فایل `.json`، ابتدا باید کلید رمزگذاری فایل را استخراج کرد. در واقع این کار از طریق دریافت پسورد فایلها و دادن آن پسورد به تابع استخراج همانطور که توسط کلید `kdf` تعریف شدهاست، انجام میشود. پارامترهای استاتیک و دینامیک وابسته به KDF برای تابع KDF در کلید `kdfparams` توضیح داده شده است.
+
+PBKDF2 باید توسط تمام پیادهسازیهای دارای حداقل سازگاری پشتیبانی شود، البته به این موارد اشاره شده است:
+
+- `kdf`: `pbkdf2`
+
+kdfparamها برای PBKDF2 عبارتند از:
+
+- `prf`: باید `hmac-sha256` باشد (ممکن است در آینده تمدید شود);
+- `c`: تعداد تکرارها؛
+- `سالت`: سالت به PBKDF منتقل می شود؛
+- `dklen`: طول کلید استخراج شده. باید >=32 باشد.
+
+هنگامی که کلید فایل استخراج شد، باید از طریق استخراج MAC تأیید شود. MAC باید به عنوان هش SHA3 (keccak-256) آرایه بایت محاسبه شود که به عنوان الحاقات 16 بایت دوم سمت چپ کلید استخراج شده با محتویات کلید `متن رمزی` تشکیل شده است، به عنوان مثال.:
+
+```js
+KECCAK(DK[16..31] ++ )
+```
+
+(که در آن `++` اپراتور الحاق است)
+
+این مقدار باید با محتویات کلید `mac` مقایسه شود. اگر متفاوت هستند، یک رمز عبور جایگزین باید درخواست شود (یا عملیات لغو شود).
+
+پس از تأیید کلید فایل، متن رمز (کلید `متن رمز` در فایل) ممکن است با استفاده از الگوریتم رمزگذاری متقارن مشخص شده توسط کلید `رمز` رمزگشایی شود و از طریق کلید `پارام رمز` پارامترگذاری شود. اگر اندازه کلید استخراج شده و اندازه کلید الگوریتم با هم مطابقت نداشته باشند، بایت های صفر و سمت راست کلید استخراج شده باید به عنوان کلید الگوریتم استفاده شوند.
+
+همه پیادهسازیهایی که حداقل مطابقت را دارند باید از الگوریتم AES-128-CTR پشتیبانی کنند که به این صورت مشخص میشود:
+
+- `cipher: aes-128-ctr`
+
+این رمز، پارامترهای زیر را می گیرد که به عنوان کلید برای کلید cipherparams داده می شود:
+
+- `iv`: بردار اولیه سازی 128 بیتی برای رمز.
+
+کلید رمز، 16 بایت سمت چپ کلید استخراج شده است، یعنی `DK[0..15]`
+
+ایجاد/رمزگذاری یک کلید مخفی باید اساساً برعکس این دستورالعملها باشد. مطمئن شوید که `uuid`، `salt` و `iv` واقعا تصادفی هستند.
+
+علاوه بر فیلد `نسخه`، که باید به عنوان یک شناسه "سخت" نسخه عمل کند، پیادهسازیها ممکن است از `minorversion` برای ردیابی تغییرات کوچکتر و بدون شکست در قالب استفاده کنند.
+
+## بردارهای تست {#test-vectors}
+
+جزئیات:
+
+- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
+- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
+- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6`
+- `Password`: `testpassword`
+- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
+
+### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
+
+آزمایش بردار با استفاده از `AES-128-CTR` و `PBKDF2-SHA-256`:
+
+محتوای فایل `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
+ },
+ "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
+ "kdf": "pbkdf2",
+ "kdfparams": {
+ "c": 262144,
+ "dklen": 32,
+ "prf": "hmac-sha256",
+ "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
+ },
+ "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**متوسط**:
+
+`Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5`
+
+### Scrypt {#scrypt}
+
+بردار آزمایشی با استفاده از AES-128-CTR و Scrypt:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "740770fce12ce862af21264dab25f1da"
+ },
+ "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
+ },
+ "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**متوسط**:
+
+`کلید استخراج شده`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c`
+
+## تغییرات از نسخه 1 {#alterations-from-v2}
+
+این نسخه چندین ناسازگاری را با نسخه 1 منتشر شده در [اینجا](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) برطرف می کند. آنها به طور خلاصه عبارتند از:
+
+- حروف بزرگ غیرقابل توجیه و متناقض است (حروف کوچک رمز، حروف مختلط Kdf، حروف بزرگ MAC).
+- به حریم خصوصی و ایرادات غیرضروری میپردازد.
+- `سالت` ذاتاً یک پارامتر تابع مشتق کلید است و شایسته آن است که با آن مرتبط شود، نه به طور کلی با رمزارز.
+- _SaltLen_ غیر ضروری است (فقط آن را از Salt استخراج کنید).
+- تابع استخراج کلید داده شده است، اما الگوریتم رمزنگاری به سختی مشخص شده است.
+- `نسخه` ذاتاً عددی است و در عین حال یک رشته است (نسخهسازی ساختاریافته با یک رشته امکانپذیر است، اما میتواند برای قالب فایل پیکربندی که به ندرت تغییر میکند، خارج از محدوده در نظر گرفته شود).
+- `KDF` و `رمز` به طور فکری مفاهيم خواهر و برادر هستند اما به طور متفاوت سازماندهي شده اند.
+- `MAC` از طریق یک قطعه داده آگنوستیک فضای خالی محاسبه می شود(!)
+
+برای ارائه فایل زیر، تغییراتی در قالب ایجاد شده است که از نظر عملکردی معادل مثال داده شده در صفحه پیوند قبلی است:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-cbc",
+ "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
+ "cipherparams": {
+ "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
+ },
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
+ },
+ "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
+ "version": 1
+ },
+ "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
+ "version": 2
+}
+```
+
+## تغییرات از نسخه 2 {#alterations-from-v2}
+
+نسخه 2 یک پیاده سازی اولیه ++C با تعدادی باگ بود. همه موارد ضروری بدون تغییر از آن باقی می مانند.
diff --git a/public/content/translations/fa/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/fa/developers/docs/design-and-ux/dex-design-best-practice/index.md
new file mode 100644
index 00000000000..7efb9db6d65
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/design-and-ux/dex-design-best-practice/index.md
@@ -0,0 +1,220 @@
+---
+title: بهترین شیوههای طراحی صرافی غیرمتمرکز (DEX)
+description: راهنمائی برای توضیح تصمیمات گرفته شده درمورد رابط کاربری و تجربه کاربری حین مبادله توکنها.
+lang: fa
+---
+
+از زمان راهاندازی یونی سواپ در سال 2018، صدها صرافی غیرمتمرکز در شبکههای مختلف راهاندازی شده است.
+بسیاری از این صرافیها یک عنصر جدید یا شیوهی مختص به خود را معرفی کردند، اما رابط کاربری بهصورت کلی به همان شکل مانده است.
+
+یکی از دلایل آن [قانون جیکوب](https://lawsofux.com/jakobs-law/) است:
+
+> کاربران بیشتر وقت خود را در وب سایتهای دیگر صرف میکنند. این بدان معناست که کاربران ترجیح میدهند تا سایت شما مشابه سایتهایی عمل کند که در حال حاضر با آنها آشنا هستند.
+
+به لطف نوآورانی همچون یونی سواپ، پنکیک سواپ و سوشی سواپ، کاربران حوزه دیفای یک ایده کلی از این دارند که صرافی غیرمتمرکز چگونه باید به نظر برسد.
+به همین دلیل، چیزهایی مثل "بهترین شیوه" هم اکنون در حال ظهور هستند. میتوان مشاهده کرد که تصمیمات طراحی در میان سایتهای مختلف بیشتر و بیشتر استانداردسازی میشود. تکامل صرافیهای غیرمتمرکز یک مثال بزرگ از تست کردن پروژه با استفاده از اجرا و انتشار آن میباشد. چیزهایی که کار کردند همانطور ماندند و چیزهایی که کار نکردند، دور انداخته شدند. هنوز جا برای شخصی سازی وجود دارد، اما استانداردهای خاصی وجود دارند که یک صرافی غیرمتمرکز باید به آنها پایبند باشد.
+
+این مقاله خلاصه ای است از:
+
+- چه چیزی را شامل شود
+- چگونه آن را تا حد امکان قابل استفاده کنیم
+- راه های اصلی برای سفارشی سازی طراحی
+
+همه وایرفریمهای نمونه بهطور خاص برای این مقاله ساخته شدهاند، اگرچه همه آنها بر اساس پروژههای واقعی هستند.
+
+کیت Figma نیز در پایین موجود است - از آن استفاده کنید و سرعت وایرفریم های خود را افزایش دهید!
+
+## آناتومی ساده یک صرافی غیرمتمرکز {#basic-anatomy-of-a-dex}
+
+رابط کاربری معمولا شامل 3 چیز است:
+
+1. فرم اصلی
+2. دکمه
+3. پنل جزئیات
+
+![Generic DEX UI، نمایش سه عنصر اصلی](./1.png)
+
+## تغییرات {#variations}
+
+این یک موضوع رایج در این مقاله خواهد بود، اما روشهای مختلفی برای سازماندهی این عناصر وجود دارد. "پنل جزئیات" می تواند بدین شکل باشد:
+
+- بالای دکمه
+- زیر دکمه
+- مخفی در پنل آکاردئونی
+- و/یا در حالت "پیش نمایش"
+
+نکته حالت "پیش نمایش" اختیاری است، اما اگر جزئیات بسیار کمی را در رابط کاربری اصلی نشان می دهید، ضروری می شود.
+
+## ساختار فرم اصلی {#structure-of-the-main-form}
+
+این کادری است که در واقع انتخاب میکنید کدام توکن را میخواهید تعویض کنید. کامپوننت شامل یک فیلد ورودی و یک دکمه کوچک در یک ردیف است.
+
+DEX ها معمولاً جزئیات اضافی را در یک ردیف بالا و یک ردیف پایین نمایش می دهند، اگرچه می توان آن را به طور متفاوت پیکربندی کرد.
+
+![ردیف ورودی، با ردیف جزئیات بالا و پایین](./2.png)
+
+## تغییرات {#variations2}
+
+دو تغییر رابط کاربری در اینجا نشان داده شده است. یکی بدون هیچ حاشیه ای، یک طرح بسیار باز ایجاد می کند، و دیگری که در آن ردیف ورودی دارای یک حاشیه است که تمرکز روی آن عنصر ایجاد می کند.
+
+![دو تغییر رابط کاربری فرم اصلی](./3.png)
+
+این ساختار اساسی به **چهار اطلاعات کلیدی** اجازه می دهد تا در طراحی نشان داده شوند: یکی در هر گوشه. اگر فقط یک ردیف بالا/پایین وجود داشته باشد، تنها دو نقطه وجود دارد.
+
+در طول تکامل دیفای، موارد مختلف زیادی در اینجا گنجانده شده است.
+
+## اطلاعات کلیدی برای درج {#key-info-to-include}
+
+- موجودی در کیف پول
+- دکمه Max
+- معادل قیمت به فیات
+- تاثیر قیمت بر مبلغ "دریافت شده"
+
+در روزهای اولیه دیفای، معادل فیات اغلب گم می شد. اگر در حال ساخت هر نوع پروژه Web3 هستید، ضروری است که معادل فیات نشان داده شود. کاربران هنوز بر حسب ارزهای محلی فکر می کنند، بنابراین برای مطابقت با مدل های ذهنی دنیای واقعی، باید این مورد لحاظ شود.
+
+در فیلد دوم (محلی که توکنی را انتخاب میکنید که با آن مبادله میکنید) میتوانید با محاسبه تفاوت بین مقدار ورودی و مقدار خروجی تخمینی، تأثیر قیمت را در کنار مقدار ارز فیات لحاظ کنید. این جزئیات کاملا مفیدی برای گنجاندن است.
+
+دکمه های درصد (مثلاً 25٪، 50٪، 75٪) می توانند یک ویژگی مفید باشند، اما فضای بیشتری را اشغال می کنند، تماس بیشتری را به اقدامات اضافه می کنند و بار ذهنی بیشتری را اضافه می کنند. در مورد لغزنده های درصد نیز همینطور است. برخی از این تصمیمات UI به برند و نوع کاربری شما بستگی دارد.
+
+جزئیات اضافی را می توان در زیر فرم اصلی نشان داد. از آنجایی که این نوع اطلاعات بیشتر برای کاربران حرفه ای است، منطقی است که:
+
+- آن را تا حد امکان مینیمال نگه دارید، یا؛
+- آن را در پنل آکاردئونی پنهان کنید
+
+![جزئیات در گوشه های آن فرم اصلی نشان داده شده است](./4.png)
+
+## اطلاعات اضافی برای درج {#extra-info-to-include}
+
+- قیمت توکن
+- افت
+- حداقل دریافتی
+- خروجی مدنظر
+- اثر قیمت
+- تخمین هزینه گس
+- باقی کارمزدها
+- مسیردهی سفارش
+
+مسلماً برخی از این جزئیات می توانند اختیاری باشند.
+
+مسیریابی سفارش جالب است، اما برای اکثر کاربران تفاوت چندانی ایجاد نمی کند.
+
+برخی جزئیات دیگر به سادگی یک چیز را به روش های مختلف بازگو می کنند. برای مثال «حداقل دریافتی» و «افت قیمت» دو روی یک سکه هستند. اگر افت قیمت را روی 1% تنظیم کردهاید، حداقل مقداری که میتوانید دریافت کنید = خروجی مدنظر - 1%. برخی از رابطهای کاربری مقدار مورد انتظار، حداقل مقدار و افت را نشان میدهند… که مفید است اما احتمالاً بیش از حد است.
+
+اکثر کاربران به هر حال افت قیمت پیش فرض را خالی می گذارند.
+
+"تأثیر قیمت" اغلب در پرانتز در کنار معادل فیات در قسمت "به" نشان داده می شود. این اطلاعات عالی درباره ux برای افزودن است، اما اگر در اینجا نشان داده شود، آیا واقعاً باید دوباره در زیر نشان داده شود؟ و سپس دوباره در یک صفحه پیش نمایش بیاید؟
+
+بسیاری از کاربران (مخصوصاً آنهایی که مقادیر کم را مبادله می کنند) به این جزئیات اهمیت نمی دهند. آنها به سادگی یک عدد وارد می کنند و swap را می زنند.
+
+![برخی جزئیات همین را نشان میدهد](./5.png)
+
+اینکه دقیقاً چه جزئیاتی نشان داده می شود به مخاطبان شما و احساسی که می خواهید برنامه داشته باشد بستگی دارد.
+
+اگر آستانه تحمل افت را در پنل جزئیات لحاظ کنید، باید آن را مستقیماً از اینجا نیز قابل ویرایش کنید. این مثال خوبی از "شتاب دهنده" است. یک ترفند ساده UX که میتواند جریان کاربران با تجربه را سرعت بخشد، بدون اینکه بر قابلیت استفاده عمومی برنامه تأثیر بگذارد.
+
+![افت قیمت را می توان از پنل جزئیات کنترل کرد](./6.png)
+
+این ایده خوبی است که نه تنها در مورد یک قطعه خاص از اطلاعات در یک صفحه، بلکه در مورد کل جریان از طریق آن به دقت فکر کنید:
+وارد کردن اعداد در فرم اصلی ← جزئیات اسکن ← کلیک کردن برای پیش نمایش صفحه (اگر صفحه پیش نمایش دارید).
+آیا پنل جزئیات باید همیشه قابل مشاهده باشد یا کاربر برای بزرگ شدن باید روی آن کلیک کند؟
+آیا باید با افزودن یک صفحه پیش نمایش اصطکاک ایجاد کنید؟ این امر کاربر را مجبور می کند تا سرعت خود را کاهش دهد و مبادله خود را در نظر بگیرد که می تواند مفید باشد. اما آیا آنها می خواهند همه همان اطلاعات را دوباره ببینند؟ چه چیزی در این مرحله برای آنها مفیدتر است؟
+
+## گزینه های طراحی {#design-options}
+
+همانطور که گفته شد، بسیاری از این موارد به سبک شخصی شما برمی گردد
+کاربر شما کیست؟
+برند شما چیست؟
+آیا یک رابط حرفه ای می خواهید که تمام جزئیات را نشان دهد یا می خواهید مینیمالیستی باشید؟
+حتی اگر به دنبال کاربران حرفهای هستید که همه اطلاعات را میخواهند، باز هم باید سخنان حکیمانه آلن کوپر را به خاطر بسپارید:
+
+> هر چقدر هم که رابط کاربری شما زیبا باشد، بهتر است کمتر از آن استفاده کنید.
+
+### ساختار {#structure}
+
+- توکن ها در سمت چپ یا توکن ها در سمت راست
+- 2 ردیف از 3
+- جزئیات بالا یا زیر دکمه
+- جزئیات گسترش یافته، حداقل شود یا نشان داده نشود
+
+### استایل کامپوننت {#component-style}
+
+- خالی
+- تاکید شده
+- پر شده
+
+از نقطه نظر UX خالص، سبک UI کمتر از آنچه فکر می کنید اهمیت دارد. روندهای بصری در چرخه می آیند و می روند و بسیاری از اولویت ها ذهنی است.
+
+ساده ترین راه برای درک این موضوع - و فکر کردن به پیکربندی های مختلف - این است که به چند نمونه نگاه کنید و سپس خودتان آزمایش کنید.
+
+کیت Figma شامل اجزای خالی، پیشفرض و پر شده است.
+
+به مثال های زیر نگاهی بیندازید تا روش های مختلفی را مشاهده کنید که می توانید همه آن ها را کنار هم قرار دهید:
+
+![3 ردیف به سبک پر شده](./7.png)
+
+![3 ردیف به سبک متن تاکید شده](./8.png)
+
+![2 ردیف به سبک خالی](./9.png)
+
+![3 ردیف به سبک متن پیشفرض، با پنل جزئیات](./10.png)
+
+![3 ردیف با ردیف ورودی به سبک متن تاکید شده](./11.png)
+
+![2 ردیف به سبک پر شده](./12.png)
+
+## اما توکن باید به کدام سمت برود؟ {#but-which-side-should-the-token-go-on}
+
+نکته اصلی این است که احتمالاً تفاوت زیادی در قابلیت استفاده ایجاد نمی کند. با این حال، چند نکته وجود دارد که باید به خاطر داشته باشید، که ممکن است شما را به یک جهت تحت تاثیر قرار دهد.
+
+دیدن تغییر مد با گذشت زمان کمی جالب است. Uniswap در ابتدا توکن را در سمت چپ داشت، اما از آن زمان آن را به سمت راست منتقل کرده است. Sushiswap نیز این تغییر را طی یک ارتقاء طراحی ایجاد کرد. بیشتر پروتکلها، اما نه همه، از همین روند پیروی کردهاند.
+
+قوانین مالی به طور سنتی نماد ارز را قبل از عدد قرار می دهد، به عنوان مثال. $50، €50، £50، اما ما _می گوییم_ 50 دلار، 50 یورو، 50 پوند.
+
+برای کاربر عمومی - به خصوص کسی که از چپ به راست، از بالا به پایین می خواند - نشانه سمت راست احتمالا طبیعی تر است.
+
+![یک رابط کاربری با توکن ها در سمت چپ](./13.png)
+
+قرار دادن توکن در سمت چپ و همه اعداد در سمت راست به طرز خوشایندی متقارن به نظر می رسند، که یک امتیاز مثبت است، اما یک نقطه ضعف دیگر در این طرح وجود دارد.
+
+قانون مجاورت بیان می کند که مواردی که نزدیک به هم هستند به عنوان مرتبط تلقی می شوند. بر همین اساس می خواهیم موارد مرتبط را در کنار یکدیگر قرار دهیم. موجودی توکن مستقیماً با خود توکن مرتبط است و هر زمان که یک توکن جدید انتخاب شود تغییر خواهد کرد. بنابراین کمی منطقی تر است که موجودی توکن در کنار دکمه انتخاب نشانه باشد. میتوان آن را به زیر نشانه منتقل کرد، اما این تقارن طرحبندی را میشکند.
+
+در نهایت، نکات مثبت و منفی برای هر دو گزینه وجود دارد، اما جالب است که به نظر می رسد چگونه روند به سمت توکن سمت راست است.
+
+# رفتار دکمه {#button-behavior}
+
+دکمه جداگانه ای برای تأیید نداشته باشید. همچنین یک کلیک جداگانه برای تأیید نداشته باشید. کاربر میخواهد Swap را انجام دهد، بنابراین فقط روی دکمه بگویید «swap» و تأیید را به عنوان اولین مرحله آغاز کنید. یک مودال میتواند پیشرفت را با یک استپر یا یک اعلان ساده "tx 1 of 2 - تایید" نشان دهد.
+
+![یک رابط کاربری با دکمههای جداگانه برای تأیید و swap](./14.png)
+
+![یک رابط کاربری با یک دکمه که تأیید میکند](./15.png)
+
+## دکمه به عنوان راهنمای متنی {#button-as-contextual-help}
+
+این دکمه می تواند به عنوان یک هشدار، وظیفه ای مضاعف را انجام دهد!
+
+این در واقع یک الگوی طراحی نسبتاً غیرعادی در خارج از Web3 است، اما در داخل آن استاندارد شده است. این یک نوآوری خوب است زیرا باعث صرفه جویی در فضا می شود و توجه را متمرکز نگه می دارد.
+
+اگر عمل اصلی - SWAP - به دلیل خطا در دسترس نیست، دلیل آن را می توان با دکمه توضیح داد، به عنوان مثال.:
+
+- تعویض شبکه
+- اتصال کیف پول
+- خطاهای متعدد
+
+این دکمه همچنین می تواند **به عملکرد** که باید انجام شود نگاشت شود. به عنوان مثال، اگر کاربر نمی تواند به دلیل اینکه در شبکه اشتباهی قرار دارد، مبادله کند، دکمه باید بگوید “switch to Ethereum” و زمانی که کاربر روی دکمه کلیک می کند، باید شبکه را به اتریوم تغییر دهد. این سرعت جریان کاربر را به میزان قابل توجهی افزایش می دهد.
+
+![عملکردهای کلیدی از CTA اصلی شروع میشوند](./16.png)
+
+![پیام خطا در CTA اصلی نشان داده میشود](./17.png)
+
+## مال خودتان را با این فایل فیگما بسازید {#build-your-own-with-this-figma-file}
+
+به لطف کار سخت پروتکل های متعدد، طراحی DEX بسیار بهبود یافته است. ما می دانیم که کاربر به چه اطلاعاتی نیاز دارد، چگونه باید آن را نشان دهیم و چگونه جریان را تا حد امکان روان کنیم.
+امیدواریم این مقاله یک نمای کلی از اصول UX ارائه دهد.
+
+اگر میخواهید آزمایش کنید، لطفاً از کیت وایرفریم فیگما استفاده کنید. تا حد امکان ساده نگه داشته می شود، اما انعطاف کافی برای ساختن ساختار اصلی به روش های مختلف دارد.
+
+[کیت وایرفریم فیگما](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
+
+دیفای به تکامل خود ادامه خواهد داد و همیشه جایی برای بهبود وجود دارد.
+
+موفق باشید!
diff --git a/public/content/translations/fa/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/fa/developers/docs/design-and-ux/heuristics-for-web3/index.md
new file mode 100644
index 00000000000..5cf74c4ece5
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/design-and-ux/heuristics-for-web3/index.md
@@ -0,0 +1,138 @@
+---
+title: 7 اکتشاف برای طراحی رابط Web3
+description: اصولی برای بهبود قابلیت استفاده از Web3
+lang: fa
+---
+
+اکتشاف قابلیت استفاده "قوانین سرانگشتی" گسترده ای هستند که می توانید برای اندازه گیری قابلیت استفاده سایت خود از آنها استفاده کنید.
+این اکتشاف ها به طور خاص برای Web3 طراحی شده اند و باید در کنار Jakob Nielsen [10 اصل کلی برای طراحی تعامل] (https://www.nngroup.com/articles/ten-usability-heuristics/) استفاده شوند.
+
+## هفت اکتشاف قابلیت استفاده برای web3 {#seven-usability-heuristics-for-web3}
+
+1. بازخورد در ادامه عمل میآید
+2. امنیت و اعتماد
+3. مهمترین اطلاعات واضح است
+4. اصطلاحات قابل درک
+5. اقدامات تا حد امکان کوتاه است
+6. اتصالات شبکه قابل مشاهده و انعطاف پذیر هستند
+7. از برنامه کنترل کنید، نه کیف پول
+
+## تعاریف و مثالها {#definitions-and-examples}
+
+### 1. بازخورد به دنبال عمل میآید {#feedback-follows-action}
+
+**وقتی اتفاقی افتاده یا در حال وقوع است باید واضح باشد.**
+
+کاربران بر اساس نتیجه گام های قبلی خود در مورد مراحل بعدی خود تصمیم می گیرند. بنابراین ضروری است که آنها از وضعیت سیستم مطلع شوند. این امر به ویژه در Web3 بسیار مهم است زیرا تراکنشها گاهی اوقات ممکن است زمان کوتاهی طول بکشد تا به بلاک چین متعهد شوند. اگر بازخوردی وجود نداشته باشد که به آنها اطلاع دهد که منتظر بمانند، کاربران مطمئن نیستند که آیا اتفاقی افتاده یا خیر.
+
+**نکات:**
+
+- از طریق پیام رسانی، اعلان ها و سایر هشدارها به کاربر اطلاع دهید.
+- زمان های انتظار را به وضوح در میان بگذارید.
+- اگر قرار است عملی بیش از چند ثانیه طول بکشد، با استفاده از یک تایمر یا یک انیمیشن به کاربر اطمینان دهید تا احساس کند چیزی در حال رخ دادن است.
+- اگر چندین مرحله برای یک فرآیند وجود دارد، هر مرحله را نشان دهید.
+
+**مثال:**
+نمایش هر مرحله درگیر در یک تراکنش به کاربران کمک می کند تا بدانند در کجای فرآیند قرار دارند. آیکون های مناسب به کاربر امکان می دهند از وضعیت اقدامات خود مطلع شود.
+
+![اطلاع رسانی به کاربر در مورد هر مرحله هنگام تعویض نشانه](./Image1.png)
+
+### 2. امنیت و اعتماد ایجاد میشوند {#security-and-trust-are-backed-in}
+
+امنیت باید در اولویت قرار گیرد و این باید برای کاربر تاکید شود.
+افراد عمیقاً به داده های خود اهمیت می دهند. ایمنی اغلب یک نگرانی اولیه برای کاربران است، بنابراین باید در تمام سطوح طراحی در نظر گرفته شود. همیشه باید به دنبال جلب اعتماد کاربران خود باشید، اما روشی که این کار را انجام میدهید میتواند در اپلیکیشنهای مختلف معنای متفاوت داشته باشد. این نباید یک فکر ثانوی باشد، بلکه باید آگاهانه طراحی شود. در طول تجربه کاربر، از جمله کانالهای اجتماعی و اسناد، و همچنین رابط کاربری نهایی، اعتماد ایجاد کنید. مواردی مانند سطح غیرمتمرکز، وضعیت چند علامت خزانه، و اینکه آیا تیم از کار افتاده است یا نه، همگی بر اعتماد کاربران تأثیر میگذارند
+
+**نکات:**
+
+- ممیزی های خود را با افتخار فهرست کنید
+- ممیزی های متعدد دریافت کنید
+- هر ویژگی ایمنی که طراحی کرده اید را تبلیغ کنید
+- خطرات احتمالی، از جمله ادغام های اساسی را برجسته کنید
+- پیچیدگی استراتژی ها را به اشتراک بگذارید
+- مسائل غیر UI را در نظر بگیرید که ممکن است بر درک کاربران شما از ایمنی تأثیر بگذارد
+
+**مثال:**
+ممیزیهای خود را در پاورقی، در اندازههای برجسته بگنجانید.
+
+![به ممیزی ها در پاورقی وب سایت استناد شده است](./Image2.png)
+
+### 3. مهمترین اطلاعات واضح است {#the-most-important-info-is-obvious}
+
+برای سیستم های پیچیده، فقط مرتبط ترین داده ها را نشان دهید. تعیین کنید چه چیزی مهم است و نمایش آن را اولویت بندی کنید.
+اطلاعات بیش از حد طاقت فرسا است و کاربران معمولاً هنگام تصمیم گیری بر روی یک قطعه اطلاعات تمرکز میکنند. در DeFi، این احتمالاً APR برای برنامههای بازدهی و LTV در برنامههای وامدهی خواهد بود.
+
+**نکات:**
+
+- تحقیقات کاربر مهمترین معیار را آشکار می کند
+- اطلاعات کلیدی را بزرگ و سایر جزئیات را کوچک و محجوب کنید
+- افراد نمی خوانند، اسکن می کنند. اطمینان حاصل کنید که طرح شما قابل اسکن است
+
+**مثال:** نشانه های بزرگ به صورت تمام رنگی هنگام اسکن به راحتی پیدا می شوند. APR بزرگ است و با رنگ برجسته برجسته شده است.
+
+![یافتن نشانه و APR آسان است](./Image3.png)
+
+### 4. اصطلاحات واضح {#clear-terminology}
+
+اصطلاحات باید قابل فهم و مناسب باشند.
+اصطلاحات فنی می تواند یک مانع بزرگ باشد، زیرا نیاز به ساخت یک مدل ذهنی کاملاً جدید دارد. کاربران نمی توانند طراحی را با کلمات، عبارات و مفاهیمی که از قبل می دانند مرتبط کنند. همه چیز گیج کننده و ناآشنا به نظر می رسد، و قبل از اینکه آنها حتی بتوانند از آن استفاده کنند، یک منحنی یادگیری شیب دار وجود دارد. کاربرانی که میخواهند مقداری پول پسانداز کنند، ممکن است به DeFi نزدیک شوند، و چیزی که پیدا میکنند این است: استخراج، فارمینگ، سهامگذاری، انتشار گازهای گلخانهای، رشوه، گاوصندوق ها، قفسهها، توکنهای vetoken، واگذاری، ایپوک ها، الگوریتمهای غیرمتمرکز، نقدینگی متعلق به پروتکل…
+سعی کنید از اصطلاحات ساده ای استفاده کنید که برای گسترده ترین گروه مردم قابل درک باشد. اصطلاحات جدید را فقط برای پروژه خود اختراع نکنید.
+
+**نکات:**
+
+- از اصطلاحات ساده و ثابت استفاده کنید
+- تا حد امکان از زبان موجود استفاده کنید
+- شرایط خود را مطرح نکنید
+- قراردادها را همانطور که ظاهر می شوند دنبال کنید
+- تا حد امکان به کاربران آموزش دهید
+
+**مثال:**
+"پاداش شما" اصطلاحی است که به طور گسترده درک میشود و خنثی است و کلمه جدیدی برای این پروژه ساخته نشده است. جوایز به USD تعلق میگیرد تا با مدلهای ذهنی دنیای واقعی مطابقت داشته باشد، حتی اگر خود پاداشها با توکن دیگری باشند.
+
+![جوایز توکنی، نمایش داده شده به دلار آمریکا](./Image4.png)
+
+### 5. اقدامات تا حد امکان کوتاه هستند {#actions-are-as-short-as-possible}
+
+با گروهبندی کنشهای فرعی، تعاملات کاربر را تسریع کنید.
+این ممکن است در سطح قرارداد هوشمند و همچنین رابط کاربری انجام شود. کاربر نباید مجبور باشد از یک قسمت سیستم به قسمت دیگر حرکت کند - یا سیستم را به طور کامل ترک کند تا یک اقدام مشترک را انجام دهد.
+
+**نکات:**
+
+- در صورت امکان، «تأیید» را با سایر اقدامات ترکیب کنید
+- مراحل امضا را تا حد امکان به هم نزدیک کنید
+
+**مثال:** ترکیب «افزودن نقدینگی» و «سهام» یک مثال ساده از شتابدهندهای است که در زمان و گس کاربر صرفهجویی میکند.
+
+![Modal نشان دادن سوئیچ برای ترکیب اقدامات سپرده و سهام](./Image5.png)
+
+### 6. اتصالات شبکه قابل مشاهده و انعطاف پذیر هستند {#network-connections-are-visible-and-flexible}
+
+به کاربر اطلاع دهید که به چه شبکه ای متصل است و میانبرهای واضحی برای تغییر شبکه ارائه دهید.
+این به ویژه در برنامه های چند زنجیره ای مهم است. عملکردهای اصلی برنامه همچنان باید هنگام قطع یا اتصال به یک شبکه غیر پشتیبانی قابل مشاهده باشند.
+
+**نکات:**
+
+- تا آنجا که ممکن است برنامه را هنگام قطع ارتباط نشان دهید
+- نشان دهید که کاربر در حال حاضر به کدام شبکه متصل است
+- کاربر را مجبور نکنید برای تغییر شبکه به کیف پول مراجعه کند
+- اگر برنامه از کاربر میخواهد که شبکه را تغییر دهد، این عمل را از تماس اصلی برای اقدام درخواست کنید
+- اگر برنامه حاوی بازارها یا انبارهایی برای چندین شبکه است، به وضوح مشخص کنید که کاربر در حال حاضر به کدام مجموعه نگاه می کند
+
+**مثال:** به کاربر نشان دهید که به کدام شبکه متصل است و به او اجازه دهید آن را در نوار برنامه تغییر دهد.
+
+![دکمه کشویی شبکه متصل را نشان می دهد](./Image6.png)
+
+### 7. کنترل از برنامه، نه کیف پول {#control-from-the-app-not-the-wallet}
+
+رابط کاربری باید همه چیزهایی که کاربر باید بداند را بگوید و کنترل همه چیزهایی که باید انجام دهد را به او بدهد.
+در Web3، اقداماتی هستند که در رابط کاربری انجام می دهید و اقداماتی که در کیف پول انجام می دهید. به طور کلی، شما یک عمل را در UI آغاز می کنید و سپس آن را در کیف پول تأیید می کنید. اگر این دو رشته به دقت ادغام نشوند، کاربران ممکن است احساس ناراحتی کنند.
+
+**نکات:**
+
+- وضعیت سیستم را از طریق بازخورد در UI اعلام کنید
+- تاریخچه آنها را ثبت کنید
+- پیوندهایی برای مسدود کردن کاوشگرها برای تراکنش های قدیمی ارائه دهید
+- میانبرهایی برای تغییر شبکه ها ارائه دهید.
+
+**مثال:** یک ظرف ظریف به کاربر نشان می دهد که چه توکن های مرتبطی در کیف پول خود دارد و CTA اصلی میانبری برای تغییر شبکه ارائه می دهد.
+
+![CTA اصلی از کاربر میخواهد شبکه را تغییر دهد](./Image7.png)
diff --git a/public/content/translations/fa/developers/docs/design-and-ux/index.md b/public/content/translations/fa/developers/docs/design-and-ux/index.md
new file mode 100644
index 00000000000..d5d609a3ded
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/design-and-ux/index.md
@@ -0,0 +1,85 @@
+---
+title: طراحی و UX در web3
+description: مقدمه ای بر طراحی و تحقیق UX در فضای Web3 و اتریوم
+lang: fa
+---
+
+آیا در طراحی با اتریوم تازه کار هستید؟ اینجا مکان مناسب شماست. جامعه اتریوم منابع مکتوبی برای آشنایی شما با اصول طراحی Web3 و تحقیق دارد. در مورد مفاهیم اصلی که ممکن است با سایر طرح های برنامه ای که با آنها آشنا هستید متفاوت باشد، آشنا خواهید شد.
+
+ابتدا به درک پایهای تری از web3 نیاز دارید؟ [**مرکز یادگیری**](/learn/) ما را بررسی کنید.
+
+## با تحقیقات کاربر شروع کنید {#start-with-user-research}
+
+طراحی موثر فراتر از ایجاد رابط های کاربری جذاب بصری است. این شامل کسب درک عمیق از نیازها، اهداف و عوامل محرک کاربر است. بنابراین، به شدت توصیه می کنیم که همه طراحان، یک فرآیند طراحی مانند [**فرایند الماس دوگانه**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)) را اتخاذ کنند تا اطمینان حاصل کنند که کار آنها هدفمند و آگاهانه است.
+
+- [Web3 به محققان و طراحان UX بیشتری نیاز دارد](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - مروری بر بلوغ طراحی فعلی
+- [راهنمای ساده برای تحقیقات UX در Web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - راهنمای ساده نحوه انجام تحقیق
+- [نحوه رویکرد به تصمیمات UX در Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - مروری کوتاه بر تحقیقات کمی و کیفی و تفاوتهای بین این دو (ویدئو، 6 دقیقه)
+- [محقق ux بودن در web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - دیدگاه شخصی در مورد اینکه یک محقق UX در web3 چگونه است
+
+## مطالعات پژوهشی در Web3 {#research-in-web3}
+
+این لیستی از تحقیقات کاربر انجام شده در Web3 است که ممکن است به تصمیم گیری در مورد طراحی و محصول کمک کند یا به عنوان الهام بخش برای انجام مطالعه شخصی باشد.
+
+| حوزه تمرکز | نام |
+|:------------------------------------------------------ |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ورود به رمزنگاری | [CRADL: UX رمز از](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
+| ورود به رمزنگاری | [CRADL: ورود به رمزارز](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
+| ورود به رمزنگاری | [بیت کوین در گزارش UX](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
+| ورود به رمزنگاری | [ConSensys: حالت درک Web3 درباره دنیا 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
+| ورود به رمزنگاری | [NEAR: شتاب دادن به تجربه به سوی پذیرش](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
+| سهام گذاری | [سهام گذاری: گرایش های کلیدی، و پیشبینیها - سهام گذار اتر](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
+| سهام گذاری | [سهام گذاری چندبرنامه ای](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
+| DAO | [به روز رسانی تحقیقات DAO در 2022: سازندگان DAO چه چیز لازم دارند؟](https://blog.aragon.org/2022-dao-research-update/) |
+| DeFi | [حالت Defi 2024](https://stateofdefi.org/) (نظرسنجی در حال انجام) |
+| DeFi | [استخرهای پوشش](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
+| DeFi | [ConSensys: گزارش تحقیقات کاربران DeFi در 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
+| متاورس | [Metaverse: گزارش تحقیقات کاربر](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
+| متاورس | [رفتن در سفری: تحقیق درباره کاربران در Metaverse](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (ویدیو، 27 دقیقه) |
+| آمار Ethereum.org UX | [داشبورد نظرسنجی قابلیت استفاده و رضایت کاربران - Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) |
+
+## طراحی برای web3 {#design-for-web3}
+
+- [راهنمای طراحی Web3 UX](https://web3ux.design/) - راهنمای عملی برای طراحی برنامه های Web3
+- [اصول طراحی وب 3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - چارچوبی از قوانین UX برای برنامه های مبتنی بر بلاک چین
+- [اصول طراحی بلاکچین](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - درسهایی که تیم طراحی بلاک چین در IBM آموخته است
+- [الگوهای طراحی Web3](https://www.web3designpatterns.io/) - یک کتابخانه انتخاب شده از الگوهای طراحی از محصولات واقعی Web3
+- [W3design.io](https://w3design.io/) - یک کتابخانه مدیریتشده از جریانهای رابط کاربری پروژههای مختلف در اکوسیستم
+- [Neueux.com](https://neueux.com/apps) - کتابخانه UI از جریان های کاربر با گزینه های مختلف فیلتر
+- [بحران قابلیت استفاده Web3: آنچه شما باید بدانید!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - بحث میزگرد در مورد مشکلات ساخت پروژه متمرکز بر توسعه دهنده (ویدئو، 34 دقیقه)
+
+## مطالعات موردی طراحی Web3 {#design-case-studies}
+
+- [Deep Work Studio](https://deepwork.studio/case-studies/)
+- [راهنمای Crypto UX](https://www.cryptouxhandbook.com/)
+- [فروش یک NFT در OpenSea](https://builtformars.com/case-studies/opensea)
+- [کنار گذاشتن کیف پول UX چگونه کیفهای پول باید عوض شوند](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (ویدیو، 20 دقیقه)
+
+## پاداشهای طراحی {#bounties}
+
+- [Dework](https://app.dework.xyz/bounties)
+- [گردهمآیی Buildbox](https://app.buidlbox.io/)
+- [گردهمآیی ETHGlobal](https://ethglobal.com/)
+
+## طراحی DAOها و جوامع {#design-daos-and-communities}
+
+در سازمان های حرفه ای جامعه محور شرکت کنید یا به گروه های طراحی بپیوندید تا درباره موضوعات و گرایش های مربوط به طراحی و تحقیق با سایر اعضا بحث کنید.
+
+- [Vectordao.com](https://vectordao.com/)
+- [Deepwork.studio](https://www.deepwork.studio/)
+- [Designer-dao.xyz](https://www.designer-dao.xyz/)
+- [We3.co](https://we3.co/)
+- [Openux.xyz](https://openux.xyz/)
+- [Open Source Web3Design](https://www.web3designers.org/)
+
+## سیستم طراحی {#design-systems}
+
+- [Optimism Design](https://www.figma.com/@optimism) (Figma)
+- [سیستم طراحی Ethereum.org Design](https://www.figma.com/@ethdotorg) (Figma)
+- [Finity، یک سیستم طراحی توسط پالیگان](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (فیگما)
+- [Kleros Design System](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
+- [Safe Design System](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
+- [سیستم طراحی ENS](https://thorin.ens.domains/)
+- [سیستم طراحی Mirror](https://degen-xyz.vercel.app/)
+
+**مقالات و پروژه های فهرست شده در این صفحه تاییدیه رسمی نیستند** و فقط برای اهداف اطلاع رسانی ارائه شده اند. ما لینک ها را بر اساس معیارهای [خطمشی لیستینگ](/contributing/design/adding-design-resources) خود به این صفحه اضافه میکنیم. اگر میخواهید پروژه/مقالهای اضافه کنیم، این صفحه را در [گیتهاب](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) ویرایش کنید.
diff --git a/public/content/translations/fa/developers/docs/evm/index.md b/public/content/translations/fa/developers/docs/evm/index.md
index 025100ab469..a7a5d7ef135 100644
--- a/public/content/translations/fa/developers/docs/evm/index.md
+++ b/public/content/translations/fa/developers/docs/evm/index.md
@@ -4,13 +4,11 @@ description: مقدمهای بر ماشین مجازی اتریوم و نحو
lang: fa
---
-نمونهسازی فیزیکی EVM را نمیتوان مانند اشاره کردن به یک ابر یا یک موج اقیانوس توصیف کرد، اما بهعنوان یک موجودیت واحد _وجود دارد_ که توسط هزاران رایانه متصل که یک کلاینت اتریوم را اجرا میکنند نگهداری میشود.
-
-خود پروتکل اتریوم صرفاً به منظور حفظ عملکرد مداوم، بدون وقفه و تغییر ناپذیر این ماشین حالت ویژه وجود دارد. این محیطی است که تمام حسابهای اتریوم و قراردادهای هوشمند در آن زندگی میکنند. در هر بلوک معین در زنجیره، اتریوم یک و تنها یک حالت «متعارف» دارد، و EVM همان چیزی است که قوانین را برای محاسبه یک حالت معتبر جدید از بلوکی به بلوک دیگر تعریف میکند.
+ماشین مجازی اتریوم (EVM) یک محیط مجازی غیرمتمرکز است که کد را به طور مداوم و ایمن در تمام گرههای اتریوم اجرا میکند. گرهها، EVM را برای اجرای قراردادهای هوشمند، با استفاده از "[گس](/gas/)" برای اندازه گیری تلاش محاسباتی مورد نیاز برای [عملیاتها](/developers/docs/evm/opcodes/) اجرا می کنند و تخصیص کارآمد منابع و امنیت شبکه را تضمین میکنند.
## پیشنیازها {#prerequisites}
-برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و مفید خواهد بود.درخت مرکل.
+برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/ Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و درخت مرکل.
## از دفتر کل تا ماشین حالات متناهی {#from-ledger-to-state-machine}
@@ -73,6 +71,7 @@ EVM به صورت یک [ماشین پشتهای](https://wikipedia.org/wiki/S
- [کدگذاریهای ماشین مجازی اتریوم](https://www.ethervm.io/)
- [مرجع تعاملی کدگذاری های ماشین مجازی اتریوم](https://www.evm.codes/)
- [مقدمهای کوتاه در مستندات Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
+- [تسلط بر اتریوم - ماشین مجازی اتریوم](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc)
## موضوعات مرتبط {#related-topics}
diff --git a/public/content/translations/fa/developers/docs/evm/opcodes/index.md b/public/content/translations/fa/developers/docs/evm/opcodes/index.md
index daa33d05b14..faeac85aa50 100644
--- a/public/content/translations/fa/developers/docs/evm/opcodes/index.md
+++ b/public/content/translations/fa/developers/docs/evm/opcodes/index.md
@@ -63,7 +63,7 @@ lang: fa
| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `هش` | | hash = addr.exists ? keccak256(addr.code) : 0 |
| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `.` | `block.coinbase` | | address of miner of current block |
+| 41 | COINBASE | 2 | `.` | `block.coinbase` | | آدرس پیشنهاد دهنده بلوک فعلی |
| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block |
| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block |
| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon |
@@ -71,7 +71,9 @@ lang: fa
| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei |
| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block |
-| 49-4F | _invalid_ | | | | | |
+| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
+| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
+| 4B-4F | _invalid_ | | | | | |
| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it |
| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory |
@@ -84,7 +86,9 @@ lang: fa
| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes |
| 5A | GAS | 2 | `.` | `gasRemaining` | | |
| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C-5E | _invalid_ | | | | | |
+| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
+| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | write word to transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
+| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copy memory from one area to another ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
| 5F | PUSH0 | 2 | `.` | `uint8` | | مقدار ثابت 0 را روی پشته هُل دهید |
| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack |
| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack |
@@ -152,9 +156,9 @@ lang: fa
| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) |
| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG1(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG1(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG1(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
+| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
+| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
+| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
| A5-EF | _invalid_ | | | | | |
| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen
| `success` | mem[retOst:retOst+retLen-1] := returndata | |
@@ -167,4 +171,4 @@ lang: fa
| FB-FC | _invalid_ | | | | | |
| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | | destroy contract and sends all funds to `addr` |
+| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract |
diff --git a/public/content/translations/fa/developers/docs/gas/index.md b/public/content/translations/fa/developers/docs/gas/index.md
index e82545c3b9b..df39471d21f 100644
--- a/public/content/translations/fa/developers/docs/gas/index.md
+++ b/public/content/translations/fa/developers/docs/gas/index.md
@@ -1,5 +1,5 @@
---
-title: گاز و کارمزدها
+title: گس و کارمزدها
description:
lang: fa
---
@@ -117,23 +117,7 @@ lang: fa
مقیاسپذیری لایه 2 یک ابتکار اولیه برای بهبود هزینه گاز، تجربه کاربری و مقیاسپذیری است. [اطلاعات بیشتر درباره مقیاسپذیری لایه 2](/developers/docs/scaling/#layer-2-scaling).
-## ارتقاء لندن (London Upgrade) / EIP - 1559 چه بود؟ {#what-was-the-london-upgrade-eip-1559}
-
-پیش از ارتقاء لندن، بلوکهای اتریوم اندازه ثابتی داشتند. در زمان تقاضای بالای شبکه، این بلوک ها با ظرفیت کامل کار می کردند. در نتیجه، کاربران عموماً باید صبر میکردند که تقاضای بالا کاهش یابد تا بتوانند در یک بلوک جای بگیرند، و این موضوع باعث میشد تجربه کاربری چندان خوب نباشد. ارتقاء لندن بلوکهای با اندازه متغیر را به اتریوم معرفی کرد.
-
-روشی که کارمزد تراکنش در شبکه اتریوم محاسبه میشد با [ارتقاء لندن](/history/#london) در اوت 2021 تغییر کرد. قبل از ارتقاء لندن، کارمزدها بدون تفکیک کارمزدهای `پایه` و `اولویت` به شرح زیر محاسبه می شد:
-
-فرض کنید آلیس باید 1 اتر به باب میپرداخت. در این تراکنش محدوده گاز برابر 21,000 واحد بود و قیمت گاز برابر 200 gwei.
-
-کارمز کلی معادل `واحد گاز (محدوده) * قیمت گاز به ازای هر واحد` یعنی `21,000 * 200 = 4,200,000 Gwei` یا 0.0042 ETH است
-
-اجرای [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) در ارتقاء لندن باعث شد که مکانیزم پرداخت کارمزد تراکنش پیچیدهتر شود، اما کارمزدهای گاز را قابل پیشبینیتر کرد که منجر به بازار کارمزد تراکنش کارآمدتر شد. کاربران میتوانند تراکنش را با یک `maxFeePerGas` مطابق با مبلغی که مایل هستند برای اجرای تراکنششان بپردازند ارسال کنند؛ با علم به این که نیازی نیست چیزی بیشتر از قیمت بازار برای گاز (`baseFeePerGas`) بپردازند، و اضافهپرداخت بیشتر از انعامشان را بازپس بگیرند.
-
-این ویدئو EIP-1559 و مزایای آن را توضیح میدهد:
-
-
-
-## نظارت بر کارمزدهای گاز {#moitoring-gas-fees}
+## نظارت بر کارمزدهای گس {#monitoring-gas-fees}
اگر میخواهید قیمت گاز را رصد کنید، تا بتوانید اترتان را با هزینه کمتری بفرستید، میتوانید از ابزارهای متفاوتی مثل موارد زیر استفاده کنید:
@@ -152,4 +136,4 @@ lang: fa
- [اثبات سهام در مقابل اثبات کار](https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/)
- [استراتژی های بهینهسازی گاز برای توسعه دهندگان](https://www.alchemy.com/overviews/solidity-gas-optimization)
- [اسناد EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
-- [منابع EIP-1559 تیم بیکو](https://hackmd.io/@timbeiko/1559-resources).
+- [منابع تیم بیکو درباره EIP-1559](https://hackmd.io/@timbeiko/1559-resources).
diff --git a/public/content/translations/fa/developers/docs/intro-to-ethereum/index.md b/public/content/translations/fa/developers/docs/intro-to-ethereum/index.md
index 6917b4429ee..d995b07a135 100644
--- a/public/content/translations/fa/developers/docs/intro-to-ethereum/index.md
+++ b/public/content/translations/fa/developers/docs/intro-to-ethereum/index.md
@@ -36,7 +36,7 @@ lang: fa
**اتر (ETH)** ارز رمزنگاریشده بومی اتریوم است. هدف ETH فراهمسازی امکان محاسبه برای بازار است. چنین بازاری یک مشوق اقتصادی برای شرکتکنندگان جهت تأیید و اجرای درخواستهای تراکنش و فراهمسازی منابع محاسباتی برای شبکه ایجاد میکند.
-هر شرکتکننده که درخواست تراکنشی را پخش میکند باید مقداری ETH را هم بهعنوان جایزه به شبکه ارائه دهد. این جایزه به کسی تعلق میگیرد که در نهایت کارِ تأیید تراکنش، اجرای آن، تحویل دادن آن به بلاکچین و پخش آن در شبکه را انجام میدهد.
+هر شرکتکننده که درخواست تراکنشی را پخش میکند باید مقداری ETH را هم بهعنوان جایزه به شبکه ارائه دهد. شبکه بخشی از جایزه را میسوزاند و بقیه را به هر کس که در نهایت کار تأیید تراکنش، اجرای آن، ثبت آن در بلاکچین و پخش آن به شبکه را انجام دهد، اعطا می کند.
مقدار ETH پرداختشده، با منابع مورد نیاز برای انجام محاسبه تطابق دارد. این جایزهها همچنین مانع از این میشوند که شرکتکنندگان بداندیش بتوانند عمداً با درخواست اجرای محاسبات بینهایت یا سایر اسکریپتهای پرمصرف شبکه را مسدود کنند، زیرا این شرکتکنندگان باید هزینه منابع محاسبه را بپردازند.
@@ -107,7 +107,7 @@ ETH (اتر) همچنین برای تامین امنیت اقتصاد-کریپت
## بیشتر بخوانید {#further-reading}
- [وایتپیپر اتریوم](/whitepaper/)
-- [به هر حال اتریوم چگونه کار می کند؟](https://www.preethikasireddy.com/post/how-does-ethereum-work-anyway) - _Preethi Kasirdy_ (**توجه** این منبع هنوز ارزشمند است اما آگاه باشید که این منبع پیش از [ادغام](/roadmap/merge) است و بنابراین هنوز هم به مکانیزم اثبات کار اتریوم اشاره دارد - اتریوم در واقع اکنون با استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos) ایمن شده است)
+- [به هر حال اتریوم چگونه کار می کند؟](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasirdy_ (**توجه** این منبع هنوز ارزشمند است اما توجه داشته باشید که این منبع پیش از [ادغام](/roadmap/merge) است و بنابراین هنوز هم به مکانیزم اثبات کار اتریوم اشاره دارد - اتریوم در واقع اکنون با استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos) ایمن شده است)
_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
diff --git a/public/content/translations/fa/developers/docs/mev/index.md b/public/content/translations/fa/developers/docs/mev/index.md
new file mode 100644
index 00000000000..33ef8da3222
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/mev/index.md
@@ -0,0 +1,221 @@
+---
+title: حداکثر ارزش قابل استخراج (MEV)
+description: مقدمهای بر حداکثر ارزش قابل استخراج (MEV)
+lang: fa
+---
+
+حداکثر ارزش قابل استخراج (MEV) به بیشترین ارزش قابل استخراج از تولید بلاک اشاره دارد که علاوه بر پاداش استاندارد بلاک شامل کارمزد تراکنشها است و این کارمزدها با وارد کردن، خارج کردن و تغییر در ترتیب تراکنشهای موجود در بلاک میتواند تغییر کند.
+
+## حداکثر ارزش قابل استخراج {#maximal-extractable-value}
+
+حداکثر ارزش قابل استخراج اولین بار در زمینه [اثبات کار](/developers/docs/consensus-mechanisms/pow/)استفاده شد و اوایل به "ارزش قابل استخراج استخراجگر" اشاره میکرد. این به این دلیل است که در اثبات کار استخراجگرها شمول، عدم شمول و ترتیب تراکنشها در بلاک را کنترل میکنند. با این حال، پس از تغییر الگوریتم اجماع به اثبات سهام با [ادغام](/roadmap/merge) اعتبارسنجها این وظایف را بر عهده دارند و استخراج دیگر بخشی از پروتکل اتریوم نیست. روشهای استخراج ارزش همچنان وجود دارند و به همین دلیل عبارت حداکثر ارزش قابل استخراج استفاده میشود.
+
+## پیشنیازها {#prerequisites}
+
+مطمئن شوید که با مفاهیم زیر آشنا هستید.[تراکنشها](/developers/docs/transactions/)، [بلاکها](/developers/docs/blocks/)، [اثبات سهام](/developers/docs/consensus-mechanisms/pos) و [گاز](/developers/docs/gas/). آشنایی با [اپلیکیشنهای غیرمتمرکز](/dapps/) و [امور مالی غیرمتمرکز](/defi/) نیز میتواند مفید باشد.
+
+## استخراج حداکثر ارزش قابل استخراج {#mev-extraction}
+
+در تئوری MEV به طور کامل به اعتبارسنجها تعلق میگیرد زیرا آنها تنها کسانی هستند که میتوانند اجرای یک فرصت سودآور MEV را تضمین کنند. اما در عمل،بیشترین نسبت MEV استخراج شده مربوط به فعالان مستقل شبکه است که با نام «جستجوگرها» (Searcher) شناخته میشوند. جستجوگرها الگوریتمهای پیچیده را بر روی داده بلاک چین اعمال میکنند تا موقعیتهای سودآور MEV را شناسایی کنند و رباتهایی دارند که به صورت خودکار تراکنشهای سودآور را به شبکه ارسال میکند.
+
+به هر حال اعتبارسنجها نیز بخشی از کل MEV را به دست میآورند زیرا جستجوگرها برای اینکه احتمال شمول تراکنش سودآور خود را در بلاک افزایش دهند کارمزد تراکنش بالاتری پرداخت میکنند (که این مبلغ به اعتبارسنج داده میشود). اگر فرض کنیم که جستجوگرها از نظر اقتصادی منطقی هستند، کارمزد تراکنشی که یک جستجوگر مایل است پرداخت کند نهایتا به اندازه 100 درصد MEV محاسبه شده است (زیرا اگر کارمزد تراکنش بالاتر باشد، جستجوگر ضرر میکند).
+
+به همین دلیل، برای برخی از موقعیتهای رقابتی MEV مثل [آربیتراژ در صرافی غیرمتمرکز](#mev-examples-dex-arbitrage)، جستجوگرها مجبورند تا 90 درصد و حتی بیشتر درآمد MEV را به صورت کارمزد تراکنش به اعتبارسنج بدهند زیرا تعداد زیادی از افراد میخواهند همان معامله سودآور آربیتراژ را اجرا کنند. این به این دلیل است که تنها راه تضمین اینکه تراکنش آربیتراژ آنها اجرایی میشود این است که آنها تراکنش را با بالاترین هزینه کارمزد ثبت کرده باشند.
+
+### بهینهسازی گاز {#mev-extraction-gas-golfing}
+
+این پدیده باعث به وجود آمدن یک مزیت رقابتی به نام خوب بودن در "مسابقه گاز" شده است - که به معنای برنامه نویسی تراکنشها به گونهای که کمترین مقدار گاز را مصرف کنند، میباشد - و چون این به جستجوگران اجازه میدهد قیمت گاز بالاتری را تعیین و پرداخت نمایند و در عین حال هزینههای کل مقدار گاز خود را ثابت نگه دارند (از آنجایی که هزینه گاز = قیمت گاز \* گاز مصرف شده میباشد).
+
+چند تکنیک معروف بهینهسازی گاز عبارتند از: استفاده از آدرسهایی که با یک رشته طولانی صفر شروع میشوند (به عنوان مثال [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)) زیرا فضای (و در نتیجه گاز) کمتری برای ذخیره میگیرند. و باقی ماندن توکن های کوچک [ERC-20](/developers/docs/standards/tokens/erc-20/) در قراردادها، از آنجا که برای مقداردهی اولیه یک اسلات ذخیره سازی گاز بیشتری نسبت به به روز رسانی اسلات ذخیره سازی دارد. یافتن تکنیکهای بیشتر برای کاهش مصرف گاز، یک حوزه تحقیقاتی فعال در میان جستجوگران است.
+
+### پیشتازان عمومی {#mev-extraction-generalized-frontrunners}
+
+به جای برنامهریزی الگوریتمهای پیچیده برای شناسایی فرصتهای سودآور MEV، برخی از جستجوگران از پیشتازان عمومی استفاده میکنند. پیشتازان عمومی، ربات هایی هستند که برای شناسایی تراکنش های سودآور، استخر حافظه را تماشا می کنند. پیشتاز کد تراکنش بالقوه سودآور را کپی میکند، آدرسها را با آدرس پیشتاز جایگزین میکند و تراکنش را به صورت محلی اجرا میکند تا دوباره بررسی کند که تراکنش اصلاحشده منجر به سود در آدرس پیشتاز شود. اگر تراکنش واقعاً سودآور باشد، پیشتاز تراکنش اصلاح شده را با آدرس جایگزین شده و گاز بالاتر ارسال میکند و تراکنش اصلی را «پیشآزمایی» میکند و MEV جستجوگر اصلی را دریافت میکند.
+
+### Flashbotها {#mev-extraction-flashbots}
+
+Flashbots یک پروژه مستقل است که کلاینت های اجرا را با سرویسی گسترش میدهد که به جستجوگران اجازه میدهد تا تراکنشهای MEV را بدون افشای آنها برای اعتبارسنج ها ارسال کنند. این کار مانع از پیشروی تراکنش ها توسط پیشتازان عمومی می شود.
+
+## نمونه های MEV {#mev-examples}
+
+MEV به چند روش در بلاک چین ظاهر می شود.
+
+### آربیتراژ DEX {#mev-examples-dex-arbitrage}
+
+آربیتراژ [صرافی غیرمتمرکز](/glossary/#dex) (DEX) ساده ترین و شناخته شده ترین فرصت MEV است. در نتیجه رقابتی ترین هم هست.
+
+این کار به این صورت است: اگر دو DEX یک توکن را با دو قیمت متفاوت ارائه دهند، یک نفر می تواند توکن را در DEX با قیمت پایین تر بخرد و آن را در DEX با قیمت بالاتر در یک تراکنش اتمی بفروشد. به لطف مکانیزم بلاک چین، این آربیتراژ واقعی و بدون ریسک است.
+
+[در اینجا مثالی است](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) از تراکنش آربیتراژ سودآور که در آن جستجوگر با استفاده از قیمتهای متفاوت جفت ETH/DAI در Uniswap در مقابل Sushiswap، 1000 ETH را به 1045 ETH تبدیل کرد.
+
+### نقد شدن ها {#mev-examples-liquidations}
+
+انحلال پروتکل وام دهی فرصت شناخته شده دیگری برای MEV است.
+
+پروتکلهای وام دهی مانند Maker و Aave از کاربران میخواهند که وثیقهای (مانند ETH) را واریز کنند. سپس این وثیقه سپرده شده برای وام دادن به سایر کاربران استفاده می شود.
+
+سپس کاربران میتوانند بسته به نیازشان داراییها و نشانهها را از دیگران قرض بگیرند (مثلاً اگر میخواهید در یک پیشنهاد حاکمیتی MakerDAO رای دهید، ممکن است MKR قرض بگیرید) تا درصد معینی از وثیقه سپردهشدهشان. به عنوان مثال، اگر مبلغ وام حداکثر 30٪ باشد، کاربری که 100 DAI را به پروتکل واریز می کند، می تواند تا 30 DAI دارایی دیگر را وام بگیرد. پروتکل درصد قدرت وام گیری دقیق را تعیین می کند.
+
+همچنان که ارزش وثیقه وام گیرنده نوسان پیدا می کند، قدرت استقراض آنها نیز تغییر می کند. اگر به دلیل نوسانات بازار، ارزش دارایی های قرض گرفته شده بیش از 30٪ ارزش وثیقه آنها باشد (باز هم، درصد دقیق آن توسط پروتکل تعیین می شود)، پروتکل معمولاً به هر کسی اجازه می دهد وثیقه را نقد کند و بلافاصله بدهی وام دهندگان را پرداخت کند (این شبیه نحوه عملکرد [مارجین کال](https://www.investopedia.com/terms/m/margincall.asp) در امور مالی سنتی است). در صورت انحلال، وام گیرنده معمولاً باید هزینه انحلال سنگینی را بپردازد، که بخشی از آن به مدیر تصفیه می رود - جایی که فرصت MEV به وجود می آید.
+
+جستجوگران برای تجزیه و تحلیل داده های بلاک چین در سریع ترین زمان ممکن رقابت می کنند تا تعیین کنند کدام وام گیرندگان می توانند منحل شوند و اولین کسانی باشند که تراکنش انحلال را ارسال می کنند و هزینه انحلال را برای خود دریافت می کنند.
+
+### معامله ساندویچی {#mev-examples-sandwich-trading}
+
+معامله ساندویچی یکی دیگر از روش های رایج استخراج MEV است.
+
+برای ساندویچ کردن، یک جستجوگر استخر حافظه را برای معاملات بزرگ DEX تماشا می کند. به عنوان مثال، فرض کنید شخصی می خواهد 10000 UNI با DAI در Uniswap بخرد. معامله ای به این بزرگی تأثیر مهمی بر جفت UNI/DAI خواهد داشت و به طور بالقوه قیمت UNI را نسبت به DAI افزایش می دهد.
+
+یک جستجوگر می تواند اثر قیمت تقریبی این معامله بزرگ را روی جفت UNI/DAI محاسبه کند و بلافاصله _قبل از_ معامله بزرگ، سفارش خرید بهینه را اجرا کند، UNI را ارزان بخرد، سپس دستور فروش را فوراً _ پس از_ تجارت بزرگ اجرا کند و آن را به قیمت بالاتر ناشی از سفارش بزرگ بفروشد.
+
+با این حال، ساندویچ کردن خطرناک تر است زیرا اتمی نیست (برخلاف آربیتراژ DEX، همانطور که در بالا توضیح داده شد) و مستعد [حمله salmonella ](https://github.com/Defi-Cartel/salmonella) است.
+
+### MEV در NFT {#mev-examples-nfts}
+
+MEV در فضای NFT یک پدیده نوظهور است و لزوماً سودآور نیست.
+
+با این حال، از آنجایی که تراکنشهای NFT روی همان بلاک چین مشترک سایر تراکنشهای اتریوم انجام میشوند، جستجوگران میتوانند از تکنیکهای مشابهی که در فرصتهای سنتی MEV در بازار NFT استفاده میشود، استفاده کنند.
+
+به عنوان مثال، اگر یک افت NFT محبوب وجود داشته باشد و یک جستجوگر یک NFT خاص یا مجموعه ای از NFT ها را بخواهد، می تواند یک تراکنش را طوری برنامه ریزی کند که اولین نفر در صف خرید NFT باشد، یا می تواند کل مجموعه NFT ها را در یک تراکنش خریداری کند. یا اگر یک NFT [به اشتباه با قیمت پایین فهرست شده باشد](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent)، جستجوگر می تواند از سایر خریداران پیشی گرفته و آن را با قیمت ارزان خریداری کند.
+
+یکی از نمونههای برجسته MEV در NFT زمانی رخ داد که یک جستجوگر 7 میلیون دلار برای [خرید](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) هر Cryptopunk در کف قیمت هزینه کرد. یک محقق بلاک چین [در توییتر توضیح داد](https://twitter.com/IvanBogatyy/status/1422232184493121538) چگونه خریدار با یک ارائه دهنده MEV کار می کرد تا خرید خود را مخفی نگه دارد.
+
+### قصه طولانی {#mev-examples-long-tail}
+
+آربیتراژ DEX، انحلال، و معامله ساندویچی همگی فرصت های MEV بسیار شناخته شده ای هستند و بعید است که برای جستجوگران جدید سودآور باشند. با این حال، قصه درازی از فرصت های کمتر شناخته شده MEV وجود دارد (MEV در NFT مسلماً یکی از این فرصت ها است).
+
+جستجوگرانی که به تازگی شروع به کار کرده اند ممکن است بتوانند با جستجوی MEV در این دقصه طولانی موفقیت بیشتری پیدا کنند. بورد کار MEV متعلق به Flashbot برخی از فرصتهای نوظهور را فهرست میکند.
+
+## اثرات MEV {#effects-of-mev}
+
+MEV کلا بد نیست - پیامدهای مثبت و منفی برای MEV روی اتریوم وجود دارد.
+
+### خوب {#effects-of-mev-the-good}
+
+بسیاری از پروژههای DeFi برای اطمینان از سودمندی و پایداری پروتکلهای خود به عوامل منطقی اقتصادی متکی هستند. به عنوان مثال، آربیتراژ DEX تضمین میکند که کاربران بهترین و صحیحترین قیمتها را برای توکنهای خود دریافت میکنند و پروتکلهای وامدهی به انحلال سریع متکی هستند، زمانی که وامگیرندگان کمتر از نسبت وثیقهگذاری میشوند تا اطمینان حاصل شود که وامدهندگان بازپرداخت میکنند.
+
+بدون جستجوگران منطقی که به دنبال و رفع ناکارآمدیهای اقتصادی باشند و از انگیزههای اقتصادی پروتکلها بهره ببرند، پروتکلهای DeFi و به طور کلی ممکن است مانند امروز قوی نباشند.
+
+### بد {#effects-of-mev-the-bad}
+
+در لایه برنامه، برخی از اشکال MEV، مانند معامله ساندویچی، منجر به یک تجربه بدتر برای کاربران می شود. کاربرانی که ساندویچ می شوند با افزایش افت قیمت و اجرای بدتر در معاملات خود مواجه می شوند.
+
+در لایه شبکه، پیشتازان تعمیم یافته و حراج های قیمت گس که اغلب در آن شرکت می کنند (زمانی که دو یا چند نفر پیشتاز برای گنجاندن تراکنش در بلوک بعدی با افزایش تدریجی قیمت گس تراکنش های خود رقابت می کنند) منجر به تراکم شبکه و قیمت بالای گس برای هر کس دیگری میشود که سعی در انجام معاملات منظم دارد.
+
+فراتر از آنچه در _در_ بلوکها اتفاق میافتد، MEV میتواند اثرات مضر _ما بین_ بلوکها داشته باشد. اگر MEV موجود در یک بلوک بهطور قابلتوجهی از پاداش بلوک استاندارد فراتر رود، اعتبارسنج ها ممکن است تشویق شوند تا بلوکها را مجددا سازماندهی کنند و MEV را برای خود بگیرند، که باعث سازماندهی مجدد بلاک چین و بیثباتی اجماع می شود.
+
+این امکان سازماندهی مجدد بلاکچین [قبلاً در بلاک چین بیتکوین بررسی شده است](https://dl.acm.org/doi/10.1145/2976749.2978408). از آنجایی که پاداش بلاک بیتکوین به نصف میرسد و کارمزد تراکنشها بخش بزرگتر و بیشتری از پاداش بلوک را تشکیل میدهند، شرایطی پیش میآید که از نظر اقتصادی منطقی میشود که استخراجکنندگان از پاداش بلوک بعدی صرفنظر کنند و در عوض بلوکهای گذشته را با کارمزد بالاتر یادآوری کنند. با رشد MEV، وضعیت مشابهی ممکن است در اتریوم رخ دهد و یکپارچگی بلاک چین را تهدید کند.
+
+## حالت MEV {#state-of-mev}
+
+استخراج MEV در اوایل سال 2021 افزایش یافت و منجر به قیمت بسیار بالای گس در چند ماه اول سال شد. ظهور رله MEV متعلق به Flashbots اثربخشی پیشتازان عمومی را کاهش داده و حراج قیمت گس را از زنجیره خارج کرده و قیمت گس را برای کاربران عادی کاهش داده است.
+
+در حالی که بسیاری از جستجوگران هنوز از MEV درآمد خوبی کسب می کنند، با شناخته شدن فرصت ها و رقابت جستجوگران بیشتر و بیشتر برای فرصت های مشابه، اعتبار سنج ها درآمد کل MEV بیشتری را به دست خواهند آورد (زیرا همان نوع حراج گس که در ابتدا در بالا توضیح داده شد. در Flashbots نیز اتفاق می افتد، البته به صورت خصوصی، و اعتبار سنج ها درآمد حاصل از گس را دریافت می کنند). MEV نیز منحصر به اتریوم نیست و با رقابتی شدن فرصت ها در اتریوم، جستجوگران به سمت بلاک چین های جایگزین مانند زنجیره هوشمند بایننس حرکت می کنند، جایی که فرصت های MEV مشابه با اتریوم با رقابت کمتری وجود دارد.
+
+از سوی دیگر، انتقال از اثبات کار به اثبات سهام و تلاش مداوم برای مقیاسبندی اتریوم با استفاده از جمعآوریها، همگی چشمانداز MEV را به روشهایی تغییر میدهند که هنوز تا حدودی نامشخص است. هنوز به خوبی شناخته نشده است که چگونه داشتن پیشنهاد دهندگان بلوک تضمین شده که از قبل کمی شناخته شده اند، دینامیک استخراج MEV را در مقایسه با مدل احتمالی در اثبات کار تغییر می دهد یا چگونه این امر هنگام [انتخاب رهبر مخفی منفرد0 مختل می شود ](https://ethresear.ch/t/secret-non-single-leader-election/11789) و [فناوری اعتبارسنج توزیع شده](/staking/dvt/) پیاده سازی می شود. به طور مشابه، باید دید چه فرصتهای MEV زمانی وجود دارد که بیشتر فعالیتهای کاربر از اتریوم خارج میشوند و روی رولآپ های لایه 2 و شاردهای آن منتقل میشوند.
+
+## MEV در اثبات سهام اتریوم (PoS) {#mev-in-ethereum-proof-of-stake}
+
+همانطور که توضیح داده شد، MEV پیامدهای منفی برای تجربه کلی کاربر و امنیت لایه اجماع دارد. اما انتقال اتریوم به اجماع اثبات سهام (معروف به "ادغام") به طور بالقوه خطرات جدید مرتبط با MEV را معرفی می کند:
+
+### تمرکزگرایی اعتبارسنج {#validator-centralization}
+
+در اتریوم پس از ادغام، اعتبارسنج ها (با سپرده گذاری امنیتی 32 اتریوم) در مورد اعتبار بلوک های اضافه شده به زنجیره بیکن اتفاق نظر دارند. از آنجایی که 32 ETH ممکن است از دسترس بسیاری خارج باشد، [پیوستن به یک استخر سهام](/staking/pools/) ممکن است گزینه عملی تری باشد. با این وجود، توزیع سالم [سهامگذاران انفرادی](/staking/solo/) ایده آل است، زیرا تمرکز اعتبارسنج ها را کاهش می دهد و امنیت اتریوم را بهبود می بخشد.
+
+با این حال، اعتقاد بر این است که استخراج MEV قادر به تسریع تمرکز اعتبارسنج است. این تا حدی به این دلیل است که اعتبارسنج ها [درآمد کمتری برای پیشنهاد بلوکها ](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) نسبت به ماینرهای قبلی دارند، استخراج MEV از زمان ادغام تا حد زیادی [درآمد اعتبارسنج ها را تحت تأثیر قرار میدهد](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb).
+
+استخرهای بزرگتر سهامگذاری احتمالاً منابع بیشتری برای سرمایه گذاری در بهینه سازی های لازم برای جذب فرصت های MEV خواهند داشت. هرچه این استخرها MEV بیشتری استخراج کنند، منابع بیشتری برای بهبود قابلیتهای استخراج MEV (و افزایش درآمد کلی) دارند، که اساساً [اقتصاد مقیاس](https://www.investopedia.com/terms/e/economiesofscale.asp#) ایجاد میکند.
+
+با منابع کمتری که در اختیار دارند، سهامداران انفرادی ممکن است نتوانند از فرصت های MEV سود ببرند. این ممکن است فشار را بر اعتبارسنج های مستقل برای پیوستن به استخرهای قدرتمند برای افزایش درآمدشان افزایش دهد و تمرکززدایی در اتریوم را کاهش دهد.
+
+### استخرهای حافظه دارای مجوز {#permissioned-mempools}
+
+در پاسخ به حملات ساندویچ و پیشتاز، معامله گران ممکن است شروع به انجام معاملات خارج از زنجیره با اعتبارسنج ها برای حفظ حریم خصوصی تراکنش کنند. معاملهگر به جای ارسال یک تراکنش بالقوه MEV به استخر حافظه عمومی، آن را مستقیماً برای اعتبارسنج ارسال میکند که آن را در یک بلوک قرار میدهد و سود را با معاملهگر تقسیم میکند.
+
+«استخرهای تاریک» نسخه بزرگتری از این ترتیب است و بهعنوان استخرهای حافظه مجاز و فقط قابل دسترسی برای کاربرانی که مایل به پرداخت هزینههای خاصی هستند، عمل میکنند. این روند بی مجوز بودن و عدم اعتماد اتریوم را کاهش می دهد و به طور بالقوه بلاک چین را به مکانیزم «پرداخت برای بازی» تبدیل می کند که به نفع بالاترین پیشنهاد دهنده است.
+
+استخرهای حافظه دارای مجوز همچنین خطرات متمرکزسازی که در بخش قبل توضیح داده شد را تسریع می کنند. استخرهای بزرگی که دارای اعتبارسنج های متعدد هستند، احتمالاً از ارائه حریم خصوصی تراکنش به معامله گران و کاربران سود می برند و درآمد MEV آنها را افزایش می دهند.
+
+مبارزه با این مشکلات مرتبط با MEV در اتریوم پس از ادغام، یک حوزه اصلی تحقیق است. تا به امروز، دو راه حل پیشنهادی برای کاهش تأثیر منفی MEV بر تمرکززدایی و امنیت اتریوم پس از ادغام، **جداسازی پیشنهاد دهنده-سازنده (PBS)** و **API Builder** هستند.
+
+### تفکیک پیشنهاد دهنده و سازنده {#proposer-builder-separation}
+
+هم در اثبات کار و هم در اثبات سهام، گرهی که یک بلوک می سازد، آن را برای اضافه کردن به زنجیره به گره های دیگر شرکت کننده در اجماع پیشنهاد می کند. یک بلوک جدید پس از ساختن یک استخراجگر دیگر در بالای آن (در PoW) یا دریافت تاییدیه از اکثر اعتبارسنج ها (در PoS) بخشی از زنجیره متعارف می شود.
+
+ترکیبی از نقش های سازنده بلوک و پیشنهاد دهنده بلوک چیزی است که بیشتر مشکلات مربوط به MEV را که قبلاً توضیح داده شد معرفی می کند. برای مثال، گرههای اجماع انگیزه ایجاد سازماندهی مجدد زنجیرهای در حملات طولانی برای به حداکثر رساندن درآمد MEV دارند.
+
+[تفکیک پیشنهاد دهنده-سازنده](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) برای کاهش تأثیر MEV، به ویژه در لایه اجماع، طراحی شده است. ویژگی اصلی PBS جداسازی قوانین سازنده بلوک و پیشنهاد دهنده بلوک است. اعتبارسنج ها همچنان مسئول پیشنهاد و رایگیری در مورد بلوکها هستند، اما دسته جدیدی از نهادهای تخصصی به نام **بلوک سازان**، وظیفه سفارش تراکنشها و ساخت بلوکها را بر عهده دارند.
+
+تحت PBS، یک سازنده بلوک یک بسته تراکنش ایجاد می کند و پیشنهادی را برای گنجاندن آن در یک بلوک بیکن چین (به عنوان "بار اجرایی") قرار می دهد. اعتبارسنج انتخاب شده برای پیشنهاد بلوک بعدی، پیشنهادات مختلف را بررسی میکند و بستهای را با بالاترین هزینه انتخاب میکند. PBS اساساً یک بازار حراج ایجاد می کند، جایی که سازندگان با اعتبارسنج هایی که فضای بلوک را می فروشند، مذاکره می کنند.
+
+طرحهای فعلی PBS از یک [طرح آشکارسازی تعهد](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) استفاده میکنند که در آن سازندگان فقط یک تعهد رمزنگاری به محتویات یک بلوک (سر بلوک) را همراه با پیشنهادات خود منتشر میکنند. پس از پذیرش پیشنهاد برنده، پیشنهاد دهنده یک پیشنهاد بلوک امضا شده ایجاد می کند که شامل سر بلوک است. انتظار میرود سازنده بلوک پس از مشاهده طرح بلوک امضاشده، متن کامل بلوک را منتشر کند، و همچنین باید قبل از نهایی شدن، [تأییدکنندههای](/glossary/#attestation) کافی از اعتبارسنج ها دریافت کند.
+
+#### چگونه جداسازی پیشنهاد دهنده و سازنده تأثیر MEV را کاهش می دهد؟ {#how-does-pbs-curb-mev-impact}
+
+جداسازی پیشنهاد دهنده-سازنده درون پروتکل، با حذف استخراج MEV از حوزه اعتبارسنج ها، اثر MEV بر اجماع را کاهش میدهد. در عوض، سازندگان بلوک که سختافزار تخصصی را اجرا میکنند، فرصتهای MEV را در آینده به دست خواهند آورد.
+
+این امر اعتبارسنج ها را بهطور کامل از درآمد مرتبط با MEV مستثنی نمیکند، زیرا سازندگان باید برای پذیرش بلوکهایشان توسط اعتبارسنج ها، قیمت بالایی داشته باشند. با این وجود، با توجه به اینکه اعتبارسنج ها دیگر مستقیماً بر روی بهینهسازی درآمد MEV تمرکز نمیکنند، تهدید حملات طولانی کاهش مییابد.
+
+جداسازی پیشنهاد دهنده-سازنده همچنین خطرات متمرکزسازی MEV را کاهش می دهد. به عنوان مثال، استفاده از یک طرح تعهد-افشا، نیاز سازندگان را به اعتماد به اعتبارسنج ها برای ربودن فرصت MEV یا افشای آن در معرض سایر سازندگان از بین میبرد. این امر مانع سود سهامداران انفرادی از MEV را کاهش می دهد، در غیر این صورت، سازندگان به طرفداری از استخرهای بزرگ با شهرت خارج از زنجیره و انجام معاملات خارج از زنجیره با آنها گرایش پیدا می کنند.
+
+به طور مشابه، اعتبارسنج ها مجبور نیستند به سازندگان بلوک اعتماد کنند که بدنه های بلوک را پس نمیکشند یا بلوک های نامعتبر را منتشر نمی کنند زیرا پرداخت بدون قید و شرط است. حتی اگر بلوک پیشنهادی در دسترس نباشد یا توسط اعتبارسنجی دیگر نامعتبر اعلام شود، هزینه اعتبارسنج همچنان پردازش میکند. در مورد دوم، بلوک به سادگی دور ریخته می شود و سازنده بلوک را مجبور می کند که تمام هزینه های تراکنش و درآمد MEV را از دست بدهد.
+
+### API سازندهی بلوک {#builder-api}
+
+در حالی که جداسازی پیشنهاد دهنده و سازنده وعده کاهش اثرات استخراج MEV را می دهد، اجرای آن نیازمند تغییراتی در پروتکل اجماع است. به طور خاص، قانون [انتخاب فورک](/developers/docs/consensus-mechanisms/pos/#fork-choice) در بیکن چین باید به روز شود. [API سازنده بلوک](https://github.com/ethereum/builder-specs) یک راه حل موقت است که با هدف ارائه پیاده سازی کاری جداسازی پیشنهاد دهنده-سازنده، البته با مفروضات اعتماد بالاتر است.
+
+API سازنده بلوک نسخه اصلاح شده [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) است که توسط کلاینت های لایه اجماع برای درخواست بارهای اجرایی از کلاینت های لایه اجرا استفاده می شود. همانطور که در [مشخصات اعتبارسنج صادق](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) مشخص شده است، اعتبارسنجی هایی که برای وظایف پیشنهادی بلوک انتخاب میشوند، یک بسته تراکنش را از یک کلاینت اجرا که متصل است درخواست میکنند که آن را در بلوک پیشنهادی بیکن چین قرار میدهند.
+
+API سازنده بلوک همچنین به عنوان یک میان افزار بین اعتبارسنج و کلاینت های لایه اجرا عمل می کند. اما متفاوت است زیرا به اعتبارسنج های موجود در بیکن چین اجازه میدهد تا بلوکها را از موجودیتهای خارجی تهیه کنند (بهجای ساختن یک بلوک به صورت محلی با استفاده از یک کلاینت اجرا).
+
+در زیر یک نمای کلی از نحوه عملکرد API سازنده بلوک آورده شده است:
+
+1. Builder API اعتبارسنج را به شبکه ای از سازنده های بلوک که کلاینت های لایه اجرا را اجرا می کنند متصل می کند. مانند PBS، سازندگان بلوک نیز طرف های تخصصی هستند که در بلوکسازی با منابع فشرده سرمایهگذاری میکنند و از استراتژیهای مختلف برای به حداکثر رساندن درآمد حاصل از MEV به علاوه ترفند های اولویت بندی استفاده میکنند.
+
+2. یک اعتبارسنج (که یک کلاینت لایه اجماع را اجرا می کند) بارهای اجرایی را به همراه پیشنهادات از شبکه سازندگان درخواست می کند. پیشنهادهای سازنده شامل سرفصل بار اجرایی - تعهد رمزنگاری به محتویات بار - و هزینه ای است که باید به اعتبارسنج پرداخت شود.
+
+3. اعتبارسنج پیشنهادهای دریافتی را بررسی میکند و بار اجرایی را با بالاترین هزینه انتخاب میکند. با استفاده از API سازنده، اعتبارسنج یک پیشنهاد بلوک "کور" در بیکن ایجاد می کند که فقط شامل امضای آنها و سر پرداخت اجرا می شود و آن را برای سازنده ارسال می کند.
+
+4. سازندهای که API سازنده را اجرا میکند، انتظار میرود که با مشاهده پیشنهاد بلوک کور، با بار اجرایی کامل پاسخ دهد. این به اعتبارسنج اجازه می دهد تا یک بلوک بیکن "امضا" شده ایجاد کند که در سراسر شبکه منتشر می شود.
+
+5. هنوز انتظار میرود که اعتبارسنج با استفاده از API سازنده، در صورتی که سازنده بلوک به سرعت پاسخ ندهد، یک بلوک را به صورت محلی بسازد، بنابراین پاداشهای پیشنهاد بلوک را از دست نمیدهند. با این حال، اعتبارسنج نمیتواند بلوک دیگری را با استفاده از تراکنشهای آشکار شده یا مجموعهای دیگر ایجاد کند، زیرا به معنای _مبهم سازی_ (امضا کردن دو بلوک در یک اسلات) است، که یک جرم قابل جریمه شدن است.
+
+یک نمونه از پیادهسازی API سازنده همین [MEV Boost](https://github.com/flashbots/mev-boost) است، یک بهینه سازی در [مکانیسم حراج فلشباتها](https://docs.flashbots.net/Flashbots-auction/overview/) که برای مهار اثرات جانبی منفی MEV در اتریوم طراحی شده است. حراج Flashbots به اعتبارسنج ها در اثبات سهام اجازه می دهد تا کار ساخت بلوک های سودآور را به طرف های تخصصی به نام **جستجوگرها** برون سپاری کنند.
+
+جستجوگران به دنبال فرصتهای سودآور MEV میگردند و بستههای تراکنش را برای مسدود کردن پیشنهادکنندگان همراه با [مناقصه با قیمت مهر و موم شده](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) برای درج در بلوک ارسال میکنند. اعتباردهندهای که mev-geth را اجرا میکند، یک نسخه فورک شده از کلاینت go-ethereum (Geth) فقط باید بستهای را انتخاب کند که بیشترین سود را دارد و آن را به عنوان بخشی از بلوک جدید قرار دهد. برای محافظت از پیشنهاد دهندگان بلوک (اعتبارسنج ها) در برابر هرزنامه و تراکنشهای نامعتبر، بستههای تراکنش قبل از رسیدن به پیشنهاددهنده از **relayerها** برای اعتبارسنجی عبور میکنند.
+
+MEV Boost همان حراج Flashbots اصلی را حفظ می کند، البته با ویژگی های جدیدی که برای تغییر اتریوم به اثبات سهام طراحی شده است. جستجوگران هنوز تراکنشهای سودآور MEV را برای گنجاندن در بلوکها پیدا میکنند، اما دسته جدیدی از طرفهای تخصصی به نام **سازندگان بلوک** مسئول جمعآوری تراکنشها و بستهها در بلوکها هستند. سازنده پیشنهادات قیمت مهر و موم شده را از جستجوگران می پذیرد و بهینه سازی هایی را برای یافتن سودآورترین سفارش اجرا می کند.
+
+رله همچنان مسئول اعتبارسنجی بسته های تراکنش قبل از ارسال آنها به پیشنهاد دهنده است. با این حال، MEV Boost در این حین **scrows** را معرفی میکند که مسئول ارائه [در دسترس بودن دادهها](/developers/docs/data-availability/) با ذخیره بدنههای بلوک ارسال شده توسط سازندهها و سرهای بلوک ارسال شده توسط اعتبارسنج ها هستند. در اینجا، یک اعتبارسنج متصل به یک رله، بارهای اجرایی موجود را میپرسد و از الگوریتم سفارش MEV Boost برای انتخاب سر بار پرداخت با بالاترین پیشنهاد + نکات MEV استفاده میکند.
+
+#### چگونه API سازنده تأثیر MEV را کاهش می دهد؟ {#how-does-builder-api-curb-mev-impact}
+
+مزیت اصلی API سازنده پتانسیل آن برای دموکراتیک کردن دسترسی به فرصت های MEV است. استفاده از طرحهای commit-reveal مفروضات اعتماد را حذف میکند و موانع ورود را برای اعتبارسنج ها که به دنبال بهرهمندی از MEV هستند کاهش میدهد. این باید فشار روی سهامگذاران انفرادی را برای ادغام با استخرهای بزرگ به منظور افزایش سود MEV کاهش دهد.
+
+اجرای گسترده API سازنده رقابت بیشتر بین سازندگان بلوک را تشویق می کند که مقاومت در برابر سانسور را افزایش می دهد. از آنجایی که اعتبارسنج ها پیشنهادهای سازندههای متعدد را بررسی میکنند، سازندهای که قصد سانسور یک یا چند تراکنش کاربر را دارد باید از همه سازندگان غیرسانسورکننده دیگر پیشی بگیرد تا موفق شود. این به طور چشمگیری هزینه سانسور کاربران را افزایش می دهد و این عمل را دلسرد می کند.
+
+برخی از پروژهها، مانند MEV Boost، از API سازنده به عنوان بخشی از ساختار کلی استفاده میکنند که برای ارائه حریم خصوصی تراکنشها به برخی از طرفها طراحی شده است، مانند معاملهگرانی که سعی میکنند از حملات پیشتازی/ ساندویچ اجتناب کنند. این با ارائه یک کانال ارتباطی خصوصی بین کاربران و سازندگان بلوک به دست می آید. برخلاف استخرهای حافظه دارای مجوز که قبلا توضیح داده شد، این رویکرد به دلایل زیر سودمند است:
+
+1. وجود سازنده های متعدد در بازار سانسور را غیرعملی می کند که به نفع کاربران است. در مقابل، وجود استخرهای تاریک متمرکز و مبتنی بر اعتماد، قدرت را در دستان معدود سازندگان بلوک متمرکز میکند و امکان سانسور را افزایش میدهد.
+
+2. نرم افزار API سازنده منبع باز است که به هر کسی اجازه می دهد خدمات سازنده بلوک را ارائه دهد. این بدان معناست که کاربران مجبور به استفاده از بلوکساز خاصی نیستند و بیطرفی و عدم مجوزمحوری اتریوم را بهبود میبخشد. علاوه بر این، معاملهگرانی که به دنبال MEV هستند، سهواً با استفاده از کانالهای تراکنش خصوصی، به متمرکزسازی کمک نمیکنند.
+
+## منابع مرتبط {#related-resources}
+
+- [اسناد Flashbotها](https://docs.flashbots.net/)
+- [گیتهاب Flashbotها](https://github.com/flashbots/pm)
+- [MEV-Explore](https://explore.flashbots.net/) - _داشبورد و کاوشگر تراکنش زنده برای تراکنشهای MEV_
+- [mevboost.org](https://www.mevboost.org/) - _ردیاب با آمار بیدرنگ برای رلههای MEV-Boost و سازندگان بلوک_
+
+## بیشتر بخوانید {#further-reading}
+
+- [ارزش قابل استخراج استخراجگر (MEV) چیست؟](https://blog.chain.link/what-is-miner-extractable-value-mev/)
+- [MEV و Me](https://www.paradigm.xyz/2021/02/mev-and-me)
+- [اتریوم یک جنگل تاریک است](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/)
+- [فرار از جنگل تاریک](https://samczsun.com/escaping-the-dark-forest/)
+- [Flashbotها: فرار رو به جلو در بحران MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752)
+- [@bertcmiller's MEV Threads](https://twitter.com/bertcmiller/status/1402665992422047747)
+- [MEV-Boost: معماری Flashbots آماده ادغام](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
+- [MEV Boost چیست؟](https://www.alchemy.com/overviews/mev-boost)
+- [چرا mev-boost را اجرا کنید؟](https://writings.flashbots.net/writings/why-run-mevboost/)
+- [راهنمای سفر به اتریوم](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum)
diff --git a/public/content/translations/fa/developers/docs/networking-layer/index.md b/public/content/translations/fa/developers/docs/networking-layer/index.md
new file mode 100644
index 00000000000..519af1b03ef
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/networking-layer/index.md
@@ -0,0 +1,155 @@
+---
+title: لایهی شبکه
+description: مقدمه ای بر لایه شبکه اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+اتریوم یک شبکه همتا به همتا با هزاران گره است که باید بتوانند با استفاده از پروتکل های استاندارد شده با یکدیگر ارتباط برقرار کنند. "لایه شبکه" پشته ای از پروتکل ها است که به آن گره ها اجازه می دهد یکدیگر را پیدا کنند و اطلاعات را مبادله کنند. این شامل اطلاعات "شایعه" (ارتباطات یک به چند) در شبکه و همچنین تعویض درخواست ها و پاسخ ها بین گره های خاص (ارتباط یک به یک) است. هر گره برای اطمینان از ارسال و دریافت اطلاعات صحیح باید به قوانین شبکه خاصی پایبند باشد.
+
+نرمافزار کلاینت دارای دو بخش است (کلینتهای اجرا و کلاینتهای اجماع) که هر کدام دارای پشته شبکه مجزای خود هستند. علاوه بر برقراری ارتباط با سایر گرههای اتریوم، کلاینتهای اجرا و اجماع باید با یکدیگر ارتباط برقرار کنند. در این صفحه توضیح مقدماتی در مورد پروتکل هایی که این ارتباط را فعال می کنند ارائه می دهد.
+
+کلاینت های اجرا تراکنش ها را از طریق شبکه همتا به همتای لایه اجرا شایع می کنند. این امر نیاز به ارتباط رمزگذاری شده بین همتایان تایید شده دارد. هنگامی که یک اعتبارسنج برای پیشنهاد یک بلوک انتخاب می شود، تراکنش ها از مخزن تراکنش های محلی گره از طریق یک اتصال RPC محلی به کلاینت های اجماع منتقل می شوند که در بلوک های بیکن بسته بندی می شوند. کلاینت های اجماع سپس بلوک های بیکن را در شبکه p2p خود شایع می کنند. این به دو شبکه p2p جداگانه نیاز دارد: یکی اتصال کلاینت های اجرا برای شایعات تراکنش و دیگری اتصال کلاینت های اجماع برای شایعات بلوک.
+
+## موارد مورد نیاز {#prerequisites}
+
+مقداری دانش درباره [گره ها و کلاینت ihd](/developers/docs/nodes-and-clients/) اتریوم برای درک این صفحه مفید خواهد بود.
+
+## لایه اجرا {#execution-layer}
+
+پروتکل های شبکه لایه اجرا به دو پشته تقسیم می شوند:
+
+- پشته اکتشاف: بر روی UDP ساخته شده است و به یک گره جدید اجازه می دهد همتاهایی را برای اتصال پیدا کند
+
+- پشته DevP2P: در بالای TCP قرار می گیرد و گره ها را قادر به تبادل اطلاعات می کند
+
+هر دو پشته به صورت موازی کار می کنند. پشته اکتشاف، شرکتکنندگان جدید شبکه را به شبکه تغذیه میکند و پشته DevP2P تعاملات آنها را فعال میکند.
+
+### اکتشاف {#discovery}
+
+اکتشاف فرآیند یافتن گره های دیگر در شبکه است. این بوت استرپ با استفاده از مجموعه کوچکی از بوتنودها انجام می شود (گره هایی که آدرس آنها [هاردکد](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) در کلاینت است تا بتوان آنها را فورا پیدا کرد و کلاینت را به همتایان متصل کرد). این بوتنودها فقط برای معرفی یک گره جدید به مجموعهای از همتایان وجود دارند - این تنها هدف آنهاست، آنها در کارهای عادی کلاینت مانند همگامسازی زنجیره شرکت نمیکنند و تنها در اولین باری که کلاینت چرخانده میشود، استفاده میشوند.
+
+پروتکل مورد استفاده برای تعاملات گره-بوتنود یک شکل تغییر یافته از [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) است که از [جدول هش توزیع شده](https://en.wikipedia.org/wiki/Distributed_hash_table) برای به اشتراک گذاری لیست گره ها استفاده می کند. هر گره دارای نسخه ای از این جدول است که حاوی اطلاعات مورد نیاز برای اتصال به نزدیکترین همتایان خود است. این "نزدیک" بار جغرافیایی ندارد - بلکه در فاصله با شباهت شناسه گره تعریف می شود. جدول هر گره به عنوان یک ویژگی امنیتی به طور منظم به روز می شود. به عنوان مثال، در [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)، گرههای پروتکل اکتشاف همچنین میتوانند «تبلیغاتی» را ارسال کنند که پروتکلهای فرعی را که کلاینت پشتیبانی میکند، نمایش میدهد و به همتایان اجازه میدهد در مورد پروتکلهایی که هر دو میتوانند برای برقراری ارتباط استفاده کنند، مذاکره کنند.
+
+اکتشاف با یک بازی پینگ پنگ شروع می شود. یک پینگ پنگ موفق، گره جدید را به یک بوت نود "پیوند" می کند. پیام اولیه ای که به بوت نود از وجود گره جدیدی که وارد شبکه می شود هشدار می دهد `PING` است. این `PING` شامل اطلاعات هش شده در مورد گره جدید، بوت نود و یک مهر زمان انقضا است. بوتنود `PING` را دریافت میکند و یک `PONG` حاوی هش `PING` برمیگرداند. اگر هشهای `PING` و `PONG` مطابقت داشته باشند، ارتباط بین گره جدید و بوتنود تأیید میشود و گفته میشود که آنها "متصل" شدهاند.
+
+پس از اتصال، گره جدید می تواند یک درخواست `FIND-NEIGHBOURS` را به بوت نود ارسال کند. داده های بازگردانده شده توسط بوت نود شامل لیستی از همتایان است که گره جدید می تواند به آنها متصل شود. اگر گرهها متصل نباشند، درخواست `FIND-NEIGHBOURS` با شکست مواجه میشود، بنابراین گره جدید نمیتواند وارد شبکه شود.
+
+هنگامی که گره جدید لیستی از همسایگان را از بوت نود دریافت می کند، مبادله PING-PONG را با هر یک از آنها آغاز می کند. پینگپنگهای موفق، گره جدید را با همسایگانش پیوند میدهند و تبادل پیام را ممکن میسازند.
+
+```
+start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours
+```
+
+کلاینت های اجرا در حال حاضر از پروتکل اکتشاف [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) استفاده می کنند و تلاش فعالی برای انتقال به پروتکل [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) وجود دارد.
+
+#### ENR: رکوردهای گره اتریوم {#enr}
+
+این [رکورد گره اتریوم (ENR)](/developers/docs/networking-layer/network-addresses/) یک شی است که شامل سه عنصر اساسی است: یک امضا (هش از محتویات رکورد ساخته شده بر اساس برخی از طرح های هویت توافق شده)، یک شماره دنباله ای که تغییرات را در رکورد ردیابی می کند، و یک لیست دلخواه از جفت های کلیدهای ارزش. این یک فرمت مقاوم در برابر آینده است که امکان تبادل آسان اطلاعات شناسایی بین همتایان جدید را فراهم می کند و فرمت [آدرس شبکه](/developers/docs/networking-layer/network-addresses) ترجیحی برای گره های اتریوم است.
+
+#### چرا اکتشاف بر اساس UDP ساخته شده است؟ {#why-udp}
+
+UDP هیچ گونه بررسی خطا، ارسال مجدد بسته های ناموفق، یا باز و بسته شدن پویا اتصالات را پشتیبانی نمی کند - در عوض، صرف نظر از اینکه آیا با موفقیت دریافت شده است یا خیر، فقط یک جریان مداوم از اطلاعات را به سمت یک هدف شلیک می کند. این عملکرد حداقلی همچنین به هزینه حداقلی تبدیل می شود و این نوع اتصال را بسیار سریع می کند. برای اکتشاف، جایی که یک گره به سادگی میخواهد حضور خود را نشان دهد تا پس از آن یک ارتباط رسمی با همتا برقرار کند، UDP کافی است. با این حال، برای بقیه پشته شبکه، UDP برای هدف امورات مناسب نیست. تبادل اطلاعات بین گرهها بسیار پیچیده است و بنابراین به پروتکل کاملتری نیاز دارد که بتواند از ارسال مجدد، بررسی خطا و غیره پشتیبانی کند. سربار اضافی مرتبط با TCP ارزش عملکرد اضافی را دارد. بنابراین، اکثر پشته P2P روی TCP عمل می کند.
+
+### DevP2P {#devp2p}
+
+DevP2P خودش مجموعه کاملی از پروتکلهایی است که اتریوم برای ایجاد و نگهداری شبکه همتا به همتا پیادهسازی میکند. پس از ورود گره های جدید به شبکه، تعاملات آنها توسط پروتکل هایی در پشته [DevP2P](https://github.com/ethereum/devp2p) کنترل می شود. همه اینها در بالای TCP قرار دارند و شامل پروتکل انتقال RLPx، پروتکل سیمی و چندین پروتکل فرعی هستند. پروتکل [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) پروتکلی است که بر شروع، احراز هویت و حفظ نشست ها بین گره ها حاکم است. RLPx پیام ها را با استفاده از RLP (پیشوند طول بازگشتی) رمزگذاری می کند که یک روش بسیار کارآمد برای رمزگذاری داده ها در یک ساختار حداقلی برای ارسال بین گره ها است.
+
+یک جلسه RLPx بین دو گره با یک ارتباط گیری رمزنگاری اولیه آغاز می شود. این مرحله شامل ارسال یک پیام احراز هویت توسط گره است که سپس توسط همتا تایید می شود. در تأیید موفقیت آمیز، همتا یک پیام تأیید اعتبار برای بازگشت به گره آغازگر تولید می کند. این یک فرآیند تبادل کلید است که گره ها را قادر می سازد به صورت خصوصی و ایمن با هم ارتباط برقرار کنند. یک ارتباط گیری رمزنگاری شده موفق، سپس هر دو گره را تحریک می کند تا پیام "سلام" را به یکدیگر "روی سیم" ارسال کنند. پروتکل سیمی با تبادل موفقیت آمیز پیام های سلام آغاز می شود.
+
+پیام های سلام شامل موارد زیر است:
+
+- نسخه پروتکل
+- شناسه کلاینت
+- پورت
+- شناسه گره
+- لیستی از پروتکل های فرعی پشتیبانی شده
+
+این اطلاعات مورد نیاز برای یک تعامل موفق است زیرا مشخص می کند که چه قابلیت هایی بین هر دو گره به اشتراک گذاشته می شود و ارتباطات را پیکربندی می کند. یک فرآیند مذاکره پروتکل فرعی وجود دارد که در آن لیست های پروتکل های فرعی پشتیبانی شده توسط هر گره با هم مقایسه می شوند و مواردی که برای هر دو گره مشترک هستند می توانند در نشست استفاده شوند.
+
+همراه با پیام های سلام، پروتکل سیم همچنین می تواند یک پیام "قطع اتصال" ارسال کند که به همتایان هشدار می دهد که اتصال بسته خواهد شد. پروتکل سیمی همچنین شامل پیام های PING و PONG است که به صورت دوره ای برای باز نگه داشتن یک جلسه ارسال می شوند. بنابراین مبادلات پروتکل RLPx و سیمی پایههای ارتباط بین گرهها را ایجاد میکنند و داربستی را برای اطلاعات مفیدی که طبق یک پروتکل فرعی خاص مبادله میشوند فراهم میکنند.
+
+### پروتکل های فرعی {#sub-protocols}
+
+#### پروتکل سیمی {#wire-protocol}
+
+هنگامی که همتاها متصل می شوند و یک نشست RLPx شروع می شود، پروتکل سیمی نحوه ارتباط همتاها را مشخص می کند. در ابتدا، پروتکل سیمی سه وظیفه اصلی را تعریف کرد: همگام سازی زنجیره ای، انتشار بلوک و تبادل تراکنش. با این حال، هنگامی که اتریوم به اثبات سهام روی آورد، انتشار بلوک و همگام سازی زنجیره بخشی از لایه اجماع شد. مبادله تراکنش هنوز در اختیار کلاینت اجرا است. تبادل تراکنش به مبادله تراکنش های معلق بین گره ها اشاره دارد تا سازندگان بلوک بتوانند برخی از آنها را برای گنجاندن در بلوک بعدی انتخاب کنند. اطلاعات دقیق درباره این وظایف [اینجا](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) موجود است. کلاینت هایی که از این پروتکل های فرعی پشتیبانی می کنند، آنها را از طریق [JSON-RPC](/developers/docs/apis/json-rpc/) در معرض دید قرار می دهند.
+
+#### les (پروتکل فرعی سبک اتریوم) {#les}
+
+این یک پروتکل حداقلی برای همگام سازی کلاینت های سبک است. به طور سنتی این پروتکل به ندرت مورد استفاده قرار میگرفت زیرا گرههای کامل برای ارائه دادهها به کلاینت های سبک بدون ایجاد انگیزه مورد نیاز هستند. رفتار پیشفرض کلاینتهای اجرا این است که دادههای کلاینت سبک را روی les ارائه نمیکنند. اطلاعات بیشتر در les [جزئیات فنی](https://github.com/ethereum/devp2p/blob/master/caps/les.md) موجود است.
+
+#### Snap {#snap}
+
+[پروتکل snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) یک برنامه افزودنی اختیاری است که به همتایان اجازه میدهد تا تصاویر لحظه ای از وضعیتهای اخیر را مبادله کنند، و به همتایان اجازه میدهد تا دادههای حساب و ذخیرهسازی را بدون نیاز به دانلود گرههای میانی درخل مرکل تأیید کنند.
+
+#### Wit (پروتکل شاهد) {#wit}
+
+[پروتکل شاهد](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) یک برنامه افزودنی اختیاری است که تبادل شاهدان حالت را بین همتایان امکانپذیر میکند و به همگامسازی کلاینت ها با نوک زنجیره کمک میکند.
+
+#### Whisper {#whisper}
+
+Whisper پروتکلی بود که هدف آن ارسال پیام ایمن بین همتایان بدون نوشتن هیچ گونه اطلاعاتی در بلاکچین بود. بخشی از پروتکل سیم DevP2P بود اما اکنون منسوخ شده است. دیگر [پروژه های مرتبط](https://wakunetwork.com/) با اهداف مشابه وجود دارند.
+
+## لایه اجماع {#consensus-layer}
+
+کلاینت های اجماع در یک شبکه همتا به همتا جداگانه با مشخصات متفاوت شرکت می کنند. کلاینت های اجماع باید در شیوع بلوک شرکت کنند تا بتوانند بلوکهای جدید را از همتایان دریافت کنند و زمانی که نوبت به پیشنهاد بلوک رسید، آنها را پخش کنند. مشابه لایه اجرا، ابتدا به یک پروتکل اکتشاف نیاز است تا یک گره بتواند همتایان را پیدا کند و نشست های امنی را برای تبادل بلوک ها، گواهی ها و غیره ایجاد کند.
+
+### اکتشاف {#consensus-discovery}
+
+مشابه کلاینت های اجرا، کلاینت های اجماع از [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) روی UDP برای یافتن همتایان استفاده می کنند. پیادهسازی لایه اجماع discv5 با اجرای کلاینتهای اجرا تنها از این جهت متفاوت است که شامل مبدّلی است که discv5 را به پشته [libP2P](https://libp2p.io/) متصل میکند و DevP2P را منسوخ میکند. جلسههای RLPx لایه اجرا به نفع ارتباطگیری کانال ضد-نویز libP2P منسوخ شده است.
+
+### ENRها {#consensus-enr}
+
+ENR برای گره های اجماع شامل کلید عمومی گره، آدرس IP، پورت های UDP و TCP و دو فیلد خاص اجماع است: فیلد بیتی زیرشبکه گواهی و کلید `eth2`. مورد اول یافتن همتایان شرکت کننده در زیرشبکه های شایعات گویای گواهی را برای گره ها آسان تر می کند. کلید `eth2` نیز حاوی اطلاعاتی در مورد اینکه گره از کدام نسخه فورک اتریوم استفاده می کند، اطمینان حاصل می کند که همتایان به اتریوم مناسب متصل هستند.
+
+### libP2P {#libp2p}
+
+پشته libP2P از تمام ارتباطات پس از اکتشاف پشتیبانی می کند. کلاینت ها می توانند شماره گیری کرده و به IPv4 و/یا IPv6 همانطور که در ENR آنها تعریف شده است گوش دهند. پروتکل های لایه libP2P را می توان به دو حوزه شایعات و درخواست/پاسخ تقسیم کرد.
+
+### شایعات {#gossip}
+
+دامنه شایعات شامل تمام اطلاعاتی است که باید به سرعت در سراسر شبکه پخش شود. این شامل بلوک های بیکن، اثبات ها، امضاها، خروج و جریمه شدن است. این با استفاده از libP2P gossipsub v1 منتقل میشود و متکی به ابردادههای مختلفی است که به صورت محلی در هر گره ذخیره میشوند، از جمله حداکثر اندازه محمولههای شایعات برای دریافت و ارسال. اطلاعات دقیق در مورد دامنه شایعات [اینجا](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub) موجود است.
+
+### درخواست-پاسخ {#request-response}
+
+دامنه درخواست-پاسخ شامل پروتکل هایی برای کلاینت هایی است که اطلاعات خاصی را از همتایان خود درخواست می کنند. به عنوان مثال میتوان به درخواست بلوکهای بیکن خاص با هشهای ریشه خاص یا در محدودهای از اسلاتها اشاره کرد. پاسخ ها همیشه به صورت بایت های رمزگذاری شده SSZ فشرده شده برگردانده می شوند.
+
+## چرا کلاینت اجماع SSZ را به RLP ترجیح می دهد؟ {#ssz-vs-rlp}
+
+SSZ مخفف سریال سازی ساده است. از افست های ثابتی استفاده می کند که رمزگشایی بخش های جداگانه یک پیام رمزگذاری شده را بدون نیاز به رمزگشایی کل ساختار آسان می کند، که برای کلاینت اجماع بسیار مفید است زیرا می تواند به طور موثر بخش های خاصی از اطلاعات را از پیام های رمزگذاری شده بگیرد. همچنین به طور خاص برای ادغام با پروتکلهای مرکل، با افزایش کارایی مرتبط برای Merkleization طراحی شده است. از آنجایی که همه هش ها در لایه اجماع ریشه های مرکل هستند، این باعث بهبود قابل توجهی می شود. SSZ همچنین نمایش منحصر به فرد اعداد را تضمین می کند.
+
+## اتصال کلاینت های اجرا و اجماع {#connecting-clients}
+
+کلاینت های اجماع و اجرا به صورت موازی اجرا می شوند. آنها باید به هم متصل شوند تا کلاینت اجماع بتواند دستورالعمل هایی را برای کلاینت اجرا ارائه دهد و کلاینت اجرا بتواند بسته هایی از تراکنش ها را به کلاینت اجماع ارسال کند تا در بلوک های بیکن گنجانده شوند. ارتباط بین دو کلاینت را می توان با استفاده از یک اتصال RPC محلی به دست آورد. یک API معروف به ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) دستورالعمل های ارسال شده بین دو کلاینت را تعریف می کند. از آنجایی که هر دو کلاینت پشت یک هویت شبکه قرار دارند، یک ENR (رکورد گره اتریوم) به اشتراک می گذارند که حاوی یک کلید جداگانه برای هر کلاینت (کلید eth1 و کلید eth2) است.
+
+خلاصه ای از جریان کنترل در زیر نشان داده شده است، همراه با پشته شبکه مربوطه در پرانتز.
+
+### وقتی کلاینت اجماع یک تولیدکننده بلوک نیست: {#when-consensus-client-is-not-block-producer}
+
+- کلاینت اجماع یک بلوک را از طریق پروتکل شایعات بلوک دریافت می کند (p2p اجماع)
+- کلاینت اجماع بلوک را از قبل تأیید می کند، یعنی اطمینان حاصل می کند که از یک فرستنده معتبر با متادیتا صحیح رسیده است
+- تراکنش های موجود در بلوک به عنوان یک پیلود اجرا (اتصال RPC محلی) به لایه اجرا ارسال می شوند
+- لایه اجرا تراکنش ها را اجرا می کند و وضعیت موجود در هدر بلوک را تأیید می کند (یعنی تطابق هش ها را بررسی می کند)
+- لایه اجرا داده های اعتبارسنج را به لایه اجماع برمی گرداند، بلوک هم الان به عنوان تایید شده در نظر گرفته می شود (اتصال RPC محلی)
+- لایه اجماع، بلوک را به سر بلاکچین خود اضافه می کند و آن را تأیید می کند، تأیید را از طریق شبکه پخش می کند (p2p اجماع)
+
+### وقتی کلاینت اجماع یک تولید کننده بلوک است: {#when-consensus-client-is-block-producer}
+
+- کلاینت اجماع اطلاعیه دریافت می کند که تولید کننده بلوک بعدی است (p2p اجماع)
+- لایه اجماع روش `ایجاد بلوک` را در کلاینت اجرا فرا می خواند (RPC محلی)
+- لایه اجرا به مخزن تراکنش که توسط پروتکل شایعات تراکنش پر شده است دسترسی دارد (p2p اجرا)
+- کلاینت اجرا تراکنش ها را در یک بلوک بسته بندی می کند، تراکنش ها را اجرا می کند و یک هش بلوک ایجاد می کند
+- کلاینت اجماع تراکنش ها و هش بلوک را از کلاینت اجرا می گیرد و به بلوک بیکن اضافه می کند (RPC محلی)
+- کلاینت اجماع بلوک را از طریق پروتکل شایعات بلوک پخش می کند (p2p اجماع)
+- سایر کلاینت ها بلوک پیشنهادی را از طریق پروتکل شایعات بلوک دریافت می کنند و همانطور که در بالا توضیح داده شد اعتبارسنجی می کنند (p2p اجماع)
+
+هنگامی که بلوک توسط اعتبارسنج های کافی تأیید شد، به سر زنجیره اضافه می شود، تنظیم می شود و در نهایت نهایی می شود.
+
+![](cons_client_net_layer.png) ![](exe_client_net_layer.png)
+
+شماتیک لایه شبکه برای مشتریان اجماع و اجرا، از [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
+
+## اطلاعات بیشتر {#further-reading}
+
+[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [مشخصات شبکه لایه اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia به discv5](https://vac.dev/kademlia-to-discv5) [مقاله kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [معرفی p2p اتریوم ](https://p2p.paris/en/talks/intro-ethereum-networking/) [رابطه eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [ویدیوی مرج و جزئیات کلاینت eth2](https://www.youtube.com/watch?v=zNIrIninMgg)
diff --git a/public/content/translations/fa/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/fa/developers/docs/networking-layer/network-addresses/index.md
new file mode 100644
index 00000000000..f1d459e5c81
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/networking-layer/network-addresses/index.md
@@ -0,0 +1,38 @@
+---
+title: آدرسهای شبکه
+description: مقدمه ای بر آدرس های شبکه.
+lang: fa
+sidebarDepth: 2
+---
+
+گره های اتریوم برای اتصال به همتایان باید خود را با برخی از اطلاعات اولیه شناسایی کنند. برای اطمینان از اینکه هر همتای بالقوه می تواند این اطلاعات را تفسیر کند، در یکی از سه فرمت استاندارد شده ای که هر گره اتریوم می تواند درک کند، ارسال می شود: multiaddr، enode، یا Ethereum Node Records (ENR). ENR ها استاندارد فعلی آدرس های شبکه اتریوم هستند.
+
+## موارد مورد نیاز {#prerequisites}
+
+برای درک این صفحه، مقداری آشنایی با [لایه شبکه](/developers/docs/networking-layer/) اتریوم لازم است.
+
+## Multiaddr {#multiaddr}
+
+قالب اصلی آدرس گره اتریوم 'multiaddr' (مخفف 'multi-addresses') بود. Multiaddr یک قالب جهانی است که برای شبکه های همتا به همتا طراحی شده است. آدرس ها به صورت جفت های کلید-مقدار با کلیدها و مقادیری که با یک اسلش رو به جلو از هم جدا شده اند نشان داده می شوند. به عنوان مثال، multiaddr برای یک گره با آدرس IPv4 `192.168.22.27` در حال گوش دادن به پورت TCP `33000` به نظر می رسد:
+
+`/ip4/192.168.22.27/tcp/33000`
+
+برای یک گره اتریوم، multiaddr شامل شناسه گره (هش کلید عمومی آنها) است:
+
+`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br`
+
+## Enode {#enode}
+
+یک Enode راهی برای شناسایی گره اتریوم با استفاده از فرمت آدرس URL است. شناسه گره هگزادسیمال در قسمت نام کاربری URL که از میزبان جدا شده است با استفاده از علامت @ کدگذاری می شود. نام میزبان فقط می تواند به عنوان یک آدرس IP داده شود. نام های DNS مجاز نیستند. پورت موجود در قسمت hostname پورت گوش دادن TCP است. اگر پورت های TCP و UDP (کشف) متفاوت باشند، پورت UDP به عنوان پارامتر پرس و جو "discport" مشخص می شود
+
+در مثال زیر، گره URL گرهای را با آدرس IP `10.3.58.6`، پورت TCP `30303` و پورت کشف UDP `30301` توصیف میکند.
+
+`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301`
+
+## سوابق گره اتریوم (ENR) {#enr}
+
+Ethereum Node Records (ENRs) یک فرمت استاندارد شده برای آدرس های شبکه در اتریوم است. آنها جایگزین multiaddr و enodes می شوند. اینها به ویژه مفید هستند زیرا اجازه تبادل اطلاعات بیشتر بین گره ها را می دهند. ENR شامل یک امضا، شماره دنباله و فیلدهایی است که طرح هویت مورد استفاده برای تولید و اعتبارسنجی امضاها را شرح می دهد. ENR همچنین می تواند با داده های دلخواه سازماندهی شده به عنوان جفتهای مقدار کلید پر شود. این جفتهای مقدار کلید حاوی آدرس IP گره و اطلاعات مربوط به پروتکلهای فرعی هستند که گره قادر به استفاده از آن است. کلاینتهای اجماع از یک [ساختار خاص ENR](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) برای شناسایی نودهای راهاندازی استفاده میکنند و همچنین یک فیلد `eth2` حاوی اطلاعات مربوط به فورک فعلی اتریوم و زیرشبکه شایعه تصدیق را در بر میگیرد (این، گره را به یک مجموعه خاصی از همتایان که گواهینامه های آنها با هم جمع شده است، وصل میکند).
+
+## اطلاعات بیشتر {#further-reading}
+
+[EIP-778: سوابق گره اتریوم (ENR)](https://eips.ethereum.org/EIPS/eip-778) [آدرسهای شبکه در اتریوم](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
diff --git a/public/content/translations/fa/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/fa/developers/docs/networking-layer/portal-network/index.md
new file mode 100644
index 00000000000..aad0835e42a
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/networking-layer/portal-network/index.md
@@ -0,0 +1,83 @@
+---
+title: شبکه پرتال
+description: مروری بر شبکه پورتال - یک شبکه در حال توسعه که برای پشتیبانی از مشتریان با منابع کم طراحی شده است.
+lang: fa
+---
+
+اتریوم شبکه ای متشکل از رایانه هایی است که نرم افزار کاربر اتریوم را اجرا می کنند. هر یک از این کامپیوترها "گره" نامیده می شوند. نرم افزار کاربر به یک گره اجازه می دهد تا داده ها را در شبکه اتریوم ارسال و دریافت کند و داده ها را بر اساس قوانین پروتکل اتریوم تأیید می کند. گره ها داده های تاریخی زیادی را در فضای ذخیره سازی دیسک خود نگه می دارند و زمانی که بسته های جدیدی از اطلاعات را که به نام بلوک ها شناخته می شوند از سایر گره های شبکه دریافت می کنند، به آن اضافه می کنند. این برای بررسی اینکه یک گره همیشه اطلاعاتی مطابق با بقیه شبکه دارد ضروری است. این بدان معناست که اجرای یک گره می تواند به فضای دیسک زیادی نیاز داشته باشد. برخی از عملیات گره ها می توانند به مقدار زیادی RAM نیز نیاز داشته باشند.
+
+برای دور زدن این مشکل ذخیره سازی دیسک، گره های "سبک" توسعه یافته اند که به جای ذخیره کردن همه آنها، اطلاعات را از گره های کامل درخواست می کنند. با این حال، این بدان معنی است که گره سبک به طور مستقل اطلاعات را تأیید نمی کند و در عوض به گره دیگری اعتماد دارد. همچنین به این معنی است که گره های کامل باید کار اضافی را برای خدمت به آن گره های سبک انجام دهند.
+
+شبکه پورتال یک طراحی شبکه جدید برای اتریوم است که هدف آن حل مشکل در دسترس بودن داده برای گره های "سبک" بدون نیاز به اعتماد یا اعمال فشار اضافی بر گره های کامل، با اشتراک گذاری داده های لازم در قطعات کوچک در سراسر شبکه است.
+
+جزئیات بیشتر [گره ها و کاربرها](/developers/docs/nodes-and-clients/)
+
+## چرا به شبکه پورتال نیاز داریم {#why-do-we-need-portal-network}
+
+گره های اتریوم کپی کامل یا جزئی خود از بلاک چین اتریوم را ذخیره می کنند. این کپی محلی، برای اعتبارسنجی تراکنش ها و اطمینان از اینکه گره از زنجیره صحیح پیروی می کند استفاده می شود. این دادههای ذخیرهشده محلی، به گرهها اجازه میدهند تا بدون نیاز به اعتماد به هیچ نهاد دیگری، بهطور مستقل تأیید کنند که دادههای ورودی معتبر و صحیح هستند.
+
+این کپی محلی از بلاک چین و داده های مربوط به وضعیت و دریافت، فضای زیادی را در هارد دیسک گره اشغال می کند. به عنوان مثال، یک هارد دیسک 2 ترابایتی برای اجرای یک گره با استفاده از [Geth](https://geth.ethereum.org) جفت شده با یک کلاینت اجماع توصیه می شود. با استفاده از Snap Sync، که فقط داده های زنجیره ای از مجموعه نسبتاً جدید بلوک ها را ذخیره می کند، Geth معمولاً حدود 650 گیگابایت فضای دیسک را اشغال می کند اما در حدود 14 گیگابایت در هفته رشد می کند (شما می توانید گره را به صورت دوره ای به 650 گیگابایت کاهش دهید).
+
+این بدان معناست که اجرای گرهها میتواند گران باشد، زیرا مقدار زیادی از فضای دیسک باید به اتریوم اختصاص داده شود. چندین راه حل برای این مشکل در نقشه راه اتریوم وجود دارد، از جمله [انقضای تاریخچه](/roadmap/statelessness/#history-expiry)، [انقضای وضعیت](/roadmap/statelessness/#state-expiry) و [بی حالت بودن](/roadmap/statelessness/). با این حال، احتمالاً چندین سال تا اجرایی شدن فاصله دارد. همچنین [گره های سبک](/developers/docs/nodes-and-clients/light-clients/) وجود دارند که کپی خود را از داده های زنجیره ای ذخیره نمی کنند، آنها داده های مورد نیاز خود را از گره های کامل درخواست می کنند. با این حال، این بدان معناست که گرههای سبک باید به گرههای کامل اعتماد کنند تا دادههای صادقانه ارائه کنند و همچنین بر گرههای کاملی که باید دادههای مورد نیاز گرههای سبک را ارائه دهند، استرس وارد میکند.
+
+هدف شبکه پورتال ارائه روشی جایگزین برای گره های سبک برای دریافت داده های خود است که نیازی به اعتماد یا اضافه کردن قابل توجه به کاری که باید توسط گره های کامل انجام شود ندارد. روشی که این کار انجام خواهد شد، معرفی روشی جدید برای گرههای اتریوم برای به اشتراک گذاری داده ها در سراسر شبکه است.
+
+## شبکه پورتال چگونه کار می کند؟ {#how-does-portal-network-work}
+
+گره های اتریوم پروتکل های سختگیرانه ای دارند که نحوه ارتباط آنها با یکدیگر را مشخص می کند. کاربرهای اجرا با استفاده از مجموعهای از پروتکلهای فرعی به نام [DevP2P](/developers/docs/networking-layer/#devp2p) ارتباط برقرار میکنند، در حالی که کاربرهای اجماع از پشته متفاوتی از پروتکلهای فرعی به نام [libP2P](/developers/docs/networking-layer/#libp2p) استفاده میکنند. اینها انواع داده هایی را که می توانند بین گره ها ارسال شوند، تعریف می کنند.
+
+![devP2P و libP2P](portal-network-devp2p-libp2p.png)
+
+گرهها همچنین میتوانند دادههای خاصی را از طریق [JSON-RPC API](/developers/docs/apis/json-rpc/) ارائه دهند، به این ترتیب برنامهها و کیف پولها اطلاعات را با گرههای اتریوم مبادله میکنند. با این حال، هیچ یک از اینها پروتکل های ایده آلی برای ارائه داده به کاربرهای سبک نیستند.
+
+کاربرهای سبک در حال حاضر نمی توانند قطعات خاصی از داده های زنجیره ای را از طریق DevP2P یا libP2p درخواست کنند زیرا این پروتکل ها فقط برای فعال کردن همگام سازی زنجیره ای و شایعه پراکنی بلوک ها و تراکنش ها طراحی شده اند. کاربرهای سبک نمیخواهند این اطلاعات را دانلود کنند زیرا این کار باعث میشود که آنها "سبک" بودن را متوقف کنند.
+
+JSON-RPC API یک انتخاب ایدهآل برای درخواست دادههای کاربر سبک نیست، زیرا بر اتصال به یک گره کامل خاص یا ارائهدهنده RPC متمرکز است که میتواند به دادهها سرویس دهد. این بدان معناست که کاربر سبک باید به صداقت آن گره/ارائهدهنده خاص اعتماد کند، و همچنین گره کامل ممکن است مجبور باشد بسیاری از درخواستهای بسیاری از مشتریان سبک را رسیدگی کند و به پهنای باند مورد نیاز آنها بیفزاید.
+
+هدف شبکه پورتال این است که در کل طراحی، به طور خاص برای سبکی، خارج از محدودیت های طراحی مشتریان موجود اتریوم، تجدید نظر کند.
+
+ایده اصلی شبکه پورتال این است که با فعال کردن اطلاعات مورد نیاز مشتریان سبک، مانند دادههای تاریخی و هویت سر فعلی زنجیره، بهترین بیتها از پشته شبکه فعلی را دریافت کند که از طریق یک شبکه غیرمتمرکز همتا به همتا به سبک DevP2P با استفاده از [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (شبیه Bittorrent) ارائه خواهند شد.
+
+ایده این است که بخشهای کوچکی از کل دادههای تاریخی اتریوم و برخی مسئولیتهای گره خاص به هر گره اضافه شود. سپس، درخواستها با جستجوی گرههایی که دادههای خاص درخواست شده را ذخیره میکنند، و با بازیابی آنها از آنها ارائه میشوند.
+
+این مدل معمولی گرههای نوری را وارونه میکند که یک گره را پیدا میکنند و از آنها درخواست میکنند تا حجم زیادی از داده را فیلتر و ارائه کنند. در عوض، آنها به سرعت شبکه بزرگی از گرهها را فیلتر میکنند که هر کدام حجم کمی از دادهها را مدیریت میکنند.
+
+هدف این است که به شبکه غیرمتمرکز مشتریان پورتال سبک وزن اجازه دهیم تا:
+
+- سر زنجیره را دنبال کند
+- داده های زنجیره ای اخیر و گذشته را همگام کند
+- اطلاعات وضعیت را بازیابی کند
+- تراکنش ها را پخش کند
+- تراکنش ها را با استفاده از [EVM](/developers/docs/evm/) اجرا کند
+
+مزایای این طراحی شبکه عبارتند از:
+
+- کاهش وابستگی به ارائه دهندگان متمرکز
+- کاهش استفاده از پهنای باند اینترنت
+- همگام سازی حداقل یا صفر
+- قابل دسترسی برای دستگاه های دارای محدودیت منابع (<1 گیگابایت رم، <100 مگابایت فضای دیسک، 1 CPU)
+
+نمودار زیر عملکردهای کاربرهای موجود را نشان میدهد که میتواند توسط شبکه پورتال ارائه شود و کاربران را قادر میسازد تا به این عملکردها در دستگاههای با منابع بسیار کم دسترسی داشته باشند.
+
+![جدول شبکه پورتال](portal-network-table2.png)
+
+## تنوع مشتری به طور پیش فرض {#client-diversity-as-default}
+
+توسعه دهندگان شبکه پورتال همچنین طراحی را برای ساختن سه مشتری مجزای شبکه پورتال از روز اول انتخاب کردند.
+
+کاربران شبکه پورتال عبارتند از:
+
+- [Trin](https://github.com/ethereum/trin): نوشته شده در Rust
+- [Fluffy](https://nimbus.team/docs/fluffy.html): نوشته شده به زبان Nim
+- [فوق سبک](https://github.com/ethereumjs/ultralight): نوشته شده در تایپ اسکریپت
+- [Shisui](https://github.com/GrapeBaBa/shisui): نوشته شده در Go
+
+داشتن چندین پیادهسازی کاربر مستقل، انعطافپذیری و عدم تمرکز شبکه اتریوم را افزایش میدهد.
+
+اگر یک کاربر مشکلات یا آسیب پذیری هایی را تجربه کند، سایر کاربرها می توانند به آرامی به کار خود ادامه دهند و از یک نقطه شکست جلوگیری کنند. علاوه بر این، پیادهسازیهای متنوع مشتری، نوآوری و رقابت را تقویت میکند، باعث پیشرفتها و کاهش خطرات تککِشتی در اکوسیستم میشود.
+
+## بیشتر بخوانید {#futher-reading}
+
+- [شبکه پورتال (Piper Merriam در Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA).
+- [دیسکورد شبکه پورتال](https://discord.gg/CFFnmE7Hbs)
+- [وب سایت شبکه پورتال](https://www.ethportal.net/)
diff --git a/public/content/translations/fa/developers/docs/networks/index.md b/public/content/translations/fa/developers/docs/networks/index.md
index 6d1c0df1bf9..c02d9aee46d 100644
--- a/public/content/translations/fa/developers/docs/networks/index.md
+++ b/public/content/translations/fa/developers/docs/networks/index.md
@@ -50,6 +50,7 @@ lang: fa
- [گیت هاب](https://github.com/eth-clients/sepolia)
- [Otterscan](https://sepolia.otterscan.io/)
- [Etherscan](https://sepolia.etherscan.io)
+- [Blockscout](https://eth-sepolia.blockscout.com/)
##### فاست ها
@@ -60,6 +61,7 @@ lang: fa
- [فاست Alchemy Sepolia](https://sepoliafaucet.com/)
- [فاست Infura Sepolia](https://www.infura.io/faucet)
- [فاست Chainstack Sepolia](https://faucet.chainstack.com/sepolia-faucet)
+- [فاست اتریوم اکوسیستم](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia)
#### Goerli_(پشتیبانی طولانی مدت)_ {#goerli}
@@ -76,6 +78,7 @@ Goerli یک شبکه تست برای آزمایش اعتبارسنجی و س
- [وبسایت](https://goerli.net/)
- [گیتهاب](https://github.com/eth-clients/goerli)
- [Etherscan](https://goerli.etherscan.io)
+- [Blockscout](https://eth-goerli.blockscout.com/)
##### فاست ها
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md
new file mode 100644
index 00000000000..a26391d9d4c
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md
@@ -0,0 +1,89 @@
+---
+title: نود آرشیو در اتریوم
+description: مروری بر نود آرشیو در اتریوم
+lang: fa
+sidebarDepth: 2
+---
+
+یک گره آرشیو نمونهای از کاربر اتریوم است که برای آرشیو تمامی وضعیتهای تاریخی شبکه پیکربندی شده است. این گره ابزاری مفید برای استفاده در موارد خاص بوده ولی ممکن است اجرای آن نسبت به گره کامل دشوارتر باشد.
+
+## پیشنیازها {#prerequisites}
+
+شما باید قبل از استفاده از نود آرشیوگر درک درستی از مواردی مانند [مفهوم نود در اتریوم](/developers/docs/nodes-and-clients/) ،[معماری آن](/developers/docs/nodes-and-clients/node-architecture/), [استراتژیهای همگامسازی](/developers/docs/nodes-and-clients/#sync-modes), تمرینهای مرتبط با [راهاندازی](/developers/docs/nodes-and-clients/run-a-node/) و [استفاده از این نوع نودها](/developers/docs/apis/json-rpc/).
+
+## گره آرشیوگر چیست؟
+
+برای درکی درست از اهمیت یک گره آرشیو، بیایید مفهوم «حالت» را برایتان روشن کنیم. اتریوم را میتوان به عنوان _ماشین حالتی که مبتنی بر تراکنش است_ نامگذاری نمود. این ماشین شامل حسابها و برنامههایی است که با اجرای تراکنشها وضعیت خود را تغییر میدهند. دادههای جهانی به همراه اطلاعات هر حساب و قرارداد، در یک پایگاه دادۀ درختی به نام وضعیت ذخیرهسازی میشوند. این عمل توسط کاربر در لایۀ اجرا (EL) انجام میگیرد که شامل موارد زیر است:
+
+- موجودیها و نانسهای حساب
+- کد قرارداد و ذخیرهسازی
+- دادههای مربوط به اجماع مانند قرارداد سهام گذاری
+
+برای تعامل با شبکه، تایید و تولید بلاک جدید، کاربرهای اتریوم باید با آخرین تغییرات (انتهای زنجیرۀ شبکه) و وضعیت فعلی آن همگام باشند. کاربر لایۀ اجرا که به عنوان یک نود کامل پیکربندی شده است آخرین وضعیت شبکه را تایید و از آن پیروی میکند اما فقط چند حالت گذشته را میتواند در خود ذخیره کند، به عنوان مثال، تنها قابلیت ذخیرهسازی وضعیت مرتبط با 128 بلوک آخر در شبکه را دارد، بنابراین این کاربر میتواند سازماندهی مجدد زنجیره را مدیریت کرده و دسترسی سریع به دادههای اخیر را فراهم نماید. وضعیت اخیر حالتی است که تمامی کاربرها برای تایید تراکنشهای دریافتی و استفاده از شبکه به آن نیاز دارند.
+
+شما میتوانید وضعیت را به عنوان اسنپشات شبکه در یک بلوک مشخص و آرشیو را به عنوان بازپخش تاریخی آن تصور کنید.
+
+وضعیتهای تاریخی را میتوان با خیال راحت از بین برد، چون این وضعیتها برای عملکرد شبکه ضروری نیستند و نگهداری از تمامی دادههای قدیمی برای کاربر بیهوده است. وضعیتهایی که قبل از چند بلوک اخیر وجود داشتهاند (مانند 128 بلوک از آخر) دور ریخته میشوند. گرههای کامل تنها دادههای تاریخی بلاکچین را نگهداری میکنند (بلوکها و تراکنشها) و اسنپشاتهای تاریخی میتوانند گهگاه در صورت درخواست برای بازسازی دوبارۀ وضعیتهای قدیمیتر استفاده شوند. آنها این کار را با اجرای مجدد تراکنشهای گذشته در EVM انجام میدهند، که زمانی که وضعیت موردنظر از نزدیکترین اسنپشات فاصله دارد، ممکن است سخت باشد.
+
+با این حال، این بدین معنی است که دسترسی به یک وضعیت تاریخی در یک گره کامل، محاسباتی زیادی لازم دارد. کاربر ممکن است نیاز به اجرای تمام تراکنشهای گذشته و محاسبۀ یک وضعیت تاریخی از پیدایش داشته باشد. گرههای آرشیو این مشکل را با ذخیرهسازیِ نه فقط وضعیتهای اخیر بلکه تمام وضعیتهای تاریخی ایجاد شده بعد از هر بلوک حل میکنند. این کار اساساً نوعی مبادلۀ دو طرفه با فضای بیشتر دیسک را ایجاد میکند.
+
+توجه به این نکته بسیار مهم است که شبکه به گرههای آرشیو برای نگهداری و ارائه تمام دادههای تاریخی وابسته نیست. همانطور که در بالا اشاره شد، تمام وضعیتهای موقت تاریخی میتوانند از طریق گرههای کامل به دست آیند. تراکنشها توسط هر گره کامل ذخیره میشوند (در حال حاضر کمتر از 400G) و میتوان برای ساخت کل آرشیو، مجدداً آنها را در شبکه پخش کرد.
+
+### موارد استفاده
+
+استفادۀ منظم از شبکۀ اتریوم مانند ارسال تراکنشها، استقرار قراردادها، تایید اجماعها و غیره نیازی به دسترسی داشتن به وضعیتهای تاریخی ندارد. به طور کلی کاربران هرگز برای تعامل استاندارد با شبکه نیازی به گره آرشیو ندارند.
+
+مزیت اصلی آرشیوِ وضعیت، دسترسی سریع به درخواستهای مرتبط با وضعیتهای تاریخی است. برای مثال، گره آرشیو با سرعت زیادی به نتایجی مانند موارد زیر میرسد:
+
+- _موجودی حساب اتریومی 0x1337… در بلوک 15537393 چقدر بود؟_
+- _موجودی توکن 0x در بلوک 1920000 چقدر است؟_
+
+همانطور که در بالا توضیح داده شد، یک گره کامل باید این دادهها را با اجرای EVM که از CPU استفاده میکند و بسیار زمانبر است، تولید کند. گرههای آرشیو به تمام این دادهها بر روی دیسک دسترسی دارند و بلافاصله پاسخها را نسبت به این قبیل مسائل ارائه میدهند. این ویژگی برای بخشهای خاصی از زیرساخت شبکه مفید است، برای مثال:
+
+- ارائهدهندگان سرویسهایی مثل جستجوگرهای بلوک
+- پژوهشگران
+- تحلیلگران امنیتی
+- توسعهدهندگان برنامههای غیرمتمرکز یا Dappها
+- حسابرسی و انطباق
+سرویسهای رایگان مختلف وجود دارند که امکان دسترسی به دادههای تاریخی را فراهم میکنند. از آنجا که اجرای یک گره آرشیو پرزحمت تر است، دسترسی به آن از طریق سرویسهای مختلف عمدتاً محدود بوده و ممکن است این سرویسها تنها بعضی اوقات کار کنند. اگر پروژۀ شما نیاز به دسترسی پیوسته به دادههای تاریخی دارد، بهتر است خودتان یک گره آرشیو بر روی سیستمتان اجرا کنید.
+
+
+
+## اجراها و کاربرد
+
+گره آرشیو به معنای دادههای ارائه شده از سوی کاربرهایی است که با کاربرهای لایه اجرا روبه رو هستند زمانی که آنها پایگاه دادۀ وضعیت را مدیریت کرده و نقاط پایانی JSON-RPC را فراهم میکنند. گزینههای پیکربندی، زمان همگامسازی و سایز دادهها ممکن است بسته به کاربر متفاوت باشد. برای جزئیات بیشتر، لطفا به اسناد ارائه شده توسط کاربرتان رجوع کنید.
+
+قبل از شروع راهاندازی گره آرشیوتان، در رابطه با تفاوتهای بین کاربرها و علی الخصوص [نیازمندیهای سختافزاریشان](/developers/docs/nodes-and-clients/run-a-node/#requirements) مطالعه کنید. شایان ذکر است که اکثر کاربرها بهینهسازی نشدهاند و آرشیوشان نیاز به فضای بیش از 12 ترابایت دارد. در مقابل، پیادهسازیهایی مانند Erigon میتوانند همان داده را در کمتر از 3 ترابایت ذخیره کنند که موثرترین راه برای اجرای یک گره آرشیو محسوب میشود.
+
+
+
+## اقدامات توصیه شده
+
+جدا از [توصیههای کلی برای اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/)، یک گره آرشیو ممکن است از نظر سختافزار و نگهداری الزامات بیشتری داشته باشد. با توجه به [ویژگیهای کلیدی](https://github.com/ledgerwatch/erigon#key-features) عملیترین رویکرد در این زمینه همان استفاده از پیادهسازی کاربر [Erigon](/developers/docs/nodes-and-clients/#erigon) است.
+
+
+
+### سختافزار
+
+همیشه مطمئن شوید که الزامات سخت افزاری برای یک حالت معین در اسناد کاربر را تایید میکنید. بزرگترین نیاز برای گرههای آرشیو فضای دیسک است. این فضا بسته به کاربر، میتواند از 3 ترابایت تا 12 ترابایت متفاوت باشد. حتی اگر HDD راهحل بهتری برای حجم زیادی از داده به نظر رسد، برای همگامسازی و به روزرسانی پیوستهاش با زنجیرۀ شبکه، به درایوهای SSD نیاز خواهد داشت. درایوهای [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) به اندازۀ کافی خوب هستند ولی باید کیفیت قابل اعتماد حداقل در حد [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences) داشته باشند. دیسکها را میتوان بر روی کامپیوتر یا یک سرور با اسلات کافی نصب کرد. چنین دستگاههایی برای اجرای گره با زمان کاریِ بالا ایده آل و مناسب هستند. اجرای آن بر روی لپ تاپ نیز امکانپذیر است ولی قابل حمل بودنش هزینۀ اضافی به همراه خواهد داشت.
+
+تمامی دادهها باید در یک حجم قرار گیرند بنابراین دیسکها باید به عنوان مثال توسط [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) یا [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html) به هم متصل شوند. همچنین ممکن است استفاده از سیستم فایل [ZFS](https://en.wikipedia.org/wiki/ZFS) از آنجا که از ویژگی Copy-on-write پشتیبانی میکند، ارزشمند باشد، در واقع این ویژگی اطمینان حاصل میکند که دادهها به درستی بر روی دیسک و بدون هیچ گونه خطای سطح پایین نوشته شده باشند.
+
+برای ثبات و امنیت بیشتر به منظور جلوگیری از خرابی تصادفی در پایگاه داده، به خصوص در تنظیمات حرفهای، از [ECC memory](https://en.wikipedia.org/wiki/ECC_memory) در صورتی که توسط سیستمتان پشتیبانی میشود، استفاده کنید. به طور کلی توصیه میشود سایز RAM هم اندازۀ گره کامل باشد ولی در کل RAM بیشتر میتواند به سرعت همگامسازی کمک کند.
+
+در طول همگامسازی اولیه، کاربرها در حالت آرشیو هر تراکنشی را از زمان پیدایش اجرا میکنند. سرعت اجرا بیشتر توسط CPU محدود میشود، بنابراین CPU سریعتر میتواند به زمان همگامسازی اولیه کمک کند. در یک کامپیوتر معمولی، زمان همگامسازی اولیه میتواند تا یک ماه طول بکشد.
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [گره کامل اتریوم در مقایسه با گره آرشیو](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode، سپتامبر 2022_
+- [گره آرشیو اتریوم خودتان را بسازید](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _تامس جی راش، اوت 2021_
+- [چگونه Erigon را نصب کنیم، RPC اِریگون و TrueBlocks (اسکریپ و API) به عنوان خدمات](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– ماگنون هانسن، بهروز رسانی سپتامبر 2022_
+
+
+
+## موضوعات مرتبط {#related-topics}
+
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
+- [راهاندازی یک گره](/developers/docs/nodes-and-clients/run-a-node/)
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/bootnodes/index.md
new file mode 100644
index 00000000000..34e555578f9
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/bootnodes/index.md
@@ -0,0 +1,31 @@
+---
+title: مقدمه ای بر بوتنودهای اتریوم
+description: اطلاعات اولیه ای که برای درک بوت نودها نیاز دارید
+lang: fa
+---
+
+هنگامی که یک گره جدید به شبکه اتریوم میپیوندد، باید به گرههایی که از قبل در شبکه هستند متصل شود تا همتاهای جدید را کشف کند. به این نقاط ورود به شبکه اتریوم، بوت نود می گویند. کاربرها معمولاً فهرستی از بوت نودها را دارند که در آنها کدگذاری شده است. این بوت نودها معمولاً توسط تیم توسعه دهنده بنیاد اتریوم یا خود تیم های کاربر اجرا می شوند. توجه داشته باشید که بوت نودها با گره های استاتیک یکسان نیستند. گره های استاتیک بارها و بارها فراخوانی می شوند، در حالی که بوت نودها فقط زمانی فراخوانی می شوند که همتاهای کافی برای اتصال به آن ها وجود نداشته باشد و یک گره نیاز به بوت استرپ برخی از اتصالات جدید داشته باشد.
+
+## اتصال به یک بوت نود {#connect-to-a-bootnode}
+
+اکثر کاربرها فهرستی از بوتنودها را در خود دارند، اما ممکن است بخواهید بوتنود خود را نیز اجرا کنید، یا از یکی استفاده کنید که بخشی از لیست کدهای سخت کاربر نیست. در این مورد، می توانید آنها را هنگام راهاندازی کاربر خود به شرح زیر مشخص کنید (به عنوان مثال برای Geth، لطفاً اسناد کاربر خود را بررسی کنید):
+
+```
+geth --bootnodes "enode://@:"
+```
+
+## اجرای یک بوت نود {#run-a-bootnode}
+
+بوت نودها گره های کاملی هستند که پشت NAT نیستند ([ترجمه آدرس شبکه](https://www.geeksforgeeks.org/network-address-translation-nat/)). هر گره کامل تا زمانی که در دسترس عموم باشد می تواند به عنوان یک بوت نود عمل کند.
+
+هنگامی که یک گره را راهاندازی می کنید، باید [enode](/developers/docs/networking-layer/network-addresses/#enode) شما را ثبت کند، که یک شناسه عمومی است که دیگران می توانند از آن برای اتصال به گره شما استفاده کنند.
+
+این enode معمولاً در هر راهاندازی مجدد بازسازی میشود، بنابراین مطمئن شوید که به مستندات کاربر خود در مورد نحوه ایجاد یک enode پایدار برای بوتنود خود نگاه کنید.
+
+برای اینکه بوتنود خوبی باشید، ایده خوبی است که حداکثر تعداد همتاهایی را که میتوانند به آن متصل شوند، افزایش دهید. اجرای یک بوت نود با همتایان زیاد، پهنای باند مورد نیاز را به میزان قابل توجه افزایش می دهد.
+
+## بوت نودهای موجود {#available-bootnodes}
+
+فهرستی از بوت نودهای داخلی در go-ethereum را میتوانید [اینجا](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) پیدا کنید. این بوت نودها توسط بنیاد اتریوم و تیم go-ethereum نگهداری می شوند.
+
+لیست های دیگری از بوت نودها وجود دارد که توسط داوطلبان نگهداری می شوند. لطفاً مطمئن شوید که همیشه حداقل یک بوتنود رسمی گنجانده شده است، در غیر این صورت ممکن است تحت حمله Eclipse قرار بگیرید.
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md
new file mode 100644
index 00000000000..9a2fcf0b6b2
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md
@@ -0,0 +1,109 @@
+---
+title: تنوع کلاینتها
+description: توضیح سطح بالایی از اهمیت تنوع کلاینت در اتریوم.
+lang: fa
+sidebarDepth: 2
+---
+
+رفتار یک گرهی اتریوم توسط نرمافزار کلاینتی که اجرا میکند کنترل میشود. چندین کلاینت اتریوم در سطح تولید وجود دارند که هر کدام به زبانهای مختلف توسط تیمهای جداگانه توسعه یافته و نگهداری میشوند. کلاینتها بر اساس مشخصات مشترکی ساخته شدهاند که تضمین میکند کلاینتها بهطور یکپارچه با یکدیگر ارتباط برقرار میکنند و عملکرد یکسانی دارند و تجربهی کاربری برابری را ارائه میدهند. با این حال، در حال حاضر توزیع کلاینتها در سراسر گرهها به اندازهی کافی برای تحقق این تقویت شبکه با پتانسیل کامل آن برابر نیست. در حالت ایدهآل، کاربران تقریباً بهطور مساوی بین کلاینتهای مختلف تقسیم میکنند تا بیشترین تنوع کلاینت را به شبکه بیاورند.
+
+## پیشنیازها {#prerequisites}
+
+اگر از قبل نمیدانید گرهها و کاربرها چیست، [گرهها و کاربرها](/developers/docs/nodes-and-clients/) را بررسی کنید. لایههای [اجرا](/glossary/#execution-layer) و [اجماع](/glossary/#consensus-layer) در واژهنامه تعریف شدهاند.
+
+## چرا چندین کلاینت وجود دارد؟ {#why-multiple-clients}
+
+کلاینتهای متعددی وجود دارند که بهطور مستقل توسعه یافته و نگهداری میشوند زیرا تنوع کلاینت شبکه را در برابر حملات و اشکالهای نرمافزاری سرسختتر میکند. تعدد کلاینتها یک نقطهی قوت منحصربهفرد برای اتریوم است - سایر زنجیرههای بلوکی بر مصونیت یک کلاینت از خطای تکیه دارند. با این حال، صرفاً در دسترس داشتن چندین کلاینت کافی نیست، آنها باید توسط جامعه پذیرفته شوند و کل گرههای فعال بهطور نسبتاً مساوی در بین آنها توزیع شوند.
+
+## چرا تنوع کلاینت مهم است؟ {#client-diversity-importance}
+
+داشتن کلاینتهای توسعهیافته بهطور مستقل و نگهداریشدهی متعدد برای سلامت یک شبکهی غیرمتمرکز حیاتی است. بیایید دلایل آن را بررسی کنیم.
+
+### اشکالات نرمافزاری {#bugs}
+
+یک اشکال در یک کلاینت منفرد که نمایندهی اقلیتی از گرههای اتریوم باشد، خطر کمتری برای شبکه دارد. با توزیع تقریباً یکنواخت گرهها در بین بسیاری از کلاینتها، احتمال اینکه اکثر کلاینتها از یک مشکل مشترک رنج ببرند اندک است و در نتیجه شبکه قویتر است.
+
+### تابآوری در برابر حملات {#resilience}
+
+تنوع کلاینت همچنین باعث تابآوری در برابر حملات میشود. بهعنوان مثال، حمله ای که [یک کلاینت خاص را به سمت شاخهی خاصی از زنجیره فریب دهد](https://twitter.com/vdWijden/status/1437712249926393858) بعید است موفقیت آمیز باشد زیرا بعید است سایر کلاینتها به همان شیوه فریب بخورند و زنجیرهی متعارف خراب نمیشود. تنوع کم کلاینت، خطر مرتبط با هک در کلاینت غالب را افزایش میدهد. قبلاً ثابت شده است که تنوع کلاینت، دفاع مهمی در برابر حملات مخرب در شبکه است. بهعنوان مثال، حملهی محرومسازی از سرویس شانگهای در سال 2016 به این خاطر امکانپذیر بود که مهاجمان توانستند کلاینت غالب (Geth) را فریب دهند که یک دیسک آهستهی عملیات i/o را دهها هزار بار در هر بلوک اجرا کند. از آنجایی که کلاینتهای جایگزین نیز آنلاین بودند و آسیبپذیری را نداشتند، اتریوم توانست در مقابل حمله مقاومت کند و تا زمانی که آسیبپذیری در Geth رفع شد، به کار خود ادامه دهد.
+
+### قطعیت اثبات سهام {#finality}
+
+یک باگ در یک کاربر توافقی با بیش از 33 درصد از گرههای اتریوم میتواند از نهایی شدن لایه اجماع جلوگیری کند، به این معنی که کاربران نمیتوانند اعتماد کنند که تراکنشها در مقطعی بازگردانده یا تغییر نخواهند کرد. این برای بسیاری از برنامه های ساخته شده در بالای اتریوم، به ویژه DeFi، بسیار مشکل ساز خواهد بود.
+
+ بدتر از آن، یک اشکال حیاتی در کلاینت با اکثریت دو سوم میتواند باعث شود که زنجیره بهاشتباه تقسیم و نهایی شود، که باعث میشود مجموعهی بزرگی از اعتبارسنجها در زنجیرهای نامعتبر گیر کنند. اگر بخواهند دوباره به زنجیرهی درست بپیوندند، این اعتبارسنجها با برخورد شدید یا خروج و فعالسازی مجدد داوطلبانهی آهسته و پرهزینه مواجه میشوند. شدت برخورد شدید متناسب با تعداد گرههای مقصر است و دو سوم اکثریت مورد شدیدترین برخورد قرار میگیرند (32 اتر).
+
+اگرچه این سناریوها بعید هستند، اما اکوسیستم اتریوم میتواند ریسک آنها را با یکنواخت کردن توزیع کلاینتها در سراسر گرههای فعال کاهش دهد. در حالت ایده آل، هیچ کاربر اجماع هرگز به سهم 33% از کل گره ها نخواهد رسید.
+
+### مسئولیت مشترک {#responsibility}
+
+داشتن اکثریت کلاینتها هزینهی انسانی هم دارد. این کار، فشار و مسئولیت بیش از حدی بر دوش یک تیم توسعهی کوچک وارد میکند. هرچه تنوع کلاینت کمتر باشد، بار مسئولیت توسعهدهندگانی که از کلاینت اکثریت نگهداری میکنند، بیشتر میشود. پخش کردن این مسئولیت بین تیمهای متعدد، هم برای سلامت شبکهی گرههای اتریوم و هم برای شبکهی افراد آن مفید است.
+
+## تنوع کلاینت فعلی {#current-client-diversity}
+
+![نمودار دایرهای که تنوع کلاینت را نشان میدهد](./client-diversity.png) _دادههای نمودار از [ethernodes.org](https://ethernodes.org) و [ clientdiversity.org](https://clientdiversity.org/)_
+
+دو نمودار دایرهای بالا تصاویری فوری از تنوع کلاینت فعلی برای لایههای اجرا و اجماع (در زمان نگارش در ژانویه 2022) را نشان میدهند. لایهی اجرا غالباً در سلطهی [Geth](https://geth.ethereum.org/) است، [Open Ethereum با فاصله دوم است، ](https://openethereum.github.io/) [Erigon](https://github.com/ledgerwatch/erigon) سوم است و [Nethermind](https://nethermind.io/) چهارم است، و در عین حال سایر کلاینتها که کمتر از 1% شبکه را تشکیل میدهند. رایجترین کلاینت مورد استفاده در لایهی اجماع - [Prysm](https://prysmaticlabs.com/#projects) - به اندازه Geth غالب نیست، اما در عین حال بیش از 60% از شبکه را نمایندگی میکند. [Lighthouse](https://lighthouse.sigmaprime.io/) و [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) به ترتیب 20% و حدود 14% حضور دارند و سایر کلاینتها بهندرت استفاده میشوند.
+
+داده های لایه اجرا از [Ethernodes](https://ethernodes.org) در 23 ژانویه 2022 به دست آمدند. دادههای کلاینتهای اجماع از [Michael Sproul](https://github.com/sigp/blockprint) گرفته شده است. بهدست آوردن دادههای کاربر اجماع دشوارتر است، زیرا کاربرهای لایه اجماع همیشه دارای ردپاهای واضحی نیستند که بتوان از آنها برای شناسایی استفاده کرد. دادهها با استفاده از یک الگوریتم طبقهبندی تولید شدهاند که گاهی برخی از کلاینتهای اقلیت را گیج میکند (برای جزئیات بیشتر به [اینجا](https://twitter.com/sproulM_/status/1440512518242197516) مراجعه کنید). در نمودار بالا، این طبقهبندیهای مبهم یک برچسب یا این/یا آن (بهعنوان مثال Nimbus/Teku) دارند. با وجود این، واضح است که اکثریتِ شبکه Prysm را اجرا میکند. دادهها، تصویری از مجموعهی ثابتی از بلوکها هستند (در این مورد، بلوکهای بیکن در اسلاتهای 2048001 تا 2164916) و حضور غالب Prysm گاهی اوقات بالاتر و بیش از 68% بوده است. علیرغم صرفاً یک تصویر بودن، مقادیر نمودار درک کلی خوبی از وضعیت فعلی تنوع کلاینت ارائه میدهند.
+
+داده های به روز شده تنوع مشتری، برای لایه اجماع اکنون در [clientdiversity.org](https://clientdiversity.org/) در دسترس است.
+
+## لایهی اجرا {#execution-layer}
+
+تا به حال، گفتگو پیرامون تنوع کلاینت عمدتاً بر لایهی اجماع متمرکز بوده است. با این حال، کلاینت اجرای [Geth](https://geth.ethereum.org) در حال حاضر حدود 85% از کل گرهها را تشکیل میدهد. این درصد به دلایل یکسان برای کلاینتهای اجماع مشکلساز است. برای مثال، یک اشکال نرمافزاری در Geth که روی انجام دادن تراکنش تأثیر میگذارد یا پیلودهای اجرایی درست میکند، میتواند منجر به این شود که کلاینتهای اجماع تراکنشهای مشکلساز یا مشکلدار را نهایی کنند. بنابراین، اتریوم با توزیع یکنواختتری از کلاینتهای اجرایی سالمتر خواهد بود. حالت ایدهآل این است که هیچ کلاینتی بیش از 33% از شبکه را نمایندگی نکند.
+
+## از کلاینت اقلیت استفاده کنید {#use-minority-client}
+
+توجه کردن به تنوع کلاینت به بیش از کاربران منفردی نیاز دارد که کلاینتهای اقلیت را انتخاب کنند - این کار نیازمند استخرهای استخراج/ اعتبارسنج و نهادهایی مانند dappها و صرافیهای اصلی است تا کلاینتها را هم تغییر دهند. با این حال، همهی کاربران میتوانند سهم خود را در اصلاح عدم توازن فعلی و عادیسازی استفاده از تمام نرمافزارهای موجود اتریوم انجام دهند. پس از ادغام، تمام عملگرهای گره ملزم به اجرای یک کلاینت اجرا و یک کلاینت اجماع خواهند بود. انتخاب ترکیبی از کلاینتهای پیشنهادشده در زیر به افزایش تنوع کلاینت کمک میکند.
+
+### کلاینتهای اجرا {#execution-clients}
+
+[Besu](https://www.hyperledger.org/use/besu)
+
+[Nethermind](https://downloads.nethermind.io/)
+
+[Erigon](https://github.com/ledgerwatch/erigon)
+
+[Go-Ethereum](https://geth.ethereum.org/)
+
+### کلاینتهای اجماع {#consensus-clients}
+
+[Nimbus](https://nimbus.team/)
+
+[Lighthouse](https://github.com/sigp/lighthouse)
+
+[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
+
+[Lodestar](https://github.com/ChainSafe/lodestar)
+
+[Prysm](https://docs.prylabs.network/docs/getting-started)
+
+کاربران فنی میتوانند با نوشتن آموزشها و مستندات بیشتر برای کلاینتهای اقلیت و تشویق همتایان گرهگردان خود به مهاجرت کردن دور از کلاینتهای غالب، به تسریع این فرایند کمک کنند. راهنماهای تغییر به کلاینت اجماع اقلیت در [clientdiversity.org](https://clientdiversity.org/) موجود است.
+
+## داشبوردهای تنوع کلاینت {#client-diversity-dashboards}
+
+چند داشبورد آمار تنوع کلاینت را بهصورت لحظهای برای لایهی اجرا و اجماع ارائه میدهند.
+
+**لایهی اجماع:**
+
+- [Rated.network](https://www.rated.network/)
+- [clientdiversity.org](https://clientdiversity.org/) **لایه اجرا:**
+
+- [supermajority.info](https://supermajority.info//)
+- [Ethernodes](https://ethernodes.org/)
+
+## اطلاعات بیشتر {#further-reading}
+
+- [تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
+- [ادغام اتریوم: کلاینت اکثریت را با ریسک خودتان اجرا کنید!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) - _دانکراد فیست، 24 مارس 2022_
+- [اهمیت تنوع کلاینت](https://our.status.im/the-importance-of-client-diversity/)
+- [فهرست خدمات گرهی اتریوم](https://ethereumnodes.com/)
+- [«پنج چرا»ی مشکل تنوع کلاینت](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
+- [تنوع اتریوم و نحوه حل آن (یوتیوب)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
+- [clientdiversity.org](https://clientdiversity.org/)
+
+## موضوعات مرتبط {#related-topics}
+
+- [اجرای یک گرهی اتریوم](/run-a-node/)
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/index.md
index 04ecebd6da6..97ad557b24c 100644
--- a/public/content/translations/fa/developers/docs/nodes-and-clients/index.md
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/index.md
@@ -5,61 +5,94 @@ lang: fa
sidebarDepth: 2
---
-اتریوم یک شبکهی توزیعشده از رایانههایی است که نرمافزار را اجرا میکنند (به نام گرهها) که میتواند بلوکها و دادههای تراکنش را تأیید کنند. برای «اجرای» یک گره، به یک برنامهی کاربردی که به عنوان کلاینت شناخته میشود در رایانه خود نیاز دارید.
+اتریوم یک شبکه توزیعشده از رایانهها (معروف به گرهها) است که نرمافزاری را اجرا میکنند که میتواند بلوکها و دادههای تراکنش را تأیید کند. نرم افزار باید بر روی رایانهی شما اجرا شود تا آن را به یک نود اتریوم تبدیل کند. برای تشکیل یک گره، دو بخش مجزا از نرمافزار (که به عنوان "کلاینت" شناخته می شوند) مورد نیاز است.
## پیشنیازها {#prerequisites}
-پیش از آن که نمونهی کلاینت اتریوم خود را اجرا کنید و در این موضوع عمیق شوید باید [مبانی ماشین مجازی اتریوم](/developers/docs/evm/) و شبکهی همتا به همتا را بدانید و متوجه شوید. به [معرفی اتریوم](/developers/docs/intro-to-ethereum/) ما نگاهی بیاندازید.
+پیش از آن که نمونهی کلاینت اتریوم خود را اجرا کنید و در این موضوع عمیق شوید باید [مبانی ماشین مجازی اتریوم](/developers/docs/evm/) و شبکهی همتا به همتا را بدانید و متوجه شوید. به [معرفی اتریوم](/developers/docs/intro-to-ethereum/) ما نگاهی بیندازید.
-If you're new to the topic of nodes, we recommend first checking out our user-friendly introduction on [running an Ethereum node](/run-a-node).
+اگر با موضوع گرهها تازه کار هستید، توصیه میکنیم ابتدا مقدمه کاربرپسند ما در مورد [اجرای گره اتریوم](/run-a-node) را بررسی کنید.
## کلاینتها و گرهها چه هستند؟ {#what-are-nodes-and-clients}
-«گره» به اجرای یک تکه از نرمافزار کلاینت گفته میشود. کلاینت یک پیادهسازی از اتریوم است که تمام تراکنشهای هر بلوک را تأیید میکند، شبکه را ایمن نگه میدارد و دادهها را دقیق نگه میدارد.
+"گره" هر نمونهای از نرمافزار مشتری اتریوم است که به رایانه های دیگری که نرمافزار اتریوم را نیز اجرا می کنند متصل است و یک شبکه را تشکیل میدهد. یک کلاینت یک نرمافزار پیادهسازی اتریوم است که داده ها را بر اساس قوانین پروتکل تأیید می کند و شبکه را ایمن نگه می دارد. یک گره باید دو کلاینت را اجرا کند: یک کلاینت اجماع و یک کلاینت اجرا.
-شما میتوانید یک نمای در لحظه و زنده را از شبکهی اتریوم را با نگاه به [نقشهی گرهها](https://etherscan.io/nodetracker) ببینید.
+- کلاینت اجرا (همچنین به عنوان مهندس اجرا، کلاینت EL یا قبلاً کلاینت Eth1 شناخته می شود) به تراکنشهای جدید پخش شده در شبکه گوش می دهد، آنها را در EVM اجرا می کند و آخرین وضعیت و پایگاه داده تمام داده های فعلی اتریوم را نگه می دارد.
+- کلاینت اجماع (همچنین به عنوان نود بیکن، کلاینت CL یا قبلاً کلاینت Eth2 شناخته میشود) الگوریتم اجماع اثبات سهام را پیادهسازی میکند، که شبکه را قادر میسازد بر اساس دادههای معتبر از کلاینت اجرا به اجماع برسد. همچنین نرمافزار سومی وجود دارد که به عنوان "اعتبارسنج" شناخته می شود که می تواند به کلاینت اجماع اضافه شود و به یک گره اجازه می دهد تا در ایمنسازی شبکه مشارکت کند.
-[کلاینتهای اتریوم](/developers/docs/nodes-and-clients/#execution-clients) بسیاری در زبانهای برنامهنویسی مختلفی مثل گو، Rust، جاوا اسکریپت، تایپاسکریپت، پایتون، سیشارپ، داتنت، Nim و جاوا وجود دارند. همهی این پیادهسازیها مشخصات رسمی (در اصل [یلو پیپر اتریوم](https://ethereum.github.io/yellowpaper/paper.pdf)) را دنبال میکنند. این مشخصاتْ نحوهی عملکرد شبکهی اتریوم و زنجیرهی بلوکی را تعیین میکند.
+این کلاینتها با هم کار می کنند تا سر زنجیره اتریوم را پیگیری کنند و به کاربران اجازه دهند با شبکه اتریوم تعامل داشته باشند. طراحی مدولار با چندین نرمافزار که با هم کار می کنند [پیچیدگی کپسوله شده](https://vitalik.eth.limo/general/2022/02/28/complexity.html) نامیده می شود. این رویکرد اجرای یکپارچه [مرج](/roadmap/merge) را آسانتر میکند، نگهداری و توسعه نرمافزار کلاینت را آسانتر میکند، و استفاده مجدد از کلاینتهای تنها را، برای مثال، در [اکوسیستم لایه2](/layer-2/) ممکن میسازد.
-![کلاینت اجرا](./client-diagram.png) نمودار ساده شدهی ویژگیهای کلاینت اتریوم.
+![کلاینت اجرا و اجماع کنار هم](./eth1eth2client.png) نمودار سادهشدهی کلاینت اجرا و اجماع کنار هم.
+
+### تنوع کلاینتها {#client-diversity}
+
+هم [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients) و هم [کلاینتهای اجماع](/developers/docs/nodes-and-clients/#consensus-clients) در انواع زبان های برنامه نویسی که توسط تیم های مختلف توسعه یافتهاند وجود دارند.
+
+پیادهسازی های متعدد کلاینت می تواند شبکه را با کاهش وابستگی آن به یک پایگاه کد، قویتر کند. هدف ایده آل دستیابی به تنوع بدون هرگونه تسلط کلاینت بر شبکه است و در نتیجه یک نقطه شکست بالقوه را از بین می برد. تنوع زبان ها همچنین جامعه توسعه دهندگان گسترده تری را دعوت می کند و به آنها اجازه می دهد تا به زبان دلخواه خود ادغام ایجاد کنند.
+
+درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) بیشتر بدانید.
+
+وجه مشترک این پیاده سازی ها این است که همه آنها از یک مشخصات واحد پیروی می کنند. مشخصات نحوه عملکرد شبکه اتریوم و بلاکچین را تعیین می کند. هر جزئیات فنی تعریف شده است و مشخصات را می توان به صورت زیر یافت:
+
+- در اصل، [زردنامه اتریوم](https://ethereum.github.io/yellowpaper/paper.pdf)
+- [مشخصات لایه اجرا](https://github.com/ethereum/execution-specs/)
+- [مشخصات لایه اجماع](https://github.com/ethereum/consensus-specs)
+- [EIPهای](https://eips.ethereum.org/) پیادهسازی شده در گسترهای از [ارتقاهای شبکه](/history/)
+
+### ردیابی نودها در شبکه {#network-overview}
+
+ردیابهای متعدد یک نمای کلی از گرهها در شبکه اتریوم در زمان واقعی ارائه میدهند. توجه داشته باشید که با توجه به ماهیت شبکه های غیرمتمرکز، این خزنده ها تنها می توانند دید محدودی از شبکه ارائه دهند و ممکن است نتایج متفاوتی را گزارش کنند.
+
+- [نقشه نودها](https://etherscan.io/nodetracker) توسط Etherscan
+- [Ethernodes](https://ethernodes.org/) توسط Bitfly
+- [Nodewatch](https://www.nodewatch.io/) توسط Chainsafe، که در نودهای اجماع میخزد
## انواع گره {#node-types}
-اگر میخواهید که [گرهی خودتان را اجرا کنید](/developers/docs/nodes-and-clients/run-a-node/) باید بدانید که گرههای مختلفی وجود دارند که دادههای مختلفی را استفاده میکنند. در واقع کلاینتها میتوانند سه نوع گره را اجرا کنند - سبک، کامل و آرشیو. گزینههای استراتژیهای همگامسازی مختلف هم وجود دارند که زمان همگامسازی را سریعتر میکنند. همگامسازی به این اشاره دارد که با چه سرعتی میتواند بهروزترین اطلاعات را در مورد وضعیت اتریوم دریافت کند.
+اگر میخواهید [گرهی خودتان را اجرا کنید](/developers/docs/nodes-and-clients/run-a-node/)، باید بدانید که گرههای مختلفی وجود دارند که دادههای مختلفی را استفاده میکنند. در واقع، کلاینتها می توانند سه نوع مختلف از گره را اجرا کنند: سبک، کامل و آرشیو. همچنین گزینههایی از استراتژیهای همگامسازی مختلف وجود دارد که زمان همگامسازی سریعتر را امکانپذیر میکند. همگامسازی به این اشاره دارد که با چه سرعتی میتوان بهروزترین اطلاعات را در مورد وضعیت اتریوم دریافت کرد.
+
+### گره کامل {#full-node}
-### گرهی کامل {#full-node}
+گرههای کامل اعتبارسنجی بلوک به بلوک زنجیره بلوک را انجام میدهند، از جمله دانلود و تأیید بدنه بلوک و دادههای حالت برای هر بلوک. کلاسهای مختلفی از گره کامل وجود دارد - برخی از بلوکهای پیدایش شروع میکنند و تک بلوکها را در کل تاریخچه بلاکچین تأیید میکنند. برخی دیگر تأیید خود را در بلوکی جدیدتر که به معتبر بودن آن اعتماد دارند شروع میکنند (مثلاً «همگامسازی فوری» Geth). صرف نظر از جایی که تأیید شروع می شود، گره های کامل فقط یک کپی محلی از داده های نسبتاً اخیر (معمولاً 128 عدد از جدیدترین بلوک ها) را نگه می دارند، که اجازه می دهد تا داده های قدیمی برای صرفهجویی در فضای دیسک حذف شوند. داده های قدیمی را می توان در صورت نیاز دوباره تولید کرد.
-- دادههای زنجیره بلوکی را کامل نگهداری میکند.
+- دادههای زنجیرهی بلوکی کامل را بهطور کامل ذخیره میکند (اگرچه حشو و زواید این دادهها به صورت دورهای حذف میشود، بنابراین یک گرهی کامل تمام دادههای حالت را از زمان پیدایش تاکنون ذخیره نمیکند)
- در اعتبارسنجی بلوکها شرکت میکند و همهی وضعیتها و بلوکها را تأیید میکند.
-- همهی وضعیتها میتوانند از گرهی کامل استخراج شوند.
+- همه حالت ها را می توان یا از حافظه محلی بازیابی کرد یا از «اسنپشاتهایی» توسط یک گره کامل بازسازی کرد.
- در خدمت شبکه است و دادهها را در زمان درخواست ارائه میدهد.
-### گرهی سبک {#light-node}
+### گره آرشیو {#archive-node}
-- زنجیرهی هدر را ذخیره و هر چیز دیگری را درخواست میکند.
-- میتواند اعتبار دادهها را نسبت به ریشههای حالت در هدرهای بلوک تأیید کند.
-- برای دستگاههای کمظرفیت، مانند دستگاههای تعبیهشده یا تلفنهای همراه، که توانایی ذخیرهی چندین گیگابایت دادههای زنجیره بلوکی را ندارند، مفید است.
+گره های آرشیوی گره های کاملی هستند که هر بلوک را از پیدایش تأیید می کنند و هرگز هیچ یک از دادههای دانلود شده را حذف نمی کنند.
-### گرهی آرشیو {#archive-node}
+- هر چیزی که در گره کامل نگهداری میشود را ذخیره میکند و یک آرشیو کامل از حالتهای تاریخی میسازد. اگر میخواهید چیزی مانند موجودی حساب را در بلوک شماره 4،000،000 جستجو کنید، یا به سادگی و با اطمینان مجموعه تراکنشهای خود را بدون استخراج آنها با استفاده از ردیابی آزمایش کنید، به چنین چیزی نیاز است.
+- این دادهها واحدهای ترابایت را نشان میدهند، که گرههای آرشیوی را برای کاربران متوسط جذابتر میکند، اما میتواند برای خدماتی مانند کاوشگرهای بلوک، فروشندگان کیفپول و تحلیل زنجیره مفید باشد.
-- هر چیزی که در گره کامل نگهداری میشود را ذخیره کرده و یک آرشیو کامل از وضعیتهای تاریخی میسازد. وقتی میخواهید درخواستی بفرستید، مثل گرفتن موجودی حساب در بلوک شمارهی 4,000,000، یا بهطور ساده و قابلاتکا [مجموعهی تراکنش خود را بدون نیاز به استخراج آنها با استفاده از OpenEthereum آزمایش کنید](https://openethereum.github.io/JSONRPC-trace-module#trace_callmany)، نیاز میشود.
-- این دادهها واحدهای ترابایتی را نشان میدهند که گرههای آرشیو را برای کاربران متوسط از جذابیت میاندازد، اما میتواند برای سرویسهایی مانند جستجوگرهای بلوک، نگهدارندگان کیف پول و تجزیه و تحلیل زنجیره مفید باشند.
+همگامسازی کلاینتها در هر حالتی غیر از آرشیو منجر به کاهش دادههای زنجیرهی بلوکی میشود. این بدان معناست که هیچ آرشیوی از تمام حالتهای تاریخی وجود ندارد اما گرهی کامل قادر است آنها را بنا به تقاضا بسازد.
-همگامسازی کلاینتها در هر حالتی غیر از آرشیو منجر به کاهش دادههای زنجیرهی بلوکی میشود. این بدان معناست که هیچ آرشیوی از تمام وضعیتهای تاریخی وجود ندارد اما گرهی کامل قادر است آنها را بنا به تقاضا بسازد.
+درباره [نودهای آرشیوی](/developers/docs/nodes-and-clients/archive-nodes) بیشتر بدانید.
+
+### گره سبک {#light-node}
+
+به جای دانلود هر بلوک، گره های سبک فقط هدر بلوک ها را دانلود می کنند. این هدرها حاوی اطلاعات خلاصه ای در مورد محتویات بلوک ها هستند. هر اطلاعات دیگری که گره سبک نیاز دارد از یک گره کامل درخواست می شود. سپس گره سبک میتواند به طور مستقل دادههایی را که دریافت میکند با توجه به ریشههای حالت در هدرهای بلوک تأیید کند. گرههای سبک به کاربران امکان میدهند بدون سختافزار قدرتمند یا پهنای باند بالا که برای اجرای گرههای کامل لازم است، در شبکهی اتریوم مشارکت کنند. در نهایت، گرههای سبک ممکن است روی تلفنهای همراه یا دستگاههای تعبیهشده اجرا شوند. گرههای سبک در اجماع شرکت نمیکنند (یعنی نمیتوانند ماینر/اعتبارسنج باشند)، اما میتوانند با همان عملکرد و تضمینهای امنیتی یک گره کامل به بلاکچین اتریوم دسترسی داشته باشند.
+
+کلاینت های سبک ناحیهای برای توسعه فعال اتریوم هستند و انتظار داریم به زودی شاهد کلاینت های سبک جدید برای لایه اجماع و لایه اجرا باشیم. همچنین مسیرهای بالقوهای برای ارائهی دادههای کلاینت سبک از طریق [شبکهی شایعه](https://www.ethportal.net/) وجود دارد. این خودش مزیت است، زیرا شبکهی شایعه میتواند شبکهای از گرههای سبک را بدون نیاز به گرههای کامل برای ارائهی درخواستها پشتیبانی کند.
+
+اتریوم هنوز از گرههای سبک پرتعدادی پشتیبانی نمیکند، اما پشتیبانی از گرههای سبک حوزهای است که انتظار میرود در آیندهی نزدیک بهسرعت توسعه یابد. به طور خاص، کلاینتهایی مانند [Nimbus](https://nimbus.team/) و [Helios](https://github.com/a16z/helios) و [LodeStar](https://lodestar.chainsafe.io/) در حال حاضر به شدت بر روی گره های سبک متمرکز شده اند.
## چرا باید یک گرهی اتریوم را اجرا کنم؟ {#why-should-i-run-an-ethereum-node}
-اجرای یک گره به شما این امکان را میدهد که بدون نیاز به اعتماد و به شکل خصوصی از اتریوم ضمن پشتیبانی از اکوسیستم استفاده کنید.
+اجرای یک گره به شما این امکان را می دهد که به طور مستقیم، بدون نیاز به شخص ثالث و به صورت خصوصی از اتریوم استفاده کنید و در عین حال از شبکه با قوی تر و غیرمتمرکز نگه داشتن آن پشتیبانی کنید.
### مزایا برای شما {#benefits-to-you}
-اجرای گرهی خودتان شما را قادر میسازد از اتریوم به شکل واقعاً خصوصی، خودکفا و بدون نیاز به اعتماد استفاده کنید. نیازی نیست به شبکه اعتماد کنید زیرا میتوانید دادهها را خودتان با کلاینت خود تأیید کنید. «اعتماد نکنید، اعتبارسنجی کنید» یک سخن مشهور مربوط به زنجیرهی بلوکی است.
+اجرای گره شما را قادر می سازد از اتریوم به صورت خصوصی، خودکفا و بدون نیاز به شخص ثالث استفاده کنید. نیازی نیست به شبکه اعتماد کنید زیرا میتوانید دادهها را خودتان با کلاینت خود تأیید کنید. «اعتماد نکنید، اعتبارسنجی کنید» یکی از شعارهای اصلی زنجیرهی بلوکی است.
-- گرهی شما تمام تراکنشها و بلوکها را با توجه به قوانین اجماع به تنهایی اعتبارسنجی میکند. این به این معنی است که شما نیازی به اتکا به هیچ گرهی دیگری در شبکه یا اعتماد تام به آنها ندارید.
-- شما نیازی به افشای آدرس و موجودیتان به گرههای تصادفی ندارید. همه چیز میتواند با کلاینت خودتان بررسی شود.
-- اگر از گرهی خودتان استفاده کنید برنامهی غیرمتمرکزتان میتواند ایمنتر و خصوصیتر باشد. [MetaMask](https://metamask.io), [MyEtherWallet](https://myetherwallet.com) and some other wallets can be easily pointed to your own local node.
-- شما میتوانید نقاط پایانی فراخوانی رویهای دوردست (RPC) سفارشی خود را برنامهریزی کنید.
-- شما میتوانید با استفاده از **ارتباط بین پردازشی (IPC)** گرهی خود را متصل کنید یا برای بارگذاری برنامهی خود بهعنوان افزونه آن را بازنویسی کنید. با این روش تأخیر کمی خواهید داشت، که برای جایگزینی تراکنشهای شما در سریعترین زمان ممکن لازم است (یعنی پیشاجرا).
+- گره شما تمام تراکنشها و بلوکها را با توجه به قوانین اجماع به تنهایی اعتبارسنجی میکند. این نکته به این معنی است که شما نیازی به اتکا به هیچ گرهی دیگری در شبکه یا اعتماد تام به آنها ندارید.
+- می توانید از کیف پول اتریوم با گره خود استفاده کنید. میتوانید از دپها به صورت ایمنتر و خصوصیتر استفاده کنید، زیرا مجبور نخواهید بود آدرسها و موجودیهای خود را به واسطهها فاش کنید. همهچیز میتواند با کلاینت خودتان بررسی شود. [متاسک](https://metamask.io) و [Frame](https://frame.sh/) و [بسیاری از کیفپولهای دیگر](/wallets/find-wallet/) ورود RPC را پشتیبانی میکنند و به آنها امکان میدهد از گره شما استفاده کنند.
+- میتوانید سرویسهای دیگری را که به دادههای اتریوم وابسته هستند، اجرا و میزبانی کنید. به عنوان مثال، این ممکن است یک اعتبار سنج بیکنچین، نرمافزاری مانند لایه2، زیرساخت، کاوشگرهای بلوک، پردازشگرهای پرداخت و غیره باشد.
+- شما می توانید [نقاط پایانی RPC](/developers/docs/apis/json-rpc/) سفارشی خود را ارائه دهید. حتی می توانید این نقاط پایانی را به صورت عمومی به جامعه ارائه دهید تا به آنها کمک کنید از ارائهدهندگان متمرکز بزرگ اجتناب کنند.
+- شما میتوانید با استفاده از **ارتباط بین پردازشی (IPC)** گرهی خود را متصل کنید یا برای بارگذاری برنامهی خود بهعنوان افزونه آن را بازنویسی کنید. این کار لتنسی کمی را به همراه دارد، که کمک بسیاری می کند، به عنوان مثال، هنگام پردازش دادههای زیادی با استفاده از کتابخانههای وب3.0 یا زمانی که باید تراکنشهای خود را با بیشترین سرعت ممکن جایگزین کنید (یعنی frontrunning).
+- شما میتوانید مستقیماً اتر را برای ایمنسازی شبکه و کسب پاداش سهامگذاری کنید. بخش [سهامگذاری انفرادی](/staking/solo/) را برای شروع ببینید.
![چگونه با استفاده از برنامههای کاربردی و گرهها به اتریوم دسترسی داشته باشید](./nodes.png)
@@ -67,241 +100,202 @@ If you're new to the topic of nodes, we recommend first checking out our user-fr
داشتن مجموعهی متنوعی از گرهها برای سلامت، امنیت و انعطافپذیری عملیاتی اتریوم حائظ اهمیت است.
-- آنها دسترسی به دادههای زنجیرهی بلوکی را برای کلاینتهای سبکی که به آن وابسته هستند فراهم میکنند. در پیکهای استفادهی زیاد، باید گرههای کامل کافی برای همگامسازی گرههای سبک وجود داشته باشد. گرههای سبک همهی زنجیره بلوکی را ذخیره نمیکنند و به جای آن دادهها را با [ریشهی وضعیت درون هدر بلوکها](/developers/docs/blocks/#block-anatomy) اعتبارسنجی میکنند. آنها میتوانند در صورت نیاز اطلاعات بیشتری را از بلوکها درخواست کنند.
-- گرههای کامل قوانین اجماع اثبات کار را اجرا میکنند تا نتوان آنها را فریب داد که بلوکهایی را بپذیرند که از آنها پیروی نمیکنند. این کار امنیت بیشتری را در شبکه ایجاد میکند، چون اگر همهی گرهها گرههای سبک باشند که تأیید کامل را انجام نمیدهند، استخراجگرها میتوانند به شبکه حمله کنند و برای مثال بلوکهایی با پاداش بالاتر بسازند.
+- گره های کامل قوانین لایه اجماع را اجرا می کنند بنابراین نمی توان آنها را فریب داد تا بلوک هایی را بپذیرند که از آن قوانین پیروی نمی کنند. این امر امنیت بیشتری را در شبکه ایجاد می کند زیرا اگر همه گره ها گره های سبک باشند که تأیید کامل را انجام نمی دهند، اعتبار سنجها می توانند به شبکه حمله کنند.
+- در صورت حمله ای که بر دفاعیات اقتصاد رمزنگاریشدهی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/#what-is-pos) غلبه کند، می توان با انتخاب گره های کامل که از زنجیره صادقانه پیروی می کنند، یک بازیابی اجتماعی انجام داد.
+- گرههای بیشتر در شبکه منجر به ایجاد یک شبکه متنوعتر و قویتر میشود، هدف نهایی تمرکززدایی، که سیستمی مقاوم در برابر سانسور و قابل اعتماد را امکانپذیر میسازد.
+- گره های کامل دسترسی به داده های بلاکچین را برای کلاینتهای سَبُکی که به آن وابسته هستند، فراهم می کند. گرههای سبک همهی زنجیره بلوکی را ذخیره نمیکنند و به جای آن دادهها را با [ریشهی حالت درون هدر بلوکها](/developers/docs/blocks/#block-anatomy) اعتبارسنجی میکنند. آنها می توانند در صورت نیاز اطلاعات بیشتری را از گره های کامل درخواست کنند.
-اگر یک گرهی کامل را اجرا کنید، کل شبکهی اتریوم از آن سود میبرد.
+اگر یک گره کامل را اجرا کنید، کل شبکه اتریوم از آن سود می برد، حتی اگر اعتبارسنج را اجرا نکنید.
## اجرای گرهی خودتان {#running-your-own-node}
-به اجرای کلاینت اتریوم خود علاقه دارید؟
-
-For a beginner-friendly introduction visit our [run a node](/run-a-node) page to learn more.
-
-If you're more of a technical user, learn how to [spin up your own node](/developers/docs/nodes-and-clients/run-a-node/) with the command line!
-
-### پروژهها {#projects}
-
-[**یک کلاینت انتخاب کنید و دستورالعملهایش را اجرا کنید**](#clients)
-
-**ethnode -** **_یک گرهی اتریوم (geth یا OpenEthereum) را برای توسعهی محلی اجرا کنید._**
+دوست دارید کلاینت اتریوم خودتان را اجرا کنید؟
-- [گیتهاب](https://github.com/vrde/ethnode)
+جهت مطالعهی مقدمهای ویژهی مبتدیان، از صفحهی [اجرای یک گره](/run-a-node)ی ما دیدن کنید تا بیشتر بدانید.
-**DAppNode -** **_یک رابط کاربری گرافیکی سیستمعامل برای اجرای گرههای Web3 شامل اتریوم و زنجیرهی بیکن روی دستگاههای مخصوص._**
-
-- [dappnode.io](https://dappnode.io)
-
-### منابع {#resources}
-
-- [اجرای گرههای کامل اتریوم: راهنمایی کامل](https://medium.com/coinmonks/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _- جاستین لروکس، 7 نوامبر 2019_
-- [صفحهی تقلب پیکربندی گرهها](https://dev.to/5chdn/ethereum-node-configuration-modes-cheat-sheet-25l8) _5 ژانویه 2019 - آفری شودن_
-- [چگونه یگ گرهی geth را نصب و اجرا کنیم](https://www.quiknode.io/guides/infrastructure/how-to-install-and-run-a-geth-node) _ 4 اکتبر 2020 - ساهیل سن_
-- [چگونه یک گرهی OpenEthereum (parity سابق)](https://www.quiknode.io/guides/infrastructure/how-to-run-a-openethereum-ex-parity-client-node) _22 سپتامبر 2020 - ساهیل سان_
+اگر بیشتر یک کاربر فنی هستید، جزئیات و گزینههای بیشتری را در مورد نحوه [ثبتنام گره خود](/developers/docs/nodes-and-clients/run-a-node/) بررسی کنید.
## جایگزینها {#alternatives}
-اجرای گره خود میتواند دشوار باشد و همیشه نیازی به اجرای نمونهی خود ندارید. در این مورد شما میتوانید از وب سرویس طرف ثالث مثل [Infura](https://infura.io)، [Alchemy](https://alchemyapi.io) یا [QuikNode](https://www.quiknode.io) استتفاده کنید. [ArchiveNode](https://archivenode.io/) هم یک گزینهی جایگزین استکه امیدوار است دادههای آرشیو روی زنجیرهی بلوکی اتریوم را برای توسعهدهندگان مستقلی که در غیر این صورت توانایی پرداخت آن را ندارند، به ارمغان بیاورد. For an overview of using these services, check out [nodes as a service](/developers/docs/nodes-and-clients/nodes-as-a-service/).
+راهاندازی گره خود میتواند برای شما زمان و منابع هزینه داشته باشد، اما همیشه نیازی به اجرای نمونه خود ندارید. در این مورد، می توانید از یک ارائه دهنده API شخص ثالث استفاده کنید. برای مروری بر استفاده از این سرویسها، [گرهها بهعنوان سرویس](/developers/docs/nodes-and-clients/nodes-as-a-service/) را مطالعه کنید.
-اگر شخصی یک گرهی اتریوم را با یک وب سرویس عمومی در انجمن شما اجرا میکند، میتوانید کیف پولهای سبک خود (مانند MetaMask) را [از طریق RPC سفارشی](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) به یک گرهی انجمن هدایت کنید و نسبت به طرف ثالث مورد اعتماد تصادفی، حریم خصوصی بیشتری را حفظ کنید.
+اگر شخصی یک گره اتریوم را با یک API عمومی در انجمن شما اجرا می کند، می توانید کیف پول های خود را از طریق RPC سفارشی به یک گره انجمن هدایت کنید و از حریم خصوصی بیشتری نسبت به شخص ثالث مورد اعتماد تصادفی برخوردار شوید.
از طرف دیگر، اگر کلاینت را اجرا میکنید، میتوانید آن را با دوستان خود که ممکن است به آن نیاز داشته باشند به اشتراک بگذارید.
-## کلاینتهای اجرا (پیشتر «کلاینتهای Eth1») {#execution-clients}
+## کلاینتهای اجرا {#execution-clients}
-جامعهی اتریوم چندین کلاینت اجرای متنباز (که قبلاً به عنوان «کلاینتهای Eth1» یا فقط «کلاینتهای اتریوم» شناخته میشدند) نگهداری میکند که توسط تیمهای مختلف با استفاده از زبانهای برنامه نویسی مختلف توسعه یافتهاند. این کار باعث میشود شبکه قویتر و پخشتر شود. هدف ایدهآل دستیابی به تنوع بدون تسلط هیچ کلاینتی برای کاهش هر نقطه شکستی است.
+جامعهی اتریوم چندین کلاینت اجرای منبعباز (که قبلاً به عنوان «کلاینتهای Eth1» یا صرفاً «کلاینتهای اتریوم» شناخته میشدند) را نگهداری میکند که توسط تیمهای مختلف با استفاده از زبانهای برنامه نویسی مختلف توسعه یافتهاند. این شبکه را قویتر و [متنوعتر](/developers/docs/nodes-and-clients/client-diversity/) میکند. هدف ایدهآل، دستیابی به تنوع بدون تسلط هیچ کلاینتی برای کاهش هر نقطهی شکستی است.
-این جدول خلاصهای از کلاینتهای مختلف ارائه میدهد. همهی آنها در [آزمون کلاینت](https://github.com/ethereum/tests) قبول شدهاند و بهطور فعال نگهداری میشوند تا با ارتقاهای شبکه همگام بمانند.
+این جدول، اطلاعات کلاینتهای مختلف را بهطور خلاصه نشان میدهد. همهی آنها در [آزمایشهای کلاینت](https://github.com/ethereum/tests) قبول شدهاند و بهطور فعال نگهداری میشوند تا با ارتقاهای شبکه همگام بمانند.
-| کلاینت | زبان | سیستمعامل | شبکهها | راهبرد همگامسازی | هرس کردن وضعیت |
-| ------------------------------------------------------------------------- | --------------- | ----------------------- | -------------------------------------------- | ------------------- | ----------------------- |
-| [Geth](https://geth.ethereum.org/) | Go | لینوکس، ویندوز، مکاواس | شبکهی اصلی، Görli، Rinkeby، Ropsten | Snap, Full | آرشیو، هرسشده (Pruned) |
-| [Nethermind](http://nethermind.io/) | سیشارپ، داتنت | لینوکس، ویندوز، مکاواس | شبکهی اصلی، Görli، Rinkeby، Ropsten و بیشتر | Fast, Beam, Archive | آرشیو، هرسشده (Pruned) |
-| [Besu](https://besu.hyperledger.org/en/stable/) | جاوا | لینوکس، ویندوز، مکاواس | Mainnet, Rinkeby, Ropsten, Görli, and more | سریع، کامل | آرشیو، هرسشده (Pruned) |
-| [Erigon](https://github.com/ledgerwatch/erigon) | Go | لینوکس، ویندوز، مکاواس | شبکهی اصلی، Görli، Rinkeby، Ropsten | Full | آرشیو، هرسشده (Pruned) |
-| [OpenEthereum (Deprecated)](https://github.com/openethereum/openethereum) | Rust | لینوکس، ویندوز، مکاواس | شبکهی اصلی، Kovan، Ropsten و بیشتر | Warp، کامل | آرشیو، هرسشده (Pruned) |
+| کلاینت | زبان | سیستمعامل | شبکهها | راهبرد همگامسازی | هرس کردن وضعیت |
+| ------------------------------------------------------------------------ | ---------- | ----------------------- | --------------------------- | -------------------------------------------------------------- | ----------------------- |
+| [Geth](https://geth.ethereum.org/) | Go | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [Snap](#snap-sync), [Full](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Nethermind](https://www.nethermind.io/) | C#, .NET | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [Snap](#snap-sync) (without serving), Fast, [Full](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Besu](https://besu.hyperledger.org/en/stable/) | جاوا | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [فوری](#snap-sync), [سریع](#fast-sync), [پر](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Erigon](https://github.com/ledgerwatch/erigon) | Go | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [کامل](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [Reth](https://reth.rs/) | Rust | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [کامل](#full-sync) | آرشیو، هرسشده (Pruned) |
+| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | لینوکس، ویندوز، مکاواس | Sepolia, Holesky | [کامل](#full-sync) | Pruned |
-**دقت کنید که OpenEthereum[منسوخ شده است](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) و دیگر نگهداری نمیشود.** با احتیاط از آن استفاده کنید و ترجیحاً به پیادهسازی کلاینت دیگری بروید.
+جهت کسب اطلاعات بیشتر دربارهی شبکههای پشتیبانیشده [شبکههای اتریوم](/developers/docs/networks/) را بخوانید.
-برای شبکههای پشتیبانیشدهی بیشتر [شبکههای اتریوم](/developers/docs/networks/) را بخوانید.
+هر کلاینت دارای موارد استفاده و مزایای منحصربهفردی است، بنابراین شما باید یکی را بر اساس ترجیحات خود انتخاب کنید. تنوع اجازه میدهد تا پیادهسازیها بر روی ویژگیهای مختلف و مخاطبان کاربر متمرکز شوند. ممکن است بخواهید کلاینت را بر اساس ویژگیها، پشتیبانی، زبان برنامهنویسی یا مجوزها انتخاب کنید.
-### مزایای پیادهسازیهای مختلف {#advantages-of-different-implementations}
+### Besu {#besu}
-هر کلاینت دارای موارد استفاده و مزایای منحصر به فردی است، بنابراین شما باید یکی را بر اساس ترجیحات خود انتخاب کنید. تنوع اجازه میدهد تا پیادهسازیها بر روی ویژگیهای مختلف و مخاطبان کاربر متمرکز شوند. ممکن است بخواهید کلاینت را بر اساس ویژگیها، پشتیبانی، زبان برنامهنویسی یا مجوزها انتخاب کنید.
+هایپرلجر Besu یک کلاینت اتریوم در ردهی سازمانی برای شبکههای عمومی و مجوزدار است. این کلاینت تمام ویژگیهای اصلی اتریوم، از ردیابی گرفته تا GraphQL را اجرا میکند، نظارت گستردهای دارد و توسط ConsenSys، هم در کانالهای جامعه باز و هم از طریق SLAهای تجاری برای شرکتها، پشتیبانی میشود. این کلاینت به زبان جاوا نوشته شده است و دارای مجوز Apache 2.0 است.
-#### Go Ethereum {#geth}
+[اسناد](https://besu.hyperledger.org/en/stable/) گسترده Besu شما را در تمام جزئیات مربوط به ویژگیها و تنظیمات آن راهنمایی میکند.
-Go Ethereum (به طور خلاصه geth) یکی از پیادهسازیهای اصلی برای پروتکل اتریوم است. در حال حاضر، گستردهترین کلاینت با بزرگترین پایگاه کاربران و ابزارهای متنوع برای کاربران و توسعهدهندگان است. به زبان Go نوشتهشده، کاملاً متن باز است و مجوز آن تحت GNU LGPL v3 است.
+### Erigon {#erigon}
-#### OpenEthereum {#openethereum}
+Erigon که قبلاً به عنوان Turbo-Geth شناخته می شد، به عنوان یک فورک Go Ethereum با جهت گیری سرعت و کارایی فضای دیسک شروع به کار کرد. Erigon یک نرمافزار کاملاً بازسازیشده از اتریوم است که در حال حاضر با زبان Go نوشته شده است اما نرمافزارهایی به زبانهای دیگر در دست توسعه دارد. هدف Erigon ارائهی پیادهسازی سریعتر، ماژولارتر و بهینهتر اتریوم است. میتواند با استفاده از حدود 2 ترابایت فضای دیسک، در کمتر از 3 روز، همگامسازی گره آرشیو کامل را انجام دهد.
-OpenEthereum یک کلاینت اتریوم سریع، غنی و پیشرفته مبتنی بر CLI است. برای ارائه زیرساختهای ضروری برای خدمات سریع و قابل اعتماد ساخته شده است که نیاز به همگام سازی سریع و حداکثر زمان بهکار دارد. هدف OpenEthereum این است که سریعترین، سبکترین و امنترین کلاینت اتریوم باشد. یک پایگاه کد تمیز و ماژولار برای موارد زیر است:
+### Go Ethereum {#geth}
-- سفارشیسازی آسان.
-- ادغام سبک در خدمات یا محصولات.
-- حداقل حافظه و رد پای حافظه
+Go Ethereum (به طور خلاصه geth) یکی از پیادهسازیهای اصلی برای پروتکل اتریوم است. در حال حاضر، geth رایجترین کلاینت با بزرگترین پایگاه کاربران و ابزارهای متنوع برای کاربران و توسعهدهندگان است. این کلاینت به زبان Go نوشته شده است، کاملاً منبعباز است و مجوز آن تحت GNU LGPL v3 است.
-OpenEthereum با استفاده از زبان برنامهنویسی پیشرو Rust ساخته شده و مجوز آن تحت GPLv3 است.
+درباره Geth در [اسناد](https://geth.ethereum.org/docs/) آن بیشتر بیاموزید.
-**دقت کنید که OpenEthereum[منسوخ شده است](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) و دیگر نگهداری نمیشود.** با احتیاط از آن استفاده کنید و ترجیحاً به پیادهسازی کلاینت دیگری بروید.
+### Nethermind {#nethermind}
-#### Nethermind {#nethermind}
-
-Nethermind یک پیادهسازی اتریوم است که با پشتهی فناوری سیشارپ داتنت ایجاد شده و بر روی تمام پلتفرمهای اصلی از جمله ARM اجرا میشود. این پیادهسازی کارکردی عادی با موارد زیر ارائه میدهد:
+Nethermind یک نرمافزار اتریومی است که با پشته فناوری C#.NET، دارای مجوز LGPL-3.0 است که بر روی تمام پلتفرمهای اصلی از جمله ARM اجرا میشود. این پیادهسازی در رابطه با موارد زیر، کارکردی عالی دارد:
- یک ماشین مجازی بهینه
-- دسترسی به وضعیت
-- شبکه و ویژگیهای غنی مانند داشبوردهای Prometheus/Grafana، پشتیبانی از گزارش سازمانی seq، ردیابی JSON RPC، و افزونههای تجزیه و تحلیل.
+- دسترسی به حالت
+- شبکه و ویژگیهای غنی مانند داشبوردهای Prometheus/Grafana، پشتیبانی از گزارش سازمانی seq، ردیابی JSON-RPC، و افزونههای تجزیه و تحلیل.
-Nethermind همچنین [اسناد با جزییات](https://docs.nethermind.io)، پشتیبانی توسعهی قوی، یک جامعهی آنلاین و پشتیبانی 24 ساعته در 7 روز هفته برای کاربران پرمیوم دارد.
+Nethermind همچنین [مستندات مشروح](https://docs.nethermind.io)، پشتیبانی توسعهی قوی، یک جامعهی آنلاین و پشتیبانی 24 ساعته در 7 روز هفته برای کاربران پرمیوم دارد.
-#### Besu {#besu}
+### Reth {#reth}
-هایپرلجر Besu یک کلاینت اتریوم در ردهی سازمانی برای شبکههای عمومی و مجوزدار است. این کلاینت تمام ویژگیهای اصلی اتریوم، از ردیابی گرفته تا GraphQL را اجرا میکند، نظارت گستردهای دارد و توسط ConsenSys پشتیبانی میشود، هم در کانالهای جامعه باز و هم از طریق SLAهای تجاری برای شرکتها. به زبان جاوا نوشته شده و دارای مجوز آپاچی 2.0 است.
+Reth (مخفف Rust Ethereum) یک پیادهسازی گره کامل اتریوم است که بر کاربرپسند بودن، بسیار ماژولار، سریع و کارآمد تمرکز دارد. Reth در اصل توسط Paradigm ساخته و به جلو هدایت شد و تحت مجوز Apache و MIT مجوز دارد.
-#### Erigon {#erigon}
+Reth آماده تولید است و برای استفاده در محیطهای حیاتی مانند سرویسها یا سرویسهای با زمان بالا مناسب است. در موارد استفاده که عملکرد بالا با حاشیه های زیاد مورد نیاز است مانند RPC، MEV، ایندکسینگ، شبیه سازی و فعالیت های P2P، عملکرد خوبی دارد.
-Erigon که قبلاً به عنوان Erigon شناخته میشد، یک فورک Go Ethereum است که هدفش سرعت و کارایی فضای دیسک است. Erigon یک پیادهسازی کاملاً بازسازی شده از Ethereum است که در حال حاضر به زبان Go نوشته شده است، اما پیادهسازی آن به زبانهای دیگر برنامهریزی شده است. هدف Erigon ارائهی پیادهسازی سریعتر، ماژولارتر و بهینهتر اتریوم است. این کلاینت میتواند با بکارگیری کمتر از 2 ترابایت فضای دیسک، در کمتر از 3 روز، همگامسازی گرهی آرشیو کامل را انجام دهد
+با بررسی [Reth Book](https://reth.rs/) یا [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) بیشتر بیاموزید.
-### حالات همگامسازی {#sync-modes}
+### در حال توسعه {#execution-in-development}
-برای پیگیری و تأیید دادههای جاری در شبکه، کلاینت اتریوم باید با آخرین حالت شبکه همگام شود. این کار با دانلود دادهها از همتایان، تأیید رمزنگاری یکپارچگی آنها و ایجاد یک پایگاه دادهی محلی زنجیرهی بلوکی انجام میشود.
+این کلاینتها هنوز در مراحل اولیه توسعه هستند و هنوز برای استفاده در تولید توصیه نمی شوند.
-حالتهای همگامسازی رویکردهای متفاوتی را برای این فرایند با بدهبستانهای مختلف نشان میدهند. کلاینتها همچنین در پیادهسازیهای الگوریتمهای همگامسازی تفاوت دارند. برای جزئیات پیادهسازی، همیشه به مستندات رسمی کلاینت انتخابی خود مراجعه کنید.
+#### EthereumJS {#ethereumjs}
-#### نگاهی اجمالی بر راهبردها {#overview-of-strategies}
+کلاینت اجرای EthereumJS (EthereumJS) با TypeScript نوشته شده است و متشکل از تعدادی بسته، از جمله هسته های اولیه اتریوم که توسط کلاس های Block، Transaction و Merkle-Patricia Trie و اجزای اصلی مشتری شامل پیادهسازی ماشین مجازی اتریوم (EVM)، کلاس بلاکچین و پشته شبکه DevP2P ارائه می شود.
-نگاهی اجمالی بر رویکردهای همگامسازی استفادهشده در شبکهی اصلی کلاینتهای آماده:
+با خواندن [اسناد](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) در مورد آن بیشتر بیاموزید
-##### همگامسازی کامل
+## کلاینتهای اجماع {#consensus-clients}
-همگامسازی کامل همهی بلوکها (از جمله هدرها، تراکنشها و رسیدها) را بارگیری میکند و با اجرای هر بلوک از پیدایش، وضعیت زنجیرهی بلوکی را به صورت تدریجی ایجاد میکند.
+چندین کلاینت اجماع (که قبلاً بهعنوان کلاینتهای «Eth2» شناخته میشدند) وجود دارد که از [ارتقاهای اجماع](/roadmap/beacon-chain/) پشتیبانی میکنند. آنها مسئول همه منطق مربوط به اجماع از جمله الگوریتم انتخاب فورک، پردازش گواهیها و مدیریت پاداشها و مجازاتهای [اثبات سهام](/developers/docs/consensus-mechanisms/pos) هستند.
-- اعتماد را به حداقل میرساند و با تأیید هر تراکنش، بالاترین امنیت را ارائه میدهد.
-- ٰبا افزایش تعداد تراکنشها، پردازش همه تراکنشها ممکن است روزها تا هفتهها طول بکشد.
-
-##### همگامسازی سریع
+| کلاینت | زبان | سیستمعامل | شبکهها |
+| ------------------------------------------------------------- | ---------- | ----------------------- | --------------------------------------------------------------- |
+| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Pyrmont, Sepolia, Ropsten، و غیره |
+| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Sepolia, Ropsten، و غیره |
+| [Nimbus](https://nimbus.team/) | Nim | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Sepolia, Ropsten، و غیره |
+| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | لینوکس، ویندوز، مکاواس | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten، و غیره |
+| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | جاوا | لینوکس، ویندوز، مکاواس | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten، و غیره |
-همگامسازی سریع همه بلوکها (از جمله هدرها، تراکنشها و رسیدها) را دانلود میکند، همه هدرها را تأیید میکند، وضعیت را دانلود میکند و آن را در برابر هدرها تأیید میکند.
+### Lighthouse {#lighthouse}
-- بر امنیت مکانیزم اجماع اتکا دارد.
-- همگامسازی تنها چند ساعت زمان میبرد.
+Lighthouse یک زیرساخت کلاینت اجماع است که با زبان Rust تحت مجوز Apache-2.0 نوشته شده است. توسط Sigma Prime نگهداری می شود و از زمان پیدایش Beacon Chain پایدار و آماده تولید بوده است. شرکت های مختلف، استخرهای سهامگذاری و افراد به آن متکی هستند. هدف آن این است که در محیطهای مختلف، از رایانههای شخصی رومیزی گرفته تا پیادهسازیهای خودکار پیچیده، ایمن و کارآمد و قابل اجرا باشد.
-##### همگامسازی سبک
+اسناد را می توان در [کتاب Lighthouse](https://lighthouse-book.sigmaprime.io/) پیدا کرد
-حالت کلاینت سبک همهی هدرهای بلوک و دادههای بلوک را بارگیری میکند و برخی را بهطور تصادفی تأیید میکند. فقط نوک زنجیره را از نقاط بررسی مطمئن همگامسازی میکند.
+### Lodestar {#lodestar}
-- با تکیه بر اعتماد به توسعهدهندگان و مکانیزم اجماع، تنها آخرین وضعیت را دریافت میکند.
-- کلاینت ظرف چند دقیقه با وضعیت فعلی شبکه آماده استفاده است.
+Lodestar یک زیرساخت کلاینت اجرا آماده تولید است که با زبان Typescript تحت مجوز LGPL-3.0 نوشته شده است. این سیستم توسط ChainSafe Systems نگهداری می شود و جدیدترین کلاینت اجماع برای سهامگذاران انفرادی، توسعه دهندگان و محققین است. Lodestar متشکل از یک Beacon Node و کلاینت اعتبارسنج است که توسط زیرساخت جاوا اسکریپت پروتکلهای اتریوم پشتیبانی می شود. هدف Lodestar بهبود قابلیت استفاده اتریوم با کلاینتهای سبک، گسترش دسترسی به گروه بزرگتری از توسعه دهندگان و کمک بیشتر به تنوع اکوسیستم است.
-[اطلاعات بیشتر دربارهی کلاینتهای سبک](https://www.parity.io/blog/what-is-a-light-client/)
+اطلاعات بیشتر را می توانید در [وب سایت Lodestar](https://lodestar.chainsafe.io/) ما بیابید
-##### همگامسازی فوری
+### Nimbus {#nimbus}
-توسط geth پیادهسازی شده است. با استفاده از عکسهای فوری پویا که توسط همتایان ارائه میشوند، تمام دادههای حساب و ذخیرهسازی را بدون بارگیری گرههای درخت میانی بازیابی میکند و سپس درخت مرکل را به صورت محلی بازسازی میکند.
+Nimbus یک زیرساخت کلاینت اجماع است که با زبان Nim تحت مجوز Apache-2.0 نوشته شده است. این یک کلاینت آماده تولید است که توسط سهامگذاران انفرادی و استخرهای سهامگذاری استفاده می شود. Nimbus برای بهره وری از منابع طراحی شده است، و اجرای آن را بر روی دستگاه های دارای محدودیت منابع و زیرساخت های سازمانی با سهولت یکسان، بدون به خطر انداختن ثبات یا عملکرد پاداش آسان می کند. ردپای منبع سبکتر به این معنی است که کلاینت دارای حاشیه ایمنی بیشتری در زمانی که شبکه تحت استرس است باشد.
-- سریعترین راهبرد همگامسازی که توسط geth توسعه داده شده است و هماکنون حالت پیشفرض آن است
-- صرفهجویی در مصرف حافظه و پهنای باند شبکه بدون به خطر انداختن امنیت.
+در [اسناد Nimbus](https://nimbus.guide/) بیشتر بیاموزید
-[اطلاعات بیشتر در مورد همگامسازی فوری](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)
+### Prysm {#prysm}
-##### همگامسازی Warp
+Prysm یک کلاینت اجماع با امکانات کامل و منبع باز است که با زبان Go تحت مجوز GPL-3.0 نوشته شده است. دارای یک رابط کاربری وب اپلیکیشن اختیاری است و تجربه کاربر، اسناد و قابلیت پیکربندی را هم برای کاربران شرکتی و هم برای کاربران سازمانی در اولویت قرار می دهد.
-توسط OpenEthereum پیادهسازی شده است. گرهها بهطور منظم یک عکس فوری از وضعیت بحرانی اجماع تولید میکنند و هر همتایی میتواند این عکسهای فوری را از طریق شبکه دریافت کند و همگامسازی سریع را از این نقطه ممکن سازد.
+برای اطلاعات بیشتر به [اسناد Prysm](https://docs.prylabs.network/docs/getting-started/) مراجعه کنید.
-- سریعترین حالت و حالت پیشفرض همگامسازی OpenEthereum متکی به عکسهای فوری ایستا است که توسط همتایان ارائه میشود.
-- راهکاری مشابه همگامسازی فوری اما بدون مزایای امنیتی خاص.
+### Teku {#teku}
-[اطلاعات بیشتر در مورد Warp](https://openethereum.github.io/Beginner-Introduction#warping---no-warp)
+Teku یکی از کلاینت های اصلی Beacon Chain Genesis است. در کنار اهداف معمول (امنیت، استحکام، پایداری، قابلیت استفاده، عملکرد)، Teku به طور خاص به دنبال مطابقت کامل با استانداردهای مختلف کلاینت اجماع است.
-##### همگامسازی Beam
+Teku گزینه های استقرار بسیار انعطاف پذیری را ارائه می دهد. گره beacon و کلاینت اعتبارسنج را می توان با هم به عنوان یک فرآیند واحد اجرا کرد که برای سهامگذاران انفرادی بسیار راحت است، یا گره ها را می توان به طور جداگانه برای عملیات های پیچیده ای اجرا کرد. علاوه بر این، Teku به طور کامل با [Web3Signer](https://github.com/ConsenSys/web3signer/) برای امضای امنیت کلید و حفاظت از جریمه قابل استفاده است.
-توسط Nethermind و Trinity پیادهسازی شده است. مانند همگامسازی سریع عمل میکند، اما دادههای مورد نیاز برای اجرای آخرین بلوکها را نیز بارگیری میکند، که به شما امکان میدهد ظرف چند دقیقه جستجوی زنجیره را شروع کنید.
+Teku به زبان جاوا نوشته شده و دارای مجوز آپاچی 2.0 است. این کلاینت توسط تیم Protocols در ConsenSys که مسئولیت Besu و Web3Signer را نیز بر عهده دارد، توسعه یافته است. در [اسناد Teku](https://docs.teku.consensys.net/en/latest/) بیشتر بیاموزید.
-- ابتدا وضعیت را همگامسازی میکند و شما را قادر میسازد ظرف چند دقیقه RPC را درخواست کنید.
-- هنوز در حال توسعه است و کاملاً قابلاعتماد نیست، همگامسازی پسزمینه کند شده است و پاسخهای RPC ممکن است شکست بخورند.
+## حالات همگامسازی {#sync-modes}
-[اطلاعات بیشتر دربارهی همگامسازی Beam](https://medium.com/@jason.carver/intro-to-beam-sync-a0fd168be14a)
+برای پیگیری و تأیید دادههای جاری در شبکه، کلاینت اتریوم باید با آخرین حالت شبکه همگام شود. این کار با بارگیری کردن دادهها از همتایان، تأیید رمزنگاری یکپارچگی آنها و ایجاد یک پایگاه دادهی محلی زنجیرهی بلوکی انجام میشود.
-#### برپا کردن در کلاینتها {#client-setup}
+حالتهای همگامسازی رویکردهای متفاوتی را برای این فرایند با بدهبستانهای مختلف نشان میدهند. کلاینتها همچنین در پیادهسازیهای الگوریتمهای همگامسازی تفاوت دارند. برای اطلاع از جزئیات پیادهسازی، همیشه به مستندات رسمی کلاینت انتخابی خود مراجعه کنید.
-کلاینتها با توجه به نیازهای شما گزینههای پیکربندی غنیای را ارائه میدهند. بر اساس سطح امنیت، دادههای موجود و هزینه، موردی را انتخاب کنید که برای شما مناسب است. به غیر از الگوریتم همگامسازی، میتوانید هرس (pruning) انواع مختلف دادههای قدیمی را نیز تنظیم کنید. هرس امکان حذف دادههای قدیمی را فراهم میکند، بهعنوان مثال حذف گرههای درخت وضعیت که از بلوکهای اخیر غیرقابلدسترسی هستند.
+### حالتهای همگامسازی لایه اجرا {#execution-layer-sync-modes}
-به مستندات یا صفحهی راهنمای کلاینت توجه کنید تا بفهمید کدام حالت همگامسازی حالت پیشفرض است. شما میتوانید زمانی که بهطور کامل تنظیم شدید مدل همگامسازی ترجیحی را انتخاب کنید، مثل:
+لایه اجرا ممکن است در حالتهای مختلف اجرا شود تا با موارد استفاده متفاوت مطابقت داشته باشد، از اجرای مجدد حالت سراسریبلاکچین گرفته تا فقط همگامسازی با نوک زنجیره از یک نقطه بازرسی قابل اعتماد.
-**تنظیم همگامسازی سبک در [geth](https://geth.ethereum.org/) یا [ERIGON](https://github.com/ledgerwatch/erigon)**
+#### همگامسازی کامل {#full-sync}
-`geth --syncmode "light"`
+یک همگامسازی کامل همه بلوکها (از جمله سرصفحهها و بدنههای بلوک) را دانلود میکند و با اجرای هر بلوک از زمان بلوک جنسیس، حالت بلاکچین را بهصورت تدریجی بازسازی میکند.
-**تنظیم همگامسازی کامل با آرشیو در [Besu](https://besu.hyperledger.org/)**
+- اعتماد را به حداقل میرساند و با تأیید هر تراکنش، بالاترین امنیت را ارائه میدهد.
+- ٰبا افزایش تعداد تراکنشها، پردازش همه تراکنشها ممکن است روزها تا هفتهها طول بکشد.
-`besu --sync-mode=FULL`
+[گرههای آرشیو](#archive-node) یک همگامسازی کامل را برای ایجاد (و حفظ) تاریخچه کاملی از تغییرات حالت ایجاد شده توسط هر تراکنش در هر بلوک انجام میدهند.
-مانند هر پیکربندی دیگر، می توان آن را با پرچم راهاندازی (startup flag) یا در فایل پیکربندی تعریف کرد. یک مثال دیگر [Nethermind](https://docs.nethermind.io/nethermind/) است که از شما میخواهد پیکربندی را در اولین تنظیم اولیه انتخاب کنید و یک فایل پیکربندی ایجاد میکند.
+#### همگامسازی سریع {#fast-sync}
-## کلاینتهای اجماع («کلاینتهای Eth2» سابق) {#consensus-clients}
+همانند یک همگامسازی کامل، یک همگامسازی سریع همه بلوکها (از جمله سرصفحهها، تراکنشها و رسیدها) را دانلود میکند. با این حال، بهجای پردازش مجدد تراکنشهای تاریخی، یک همگامسازی سریع هنگامی که به وضعیت وارد کردن و پردازش کردن بلوکها تغییر مییابد تا یک فول نود را تهیه کند، تا زمانی که به سررسید اخیر برسد، به رسیدها متکی است.
-چندین کلاینت اجماع (که قبلاً بهعنوان کلاینتهای «Eth2» شناخته میشدند) وجود دارد که از [ارتقاهای اجماع](/roadmap/beacon-chain/) پشتیبانی میکنند. They are running the Beacon Chain and will provide proof-of-stake consensus mechanism to execution clients after [The Merge](/roadmap/merge/).
+- استراتژی همگامسازی سریع.
+- تقاضای پردازش را به نفع استفاده از پهنای باند کاهش می دهد.
-| کلاینت | زبان | سیستمعامل | شبکهها |
-| ----------------------------------------------------------- | ---------- | ----------------------- | ---------------------------------------- |
-| [Teku](https://pegasys.tech/teku) | جاوا | لینوکس، ویندوز، مکاواس | زنجیرهی بیکن، Goerli |
-| [Nimbus](https://nimbus.team/) | Nim | لینوکس، ویندوز، مکاواس | زنجیرهی بیکن، Goerli |
-| [Lighthouse](https://lighthouse-book.sigmaprime.io/) | Rust | لینوکس، ویندوز، مکاواس | زنجیرهی بیکن، Goerli، Pyrmont |
-| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | لینوکس، ویندوز، مکاواس | زنجیرهی بیکن، Goerli |
-| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | لینوکس، ویندوز، مکاواس | زنجیرهی بیکن، Gnosis، Goerli، Pyrmont |
+#### همگامسازی فوری {#snap-sync}
-## سختافزار {#hardware}
+همگامسازیهای سریع نیز زنجیره را بلوک به بلوک تأیید میکنند. با این حال، به جای شروع از بلوک جنسیس، یک همگامسازی فوری در یک نقطه بازرسی جدیدتر «معتمد» که به عنوان بخشی از بلاکچین واقعی شناخته شده است، شروع می شود. گره در حین حذف داده های قدیمی تر از سن معین، نقاط بازرسی دوره ای را ذخیره می کند. این اسنپشاتها برای بازسازی دادههای حالت در صورت نیاز به جای ذخیرهسازی برای همیشه استفاده میشوند.
-نیازهای سختافزاری بر اساس کلاینت متفاوت است اما معمولاً آنقدر زیاد نیست چون گره فقط باید همگام بماند. این را با استخراج که نیاز به توان پردازشی زیادی دارد اشتباه نگیرید. با این حال، سختافزار قدرتمندتر زمان همگامسازی و عملکرد را بهبود میبخشد. بسته به نیازها و خواستههای شما، اتریوم میتواند بر روی رایانه، سرور خانگی، رایانههای تکبُرد یا سرورهای خصوصی مجازی در فضای ابری اجرا شود.
+- سریعترین استراتژی همگام سازی، در حال حاضر به طور پیش فرض در شبکه اصلی اتریوم.
+- صرفهجویی در مصرف حافظه و پهنای باند شبکه بدون به خطر انداختن امنیت.
-یک راه ساده برای اجرای گرهی خودتان، استفاده از باکسهای پلاگ اند پلی (plug and play) مثل [DAppNode](https://dappnode.io/) است. این باکسْ سختافزار لازم برای اجرای کلاینتها و برنامههایی که به آنها وابسته است را با یک رابط کاربری ساده ارائه میدهد.
+[جزئیات بیشتر همگامسازی سریع](https://github.com/ethereum/devp2p/blob/master/caps/snap.md).
-### الزامات {#requirements}
+#### همگامسازی سبک {#light-sync}
-پیش از نصب هر کلاینتی مطمئن شوید که رایانهی شما منابع لازم را برای اجرای آن دارد. الزامات کمینه و پیشنهادی را میتوانید در زیر ببینید، هر چند که بخش کلیدی آن فضای حافظه است. همگامسازی زنجیرهی بلوکی اتریوم بسیار به ورودی و خروجی حساس است. بهتر است که حتما درایو حالت جامد (SSD) داشته باشید. برای اجرای کلاینت اتریوم بر روی هارددیسک (HDD) شما نیاز به حداقل 8 گیگابایت رم دارید که به عنوان حافظهی نهان استفاده کنید.
+حالت کلاینت سبک همهی هدرهای بلوک و دادههای بلوک را بارگیری میکند و برخی را بهطور تصادفی تأیید میکند. فقط نوک زنجیره را از نقاط بررسی مطمئن همگامسازی میکند.
-#### الزامات حداقلی {#recommended-specifications}
+- با تکیه بر اعتماد به توسعهدهندگان و مکانیزم اجماع، تنها آخرین وضعیت را دریافت میکند.
+- کلاینت ظرف چند دقیقه با وضعیت فعلی شبکه آماده استفاده است.
-- پردازنده با حداقل دو هسته
-- حداقل 4 گیگابایت رم با یک درایو ذخیرهسازی جامد (SSD)، +8 گیگابایت اگر هارددیسک دارید
-- پهنای باند 8 مگابیت بر ثانیه
+**نکته** همگامسازی سبک هنوز با اتریوم اثبات سهام کار نمیکند - نسخههای جدید همگامسازی سبک به زودی عرضه میشوند!
-#### مشخصات پیشنهادی {#recommended-specifications}
+[بیشتر در مورد کلاینت های سبک](/developers/docs/nodes-and-clients/light-clients/)
-- پردازندهی سریع با حداقل چهار هسته
-- حداقل 16 گیگابایت رم
-- درایو ذخیرهسازی جامد (SSD) سریع با حداقل 500 گیگابایت فضای خالی
-- پهنای باند بیش از 25 مگابیت بر ثانیه
+### حالتهای همگامسازی لایه اجماع {#consensus-layer-sync-modes}
-حالت همگامسازی که انتخاب میکنید بر فضای مورد نیاز تأثیر میگذارد، اما ما فضای دیسک مورد نیاز برای هر کلاینت را در زیر تخمین زدهایم.
+#### همگامسازی خوشبینانه {#optimistic-sync}
-| کلاینت | فضای حافظه (همگامسازی سریع) | فضای حافظه (آرشیو کامل) |
-| ------------ | ---------------------------- | ----------------------- |
-| Geth | بیش از 400 گیگابایت | بیش از 6 ترابایت |
-| OpenEthereum | بیش از 280 گیگابایت | بیش از 6 ترابایت |
-| Nethermind | بیش از 200 گیگابایت | بیش از 5 ترابایت |
-| Besu | بیش از 750 گیگابایت | بیش از 5 ترابایت |
-| Erigon | اطلاقناپذیر | بیش از 1 ترابایت |
+همگامسازی خوشبینانه یک استراتژی همگامسازی پس از ارتقاء مرج است که بهمنظور سازگاری با انتخاب و عقبنشینی طراحی شده است و به گرههای اجرا اجازه میدهد از طریق روشهای تعیینشده همگام شوند. موتور اجرا می تواند _بهطور خوشبینانه_ بلوک های بیکن را بدون تأیید کامل آنها وارد کند، آخرین هد را پیدا کند و سپس شروع به همگام سازی زنجیره با روش های بالا کند. سپس، پس از اینکه کلاینت اجرا به نتیجه رسید، اعتبار تراکنشهای موجود در زنجیره بیکن را به کلاینت اجماع اطلاع میدهد.
-- توجه: Erigon همگامسازی سریع را انجام نمیدهد، اما هرس کامل امکانپذیر است (تقریبا 500 گیگابایت)
+[حزئیات بیشتر همگامسازی خوشبینانه](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md)
-این نمودارها نشان میدهند الزامات حافظه چطور همواره در حال تغییر هستند. برای بهروزترین دادهها برای geth و OpenEthereum [دادههای همگامسازی کامل](https://etherscan.io/chartsync/chaindefault) و [دادههای همگامسازی آرشیو](https://etherscan.io/chartsync/chainarchive) را مشاهده کنید.
+#### همگامسازی نقطه بازرسی {#checkpoint-sync}
-### اتریوم روی رایانهی تکبرد {#ethereum-on-a-single-board-computer}
+همگامسازی نقطه بازرسی، که به عنوان همگامسازی ذهنی ضعیف نیز شناخته میشود، تجربه کاربری برتری را برای همگامسازی Beacon Node ایجاد میکند. این مبتنی بر فرضیات [فردیت ضعیف](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) است که امکان همگام سازی زنجیره بیکن از یک نقطه بازرسی ذهنی ضعیف اخیر را به جای جنسیس فراهم می کند. همگامسازیهای نقطه بازرسی با مفروضات اعتماد مشابهی مانند همگامسازی از زمان بلوک [جنسیس](/glossary/#genesis-block)، زمان همگامسازی اولیه را به میزان قابل توجهی سریعتر میکند.
-راحتترین و ارزانترین راه برای اجرای گرهی اتریوم استفاده از یک رایانهی تکبردی با معماری ARM مانند Raspberry Pi است. [اتریوم روی ARM](https://twitter.com/EthereumOnARM) تصاویری از کلاینتهای geth، OpenEthereum، Nethermind و Besu ارائه میدهد. این یک آموزش ساده برای [چگونه یک کلاینت ARM را بسازیم و بر پا کنیم](/developers/tutorials/run-node-raspberry-pi/) است.
+در عمل، این بدان معناست که گره شما به یک سرویس راه دور متصل می شود تا حالت های نهایی را بارگیری کند و به تأیید داده ها از آن نقطه ادامه می دهد. شخص ثالثی که داده ها را ارائه می دهد مورد اعتماد است و باید با دقت انتخاب شود.
-دستگاههای کوچک، مقرون به صرفه و کارآمد مانند اینها برای اجرای یک گره در خانه ایده آل هستند.
+جزئیات بیشتر [همگامسازی نقطه بازرسی](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)
## بیشتر بخوانید {#further-reading}
-اطلاعات بسیاری دربارهی کلاینتهای اتریوم بر روی اینترنت وجود دارد. اینها چند منبع هستند که میتوانند مفید باشند.
-
- [اتریوم مقدماتی - بخش دوم - فهم گرهها](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _- ویل بارنز، 13 فوریه 2019_
-- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کم انگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _- جاستین لروکس، 7 نوامبر 2019_
-- [آنالیز نیازمندیهای سختافزار برای تبدیل شدن به یک گرهی کامل معتبر اتریوم](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _- آلبرت پالا، 24 سپتامبر 2018_
-- [اجرای یک گره Besu هایپرلجر بر شبکهی اصلی اتریوم: مزایا، نیازمندیها و راهاندازی](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _- فلیپ فراگی، 7 مه 2020_
+- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جاستین لروکس، 7 نوامبر 2019_
## موضوعات مرتبط {#related-topics}
@@ -310,4 +304,4 @@ Erigon که قبلاً به عنوان Erigon شناخته میشد، یک ف
## آموزشهای مرتبط {#related-tutorials}
-- [Raspberry Pi 4 خود را فقط با اتصال کارت MicroSD به یک گرهی اعتبارسنج تبدیل کنید - راهنمای نصب](/developers/tutorials/run-node-raspberry-pi/) _- Raspberry Pi 4 خود را متصل کنید، یک کابل اترنت وصل کنید، دیسک SSD را وصل کنید و دستگاه را روشن کنید تا Raspberry Pi 4 را به یک گرهی کامل اتریوم که لایهی اجرا (شبکهی اصلی) و / یا لایهی اجماع (زنجیرهی بیکن / اعتبارسنج) را اجرا میکند تبدیل کنید._
+- [Raspberry Pi 4 خود را فقط با اتصال کارت MicroSD به یک گره اعتبارسنج تبدیل کنید – راهنمای نصب](/developers/tutorials/run-node-raspberry-pi/) _– Raspberry Pi 4 خود را فلش کنید، یک کابل اترنت به آن وصل کنید، دیسک SSD را وصل کنید و دستگاه را روشن کنید تا Raspberry Pi 4 را به یک گره کامل اتریوم که لایه اجرا (شبکهی اصلی) و / یا لایه اجماع (زنجیرهی بیکن / اعتبارسنج) را اجرا میکند، تبدیل کنید._
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/light-clients/index.md
new file mode 100644
index 00000000000..bc48499e54c
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/light-clients/index.md
@@ -0,0 +1,61 @@
+---
+title: کاربرهای رقیق
+description: مقدمهای بر کاربر سبک اتریوم.
+lang: fa
+---
+
+اجرای گره کامل روشی خصوصی، مقاوم به سانسور و غیر متمرکز برای تعامل با شبکۀ اتریوم است. با داشتن یک گره کامل در واقع نسخۀ خود از بلاک چین را خواهید داشت که میتوانید از طریق آن به شبکۀ همتا به همتای اتریوم دسترسی مستقیم داشته باشید و در لحظه از آن پرس و جو کنید. به هر حال، اجرای گره کامل نیازمند مقادیر قابل توجه از منابع محاسباتی مانند حافظه، فضای ذخیرهسازی و قدرت پردازش است. بنابراین هر کس در شبکه نمیتواند گره خود را اجرا کند. در نقشۀ راه اتریوم چندین راهحل برای این مسئله وجود دارد برای مثال بیوضعیت بودن یکی از این راهحلهاست که البته چندین سال با اجرای آن فاصله داریم. برای آیندهای نزدیک، چارهای جز فدا کردنِ برخی از مزایای گره کامل در برابر بهبود کارکردی نداریم، این راهکار به افراد اجازه میدهد با الزامات سختافزاری حداقلی بتوانند گرههایی اجرا کنند. گرههایی که این کار را میکنند گره سبک نام دارند.
+
+## کاربر سبک چیست؟ {#what-is-a-light-client}
+
+گره سبک گرهای است که نرمافزار کاربر سبک را اجرا میکند. به جای نگهداری از نسخه های محلی از زنجیرهی بلوکی و تائید مستقل همه تغییرات، در عوض آنها داده های لازم را از بعضی از ارائه دهندگان درخواست می کنند. ارائه دهنده ممکن است به گره کامل دسترسی مستقیم، یا طریق یک سرور RPC متمرکز شده، داشته باشد. پس از آن داده توسط گره سیک تائید می شود، که اجازه می دهد با سر یا راس زنجیره همگام شود. در واقع گره سبک فقط سرتیتر بلوکها را پردازش و نگهداری میکند و فقط در شرایط خاصی محتوای کامل یک بلوک را دانلود میکند. گرهها بسته به ترکیب نرمافزار سَبُکی و کاربر کاملی که اجرا میکنند، میتوانند از نظر سَبُکی متفاوت باشند. برای مثال، سبکترین پیکربندی شامل اجرای یک کاربر اجرای سبک و یک کاربر اجماع سبک خواهد بود. همچنین ممکن است بسیاری از گرهها بخواهند یک گره کامل در لایه اجرا و یک گره سبک در لایه اجماع یا بالعکس باشند.
+
+## کاربرهای سبک چگونه کار میکنند؟ {#how-do-light-clients-work}
+
+زمانی که شبکه اتریوم شروع به استفاده از مکانیزم اجماع اثبات سهام کرد، زیرساخت جدیدی مخصوص پشتیبانی از کاربرهای سبک معرفی شد. این سیستم با انتخاب تصادفی یک زیرمجموعه از دستههای متشکل از 512 گره اعتبارسنج در هر 1.1 ثانیه کار میکند که به عنوان یک **کمیتۀ همگامسازی** عمل میکند. این کمیته همگامسازی، سرتیتر بلوکهای جدید را امضا میکند. سرتیتر هر بلوک شامل امضای تجمیعی اعتبارسنجهای کمیته همگامسازی و نیز یک bifield است که نشان میدهد کدام اعتبارسنجها امضا کرده و کدام یک امضا نکردهاند. به علاوه در سرتیتر بلوک یک لیست اعتبارسنجهایی وجود دارد که انتظار میرود د امضای بلوک بعدی شرکت کنند. در نتیجه یک گره سبک به سرعت میتواند تایید کمیته اعتبارسنج و همچنین اصالت کمیته را بررسی کند، آنها این کار را با مقایسۀ دادههای دریافتی با دادۀ مورد انتظارشان در بلاک قبلی انجام میدهند. از این طریق، گره سبک میتواند بدون دانلود زنجیرۀ کامل اتریوم و تنها با استفاده از سرتیترها، خود را با آخرین وضعیت بلاک چین همگام کند.
+
+در لایۀ اجرا هیچ مشخصات دقیقی برای گرههای سبک وجود ندارد. گره سبک در لایۀ اجرا میتواند یک «حالت سبک» از گره کامل باشد که مشابه با آن دارای تمام قابلیتهای شبکه و ماشین مجازی اتریوم است اما تنها سرتیتر بلاکها را بدون دانلود آنها تایید میکند، یا ممکن است یک کلاینت خلاصهتر باشد که برای تعامل خود با شبکه اتریوم به درخواستهای RPC ارسالی به یک سرور خارجی متکی است.
+
+## چرا گرههای سبک مهم هستند؟ {#why-are-light-clients-important}
+
+گره سبک از این منظر اهمیت دارد که به کاربران امکان میدهد به جای اعتماد کورکورانه به خدمات یک اپراتور واسطه، دادههای ورودی را با تنها کسر کوچکی از منابع محاسباتی یک گره کامل تایید کنند. گرههای سبک میتوانند درستی دادههای دریافتی را با سرتیتر بلاکها که میدانند توسط حداقل دو سومِ مجموعهای تصادفی از 512 اعتبارسنج اتریوم امضا شدهاند، کنترل کنند. این میتواند مدرکی قوی از صحت دادهها باشد.
+
+اجرای یک گره سبک فقط به مقدار کمی قدرت محاسباتی، حافظه و فضای ذخیرهسازی نیاز دارد، بنابراین با یک دستگاه موبایل و از طریق اپلیکیشن یا افزونه مرورگر میتوان به یک گره سبک در شبکه تبدیل شد. در واقع گره سبک روشی بینیاز از اعتماد برای دسترسی به اتریوم است که به همان اندازۀ وابستگی به طرف یک واسطه یا اپراتور خارجی، بدون زحمت و آسان است.
+
+یک مثال ساده را میتوان برای روشن شدن موضوع در نظر گرفت. فرض کنید میخواهیم آخرین موجودی آدرس خود را چک کنیم. برای این کار باید درخواستی را به یک گره کامل اتریوم ارسال کنیم. گره کامل پس از بررسی نسخۀ محلی خود از وضعیت اتریوم میتواند موجودی حساب را به شما اعلام کند. به هر حال، بسیاری از کاربران دسترسی مستقیم به یک گره کامل ندارند و باید از اپراتورهای متمرکز که این خدمات را ارائه میدهند، استفاده کنند. درخواست به آنها ارسال میشود و نتیجه به شما باز میگردد. یک مشکل جدی وجود دارد، باید به آن اپراتور خارجی و صحت دادههایش اعتماد کنید. تا خودتان به عنوان یک گره آنها را تایید نکنید، هرگز راهی وجود ندارد تا از صحت اطلاعات به طور کامل مطمئن شوید.
+
+گره سبک این مشکل را رفع میکند. البته لازم به ذکر است که همچنان دادهها باید از یک اپراتور خارجی درخواست شوند اما وقتی دادهها دریافت شد، گره سبک میتواند صحت آنها را با اطلاعات موجود در سرتیتر بلاکها کنترل کند، در این صورت است که میتوان از درستی دادهها اطمینان داشت. در واقع، اینجا، به جای یک اپراتور مورد اعتماد، خودِ شبکۀ اتریوم است که درستی دادهها را تایید میکند.
+
+## با گره سبک چه ابداعاتی ممکن میشوند؟ {#what-innovations-do-light-clients-enable}
+
+توانمندسازی افراد در دسترسی به شبکۀ اتریوم به صورت مستقل و با سطحی حداقلی از الزامات سختافزاری و اتکا به واسطهها، مزیت اصلی گره سبک است. این برای کاربران سودمند است زیرا میتوانند دادهها را خود تایید کنند و برای شبکه خوب است چون تعداد و تنوع گرههای مشارکتکننده در تایید بلاکها را افزایش میدهد.
+
+توانایی در اجرای گره اتریوم روی دستگاههایی با فضای ذخیره، حافظه و قدرت پردازش محدود، اصلیترین زمینۀ نوآوریهای بعدی است که به واسطۀ راهحل گره سبک شکوفا خواهند شد. در حالی که گرههای اتریوم در حال حاضر نیاز به مقدار قابل توجهی منابع محاسباتی دارند، گره سبک میتواند در مرورگرها تعبیه شود، روی دستگاه موبایل یا حتی دستگاههای کوچکتر مثل ساعت هوشمند اجرا شود. این بدان معناست که کیف پولهای اتریوم با کلاینتهای تعبیهشده میتوانند روی تلفن همراه اجرا شوند. بنابراین کیف پولهای موبایل میتوانند بیشتر از این غیر متمرکز شوند زیرا نیازی به دادههای تامینکنندگان متمرکز ندارند.
+
+فراتر از این، نوآوری گره سبک به **پیادهسازی فناوری اینترنت اشیا (IoT)** کمک میکند. یک گره سبک میتواند به سرعت مالکیت یک توکن یا NFT را تایید کند و فعالیتهایی را در شبکۀ اینترنت اشیا انجام دهد. یک [سرویس کرایۀ دوچرخه](https://youtu.be/ZHNrAXf3RDE?t=929) را در نظر بگیرید که با اجرای یک گره سبک به سرعت میتواند توکن NFT مربوط به سرویس دوچرخه را تایید کند و قفل دوچرخه را برای استفادۀ کاربر باز کند!
+
+رولآپهای اتریوم نیز میتوانند از گرههای سبک بهرهمند شوند. یکی از مشکلات اساسی آنها حملات هکری به پلتفرمهای پل است که برای انتقال داراییها از شبکۀ اصلی اتریوم به یک رولآپ استفاده میشوند. آسیبپذیری اصلی در اراکل بروز میکند که برای اطلاع از واریز شدنِ وجوه کاربر در پلتفرم پل، توسط رولآپ استفاده میشوند. اگر یک اراکل دادههای غلط بفرستد میتواند رولآپ را متقاعد کند که وجوه کاربر به پلتفرم پل فرستاده شدهاند و موجب شود وجوهی را به اشتباه آزاد کند. اجرای گره سبک در یک رولآپ میتواند در برابر اراکل مخرب ایستادگی کند زیرا واریز وجوه به پلتفرم پل توسط خودِ رولآپ تایید میشود. همین مفهوم میتواند برای سایر پلتفرمهای پل بینرنجیرهای نیز صادق باشد.
+
+گرههای سبک همچنین به ارتقای کیف پولهای اتریوم کمک میکنند. به جای اعتماد به دادههای یک اپراتور خارجی، کیف پول شما میتواند با استفاده از یک گره سبک دادهها را به صورت مستقیم تایید کند. این موضوع به افزایش امنیت کیف پولهای اتریوم میانجامد. اگر اپراتور خارجی، متقلب باشد و دادههای نادرست در اختیارتان بگذارد، گره سبک به شما خواهد گفت!
+
+## وضعیت فعلی پیشرفت گره سبک چگونه است؟ {#current-state-of-development}
+
+اکنون چندین نوع گره سبک در حال توسعه هستند که گرههای اجرای سبک، گرههای اجماع سبک یا ترکیبی از این دو هستند. اینها مثالهایی از پیادهسازی گره سبک هستند که تا زمان نوشتن این صفحه وجود دارند:
+
+- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): گره سبک اجماع در زبان TypeScript
+- [Helios](https://github.com/a16z/helios): گره سبک ترکیبی اجماع و اجرا در زبان Rust
+- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): گره سبک اجرا در زبان Go
+- [Nimbus](https://nimbus.guide/el-light-client.html): گره سبک اجماع در زبان Nim
+
+تا آنجا که میدانیم هیچ کدام از این موارد هنوز تولید نهایی نیستند.
+
+همچنین تلاش زیادی لازم است تا راههای دسترسی گرههای سبک به دادههای شبکۀ اتریوم بهبود داده شوند. در حال حاضر، فناوری گره سبک به درخواستهای RPC از گرههای کامل که از مدل سرور/ کلاینت استفاده میکنند، متکی است، اما در آینده، دادهها میتوانند به روشی غیرمتمرکز با استفاده از شبکههای اختصاصی مانند [Portal Network](https://www.ethportal.net/) درخواست شوند که دادههای گره سبک را با استفاده از پروتکل گاسیپ فرد به فرد تامین میکنند.
+
+سایر موارد موجود در [نقشۀ راه اتریوم](/roadmap/) مانند [درخت ورکل](/roadmap/verkle-trees/) و [بیوضعیت بودن](/roadmap/statelessness/) در نهایت میتوانند امنیت گرههای سبک را به امنیت یک گره کامل برسانند.
+
+## بیشتر بخوانید {#further-reading}
+
+- [Zsolt Felfodhi در کلاینتهای Geth light](https://www.youtube.com/watch?v=EPZeFXau-RE)
+- [Etan Kissling در شبکههای کلاینتهای سبک](https://www.youtube.com/watch?v=85MeiMA4dD8)
+- [Etan Kissling درباره کلاینتهای سبک بعد از ادغام](https://www.youtube.com/watch?v=ZHNrAXf3RDE)
+- [Piper Merriam: جاده پر پیچ و خم به سمت مشتریان سبک کاربردی](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md
new file mode 100644
index 00000000000..d98b0f7bc75
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md
@@ -0,0 +1,57 @@
+---
+title: معماری گره
+description: مقدمهای درباره نحوه سازماندهی گرههای اتریوم.
+lang: fa
+---
+
+یک گره اتریوم از دو کاربر تشکیل شده است: یک [کاربر اجرا](/developers/docs/nodes-and-clients/#execution-clients) و یک [کاربر اجماع](/developers/docs/nodes-and-clients/#consensus-clients).
+
+زمانی که اتریوم از [مکانیسم اثبات کار](/developers/docs/consensus-mechanisms/pow/) استفاده میکرد، یک کاربر اجرا برای اجرای یک گره کامل اتریوم کافی بود. اما، از زمان اجرای [مکانیسم اثبات سهام](/developers/docs/consensus-mechanisms/pow/)، کاربر اجرا میبایست در کنار نرمافزار دیگری به نام [کاربر اجماع ](/developers/docs/nodes-and-clients/#consensus-clients) استفاده شود.
+
+نمودار زیر رابطۀ بین دو کاربر اتریوم را نشان میدهد. هر یک از این دو کاربر به شبکههای همتا به همتای (P2P) مخصوص خود متصل میشوند. دلیل نیاز به شبکههای همتا به همتای جداگانه این است که: کاربرهای اجرا تراکنشها را از طریق شبکۀ همتا به همتای خود شایعه میکنند که آنها را قادر میسازد استخر تراکنشهای محلی خود را مدیریت کنند، در حالی که کاربرهای اجماع، بلوکها را از طریق شبکۀ همتا به همتا شایعه میکنند، که امکان اجماع و رشد زنجیره را فراهم میکند.
+
+![](node-architecture-text-background.png)
+
+برای اینکه این ساختار دوکاربری بتواند کار کند، کاربرهای اجماع باید دستهای از تراکنشها را به کاربر اجرا منتقل کنند. اجرای تراکنشها به صورت محلی اینگونه است که کاربر تایید میکند تراکنشها هیچ یک از قوانین اتریوم را نقض نمیکنند و بهروزرسانی پیشنهادی برای حالت اتریوم صحیح است. به همین ترتیب، هنگامی که گره به عنوان تولیدکنندۀ بلوک برگزیده میشود، کاربر اجماع باید بتواند دستهای از تراکنشها را از Geth درخواست کند تا در بلوک جدید گنجانده شود و آنها را برای بهروزرسانی حالت کل شبکه اجرا کند. این ارتباط بینِ کاربری توسط یک اتصال RPC محلی با استفاده از [موتور API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) اداره میشود.
+
+## کاربر اجرا چه میکند؟ {#execution-client}
+
+کاربر اجرا مسئول رسیدگی به تراکنش، شایعه تراکنش، مدیریت حالت و پشتیبانی از ماشین مجازی اتریوم ([EVM](/developers/docs/evm/)) است. ولی مسئولیتی در قبال ساخت بلوک، شایعه بلوک یا مدیریت منطق اجماع **ندارد**. این موارد، در حیطۀ اختیارات کاربر اجماع است.
+
+کاربر اجرا، پیلودهای اجرا را ایجاد میکند که شامل فهرست تراکنشها، آزمایش حالت بهروزشده و سایر دادههای مربوط به اجرا میشود. کاربرهای اجماع شامل پیلود اجرا در هر بلوک است. کاربر اجرا همچنین مسئول اجرای مجدد تراکنشها در بلوکهای جدید به منظور اطمینان از معتبر بودن آنها است. اجرای تراکنشها بر روی کامپیوتر تعبیهشدۀ کاربر اجرا به نام [ماشین مجازی اتریوم (EVM)](/developers/docs/evm) انجام میشود.
+
+کاربر اجرا همچنین از طریق [روشهای RPC](/developers/docs/apis/json-rpc) یک رابط کاربری برای اتریوم فراهم میکند که کاربران را قادر میسازد از بلاکچین اتریوم درخواست اطلاعات کنند، تراکنشها را ارسال کنند و قراردادهای هوشمند را به شیوهای مؤثر به کار گیرند. معمولا تماسهای RPC توسط کتابخانهای مانند [Web3js](https://docs.web3js.org/) یا [Web3py](https://web3py.readthedocs.io/en/v5/) یا یک رابط کاربری مانند کیف پول مرورگر انجام میشود.
+
+به طور خلاصه، کاربر اجرا عبارت است از:
+
+- یک دروازۀ کاربری به اتریوم
+- خانۀ ماشین مجازی اتریوم، استخر تراکنش و حالت اتریوم.
+
+## کاربر اجماع چه میکند؟ {#consensus-client}
+
+کاربر اجماع با تمام منطقی سر و کار دارد که یک گره را قادر میسازد با شبکۀ اتریوم همگام بماند. این موارد شامل دریافت بلوکها از همتایان و اجرای یک الگوریتم انتخاب فورک است تا اطمینان حاصل شود گره همواره زنجیرهای با بیشترین انباشت گواه را دنبال میکند (وزندهیشده توسط ترازهای مؤثر اعتبارسنج). مشابه کاربر اجرا، کاربرهای اجماع نیز شبکۀ همتا به همتای خود را دارند که از طریق آن بلوکها و تصدیقها را به اشتراک میگذارند.
+
+کاربر اجماع در تایید یا پیشنهاد بلوکها شرکت نمیکند - این کار توسط یک اعتبارسنج انجام میشود که یک افزونۀ اختیاری برای کاربر اجماع محسوب میشود. یک کاربر اجماع بدون یک اعتبارسنج تنها با سر زنجیره همگام میشود و به گره اجازۀ همگامسازی میدهد. این امر به کاربران امکان میدهد با استفاده از کاربر اجرای خود با اتریوم تراکنش کنند با این اطمینان که در زنجیرۀ صحیح قرار دارند.
+
+## اعتبارسنج ها {#validators}
+
+اپراتورهای گره میتوانند با واریز 32 اتریوم در قرارداد سپرده، یک اعتبارسنج را به کاربر اجماع خود اضافه کنند. کاربر اعتبارسنج با کاربر اجماع همبسته است و میتواند در هر زمان به یک گره اضافه شود. اعتبارسنج، تصدیقها و پیشنهادهای بلوک را مدیریت میکند. آنها یک گره را قادر میسازند تا از طریق جریمه یا اسلشینگ به جمعآوری پاداش بپردازد یا ETH از دست بدهد. اجرای نرمافزار اعتبارسنج همچنین باعث انتخاب یک گره واجد شرایط برای پیشنهاد یک بلوک جدید میشود.
+
+[در مورد سهام گذاری بیشتر بخوانید](/staking/).
+
+## مقایسۀ اجزای گره {#node-comparison}
+
+| کاربر اجرا | کاربر اجماع | اعتبارسنج |
+| --------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------ |
+| تراکنشهای را از طریق شبکۀ همتا به همتای خود شایعه میکند | از طریق شبکۀ همتا به همتای خود، بلوکها و تصدیقها را شایعه میکند | بلوکها را پیشنهاد میکند |
+| تراکنشها را اجرا/ بازاجرا میکند | الگوریتم انتخاب فورک را اجرا میکند | پاداشها/جریمهها را میگیرد |
+| تغییرات حالت ورودی را تایید میکند | سر زنجیره را پیگیری میکند | تصدیقها را میسازد |
+| تلاشهای حالت و رسیدها را مدیریت میکند | حالت بیکن را مدیریت میکند (شامل اطلاعات اجماع و اجرا) | برای سهام گذاری شدن به 32 اتریوم نیاز دارد |
+| پیلود اجرا را ایجاد میکند | تصادفی بودن انباشتهشده در RANDAO را ردیابی میکند | قابل اسلش شدن است |
+| JSON-RPC API را برای تعامل با اتریوم در معرض قرار میدهد | توجیه و نهایی شدن را پیگیری میکند | |
+
+## بیشتر بخوانید {#further-reading}
+
+- [اثبات سهام](/developers/docs/consensus-mechanisms/pos)
+- [پیشنهاد بلوک](/developers/docs/consensus-mechanisms/pos/block-proposal)
+- [پاداشها و جریمههای اعتبارسنج](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
index 8266a1ef556..603008296b5 100644
--- a/public/content/translations/fa/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
@@ -13,17 +13,25 @@ sidebarDepth: 2
اگر از قبل درک درستی از گرهها و کلاینتها ندارید، به [گرهها و کلاینتها](/developers/docs/nodes-and-clients/) مراجعه کنید.
+## سهام گذاران {#stakoooooooooooooors}
+
+سهامداران انفرادی به جای اتکا به ارائه دهندگان شخص ثالث، باید زیرساخت خود را اجرا کنند. این به معنای اجرای یک کلاینت اجرا همراه با یک کلاینت اجماع است. قبل از [ادغام](/roadmap/merge)، این امکان وجود داشت که فقط یک کلاینت اجماع اجرا شود و از یک ارائه دهنده متمرکز برای داده های اجرا استفاده شود. این دیگر امکانپذیر نیست - یک سهام گذار انفرادی باید هر دو مشتری را اجرا کند. با این حال، خدماتی برای تسهیل این فرآیند وجود دارد.
+
+[در مورد اجرای یک گره بیشتر بخوانید](/developers/docs/nodes-and-clients/run-a-node/).
+
+خدماتی که در این صفحه توضیح داده شده است برای گره های بدون شرط بندی است.
+
## سرویسهای گره چگونه کار میکنند؟ {#how-do-node-services-work}
-ارائهدهندگان خدمات گره، کلاینتهای گرهی توزیع شده را در پشتصحنه برای شما اجرا میکنند، بنابراین نیازی ندارید که خودتان آنها را انجام دهید.
+ارائهدهندگان خدمات گره، کلاینتهای گره توزیع شده را در پشتصحنه برای شما اجرا میکنند، بنابراین نیازی ندارید که خودتان آنها را انجام دهید.
این سرویسها معمولاً یک کلید API ارائه میکنند که میتوانید از آن برای نوشتن و خواندن از زنجیرهی بلوکی استفاده کنید. آنها اغلب علاوه بر شبکهی اصلی به [شبکههای تست اتریوم](/developers/docs/networks/#ethereum-testnets) نیز دسترسی دارند.
-برخی از سرویسها گرهی اختصاصی خودشان را به شما ارائه میدهند و آنها را برای شما مدیریت میکنند، در حالی که برخی دیگر از متعادلکنندههای بار برای توزیع فعالیت در گرهها استفاده میکنند.
+برخی از سرویسها، گره اختصاصی خودشان را به شما ارائه میدهند و آنها را برای شما مدیریت میکنند، در حالی که برخی دیگر از متعادلکنندههای بار برای توزیع فعالیت در گرهها استفاده میکنند.
-ادغام با اغلب سرویسهای گره بهشدت آسان است، که معمولاً شامل یک خط تغییر در کد خود برای تعویض گرهای که خودتان میزبانی میکنید یا حتی جابجایی آنها بین خودشان میشود.
+ادغام با اغلب سرویسهای گره بهشدت آسان است، که معمولاً شامل یک خط تغییر در کد خود برای تعویض گرهی که خودتان میزبانی میکنید یا حتی جابجایی آنها بین خودشان میشود.
-اغلب اوقات سرویسهای گره انواع مختلفی از [کلاینت های گره](/developers/docs/nodes-and-clients/#execution-clients) و [نوع ها](/developers/docs/nodes-and-clients/#node-types) را اجرا میکنند که به شما این امکان را میدهد تا علاوه بر روشهای خاص کلاینت در یک وب سرویس به گرههای کامل و بایگانیشده نیز دسترسی داشته باشید.
+سرویسهای گره اغلب [کلاینتهای گره](/developers/docs/nodes-and-clients/#execution-clients) و [انواع گره](/developers/docs/nodes-and-clients/#node-types) گوناگونی را اجرا میکنند که به شما این امکان را میدهد علاوه بر روشهای خاص کلاینت در یک API به گرههای کامل و بایگانیشده نیز دسترسی داشته باشید.
خاطرنشان میشود که سرویسهای گرهْ کلیدهای خصوصی یا اطلاعات شما را نباید و نمیتوانند ذخیره کنند.
@@ -31,133 +39,261 @@ sidebarDepth: 2
مزیت اصلی استفاده از سرویس گره این است که نیازی به صرف زمان مهندسی برای نگهداری و مدیریت گرهها ندارید. این کار به شما امکان میدهد بهجای نگرانی در مورد تعمیر و نگهداری زیرساخت، روی ساخت محصول خود تمرکز کنید.
-اجرای گرههای شخصی شما از ذخیرهسازی تا پهنای باند و زمان مهندسی ارزشمند شما، میتواند بسیار هزینهبر باشد. Things like spinning up more nodes when scaling, upgrading nodes to the latest versions, and ensuring state consistency, can distract from building and spending resources on your desired web3 product.
+اجرای گرههای شخصی شما از ذخیرهسازی تا پهنای باند و زمان مهندسی ارزشمند شما، میتواند بسیار هزینهبر باشد. مواردی مانند چرخش تعداد بیشتری گره هنگام مقیاسبندی، ارتقای گرهها به آخرین نسخهها و اطمینان از ثبات وضعیت، میتواند حواس را از ساختن و صرف منابع روی محصول Web3 موردنظر شما منحرف کند.
## معایب استفاده از یک سرویس گره چیست؟ {#cons-of-using-a-node-service}
با استفاده از یک سرویس گره، وضعیت زیرساختی محصول خود را متمرکز میکنید. به همین دلیل، پروژههایی که در آنها تمرکززدایی از اهمیت بالایی برخوردار است، ممکن است گرههای خود میزبان را به برونسپاری به طرف ثالث ترجیح دهند.
-درباره [مزایای اجرای گرهی خودتان](/developers/docs/nodes-and-clients/#benefits-to-you) بیشتر بخوانید.
+درباره [مزایای اجرای گره خودتان](/developers/docs/nodes-and-clients/#benefits-to-you) بیشتر بخوانید.
## سرویسهای گره محبوب {#popular-node-services}
-در اینجا فهرستی از محبوب ترین ارائهدهندگان گرهی اتریوم آورده شده است، بهراحتی میتوانید مواردی که درج نشدهاند را اضافه کنید! هر سرویس گره علاوه بر سطوح رایگان یا پولی، مزایا و ویژگیهای مختلفی را ارائه میکند، شما باید قبل از تصمیمگیری، بررسی کنید که کدامیک به بهترین شکل با نیازهای شما مطابقت دارند.
+در اینجا فهرستی از محبوب ترین ارائهدهندگان گره اتریوم آورده شده است، بهراحتی میتوانید مواردی که درج نشدهاند را اضافه کنید! هر سرویس گره علاوه بر سطوح رایگان یا پولی، مزایا و ویژگیهای مختلفی را ارائه میکند، شما باید قبل از تصمیمگیری، بررسی کنید که کدامیک به بهترین شکل با نیازهای شما مطابقت دارند.
-- [**Alchemy**](https://www.alchemy.com/)
+- [**شیمی**](https://alchemy.com/)
- [مستندات](https://docs.alchemyapi.io/)
- ویژگیها
- - دارای سطح رایگان
- - مقیاسپذیری در حین استفاده
- - دادههای آرشیوی رایگان
- - ابزار تجزیه و تحلیل
- - پیشخان
- - نقاط پایانی منحصربهفرد وب سرویس
- - قلابهای وب
- - پشتیبانی مستقیم
+ - دارای بزرگترین سطح کاربری رایگان با 300 میلیون واحد محاسباتی در ماه (حدود 30 میلیون درخواست getLatestBlock)
+ - پشتیبانی چند زنجیرهای برای Polygon، Starknet، Optimism، Arbitrum
+ - قدرتبخشی به حدود 70% بزرگترین dappهای اتریوم و حجم تراکنش دیفای
+ - هشدارهای قلابهای وب لحظهای از طریق Alchemy Notify
+ - بهترین پشتیبانی و اطمینانپذیری / ثبات در این سطح
+ - NFT API متعلق به Alchemy
+ - داشبورد با Request Explorer، Mempool Watcher و Composer
+ - دسترسی به فاست شبکهی تست یکپارچه
+ - انجمن سازنده Active Discord با 18 هزار کاربر
+
+- [**همه آن نود**](https://allthatnode.com/)
+ - [مستندات](https://docs.allthatnode.com/)
+ - ویژگیها
+ - 50000 درخواست در روز با ردیف آزاد
+ - پشتیبانی از بیش از 40 پروتکل
+ - از JSON-RPC (EVM, Tendermint) و REST و APIهای وبسوکت پشتیبانی میشود
+ - دسترسی نامحدود به داده های آرشیو
+ - پشتیبانی فنی 24/7 و آپتایم 99.9 درصد
+ - فاست در چند زنجیر موجود است
+ - دسترسی نامحدود به اندپوینت با تعداد نامحدود کلیدهای API
+ - پشتیبانی از ردیابی/دیباگ API
+ - بهروزرسانیهای خودکار
+
+- [**بلاک چین مدیریت شده آمازون**](https://aws.amazon.com/managed-blockchain/)
+ - [مستندات](https://aws.amazon.com/managed-blockchain/resources/)
+ - ویژگیها
+ - گره های کاملاً مدیریت شده اتریوم
+ - موجود در شش منطقه جغرافیایی
+ - JSON-RPC از طریق HTTP و WebSocket های امن
+ - پشتیبانی از 3 زنجیره
+ - SLAها، پشتیبانی 24/7 از AWS
+ - Go-ethereum و Lighthouse
+
- [**Ankr**](https://www.ankr.com/)
- [مستندات](https://docs.ankr.com/)
- ویژگیها
- پروتکل Ankr - دسترسی به نقاط پایانی وب سرویس RPC عمومی را برای بیش از 8 زنجیره باز میکند
- تعادل بار و نظارت بر سلامت گره برای یک گذرگاه سریع و قابلاعتماد به نزدیکترین گره موجود
- سطح ممتاز که نقطه پایانی WSS و محدودیت نرخ بدون سقف را فعال میکند
- - استقرار گرهی کامل و اعتبارسنج با یک کلیک برای بیش از 40 زنجیره
+ - استقرار گره کامل و اعتبارسنج با یک کلیک برای بیش از 40 زنجیره
- مقیاسپذیری دلخواه
- - ابزار تجزیه و تحلیل
- - پیشخان
+ - ابزارهای تحلیل
+ - داشبورد
- نقاط پایانی RPC، HTTPS و WSS
- پشتیبانی مستقیم
+
+- [**انفجار**](https://blastapi.io/)
+ - [مستندات](https://docs.blastapi.io/)
+ - ویژگیها
+ - پشتیبانی RPC و WSS
+ - میزبانی از گره در چندین منطقه
+ - زیرساخت غیرمتمرکز
+ - API عمومی
+ - طرح رایگان اختصاصی
+ - پشتیبانی از چند زنجیره (بیش از 17 بلاکچین)
+ - نودهای آرشیوی
+ - پشتیبانی 24/7 در Discord
+ - مانیتورینگ و هشداردهی 24/7
+ - SLA کلی در سطح 99.9 درصد
+ - پرداخت با رمزارز
+
- [**BlockDaemon**](https://blockdaemon.com/)
- [مستندات](https://ubiquity.docs.blockdaemon.com/)
- مزایا
- - پیشخان
- - پایهی گرهمبنا
+ - داشبورد
+ - بر اساس پایه گره
- تجزیه و تحلیل
+
+- [**BlockPI**](https://blockpi.io/)
+ - [مستندات](https://docs.blockpi.io/)
+ - ویژگیها
+ - قوی & ساختار گره توزیع شده
+ - حداکثر 40 نقطه پایانی HTTPS و WSS
+ - بسته ثبتنام رایگان و بسته ماهانه
+ - روش ردیابی + پشتیبانی از دادههای آرشیو
+ - بستهها تا 90 روز اعتبار دارند
+ - برنامهریزی سفارشی و پرداخت دلخواه
+ - پرداخت با رمزارز
+ - پشتیبانی مستقیم & پشتیبانی فنی
+
+- [**Chainbase**](https://www.chainbase.com/)
+ - [مستندات](https://docs.chainbase.com)
+ - ویژگیها
+ - سرویس RPC بسیار در دسترس، سریع و مقیاسپذیر
+ - پشتیبانی از چندزنجیره
+ - تعرفههای رایگان
+ - داشبورد کاربرپسند
+ - خدمات داده بلاک چین را فراتر از RPC ارائه میدهد
+
- [**Chainstack**](https://chainstack.com/)
- [مستندات](https://docs.chainstack.com/)
- ویژگیها
- گرههای اشتراکی رایگان
- گرههای اشتراکی آرشیو
- پشتیبانی از GraphQL
- - نقاط پایانی RPC، HTTPS و WSS
+ - نقاط پایانی RPC و WSS
- گرههای کامل و بایگانی اختصاصی
- - زمان همگامسازی سریع برای بکارگیریهای اختصاصی
- - اتصال به سرویسهای ابری شما
+ - همگامسازی سریع برای استقرار اختصاصی
+ - اتصال به سرویسهای ابری خود
- هزینهی ساعتی
- پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
+
+- [**DataHub**](https://datahub.figment.io)
+ - [اسناد](https://docs.figment.io/)
+ - ویژگیها
+ - گزینهی سطح کاربری رایگان با 3,000,000 درخواست در ماه
+ - نقاط پایانی RPC و WSS
+ - گرههای کامل و بایگانی اختصاصی
+ - مقیاسبندی خودکار (تخفیف حجمی)
+ - دادههای بایگانیشدهی رایگان
+ - تجزیه و تحلیل سرویس
+ - داشبورد
+ - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
+ - پرداخت با رمزارز (سازمانی)
+
+- [**DRPC**](https://drpc.org/)
+ - [مستندات](https://docs.drpc.org/)
+ - ویژگیها
+ - گرههای RPC غیرمتمرکز
+ - بیش از 15 ارائه دهنده گره
+ - تعادل گره
+ - واحدهای محاسباتی نامحدود ماهانه به صورت رایگان
+ - تایید دادهها
+ - نقاط پایانی سفارشی
+ - نقاط پایانی HTTP و WSS
+ - کلیدهای نامحدود (ردیف رایگان و پولی)
+ - گزینههای بازگشتی یا فالبک انعطافپذیر
+ - [نقطه پایانی عمومی](https://eth.drpc.org)
+ - گرههای بایگانیشدهی اشتراکی رایگان
+
- [**GetBlock**](https://getblock.io/)
- [مستندات](https://getblock.io/docs/get-started/authentication-with-api-key/)
- ویژگیها
- - دسترسی به بیش از 40 گرهی زنجیرهی بلوکی
+ - دسترسی به بیش از 40 گره زنجیره بلوکی
- 40 هزار درخواست رایگان روزانه
- - کلیدهای وب سرویس نامحدود
- - سرعت اتصال بالا 1 گیگابایت بر ثانیه
+ - کلیدهای API نامحدود
+ - سرعت اتصال بالا به میزان 1 گیگابایت بر ثانیه
- ردیابی+آرشیو
- تجزیه و تحلیل پیشرفته
- بهروزرسانیهای خودکار
- پشتیبانی فنی
+
- [**InfStones**](https://infstones.com/)
- ویژگیها
- - دارای سطح رایگان
- - مقیاسپذیری در حین استفاده
+ - گزینه ردیف رایگان
+ - مقیاسپذیری دلخواه
- تجزیه و تحلیل
- - پیشخان
- - نقاط پایانی منحصربهفرد وب سرویس
+ - داشبورد
+ - نقاط پایانی منحصربهفرد API
- گرههای کامل اختصاصی
- - زمان همگامسازی سریع برای بکارگیریهای اختصاصی
+ - همگامسازی سریع برای استقرار اختصاصی
- پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
- - دسترسی به بیش از 50 گره زنجیرهی بلوکی
+ - دسترسی به بیش از 50 گره زنجیره بلوکی
+
- [**Infura**](https://infura.io/)
- [مستندات](https://infura.io/docs)
- ویژگیها
- - دارای سطح رایگان
- - مقیاسپذیری در حین استفاده
- - دادههای آرشیوی پولی
+ - گزینه ردیف رایگان
+ - مقیاسپذیری دلخواه
+ - دادههای بایگانیشدهی پولی
- پشتیبانی مستقیم
- - پیشخان
+ - داشبورد
+
- [**Kaleido**](https://kaleido.io/)
- [مستندات](https://docs.kaleido.io/)
+ - ویژگیها
+ - ردیف رایگان برای شروع کار
+ - استقرار گره اتریوم با یک کلیک
+ - کلاینتها و الگوریتمهای قابل تنظیم (Geth، Quorum و Besu || PoA، IBFT و Raft)
+ - بیش از 500 API اداری و خدماتی
+ - رابط RESTful برای ارسال تراکنش اتریوم (با پشتیبانی Apache Kafka)
+ - جریانهای خروجی برای ارائه رویداد (با پشتیبانی Apache Kafka)
+ - مجموعهای عمیق از خدمات «خارج زنجیره» و فرعی (مانند حملونقل پیامهای رمزگذاریشدهی دوجانبه)
+ - نصب راحت و سریع روی شبکه با کنترل دسترسی مبتنی بر نقش و حاکمیت
+ - مدیریت پیشرفتهی کاربر هم برای مدیران و هم برای کاربران نهایی
+ - زیرساخت بسیار مقیاس پذیر، تابآورتر و در سطح سازمانی
+ - مدیریت کلید خصوصی Cloud HSM
+ - اتصال شبکهی اصلی اتریوم
+ - گواهینامههای ISO 27k و SOC 2، نوع 2
+ - پیکربندی پویای زمان اجرا (بهعنوان مثال افزودن ادغامهای ابری، تغییر ورودی گرهها و غیره)
+ - پشتیبانی از ارکستراسیونهای چند ابری، چند منطقهای و ترکیبی استقرار
+ - قیمتگذاری ساعتی ساده مبتنی بر SaaS
+ - SLAها و پشتیبانی شبانهروزی در تمام ایام هفته
+
+- [**شبکه لاوا (Lava)**](https://www.lavanet.xyz/)
+ - [مستندات](https://docs.lavanet.xyz/)
- ویژگیها
- - Free startier tier
- - One-click Ethereum node deployment
- - Customizable clients and algorithms (Geth, Quorum & Besu || PoA, IBFT & Raft)
- - 500+ administrative and service APIs
- - RESTful interface for Ethereum transaction submission (Apache Kafka backed)
- - Outbound streams for event delivery (Apache Kafka backed)
- - Deep collection of "off-chain" and ancillary services (e.g. bilateral encrypted messaging transport)
- - Straightforward network onboarding with governance and role-based access control
- - Sophisticated user management for both administrators and end users
- - Highly scalable, resilient, enterprise-grade infrastructure
- - Cloud HSM private key management
- - Ethereum Mainnet Tethering
- - ISO 27k and SOC 2, Type 2 certifications
- - Dynamic runtime configuration (e.g. adding cloud integrations, altering node ingresses, etc.)
- - Support for multi-cloud, multi-region and hybrid deployment orchestrations
- - Simple hourly SaaS-based pricing
- - SLAs and 24x7 support
+ - استفاده رایگان از شبکهی تست
+ - افزونگی غیرمتمرکز برای آپ تایم بالا
+ - متن باز
+ - SDK کاملا غیرمتمرکز
+ - ادغام Ethers.js
+ - رابط مدیریت پروژه بصری
+ - یکپارچگی داده مبتنی بر اجماع
+ - پشتیبانی چند زنجیرهای یا مالتی چین
+
- [**Moralis**](https://moralis.io/)
- [مستندات](https://docs.moralis.io/)
- ویژگیها
- گرههای اشتراکی رایگان
- - گرههای آرشیو اشتراکی رایگان
+ - گرههای بایگانیشدهی اشتراکی رایگان
- تمرکز بر حفظ حریم خصوصی (سیاست عدم حفظ سوابق کار)
- پشتیبانی از زنجیرهی متقاطع
- - مقیاسپذیری در حین استفاده
- - پیشخان
+ - مقیاسپذیری دلخواه
+ - داشبورد
- SDK اتریوم منحصربهفرد
- - نقاط پایانی منحصربهفرد وب سرویس
+ - نقاط پایانی منحصربهفرد API
- پشتیبانی فنی مستقیم
-- [**Pocket Network**](https://www.pokt.network/)
- - [مستندات](https://docs.pokt.network/home/)
+
+- [**مگانود نودرئال**](https://nodereal.io/)
+ - [مستندات](https://docs.nodereal.io/nodereal/meganode/introduction)
- ویژگیها
+ - خدمات RPC ایپیآی قابل اعتماد، سریع و مقیاسپذیر
+ - API پیشرفته برای توسعهدهندگان Web3
+ - پشتیبانی از چندزنجیره
+ - شروع به استفاده به صورت رایگان
+
+- [**NOWNodes**](https://nownodes.io/)
+ - [اسناد](https://documenter.getpostman.com/view/13630829/TVmFkLwy)
+ - ویژگیها
+ - دسترسی به بیش از 50 گره زنجیره بلوکی
+ - کلید API رایگان
+ - جستجوگرهای بلوک
+ - زمان پاسخ API ⩽ 1 ثانیه
+ - تیم پشتیبانی شبانهروزی در تمام ایام هفته
+ - مدیر حسابهای شخصی
+ - گرههای مشترک، بایگانیشده، پشتیبانی و اختصاصی
+
+- [**شبکهی Pocket**](https://www.pokt.network/)
+ - [اسناد](https://docs.pokt.network/home/)
+ - ویژگیها
- پروتکل و بازار RPC غیرمتمرکز
- 1 میلیون درخواست در روز در سطح رایگان (به ازای هر نقطهی پایانی، حداکثر 2)
- [نقاط پایانی عمومی](https://docs.pokt.network/developers/public-endpoints)
- - برنامهی +Pre-Stake (اگر به بیش از 1 میلیون درخواست در روز نیاز دارید)
+ - برنامهی +Pre-Stake (در صورت نیاز به بیش از 1 میلیون درخواست در روز)
- پشتیبانی از بیش از 15 زنجیرهی بلوکی
- بیش از 6400 گره که برای خدمترسانی به برنامههای کاربردی POKT کسب میکنند
- - گرهی آرشیو، گرهی آرشیو با ردیابی و پشتیبانی از گرهی شبکهی تست
+ - گرهی بایگانیشده، گرهی بایگانیشده با ردیابی و پشتیبانی از گرهی شبکهی تست
- تنوع در کلاینت گره شبکهی اصلی اتریوم
- - هیچ نقطه شکستی وجود ندارد
+ - هیچ نقطهی شکستی وجود ندارد
- زمان خاموشی صفر
- اقتصاد توکنی نزدیک به صفر و مقرونبهصرفه (برای پهنای باند شبکه، یک بار POKT را سهامگذاری کنید)
- بدون هزینههای ماهانه، زیرساختهای خود را به یک دارایی تبدیل کنید
@@ -165,51 +301,117 @@ sidebarDepth: 2
- تعداد درخواستها در روز و تعداد گرهها را در هر ساعت بهطور بینهایت مقیاسپذیر کنید
- خصوصیترین و مقاومترین گزینه در برابر سانسور
- پشتیبانی عملی از توسعهدهندگان
- - پیشخان و تجزیه و تحلیل [پورتال Pocket](https://bit.ly/ETHorg_POKTportal)
-- [**QuikNode**](https://www.quiknode.io/)
- - ویژگیها
- - ۷ - روز امتحان رایگان
- - پشتیبانی متنوع
- - قلابهای وب
- - پیشخان
- - تجزیه و تحلیل
+ - داشبورد و تجزیه و تحلیل [پورتال Pocket](https://bit.ly/ETHorg_POKTportal)
+
+- [**QuickNode**](https://www.quicknode.com)
+ - [اسناد](https://www.quicknode.com/docs/)
+ - ویژگیها
+ - پشتیبانی فنی شبانهروزی در تمام ایام هفته و جامعه توسعهدهندگان در Discord
+ - شبکهای دارای تعادل جغرافیایی، چند ابری/فلزی، با تأخیر کم
+ - پشتیبانی چند زنجیرهای (Optimism، Arbitrum، Polygon + 11 مورد دیگر)
+ - لایههای میانی برای سرعت و پایداری (مسیریابی تماس، حافظهی پنهان، نمایهسازی)
+ - نظارت بر قرارداد هوشمند از طریق Webhooks
+ - داشبورد بصری، بستهی تجزیه و تحلیل، نویسندهی RPC
+ - ویژگیهای امنیتی پیشرفته (JWY، ماسک کردن، قرار دادن در فهرست سفید)
+ - API دادهها و تجزیه و تحلیل NFT
+ - [دارای گواهینامه SOC2](https://www.quicknode.com/security)
+ - مناسب برای اشخاص مختلف، از توسعهدهندگان گرفته تا سازمانها
+
- [**Rivet**](https://rivet.cloud/)
- - [مستندات](https://rivet.readthedocs.io/en/latest/)
- - ویژگیها
- - دارای سطح رایگان
- - مقیاسپذیری در حین استفاده
+ - [اسناد](https://rivet.readthedocs.io/en/latest/)
+ - ویژگیها
+ - گزینه ردیف رایگان
+ - مقیاسپذیری دلخواه
+
+- [**SenseiNode**](https://senseinode.com)
+ - [اسناد](https://docs.senseinode.com/)
+ - ویژگیها
+ - گرههای اختصاصی و اشتراکی
+ - داشبورد
+ - میزبانی خاموش AWS در چندین ارائه دهنده میزبانی در مکان های مختلف در آمریکای لاتین
+ - کلاینتهای Prysm و Lighthouse
+
- [**SettleMint**](https://console.settlemint.com/)
- - [مستندات](https://docs.settlemint.com/)
+ - [اسناد](https://docs.settlemint.com/)
- ویژگیها
- دورهی آزمایشی رایگان
- - مقیاسپذیری در حین استفاده
+ - مقیاسپذیری دلخواه
- پشتیبانی از GraphQL
- - نقاط پایانی RPC، HTTPS و WSS
+ - نقاط پایانی RPC و WSS
- گرههای کامل اختصاصی
- اتصال به سرویسهای ابری خود
- - ابزار تجزیه و تحلیل
- - پیشخان
+ - ابزارهای تحلیل
+ - داشبورد
- هزینهی ساعتی
- پشتیبانی مستقیم
+
+- [**Tenderly**](https://tenderly.co/web3-gateway)
+ - [اسناد](https://docs.tenderly.co/web3-gateway/web3-gateway)
+ - ویژگیها
+ - بخش رایگان شامل 25 میلیون واحد مناقصه در ماه
+ - دسترسی رایگان به دادههای تاریخی
+ - خوانایی بخشهای سنگین تا 8 برابر سریعتر
+ - دسترسی به خواندن 100٪ ثابت
+ - نقاط پایانی JSON-RPC
+ - سازنده درخواست RPC و پیش نمایش درخواست مبتنی بر رابط کاربری
+ - کاملاً با ابزارهای توسعه، اشکالزدایی یا دیباگ کردن و تست تندرلی یکپارچه شده است
+ - شبیهسازی تراکنشها
+ - تجزیه و تحلیل و فیلتر کردن استفاده
+ - دسترسی آسان به مدیریت کلید
+ - پشتیبانی مهندسی اختصاصی از طریق چت، ایمیل و دیسکورد
+
+- [**توکن ویو**](https://services.tokenview.io/)
+ - [اسناد](https://services.tokenview.io/docs?type=nodeService)
+ - ویژگیها
+ - پشتیبانی فنی شبانهروزی در تمام ایام هفته & و جامعه توسعهدهندگان در Telegram
+ - پشتیبانی از چند زنجیره (بیت کوین، اتریوم، ترون، زنجیره هوشمند بایننس، اتریوم کلاسیک)
+ - هر دو نقطه پایانی RPC و WSS برای استفاده باز هستند
+ - دسترسی نامحدود به داده های آرشیو API
+ - داشبورد با Request Explorer و Mempool Watcher
+ - ایپیآی دیتا انافتی (NFT data API) و Webhook اطلاع رسانی میکنند
+ - پرداخت با رمزارز
+ - پشتیبانی خارجی برای الزامات رفتاری اضافی
+
- [**Watchdata**](https://watchdata.io/)
- - [مستندات](https://docs.watchdata.io/)
+ - [اسناد](https://docs.watchdata.io/)
+ - ویژگیها
+ - اطمینانپذیری دادهها
+ - اتصال بدون وقفه بدون توقف
+ - خودکارسازی فرایند
+ - تعرفههای رایگان
+ - سقف بالا برای امکانات گوناگون که برای هر کاربری مناسب است
+ - پشتیبانی از گرههای مختلف
+ - مقیاسپذیری منابع
+ - سرعت پردازش بالا
+
+- [**ZMOK**](https://zmok.io/)
+ - [اسناد](https://docs.zmok.io/)
- ویژگیها
- - Data reliability
- - Uninterrupted connection with no downtime
- - Process automation
- - Free tariffs
- - High limits that suit any user
- - Support for various nodes
- - Resource scaling
- - High processing speeds
+ - پیشدستی بهعنوان سرویس
+ - استخر حافظهی معاملات جهانی با روشهای جستجو/فیلتر
+ - هزینهی TX نامحدود و گاز بینهایت برای ارسال تراکنشها
+ - دریافت بلوک جدید و خواندن زنجیرهی بلوکی به سریعترین شکل ممکن
+ - تضمین بهترین قیمت برای هر فراخوانی API
+
+- [**Zeeve**](https://www.zeeve.io/)
+ - [اسناد](https://www.zeeve.io/docs/)
+ - ویژگیها
+ - پلتفرم اتوماسیون بدون کد درجه سازمانی که استقرار، نظارت و مدیریت گره ها و شبکه های بلاکچین را ارائه می دهد
+ - بیش از 30 پروتکل پشتیبانی شده & یکپارچهسازی، و افزودن موارد دیگر
+ - خدمات زیرساخت Web3 با ارزش افزوده مانند ذخیرهسازی غیرمتمرکز، هویت غیرمتمرکز و APIهای داده دفتر کل بلاکچین برای موارد استفاده در دنیای واقعی
+ - پشتیبانی 24 ساعته و نظارت فعال، سلامت گره ها را همیشه تضمین می کند.
+ - نقاط پایانی RPC اقدام به ارائه دسترسی تأیید شده به API ها، مدیریت بدون دردسر با داشبورد و تجزیه و تحلیل بصری میکنند.
+ - هم سرویس ابری مدیریت شده را ارائه می دهد و هم گزینه های ابری خود را برای انتخاب می آورد و از همه ارائه دهندگان ابر اصلی مانند AWS و Azure و Google Cloud و Digital Ocean و سرویس محلی پشتیبانی میکند.
+ - ما هر بار از مسیریابی هوشمند برای رسیدن به نزدیکترین گره به کاربر شما استفاده می کنیم
+
## بیشتر بخوانید {#further-reading}
-- [فهرست خدمات گره اتریوم](https://ethereumnodes.com/)
+- [فهرست خدمات گرهی اتریوم](https://ethereumnodes.com/)
## موضوعات مرتبط {#related-topics}
-- [گرهها و کلاینتها](/developers/docs/nodes-and-clients/)
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
## آموزشهای مرتبط {#related-tutorials}
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/run-a-node/index.md
index a39b8e4a4c5..f01d54b0da4 100644
--- a/public/content/translations/fa/developers/docs/nodes-and-clients/run-a-node/index.md
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/run-a-node/index.md
@@ -7,27 +7,35 @@ sidebarDepth: 2
اجرای گرهی خودتان مزایای متنوعی برای شما دارد، امکانات جدیدی را در اختیارتان قرار میدهد و به پشتیبانی از اکوسیستم کمک میکند. این صفحه شما را برای چرخاندن گرهی خودتان و ایفای نقش برای اعتبارسنجی تراکنشهای اتریوم راهنمایی میکند.
+توجه داشته باشید که پس از [ادغام](/roadmap/merge)، دو کلاینت برای اجرای یک گره اتریوم مورد نیاز است. یک کلاینت **لایه اجرا (EL)** و یک سرویس گیرنده **لایه اجماع (CL)**. این صفحه، نحوه نصب، پیکربندی و اتصال این دو کلاینت برای اجرای یک گره اتریوم را نشان می دهد.
+
## پیشنیازها {#prerequisites}
شما باید بدانید که گرهی اتریوم چیست و چرا ممکن است بخواهید یک کلاینت را اجرا کنید. این موضوع در [گرهها و کلاینتها](/developers/docs/nodes-and-clients/) بررسی شده است.
-If you're new to the topic of running a node, or looking for a less technical path, we recommend first checking out our user-friendly introduction on [running an Ethereum node](/run-a-node).
+اگر موضوع اجرای یک گره برایتان تازه است یا به دنبال راهی هستید که کمتر فنی باشد، توصیه میکنیم ابتدا به مقدمهی کاربرپسند ما دربارهی [اجرای یک گرهی اتریوم](/run-a-node) نگاهی بیاندازید.
## انتخاب یک رویکرد {#choosing-approach}
-اولین گام برای چرخاندن گره خودتان انتخاب رویکردتان است. شما باید کلاینت (نرمافزار)، محیط و پارامترهایی که میخواهید با آنها کار را شروع کنید انتخاب کنید. همهی [کلاینتهای شبکهی اصلی](/developers/docs/nodes-and-clients/#advantages-of-different-implementations) را ببینید.
+اولین گام برای چرخاندن گرهی خودتان، انتخاب رویکردتان است. بر اساس الزامات و احتمالات مختلف، شما باید پیاده سازی کلاینت (هم از کلاینتهای اجرا و هم اجماع)، محیط (سخت افزار، سیستم) و پارامترهای تنظیمات کلاینت را انتخاب کنید.
+
+این صفحه شما را از طریق این تصمیمات راهنمایی می کند و به شما کمک می کند تا مناسب ترین راه را برای اجرای نمونه اتریوم خود پیدا کنید.
+
+برای انتخاب از بین پیادهسازیهای کلاینت، همه [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients)، [کلاینتهای اجماع](/developers/docs/nodes-and-clients/#consensus-clients) آماده در شبکه اصلی را ببینید و درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity) اطلاعات کسب کنید.
+
+با در نظر گرفتن [نیازهای](#requirements) کلاینتها، تصمیم بگیرید که آیا نرم افزار را روی [سخت افزار خود یا در فضای ابری](#local-vs-cloud) اجرا کنید.
-### تنظیمات کلاینت {#client-settings}
+پس از آمادهسازی محیط، کلاینت های انتخابی را با [رابط مناسب برای مبتدیان](#automatized-setup) یا [به صورت دستی](#manual-setup) با استفاده از ترمینال با گزینه های پیشرفته نصب کنید.
-پیادهسازیهای کلاینت حالتهای مختلف همگامسازی و گزینههای مختلف دیگر را فعال میکنند. [حالات همگامسازی](/developers/docs/nodes-and-clients/#sync-modes) نشانگر روشهای مختلف دانلود و اعتبارسنجی دادههای زنجیرهی بلوکی است. پیش از آغاز یک گره، شما باید تصمیم بگیرید که از کدام شبکه و کدام حالت همگامسازی استفاده نمایید. مهمترین چیزی که باید به آن توجه کرد حافظهی دیسک و زمان همگامسازی است که کلاینت نیاز دارد.
+هنگامی که گره در حال اجرا و همگام سازی است، شما آماده [استفاده از آن](#using-the-node) هستید، اما مطمئن شوید که مراقب [نگهداری](#operating-the-node) آن هستید.
-تمام گزینهها و ویژگیها را میتوان در مستندات کلاینت مشاهده کرد. پیکربندیهای متنوع کلاینت میتواند با اجرای کلاینت با پرچمهای متناظر تنظیم شود. برای اهداف آزمایشی، ممکن است ترجیح بدهید که کلاینت خود را روی شبکهی تست اجرا کنید. [نگاه اجمالی بر شبکههای پشتیبانیشده را مشاهده کنید](/developers/docs/nodes-and-clients/#execution-clients).
+![نصب کلاینت](./diagram.png)
-### محیطزیست و سختافزار {#environment-and-hardware}
+### محیط زیست و سختافزار {#environment-and-hardware}
#### محلی یا ابری {#local-vs-cloud}
-کلاینتهای اتریوم میتوانند روی رایانههای ردهی مصرفکننده کار کنند و برخلاف استخراج به سختافزار خاصی نیاز ندارند. بنابراین، شما بر اساس نیاز خود گزینههای مختلفی برای بکارگیری دارید. برای ساده کردن، بیایید اجرای یک گره را هم در یک ماشین فیزیکی محلی و هم در یک سرور ابری بررسی کنیم:
+کلاینتهای اتریوم میتوانند روی رایانههای درجه مصرفکننده کار کنند و به سختافزار خاصی مانند ماشینهای استخراج نیاز ندارند. بنابراین، شما گزینه های مختلفی برای استقرار گره بر اساس نیاز خود دارید. برای سادهسازی، بیایید اجرای یک گره را هم در یک ماشین فیزیکی محلی و هم در یک سرور ابری بررسی کنیم:
- ابر
- ارائهدهندگانْ زمان بهکار (uptime) سرور بالا و آدرسهای آیپی (IP) عمومی ثابت ارائه میدهند
@@ -38,125 +46,435 @@ If you're new to the topic of running a node, or looking for a less technical pa
- رویکرد بیاعتمادتر و حاکمیتیتر
- سرمایهگذاری برای یک بار
- امکان خرید ماشینهای پیشپیکربندیشده
- - شما باید بهطور فیزیکی دستگاه را آماده، نگهداری و احتمالاً عیبیابی کنید
+ - شما باید بهطور فیزیکی دستگاه و شبکه را آماده، نگهداری و احتمالاً عیبیابی کنید
-هر دو گزینه مزایای متفاوتی دارند که در بالا خلاصه شده است. اگر به دنبال راهحل ابری هستید، علاوه بر بسیاری از ارائهدهندگان سنتی پردازش ابری، خدماتی هم وجود دارند که بر روی بکارگیری گرهها متمرکز شدهاند. برای مثال:
-
-- [QuikNode](https://www.quiknode.io/)
-- [Blockdaemon](https://blockdaemon.com)
-- [LunaNode](https://www.lunanode.com/)
-- [Alchemy](https://www.alchemy.com/)
+هر دو گزینه مزایای متفاوتی دارند که در بالا خلاصه شده است. اگر به دنبال راهحل ابری هستید، علاوه بر بسیاری از ارائهدهندگان سنتی پردازش ابری، سرویسهایی هم وجود دارند که بر روی بهکارگیری گرهها تمرکز دارند. برای گزینه های بیشتر در مورد گره های میزبان، [گره ها را به عنوان یک سرویس](/developers/docs/nodes-and-clients/nodes-as-a-service/) بررسی کنید.
#### سختافزار {#hardware}
-با این حال، یک شبکهی غیرمتمرکز و مقاوم در برابر سانسور نباید بر ارائهدهندگان ابری متکی باشد. برای اکوسیستم سالمتر است که هر کس با سختافزار شخصی خودش گره را اجرا کند. سادهترین راه استفاده از ماشینهای پیشپیکربندیشده است:
+با این حال، یک شبکهی غیرمتمرکز و مقاوم در برابر سانسور نباید بر ارائهدهندگان ابری متکی باشد. در عوض، اجرای گره تان بر روی سختافزار محلی خودتان برای اکوسیستم سالم تر است. [تخمینها](https://www.ethernodes.org/networkType/Hosting) سهم بزرگی از گرههای اجرا شده روی ابر را نشان میدهد که میتواند به یک نقطه شکست تبدیل شود.
+
+کلاینت های اتریوم می توانند بر روی کامپیوتر، لپ تاپ، سرور یا حتی یک کامپیوتر تک برد شما اجرا شوند. در حالی که اجرای کلاینت ها بر روی رایانه شخصی شما امکانپذیر است، داشتن یک ماشین اختصاصی فقط برای گره می تواند عملکرد و امنیت آن را به میزان قابل توجهی افزایش دهد و در عین حال تأثیر آن را بر روی رایانه اصلی شما به حداقل برساند.
+
+استفاده از سخت افزار خودتان می تواند بسیار آسان باشد. بسیاری از گزینه های ساده و همچنین تنظیمات پیشرفته برای افراد فنی بیشتر وجود دارد. بنابراین بیایید به الزامات و ابزارهای اجرای کلاینت های اتریوم بر روی دستگاه شما نگاه کنیم.
+
+#### الزامات {#requirements}
+
+نیازهای سختافزاری برای هر کلاینت متفاوت است، اما معمولاً آنقدر زیاد نیست، چون گره فقط باید همگام بماند. آن را با استخراج که به قدرت محاسباتی بسیار بیشتری نیاز دارد، اشتباه نگیرید. با این حال، سختافزار قدرتمندتر زمان همگامسازی و عملکرد را بهبود میبخشد.
+
+پیش از نصب هر کلاینتی مطمئن شوید که رایانهی شما منابع لازم را برای اجرای آن دارد. در زیر می توانید الزامات حداقل و توصیه شده را بیابید.
+
+گلوگاه سخت افزار شما بیشتر فضای دیسک است. همگام سازی بلاکچین اتریوم بسیار فشرده ورودی/خروجی است و به فضای زیادی نیاز دارد. بهتر است یک **حافظه اس اس دی** با صدها گیگابایت فضای خالی حتی پس از همگام سازی داشته باشید.
+
+اندازه پایگاه داده و سرعت همگام سازی اولیه به مشتری انتخابی، پیکربندی و [استراتژی همگام سازی](/developers/docs/nodes-and-clients/#sync-modes) بستگی دارد.
+
+همچنین مطمئن شوید که اتصال اینترنت شما دارای [محدودیت پهنای باند](https://wikipedia.org/wiki/Data_cap) نباشد. توصیه میشود از یک اتصال نامحدود به اینترنت استفاده کنید، چون حجم پهنای لازم برای همگامسازی اولیه و پخش دادهها در شبکه ممکن است از محدودیت حجمی پهنای باند شما بیشتر باشد.
+
+##### سیستمعامل
+
+همهی کلاینتها از سیستمعاملهای اصلی یعنی لینوکس، مکاواس و ویندوز پشتیبانی میکنند. این بدان معناست که میتوانید گرهها را با سیستمعاملی (OS) که برای شما مناسبتر است، روی رایانههای رومیزی یا سرورهای معمولی اجرا کنید. مطمئن شوید که سیستمعامل شما بهروز است تا از مشکلات احتمالی و آسیبپذیریهای امنیتی جلوگیری شود.
+
+##### الزامات حداقلی
+
+- پردازنده با حداقل 2 هسته
+- 8 گیگ رم
+- 2 ترا SSD
+- پهنای باند حداقل 10 مگابیت بر ثانیه
+
+##### مشخصات پیشنهادی
+
+- پردازندهی سریع با حداقل 4 هسته
+- حداقل 16 گیگابایت رم
+- SSD سریع بالای 2 ترا
+- پهنای باند حداقل 25 مگابیت بر ثانیه
+
+حالت همگامسازی و سرویس گیرندهای که انتخاب میکنید بر فضای مورد نیاز تأثیر میگذارند، اما ما فضای دیسک مورد نیاز برای هر مشتری را در زیر تخمین زدهایم.
+
+| کلاینت | اندازه دیسک (همگام سازی فوری) | فضای حافظه (آرشیو کامل) |
+| ---------- | ----------------------------- | ----------------------- |
+| Besu | 800GB+ | 12TB+ |
+| Erigon | شامل نمیشود | 2.5TB+ |
+| Geth | 500GB+ | 12TB+ |
+| Nethermind | 500GB+ | 12TB+ |
+| Reth | شامل نمیشود | 2.2TB+ |
+
+- توجه: Erigon و Reth همگامسازی فوری را ارائه نمیدهند، اما هرس کامل امکانپذیر است (حدود 2 ترا برای Erigon و حدود 1.2 ترا برای Reth)
+
+برای کلاینتهای اجماع، فضای مورد نیاز به پیادهسازی کلاینت و ویژگیهای فعال (مثلاً جریمهکننده اعتبارسنج) نیز بستگی دارد، اما معمولاً با 200 گیگابایت دیگر مورد نیاز برای دادههای بیکن محاسبه میشود. با تعداد زیادی اعتبارسنج، بار پهنای باند نیز افزایش می یابد. میتوانید [جزئیات مربوط به الزامات کلاینت اجماع را در این تحلیل بیابید](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc).
+
+#### راهکارهای عملی {#plug-and-play}
+
+سادهترین گزینه برای اجرای یک گره با سختافزار خود استفاده از جعبه های راهاندازی آسان است. دستگاههای از پیش تنظیم شده توسط فروشندگان سادهترین تجربه را ارائه می دهند: سفارش، اتصال، اجرا. همه چیز از قبل پیکربندی شده است و به طور خودکار با یک راهنمای بصری و داشبورد برای نظارت و کنترل نرمافزار اجرا می شود.
- [DappNode](https://dappnode.io/)
- [Avado](https://ava.do/)
-[الزامات فضای ذخیرهسازی برای هر کلاینت و حالت همگامسازی](/developers/docs/nodes-and-clients/#requirements) را جهت اطلاع از حداقل فضای لازم و فضای توصیهشده بررسی کنید. بهطور کلی، قدرت محاسباتی متوسط باید کافی باشد. معمولاً مشکل از سرعت درایو است. در همگامسازی ابتدایی، کلاینتهای اتریوم عملیاتهای خواندن و نوشتن بسیاری را انجام میدهند. در نتیجه درایو حالت جامد (SSD) به شدت پیشنهاد میشود. یک کلاینت ممکن است نتواند [حالت فعلی را بر روی هارددیسک همگامسازی کند](https://github.com/ethereum/go-ethereum/issues/16796#issuecomment-391649278) و همواره چند بلوک از شبکهی اصلی عقب بماند. شما میتوانید اکثر کلاینتها را بر روی [یک رایانهی تکبورد با ARM](/developers/docs/nodes-and-clients/#ethereum-on-a-single-board-computer/) اجرا کنید. همچنین میتوانید از سیستمعامل [Ethbian](https://ethbian.org/index.html) برای Raspberry Pi 4 استفاده کنید. This lets you [run a client by flashing the SD card](/developers/tutorials/run-node-raspberry-pi/). بر اساس امکانات نرمافزار و سختافزاری شما، زمان همگامسازی اولیه و نیازهای ذخیرهسازی ممکن است متفاوت باشد. فراموش نکنید که [الزامات فضای ذخیرهسازی و زمان همگامسازی](/developers/docs/nodes-and-clients/#recommended-specifications) را بررسی کنید. همچنین مطمئن شوید که اتصال اینترنت شما با [حد پهنای باند](https://wikipedia.org/wiki/Data_cap) محدود نشده باشد. توصیه میشود از یک اتصال نامحدود استفاده کنید، چون حجم پهنای لازم برای همگامسازی اولیه و پخش دادهها در شبکه ممکن است از حد مجاز تنظیمشده فراتر رود.
+#### اتریوم روی رایانهی تکبرد {#ethereum-on-a-single-board-computer}
-#### سیستمعامل {#operating-system}
+یک راه آسان و ارزان برای اجرای یک گره اتریوم، استفاده از کامپیوتر تک بردی است، حتی با معماری ARM مانند Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) تصاویری با قابلیت اجرا و اجرای چندگانه مشتری را برای رزبری پای و دیگر بردهای ARM فراهم میکند.
-همهی کلاینتها سیستمعاملهای اصلی یعنی لینوکس، مکاواس و ویندوز را پشتیبانی میکنند. این بدان معناست که میتوانید گرهها را با سیستمعاملی (OS) که برای شما مناسبتر است، روی رایانههای رومیزی یا سرورهای معمولی اجرا کنید. مطمئن شوید که سیستمعامل شما بهروز است تا از مشکلات احتمالی و آسیبپذیریهای امنیتی جلوگیری شود.
+دستگاه های کوچک، مقرون به صرفه و کارآمد مانند این ها برای اجرای یک گره در خانه ایده آل هستند، اما عملکرد محدود آنها را در نظر داشته باشید.
## چرخاندن گره {#spinning-up-node}
-### دریافت نرمافزار کلاینت {#getting-the-client}
+راهاندازی واقعی کلاینت را میتوان با راهاندازهای خودکار یا به صورت دستی انجام داد و مستقیماً نرمافزار کلاینت را راهاندازی کرد.
+
+برای کاربران نا آشناتر، رویکرد پیشنهادی استفاده از یک لانچر است، نرمافزاری که شما را در نصب راهنمایی میکند و فرآیند راهاندازی کلاینت را خودکار میکند. با این حال، اگر تجربه استفاده از ترمینال را دارید، مراحل تنظیم دستی باید ساده باشد.
+
+### نصب با راهنما {#automatized-setup}
+
+چندین پروژه کاربرپسند قصد بهبود تجربه راهاندازی یک کلاینت را دارند. این لانچرها نصب و پیکربندی خودکار کلاینت را ارائه میکنند و برخی حتی یک رابط گرافیکی برای راهاندازی و نظارت بر کلاینتها ارائه میدهند.
+
+در زیر چند پروژه وجود دارد که می تواند به شما در نصب و کنترل کلاینت ها فقط با چند کلیک کمک کند:
-ابتدا [نرمافزار کلاینت](/developers/docs/nodes-and-clients/#execution-clients) مدنظرتان را بارگیری کنید
+- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - که همراه دستگاه خریداری شده از یک فروشنده ارائه نمی شود. این نرمافزار، راهانداز گره واقعی و مرکز کنترل با ویژگی های بسیار می توانند بر روی سختافزار دلخواه استفاده شوند.
+- [eth-docker](https://eth-docker.net/) - راهاندازی خودکار با استفاده از داکر با تمرکز بر روی استقرار آسان و ایمن، نیاز به دانش پایه و ترمینال داکر دارد که برای کاربران کمی پیشرفتهتر توصیه میشود.
+- [Stereum](https://stereum.net/ethereum-node-setup/) - یک لانچر برای نصب کلاینتها روی سرور راه دور از طریق اتصال SSH با راهنمای راهاندازی رابط کاربری گرافیکی، مرکز کنترل، و بسیاری از ویژگیهای دیگر.
+- [NiceNode](https://www.nicenode.xyz/) - یک لانچر با تجربه کاربری ساده برای اجرای یک گره در رایانه شما. فقط کلاینتها را انتخاب کنید و آنها را با چند کلیک شروع کنید. همچنان تحت توسعه است.
+- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - ابزار تنظیم گره که به طور خودکار یک پیکربندی داکر را با استفاده از ویزارد CLI ایجاد می کند. توسط Nethermind با زبان Go نوشته شده.
-شما بهراحتی میتوانید یک برنامهی کاربردی قابلاجرا یا بستهی نصبی را بارگیری کنید که مناسب سیستمعامل و معماری شما باشد. همیشه امضاها و چک تجمیع بستههای بارگیریشده را بررسی کنید. برخی کلاینتها مخازنی هم برای نصب و ارتقای آسانتر ارائه میدهند. در صورت ترجیح میتوانید از منبع شروع به ساختن کنید. همه کلاینتها متنباز هستند، بنابراین میتوانید آنها را با کامپایلر مناسب از کد منبع بسازید.
+### راهنماب دستی نصب کلاینت {#manual-setup}
-باینریهای قابلاجرا برای پیادهسازی های سرویسگیرنده شبکهی اصلی پایدار را میتوان از صفحات انتشار آنها بارگیری کرد:
+گزینه دیگر، دانلود، تأیید و پیکربندی نرمافزار کلاینت به صورت دستی است. حتی اگر برخی از کلاینتها یک رابط گرافیکی ارائه دهند، راهاندازی دستی همچنان به مهارت های اولیه با ترمینال نیاز دارد اما تطبیق پذیری بسیار بیشتری را ارائه می دهد.
+همانطور که قبلا توضیح داده شد، راهاندازی گره اتریوم خود مستلزم اجرای یک جفت کلاینت اجماع و اجرا است. برخی از کلاینتها ممکن است شامل یک کلاینت سبک از نوع دیگر باشند و بدون نیاز به نرمافزار دیگری همگام شوند. با این حال، تأیید کامل بدون نیاز به شخص ثالث نیاز به هر دو پیادهسازی دارد.
+
+#### دریافت نرمافزار کلاینت {#getting-the-client}
+
+ابتدا، باید نرمافزار [کلاینت اجرا](/developers/docs/nodes-and-clients/#execution-clients) و [کلاینت اجماع](/developers/docs/nodes-and-clients/#consensus-clients) دلخواه خود را بدست آورید.
+
+شما به سادگی می توانید یک برنامه اجرایی یا بسته نصبی را دانلود کنید که مناسب سیستم عامل و معماری شما باشد. همیشه امضاها و checksumهای بسته های دانلود شده را بررسی کنید. برخی از مشتریان همچنین مخازن یا تصاویر داکر را برای نصب و به روز رسانی آسان تر ارائه می دهند. همه کلاینت ها منبع باز هستند، بنابراین می توانید آنها را از سمت منبع نیز بسازید. این روش پیشرفتهتر است، اما در برخی موارد ممکن است نیاز باشد.
+
+دستورالعملهای نصب هر کلاینت در اسنادی که در فهرست کلاینتهای فوقالذکر پیوند داده شدهاند، ارائه شده است.
+
+در اینجا صفحات انتشار کلاینت ها وجود دارد که می توانید باینری های از پیش ساخته شده آنها یا دستورالعمل های نصب را پیدا کنید:
+
+##### کلاینتهای اجرا
+
+- [Besu](https://github.com/hyperledger/besu/releases)
+- [Erigon](https://github.com/ledgerwatch/erigon/releases)
- [Geth](https://geth.ethereum.org/downloads/)
-- [OpenEthereum,](https://github.com/openethereum/openethereum/releases)
- [Nethermind](https://downloads.nethermind.io/)
-- [Besu](https://besu.hyperledger.org/en/stable/)
-- [Erigon](https://github.com/ledgerwatch/erigon)
+- [Reth](https://reth.rs/installation/installation.html)
+
+همچنین شایان ذکر است که تنوع کلاینتها یک [مسئله در لایه اجرا](/developers/docs/nodes-and-clients/client-diversity/#execution-layer) است. توصیه می شود که خوانندگان به اجرای یک نسخه حداقلی از کلاینت اجرا فکر کنند.
+
+##### کلاینتهای اجماع
+
+- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest)
+- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (یک باینری از پیش ساخته شده ارائه نمی دهد، فقط یک تصویر داکر یا باید از منبع ساخته شود)
+- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest)
+- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest)
+- [Teku](https://github.com/ConsenSys/teku/releases)
+
+[تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) برای گره های اجماع که اعتبارسنج را اجرا می کنند بسیار مهم است. اگر اکثر اعتبارسنجها پیادهسازی یک کلاینت واحد را اجرا کنند، امنیت شبکه در خطر است. بنابراین توصیه می شود که یک کلاینت اقلیتی را در نظر بگیرید.
+
+[آخرین استفاده از کلاینت شبکه را ببینید](https://clientdiversity.org/) و درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity) بیشتر بدانید.
+
+##### تایید نرم افزار
+
+هنگام دانلود نرمافزار از اینترنت، توصیه می شود بینقص بودن آن را بررسی کنید. این مرحله اختیاری است، اما به خصوص در مورد زیرساخت های حیاتی مانند مشتری اتریوم، مهم است که از بردارهای حمله احتمالی آگاه باشید و از آنها اجتناب کنید. اگر یک باینری از پیش ساخته شده دانلود کرده اید، باید به آن اعتماد کنید و خطر این را در نظر بگیرید که مهاجم ممکن است بتواند فایل اجرایی را با یک فایل مخرب تعویض کند.
+
+توسعه دهندگان، باینری های منتشر شده را با کلیدهای PGP خود امضا می کنند تا بتوانید به صورت رمزنگاری تأیید کنید که دقیقاً نرم افزاری را که ایجاد کرده اند اجرا می کنید. شما فقط باید کلیدهای عمومی مورد استفاده توسعه دهندگان را به دست آورید که می توانند در صفحات انتشار کلاینت یا در اسناد یافت شوند. پس از دانلود نسخه کلاینت و امضای آن، می توانید از پیادهسازی PGP استفاده کنید، به عنوان مثال [GnuPG](https://gnupg.org/download/index.html) تا به راحتی آنها را تأیید کنید. آموزش تأیید نرمافزار منبع باز با استفاده از `gpg` در [لینوکس](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) یا [ویندوز/مک](https://freedom.press/training/verifying-open-source-software/) را بررسی کنید.
-**دقت کنید که OpenEthereum[منسوخ شده است](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) و دیگر نگهداری نمیشود.** با احتیاط از آن استفاده کنید و ترجیحاً به پیادهسازی کلاینت دیگری بروید.
+شکل دیگر تأیید این است که مطمئن شوید هش، اثر انگشت رمزنگاری منحصربهفرد، نرمافزاری که دانلود کردهاید با آنچه توسعهدهندگان ارائه کردهاند مطابقت دارد. این حتی ساده تر از استفاده از PGP است و برخی از کلاینتها فقط این گزینه را ارائه می دهند. فقط تابع هش را روی نرمافزار دانلود شده اجرا کنید و آن را با یکی از صفحه انتشار مقایسه کنید. برای مثال:
-### آغاز کلاینت {#starting-the-client}
+```sh
+sha256sum teku-22.6.1.tar.gz
-قبل از راهاندازی نرمافزار کلاینت اتریوم، آخرین بررسی را انجام دهید تا مطمئن شوید محیط شما آماده است. برای مثال، مطمئن شوید که:
+9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde
+```
-- فضای حافظهی کافی با توجه به شبکه و حالت همگامسازی انتخابی وجود دارد.
+#### نصب کلاینت {#client-setup}
+
+پس از نصب، دانلود یا کامپایل نرمافزار کلاینت، آماده اجرای آن هستید. این فقط به این معنی است که باید با پیکربندی مناسب اجرا شود. کلاینتها گزینه های پیکربندی خوبی را ارائه می دهند که میتوانند ویژگی های مختلفی را فعال کنند.
+
+بیایید با گزینه هایی شروع کنیم که می توانند به طور قابل توجهی بر عملکرد کلاینت و استفاده از داده تأثیر بگذارند. [حالتهای همگامسازی](/developers/docs/nodes-and-clients/#sync-modes) روشهای مختلف بارگیری و اعتبارسنجی دادههای زنجیرهی بلوکی را نشان میدهند. پیش از آغاز گره، باید تصمیم بگیرید که از کدام شبکه و کدام حالت همگامسازی استفاده نمایید. مهمترین چیزهایی که باید در نظر بگیرید فضای دیسک و زمان همگام سازی مورد نیاز کلاینت است. برای تعیین اینکه کدام حالت همگام سازی پیش فرض است، به اسناد کلاینت توجه کنید. اگر برای شما مناسب نیست، یکی دیگر را بر اساس سطح امنیت، داده های موجود و هزینه انتخاب کنید. به غیر از الگوریتم همگامسازی، میتوانید هرس (pruning) انواع مختلف دادههای قدیمی را نیز تنظیم کنید. هرس امکان حذف دادههای قدیمی را فراهم میکند، بهعنوان مثال حذف گرههای درخت وضعیت که از بلوکهای اخیر غیرقابلدسترسی هستند.
+
+سایر گزینه های پیکربندی اولیه عبارتند از، به عنوان مثال. انتخاب یک شبکه - شبکه اصلی یا شبکههای آزمایشی، فعال کردن نقطه پایانی HTTP برای RPC یا WebSockets و غیره. شما می توانید تمام ویژگی ها و گزینه ها را در اسناد کلاینت بیابید. پیکربندی های مختلف کلاینت را می توان با اجرای کلاینت با پرچم های مربوطه به طور مستقیم در فایل CLI یا پیکربندی تنظیم کرد. هر کلاینت کمی متفاوت است. لطفاً برای جزئیات بیشتر در مورد گزینه های پیکربندی، همیشه به اسناد رسمی یا صفحه راهنمای آن مراجعه کنید.
+
+برای اهداف آزمایشی، ممکن است ترجیح دهید یک کلاینت را در یکی از شبکه های تست نت اجرا کنید. [مشخصات کلی شبکههای پشتیبانیشده را مشاهده کنید](/developers/docs/nodes-and-clients/#execution-clients).
+
+نمونه هایی از اجرای کلاینت های اجرایی با پیکربندی اولیه را می توان در بخش بعدی یافت.
+
+#### آغاز بهکار کلاینت اجرا {#starting-the-execution-client}
+
+قبل از راهاندازی نرمافزار کلاینت اتریوم، آخرین بررسی را انجام دهید که آیا محیط شما آماده است. برای مثال، مطمئن شوید که:
+
+- فضای دیسک کافی با توجه به شبکه انتخابی و حالت همگام سازی وجود دارد.
- حافظه و پردازنده توسط برنامههای دیگر استفاده نمیشود.
-- سیستمعامل به آخرین نسخهی خود بهروز شده است.
-- زمان و تاریخ سیستم درست است.
+- سیستم عامل به آخرین نسخه آپدیت شده است.
+- سیستم زمان و تاریخ صحیح را دارد.
- روتر و فایروال شما اتصالات را در پورتهای شنونده (listening ports) میپذیرند. به طور پیشفرض کلاینتهای اتریوم از یک پورت شنونده (TCP) و یک پورت یابنده (UDP) که هر دو بهطور پیشفرض روی 30303 هستند استفاده میکنند.
-کلاینت خود را ابتدا روی شبکهی تست اجرا کنید تا مطمئن شوید که همهچیز بهدرستی کار میکند. اجرای یک گره سبک geth باید کارگشا باشد. شما باید هرگونه تنظیمات کلاینت که به صورت پیشفرض وجود ندارند را در ابتدا مشخص کنید. میتوانید از پرچمها و فایلهای پیکربندی برای مشخص کردن پیکربندی موردنظر استفاده کنید. برای اطلاع از جزئیات، مستندات کلاینت خود را بررسی کنید. اجرای کلاینت، توابع اصلی، نقاط پایانی انتخاب شده و جستجوی همتایان را آغاز میکند. پس از یافتن موفق همتایان، کلاینت شروع به همگامسازی میکند. دادهی کنونی زنجیرهی بلوکی زمانی آماده خواهد بود که کلاینت بهطور موفقیتآمیز با وضعیت فعلی همگامسازی کرده باشد.
+کلاینت خود را ابتدا روی شبکهی تست اجرا کنید تا مطمئن شوید که همهچیز بهدرستی کار میکند.
+
+شما باید هرگونه تنظیمات کلاینت که به صورت پیشفرض وجود ندارند را در ابتدا مشخص کنید. میتوانید از پرچمها و فایلهای پیکربندی برای مشخص کردن پیکربندی موردنظر استفاده کنید. مجموعه ای از ویژگی ها و نحو پیکربندی هر کلاینت متفاوت است. برای جزئیات، اسناد کلاینت خود را بررسی کنید.
+
+کلاینتهای اجرا و اجماع از طریق یک نقطه پایانی تأیید شده مشخص شده در [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine) ارتباط برقرار می کنند. برای اتصال به یک کلاینت اجماع، کلاینت اجرا باید یک [`jwtsecret`](https://jwt.io/) در یک مسیر شناخته شده ایجاد کند. به دلایل امنیتی و پایداری، کلاینتها باید روی یک ماشین اجرا شوند و هر دو کلاینت باید این مسیر را بدانند زیرا برای تأیید اعتبار یک اتصال RPC محلی بین آنها استفاده میشود. کلاینت اجرا همچنین باید یک پورت شنونده (listening port) برای APIهای تایید شده تعریف کند.
+
+این نشانه به طور خودکار توسط نرمافزار کلاینت تولید می شود، اما در برخی موارد، ممکن است لازم باشد خودتان آن را انجام دهید. میتوانید آن را با [OpenSSL](https://www.openssl.org/)تولید کنید:
+
+```sh
+openssl rand -hex 32 > jwtsecret
+```
+
+#### اجرای یک کلاینت اجرا {#running-an-execution-client}
+
+این بخش شما را از طریق راهاندازی کلاینت های اجرا راهنمایی می کند. این فقط به عنوان نمونه ای از یک پیکربندی اولیه عمل می کند که کلاینت را با این تنظیمات شروع میکند:
-### استفاده از کلاینت {#using-the-client}
+- شبکه ای را برای اتصال به شبکه اصلی در مثال های ما مشخص می کند
+ - در عوض میتوانید [یکی از شبکههای آزمایشی](/developers/docs/networks/) را برای آزمایش اولیه تنظیمات خود انتخاب کنید
+- دایرکتوری داده را تعریف می کند، جایی که تمام داده ها از جمله بلاکچین در آن ذخیره می شود
+ - مطمئن شوید که مسیر را با یک مسیر واقعی جایگزین کنید، به عنوان مثال به درایو خارجی شما اشاره می کند
+- رابط ها را برای برقراری ارتباط با کلاینت فعال می کند
+ - از جمله JSON-RPC و Engine API برای ارتباط با کلاینت اجماع
+- مسیر `jwtsecret` را برای API احراز هویت شده تعریف می کند
+ - مطمئن شوید که مسیر مثال را با یک مسیر واقعی جایگزین کنید که برای کلاینتها قابل دسترسی باشد، مثلاً `/tmp/jwtsecret`
-کلاینتها ارائهدهندهی نقاط پایانی وب سرویس RPC هستند که میتوانید از آنها برای کنترل کلاینت و ارتباط با شبکهی اتریوم به اشکال مختلف استفاده کنید:
+لطفاً به خاطر داشته باشید که این فقط یک مثال اولیه است، تمام تنظیمات دیگر به طور پیش فرض تنظیم می شوند. برای اطلاع از مقادیر، تنظیمات و ویژگیهای پیشفرض، به مستندات هر کلاینت توجه کنید. برای ویژگی های بیشتر، به عنوان مثال برای اجرای اعتبارسنج، نظارت و غیره، لطفاً به مستندات کلاینت خاص مراجعه کنید.
-- فراخوانی دستی آنها با یک پروتکل مناسب (مثلاً استفاده از `curl`)
-- ضمیمه کردن کنسول ارائه شده (مثلاً `geth attach`)
-- پیادهسازی آنها در برنامههای کاربردی
+> توجه داشته باشید که جریمههای معکوس `\` در مثال ها فقط برای اهداف قالب بندی هستند. پرچم های پیکربندی را می توان در یک خط تعریف کرد.
-کلاینتهای مختلف پیادهسازیهای مختلفی برای نقاط پایانی RPC دارند. اما برای JSON-RPC استانداردی وجود دارد که میتوانید برای هر کلاینتی استفاده نمایید. برای مروری اجمالی، [مستندات JSON-RPC را بخوانید](https://eth.wiki/json-rpc/API). برنامههای کاربردی که نیاز به اطلاعات از شبکهی اتریوم دارند میتوانند از RPC استفاده کنند. برای مثال، کیف پول معروف MetaMask به شما اجازه میدهد که [یک نمونهی زنجیرهی بلوکی محلی را اجرا کنید و به آن متصل کنید](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node).
+##### اجرای Besu
+
+این مثال Besu را در شبکه اصلی شروع میکند، دادههای بلاکچین را در قالب پیشفرض در `/data/ethereum` ذخیره میکند، JSON-RPC و Engine RPC را برای اتصال کلاینت اجماع فعال میکند. Engine API با نشانه `jwtsecret` احراز هویت می شود و فقط تماس از `localhost` مجاز است.
+
+```sh
+besu --network=mainnet \
+ --data-path=/data/ethereum \
+ --rpc-http-enabled=true \
+ --engine-rpc-enabled=true \
+ --engine-host-allowlist="*" \
+ --engine-jwt-enabled=true \
+ --engine-jwt-secret=/path/to/jwtsecret
+```
+
+Besu همچنین دارای یک گزینه لانچر است که یک سری سوالات را می پرسد و فایل پیکربندی را ایجاد می کند. لانچر تعاملی را با استفاده از موارد زیر اجرا کنید:
+
+```sh
+besu --Xlauncher
+```
+
+[اسناد Besu](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) حاوی گزینههای اضافی و جزئیات پیکربندی است.
+
+##### اجرای Erigon
+
+این مثال Erigon را در شبکه اصلی شروع میکند، دادههای بلاکچین را در `/data/ethereum` ذخیره میکند، JSON-RPC را فعال میکند،تعیین می کند که چه فضاهای نامی مجاز است و احراز هویت را برای اتصال کلاینت اجماع که توسط مسیر `jwtsecret` تعریف می شود، فعال می کند.
+
+```sh
+erigon --chain mainnet \
+ --datadir /data/ethereum \
+ --http --http.api=engine,eth,web3,net \
+ --authrpc.jwtsecret=/path/to/jwtsecret
+```
+
+Erigon به طور پیش فرض یک همگام سازی کامل را با 8 گیگابایت هارد دیسک انجام می دهد که منجر به بیش از 2 ترابایت داده آرشیو می شود. مطمئن شوید که `datadir` به دیسک با فضای خالی کافی اشاره می کند یا به پرچم `--prune` نگاه کنید که می تواند انواع مختلف داده را هرس کند. برای کسب اطلاعات بیشتر، `--help` مربوط به Erigon را بررسی کنید.
+
+##### اجرای Geth
+
+این مثال Geth را در شبکه اصلی شروع میکند، دادههای بلاکچین را در `/data/ethereum` ذخیره میکند، JSON-RPC را فعال میکند و مشخص میکند که کدام فضاهای نام مجاز هستند. همچنین احراز هویت را برای اتصال کلاینت اجماع فعال می کند که به مسیر `jwtsecret` نیاز دارد و همچنین گزینه ای را که در مثال ما فقط از `localhost` مجاز است، تعیین می کند.
+
+```sh
+geth --mainnet \
+ --datadir "/data/ethereum" \
+ --http --authrpc.addr localhost \
+ --authrpc.vhosts="localhost" \
+ --authrpc.port 8551
+ --authrpc.jwtsecret=/path/to/jwtsecret
+```
+
+[اسناد برای همه گزینههای پیکربندی](https://geth.ethereum.org/docs/fundamentals/command-line-options) را بررسی کنید و درباره [اجرای Geth با یک کلاینت اجماع](https://geth.ethereum.org/docs/getting-started/consensus-clients) بیشتر بدانید.
+
+##### اجرای Nethermind
+
+Nethermind [گزینه های نصب](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) مختلفی را ارائه می دهد. این بسته با باینریهای مختلف، از جمله یک لانچر با راهاندازی هدایتشده ارائه میشود که به شما در ایجاد پیکربندی به صورت تعاملی کمک میکند. از طرف دیگر، Runner را پیدا میکنید که خود فایل اجرایی است و فقط میتوانید آن را با پرچمهای پیکربندی اجرا کنید. JSON-RPC بهصورت پیشفرض فعال است.
+
+```sh
+Nethermind.Runner --config mainnet \
+ --datadir /data/ethereum \
+ --JsonRpc.JwtSecretFile=/path/to/jwtsecret
+```
+
+اسناد Nethermind یک [راهنمای کامل](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) در مورد اجرای Nethermind با کلاینت اجماع ارائه می دهد.
+
+یک کلاینت اجرا، توابع اصلی، نقاط پایانی انتخابی خود را آغاز می کند و شروع به جستجوی همتا می کند. پس از یافتن موفق همتایان، کلاینت شروع به همگامسازی میکند. کلاینت اجرا منتظر اتصال از سمت کلاینت اجماع خواهد بود. دادههای کنونی زنجیرهی بلوکی زمانی آماده خواهد بود که کلاینت بهطور موفقیتآمیز با وضعیت فعلی همگامسازی کرده باشد.
+
+##### اجرای Reth
+
+این مثال با استفاده از موقعیت مکانی داده پیش فرض، Reth را در شبکه اصلی شروع می کند. احراز هویت JSON-RPC و Engine RPC را برای اتصال کلاینت اجماع که توسط مسیر `jwtsecret` تعریف شده است، فعال می کند و فقط تماس از `localhost` مجاز است.
+
+```sh
+reth node \
+ --authrpc.jwtsecret /path/to/jwtsecret \
+ --authrpc.addr 127.0.0.1 \
+ --authrpc.port 8551
+```
+
+برای اطلاعات بیشتر در مورد دایرکتوری های داده پیش فرض داده، به [پیکربندی Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) مراجعه کنید. [اسناد Reth](https://reth.rs/run/mainnet.html) حاوی گزینههای اضافی و جزئیات پیکربندی است.
+
+#### آغاز بهکار کلاینت اجماع {#starting-the-consensus-client}
+
+کلاینت اجماع باید با پیکربندی پورت مناسب شروع شود تا یک اتصال RPC محلی به کلاینت اجرا برقرار شود. کلاینت های اجماع باید با پورت کلاینت اجرای در معرض، به عنوان آرگومان پیکربندی اجرا شوند.
+
+کلاینت اجماع همچنین به مسیر `jwt-secret` کلاینت اجرا نیاز دارد تا بتواند ارتباط RPC بین آنها را تأیید کند. مشابه مثالهای اجرایی بالا، هر کلاینت اجماع یک پرچم پیکربندی دارد که مسیر فایل توکن jwt را به عنوان آرگومان میگیرد. این مسیر باید با مسیر `jwtsecret` ارائهشده به کلاینت اجرا مطابقت داشته باشد.
+
+اگر قصد دارید یک اعتبارسنج را اجرا کنید، مطمئن شوید که یک پرچم پیکربندی که آدرس اتریوم گیرنده کارمزد را مشخص میکند، اضافه کنید. اینجاست که پاداشهای اتر برای اعتبارسنج شما جمع میشوند. هر کلاینت اجماع یک گزینه دارد، مثلاً `--suggested-fee-recipient=0xabcd1`، که آدرس اتریوم را به عنوان آرگومان می گیرد.
+
+هنگام راهاندازی یک بیکننود در یک شبکه آزمایشی، میتوانید با استفاده از یک نقطه پایانی عمومی برای [همگامسازی نقطه چک](https://notes.ethereum.org/@launchpad/checkpoint-sync) زمان همگامسازی قابل توجهی صرفهجویی کنید.
+
+#### اجرای یک کلاینت اجماع {#running-a-consensus-client}
+
+##### اجرای Lighthouse
+
+قبل از اجرای Lighthouse، در [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html) درباره نحوه نصب و پیکربندی آن بیشتر بیاموزید.
+
+```sh
+lighthouse beacon_node \
+ --network mainnet \
+ --datadir /data/ethereum \
+ --http \
+ --execution-endpoint http://127.0.0.1:8551 \
+ --execution-jwt /path/to/jwtsecret
+```
+
+##### اجرای Lodestar
+
+نرمافزار Lodestar را با کامپایل یا دانلود تصویر داکر نصب کنید. در [اسناد](https://chainsafe.github.io/lodestar/) و جامع تر در [راهنمای راه اندازی](https://hackmd.io/@philknows/rk5cDvKmK) بیشتر بیاموزید.
+
+```sh
+lodestar beacon \
+ --rootDir="/data/ethereum" \
+ --network=mainnet \
+ --eth1.enabled=true \
+ --execution.urls="http://127.0.0.1:8551" \
+ --jwt-secret="/path/to/jwtsecret"
+```
+
+##### اجرای Nimbus
+
+Nimbus هم با اجماع و هم با کلاینت های اجرا عرضه می شود. این می تواند بر روی دستگاه های مختلف حتی با قدرت محاسباتی بسیار کم اجرا شود. پس از [نصب وابستگی ها و خود Nimbus](https://nimbus.guide/quick-start.html)، می توانید کلاینت اجماع آن را اجرا کنید:
+
+```sh
+nimbus_beacon_node \
+ --network=mainnet \
+ --web3-url=http://127.0.0.1:8551 \
+ --rest \
+ --jwt-secret="/path/to/jwtsecret"
+```
+
+##### اجرای Prysm
+
+Prysm همراه با اسکریپت است که امکان نصب خودکار آسان را فراهم می کند. جزئیات را می توان در [اسناد Prysm](https://docs.prylabs.network/docs/install/install-with-script) پیدا کرد.
+
+```sh
+./prysm.sh beacon-chain \
+ --mainnet \
+ --datadir /data/ethereum \
+ --execution-endpoint=http://localhost:8551 \
+ --jwt-secret=/path/to/jwtsecret
+```
+
+##### اجرای Teku
+
+```sh
+teku --network mainnet \
+ --data-path "/data/ethereum" \
+ --ee-endpoint http://localhost:8551 \
+ --ee-jwt-secret-file "/path/to/jwtsecret"
+```
+
+هنگامی که یک کلاینت اجماع برای خواندن قرارداد سپرده و شناسایی اعتبارسنجها به کلاینت اجرا متصل می شود، به سایر همتایان بیکننود نیز متصل می شود و شروع به همگام سازی اسلات های اجماع از زمان پیدایش می کند. هنگامی که Beacon Node به دوره فعلی رسید، Beacon API برای اعتبارسنج شما قابل استفاده می شود. درباره [API های Beacon Node](https://eth2docs.vercel.app/) بیشتر بیاموزید.
+
+### افزودن اعتبارسنجها {#adding-validators}
+
+یک کلاینت اجماع به عنوان یک Beacon Node برای اعتبارسنجها برای اتصال عمل می کند. هر کلاینت اجماع دارای نرمافزار اعتبارسنج مخصوص به خود است که در مستندات مربوطه به تفصیل شرح داده شده است.
+
+اجرای اعتبارسنج خود اجازهی [سهامگذاری انفرادی](/staking/solo/)، موثرترین و بی اعتمادترین روش برای پشتیبانی از شبکه اتریوم را میدهد. بااینحال، نیاز به سپردهگذاری 32 اتر دارد. برای اجرای یک اعتبارسنج بر روی گره خود با مقدار کمتر، ممکن است یک استخر غیرمتمرکز با عملگرهای گره بدون مجوز، مانند [Rocket Pool](https://rocketpool.net/node-operators) مورد علاقه شما باشد.
+
+سادهترین راه برای شروع کار با تولید کلید سهامگذاری و اعتبارسنج، استفاده از [لانچپد سهامگذاری شبکهی تست Holesky](https://holesky.launchpad.ethereum.org/) است که به شما امکان می دهد تنظیمات خود را با [گره های در حال اجرا در Holesky](https://notes.ethereum.org/@launchpad/holesky) آزمایش کنید. وقتی برای شبکهی اصلی آماده شدید، میتوانید این مراحل را با استفاده از [سکوی پرتاب سهامگذاری شبکهی اصلی](https://launchpad.ethereum.org/) تکرار کنید.
+
+برای مروری بر گزینه های سهامگذاری به [صفحه سهامگذاری](/staking) نگاه کنید.
+
+### استفاده کردن از گره {#using-the-node}
+
+کلاینتهای اجرا [نقاط پایانی RPC API](/developers/docs/apis/json-rpc/) را ارائه میکنند که میتوانید از آنها برای ارسال تراکنشها، تعامل با قراردادهای هوشمند یا استقرار آنها در شبکه اتریوم به روشهای مختلف استفاده کنید:
+
+- فراخوانی دستی آنها با یک پروتکل مناسب (مثلاً با استفاده از `curl`)
+- ضمیمه کردن کنسول ارائهشده (مثلاً `geth attach`)
+- پیادهسازی آنها در برنامه های کاربردی با استفاده از کتابخانه های web3، مثلاً [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)، [ethers](https://github.com/ethers-io/ethers.js/)
+
+کلاینتهای مختلف پیادهسازیهای مختلفی برای نقاط پایانی RPC دارند. اما برای JSON-RPC استانداردی وجود دارد که میتوانید برای هر کلاینتی استفاده نمایید. برای مروری اجمالی، [مستندات JSON-RPC را بخوانید](/developers/docs/apis/json-rpc/). برنامههای کاربردی که نیاز به اطلاعات از شبکهی اتریوم دارند میتوانند از RPC استفاده کنند. به عنوان مثال، کیف پول محبوب متامسک به شما امکان می دهد [به نقطه پایانی RPC خود متصل شوید](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) که دارای مزایای امنیتی و حریم خصوصی قوی است.
+
+کلاینتهای اجماع همگی یک [API بیکن](https://ethereum.github.io/beacon-APIs) را در معرض نمایش میگذارند که میتواند با ارسال درخواست با استفاده از ابزارهایی مانند [Curl](https://curl.se) برای بررسی وضعیت کلاینت اجماع یا بارگیری کردن بلوکها و دادههای اجماع استفاده شود. اطلاعات بیشتر در این مورد را میتوان در اسناد مربوط به هر کلاینت اجماع یافت.
#### دستیابی به RPC {#reaching-rpc}
-پورت پیشفرض JSON-RPC `8545` است اما میتوانید پورتهای نقاط پایانی محلی را در فایل پیکربندی مشخص کنید. در حالت پیشفرض، رابط RPC فقط در هاست محلی (localhost) رایانهی شما قابل دسترسی است. برای اینکه بتوانید از راه دور به آن دسترسی داشته باشید، میتوانید با تغییر آدرس به `0.0.0.0` آن را در معرض دید عموم قرار دهید. بدین ترتیب از طریق آدرسهای آیپی (IP) محلی و عمومی قابلدسترسی خواهد بود. در بیشتر موارد، باید روی روتر خود بازارسالی پورت (port forwarding) را هم تنظیم کنید.
+درگاه پیشفرض برای اجرای برنامه JSON-RPC `8545` است اما میتوانید پورتهای نقاط انتهایی محلی را در پیکربندی تغییر دهید. در حالت پیشفرض، رابط RPC فقط در هاست محلی (localhost) رایانهی شما قابل دسترسی است. برای اینکه بتوانید از راه دور به آن دسترسی داشته باشید، میتوانید با تغییر آدرس به `0.0.0.0` آن را در معرض دید عموم قرار دهید. این باعث می شود که از طریق شبکه محلی و آدرس های IP عمومی قابل دسترسی باشد. در بیشتر موارد، باید روی روتر خود باز ارسالی پورت (port forwarding) را هم تنظیم کنید.
-شما باید این کار را با احتیاط انجام دهید، چون هر کسی در اینترنت اجازه میدهد گرهی شما را کنترل کند. اگر از کلاینت خود به عنوان کیف پول استفاده میکنید، بازیگران بداندیش میتوانند به گرهی شما دسترسی پیدا کنند تا سیستم شما را خراب کنند یا سرمایههای شما را بدزدند.
+با احتیاط به قرار دادن پورت ها در معرض اینترنت نگاه کنید زیرا این کار به هر کسی در اینترنت اجازه می دهد گره شما را کنترل کند. اگر از کلاینت خود بهعنوان کیف پول استفاده میکنید، افراد خرابکار میتوانند به گره شما دسترسی پیدا کنند تا سیستم شما را خراب کنند یا سرمایههای شما را بدزدند.
-راهحل این مشکل، جلوگیری از تغییرپذیری روشهای بالقوه خطرناک RPC است. برای مثال، با `geth` شما میتوانید روشهای تغییرپذیر را با پرچم مشخص کنید: `--http.api web3,eth,txpool`.
+راهحل این مشکل، جلوگیری از تغییرپذیری روشهای بالقوه خطرناک RPC است. برای مثال، با Geth، میتوانید روشهای اصلاحپذیر را با یک پرچم اعلام کنید: `--http.api web3,eth,txpool`.
-همچنین میتوانید با اشاره سرویس وب سرور، مانند Nginx، به آدرس محلی و پورت کلاینت خود، دسترسی به رابط RPC خود را میزبانی کنید.
+دسترسی به رابط RPC را می توان از طریق توسعه APIهای لایه لبه یا برنامه های کاربردی وب سرور، مانند Nginx، و اتصال آنها به آدرس محلی و پورت کلاینت خود گسترش داد. استفاده از یک لایه میانی همچنین میتواند به توسعهدهندگان این امکان را بدهد که گواهی را برای اتصالات `https` ایمن به رابط RPC تنظیم کنند.
-سادهترین و بهترین راه از حیث حفظ حریم خصوصی برای تنظیم یک نقطهی پایانی قابلدسترس این است که سرویس [Tor](https://www.torproject.org/) آنیون خود را داشته باشید. بدین ترتیب میتوانید به RPC خارج از شبکهی محلی خود بدون آدرس آیپی (IP) عمومی ثابت یا پورتهای باز شده دسترسی پیدا کنید. برای انجام این کار:
+راهاندازی یک وب سرور، یک پروکسی یا Rest API روبه خارج تنها راه برای دسترسی به نقطه پایانی RPC گره شما نیست. یکی دیگر از راههای حفظ حریم خصوصی برای تنظیم یک نقطه پایانی قابل دسترسی عمومی، میزبانی گره در سرویس پیاز [Tor](https://www.torproject.org/) خودتان است. بدین ترتیب میتوانید به RPC خارج از شبکهی محلی خود بدون آدرس آیپی (IP) عمومی ثابت یا پورتهای باز شده دسترسی پیدا کنید. با این حال، استفاده از این پیکربندی ممکن است تنها به نقطه پایانی RPC اجازه دهد که از طریق شبکه Tor که توسط همه برنامهها پشتیبانی نمیشود و ممکن است منجر به مشکلات اتصال شود، قابل دسترسی باشد.
-- `tor` را نصب کنید
-- پیکربندی `torrc` را برای فعالسازی سرویس پنهان با آدرس RPC کلاینت و پورت خود ویرایش کنید
-- سرویس `tor` را مجدداً راهاندازی کنید
+برای انجام این کار، باید [سرویس onion](https://community.torproject.org/onion-services/) خود را ایجاد کنید. [اسناد](https://community.torproject.org/onion-services/setup/) راهاندازی سرویس پیاز را برای هاست خود بررسی کنید. می توانید آن را به یک وب سرور با پروکسی به درگاه RPC یا فقط مستقیماً به RPC اشاره کنید.
-وقتی Tor را مجدداً راهاندازی میکنید، کلیدهای سرویس پنهان و نام میزبان را در نشانی مدنظرتان دریافت میکنید. از آن به بعد، RPC شما روی نام میزبان `.onion` قابلدسترسی خواهد بود.
+در نهایت، و یکی از محبوب ترین راه ها برای دسترسی به شبکه های داخلی از طریق اتصال VPN است. بسته به مورد استفاده شما و تعداد کاربرانی که نیاز به دسترسی به گره شما دارند، یک اتصال VPN ایمن ممکن است یک گزینه باشد. [OpenVPN](https://openvpn.net/) یک SSL VPN با امکانات کامل است که برنامه افزودنی شبکه ایمن لایه دوم یا سوم OSI را با استفاده از پروتکل استاندارد صنعتی SSL/TLS پیادهسازی میکند، از روشهای تأیید اعتبار کلاینت انعطافپذیر بر اساس گواهیها، کارتهای هوشمند و/یا نام کاربری پشتیبانی میکند، نام کاربری/رمز را ارائه می دهد و به سیاست های کنترل دسترسی خاص کاربر یا گروه با استفاده از قوانین فایروال اعمال شده در رابط مجازی VPN اجازه کار می دهد.
-### گرداندن گره {#operating-the-node}
+### استفاده از گره {#operating-the-node}
شما باید بهطور مرتب گره خود را کنترل کنید تا مطمئن شوید که به درستی کار میکند. ممکن است نیاز به انجام تعمیرات گاهبهگاه داشته باشید.
-#### برخط نگهداشتن گره {#keeping-node-online}
+#### آنلاین نگهداشتن گره {#keeping-node-online}
+
+نیازی نیست که گره شما همیشه آنلاین باشد، اما باید آن را تا حد امکان آنلاین نگه دارید تا با شبکه همگام شود. برای راه اندازی مجدد می توانید آن را خاموش کنید، اما به خاطر داشته باشید که:
-نیازی نیست که گرهی شما بیوقعه برخط باشد، اما باید آن را تا حد امکان برخط نگه دارید تا با شبکه همگام شود. برای راهاندازی مجدد میتوانید آن را خاموش کنید، اما به خاطر داشته باشید که:
+- اگر وضعیت اخیر همچنان روی دیسک نوشته می شود، خاموش شدن می تواند چند دقیقه طول بکشد.
+- خاموش شدن اجباری می تواند به دیتابیس آسیب برساند و شما را ملزم به همگام سازی مجدد کل گره کند.
+- کلاینت شما با شبکه همگام نمی شود و با راه اندازی مجدد باید مجدداً همگام شود. در حالی که گره می تواند از زمانی که آخرین خاموش شده بود همگام سازی را آغاز کند، بسته به مدت زمانی که آفلاین بوده است، فرآیند ممکن است زمان ببرد.
-- اگر وضعیت اخیر همچنان روی دیسک نوشته میشود، خاموش شدن میتواند تا چند دقیقه طول بکشد.
-- خاموش شدن اجباری میتواند به پایگاه داده آسیب برساند.
-- کلاینت شما با شبکه همگام نمیشود و با راهاندازی مجدد باید مجدداً همگام شود.
+_این موضوع روی گرههای اعتبار سنج لایهی اجماع اعمال نمیشود._ آفلاین کردن گرهی شما بر تمام سرویسهای وابسته به آن تأثیر میگذارد. اگر یک گره را برای _سهامگذاری_ اجرا میکنید، باید سعی کنید زمان خاموشی را تا حد امکان پایین آورید.
-_این موضوع روی گرههای اعتبار سنج لایهی اجماع اعمال نمیشود._ بُرونخط کردن گرهی شما بر تمام سرویسهای وابسته به آن تأثیر میگذارد. اگر یک گره را برای _سهامگذاری_ اجرا میکنید باید سعی کنید زمان خاموشی را تا حد امکان پایین آورید.
+#### ساختن سرویسهای کلاینت {#creating-client-services}
-#### ساختن سرویس کلاینت {#creating-client-service}
+ساختن سرویسی را برای اجرای خودکار کلاینتهای خود در هنگام راهاندازی در نظر بگیرید. به عنوان مثال، در سرورهای لینوکس، بهترین رویه ایجاد یک سرویس است، به عنوان مثال با `systemd`، که کلاینت را با پیکربندی مناسب، تحت یک کاربر با امتیازات محدود اجرا می کند و به طور خودکار ریستارت می شود.
-برای اجرای خودکار کلاینت در هنگام راهاندازی، ساختن سرویس را در نظر بگیرید. بهعنوان مثال در سرورهای لینوکس، بهترین رویه ساخت سرویسی است که کلاینت را با پیکربندی مناسب، تحت کاربر با امتیازات محدود اجرا میکند و بهطور خودکار مجدداً راهاندازی میشود.
+#### بهروزرسانی کلاینتها {#updating-clients}
-#### بهروزرسانی کلاینت {#updating-client}
+شما باید نرمافزار کلاینت خود را با آخرین پچهای امنیتی، ویژگیها و [EIPها](/eips/) بهروز نگهدارید. بهویژه قبل از [فورک سخت](/history/)، مطمئن شوید که نسخههای کلاینت صحیح را اجرا میکنید.
-شما باید نرمافزار کلاینت خود را با آخرین پچهای امنیتی، ویژگیها و [EIPها](/eips/) بهروز نگهدارید. خصوصاً قبل از انجام [فورکهای سخت](/history/) مطمئن شوید که نسخهی درست کلاینت را اجرا میکنید.
+> قبل از بهروزرسانیهای مهم شبکه، EF یک پست را در [وبلاگ](https://blog.ethereum.org) خود منتشر میکند. میتوانید [مشترک این اعلامیهها شوید](https://blog.ethereum.org/category/protocol#subscribe) تا زمانی که گره شما نیاز به بروزرسانی دارد، اعلان را در ایمیل خود دریافت کنید.
+
+بروزرسانی کلاینتها بسیار ساده است. هر کلاینت دستورالعملهای خاصی را در مستندات خود دارد، اما فرآیند معمولاً فقط دانلود آخرین نسخه و راهاندازی مجدد کلاینت با فایل اجرایی جدید است. کلاینت باید از جایی که کارش را متوقف کرد، اما با بهروزرسانیهای اعمال شده، به کار خود ادامه دهد.
+
+هر پیادهسازی کلاینت دارای یک رشته نسخه قابلخواندن توسط انسان است که در پروتکل همتا به همتا استفاده میشود، اما از طریق خط فرمان نیز قابلدسترسی است. این رشته نسخه به کاربران امکان می دهد بررسی کنند که آیا نسخه صحیح را اجرا میکنند یا نه و به جستجوگرهای بلوک و سایر ابزارهای تحلیلی علاقهمند به تعیین کمیت توزیع مشتریان خاص اجازهی دسترسی به شبکه را میدهد. لطفاً جهت کسب اطلاعات بیشتر در مورد رشتههای نسخه به مستندات هر کلاینت مراجعه کنید.
#### اجرای سرویسهای اضافه {#running-additional-services}
-اجرای گره خودتان به شما امکان میدهد از خدماتی استفاده کنید که نیاز به دسترسی مستقیم به RPC کلاینت اتریوم دارند. اینها سرویسهایی هستند که بر روی اتریوم ساخته شدهاند مثل [راهحلهای لایهی 2](/developers/docs/scaling/#layer-2-scaling)، [کلاینتهای اجماع] و سایر زیرساختهای اتریوم.
+اجرای گره خودتان به شما امکان میدهد از خدماتی استفاده کنید که نیاز به دسترسی مستقیم به RPC کلاینت اتریوم دارند. اینها خدماتی هستند که بر روی اتریوم ساخته شده اند مانند [راهکارهای لایه 22](/developers/docs/scaling/#layer-2-scaling)، پشتیبان برای کیف پول، کاوشگرهای بلوک، ابزارهای توسعه دهنده و سایر زیرساخت های اتریوم.
#### نظارت بر گره {#monitoring-the-node}
-برای نظارت صحیح بر گرهی خود، جمعآوری معیارها را در نظر بگیرید. کلاینتها نقاط پایانیهای معیارها را ارائه میدهند که شما بتوانید دادههای جامعی دربارهی گرهی خود دریافت کنید. از ابزارهایی مثل [InfluxDB](https://www.influxdata.com/get-influxdb/) یا [Prometheus](https://prometheus.io/) برای ساخت پایگاه دادههایی استفاده کنید که میتوانید با استفاده از نرمافزارهایی مثل [Grafana](https://grafana.com/) آنها را تبدیل به بازنمایی بصری و نمودار کنید. تنظیمات زیادی برای استفاده از این نرمافزار و داشبوردهای مختلف Grafana وجود دارد تا بتوانید گرهی خود و شبکه را بهطور کامل به شکل بصری بازنمایی کنید. بهعنوان بخشی از نظارت خود، مطمئن شوید که عملکرد دستگاه خود را زیر نظر داشته باشید. در طول همگامسازی اولیهی گره شما، ممکن است نرمافزار کلاینت برای پردازنده و رم بسیار سنگین باشد. علاوه بر Grafana میتوانید از ابزارهایی که سیستمعاملتان به شما ارائه میدهد، مثل `htop` یا `uptime`، برای این کار استفاده کنید.
+برای نظارت صحیح بر گره خود، معیارهای تجمعی را در نظر بگیرید. کلاینتها نقاط پایانی معیارها را ارائه میکنند تا بتوانید دادههای جامعی درباره گره خود دریافت کنید. از ابزارهایی مثل [InfluxDB](https://www.influxdata.com/get-influxdb/) یا [Prometheus](https://prometheus.io/) برای ساخت پایگاه دادههایی استفاده کنید که میتوانید با استفاده از نرمافزارهایی مثل [Grafana](https://grafana.com/) آنها را تبدیل به بازنمایی بصری و نمودار کنید. تنظیمات زیادی برای استفاده از این نرمافزار و داشبوردهای مختلف Grafana وجود دارد تا بتوانید گره خود و شبکه را کاملاً به شکل بصری بازنمایی کنید. برای مثال، [آموزش نظارت بر Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/) را بررسی کنید.
+
+بهعنوان بخشی از نظارت خود، مطمئن شوید که عملکرد دستگاه خود را زیر نظر داشته باشید. در طول همگامسازی اولیهی گره شما، ممکن است نرمافزار کلاینت برای پردازنده و رم بسیار سنگین باشد. علاوه بر Grafana میتوانید از ابزارهایی که سیستمعاملتان به شما ارائه میدهد، مثل `htop` یا `uptime`، برای این کار استفاده کنید.
## بیشتر بخوانید {#further-reading}
-- [تحلیل نیازهای سختافزاری برای تبدیل شدن به یک گرهی کامل معتبر اتریوم](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _- آلبرت پالا، 24 سپتامبر 2018_
-- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _- جاستین لروکس، 7 نوامبر 2019_
-- [اجرای یک گرهی Besu هایپرلجر روی شبکهی اصلی اتریوم: مزایا، نیازمندیها و راهاندازی](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _- فلیپ فراگی، 7 مه 2020_
-- [بکارگیری کلاینت اتریوم Nethermind با پشتهی نظارت](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _- Nethermind.eth، 8 جولای 2020_
+- [راهنماهای سهام گذاری اتریوم](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat، به روز رسانی مکرر_
+- [راهنما | نحوه ایجاد یک اعتبارسنج برای سس اتریوم در شبکه اصلی](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet)_- CoinCashew مرتباً به روز میشود_
+- [راهنماهای ETHStaker درباره اجرای اعتبارسنج در شبکهی تست](https://github.com/remyroy/ethstaker#guides) – _ETHStaker، مرتباً بهروز میشود_
+- [سوالات متداول ادغام برای اپراتورهای نود](https://notes.ethereum.org/@launchpad/node-faq-merge) - _جولای 2022_
+- [تحلیل نیازمندیهای سختافزاری برای تبدیل شدن به یک گرهی کامل معتبر اتریوم](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– آلبرت پالا، 24 سپتامبر 2018_
+- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جاستین لروکس، 7 نوامبر 2019_
+- [اجرای یک گرهی هایپرلجر Besu روی شبکهی اصلی اتریوم: مزایا، نیازمندیها و راهاندازی](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– فلیپ فراگی، 7 مه 2020_
+- [بهکارگیری کلاینت اتریوم Nethermind با پشتهی نظارت](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _- Nethermind.eth، 8 ژوئیه 2020_
## موضوعات مرتبط {#related-topics}
-- [گرهها و کلاینتها](/developers/docs/nodes-and-clients/)
+- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
- [بلوکها](/developers/docs/blocks/)
- [شبکهها](/developers/docs/networks/)
diff --git a/public/content/translations/fa/developers/docs/oracles/index.md b/public/content/translations/fa/developers/docs/oracles/index.md
new file mode 100644
index 00000000000..64c34080230
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/oracles/index.md
@@ -0,0 +1,433 @@
+---
+title: Oracles
+description: اوراکلها قراردادهای هوشمند اتریوم را با دسترسی به دادههای دنیای واقعی، باز کردن موارد استفاده بیشتر و ارزش بیشتر برای کاربران فراهم میکند.
+lang: fa
+---
+
+اوراکلها برنامههایی هستند که فیدهای داده تولید میکنند که منابع داده خارج از زنجیره را برای قراردادهای هوشمند در دسترس بلاکچین قرار میدهند. این امر ضروری است زیرا قراردادهای هوشمند مبتنی بر اتریوم به طور پیش فرض نمیتوانند به اطلاعات ذخیره شده خارج از شبکه بلاکچین دسترسی داشته باشند.
+
+دادن قابلیت اجرای قراردادهای هوشمند با استفاده از دادههای خارج از زنجیره، کاربرد و ارزش برنامههای غیرمتمرکز را گسترش میدهد. به عنوان مثال، بازارهای پیشبینی زنجیرهای به اوراکلها برای ارائه اطلاعاتی درباره نتایجی که برای اعتبارسنجی پیشبینیهای کاربر استفاده میکنند، متکی هستند. فرض کنید آلیس 20 ETH بر روی این که چه کسی رئیس جمهور آینده ایالات متحده آمریکا خواهد شد، شرط ببندد. در آن صورت، پیشبینی بازار به یک اوراکل برای تأیید نتایج انتخابات و تعیین اینکه آیا آلیس (Alice) واجد شرایط پرداخت است یا خیر، نیاز دارد.
+
+## موارد مورد نیاز {#prerequisites}
+
+این صفحه فرض میکند که خواننده با مفاهیم پایه اتریوم از جمله [گرهها](/developers/docs/nodes-and-clients/)، [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) و [ماشین مجازی اتریوم یا EVM](/developers/docs/evm/) آشنا میباشد. همچنین شما باید درک خوبی از [قراردادهای هوشمند](/developers/docs/smart-contracts/) و [ساختار قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/)، مخصوصاً [رویدادها](/glossary/#events) داشته باشید.
+
+## اوراکل بلاکچین چیست؟ {#what-is-a-blockchain-oracle}
+
+اوراکلها برنامههایی هستند که اطلاعات خارجی (یعنی اطلاعات ذخیره شده خارج از زنجیره) را به قراردادهای هوشمند در حال اجرا بر روی بلاکچین منبع، تأیید و انتقال میدهند. علاوه بر «پول کردن» دادههای خارج از زنجیره و پخش آن در اتریوم، اوراکلها همچنین میتوانند اطلاعات را از بلاکچین به سیستمهای خارجی «پوش» کنند، بهعنوان مثال، زمانی که کاربر هزینهای را از طریق تراکنش اتریوم ارسال میکند، قفل هوشمند را باز کند.
+
+بدون اوراکل، یک قرارداد هوشمند به طور کامل به دادههای زنجیرهای محدود میشود.
+
+اوراکلها بر اساس منبع دادهها (یک یا چند منبع)، مدلهای قابل اعتماد (متمرکز یا غیرمتمرکز)، و معماری سیستم (خواندن فوری، انتشار، اشتراک، و درخواست-پاسخ) متفاوت هستند. ما همچنین میتوانیم بین اوراکلها تمایز قائل شویم که آیا آنها دادههای خارجی را برای استفاده توسط قراردادهای روی زنجیره (اوراکلهای ورودی) بازیابی میکنند، اطلاعات را از زنجیره بلاک به برنامههای خارج از زنجیره (اوراکلهای خروجی) ارسال میکنند یا وظایف محاسباتی را خارج از زنجیره انجام میدهند (اوراکلهای محاسباتی).
+
+## چرا قراردادهای هوشمند به اوراکل نیاز دارند؟ {#why-do-smart-contracts-need-oracles}
+
+بسیاری از توسعه دهندگان قراردادهای هوشمند را به عنوان کدی می بینند که در آدرسهای خاصی در بلاکچین اجرا میشود. با این حال، [دیدگاه کلیتر قراردادهای هوشمند](/smart-contracts/) این است که آنها برنامههای نرمافزاری خود-اجرای هستند که قادر به اجرای توافقات بین طرفین پس از برآورده شدن شرایط خاص هستند - از این رو به این اصطلاح قراردادهای هوشمند میگوییم.»
+
+اما استفاده از قراردادهای هوشمند برای اجرای توافقات بین افراد، با توجه به اینکه اتریوم قطعی است، ساده نیست. یک [سیستم قطعی](https://en.wikipedia.org/wiki/Deterministic_algorithm) سیستمی است که همیشه نتایج یکسانی را با توجه به وضعیت اولیه و یک ورودی خاص تولید میکند، به این معنی که تصادفی یا تغییر در فرآیند محاسبه خروجیها از ورودی ها وجود ندارد.
+
+برای دستیابی به اجرای قطعی، بلاک چینها گرهها را به اجماع در مورد سؤالات باینری ساده (درست/نادرست) با استفاده از _فقط_ دادههای ذخیره شده در خود بلاک چین محدود میکنند. نمونههایی از این گونه سوالات عبارتند از:
+
+- "آیا مالک حساب (که با یک کلید عمومی مشخص میشود) این تراکنش را با کلید خصوصی جفت شده امضا کرده است؟"
+- "آیا این حساب دارای وجوه کافی برای پوشش تراکنش است؟"
+- «آیا این معامله در چارچوب این قرارداد هوشمند معتبر است؟» و غیره.
+
+اگر بلاکچینها اطلاعاتی را از منابع خارجی (یعنی از دنیای واقعی) دریافت میکردند، دستیابی به جبر غیرممکن خواهد بود و از توافق گرهها در مورد اعتبار تغییرات در وضعیت بلاک چین جلوگیری میکند. به عنوان مثال یک قرارداد هوشمند را در نظر بگیرید که یک تراکنش را بر اساس نرخ ارز فعلی اتر-USD به دست آمده از یک API قیمت سنتی انجام میدهد. این رقم احتمالاً اغلب تغییر میکند (غیر از اینکه API ممکن است منسوخ یا هک شود)، به این معنی که گره یا همان نودهایی که کد قرارداد یکسانی را اجرا میکنند به نتایج متفاوتی میرسند.
+
+برای یک بلاک چین عمومی مانند اتریوم، با هزاران گره در سراسر جهان که تراکنشها را پردازش میکنند، جبرگرایی بسیار مهم است. بدون هیچ مرجع مرکزی به عنوان منبع حقیقت، گرهها به مکانیزمهایی برای رسیدن به همان حالت پس از اعمال همان تراکنشها نیاز دارند. موردی که به موجب آن گره یا نود A کد قرارداد هوشمند را اجرا میکند و در نتیجه "3" دریافت میکند، در حالی که گره یا نود B پس از اجرای همان تراکنش، "7" را دریافت میکند، باعث میشود اجماع از بین برود و ارزش اتریوم به عنوان یک پلتفرم محاسباتی غیرمتمرکز را حذف کند.
+
+این سناریو همچنین مشکل طراحی بلاکچین برای استخراج اطلاعات از منابع خارجی را مطرح میکند. با این حال، اوراکل این مشکل را با گرفتن اطلاعات از منابع خارج از زنجیره و ذخیره آن در بلاکچین برای مصرف قراردادهای هوشمند حل میکند. از آنجایی که اطلاعات ذخیره شده در زنجیره غیرقابل تغییر و در دسترس عموم است، گره یا نودهای اتریوم میتوانند با خیال راحت از دادههای خارج از زنجیره وارد شده اوراکل برای محاسبه تغییرات حالت بدون اجماع استفاده کنند.
+
+برای انجام این کار، اوراکل معمولاً از یک قرارداد هوشمند در حال اجرا بر روی زنجیره و برخی از اجزای خارج از زنجیره تشکیل شده است. قرارداد روی زنجیره درخواستهایی برای دادهها از سایر قراردادهای هوشمند دریافت میکند، که آنها را به جزء خارج از زنجیره (به نام گره اوراکل) ارسال میکند. این گره یا نود اوراکل میتواند منابع داده را جستجو کند - برای مثال با استفاده از رابطهای برنامهنویسی کاربردی (API) - و تراکنشهایی را برای ذخیره دادههای درخواستی در فضای ذخیرهسازی قرارداد هوشمند ارسال کند.
+
+اساساً یک اوراکل بلاک چین، شکاف اطلاعاتی بین بلاک چین و محیط خارجی را پر کرده و "قراردادهای هوشمند ترکیبی" ایجاد میکند. قرارداد هوشمند ترکیبی قراردادی است که بر اساس ترکیبی از کد قرارداد درون زنجیرهای و زیرساخت خارج از زنجیره عمل میکند. بازارهای پیشبینی غیرمتمرکز نمونهای عالی از قراردادهای هوشمند ترکیبی هستند. نمونههای دیگر ممکن است شامل قراردادهای هوشمند بیمه محصولات باشد که زمانی پرداخت میشوند که مجموعهای از اوراکلها تشخیص دهند که پدیدههای آب و هوایی خاصی رخ داده است.
+
+## مشکل اوراکل چیست؟ {#the-oracle-problem}
+
+اوراکلها یک مشکل مهم را حل میکنند، اما برخی از عوارض را نیز معرفی میکنند، به عنوان مثال:
+
+- چگونه بررسی کنیم که اطلاعات وارد شده از منبع صحیح استخراج شده یا دستکاری نشده است؟
+
+- چگونه اطمینان حاصل کنیم که این دادهها همیشه در دسترس هستند و به طور منظم به روز میشوند؟
+
+به اصطلاح "مشکل اوراکل" مشکلاتی را که با استفاده از اوراکلهای بلاک چین برای ارسال ورودی به قراردادهای هوشمند به وجود میآید را نشان میدهد. برای اجرای صحیح قرارداد هوشمند، دادههای اوراکل باید صحیح باشد. علاوه بر این، نیاز به «اعتماد» به اپراتورهای اوراکل برای ارائه اطلاعات دقیق، جنبه «بدون نیاز به اعتماد» قراردادهای هوشمند را تضعیف میکند.
+
+اوراکلهای مختلف راهحلهای متفاوتی برای مشکل اوراکل ارائه میکنند که در ادامه به بررسی آنها میپردازیم. اوراکلها معمولاً بر این اساس ارزیابی میشوند که چگونه میتوانند چالشهای زیر را مدیریت کنند:
+
+1. **صحت**: اوراکل نباید باعث شود که قراردادهای هوشمند تغییرات حالت را بر اساس دادههای خارج از زنجیره نامعتبر ایجاد کنند. اوراکل باید _اصالت_ و _یکپارچگی_ دادهها را تضمین کند. اصالت به این معنی است که دادهها از منبع صحیح دریافت شدهاند، در حالی که یکپارچگی به این معنی است که دادهها قبل از ارسال روی زنجیره دست نخورده باقی ماندهاند (یعنی تغییر نکردهاند).
+
+2. **در دسترس بودن**: اوراکل نباید قراردادهای هوشمند را از اجرای اقدامات و ایجاد تغییرات حالت به تاخیر بیاندازد یا از آن جلوگیری کند. این بدان معناست که دادههای یک اوراکل باید بدون وقفه _در صورت درخواست در دسترس باشد_.
+
+3. **سازگاری انگیزه**: اوراکل باید ارائه دهندگان دادههای خارج از زنجیره را تشویق کند تا اطلاعات صحیح را به قراردادهای هوشمند ارسال کنند. سازگاری انگیزه شامل _قابلیت انتساب_ و _پاسخگویی_ است. قابلیت انتساب امکان پیوند بخشی از اطلاعات خارجی را به ارائهدهنده آن فراهم میکند، در حالی که مسئولیتپذیری ارائهدهندگان دادهها را به اطلاعاتی که میدهند پیوند میدهد، بنابراین میتوانند بر اساس کیفیت اطلاعات ارائهشده پاداش یا جریمه شوند.
+
+## سرویس اوراکل بلاک چین چگونه کار میکند؟ {#how-does-a-blockchain-oracle-service-work}
+
+### کاربران {#users}
+
+کاربران موجودیتهایی (یعنی قراردادهای هوشمند) هستند که برای انجام اقدامات خاص به اطلاعات خارج از بلاک چین نیاز دارند. گردش کار اصلی یک سرویس اوراکل با ارسال درخواست داده توسط کاربر به قرارداد اوراکل شروع میشود. درخواستهای داده معمولاً به برخی یا همه سؤالات زیر پاسخ میدهند:
+
+1. گرههای خارج از زنجیره میتوانند برای اطلاعات درخواستی از چه منابعی استفاده کنند؟
+
+2. گزارشگران چگونه اطلاعات را از منابع داده پردازش میکنند و نقاط داده مفید را استخراج میکنند؟
+
+3. چه تعداد گره یا نود اوراکل میتوانند در بازیابی دادهها شرکت کنند؟
+
+4. چگونه باید مغایرتهای گزارشهای اوراکل را مدیریت کرد؟
+
+5. چه روشی باید در فیلتر کردن مطالب ارسالی و تجمیع گزارشها در یک مقدار واحد اجرا شود؟
+
+### قرارداد اوراکل {#oracle-contract}
+
+قرارداد اوراکل جزء زنجیرهای برای سرویس اوراکل است. به درخواستهای داده از قراردادهای دیگر گوش میدهد، پرس و جوهای داده را به گرههای اوراکل رله کرده و دادههای برگشتی را به قراردادهای کلاینت پخش میکند. این قرارداد همچنین ممکن است برخی از محاسبات را روی نقاط داده برگشتی انجام دهد تا یک مقدار مجموع برای ارسال به قرارداد درخواست کننده ایجاد کند.
+
+قرارداد اوراکل برخی از توابع را نشان میدهد که قراردادهای کلاینت هنگام درخواست داده آنها را فراخوانی میکنند. پس از دریافت یک درخواست جدید، قرارداد هوشمند یک [رویداد گزارش یا همان ایونت لاگ](/developers/docs/smart-contracts/anatomy/#events-and-logs) را با جزئیات درخواست داده ارسال میکند. این مورد به گرههای خارج از زنجیره مشترک در گزارش (معمولاً از چیزی مانند دستور JSON-RPC `eth_subscribe` استفاده میکند)، که به بازیابی دادههای تعریفشده در رویداد لاگ میپردازند.
+
+در زیر یک [نمونه قرارداد اوراکل](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) توسط پدرو کاستا آمده است. این یک سرویس اوراکل ساده است که میتواند در صورت درخواست سایر قراردادهای هوشمند، APIهای خارج از زنجیره را جستجو کند و اطلاعات درخواستی را در زنجیره بلوکی ذخیره کند:
+
+```solidity
+pragma solidity >=0.4.21 <0.6.0;
+
+contract Oracle {
+ Request[] requests; //list of requests made to the contract
+ uint currentId = 0; //increasing request id
+ uint minQuorum = 2; //minimum number of responses to receive before declaring final result
+ uint totalOracleCount = 3; // Hardcoded oracle count
+
+ // defines a general api request
+ struct Request {
+ uint id; //request id
+ string urlToQuery; //API url
+ string attributeToFetch; //json attribute (key) to retrieve in the response
+ string agreedValue; //value from key
+ mapping(uint => string) answers; //answers provided by the oracles
+ mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted)
+ }
+
+ //event that triggers oracle outside of the blockchain
+ event NewRequest (
+ uint id,
+ string urlToQuery,
+ string attributeToFetch
+ );
+
+ //triggered when there's a consensus on the final result
+ event UpdatedRequest (
+ uint id,
+ string urlToQuery,
+ string attributeToFetch,
+ string agreedValue
+ );
+
+ function createRequest (
+ string memory _urlToQuery,
+ string memory _attributeToFetch
+ )
+ public
+ {
+ uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
+ Request storage r = requests[length-1];
+
+ // Hardcoded oracles address
+ r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
+ r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
+ r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
+
+ // launch an event to be detected by oracle outside of blockchain
+ emit NewRequest (
+ currentId,
+ _urlToQuery,
+ _attributeToFetch
+ );
+
+ // increase request id
+ currentId++;
+ }
+
+ //called by the oracle to record its answer
+ function updateRequest (
+ uint _id,
+ string memory _valueRetrieved
+ ) public {
+
+ Request storage currRequest = requests[_id];
+
+ //check if oracle is in the list of trusted oracles
+ //and if the oracle hasn't voted yet
+ if(currRequest.quorum[address(msg.sender)] == 1){
+
+ //marking that this address has voted
+ currRequest.quorum[msg.sender] = 2;
+
+ //iterate through "array" of answers until a position if free and save the retrieved value
+ uint tmpI = 0;
+ bool found = false;
+ while(!found) {
+ //find first empty slot
+ if(bytes(currRequest.answers[tmpI]).length == 0){
+ found = true;
+ currRequest.answers[tmpI] = _valueRetrieved;
+ }
+ tmpI++;
+ }
+
+ uint currentQuorum = 0;
+
+ //iterate through oracle list and check if enough oracles(minimum quorum)
+ //have voted the same answer as the current one
+ for(uint i = 0; i < totalOracleCount; i++){
+ bytes memory a = bytes(currRequest.answers[i]);
+ bytes memory b = bytes(_valueRetrieved);
+
+ if(keccak256(a) == keccak256(b)){
+ currentQuorum++;
+ if(currentQuorum >= minQuorum){
+ currRequest.agreedValue = _valueRetrieved;
+ emit UpdatedRequest (
+ currRequest.id,
+ currRequest.urlToQuery,
+ currRequest.attributeToFetch,
+ currRequest.agreedValue
+ );
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+### گره یا نودهای اوراکل {#oracle-nodes}
+
+گره یا نود اوراکل جزء خارج از زنجیره سرویس اوراکل است. این اطلاعات را از منابع خارجی، مانند APIهای میزبانی شده در سرورهای شخص ثالث استخراج میکند و آن را برای مصرف قراردادهای هوشمند در زنجیره قرار میدهد. گره یا نودهای اوراکل به رویدادهای قرارداد اوراکل روی زنجیره گوش میدهند و به تکمیل کار توضیح داده شده در گزارش ادامه میدهند.
+
+یک کار رایج برای نودهای اوراکل ارسال یک درخواست [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) به یک سرویس API، تجزیه پاسخ برای استخراج دادههای مرتبط است. فرمت کردن به یک خروجی قابل خواندن از طریق بلاک چین و ارسال آن در زنجیره (آنچین) با گنجاندن آن در تراکنش به قرارداد اوراکل است. همچنین ممکن است به گره یا نود اوراکل نیاز باشد تا اعتبار و یکپارچگی اطلاعات ارسالی را با استفاده از «اثبات اصالت» تأیید کند، که بعداً بررسی خواهیم کرد.
+
+اوراکلهای محاسباتی همچنین به گره یا نودهای خارج از زنجیره برای انجام وظایف محاسباتی متکی هستند که با توجه به هزینههای گس و محدودیت اندازه بلوک، اجرای آنها در زنجیره غیرعملی است. به عنوان مثال، گره یا نود اوراکل ممکن است وظیفه تولید یک رقم تصادفی قابل تأیید را داشته باشد (به عنوان مثال، برای بازیهای مبتنی بر بلاکچین).
+
+## الگوهای طراحی اوراکل {#oracle-design-patterns}
+
+اوراکلها انواع مختلفی دارند، از جمله _خواندن فوری_، _publish-subscribe_، و _Request-Response_، که دو مورد اخیر محبوبترین در میان قراردادهای هوشمند اتریوم هستند. در اینجا به طور خلاصه مدلهای انتشار-اشتراک و درخواست-پاسخ را توضیح میدهیم.
+
+### اوراکلهای انتشار و اشتراک {#publish-subscribe-oracles}
+
+این نوع اوراکل یک "فید داده" را در معرض دید قرار میدهد که سایر قراردادها میتوانند به طور منظم برای اطلاعات بخوانند. انتظار میرود که دادهها در این مورد به طور مکرر تغییر کنند، بنابراین قراردادهای مشتری باید برای بهروزرسانی دادههای ذخیرهسازی اوراکل گوش (listen) (نوعی از اصطلاحات در خصوص برنامه نویسی) دهند. به عنوان مثال اوراکلی است که آخرین اطلاعات قیمت ETH-USD را در اختیار کاربران قرار میدهد.
+
+### اوراکلهای درخواست-پاسخ {#request-response-oracles}
+
+تنظیم درخواست-پاسخ به قرارداد مشتری یا کلاینت اجازه میدهد تا دادههای دلخواه را غیر از آنچه توسط یک اوراکل انتشار-اشتراک ارائه میشود، درخواست کند. اوراکلهای درخواست-پاسخ زمانی ایدهآل هستند که مجموعه داده آنقدر بزرگ است که نمیتوان آنها را در فضای ذخیرهسازی قرارداد هوشمند ذخیره کرد و/یا کاربران تنها به بخش کوچکی از دادهها در هر مقطع زمانی نیاز خواهند داشت.
+
+اگرچه پیچیدهتر از مدلهای انتشار-اشتراک است، اما اوراکلهای درخواست پاسخ اساساً همان چیزی است که در بخش قبل توضیح دادیم. اوراکل دارای یک جزء روی زنجیره خواهد بود که درخواست داده را دریافت کرده و آن را برای پردازش به یک گره یا نود خارج از زنجیره ارسال میکند.
+
+کاربرانی که درخواستهای داده را آغاز میکنند باید هزینه بازیابی اطلاعات از منبع خارج از زنجیره را پوشش دهند. همچنین قرارداد کلاینت باید وجوهی را برای پوشش هزینههای گس متحمل شده توسط قرارداد اوراکل در بازگرداندن پاسخ از طریق تابع کالبک به تماس مشخص شده در درخواست فراهم کند.
+
+## اوراکلهای متمرکز در مقابل غیرمتمرکز {#types-of-oracles}
+
+### اوراکلهای متمرکز {#centralized-oracles}
+
+یک اوراکل متمرکز توسط یک نهاد واحد کنترل میشود که مسئول جمعآوری اطلاعات خارج از زنجیره و به روز رسانی دادههای قرارداد اوراکل در صورت درخواست است. اوراکلهای متمرکز کارآمد هستند زیرا بر یک منبع حقیقی تکیه دارند. آنها ممکن است در مواردی که مجموعه دادههای اختصاصی مستقیماً توسط مالک با امضای پذیرفته شده منتشر میشود بهتر عمل کنند. با این حال، آنها جنبههای منفی نیز دارند:
+
+#### صحت کم را تضمین میکند {#low-correctness-guarantees}
+
+با اوراکلهای متمرکز، هیچ راهی برای تأیید صحت یا عدم صحت اطلاعات ارائه شده وجود ندارد. حتی ارائه دهندگان "معتبر" میتوانند سرکش یا هک شوند. اگر اوراکل فاسد شود، قراردادهای هوشمند بر اساس دادههای نامناسب اجرا میشوند.
+
+#### در دسترس بودن ضعیف {#poor-availability}
+
+اوراکلهای متمرکز تضمین نمیکنند که همیشه دادههای خارج از زنجیره را در اختیار سایر قراردادهای هوشمند قرار دهند. اگر ارائهدهنده تصمیم بگیرد سرویس را خاموش کند یا هکری مؤلفه خارج از زنجیره اوراکل را ربود، قرارداد هوشمند شما در معرض خطر حمله انکار سرویس (DoS) قرار دارد.
+
+#### سازگاری انگیزشی ضعیف {#poor-incentive-compatibility}
+
+اوراکلهای متمرکز اغلب با انگیزههای ضعیفی طراحی شده یا برای ارائهدهنده داده برای ارسال اطلاعات دقیق/بدون تغییر وجود ندارند. پرداخت به اوراکل برای صحت، صداقت را تضمین نمیکند. این مشکل با افزایش مقدار ارزش کنترل شده توسط قراردادهای هوشمند بزرگتر میشود.
+
+### اوراکلهای غیرمتمرکز {#decentralized-oracles}
+
+اوراکلهای غیرمتمرکز برای غلبه بر محدودیتهای اوراکلهای متمرکز با حذف نقاط شکست منفرد طراحی شدهاند. یک سرویس غیرمتمرکز اوراکل شامل چندین شرکتکننده در یک شبکه همتا به همتا است که قبل از ارسال آن به یک قرارداد هوشمند، روی دادههای خارج از زنجیره یا آفچین اتفاق نظر دارند.
+
+یک اوراکل غیرمتمرکز (در حالت ایده آل) باید بدون مجوز، بدون اعتماد و عاری از اداره یک حزب مرکزی باشد؛ در واقعیت، تمرکززدایی در میان اوراکل ها در یک طیف است. شبکههای اوراکل نیمه غیرمتمرکز وجود دارد که هر کسی میتواند در آن شرکت کند، اما با یک «مالک» که گرهها را بر اساس عملکرد تاریخی تأیید و حذف میکند باشد. شبکههای اوراکل کاملاً غیرمتمرکز نیز وجود دارند: این شبکهها معمولاً بهعنوان زنجیرههای بلوکی یا همان بلاکچین مستقل اجرا میشوند و مکانیزمهای اجماع مشخصی برای هماهنگ کردن گرهها و مجازات رفتارهای نادرست دارند.
+
+استفاده از اوراکلهای غیرمتمرکز دارای مزایای زیر است:
+
+### صحت بالا را تضمین میکند {#high-correctness-guarantees}
+
+اوراکلهای غیرمتمرکز تلاش میکنند تا با استفاده از رویکردهای مختلف به صحت دادهها دست یابند. این مورد شامل استفاده از شواهدی است که صحت و یکپارچگی اطلاعات بازگردانده شده را تأیید میکند و لازم است چندین نهاد به طور جمعی در مورد اعتبار دادههای خارج از زنجیره به توافق برسند.
+
+#### اثبات اصالت {#authenticity-proofs}
+
+اثبات اصالت مکانیزمهای رمزنگاری هستند که امکان تأیید مستقل اطلاعات بازیابی شده از منابع خارجی را فراهم میکنند. این شواهد میتوانند منبع اطلاعات را تایید و تغییرات احتمالی دادهها را پس از بازیابی شناسایی کنند.
+
+نمونههایی از اثبات اصالت عبارتند از:
+
+**اثبات امنیت لایه انتقال (TLS)**: گرههای اوراکل اغلب دادهها را با استفاده از یک اتصال HTTP ایمن بر اساس پروتکل امنیت لایه انتقال (TLS) از منابع خارجی بازیابی میکنند. برخی از اوراکلهای غیرمتمرکز برای تأیید جلسات TLS (یعنی تأیید تبادل اطلاعات بین یک گره و یک سرور خاص) و تأیید عدم تغییر محتویات جلسه، از اثباتهای اعتبار یا اصالت استفاده میکنند.
+
+**تأییدات محیط اجرای مورد اعتماد (TEE)**: یک [محیط اجرای مورد اعتماد](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) یک محیط محاسباتی سندباکس شده است که از فرآیندهای عملیاتی سیستم میزبان خود جدا شده است. TEEها اطمینان حاصل میکنند که هر کد برنامه یا دادهای که در محیط محاسباتی ذخیره/استفاده میشود، یکپارچگی، محرمانه بودن و تغییرناپذیری را حفظ میکند. همچنین کاربران میتوانند یک گواهی برای اثبات اینکه یک نمونه برنامه در محیط اجرای مورد اعتماد اجرا میشود، ایجاد کنند.
+
+کلاسهای خاصی از اوراکلهای غیرمتمرکز به اپراتورهای گره اوراکل برای ارائه گواهی TEE نیاز دارند. این مورد به کاربر تأیید میکند که اپراتور گره نمونهای از سرویس گیرنده اوراکل را در یک محیط اجرای مطمئن اجرا میکند. TEEها از تغییر یا خواندن کد و دادههای برنامه توسط فرآیندهای خارجی جلوگیری میکنند، از این رو، این گواهیها ثابت میکنند که گره اوراکل اطلاعات را دست نخورده و محرمانه نگه داشته است.
+
+#### اعتبارسنجی مبتنی بر اجماع اطلاعات {#consensus-based-validation-of-information}
+
+اوراکلهای متمرکز هنگام ارائه دادهها به قراردادهای هوشمند به یک منبع حقیقت تکیه میکنند که امکان انتشار اطلاعات نادرست وجود دارد. اوراکلهای غیرمتمرکز این مشکل را با تکیه بر چندین گره اوراکل برای جستجوی اطلاعات خارج از زنجیره حل میکنند. با مقایسه دادههای چند منبع، اوراکلهای غیرمتمرکز خطر انتقال اطلاعات نامعتبر به قراردادهای زنجیرهای را کاهش میدهند.
+
+با این حال، اوراکلهای غیرمتمرکز باید با اختلافات در اطلاعات بازیابی شده از چندین منبع خارج از زنجیره مقابله کنند. برای به حداقل رساندن تفاوتها در اطلاعات و اطمینان از اینکه دادههای ارسال شده به قرارداد اوراکل منعکسکننده نظر جمعی گرههای اوراکل است، اوراکلهای غیرمتمرکز از مکانیزمهای زیر استفاده میکنند:
+
+##### رای دادن/استیک کردن در مورد صحت دادهها
+
+برخی از شبکههای اوراکل غیرمتمرکز از شرکتکنندگان میخواهند که در صحت پاسخهای پرسشهای داده رای دهند یا در مورد صحت پاسخها استیک کنند (به عنوان مثال، "چه کسی در انتخابات 2020 ایالات متحده پیروز شد؟") با استفاده از توکن بومی شبکه. سپس یک پروتکل تجمیع آرا و سهام را جمع میکند و پاسخی را که اکثریت پشتیبانی میکند به عنوان پاسخ معتبر میگیرد.
+
+گرههایی که پاسخ آنها از پاسخ اکثریت منحرف میشود، با توزیع توکنهایشان به دیگرانی که مقادیر صحیحتری ارائه میدهند، جریمه میشوند. اجبار گره یا نودها برای ایجاد پیوند قبل از ارائه دادهها، انگیزه پاسخهای صادقانه را فراهم میکند، زیرا فرض میشود که آنها افراد اقتصادی منطقی هستند که قصد دارند بازده را به حداکثر برسانند.
+
+استیک/رایگیری همچنین از اوراکلهای غیرمتمرکز در برابر [حملات سبیل](/glossary/#sybil-attack) محافظت میکند که در آن عوامل مخرب چندین هویت را برای بازی با سیستم اجماع ایجاد میکنند. با این حال، استیک نمیتواند از "بارگذاری رایگان" (گرههای اوراکل که اطلاعات را از دیگران کپی میکنند) و "اعتبارسنجی تنبل" (گرههای اوراکل اکثریت را بدون تأیید اطلاعات خود دنبال میکنند) جلوگیری کند.
+
+##### مکانیزمهای نقطه هدف
+
+[نقطه هدف](https://en.wikipedia.org/wiki/Focal_point_(game_theory)) یک مفهوم تئوری است که فرض میکند چندین موجودیت همیشه به طور پیشفرض به یک راهحل مشترک برای یک مشکل در عدم وجود هرگونه ارتباط میرسند. مکانیسمهای شلینگ پوینت (Schelling-point) اغلب در شبکههای اوراکل غیرمتمرکز استفاده میشوند تا گره یا نودها را قادر میسازد در مورد پاسخ به درخواستهای داده به توافق برسند.
+
+ایده اولیه برای این [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) بود، فید داده پیشنهادی که در آن شرکتکنندگان پاسخهایی را به سؤالات «اسکالر» (سوالاتی که پاسخهای آنها با بزرگی توصیف میشود، بهعنوان مثال، «قیمت اتریوم چقدر است؟») همراه با سپرده ارسال میکنند. کاربرانی که مقادیری را بین 25 و 75 [درصد](https://en.wikipedia.org/wiki/Percentile) ارائه میکنند، پاداش میگیرند، در حالی که آنهایی که مقادیرشان تا حد زیادی از مقدار متوسط انحراف دارد، جریمه میشوند.
+
+در حالی که SchellingCoin امروزه وجود ندارد، تعدادی اوراکل غیرمتمرکز—به ویژه [پروتکل سازندگان اوراکلها](https://docs.makerdao.com/smart-contract-modules/oracle-module)—از مکانیزم نقطه هدف برای بهبود دقت دادههای اوراکل استفاده میکردند. هر Maker Oracle متشکل از یک شبکه P2P خارج از زنجیره از گرهها ("relayers" و "feed") است که قیمتهای بازار را برای داراییهای وثیقه ارسال کرده و یک قرارداد "Medianizer" درون زنجیرهای که میانگین تمام ارزشهای ارائهشده را محاسبه میکند. پس از پایان دوره تاخیر مشخص شده، این مقدار متوسط به قیمت مرجع جدید برای دارایی مرتبط تبدیل میشود.
+
+نمونههای دیگر اوراکلهایی که از مکانیزمهای نقطه هدف استفاده میکنند عبارتند از [گزارشدهی خارج از زنجیره چین لینک](https://docs.chain.link/docs/off-chain-reporting/) و [Witnet](https://witnet.io/). در هر دو سیستم، پاسخهای گره یا نودهای اوراکل در شبکه همتا به همتا در یک مقدار مجموع، مانند میانگین یا میانه، تجمیع میشوند. گره یا نودها با توجه به میزانی که پاسخ هایشان با مقدار کل همسو یا انحراف دارد، پاداش یا مجازات میشوند.
+
+مکانیسمهای شلینگ پوینت (Schelling point) جذاب هستند زیرا ردپای روی زنجیره را به حداقل میرسانند (فقط یک تراکنش باید ارسال شود) در حالی که تمرکززدایی را تضمین میکند. مورد دوم امکانپذیر است زیرا گرهها باید قبل از وارد شدن به الگوریتمی که مقدار میانگین/میانگین را تولید میکند، در لیست پاسخهای ارسالی امضا کنند.
+
+### در دسترس بودن {#availability}
+
+خدمات غیرمتمرکز اوراکل در دسترس بودن بالای دادههای خارج از زنجیره را برای قراردادهای هوشمند تضمین میکند. این امر با غیرمتمرکز کردن منبع اطلاعات خارج از زنجیره و گره یا نودهای مسئول انتقال اطلاعات در زنجیره به دست میآید.
+
+این امر تحمل خطا را تضمین میکند زیرا قرارداد اوراکل میتواند به چندین گره یا نود (که همچنین به چندین منبع داده متکی هستند) برای اجرای پرسوجو از قراردادهای دیگر متکی باشد. تمرکززدایی در سطح منبع _و_ گره-اپراتور بسیار مهم است—شبکه ای از گرههای اوراکل که اطلاعات بازیابی شده از یک منبع را ارائه میدهند، با مشکل مشابه یک اوراکل متمرکز مواجه خواهند شد.
+
+همچنین برای اوراکلهای مبتنی بر سهام میتواند اپراتورهای گره یا نودی را که نمیتوانند به سرعت به درخواستهای داده پاسخ دهند، کاهش دهند. این به طور قابل توجهی گره یا نودهای اوراکل را برای سرمایهگذاری در زیرساختهای مقاوم در برابر خطا و ارائه به موقع دادهها تشویق میکند.
+
+### سازگاری انگیزشی خوب {#good-incentive-compatibility}
+
+اوراکلهای غیرمتمرکز طرحهای تشویقی مختلفی را برای جلوگیری از رفتار [بیزانس](https://en.wikipedia.org/wiki/Byzantine_fault) در میان گرههای اوراکل اجرا میکنند. به طور خاص، آنها به _قابلیت انتساب_ و _پاسخگویی_ دست مییابند:
+
+1. گره یا نودهای اوراکل غیرمتمرکز اغلب برای امضای دادههایی که در پاسخ به درخواستهای داده ارائه میکنند مورد نیاز است. این اطلاعات به ارزیابی عملکرد تاریخی گره یا نودهای اوراکل کمک میکند، به طوری که کاربران میتوانند هنگام درخواست داده، گره یا نودهای اوراکل غیرقابل اعتماد را فیلتر کنند. یک مثال [سیستم شهرت الگوریتمی](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) Witnet است.
+
+2. اوراکلهای غیرمتمرکز - همانطور که قبلاً توضیح داده شد - ممکن است به گره یا نودهایی نیاز داشته باشند که در مورد اطمینان خود نسبت به صحت دادههایی که ارسال میکنند، سهمی داشته باشند. در صورت بررسی ادعا، این سهام میتواند همراه با پاداش برای خدمات صادقانه بازگردانده شود. اما در صورت نادرست بودن اطلاعات نیز میتوان آن را کاهش داد، که مقداری از پاسخگویی را فراهم میکند.
+
+## کاربردهای اوراکل در قراردادهای هوشمند {#applications-of-oracles-in-smart-contracts}
+
+موارد زیر موارد استفاده رایج برای اوراکلها در اتریوم است:
+
+### بازیابی اطلاعات مالی {#retrieving-financial-data}
+
+برنامههای [مالی غیرمتمرکز](/defi/) (DeFi) امکان وامدهی، استقراض و معامله داراییها را به صورت همتا به همتا فراهم میکنند. این مورد اغلب مستلزم دریافت اطلاعات مالی مختلف، از جمله دادههای نرخ مبادله (برای محاسبه ارزش فیات ارزهای دیجیتال یا مقایسه قیمتهای توکن) و دادههای بازار سرمایه (برای محاسبه ارزش داراییهای توکنشده، مانند طلا یا دلار آمریکا) است.
+
+به عنوان مثال، یک پروتکل وام دهی دیفای، نیاز به استعلام قیمتهای فعلی بازار برای داراییها (به عنوان مثال، اتر) دارد که به عنوان وثیقه سپرده شده است. این به قرارداد اجازه میدهد تا ارزش داراییهای وثیقه را تعیین کند و تعیین کند که چقدر میتواند از سیستم وام بگیرد.
+
+«اوراکلهای قیمت» محبوب (که معمولاً به آنها گفته میشود) در دیفای شامل فیدهای قیمت زنجیرهای، پروتکل ترکیبی [فید قیمت باز](https://compound.finance/docs/prices) یونی سواپ است. href="https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles">قیمتهای میانگین وزندار زمانی (TWAP) و [میکر اوراکل](https://docs.makerdao.com/smart-contract-modules/oracle-module).
+
+سازندگان باید قبل از ادغام آنها در پروژه خود، اخطارهایی را که با این اوراکلهای قیمت همراه است، درک کنند. این [مقاله](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) تجزیه و تحلیل دقیقی از مواردی که باید در برنامه ریزی برای استفاده از هر یک از اوراکلهای قیمت ذکر شده در نظر بگیرید ارائه میدهد.
+
+در زیر مثالی از نحوه بازیابی آخرین قیمت اتر در قرارداد هوشمند خود با استفاده از فید قیمت زنجیرهای آورده شده است:
+
+```solidity
+pragma solidity ^0.6.7;
+
+import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
+
+contract PriceConsumerV3 {
+
+ AggregatorV3Interface internal priceFeed;
+
+ /**
+ * Network: Kovan
+ * Aggregator: ETH/USD
+ * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
+ */
+ constructor() public {
+ priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
+ }
+
+ /**
+ * Returns the latest price
+ */
+ function getLatestPrice() public view returns (int) {
+ (
+ uint80 roundID,
+ int price,
+ uint startedAt,
+ uint timeStamp,
+ uint80 answeredInRound
+ ) = priceFeed.latestRoundData();
+ return price;
+ }
+}
+```
+
+### ایجاد تصادفی قابل تأیید {#generating-verifiable-randomness}
+
+برخی از برنامههای بلاکچین، مانند بازیهای مبتنی بر بلاکچین یا طرحهای بختآزمایی، به سطح بالایی از غیرقابل پیشبینی و تصادفی بودن نیاز دارند تا به طور مؤثر کار کنند. با این حال، اجرای قطعی بلاکچینها تصادفی بودن را از بین میبرد.
+
+رویکرد اولیه استفاده از توابع رمزنگاری شبه تصادفی، مانند `بلاک هش` بود، اما اینها ممکن [توسط ماینرها](https://ethereum.stackexchange.com/questions/3140/risk-of-using- blockhash-other-miners-preventing-attack#:~:text=است%20که%20the%20miners%20can,to%20one%20of%20the%20players.) برای حل مشکل الگوریتم اثبات کار دستکاری شوند. همچنین، [تغییر به اثبات سهام](/roadmap/merge/) اتریوم به این معنی است که توسعهدهندگان دیگر نمیتوانند برای تصادفی بودن روی زنجیره به `بلاک هش` اعتماد کنند. در عوض، [مکانیزم RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) بیکون چین یک منبع جایگزین برای تصادفی بودن فراهم میکند.
+
+امکان تولید ارزش تصادفی خارج از زنجیره و ارسال آن در زنجیره وجود دارد، اما انجام این کار الزامات اعتماد بالایی را به کاربران تحمیل میکند. آنها باید باور داشته باشند که ارزش واقعی از طریق مکانیسمهای غیرقابل پیشبینی ایجاد شده است و در حمل و نقل تغییر نکرده است.
+
+اوراکلهایی که برای محاسبات خارج از زنجیره طراحی شدهاند، این مشکل را با تولید ایمن نتایج تصادفی خارج از زنجیره که روی زنجیره پخش میکنند همراه با اثباتهای رمزنگاری که غیرقابل پیشبینی بودن فرآیند را تأیید میکنند، حل میکنند. یک مثال [چین لینک VRF](https://docs.chain.link/docs/chainlink-vrf/) (عملکرد تصادفی قابل تأیید) است که یک تولید کننده اعداد تصادفی منصفانه و بدون دستکاری است. (RNG) برای ساخت قراردادهای هوشمند قابل اعتماد برای برنامههایی که بر نتایج غیرقابل پیشبینی تکیه دارند مفید است. مثال دیگر [API3 QRNG](https://docs.api3.org/explore/qrng/) است که تولید اعداد تصادفی کوانتومی (QRNG) را ارائه میکند، یک روش عمومی وب 3 RNG مبتنی بر پدیدههای کوانتومی با هدف ارائه شده توسط دانشگاه ملی استرالیا (ANU) است.
+
+### به دست آوردن نتایج برای رویدادها {#getting-outcomes-for-events}
+
+با اوراکلها، ایجاد قراردادهای هوشمند که به رویدادهای دنیای واقعی پاسخ میدهند، آسان است. خدمات اوراکل با اجازه دادن به قراردادها برای اتصال به APIهای خارجی از طریق اجزای خارج از زنجیره و مصرف اطلاعات از آن منابع داده، این امکان را فراهم میکند. به عنوان مثال، برنامه پیشبینی که قبلاً ذکر شد ممکن است از اوراکل درخواست کند که نتایج انتخابات را از یک منبع معتبر خارج از زنجیره (مثلاً آسوشیتد پرس) بازگرداند.
+
+استفاده از اوراکلها برای بازیابی دادهها بر اساس نتایج دنیای واقعی، سایر موارد استفاده جدید را امکانپذیر میکند. به عنوان مثال، یک محصول بیمه غیرمتمرکز به اطلاعات دقیق در مورد آب و هوا، بلایا و غیره نیاز دارد تا به طور مؤثر کار کند.
+
+### خودکارسازی قراردادهای هوشمند {#automating-smart-contracts}
+
+قراردادهای هوشمند به طور خودکار اجرا نمیشوند. بلکه یک حساب متعلق به خارجی (EOA)، یا یک حساب قرارداد دیگر، باید عملکردهای مناسب را برای اجرای کد قرارداد راه اندازی کند. در بیشتر موارد، بخش عمدهای از وظایف قرارداد عمومی است و میتواند توسط EOA و سایر قراردادها مورد استناد قرار گیرد.
+
+اما همچنین _عملکردهای خصوصی_ در قرارداد وجود دارد که برای دیگران غیرقابل دسترسی است؛ اما برای عملکرد کلی یک برنامه غیرمتمرکز بسیار مهم است. مثالها عبارتند از یک تابع `mintERC721Token()` که به صورت دورهای NFTهای جدید را برای کاربران مینت میکند، تابعی برای اعطای پرداختها در بازار پیشبینی، یا تابعی برای باز کردن قفل توکنهای استیک شده در یک دکس است.
+
+توسعه دهندگان باید چنین عملکردهایی را در فواصل زمانی فعال کنند تا برنامه به خوبی اجرا شود. با این حال، این مورد ممکن است منجر به از دست دادن ساعات بیشتری در انجام کارهای روزمره برای توسعه دهندگان شود، به همین دلیل است که اجرای خودکار قراردادهای هوشمند جذاب است.
+
+برخی از شبکههای اوراکل غیرمتمرکز خدمات اتوماسیون را ارائه میکنند که به گرههای اوراکل خارج از زنجیره اجازه میدهد تا عملکردهای قرارداد هوشمند را بر اساس پارامترهای تعریف شده توسط کاربر فعال کنند. به طور معمول، این امر مستلزم «ثبت» قرارداد هدف با سرویس اوراکل، تأمین بودجه برای پرداخت به اپراتور اوراکل و مشخص کردن شرایط یا زمانهای شروع قرارداد است.
+
+[شبکه کیپر](https://chain.link/keepers) چین لینک گزینههایی را برای قراردادهای هوشمند برای برونسپاری وظایف تعمیر و نگهداری منظم به روشی به حداقل رسیده و غیرمتمرکز ارائه میدهد. [داکیومنت کیپر ](https://docs.chain.link/docs/chainlink-keepers/introduction/) را برای اطلاعات در مورد سازگار کردن قرارداد خود با کیپر و استفاده از سرویس Upkeep بخوانید.
+
+## نحوه استفاده از اوراکلهای بلاک چین {#use-blockchain-oracles}
+
+چندین برنامه اوراکل وجود دارد که میتوانید آنها را در برنامه اتریوم خود ادغام کنید:
+
+**[چین لینک](https://chain.link/)** - _شبکههای غیرمتمرکز اوراکل چین لینک ارائه میکنند ورودیها، خروجیها و محاسبات ضد دستکاری برای پشتیبانی از قراردادهای هوشمند پیشرفته در هر بلاک چین را اعمال میکند._
+
+**[کرونیکل](https://chroniclelabs.org/)** - _کرونیکل بر محدودیتهای فعلی غلبه میکند انتقال دادهها در زنجیره با توسعه اوراکلهای واقعا مقیاس پذیر، مقرون به صرفه، غیرمتمرکز و قابل تأیید را پیادهسازی میکند._
+
+**[Witnet](https://witnet.io/)** - _ویت نت بدون مجوز است، اوراکل غیرمتمرکز و مقاوم در برابر سانسور به قراردادهای هوشمند کمک میکند تا با ضمانتهای ارزی-اقتصادی قوی به رویدادهای دنیای واقعی واکنش نشان دهند._
+
+**[UMA Oracle](https://uma.xyz)** - _اوراکل آپتیمیستیک UMA به قراردادهای هوشمند اجازه میدهد قراردادهایی برای دریافت سریع و دریافت هر نوع داده برای برنامههای مختلف، از جمله بیمه، مشتقات مالی و بازارهای پیش بینی انجام دهند._
+
+**[تلور](https://tellor.io/)** - _تلور شفاف و پروتکل اوراکل بدون مجوز برای قرارداد هوشمند شما است تا به راحتی هر دادهای را هر زمان که به آن نیاز داشتید دریافت کنید._
+
+**[پروتکل باند](https://bandprotocol.com/)** - _پروتکل باند یک پلتفرم اوراکل داده متقابل زنجیرهای که دادهها و APIهای دنیای واقعی را جمعآوری و به قراردادهای هوشمند متصل میکند._
+
+**[Paralink](https://paralink.network/)** - _پارالینک یک برنامه منبع باز ارائه میکند و پلتفرم اوراکل غیرمتمرکز برای قراردادهای هوشمند در حال اجرا بر روی اتریوم و سایر بلاک چینهای محبوب است._
+
+**[شبکه Pyth](https://pyth.network/)** - _شبکه Pyth یک شبکه اوراکل مالی شخص اول که برای انتشار دادههای مستمر دنیای واقعی روی زنجیره در محیطی مقاوم در برابر دستکاری، غیرمتمرکز و خودپایدار طراحی شده است._
+
+**[API3 DAO](https://www.api3.org/)** - _API3 DAO در حال ارائه راه حلهای اوراکل شخص اول است که شفافیت منبع، امنیت و مقیاس پذیری بیشتری را در یک راه حل غیرمتمرکز برای قراردادهای هوشمند ارائه میکند_
+
+**[Supra](https://supra.com/)** - یک جعبه ابزار یکپارچه از راهحلهای زنجیرهای متقابل که همه بلاک چینها را به هم متصل میکند. (L1ها و L2ها) یا خصوصی (تشکیلات)، ارائه فیدهای غیرمتمرکز قیمت اوراکل که میتواند برای موارد استفاده در زنجیره و خارج از زنجیره استفاده شود.
+
+## بیشتر بخوانید {#further-reading}
+
+**مقالات**
+
+- [اوراکل بلاک چین چیست؟](https://chain.link/education/blockchain-oracles) — _چین لینک_
+- [اوراکل بلاک چین چیست؟](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _پاتریک کالینز< /em>
+- [اوراکلهای غیرمتمرکز: مروری جامع](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _ژولین تیونارد_
+- [اجرای اوراکل بلاک چین در اتریوم](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) - *پدرو کاستا*
+- [چرا قراردادهای هوشمند نمیتوانند تماسهای API برقرار کنند؟](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
+- [چرا به اوراکلهای غیرمتمرکز نیاز داریم](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) — _Bankless< /em>
+- [پس میخواهید از اوراکل قیمت استفاده کنید](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
+
+**ویدیوها**
+
+- [Oracles و گسترش ابزار بلاک چین](https://youtu.be/BVUZpWa8vpw) — _بخش مالی ریل ویژن_
+- [تفاوتهای اوراکلهای شخص اول و شخص ثالث](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/) - _Blockchain Oracle Summit_
+
+**آموزشها**
+
+- [نحوه واکشی قیمت فعلی اتریوم در سالیدیتی](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _چین لینک_
+- [مصرف دادههای اوراکل](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _کرونیکل_
+
+**نمونه پروژهها**
+
+- [پروژه شروع کامل چین لینک برای اتریوم در سالیدیتی](https://github.com/hackbg/chainlink-fullstack) — _HackBG_
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md b/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md
new file mode 100644
index 00000000000..3e0b74870d6
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md
@@ -0,0 +1,76 @@
+---
+title: ترکیب پذیری قراردادهای هوشمند
+description:
+lang: fa
+incomplete: true
+---
+
+## معرفی مختصر {#a-brief-introduction}
+
+قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. برای تبدیل شدن به یک توسعه دهنده dapp نیازی به نوشتن قرارداد هوشمند خود ندارید، فقط باید بدانید که چگونه با آنها تعامل داشته باشید. برای مثال، میتوانید از قراردادهای هوشمند موجود در [Uniswap](https://uniswap.exchange/swap)، یک صرافی غیرمتمرکز، برای مدیریت همه منطق مبادله توکن ها در برنامه خود استفاده کنید - لازم نیست از صفر شروع کنید. برخی از قراردادهای [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) و v3 را بررسی کنید.
+
+## ترکیبپذیری چیست؟ {#what-is-composability}
+
+ترکیب پذیری به معنای ترکیب کامپوننت های مجزا، با یکدیگر، به منظور ساخت یک سیستم و یا خروجی جدید می باشد. در توسعه نرمافزار، مبحث ترکیب پذیری به این معناست که توسعه دهنده می توانند با استفاده مجدد از کامپوننت های نرم افزاری موجود، یک اپلیکیشن جدید مد نظر خود را بسازند. یک راه خوب برای درک ترکیب پذیری این است که قطعات ترکیب پذیر را به صور قطعات لگو در نظر بگیریم. هر یک از قطعات لگو، می تواند با سایر قطعات تلفیق شده و با این تلفیق هایی که انجام میشود، قابلیت ساخت سازه های پیچیده ای را فراهم کند.
+
+در اتریوم، قراردادهای هوشمند را میتوان به نوعی مشابه یک پازل یا لگو داست که می توانید با کنار هم قراردادن پروژه های مختلف در قرارداد هوشمندتان، پروژه خود را بسازید. این موضوع به این معناست که نیاز نیست چرخ را دوباره اختراع کنید و یا ساخت پروژه خود را از صفر شروع کنید.
+
+## ترکیب پذیری چگونه عمل میکند؟ {#how-does-composability-work}
+
+قراردادهای هوشمند اتریومی، مشابه API های عمومی هستند که هر کسی می تواند با آنها ارتباط برقرار کرده و یا اپلیکیشن غیر متمرکز خود را با ویژگی های مد نظر، با آن تطبیق داده و یکپارچه کند. به عبارت کلی در خصوص ترکیب پذیری در قراردادهای هوشمند میتوان به سه اصل اساسی و مهم اشاره کرد: ماژولاریتی، خود اجرا بودن، و قابلیت دسترسی:
+
+**1. ماژولاریتی**: به معنای ویژگی هر کامپوننت برای انجام یک عملیات خاص و مشخص می باشد. هر کدام از قراردادهای هوشمند در اتریوم، یک مورد استفاده مخصوص به خود دارد. (همانطور که در مثال Uniswap نمایش داده شده است).
+
+**2. استقلال یا خوداجرایی**: کامپوننت هایی که قابل ترکیب هستند باید بتوانند به صورت مجزا از یکدیگر عمل کنند. هر قرارداد هوشمند در اتریوم، به صورت خودمختار اجرا میشود و میتواند بدون نیاز به بقیه المان های سیستم کار کند.
+
+**3. قابلیت دسترسی**: در صورتی که کتابخانه ها و یا قراردادهای هوشمندی که توسعه دهنده ها بخواهند از آنها در اپلیکیشن های خود استفاده کنند، به صورت عمومی در دسترس نباشند، توسعه دهنده ها نمیتوانند آنها را فراخوانی کرده و از آنها استفاده کنند. با توجه به نوع طراحی پیش فرض در شبکه اتریوم، قراردادهای هوشمند کد باز بوده و هر کسی میتواند این قراردادها را فراخوانی و استفاده نموده و یا کدهای مورد نظر خود را از یک مخزن منشعب نموده و از آن استفاده کند.
+
+## مزایای ترکیب پذیری {#benefits-of-composability}
+
+### چرخه توسعه کوتاه تر {#shorter-development-cycle}
+
+در زمان تولید [اپلیکیشن های غیرمتمرکز](/dapps/#what-are-dapps) (یا dapp ها) ترکیب پذیری می تواند باعث کاهش حجم کار توسعه دهنده های نرمافزار شود. [همانطور که Naval Ravikant می گوید: ](https://twitter.com/naval/status/1444366754650656770) "متن باز یعنی هر مشکلی فقط باید یکبار حل شود."
+
+اگر یک قرارداد هوشمند میتواند یک مشکل را حل کند، سایر توسعه دهنده ها می توانند از آن استفاده کنند و نیازی نیست که یک مشکل یکسان را دوباره حل کنند. بدین ترتیب توسعه دهنده ها میتوانند با استفاده از کتابخانه های موجود و اضافه کردن قابلیت های اضافی به آنها، اپلیکیشن های غیر متمرکز جدیدی را بسازند.
+
+### نوآوری بیشتر {#greater-innovation}
+
+ترکیب پذیری، مشوقی برای نوآوری و تجربه های بیشتر است، به این خاطر که توسعه دهنده ها می توانند به راحتی و آزادانه از کدهای موجود استفاده مجدد کنند، آنها را تغییر دهند، کپی کنند، و یا به هر ترتیب دیگری جهت رسیدن به نتیجه مطلوب خود بهره ببرند. در نتیجه، تیم های نرم افزاری زمان کمتری را برای پیادهسازی قابلیت های ابتدایی و ساده سپری خواهند کرد و میتوانند زمان خود را صرف ویژگی های بهتر و تجربه موارد جدیدتر کنند.
+
+### تجربه کاربری بهتر {#better-user-experience}
+
+ارتباط بین کامپوننت ها در اکوسیستم اتریوم باعث افزایش تجربه کاربری می شود. در اکوسیستمی که اپلیکیشن های غیرمتمرکز با سایر قراردادهای هوشمند مورد نیاز یکپارچه شده باشند، دست کاربر برای دسترسی به امکانات و قابلیت های بیشتر، نسبت به زمانی که در یک اکوسیستم، اپلیکیشن ها نتوانند با یکدیگر ارتباط برقرار کنند، بازتر است.
+
+به منظور نمایش مزایای قابلیت های ارتباط گیری بین اجزای مختلف، مثالی از یک آربیتراژ را استفاده خواهیم کرد:
+
+اگر توکنی در `صرافی A` قیمتی بیش از `صرافی B` داشته باشد، از این تفاوت قیمت میتوان برای کسب سود استفاده کرد. با این حال، تنها در زمانی میتوانید این کار رانجام دهید که سرمایه لازم برای اجرای تراکنش مورد نیاز را داشته باشید ( خرید توکن از `صرافی B` و فروش در `صرافی A`).
+
+در زمانی که سرمایه لازم برای انجام این ترید را نداشته باشید، استفاده از وام سریع یا همان flash loan گزینه ای ایده آل به حساب می آید. [وام های سریع](/defi/#flash-loans) مفهومی بسیار تکنیکال دارند، اما اگر بخواهیم به صورت ساده بگوئیم، ایده کلی به این صورت است که بدون نیاز به هیچ گونه گروگذاری یا داشتن سرمایه اولیه، می توان دارایی مورد نظر را قرض گرفت و البته که باید بازگشت وام، <0>در همان تراکنش0> صورت بگیرد.
+
+به مثال ابتدایی خود بر میگردیم، یک تریدر آربیتراژ می تواند با دریافت حجم زیادی وام سریع، توکن ها را از `صرافی B` خریده، آنها را در `صرافی A` بفروشد، وام گرفته شده را به همراه بهره آن بپردازد، و در نهایت سود باقیمانده را برای خود نگه دارد، و همه این اتفاقات تنها در همان یک تراکنش رخ می دهد. این منطق پیچیده نیاز به فراخوانی و استفاده ترکیبی از چندین قرارداد مختلف دارد، که در صورت نبود قابلیت ارتباط گیری بین قراردادهای هوشمند، امکانپذیر نبود.
+
+## مثالهایی از ترکیب پذیری در اتریوم {#composability-in-ethereum}
+
+### معاوضه توکنها {#token-swaps}
+
+اگر اپلیکیشن غیر متمرکزی بسازید که نیازمند پرداخت به تراکنش ها با اتر باشد، میتوانید از طریق یکپارچه سازی آن با منطق معاوضه توکن ها، قابلیت پرداخت با سایر توکن های ERC20 را برای کاربران فراهم کنید. این کد، پیش از اینکه تابع مورد نظر را اجرا کند، توکن کاربر را به صورت خودکار به اتر (ETH) تبدیل میکند.
+
+### حکومت {#governance}
+
+ساخت یک سیستم حاکمیتی سفارشی برای یک [DAO](/dao/) می تواند بسیار هزینه و زمان بر باشد. به جای آن، می توانید از یک تولکیت یا مجموعه ابزار متن باز حاکمیتی، مثل [Aragon Client](https://client.aragon.org/) استفاده کنید تا DAO خود را گسترش داده و به سرعت هر چه تمامتر یک چارچوب حاکمیتی بسازید.
+
+### مدیریت هویت {#identity-management}
+
+به جای ساختن یک سیستم احراز هویت و یا تکیه بر سرویس دهنده های متمرکز، می توانید ابزارهای هویت غیرمتمرکز (DID) را برای مدیریت احراز هویت کاربران با سیستم خود یکپارچه سازی و استفاده کنید. نمونه ای از این ابزارها، [SpruceID](https://www.spruceid.com/) است که قابلیت "ورود با اتریوم" را ارئه میدهد که با استفاده از آن کاربران میتوانند عملیات احراز هویت خود را با کیف پول اتریومی انجام دهند.
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [رابط کاربری اپلیکیشن غیرمتمرکز خود را به سرعت با create-eth-app ایجاد کنید](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/)_- نمای کلی نحوه استفاده از create-eth-app برای ساخت اپلیکیشن ها که قراردادهای هوشمند نیز در آنها قابل استفاده هستند._
+
+## اطلاعات بیشتر {#further-reading}
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
+
+- [ترکیب پذیری، نوآوری است](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/)
+- [علت اهمیت ترکیب پذیری برای Web3](https://hackernoon.com/why-composability-matters-for-web3)
+- [ترکیب پذیری چیست؟](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.)
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md
new file mode 100644
index 00000000000..ac046a229b2
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md
@@ -0,0 +1,310 @@
+---
+title: تایید رسمی قراردادهای هوشمند
+description: مروری بر تایید رسمی قراردادهای هوشمند اتریوم
+lang: fa
+---
+
+[قراردادهای هوشمند](/developers/docs/smart-contracts/) امکان ایجاد برنامههای غیرمتمرکز، بدون نیاز به اعتماد و قوی را فراهم میکنند که موارد استفاده جدیدی را معرفی کرده و ارزش را برای کاربران آزاد میکنند. از آنجایی که قراردادهای هوشمند مقادیر زیادی از ارزش را مدیریت میکنند، امنیت یک ملاحظهی حیاتی برای توسعهدهندگان است.
+
+تأیید رسمی یکی از تکنیک های توصیه شده برای بهبود [امنیت قرارداد هوشمند](/developers/docs/smart-contracts/security/) است. تأیید رسمی، که از [روشهای رسمی](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) برای تعیین، طراحی و تأیید برنامهها استفاده میکند، سالهاست که برای اطمینان از صحت سیستمهای سختافزاری و نرمافزاری حیاتی استفاده میشود.
+
+هنگامی که در قراردادهای هوشمند پیادهسازی می شود، تأیید رسمی می تواند ثابت کند که منطق تجاری یک قرارداد با مشخصات از پیش تعریف شده مطابقت دارد. در مقایسه با روشهای دیگر برای ارزیابی صحت کد قرارداد، مانند آزمایش، تأیید رسمی تضمینهای قویتری برای صحیح بودن قرارداد هوشمند میدهد.
+
+## تایید رسمی چیست؟ {#what-is-formal-verification}
+
+تأیید رسمی به فرآیند ارزیابی صحت یک سیستم با توجه به مشخصات رسمی اشاره دارد. به عبارت سادهتر، تأیید رسمی به ما امکان می دهد بررسی کنیم که آیا رفتار یک سیستم برخی از الزامات را برآورده می کند (یعنی آنچه را که ما می خواهیم انجام می دهد).
+
+رفتارهای مورد انتظار سیستم (در این مورد یک قرارداد هوشمند) با استفاده از مدلسازی رسمی توصیف میشوند، در حالی که زبانهای مشخصات امکان ایجاد خواص رسمی را فراهم میکنند. سپس تکنیکهای تأیید رسمی میتوانند تأیید کنند که اجرای یک قرارداد با مشخصات آن مطابقت دارد و اثبات ریاضی صحت قرارداد اول را به دست میآورد. زمانی که یک قرارداد با مشخصات خود مطابقت داشته باشد، به عنوان "صحیح عملکردی"، "درست بر اساس طراحی" یا "درست بر اساس ساخت" توصیف می شود.
+
+### مدل رسمی چیست؟ {#what-is-a-formal-model}
+
+در علوم کامپیوتر، [مدل رسمی](https://en.wikipedia.org/wiki/Model_of_computation) توصیفی ریاضی از یک فرآیند محاسباتی است. برنامهها به توابع ریاضی (معادلات) انتزاعی میشوند، و مدل نحوه محاسبه خروجیهای توابع را با توجه به ورودی توصیف میکند.
+
+مدلهای رسمی سطحی از انتزاع را فراهم میکنند که در آن تحلیل رفتار یک برنامه قابل ارزیابی است. وجود مدلهای رسمی امکان ایجاد یک _مشخصات رسمی_ را فراهم میکند که ویژگیهای مورد نظر مدل مورد نظر را توصیف میکند.
+
+تکنیکهای مختلفی برای مدلسازی قراردادهای هوشمند برای تأیید رسمی استفاده میشود. به عنوان مثال، برخی از مدل ها برای استدلال در مورد رفتار سطح بالای یک قرارداد هوشمند استفاده می شوند. این تکنیکهای مدلسازی یک نمای جعبه سیاه را برای قراردادهای هوشمند اعمال میکنند و آنها را به عنوان سیستمهایی میبینند که ورودیها را میپذیرند و محاسبات را بر اساس آن ورودیها اجرا میکنند.
+
+مدلهای سطح بالا بر رابطه بین قراردادهای هوشمند و عوامل خارجی، مانند حسابهای تحت مالکیت خارجی (EOAs)، حسابهای قراردادی و محیط بلاک چین تمرکز دارند. چنین مدل هایی برای تعریف ویژگی هایی مفید هستند که مشخص می کنند یک قرارداد چگونه باید در پاسخ به تعاملات خاص کاربر رفتار کند.
+
+برعکس، سایر مدلهای رسمی بر رفتار سطح پایین قرارداد هوشمند تمرکز دارند. در حالی که مدلهای سطح بالا میتوانند به استدلال در مورد عملکرد قرارداد کمک کنند، ممکن است نتوانند جزئیات مربوط به عملکرد داخلی پیادهسازی را ثبت کنند. مدلهای سطح پایین از نمای جعبه سفید برای تجزیه و تحلیل برنامه استفاده میکنند و برای استدلال در مورد ویژگیهای مربوط به اجرای قرارداد، به نمایشهای سطح پایینتر برنامههای قرارداد هوشمند، مانند ردیابی برنامه و [گرافهای جریان کنترل](https://en.wikipedia.org/wiki/Control-flow_graph) تکیه میکنند.
+
+مدلهای سطح پایین ایدهآل در نظر گرفته میشوند زیرا نشاندهنده اجرای واقعی یک قرارداد هوشمند در محیط اجرای اتریوم هستند (یعنی [EVM](/developers/docs/evm/)). تکنیکهای مدلسازی سطح پایین بهویژه در ایجاد ویژگیهای ایمنی حیاتی در قراردادهای هوشمند و شناسایی آسیبپذیریهای بالقوه مفید هستند.
+
+### مشخصات رسمی چیست؟ {#what-is-a-formal-specification}
+
+یک مشخصات به سادگی یک الزام فنی است که یک سیستم خاص باید برآورده کند. در برنامه نویسی، مشخصات، ایده های کلی در مورد اجرای یک برنامه (یعنی آنچه برنامه باید انجام دهد) را نشان می دهد.
+
+در زمینه قراردادهای هوشمند، مشخصات رسمی به _ویژگیها_ اشاره میکند—توضیحات رسمی الزاماتی که یک قرارداد باید برآورده کند. چنین ویژگی هایی به عنوان "غیر متغیر" توصیف می شوند و بیانگر ادعاهای منطقی در مورد اجرای یک قرارداد هستند که باید تحت هر شرایط ممکن، بدون هیچ استثنایی صادق باقی بماند.
+
+بنابراین، ما می توانیم مشخصات رسمی را به عنوان مجموعه ای از اظهارات نوشته شده به زبان رسمی در نظر بگیریم که اجرای مورد نظر یک قرارداد هوشمند را توصیف می کند. مشخصات، ویژگی های قرارداد را پوشش می دهد و نحوه رفتار قرارداد را در شرایط مختلف تعریف می کند. هدف از تأیید رسمی این است که مشخص شود آیا قرارداد هوشمند دارای این ویژگیها (غیر متغیرها) است یا خیر و اینکه این ویژگیها در طول اجرا نقض نمیشوند.
+
+مشخصات رسمی در توسعه پیادهسازی ایمن قراردادهای هوشمند حیاتی هستند. قراردادهایی که در اجرای خود موفق به پیادهسازی ثابتها نمیشوند یا خواص آنها نقض میشود، مستعد آسیبپذیریهایی هستند که میتوانند به عملکرد آسیب برسانند یا باعث سوء استفادههای مخرب شوند.
+
+## انواع مشخصات رسمی قراردادهای هوشمند {#formal-specifications-for-smart-contracts}
+
+مشخصات رسمی استدلال ریاضی در مورد صحت اجرای برنامه را امکانپذیر می کند. همانند مدلهای رسمی، مشخصات رسمی میتوانند ویژگیهای سطح بالا یا رفتار سطح پایین اجرای قرارداد را نشان دهند.
+
+مشخصات رسمی با استفاده از عناصر [منطق برنامه](https://en.wikipedia.org/wiki/Logic_programming) به دست میآیند که امکان استدلال رسمی در مورد ویژگیهای یک برنامه را فراهم میکند. یک منطق برنامه دارای قوانین رسمی است که رفتار مورد انتظار یک برنامه را (به زبان ریاضی) بیان میکند. منطق برنامه های مختلف در ایجاد مشخصات رسمی استفاده می شود، از جمله [منطق دسترسی پذیری](https://en.wikipedia.org/wiki/Reachability_problem)، [منطق زمانی](https://en.wikipedia.org/wiki/Temporal_logic)، و [منطق هوآر](https://en.wikipedia.org/wiki/Hoare_logic).
+
+مشخصات رسمی قراردادهای هوشمند را می توان به طور کلی به عنوان مشخصات **سطح بالا** یا **سطح پایین** طبقه بندی کرد. صرف نظر از اینکه یک مشخصات به چه دسته ای تعلق دارد، باید به طور کافی و بدون ابهام ویژگی سیستم مورد تجزیه و تحلیل را توصیف کند.
+
+### مشخصات سطح بالا {#high-level-specifications}
+
+همانطور که از نام آن پیداست، یک مشخصات سطح بالا (که "مشخصات مدل گرا" نیز نامیده می شود) رفتار سطح بالای یک برنامه را توصیف می کند. مشخصات سطح بالا یک قرارداد هوشمند را به عنوان یک [ماشین حالت متناهی](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) مدلسازی میکند که میتواند با انجام عملیات بین حالتها جابهجا شود، و از منطق زمانی برای تعریف خواص رسمی برای مدل FSM استفاده میشود.
+
+[منطقهای زمانی](https://en.wikipedia.org/wiki/Temporal_logic) "قوانینی برای استدلال درباره گزارههایی هستند که از نظر زمانی واجد شرایط هستند (مثلاً "من _همیشه_ گرسنه هستم" یا "من _در نهایت_ گرسنه خواهم شد.")" هنگامی که برای تأیید رسمی اعمال می شود، از منطق های زمانی برای بیان ادعاهای مربوط به رفتار صحیح سیستم های مدل سازی شده به عنوان ماشین های حالت استفاده می شود. به طور خاص، یک منطق زمانی وضعیتهای آیندهای را که یک قرارداد هوشمند میتواند در آن قرار گیرد و نحوه انتقال آن بین حالتها را توصیف میکند.
+
+مشخصات سطح بالا به طور کلی دو ویژگی مهم زمانی را برای قراردادهای هوشمند نشان می دهد: **ایمنی** و **زندهمانی**. ویژگی های ایمنی بیانگر این ایده است که "هیچ چیز بدی اتفاق نمی افتد" و معمولاً بیانگر تغییر ناپذیری است. یک ویژگی ایمنی ممکن است الزامات کلی نرمافزار را تعریف کند، مانند آزادی از [قفل شدن](https://www.techtarget.com/whatis/definition/deadlock)، یا خواص خاص دامنه را برای قراردادها بیان کند (به عنوان مثال، ثابتهای کنترل دسترسی برای توابع، مقادیر مجاز متغیرهای حالت یا شرایط برای انتقال توکن).
+
+به عنوان مثال این الزام ایمنی را در نظر بگیرید که شرایط استفاده از `transfer()` یا `transferFrom()` در قراردادهای توکن ERC-20 را پوشش می دهد: _"باقیمانده حساب فرستنده هرگز کمتر از مقدار درخواستی توکنهای ارسال شده نیست."_. این توصیف به زبان طبیعی از یک قرارداد ثابت را می توان به یک مشخصات رسمی (ریاضی) ترجمه کرد، که سپس می توان آن را به شدت از نظر اعتبار بررسی کرد.
+
+خواص زنده بودن تأکید میکنند که "بالاخره اتفاق خوبی میافتد" و مربوط به توانایی یک قرارداد برای پیشرفت از طریق حالات مختلف است. یک مثال از ویژگی زنده بودن "نقدینگی" است که به توانایی یک قرارداد برای انتقال موجودی خود به کاربران در صورت درخواست اشاره دارد. اگر این ویژگی نقض شود، کاربران نمیتوانند داراییهای ذخیرهشده در قرارداد را برداشت کنند، مانند آنچه در [حادثه کیف پول Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) اتفاق افتاد.
+
+### مشخصات سطح پایین {#low-level-specifications}
+
+مشخصات سطح بالا به عنوان نقطه شروع یک مدل حالت محدود از یک قرارداد را در نظر گرفته و ویژگی های مورد نظر این مدل را تعریف می کند. در مقابل، مشخصات سطح پایین (که همچنین به عنوان "مشخصات گرا به ویژگی" شناخته میشوند) اغلب برنامهها (قراردادهای هوشمند) را به عنوان سیستمهایی متشکل از مجموعهای از توابع ریاضی مدلسازی میکنند و رفتار صحیح چنین سیستمهایی را توصیف میکنند.
+
+به عبارت سادهتر، مشخصات سطح پایین _ردهای برنامه_ را تجزیه و تحلیل می کنند و سعی می کنند ویژگی های یک قرارداد هوشمند را بر روی این ردیابی ها تعریف کنند. ردیابیها به توالیهای اجرای توابع اشاره دارند که حالت یک قرارداد هوشمند را تغییر میدهند؛ از این رو، مشخصات سطح پایین به مشخص کردن الزامات برای اجرای داخلی یک قرارداد کمک میکنند.
+
+مشخصات رسمی سطح پایین را می توان به عنوان ویژگی های سبک هوآر یا به صورت ثابت در مسیرهای اجرا ارائه کرد.
+
+### خواص سبک هوآر {#hoare-style-properties}
+
+[منطق هوآر](https://en.wikipedia.org/wiki/Hoare_logic) مجموعهای از قوانین رسمی را برای استدلال در مورد صحت برنامهها، از جمله قراردادهای هوشمند، ارائه میکند. یک ویژگی به سبک هوآر با یک سهگانه هوآر {_P_}_c_{_Q_} نشان داده میشود، که در آن _c_ یک برنامه است و _P_ و _Q_ گزارههایی در مورد حالت c (یعنی برنامه) هستند که به ترتیب به صورت _پیش شرطها_ و _پس شرطها_ توصیف میشوند.
+
+پیش شرط یک گزاره است که شرایط لازم برای اجرای صحیح یک تابع را توصیف می کند. کاربرانی که قرارداد را امضا می کنند باید این شرط را برآورده کنند. پیش شرط یک گزاره است که شرایط لازم برای اجرای صحیح یک تابع را توصیف می کند. کاربرانی که قرارداد را امضا کنند باید این شرط را تعیین کنند. یک _ثابت_ در منطق هوآر یک گزاره است که توسط اجرای یک تابع حفظ میشود (یعنی تغییر نمیکند).
+
+مشخصات سبک هوآر می تواند _صحت جزئی_ یا _صحت کامل_ را تضمین کند. اگر پیش شرط قبل از اجرای تابع صادق باشد، اجرای یک تابع قرارداد "تا حدی صحیح" است، و اگر اجرا خاتمه یابد، پس شرط نیز صادق است. اگر یک پیش شرط قبل از اجرای تابع درست باشد، اثبات صحت کلی به دست میآید، اجرا تضمین میشود که پایان یابد و زمانی که انجام شد، شرط پسشرط صادق است.
+
+کسب اثبات صحت کامل دشوار است زیرا برخی از اجراها ممکن است قبل از خاتمه به تأخیر بیفتند یا اصلاً هرگز خاتمه نیابند. با این حال، این سؤال که آیا اجرا خاتمه مییابد یا خیر، قابل بحث است، زیرا مکانیسم گس اتریوم از حلقههای بینهایت برنامه جلوگیری میکند (اجرا یا با موفقیت خاتمه مییابد یا به دلیل خطای "تمام شدن گس" پایان مییابد).
+
+مشخصات قرارداد هوشمند ایجاد شده با استفاده از منطق هوآر دارای پیششرطها، پسشرطها و متغیرهایی هستند که برای اجرای توابع و حلقهها در یک قرارداد تعریف شدهاند. پیششرطها اغلب شامل امکان ورودیهای اشتباه به یک تابع هستند، با شرایط پسشرطی که پاسخ مورد انتظار به این ورودیها را توصیف میکنند (به عنوان مثال، ایجاد یک استثنا خاص). به این ترتیب ویژگی های سبک هوآر برای اطمینان از صحت اجرای قرارداد مؤثر است.
+
+بسیاری از چارچوبهای تأیید رسمی از مشخصات سبک هوآر برای اثبات صحت معنایی توابع استفاده میکنند. همچنین میتوان خواص به سبک هوآر (به عنوان ادعاها) را به طور مستقیم با استفاده از عبارات `require` و `assert` در سالیدیتی به کد قرارداد اضافه کرد.
+
+عبارات `require` بیانگر یک پیش شرط یا ثابت هستند و اغلب برای اعتبارسنجی ورودی های کاربر استفاده می شوند، در حالی که `assert` یک شرط پسین لازم برای ایمنی را نشان می دهد. به عنوان مثال، کنترل دسترسی مناسب برای توابع (مثالی از یک ویژگی ایمنی) را میتوان با استفاده از `require` به عنوان یک بررسی پیش شرط بر روی هویت حساب فراخوانی کننده به دستآورد. به طور مشابه، یک ثابت بر روی مقادیر مجاز متغیرهای حالت در یک قرارداد (به عنوان مثال، کل تعداد توکنهای در گردش) را میتوان از نقض با استفاده از `assert` برای تأیید وضعیت قرارداد پس از اجرای تابع محافظت کرد.
+
+### ویژگیهای سطح ردیابی {#trace-level-properties}
+
+مشخصات مبتنی بر ردیابی عملیاتهایی را توصیف میکنند که یک قرارداد را بین حالتهای مختلف انتقال میدهند و روابط بین این عملیاتها را مشخص میکنند. همانطور که قبلا توضیح داده شد، ردیابی ها دنباله ای از عملیات هستند که وضعیت یک قرارداد را به روشی خاص تغییر می دهند.
+
+این رویکرد بر مدل قراردادهای هوشمند به عنوان سیستمهای انتقال حالت با برخی حالتهای از پیش تعریفشده (توصیفشده توسط متغیرهای حالت) به همراه مجموعهای از انتقالهای از پیش تعریفشده (توصیفشده توسط توابع قرارداد) متکی است. علاوه بر این، یک [گراف جریان کنترل](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG)، که یک نمایش گرافیکی از جریان اجرای یک برنامه است، اغلب برای توصیف معنایی عملیاتی یک قرارداد استفاده میشود. در اینجا، هر ردیابی به عنوان یک مسیر در نمودار جریان کنترل نشان داده می شود.
+
+در درجه اول، مشخصات سطح ردیابی برای استدلال در مورد الگوهای اجرای داخلی در قراردادهای هوشمند استفاده می شود. با ایجاد مشخصات سطح ردیابی، ما مسیرهای اجرایی قابل قبول (به عنوان مثال، انتقال حالت) را برای یک قرارداد هوشمند اعلام می کنیم. با استفاده از تکنیک هایی مانند اجرای نمادین، می توانیم به طور رسمی تأیید کنیم که اجرا هرگز از مسیری پیروی نمی کند که در مدل رسمی تعریف نشده است.
+
+بیایید از نمونه ای از قرارداد [DAO](/dao/) استفاده کنیم که دارای برخی از توابع در دسترس عموم برای توصیف ویژگی های سطح ردیابی است. در اینجا، ما فرض می کنیم که قرارداد DAO به کاربران اجازه می دهد تا عملیات زیر را انجام دهند:
+
+- واریز وجه
+
+- رای دادن به یک پیشنهاد پس از واریز وجوه
+
+- درخواست بازپرداخت در صورت عدم رای دادن به یک پیشنهاد
+
+نمونهای از ویژگیهای سطح ردیابی میتواند _"کاربرانی که وجوهی را واریز نمیکنند نمیتوانند به پیشنهادی رای دهند"_ یا _"کاربرانی که به پیشنهادی رای نمیدهند همیشه باید بتوانند ادعای بازپرداخت داشته باشند" _. هر دو ویژگی ترتیب ترجیحی اجرا را بیان میکنند (رایگیری نمیتواند _قبل از_ واریز وجوه انجام شود و ادعای بازپرداخت نمیتواند _پس از_ رای دادن به یک پیشنهاد انجام شود).
+
+## تکنیکهایی برای تأیید رسمی قراردادهای هوشمند {#formal-verification-techniques}
+
+### بررسی مدل {#model-checking}
+
+بررسی مدل یک تکنیک تأیید رسمی است که در آن یک الگوریتم مدل رسمی یک قرارداد هوشمند را در برابر مشخصات آن بررسی میکند. در بررسی مدل، قراردادهای هوشمند اغلب به عنوان سیستمهای انتقال حالت نشان داده میشوند، در حالی که ویژگیهای روی حالتهای قرارداد مجاز با استفاده از منطق زمانی تعریف میشوند.
+
+بررسی مدل مستلزم ایجاد یک نمایش ریاضی انتزاعی از یک سیستم (به عنوان مثال، یک قرارداد) و بیان ویژگیهای این سیستم با استفاده از فرمولهایی است که ریشه در [منطق گزارهای](https://www.baeldung.com/cs/propositional-logic) دارند. این کار الگوریتم بررسی مدل را ساده می کند، یعنی ثابت کند که یک مدل ریاضی یک فرمول منطقی معین را برآورده می کند.
+
+بررسی مدل در راستیآزمایی رسمی عمدتاً برای ارزیابی ویژگیهای زمانی استفاده میشود که رفتار یک قرارداد را در طول زمان توصیف میکنند. ویژگی های موقت قراردادهای هوشمند شامل _ایمنی_ و _زندگی_ است که قبلا توضیح دادیم.
+
+به عنوان مثال، یک ویژگی امنیتی مربوط به کنترل دسترسی (به عنوان مثال، _فقط مالک قرارداد می تواند `selfdestruct`_ را فراخوانی کند) می تواند در منطق رسمی نوشته شود. پس از آن، الگوریتم بررسی مدل می تواند تأیید کند که آیا قرارداد با این مشخصات رسمی مطابقت دارد یا خیر.
+
+بررسی مدل از کاوش فضای حالت استفاده میکند، که شامل ساخت همه حالتهای ممکن یک قرارداد هوشمند و تلاش برای یافتن حالتهای قابل دسترسی است که منجر به نقض مالکیت میشود. با این حال، این می تواند به تعداد نامحدودی از حالت ها منجر شود (معروف به "مشکل انفجار حالت")، از این رو بررسی کنندگان مدل برای امکان تحلیل کارآمد قراردادهای هوشمند به تکنیک های انتزاعی تکیه می کنند.
+
+### اثبات قضیه {#theorem-proving}
+
+اثبات قضیه روشی برای استدلال ریاضی درباره صحت برنامه ها از جمله قراردادهای هوشمند است. این شامل تبدیل مدل سیستم قرارداد و مشخصات آن به فرمول های ریاضی (گزاره های منطقی) است.
+
+هدف از اثبات قضیه، تأیید هم ارزی منطقی بین این گزاره ها است. "تعادل منطقی" (که "منطقی دو مفهومی" نیز نامیده می شود) نوعی رابطه بین دو عبارت است به طوری که گزاره اول درست است _اگر و فقط اگر_ گزاره دوم درست باشد.
+
+رابطه مورد نیاز (تعادل منطقی) بین گزارههای مربوط به مدل قرارداد و ویژگیهای آن به عنوان یک گزاره قابل اثبات (به نام قضیه) فرموله میشود. با استفاده از یک سیستم رسمی استنتاج، اثبات کننده قضیه خودکار می تواند اعتبار قضیه را تأیید کند. به عبارت دیگر، یک اثبات کننده قضیه می تواند به طور قطعی ثابت کند که مدل قرارداد هوشمند دقیقاً با مشخصات آن مطابقت دارد.
+
+در حالی که مدلهای بررسی مدل به عنوان سیستمهای انتقالی با حالتهای محدود منقبض میشوند، اثبات قضیه میتواند تجزیه و تحلیل سیستمهای حالت نامتناهی را انجام دهد. با این حال، این بدان معناست که یک اثبات کننده قضیه خودکار همیشه نمی تواند بفهمد که آیا یک مسئله منطقی "قابل تصمیم گیری" است یا خیر.
+
+در نتیجه، کمک های انسانی اغلب برای راهنمایی اثبات کننده قضیه در استخراج براهین صحت مورد نیاز است. استفاده از تلاش انسانی در اثبات قضیه، استفاده از آن را نسبت به بررسی مدل که کاملاً خودکار است، گرانتر میکند.
+
+### اجرای نمادین {#symbolic-execution}
+
+اجرای نمادین روشی برای تجزیه و تحلیل قرارداد هوشمند با اجرای توابع با استفاده از _مقادیر نمادین_ (به عنوان مثال، `x > 5`) به جای _مقادیر مشخص_ ( به عنوان مثال، `x == 5`). به عنوان یک تکنیک تأیید رسمی، اجرای نمادین برای استدلال رسمی در مورد ویژگیهای سطح ردیابی در کد قرارداد استفاده میشود.
+
+اجرای نمادین یک رد اجرا را به عنوان یک فرمول ریاضی بر روی مقادیر ورودی نمادین نشان می دهد که در غیر این صورت _گزاره مسیر_ نامیده می شود. یک [حلکننده SMT](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) برای بررسی اینکه آیا یک گزاره مسیر "رضایتپذیر" است یا نه استفاده میشود (یعنی مقداری وجود دارد که میتواند فرمول را برآورده کند). اگر یک مسیر آسیب پذیر قابل رضایت باشد، حل کننده SMT یک مقدار مشخص ایجاد می کند که اجرای آن را به سمت آن مسیر هدایت می کند.
+
+فرض کنید تابع قرارداد هوشمند یک مقدار `uint` (`x`) را به عنوان ورودی می گیرد و زمانی که `x` بزرگتر از `5` باشد برمی گردد. و همچنین کمتر از `10`. یافتن مقداری برای `x` که خطا را با استفاده از یک روش آزمایش معمولی ایجاد میکند، مستلزم اجرای دهها تست (یا بیشتر) بدون اطمینان از یافتن ورودی محرک خطا است.
+
+برعکس، یک ابزار اجرای نمادین تابع را با مقدار نمادین اجرا می کند: `X > 5 ∧ X < 10` (یعنی `x` بزرگتر از 5 است و `x` کمتر از 10 است). گزاره مسیر مرتبط `x = X > 5 ∧ X < 10` سپس به حل کننده SMT داده می شود تا حل کند. اگر مقدار خاصی با فرمول `x = X > 5 ∧ X < 10`، حلکننده SMT آن را محاسبه میکند - برای مثال، حلکننده ممکن است `7` را به عنوان مقدار `x` تولید کند.
+
+از آنجایی که اجرای نمادین به ورودی های یک برنامه متکی است و مجموعه ورودی ها برای کاوش همه حالت های قابل دسترسی به طور بالقوه نامحدود است، هنوز هم نوعی آزمایش است. با این حال، همانطور که در مثال نشان داده شده است، اجرای نمادین کارآمدتر از آزمایش معمولی برای یافتن ورودی هایی است که باعث نقض مالکیت می شود.
+
+علاوه بر این، اجرای نمادین نسبت به سایر تکنیکهای مبتنی بر ویژگی (مثلاً فازی) که بهطور تصادفی ورودیهای یک تابع را تولید میکنند، نکات مثبت کاذب کمتری تولید میکند. اگر یک حالت خطا در طول اجرای نمادین ایجاد شود، می توان یک مقدار مشخص ایجاد کرد که باعث ایجاد خطا و بازتولید مسئله می شود.
+
+اجرای نمادین همچنین می تواند درجاتی از اثبات ریاضی درستی را ارائه دهد. مثال زیر از یک تابع قرارداد با حفاظت از سرریز را در نظر بگیرید:
+
+```
+function safe_add(uint x, uint y) returns(uint z){
+
+ z = x + y;
+ require(z>=x);
+ require(z>=y);
+
+ return z;
+```
+
+یک ردیابی اجرا که منجر به سرریز اعداد صحیح می شود باید این فرمول را برآورده کند: `z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)` بعید است چنین فرمولی حل شود، از این رو یک اثبات ریاضی است که تابع `safe_add` هرگز سرریز نمی شود.
+
+### چرا از تأیید رسمی برای قراردادهای هوشمند استفاده کنیم؟ {#benefits-of-formal-verification}
+
+#### نیاز به قابلیت اطمینان {#need-for-reliability}
+
+راستیآزمایی رسمی برای ارزیابی درستی سیستمهای حیاتی ایمنی استفاده میشود که خرابی آنها میتواند عواقب مخربی مانند مرگ، جراحت یا خرابی مالی داشته باشد. قراردادهای هوشمند، برنامههای کاربردی با ارزشی هستند که مقادیر زیادی از ارزش را کنترل میکنند و خطاهای ساده در طراحی میتواند منجر به
+خسارت جبرانناپذیر برای کاربران شود. با این حال، تأیید رسمی یک قرارداد قبل از استقرار، میتواند تضمینهایی را افزایش دهد که پس از اجرا بر روی بلاکچین، مطابق انتظار عمل میکند.
+
+قابلیت اطمینان یک کیفیت بسیار مطلوب در هر قرارداد هوشمند است، به خصوص به این دلیل که کد مستقر شده در ماشین مجازی اتریوم (EVM) معمولاً تغییرناپذیر است. از آنجایی که بروزرسانیهای پس از راهاندازی به راحتی قابل دسترسی نیستند، نیاز به تضمین قابلیت اطمینان قراردادها تأیید رسمی را ضروری میکند. راستیآزمایی رسمی میتواند مسائل پیچیدهای مانند سرریز و سرریز اعداد صحیح، ورود مجدد و بهینهسازی ضعیف گاز را شناسایی کند که ممکن است از دست حسابرسان و آزمایشکنندگان خارج شود.
+
+
+
+#### اثبات صحت عملکرد {#prove-functional-correctness}
+
+تست برنامه رایج ترین روش برای اثبات اینکه یک قرارداد هوشمند برخی از الزامات را برآورده می کند. این شامل اجرای یک قرارداد با نمونهای از دادههایی است که انتظار میرود مدیریت کند و رفتار آن را تحلیل کند. اگر قرارداد نتایج مورد انتظار را برای داده های نمونه برگرداند، توسعه دهندگان اثبات عینی برای صحت آن دارند.
+
+با این حال، این رویکرد نمی تواند اجرای صحیح را برای مقادیر ورودی که بخشی از نمونه نیستند ثابت کند. بنابراین، آزمایش یک قرارداد ممکن است به شناسایی اشکالات کمک کند (به عنوان مثال، اگر برخی از مسیرهای کد نتوانند نتایج دلخواه را در طول اجرا برگردانند)، اما **نمیتواند به طور قطعی عدم وجود اشکالات را ثابت کند**.
+
+برعکس، راستیآزمایی رسمی میتواند به طور رسمی ثابت کند که یک قرارداد هوشمند نیازمندیهای دامنه بینهایتی از اجراها را _بدون_ اجرای قرارداد برآورده میکند. این امر مستلزم ایجاد یک مشخصات رسمی است که دقیقاً رفتارهای صحیح قرارداد را توصیف می کند و یک مدل رسمی (ریاضی) از سیستم قرارداد را توسعه می دهد. سپس میتوانیم یک روش اثبات رسمی را برای بررسی سازگاری بین مدل قرارداد و مشخصات آن دنبال کنیم.
+
+با تأیید رسمی، سؤال تأیید اینکه آیا منطق تجاری یک قرارداد الزامات را برآورده می کند یک گزاره ریاضی است که می تواند اثبات یا رد شود. با اثبات رسمی یک گزاره، میتوانیم تعداد نامتناهی از موارد آزمایشی را با تعداد مراحل محدود تأیید کنیم. به این ترتیب تأیید رسمی چشم اندازهای بهتری برای اثبات صحت عملکرد قرارداد با توجه به مشخصات دارد.
+
+
+
+#### اهداف تأیید ایده آل {#ideal-verification-targets}
+
+هدف راستیآزمایی، سیستمی را که باید بهطور رسمی تأیید شود، توصیف میکند. تأیید رسمی به بهترین وجه در «سیستمهای تعبیهشده» (نرمافزارهای کوچک و ساده که بخشی از یک سیستم بزرگتر را تشکیل میدهند) استفاده میشود. آنها همچنین برای دامنه های تخصصی که قوانین کمی دارند ایده آل هستند، زیرا این کار تغییر ابزارها را برای تأیید ویژگی های خاص دامنه آسان تر می کند.
+
+قراردادهای هوشمند - حداقل تا حدی - هر دو الزام را برآورده می کنند. به عنوان مثال، اندازه کوچک قراردادهای اتریوم باعث می شود که آنها را به تأیید رسمی برساند. به طور مشابه، EVM از قوانین ساده پیروی می کند، که تعیین و تأیید ویژگی های معنایی را برای برنامه های در حال اجرا در EVM آسان تر می کند.
+
+
+
+### چرخه توسعه سریعتر {#faster-development-cycle}
+
+تکنیکهای تأیید رسمی، مانند بررسی مدل و اجرای نمادین، معمولاً کارآمدتر از تجزیه و تحلیل منظم کد قرارداد هوشمند (که در طول آزمایش یا ممیزی انجام میشود) هستند. این به این دلیل است که تأیید رسمی برای آزمایش ادعاها به مقادیر نمادین متکی است ("اگر کاربر سعی کند _n_ اتر را خارج کند چه؟" برخلاف آزمایشی که از مقادیر مشخصی استفاده می کند ("اگر کاربر بخواهد 5 اتر را خارج کند چه؟".
+
+متغیرهای ورودی نمادین میتوانند چندین کلاس از مقادیر بتن را پوشش دهند، بنابراین رویکردهای تأیید رسمی پوشش کد بیشتری را در بازه زمانی کوتاهتر وعده میدهند. هنگامی که به طور موثر استفاده می شود، تأیید رسمی می تواند چرخه توسعه را برای توسعه دهندگان تسریع کند.
+
+تأیید رسمی همچنین فرآیند ساخت دپها (dapps) را با کاهش خطاهای طراحی پرهزینه بهبود می بخشد. ارتقاء قراردادها (در صورت امکان) برای رفع آسیب پذیری ها مستلزم بازنویسی گسترده پایگاه های کد و تلاش بیشتر برای توسعه است. راستیآزمایی رسمی میتواند بسیاری از خطاها را در اجرای قرارداد شناسایی کند که ممکن است آزمایشکنندگان و حسابرسان را پشت سر بگذارد و فرصت کافی برای رفع آن مشکلات قبل از استقرار قرارداد فراهم میکند.
+
+
+
+## معایب تأیید رسمی {#drawbacks-of-formal-verification}
+
+
+
+### هزینه نیروی کار {#cost-of-manual-labor}
+
+راستیآزمایی رسمی، بهویژه تأیید نیمه خودکار که در آن یک انسان اثباتکننده را برای به دست آوردن اثبات صحت راهنمایی میکند، به کار دستی قابلتوجهی نیاز دارد. علاوه بر این، ایجاد مشخصات رسمی یک فعالیت پیچیده است که به سطح بالایی از مهارت نیاز دارد.
+
+این عوامل (تلاش و مهارت) تأیید رسمی را در مقایسه با روشهای معمول ارزیابی صحت قراردادها، مانند آزمایش و ممیزی، پرهزینهتر و پرهزینهتر میسازد. با این وجود، با توجه به هزینه خطاها در اجرای قراردادهای هوشمند، پرداخت هزینه برای ممیزی تأیید کامل عملی است.
+
+
+
+### منفی های کاذب {#false-negatives}
+
+تأیید رسمی فقط می تواند بررسی کند که آیا اجرای قرارداد هوشمند با مشخصات رسمی مطابقت دارد یا خیر. به این ترتیب، مهم است که مطمئن شوید مشخصات به درستی رفتارهای مورد انتظار یک قرارداد هوشمند را توصیف می کند.
+
+اگر مشخصات ضعیف نوشته شده باشند، نقض ویژگیها - که به اعدامهای آسیبپذیر اشاره دارد - توسط ممیزی تأیید رسمی قابل شناسایی نیست. در این مورد، یک توسعه دهنده ممکن است به اشتباه فرض کند که قرارداد بدون اشکال است.
+
+
+
+### مسائل مربوط به عملکرد {#performance-issues}
+
+تأیید رسمی با تعدادی از مشکلات عملکرد مواجه می شود. برای مثال، مشکلات انفجار حالت و مسیر که به ترتیب در حین بررسی مدل و بررسی نمادین با آن مواجه میشوند، میتوانند بر رویههای تأیید تأثیر بگذارند. همچنین، ابزارهای تأیید رسمی اغلب از حل کننده های SMT و سایر حل کننده های محدودیت در لایه زیرین خود استفاده می کنند و این حل کننده ها بر رویه های محاسباتی فشرده تکیه می کنند.
+
+همچنین، تعیین اینکه آیا یک ویژگی (که به عنوان یک فرمول منطقی توصیف میشود) میتواند برآورده شود یا خیر، برای تأییدکنندگان برنامه همیشه امکانپذیر نیست («[مشکل تصمیمپذیری](https://en.wikipedia.org/wiki/Decision_problem)») زیرا ممکن است یک برنامه هرگز خاتمه یابد. به این ترتیب، ممکن است اثبات برخی از خواص برای یک قرارداد، حتی اگر به خوبی مشخص شده باشد، غیرممکن باشد.
+
+
+
+## ابزارهای تأیید رسمی قراردادهای هوشمند اتریوم {#formal-verification-tools}
+
+
+
+### زبان های مشخصات برای ایجاد مشخصات رسمی {#specification-languages}
+
+**Act**: _*Act اجازه میدهد تا مشخصات بهروزرسانیهای ذخیرهسازی، شرایط قبل/پست و متغیرهای قرارداد را مشخص کنید. مجموعه ابزار آن همچنین دارای پشتیبانهای اثباتی است که میتوانند ویژگیهای زیادی را از طریق Coq، حلکنندههای SMT یا hevm اثبات کنند.**
+
+- [گیتهاب](https://github.com/ethereum/act)
+- [اسناد](https://ethereum.github.io/act/)
+
+**Scribble** - _*Scribble حاشیه نویسی کد در زبان مشخصات Scribble را به ادعاهای مشخصی تبدیل می کند که مشخصات را بررسی می کند.**
+
+- [مستندات](https://docs.scribble.codes/)
+
+**Dafny** - _*Dafny یک زبان برنامه نویسی آماده تأیید است که برای استدلال و اثبات درستی کد به حاشیه نویسی های سطح بالا متکی است.**
+
+- [گیتهاب](https://github.com/dafny-lang/dafny)
+
+
+
+### تأیید کننده های برنامه برای بررسی صحت {#program-verifiers}
+
+**Certora Prover** - _Certora Prover یک ابزار تأیید رسمی خودکار برای بررسی صحت کد در قراردادهای هوشمند است. مشخصات به زبان CVL (زبان تأیید Certora) نوشته شده است، با استفاده از ترکیبی از تجزیه و تحلیل استاتیک و حل محدودیت، نقض مالکیت شناسایی میشود._
+
+- [وبسایت](https://www.certora.com/)
+- [اسناد](https://docs.certora.com/en/latest/index.html)
+
+**Solidity SMTCchecker** - _*Solidity's SMTCchecker یک مدل بررسی کننده داخلی است که بر اساس SMT (تئوری های مدول رضایت پذیری) و حل شاخ است. تأیید می کند که کد منبع قرارداد با مشخصات در طول تدوین مطابقت دارد یا خیر و به طور ایستا نقض ویژگی های ایمنی را بررسی می کند.**
+
+- [گیتهاب](https://github.com/ethereum/solidity)
+
+**solc-verify** - _*solc-verify نسخه توسعه یافته کامپایلر سالیدیتی است که می تواند با استفاده از حاشیه نویسی و تأیید برنامه مدولار، تأیید رسمی خودکار را روی کد سالیدیتی انجام دهد.**
+
+- [گیتهاب](https://github.com/SRI-CSL/solidity)
+
+**KEVM** - _*KEVM یک معناشناسی رسمی از ماشین مجازی اتریوم (EVM) است که در چارچوب K نوشته شده است. KEVM قابل اجرا است و میتواند برخی ادعاهای مربوط به ویژگی را با استفاده از منطق دسترسپذیری اثبات کند.**
+
+- [گیتهاب](https://github.com/runtimeverification/evm-semantics)
+- [مستندات](https://jellopaper.org/)
+
+
+
+### چارچوب های منطقی برای اثبات قضیه {#theorem-provers}
+
+**Isabelle** - _Isabelle/HOL یک دستیار اثبات است که به فرمول های ریاضی اجازه می دهد تا به زبان رسمی بیان شوند و ابزارهایی برای اثبات آن فرمول ها فراهم می کند. کاربرد اصلی، رسمیسازی اثباتهای ریاضی و بهویژه تأیید رسمی است که شامل اثبات صحت سختافزار یا نرمافزار رایانه و اثبات ویژگیهای زبانها و پروتکلهای رایانه میشود._
+
+- [گیتهاب](https://github.com/isabelle-prover)
+- [مستندات](https://isabelle.in.tum.de/documentation.html)
+
+**Coq** - _Coq یک اثبات کننده قضیه تعاملی است که به شما امکان می دهد برنامه ها را با استفاده از قضایا تعریف کنید و به طور تعاملی اثبات صحت بررسی شده توسط ماشین را ایجاد کنید._
+
+- [گیتهاب](https://github.com/coq/coq)
+- [اسناد](https://coq.github.io/doc/v8.13/refman/index.html)
+
+
+
+### ابزارهای مبتنی بر اجرای نمادین برای تشخیص الگوهای آسیب پذیر در قراردادهای هوشمند {#symbolic-execution-tools}
+
+**Manticore** - _*ابزاری برای تجزیه و تحلیل ابزار تجزیه و تحلیل بایت کد EVM بر اساس اجرای نمادین*.*
+
+- [گیتهاب](https://github.com/trailofbits/manticore)
+- [مستندات](https://github.com/trailofbits/manticore/wiki)
+
+**hevm** - _*hevm یک موتور اجرای نمادین و جستجوگر معادل برای بایت کد EVM است.**
+
+- [گیت هاب](https://github.com/dapphub/dapptools/tree/master/src/hevm)
+
+**Mythil** - _ابزار اجرای نمادین برای شناسایی آسیبپذیریها در قراردادهای هوشمند اتریوم_
+
+- [گیتهاب](https://github.com/ConsenSys/mythril-classic)
+- [مستندات](https://mythril-classic.readthedocs.io/en/develop/)
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [چگونه تأیید رسمی قراردادهای هوشمند کار می کند؟](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/)
+- [چگونه تأیید رسمی می تواند قراردادهای هوشمند بی عیب و نقص را تضمین کند؟](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1)
+- [مروری بر پروژه های تایید رسمی در اکوسیستم اتریوم](https://github.com/leonardoalt/ethereum_formal_verification_overview)
+- [تایید رسمی اند تو اند قرارداد هوشمند سپرده گذاری اتریوم 2.0](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/)
+- [تایید رسمی محبوب ترین قرارداد هوشمند جهان](https://www.zellic.io/blog/formal-verification-weth)
+- [SMTCchecker و تأیید رسمی](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html)
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md b/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md
new file mode 100644
index 00000000000..beb008abc76
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md
@@ -0,0 +1,372 @@
+---
+title: آزمایش قرارداد هوشمند
+description: نمای کلی تکنیک ها و ملاحظات تست کردن قراردادهای هوشمند سالیدیتی.
+lang: fa
+---
+
+بلاک چین های عمومی مانند اتریوم تغییر ناپذیر هستند و تغییر کد قراردادهای هوشمند پس از استقرار را دشوار می کند. الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر این، یک ارتقا فقط میتواند یک خطا را پس از کشف آن برطرف کند - اگر مهاجم ابتدا آسیبپذیری را کشف کند، قرارداد هوشمند شما در معرض خطر سوء استفاده قرار میگیرد.
+الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر آن، بروزرسانی، فقط میتواند خطا را_پس از _ کشف شدن آن تصحیح کند - اگر یک مهاجم، زودتر از تصحیح آن خطا، خطا را پیدا کند، قرارداد هوشمند مربوطه در معرض سوء استفاده واقع میشود.
+
+به همین علت است که تست کردن قراردادهای هوشمند پیش از [دیپلوی](/developers/docs/smart-contracts/deploying/) بر روی شبکه اصلی، به عنوان حداقل میزان رعایت [ایمنی](/developers/docs/smart-contracts/security/) تلقی می شود. برای تست و ارزیابی میزان صحت کدهای قراردادهای هوشمند، تکنیک های مختلفی وجود دارد؛ این که انتخاب شما کدام تکنیک و به چه صورت باشد به نیازمندی و خواست خود شما بر میگردد. ضمناً، مجموعه های تستی که متشکل از ابزارها و نگرش های مختلف باشند به عنوان گزینه ای ایدهآل برای کشف و عیب یابی نواقص امنیتی کم اهمیت و پر اهمیت در کد کانترکت می باشند.
+
+
+
+## پیشنیازها {#prerequisites}
+
+در این صفحه به بررسی چگونگه تست قراردادهای هوشمند پیش از دیپلوی روی شبکه اتریوم می پردازیم. فرض بر این است که با [قراردادهای هوشمند](/developers/docs/smart-contracts/) آشنا هستید.
+
+
+
+## تست کردن قرارداد هوشمند چیست؟ {#what-is-smart-contract-testing}
+
+تست کردن قرارداد هوشمند پروسه ای است که با استفاده از آن می توانیم از صحت عملکرد کد قرارداد هوشمند به نسبت نحوه عملکرد آن کد اطمینان حاصل کنیم. در زمانی که بخواهیم از قابل اطمینان بودن، قابل استفاده بودن، و ایمنی قرارداد هوشمند مطمئن شویم، تست کردن بسیار کاربردی و مفید است.
+
+اگرچه که رویکردهای مختلفی وجود دارند، بیشتر روش های تست کردن مبنی بر اجرای یک قراردادهای هوشمند با نمونه کوچکی از داده هایی که انتظار اجرا شدن کدها با آن را داریم، میباشد. اگر کانترکت در ازای این داده های نمونه، جواب صحیح برگرداند، به معنای صحت عملکرد کد مربوطه است. بیشتر ابزارهای تست کردن، به منظور چک کردن تطابق نتایج حاصله با نتایج عملیاتی کانترکت، منابعی را به منظور نوشتن و اجرا کردن [موارد تست](https://en.m.wikipedia.org/wiki/Test_case) فراهم می کنند.
+
+
+
+### علت اهمیت تست قراردادهای هوشمند چیست؟ {#importance-of-testing-smart-contracts}
+
+قراردادهای هوشمند به طور معمول حجم زیادی از دارایی های مالی را مدیریت میکنند، کوچکترین اشتباه برنامه نویسی می تواند باعث [خسارت هنگفت به کاربران](https://rekt.news/leaderboard/) شود. تست دقیق، می تواند در یافتن عیب ها و مشکلات کد یک قرارداد هوشمند در مراحل اولیه، و تصحیح آنها پیش از عرضه کانترکت مربوطه، به شما کمک کند.
+
+اگرچه در صورتی که یک خطا یا باگ در قرارداد هوشمند کشف شود، امکان آپدیت و ارتقای آن وجود دارد، اما آپدیت کردن آن می تواند امری پیچیده بوده و در صورتی که به خطای مربوطه به درستی رسیدگی نشود، خود باعث [خطاهای دیگر](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) شود. علاوه بر آن، بروزرسانی یک کانترکت ناقض اصل تغییرناپذیری بوده و مفروضات اعتمادی اضافه ای را بر کاربران تحمیل می کند. برعکس، یک برنامه جامع برای آزمایش و تست قرارداد شما خطرات امنیتی قرارداد هوشمند را کاهش میدهد و نیاز به انجام ارتقاء منطقی پیچیده پس از استقرار یا دپلوی را کاهش میدهد.
+
+
+
+## روشهای تست قراردادهای هوشمند {#methods-for-testing-smart-contracts}
+
+روشهای تست قراردادهای هوشمند اتریوم در دو دسته کلی قرار میگیرند: **تست خودکار** و **تست دستی**. تست خودکار و تست دستی مزایا و بخشهای منحصر به فردی را ارائه میدهند، اما میتوانید هر دو را برای ایجاد یک برنامه قوی برای تجزیه و تحلیل قراردادهای خود ترکیب کنید.
+
+
+
+### تست خودکار {#automated-testing}
+
+تست خودکار از ابزارهایی استفاده میکند که به طور خودکار کد قراردادهای هوشمند را برای خطا در اجرا بررسی میکند. مزیت تست خودکار برای استفاده از [اسکریپتها](https://www.techtarget.com/whatis/definition/script?amp=1) برای راهنمایی ارزیابی عملکردهای قرارداد ناشی میشود. تست اسکریپتشده را میتوان برای اجرای مکرر با حداقل مداخله انسانی برنامهریزی کرد و تست خودکار را کارآمدتر از روشهای دستی برای تست کردن میکند.
+
+تست خودکار به ویژه زمانی مفید است که تستها تکراری و وقت گیر باشند. انجام تست دستی دشوار است؛ مستعد خطای انسانی؛ یا شامل ارزیابی عملکردهای مهم قرارداد میشود. اما ابزارهای تست خودکار میتوانند اشکالاتی داشته باشند—ممکن است برخی از اشکالات را از دست بدهند و [فضای مثبت کاذب](https://www.contrastsecurity.com/glossary/false-positive) زیادی ایجاد کنند. از این رو، جفت کردن تست خودکار با تست دستی برای قراردادهای هوشمند ایدهآل است.
+
+
+
+### تست دستی {#manual-testing}
+
+تست دستی به کمک انسان است و شامل اجرای هر یک از موارد تستی در مجموعه آزمایشی شما هنگام تجزیه و تحلیل صحت قراردادهای هوشمند است. این مورد برخلاف تست خودکار است که در آن میتوانید به طور همزمان چندین تست مجزا را روی یک قرارداد اجرا کرده و گزارشی دریافت کنید که تمام تستهای شکست خورده و قبولی را نشان میدهد.
+
+تست دستی میتواند توسط یک فرد به دنبال یک برنامه آزمون کتبی که سناریوهای مختلف آزمون را پوشش میدهد، انجام شود. همچنین میتوانید چندین فرد یا گروه را به عنوان بخشی از تست دستی و تعامل با یک قرارداد هوشمند در یک دوره مشخص بخواهید. تستکنندگان رفتار واقعی قرارداد را با رفتار مورد انتظار مقایسه کرده و هر تفاوتی را بهعنوان یک اشکال یا باگ علامتگذاری میکنند.
+
+تست دستی مؤثر به منابع قابلتوجهی (مهارت، زمان، پول و تلاش) نیاز دارد و ممکن است - به دلیل خطای انسانی - خطاهای خاصی را در حین اجرای تستها از دست داد. اما تست دستی نیز میتواند سودمند باشد - برای مثال، یک تستکننده انسانی (مثلاً یک حسابرس یا آدیتور) ممکن است از شهود برای تشخیص موارد که ابزار تست خودکار از دست میدهد استفاده کند.
+
+
+
+## تست خودکار برای قراردادهای هوشمند {#automated-testing-for-smart-contracts}
+
+
+
+### تست واحد {#unit-testing-for-smart-contracts}
+
+تست واحد عملکردهای قرارداد را به طور جداگانه ارزیابی و بررسی کرده که هر جزء به درستی کار میکند. تستهای واحد مطلوب باید ساده، سریع اجرا شوند و ایده روشنی از اینکه در صورت شکست تستها چه اشتباهی رخ داده است، ارائه دهند.
+
+تستهای واحد برای بررسی اینکه آیا توابع مقادیر مورد انتظار را برمیگردانند و اینکه ذخیرهسازی قرارداد بهدرستی پس از اجرای تابع بهروز شده است مفید هستند. علاوه بر این، اجرای تستهای واحد پس از ایجاد تغییرات در پایگاه کد قراردادها، تضمین میکند که افزودن منطق جدید باعث ایجاد خطا نمیشود. در زیر چند دستورالعمل برای اجرای تستهای واحد مؤثر آورده شده است:
+
+
+
+#### راهنماهایی برای تست واحد قراردادهای هوشمند {#unit-testing-guidelines}
+
+
+
+##### 1. منطق تجاری و گردش کار قراردادهای خود را درک کنید
+
+قبل از نوشتن تستهای واحد، دانستن اینکه یک قرارداد هوشمند چه ویژگیهایی را ارائه میدهد و کاربران چگونه به آن عملکردها دسترسی خواهند داشت و از آنها استفاده میکنند، کمک میکند. این مورد به ویژه برای اجرای [تستهای مسیر درست](https://en.m.wikipedia.org/wiki/Happy_path) مفید است که تعیین میکند آیا توابع در قرارداد، خروجی صحیح را برای ورودیهای معتبر کاربر برمیگردانند یا خیر. ما این مفهوم را با استفاده از این مثال (مختلف) از [یک قرارداد مزایده](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple- توضیح خواهیم داد. open-auction)
+
+
+
+```
+constructor(
+ uint biddingTime,
+ address payable beneficiaryAddress
+ ) {
+ beneficiary = beneficiaryAddress;
+ auctionEndTime = block.timestamp + biddingTime;
+ }
+
+function bid() external payable {
+
+ if (block.timestamp > auctionEndTime)
+ revert AuctionAlreadyEnded();
+
+ if (msg.value <= highestBid)
+ revert BidNotHighEnough(highestBid);
+
+ if (highestBid != 0) {
+ pendingReturns[highestBidder] += highestBid;
+ }
+ highestBidder = msg.sender;
+ highestBid = msg.value;
+ emit HighestBidIncreased(msg.sender, msg.value);
+ }
+
+ function withdraw() external returns (bool) {
+ uint amount = pendingReturns[msg.sender];
+ if (amount > 0) {
+ pendingReturns[msg.sender] = 0;
+
+ if (!payable(msg.sender).send(amount)) {
+ pendingReturns[msg.sender] = amount;
+ return false;
+ }
+ }
+ return true;
+ }
+
+function auctionEnd() external {
+ if (block.timestamp < auctionEndTime)
+ revert AuctionNotYetEnded();
+ if (ended)
+ revert AuctionEndAlreadyCalled();
+
+ ended = true;
+ emit AuctionEnded(highestBidder, highestBid);
+
+ beneficiary.transfer(highestBid);
+ }
+}
+```
+
+
+این یک قرارداد مزایده ساده است که برای دریافت پیشنهادها در طول دوره مناقصه طراحی شده است. اگر این مورد `highestBid` افزایش یابد، بالاترین پیشنهاد قبلی پول خود را دریافت میکند. پس از پایان دوره مناقصه، `ذینفع` قرارداد را فراخوانی میکند تا پول خود را دریافت کند.
+
+تستهای واحد برای قراردادی مانند این، عملکردهای مختلفی را که کاربر ممکن است هنگام تعامل با قرارداد فراخوانی کند، پوشش میدهد. یک مثال برای تست واحد این است که بررسی میکند آیا کاربر میتواند در حین انجام مزایده پیشنهادی ارائه دهد (یعنی تماسهای `قیمتگذاری()` موفقیتآمیز است) یا آزمایشی که بررسی میکند آیا کاربر میتواند پیشنهاد بالاتری از پیشنهاد فعلی ارائه دهد یا خیر. `highestBid`.
+
+همچنین درک گردش کار عملیاتی قراردادها به نوشتن تستهای واحد کمک میکند تا بررسی کند که آیا اجرا با الزامات مطابقت دارد یا خیر. برای مثال، قرارداد مزایده مشخص میکند که کاربران نمیتوانند پس از پایان حراج، پیشنهاد بدهند (یعنی زمانی که `زمان مزایده یا حراج تمام شود` کمتر از `block.timestamp` است). بنابراین، یک توسعهدهنده ممکن است تست واحدی را اجرا کند که بررسی میکند آیا فراخوانیهای تابع `bid()` موفق میشوند یا شکست میخورند پس از پایان حراج (یعنی وقتی `auctionEndTime` > `block.timestamp`).
+
+
+
+##### 2. کلیه مفروضات مربوط به اجرای قرارداد را ارزیابی کنید
+
+ثبت هرگونه فرضی در مورد اجرای قرارداد و نوشتن تستهای واحد برای تأیید صحت آن مفروضات مهم است. جدا از ارائه محافظت در برابر اجرای غیرمنتظره، اظهارات تست شما را مجبور میکند به عملیاتی فکر کنید که میتواند مدل امنیتی قراردادهای هوشمند را شکست دهد. یک نکته مفید این است که فراتر از "تستهای کاربر" بروید و تستهای منفی بنویسید که بررسی میکند آیا یک تابع برای ورودیهای اشتباه ناموفق است یا خیر.
+
+بسیاری از فریم ورکهای تست واحد به شما اجازه میدهند تا اظهارات را ایجاد کنید - عبارتهای سادهای که بیان میکند قرارداد چه کاری میتواند انجام دهد و چه کاری نمیتواند انجام دهد - و تستهایی را برای مشاهده اینکه آیا این ادعاها در حال اجرا هستند یا خیر، اجرا کنید. توسعهدهندهای که روی قرارداد حراج که قبلاً توضیح داده شد کار میکند، میتواند پیش از اجرای تستهای منفی، در مورد رفتار خود اظهارات زیر را بیان کند:
+
+- وقتی مزایده تمام شده یا شروع نشده است، کاربران نمیتوانند پیشنهاد دهند.
+
+- اگر پیشنهادی کمتر از آستانه قابل قبول باشد، قرارداد مزایده لغو میشود.
+
+- کاربرانی که موفق به برنده شدن در مناقصه نشوند با وجوه خود اعتبار داده میشوند
+
+**نکته**: روش دیگری برای تست مفروضات، نوشتن تستهایی است که [مادیفایر یا اصلاحکننده تابع](https://docs.soliditylang.org/en/v0.8.16/contracts را راهاندازی میکنند. html#function-modifiers) در یک قرارداد، به خصوص عبارتهای `require`، `assert` و `if…else`.
+
+
+
+##### 3. پوشش کد را اندازهگیری کنید (code coverage)
+
+[پوشش کد](https://en.m.wikipedia.org/wiki/Code_coverage) یک معیار آزمایشی است که تعداد شاخهها، خطوط و عبارات کد شما را که در طول تستها اجرا میشوند، ردیابی میکند. تستها باید پوشش کد خوبی داشته باشند، در غیر این صورت ممکن است "منفی کاذب" دریافت کنید و زمانی اتفاق میافتد که یک قرارداد همه تستها را با موفقیت پشت سر میگذارد، اما آسیب پذیریها همچنان در کد وجود دارد. با این حال، ثبت پوشش بالای کد این اطمینان را به شما میدهد که تمام عبارات/عملکردهای یک قرارداد هوشمند به اندازه کافی برای صحت تست شدهاند.
+
+
+
+##### 4. از فریم ورکهای آزمایشی توسعه یافته استفاده کنید
+
+کیفیت ابزارهای مورد استفاده در اجرای تستهای واحد برای قراردادهای هوشمند شما بسیار مهم است. یک فریم ورک تست ایده آل، فریم ورکی است که به طور منظم نگهداری شود. ویژگیهای مفیدی را ارائه میدهد (به عنوان مثال، قابلیتهای ثبت و گزارش). و باید به طور گسترده توسط توسعه دهندگان دیگر مورد استفاده و بررسی قرار گرفته باشد.
+
+فریم ورکهای تست واحد برای قراردادهای هوشمند سالیدیتی به زبانهای مختلف (عمدتاً جاوا اسکریپت، پایتون و Rust) ارائه میشوند. برخی از راهنماهای زیر را برای اطلاع از نحوه شروع اجرای تستهای واحد با فریم ورکهای تست مختلف مشاهده کنید:
+
+- **[اجرای تست واحد با Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
+- **[اجرای تست واحد با فوندری](https://book.getfoundry.sh/forge/writing-tests)**
+- **[اجرای تست واحد با وافل](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
+- **[اجرای تست واحد با ریمیکس](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
+- **[اجرای تست واحد با ایپ](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
+- **[اجرای تستهای واحد با هاردهات](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
+- **[اجرای تستهای واحد با Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
+
+
+
+### تست یکپارچهسازی {#integration-testing-for-smart-contracts}
+
+در حالی که تست واحد عملکردهای قرارداد را به صورت مجزا اشکال زدایی میکند، تستهای یکپارچهسازی اجزای یک قرارداد هوشمند را به عنوان یک کل ارزیابی میکنند. تست یکپارچه سازی میتواند مشکلات ناشی از فراخوانیهای قراردادی متقابل یا تعامل بین عملکردهای مختلف در یک قرارداد هوشمند را شناسایی کند. به عنوان مثال، تستهای یکپارچهسازی میتوانند به بررسی اینکه آیا مواردی مانند [ارثبری](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) و وابستگی به درستی کار میکنند یا خیر کمک میکند.
+
+تست یکپارچهسازی در صورتی مفید است که قرارداد شما در طول اجرا از معماری مدولار استفاده کند یا با سایر قراردادهای زنجیرهای ارتباط برقرار کند. یکی از راههای اجرای تستهای یکپارچهسازی این است که [بلاک چین](/glossary/#fork) را در یک ارتفاع خاص (با استفاده از ابزاری مانند [Forge](https://book.getfoundry.sh فورک کنید. /forge/fork-testing) یا [هاردهت](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) و تعاملات بین قرارداد شما و قراردادهای مستقر را شبیهسازی کنید.
+
+بلاک چین فورک شده مشابه شبکه اصلی رفتار خواهد کرد و دارای حسابهایی با وضعیتها و موجودیهای مرتبط است. اما فقط به عنوان یک محیط توسعه محلی سندباکس شده عمل میکند، به این معنی که برای تراکنشها به ETH واقعی نیاز نخواهید داشت، همچنین تغییرات شما بر پروتکل واقعی اتریوم تأثیر نمیگذارد.
+
+
+
+### تست مبتنی بر مشخصات {#property-based-testing-for-smart-contracts}
+
+تست مبتنی بر دارایی فرآیند بررسی این است که آیا قرارداد هوشمند برخی از ویژگیهای تعریف شده را برآورده میکند یا خیر. ویژگیها حقایقی را در مورد رفتار قرارداد بیان میکنند که انتظار میرود در سناریوهای مختلف درست باقی بماند - نمونهای از ویژگی قرارداد هوشمند میتواند "عملیات حسابی در قرارداد هرگز اورفلو یا آندرفلو" نباشد
+
+**تحلیل استاتیک** و **تحلیل دینامیکی** دو تکنیک رایج برای اجرای تست مبتنی بر ویژگی هستند و هر دو میتوانند تأیید کنند که کد یک برنامه (یک قرارداد هوشمند در این مورد) برخی از ویژگیهای از پیش تعریف شده را برآورده میکند. برخی از ابزارهای تست مبتنی بر دارایی با قوانین از پیش تعریف شده در مورد ویژگیهای قرارداد مورد انتظار ارائه میشوند و کد را در برابر آن قوانین بررسی میکنند، در حالی که برخی دیگر به شما امکان میدهند ویژگیهای سفارشی را برای یک قرارداد هوشمند ایجاد کنید.
+
+
+
+#### تجزیه و تحلیل استاتیک {#static-analysis}
+
+یک آنالایزر استاتیک کد منبع یک قرارداد هوشمند را به عنوان ورودی دریافت کرده و نتایج را با اعلام اینکه آیا قرارداد یک ویژگی را برآورده میکند یا نه، خروجی میگیرد. بر خلاف تحلیل پویا، تحلیل استاتیک شامل اجرای قرارداد برای تجزیه و تحلیل آن برای صحت نیست. تجزیه و تحلیل استاتیک در عوض درباره تمام مسیرهای احتمالی که یک قرارداد هوشمند میتواند در طول اجرا طی کند (به عنوان مثال، با بررسی ساختار کد منبع برای تعیین معنای آن برای عملیات قراردادها در زمان اجرا) استدلال میکند.
+
+[Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) و [تست استاتیک](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) روشهای رایج برای اجرای تحلیل استاتیک در قراردادها هستند. هر دو نیازمند تجزیه و تحلیل نمایشهای سطح پایین اجرای قرارداد هستند، مانند [درخت نحو انتزاعی](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) و [کنترل نمودارهای جریان](https: //www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) خروجی توسط کامپایلر.
+
+در بیشتر موارد، تجزیه و تحلیل استاتیک برای تشخیص مسائل ایمنی مانند استفاده از ساختارهای ناامن، خطاهای نحوی یا نقض استانداردهای کدگذاری در کد قرارداد مفید است. با این حال، آنالایزرهای استاتیک به طور کلی در تشخیص آسیبپذیریهای عمیقتر نامطلوب هستند و ممکن است مثبت کاذب بیش از حد تولید کنند.
+
+
+
+#### تحلیل دینامیک {#dynamic-analysis}
+
+تحلیل پویا ورودیهای نمادین (مثلاً در [اجرای نمادین](https://en.m.wikipedia.org/wiki/Symbolic_execution)) یا ورودیهای مشخص (مثلاً در [fuzzing](https://owasp.org/www-community/Fuzzing)) به یک قرارداد هوشمند عمل میکند تا ببیند آیا هر رد یا تریس(های) اجرایی خاصیت خاصی را نقض میکند یا خیر. این شکل از تست مبتنی بر ویژگی با تستهای واحد متفاوت است، زیرا موارد تست سناریوهای متعددی را پوشش میدهند و یک برنامه تولید موارد تست را انجام میدهد.
+
+[Fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) نمونهای از تکنیک تحلیل پویا برای تأیید ویژگیهای دلخواه در قراردادهای هوشمند است. یک فازر توابع را در یک قرارداد هدف با تغییرات تصادفی یا به شکل نادرست یک مقدار ورودی تعریف شده فراخوانی میکند. اگر قرارداد هوشمند وارد یک حالت خطا شود (به عنوان مثال، وضعیتی که یک ادعا با شکست مواجه شود)، مشکل علامتگذاری میشود و ورودیهایی که اجرا را به سمت مسیر آسیبپذیر هدایت میکند در یک گزارش تولید میشود.
+
+فازینگ برای ارزیابی مکانیزم اعتبارسنجی ورودی قراردادهای هوشمند مفید است زیرا مدیریت نادرست ورودیهای غیرمنتظره ممکن است منجر به اجرای ناخواسته و ایجاد اثرات خطرناک شود. این شکل از تست مبتنی بر ویژگی میتواند به دلایل زیادی ایدهآل باشد:
+
+1. **نوشتن موارد تست برای پوشش دادن بسیاری از سناریوها دشوار است.** تست ویژگی فقط مستلزم آن است که یک رفتار و طیف وسیعی از دادهها را برای تست رفتار تعریف کنید—برنامه به طور خودکار تست را تولید میکند و موارد بر اساس ویژگی تعریف شده است.
+
+2. **مجموعه تست شما ممکن است به اندازه کافی تمام مسیرهای ممکن در برنامه را پوشش ندهد.** حتی با پوشش ۱۰۰٪، ممکن است موارد حیاتی را از دست بدهید.
+
+3. **تستهای واحد ثابت میکنند که یک قرارداد برای دادههای نمونه به درستی اجرا میشود، اما اینکه آیا قرارداد برای ورودیهای خارج از نمونه به درستی اجرا میشود یا خیر، ناشناخته باقی میماند.** تستهای ویژگی، یک قرارداد هدف را با تغییرات چندگانه یک قرارداد اجرا میکنند. مقدار ورودی داده شده برای یافتن آثار اجرایی که باعث شکست ادعا میشوند. بنابراین، یک تست ویژگی تضمینهای بیشتری برای اجرای صحیح قرارداد برای یک کلاس وسیع از دادههای ورودی ارائه میدهد.
+
+
+
+### دستورالعملهایی برای اجرای تست مبتنی بر اموال برای قراردادهای هوشمند {#running-property-based-tests}
+
+اجرای تست مبتنی بر ویژگی معمولاً با تعریف یک ویژگی (به عنوان مثال، عدم وجود [اورفلو عدد صحیح](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) یا مجموعهای از ویژگیهایی که میخواهید در یک قرارداد هوشمند تأیید کنید، میباشد. همچنین ممکن است لازم باشد محدودهای از مقادیر را تعریف کنید که در آن برنامه میتواند دادههایی را برای ورودیهای تراکنش هنگام نوشتن تستهای ویژگی تولید کند.
+
+هنگامی که به درستی پیکربندی شد، ابزار تست، توابع قراردادهای هوشمند شما را با ورودیهای تولید شده بهطور تصادفی اجرا میکند. در صورت وجود هرگونه تخلف ادعایی، باید گزارشی با دادههای ورودی مشخص دریافت کنید که دارایی تحت ارزیابی را نقض میکند. برای شروع تست مبتنی بر ویژگی با ابزارهای مختلف، برخی از راهنماهای زیر را ببینید:
+
+- **[تجزیه و تحلیل استاتیک قراردادهای هوشمند با اسلیتر (Slither)](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)**
+- **[تجزیه و تحلیل استاتیک قراردادهای هوشمند با Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
+- **[تست مبتنی بر ویژگی با Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
+- **[قراردادهای فازی با فاندری (Foundry)](https://book.getfoundry.sh/forge/fuzz-testing)**
+- **[قراردادهای فازی با Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
+- **[قراردادهای فازی با ویک](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
+- **[اجرای نمادین قراردادهای هوشمند با مانتیکر (Manticore)](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
+- **[اجرای نمادین قراردادهای هوشمند با Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
+
+
+
+## تست دستی برای قراردادهای هوشمند {#manual-testing-for-smart-contracts}
+
+تست دستی قراردادهای هوشمند اغلب بعد از اجرای تستهای خودکار در چرخه توسعه انجام میشود. این شکل از تست قرارداد هوشمند را به عنوان یک محصول کاملاً یکپارچه ارزیابی میکند تا ببیند آیا مطابق با الزامات فنی مشخص شده است یا خیر.
+
+
+
+### تست قراردادها بر روی یک بلاک چین لوکال {#testing-on-local-blockchain}
+
+در حالی که تست خودکار انجام شده در یک محیط توسعه محلی یا لوکال میتواند اطلاعات مفیدی برای اشکال زدایی یا دیباگ کردن ارائه دهد، شما باید بدانید که قرارداد هوشمند شما در یک محیط تولید چگونه رفتار میکند. با این حال، استقرار یا دپلوی در زنجیره اصلی اتریوم مستلزم هزینههای گس است – ناگفته نماند که اگر قرارداد هوشمند شما همچنان دارای اشکال یا باگ باشد، شما یا کاربرانتان میتوانید پول واقعی خود را از دست بدهید.
+
+تست قرارداد خود بر روی یک بلاک چین محلی (همچنین به عنوان [شبکه توسعه](/developers/docs/development-networks/) نیز شناخته می شود) جایگزین توصیه شده برای آزمایش در شبکه اصلی است. یک بلاک چین محلی یک کپی از بلاک چین اتریوم است که به صورت محلی روی رایانه شما اجرا میشود و رفتار لایه اجرایی اتریوم را شبیهسازی میکند. به این ترتیب، میتوانید تراکنشها را طوری برنامهریزی کنید که با یک قرارداد تعامل داشته باشند، بدون اینکه هزینههای بیشتر قابلتوجهی را متحمل شوند.
+
+اجرای قراردادها بر روی یک بلاک چین محلی میتواند به عنوان نوعی تست ادغام دستی مفید باشد. [قراردادهای هوشمند بسیار قابل ترکیب هستند](/developers/docs/smart-contracts/composability/)، به شما امکان میدهد با پروتکلهای موجود ادغام کنید—اما همچنان باید اطمینان حاصل کنید که چنین بخش پیچیدهای در زنجیره فعل و انفعالات نتایج صحیح را ایجاد میکند.
+
+[اطلاعات بیشتر در مورد شبکههای توسعه.](/developers/docs/development-networks/)
+
+
+
+### تست قراردادها بر روی تست نتها یا شبکه آزمایشی {#testing-contracts-on-testnets}
+
+یک شبکه آزمایشی دقیقاً مانند شبکه اصلی اتریوم کار میکند، با این تفاوت که از اتر (ETH) بدون ارزش واقعی استفاده میکند. استقرار قرارداد خود در یک [شبکه آزمایشی](/developers/docs/networks/#ethereum-testnets) به این معنی است که هر کسی میتواند با آن تعامل داشته باشد (مثلاً از طریق فرانتاند برنامه غیرمتمرکز) بدون اینکه سرمایهای را در معرض خطر قرار دهد.
+
+این شکل از تست دستی برای ارزیابی جریان انتها به انتها برنامه شما از دیدگاه کاربر مفید است. در اینجا، آزمایشکنندههای بتا میتوانند اجرای آزمایشی را نیز انجام دهند و هرگونه مشکل در منطق تجاری و عملکرد کلی قرارداد را گزارش کنند.
+
+استقرار یا دپلوی در یک شبکه آزمایشی پس از تست بر روی یک بلاک چین محلی ایدهآل است زیرا مورد اول به رفتار ماشین مجازی اتریوم نزدیکتر است. بنابراین، برای بسیاری از پروژههای بومی اتریوم، استفاده از برنامههای غیرمتمرکز در شبکههای آزمایشی برای ارزیابی عملیات قراردادهای هوشمند در شرایط دنیای واقعی رایج است.
+
+[اطلاعات بیشتر در مورد شبکههای آزمایشی اتریوم.](/developers/docs/development-networks/#public-beacon-testchains)
+
+
+
+## تست در مقابل تأیید رسمی {#testing-vs-formal-verification}
+
+در حالی که تست کمک میکند تا تأیید شود که یک قرارداد نتایج مورد انتظار را برای برخی از ورودیهای داده برمیگرداند یا خیر، ولی نمیتواند به طور قطعی همان را برای ورودیهایی که در طول تست استفاده نشدهاند ثابت کند. بنابراین، تست یک قرارداد هوشمند نمیتواند «صحت عملکردی» را تضمین کند (یعنی نمیتواند نشان دهد که یک برنامه برای _همه_ مجموعههای مقادیر ورودی، آنطور که لازم است رفتار میکند).
+
+تأیید رسمی رویکردی برای ارزیابی صحت نرمافزار با بررسی اینکه آیا مدل رسمی برنامه با مشخصات رسمی مطابقت دارد یا خیر. یک مدل رسمی یک نمایش ریاضی انتزاعی از یک برنامه است، در حالی که یک مشخصات رسمی ویژگیهای یک برنامه را تعریف میکند (یعنی ادعاهای منطقی در مورد اجرای برنامه).
+
+از آنجایی که ویژگیها به صورت ریاضی نوشته شدهاند، میتوان تأیید کرد که یک مدل رسمی (ریاضی) سیستم با استفاده از قوانین منطقی استنتاج، مشخصاتی را برآورده میکند یا خیر. بنابراین، گفته میشود که ابزارهای تأیید رسمی «اثبات ریاضی» درستی یک سیستم را ارائه میدهند.
+
+برخلاف تست، تأیید رسمی میتواند برای تأیید اینکه اجرای قراردادهای هوشمند دارای مشخصات رسمی برای _همه_ اجراها است (یعنی بدون باگ) بدون نیاز به اجرای آن با نمونه دادهها استفاده شود. این مورد نه تنها زمان صرف شده برای اجرای دهها تست واحد را کاهش میدهد، بلکه در شناسایی آسیبپذیریهای پنهان نیز موثرتر است. گفتنی است، تکنیکهای تأیید رسمی بسته به دشواری اجرا و مفید بودنشان در طیفی قرار دارند.
+
+[بیشتر در مورد تأیید رسمی برای قراردادهای هوشمند.](/developers/docs/smart-contracts/formal-verification)
+
+
+
+## تست در مقابل ممیزی یا آدیت و پاداش باگ {#testing-vs-audits-bug-bounties}
+
+همانطور که ذکر شد، تست دقیق به ندرت میتواند عدم وجود اشکال یا باگ در قرارداد را تضمین کند. رویکردهای تأیید رسمی میتوانند تضمینهای قویتری از صحت ارائه دهند، اما در حال حاضر استفاده از آنها دشوار است و هزینههای قابل توجهی را متحمل میشود.
+
+با این وجود، میتوانید با بررسی کد مستقل، امکان شناسایی آسیبپذیریهای قرارداد را بیشتر کنید. [ممیزی یا آدیت قراردادهای هوشمند](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) و [پاداشهای باگ](https://medium. com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) دو راه برای ترغیب دیگران به تجزیه و تحلیل قراردادهای شما هستند.
+
+ممیزیها توسط حسابرسان با تجربه در یافتن موارد نقص امنیتی و شیوههای توسعه ضعیف در قراردادهای هوشمند انجام میشود. ممیزی معمولاً شامل تست (و احتمالاً تأیید رسمی) و همچنین بررسی دستی کل پایگاه کد است.
+
+برعکس، برنامه پاداش باگ معمولاً شامل ارائه پاداش مالی به یک فرد است (که معمولاً به عنوان [هکرهای کلاه سفید](https://en.wikipedia.org/wiki/White_hat_(computer_security)) توصیف میشود) یک آسیبپذیری را در یک قرارداد هوشمند کشف کرده و آن را برای توسعهدهندگان فاش میکند. پاداش باگ مشابه ممیزی یا آدیت است زیرا شامل درخواست از دیگران برای کمک به یافتن نقص در قراردادهای هوشمند است.
+
+تفاوت عمده این است که برنامههای پاداش باگ برای جامعه توسعهدهندگان/هکرهای گستردهتر باز است و طبقه وسیعی از هکرهای اخلاقی و متخصصان امنیتی مستقل را با مهارتها و تجربههای منحصربهفرد جذب میکنند. این مورد ممکن است یک مزیت نسبت به ممیزی یا آدیت قراردادهای هوشمند باشد که عمدتاً به تیمهایی متکی است که ممکن است تخصص محدودی داشته باشند.
+
+
+
+## کتابخانهها و ابزارهای آزمایش {#testing-tools-and-libraries}
+
+
+
+### ابزار تست واحد {#unit-testing-tools}
+
+- **[کاورج یا پوشش سالیدیتی](https://github.com/sc-forks/solidity-coverage)** - _ابزار پوشش کد برای قراردادهای هوشمند نوشته شده در سالیدیتی است._
+
+- **[وافل](https://ethereum-waffle.readthedocs.io/en/latest/)** - *چارچوبی برای توسعه و تست قراردادهای هوشمند پیشرفته (بر اساس ethers.js) است*.
+
+- **[تستهای ریمیکس](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _ابزاری برای آزمایش قراردادهای هوشمند سالیدیتی است. در زیر پلاگین ریمیکس "Solidity Unit Testing" کار میکند که برای نوشتن و اجرای موارد تست برای قرارداد استفاده میشود._
+
+- **[کمککننده تست اوپن زپلین](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _کتابخانه ازرشن برای تست قرارداد هوشمند اتریوم. مطمئن شوید که قراردادهای شما مطابق انتظار عمل می کند!_
+
+- **[فریم ورک تست واحد براونی](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _براونی از Pytest استفاده میکند، یک فریم ورک تستی غنی از ویژگیها که به شما امکان میدهد تستهای کوچک را با حداقل کد بنویسید و برای پروژههای بزرگ مقیاسپذیری خوبی دارد و بسیار قابل توسعه است._
+
+- **[تستهای فاندری ](https://github.com/foundry-rs/foundry/tree/master/forge)** - _Foundry Forge را ارائه میکند، یک فریم ورک آزمایشی سریع و انعطافپذیر اتریوم که قادر به اجرای آزمایشهای واحد ساده، بررسیهای بهینهسازی گس و فازبندی قرارداد است._
+
+- **[تستهای هاردهت](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _چارچوبی برای آزمایش قراردادهای هوشمند مبتنی بر ethers.js، موکا و چای است._
+
+- **[ایپ ورکس](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _چارچوب توسعه و آزمایش مبتنی بر پایتون برای قراردادهای هوشمند با هدف قرار دادن ماشین مجازی اتریوم است._
+
+- **[ویک](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _چارچوب مبتنی بر پایتون برای آزمایش واحد و فازی کردن با قابلیتهای اشکالزدایی قوی و پشتیبانی از آزمایش زنجیرهای متقابل، استفاده از pytest و Anvil برای بهترین تجربه و عملکرد کاربر است._
+
+
+
+### ابزارهای تست مبتنی بر ویژگی {#property-based-testing-tools}
+
+
+
+#### ابزارهای تحلیل استاتیکی {#static-analysis-tools}
+
+- **[Slither](https://github.com/crytic/slither)** - _Python- فریم ورک تجزیه و تحلیل استاتیک سالیدیتی برای یافتن آسیبپذیریها، بهبود درک کد و نوشتن تحلیلهای سفارشی برای قراردادهای هوشمند._
+
+- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _دریچهای برای اعمال بهترین شیوهها و شیوههای امنیتی برای زبان برنامه نویسی قرارداد هوشمند سالیدیتی است._
+
+- **[سایفرین آدرین](https://cyfrin.io/tools/aderyn)** - _تحلیلگر استاتیک مبتنی بر استاتیک که به طور خاص برای امنیت و توسعه قراردادهای هوشمند وب3 طراحی شده است._
+
+- **[ویک](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - < em x-id="4">چارچوب تحلیل استاتیک مبتنی بر پایتون با آشکارسازهای آسیبپذیری و کیفیت کد، چاپگرهایی برای استخراج اطلاعات مفید از کد و پشتیبانی برای نوشتن زیرماژولهای سفارشی.
+
+
+
+#### ابزارهای تحلیل پویا {#dynamic-analysis-tools}
+
+- **[اکیدنا](https://github.com/crytic/echidna/)** - _فازر سریع قرارداد برای شناسایی آسیبپذیریها در قراردادهای هوشمند از طریق تست مبتنی بر دارایی است._
+
+- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _ابزار فازینگ خودکار برای تشخیص تخلفات دارایی در کد قرارداد هوشمند مفید است._
+
+- **[مانتیکر](https://manticore.readthedocs.io/en/latest/index.html)** - _فریم ورک اجرای نمادین پویا برای تجزیه و تحلیل بایت کد ماشین مجازی اتریوم است._
+
+- **[میثریل (Mythril)](https://github.com/ConsenSys/mythril-classic)** - _ ابزار ارزیابی بایت کد ماشین مجازی اتریوم برای شناسایی آسیبپذیریهای قرارداد با استفاده از تجزیه و تحلیل تینت، تجزیه و تحلیل کونکولیک، و بررسی جریان کنترل است._
+
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _ Scribble یک زبان مشخصات و ابزار تأیید زمان اجرا است که به شما امکان میدهد قراردادهای هوشمند را با ویژگیهایی حاشیه نویسی کنید که به شما امکان میدهد به طور خودکار قراردادها را با ابزارهایی مانند Diligence Fuzzing یا MythX تست کنید._
+
+
+
+## آموزشهای مرتبط {#related-tutorials}
+
+- [نمای کلی و مقایسه محصولات تست مختلف](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
+- [نحوه استفاده از Echidna برای آزمایش قراردادهای هوشمند](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
+- [نحوه استفاده از Manticore برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+- [نحوه استفاده از Slither برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+- [چگونه قراردادهای Solidity را برای آزمایش شبیه سازی کنیم](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [نحوه اجرای تست های واحد در سالیدیتی با استفاده از Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [راهنمای عمیق برای تست قراردادهای هوشمند اتریوم](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
+- [نحوه تست قراردادهای هوشمند اتریوم](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
+- [راهنمای تست واحد مولوک دائو (MolochDAO) برای توسعه دهندگان](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
+- [نحوه تست قراردادهای هوشمند مانند یک حرفهای](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/fa/developers/docs/smart-contracts/upgrading/index.md
new file mode 100644
index 00000000000..0e913098cac
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/smart-contracts/upgrading/index.md
@@ -0,0 +1,165 @@
+---
+title: ارتقای قراردادهای هوشمند
+description: نگاهی کلی به الگوهای ارتقا برای قراردادهای هوشمند اتریوم
+lang: fa
+---
+
+قراردادهای هوشمند در اتریوم برنامههای خودکاری هستند که در ماشین مجازی اتریوم (EVM) اجرا میشوند. این برنامه ها از نظر طراحی تغییر ناپذیر هستند که از هرگونه بهروز رسانی منطق تجاری پس از پیادهسازی و استقرار قرارداد جلوگیری می کند.
+
+در حالی که این تغییرناپذیری برای حداقل سازی اعتماد، عدم تمرکز و امنیت قراردادهای هوشمند ضروریاند، ممکن است در برخی موارد مشکلاتی ایجاد کنند. برای مثال، کد تغییرناپذیر باعث میشود تا اصلاح کد قرارداد هوشمندی که دارای نقص امنیتی است امکانناپذیر شود.
+
+با این حال، افزایش تحقیقات در مورد بهبود قراردادهای هوشمند منجر به معرفی چندین الگوی ارتقاء شده است. این الگوهای ارتقاء به توسعه دهندگان این امکان را می دهد تا با قرار دادن منطق تجاری در قراردادهای مختلف، قراردادهای هوشمند را (در عین حفظ تغییر ناپذیری) ارتقا دهند.
+
+## پیشنیازها {#prerequisites}
+
+شما باید درک خوبی از [قراردادهای هوشمند](/developers/docs/smart-contracts/)، [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) و [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) داشته باشید. این راهنما همچنین فرض میکند که خوانندگان درک درستی از برنامهنویسی قراردادهای هوشمند دارند.
+
+## ارتقاء قرارداد هوشمند چیست؟ {#what-is-a-smart-contract-upgrade}
+
+ارتقای قرارداد هوشمند شامل تغییر منطق تجاری یک قرارداد هوشمند و در عین حال حفظ وضعیت قرارداد است. واضح است که قابلیت ارتقا و تغییرپذیری یکسان نیستند، به خصوص در زمینه قراردادهای هوشمند.
+
+شما هنوز نمی توانید یک برنامه مستقر شده را به آدرسی در شبکه اتریوم تغییر دهید. اما میتوانید کدی را که هنگام تعامل کاربران با یک قرارداد هوشمند اجرا میشود، تغییر دهید.
+
+این کار از طریق روش های زیر قابل انجام است:
+
+1. ایجاد چندین نسخه از یک قرارداد هوشمند و انتقال حالت (یعنی داده ها) از قرارداد قدیمی به نمونه جدیدی از قرارداد.
+
+2. ایجاد قراردادهای جداگانه برای ذخیره کردن منطق تجاری و حالت.
+
+3. استفاده از الگوهای پراکسی برای واگذاری فراخوانی های تابع از یک قرارداد پروکسی تغییرناپذیر به یک قرارداد منطقی قابل تغییر.
+
+4. ایجاد یک قرارداد اصلی تغییر ناپذیر که با قراردادهای ماهواره ای انعطاف پذیر برای اجرای عملکردهای خاص ارتباط برقرار می کند و به آنها متکی است.
+
+5. استفاده از الگوی الماس برای واگذاری فراخوانی های تابع از یک قرارداد پراکسی به قراردادهای منطقی.
+
+### مکانیسم ارتقا شماره 1: انتقال قرارداد {#contract-migration}
+
+انتقال قرارداد مبتنی بر نسخه سازی است - ایده ایجاد و مدیریت حالت های منحصر به فرد یک نرم افزار. انتقال قرارداد شامل استقرار یک نمونه جدید از یک قرارداد هوشمند موجود و انتقال ذخیره و موجودی به قرارداد جدید است.
+
+قراردادی که به تازگی مستقر شده است یک فضای ذخیره خالی خواهد داشت که به شما امکان می دهد داده ها را از قرارداد قدیمی بازیابی کنید و آن را در پیاده سازی جدید بنویسید. پس از آن، باید همه قراردادهایی را که با قرارداد قدیمی در تعامل بودند، بهروزرسانی کنید تا نشانی جدید را منعکس کنند.
+
+آخرین مرحله در انتقال قرارداد متقاعد کردن کاربران برای تغییر استفاده از قرارداد جدید است. نسخه جدید قرارداد تعادل و آدرس های کاربر را حفظ می کند که تغییر ناپذیری را حفظ می کند. اگر این قرارداد مبتنی بر توکن است، همچنین باید با صرافیها تماس بگیرید تا قرارداد قدیمی را کنار بگذارید و از قرارداد جدید استفاده کنید.
+
+انتقال قرارداد یک اقدام نسبتاً ساده و ایمن برای ارتقاء قراردادهای هوشمند بدون ایجاد اختلال در تعاملات کاربر است. با این حال، انتقال دستی ذخیره سازی و موجودی کاربر به قرارداد جدید زمان بر است و می تواند کارمزد گس زیادی را به همراه داشته باشد.
+
+[اطلاعات بیشتر در مورد انتقال قرارداد.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
+
+### مکانیسم ارتقاء شماره 2: جداسازی داده ها {#data-separation}
+
+روش دیگر برای ارتقای قراردادهای هوشمند، تفکیک منطق تجاری و ذخیره داده ها به قراردادهای جداگانه است. این بدان معنی است که کاربران با قرارداد منطقی تعامل دارند، در حالی که داده ها در قرارداد ذخیره سازی ذخیره می شوند.
+
+قرارداد منطقی شامل کدی است که هنگام تعامل کاربران با برنامه اجرا می شود. همچنین آدرس قرارداد ذخیره سازی را نگه می دارد و برای دریافت و تنظیم داده ها با آن تعامل دارد.
+
+در همین حال، قرارداد ذخیره سازی وضعیت مرتبط با قرارداد هوشمند، مانند موجودی ها و آدرس های کاربر را حفظ می کند. توجه داشته باشید که قرارداد ذخیره سازی متعلق به قرارداد منطقی است و با آدرس دومی در هنگام استقرار پیکربندی شده است. این امر از تماس قراردادهای غیرمجاز با قرارداد ذخیره سازی یا به روز رسانی داده های آن جلوگیری می کند.
+
+بهطور پیشفرض، قرارداد ذخیرهسازی تغییر ناپذیر است، اما میتوانید قرارداد منطقی را که به آن اشاره میکند با یک پیادهسازی جدید جایگزین کنید. با این کار کدی که در EVM اجرا میشود، تغییر میکند، در حالی که فضای ذخیرهسازی و تعادل را دست نخورده نگه میدارد.
+
+استفاده از این روش ارتقا مستلزم بروز رسانی آدرس قرارداد منطقی در قرارداد ذخیره سازی است. همچنین به دلایلی که قبلا توضیح داده شد، باید قرارداد منطقی جدید را با آدرس قرارداد ذخیره سازی پیکربندی کنید.
+
+پیاده سازی الگوی جداسازی داده ها در مقایسه با انتقال قرارداد ساده تر است. با این حال، باید چندین قرارداد را مدیریت کنید و طرحهای مجوز پیچیده را برای محافظت از قراردادهای هوشمند در برابر ارتقاهای مخرب اجرا کنید.
+
+### مکانیسم ارتقاء شماره 3: الگوهای پراکسی {#proxy-patterns}
+
+الگوی پراکسی همچنین از جداسازی داده ها برای حفظ منطق تجاری و داده ها در قراردادهای جداگانه استفاده می کند. با این حال، در یک الگوی پراکسی، قرارداد ذخیرهسازی (به نام پراکسی) قرارداد منطقی را در طول اجرای کد فراخوانی می کند. این روش برعکس روش جداسازی داده است، که در آن قرارداد منطقی قرارداد ذخیره سازی را فرامیخواند.
+
+این چیزی است که در یک الگوی پراکسی اتفاق می افتد:
+
+1. کاربران با قرارداد پراکسی تعامل دارند، که دادهها را ذخیره میکند، اما منطق تجاری را حفظ نمیکند.
+
+2. قرارداد پراکسی آدرس قرارداد منطقی را ذخیره می کند و تمام فراخوانی های تابع را با استفاده از تابع `delegatecall` به قرارداد منطقی (که منطق تجاری را نگه می دارد) واگذار می کند.
+
+3. پس از ارسال فراخوانی به قرارداد منطقی، داده های برگشتی از قرارداد منطقی بازیابی شده و به کاربر بازگردانده می شود.
+
+استفاده از الگوهای پراکسی نیاز به درک عملکرد **delegatecall** دارد. اساساً، `delegatecall` یک کد عملیاتی است که به یک قرارداد اجازه میدهد قرارداد دیگری را فراخوانی کند، در حالی که اجرای کد واقعی در متن قرارداد فراخوانی اتفاق میافتد. مفهوم استفاده از `delegatecall` در الگوهای پراکسی این است که قرارداد پراکسی در حافظه خود می خواند و می نویسد و منطق ذخیره شده در قرارداد منطقی را اجرا می کند که گویی در حال فراخوانی یک تابع داخلی است.
+
+از [اسناد سالیدیتی](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries):
+
+> _نوع خاصی از تماس پیام وجود دارد، به نام **delegatecall** که با فراخوانی پیام یکسان است، صرف نظر از این که کد در آدرس مورد نظر در متن (یعنی در آدرس) اجرا می شود قرارداد فراخوانی و `msg.sender` و `msg.value` مقادیر خود را تغییر نمی دهند._ _این بدان معناست که یک قرارداد می تواند به صورت پویا کد را از آدرسی متفاوت در زمان اجرا بارگیری کند. محل ذخیره، آدرس فعلی و موجودی همچنان به قرارداد فراخوانی استناد میکنند، فقط کد از آدرس فراخوانی گرفته میشود._
+
+قرارداد پراکسی میداند که هر زمان که کاربر تابعی را فراخوانی میکند، `delegatecall` را فراخوانی میکند زیرا یک تابع `fallback` در آن تعبیه شده است. در برنامه نویسی سالیدیتی، [تابع fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) زمانی اجرا می شود که یک فراخوانی تابع با توابع مشخص شده در قرارداد مطابقت نداشته باشد.
+
+برای کارکرد الگوی پراکسی نیاز به نوشتن یک تابع بازگشتی سفارشی است که مشخص میکند قرارداد پراکسی چگونه باید فراخوانیهای تابعی را که پشتیبانی نمیکند مدیریت کند. در این مورد، تابع fallback پراکسی برای شروع یک فراخوانی واگذاری و تغییر مسیر درخواست کاربر به اجرای قرارداد منطقی فعلی برنامه ریزی شده است.
+
+قرارداد پراکسی به طور پیش فرض تغییر ناپذیر است، اما قراردادهای منطقی جدید با منطق تجاری به روز شده می توانند ایجاد شوند. در این صورت انجام ارتقاء به تغییر آدرس قرارداد منطقی اشاره شده در قرارداد پراکسی بستگی دارد.
+
+با اشاره قرارداد پراکسی به یک قرارداد منطقی جدید، کد اجرا شده هنگام فراخوانی تابع قرارداد پراکسی تغییر می کند. این به ما امکان میدهد تا منطق قرارداد را بدون درخواست از کاربران برای تعامل با یک قرارداد جدید ارتقا دهیم.
+
+الگوهای پراکسی روشی محبوب برای ارتقای قراردادهای هوشمند هستند زیرا مشکلات مربوط به انتقال قرارداد را از بین می برند. با این حال، استفاده از الگوهای پراکسی پیچیدهتر است و در صورت استفاده نادرست، میتواند نقصهای مهمی مانند [برخورد انتخابگر تابع](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) ایجاد کند.
+
+[اطلاعات بیشتر در مورد الگوهای پراکسی](https://blog.openzeppelin.com/proxy-patterns/).
+
+### مکانیسم ارتقاء شماره 4: الگوی استراتژی {#strategy-pattern}
+
+این تکنیک تحت تأثیر [الگوی استراتژی](https://en.wikipedia.org/wiki/Strategy_pattern) است، که ایجاد برنامههای نرمافزاری را تشویق میکند که با برنامههای دیگر برای پیادهسازی ویژگیهای خاص ارتباط برقرار کنند. اعمال الگوی استراتژی برای توسعه اتریوم به معنای ساخت یک قرارداد هوشمند است که توابع قراردادهای دیگر را فراخوانی می کند.
+
+قرارداد اصلی در این مورد حاوی منطق اصلی تجارت است، اما با سایر قراردادهای هوشمند ("قراردادهای ماهواره ای") برای اجرای عملکردهای خاص ارتباط برقرار می کند. این قرارداد اصلی همچنین آدرس هر قرارداد اقماری را ذخیره می کند و می تواند بین پیاده سازی های مختلف قرارداد اقماری جابجا شود.
+
+می توانید یک قرارداد اقماری جدید بسازید و قرارداد اصلی را با آدرس جدید پیکربندی کنید. این به شما امکان میدهد _استراتژیها_ (یعنی اجرای منطق جدید) را برای یک قرارداد هوشمند تغییر دهید.
+
+اگرچه شبیه به الگوی پراکسی که قبلاً مورد بحث قرار گرفت، الگوی استراتژی متفاوت است زیرا قرارداد اصلی که کاربران با آن تعامل دارند، منطق تجاری را حفظ می کند. استفاده از این الگو به شما این فرصت را می دهد که تغییرات محدودی را در یک قرارداد هوشمند بدون تأثیر بر زیرساخت اصلی ایجاد کنید.
+
+اشکال اصلی این است که این الگو بیشتر برای بهروزرسانیهای جزئی مفید است. همچنین، اگر قرارداد اصلی به خطر بیفتد (به عنوان مثال، از طریق هک)، نمی توانید از این روش ارتقا استفاده کنید.
+
+### مکانیسم ارتقاء شماره 5: الگوی الماس {#diamond-pattern}
+
+الگوی الماس را می توان بهبود در الگوی پروکسی در نظر گرفت. الگوهای الماس با الگوهای پراکسی متفاوت هستند زیرا قرارداد پروکسی الماس می تواند فراخوانی های تابع را به بیش از یک قرارداد منطقی واگذار کند.
+
+قراردادهای منطقی در الگوی الماس به عنوان _فاست_ شناخته می شوند. برای اینکه الگوی الماس کار کند، باید در قرارداد پراکسی یک نقشه برداری ایجاد کنید که [انتخابگرهای تابع](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) را به آدرسهای جنبههای مختلف نگاشت میکند.
+
+هنگامی که یک کاربر یک تابع را فراخوانی می کند، قرارداد پراکسی نگاشت را بررسی می کند تا فاست مسئول اجرای آن تابع را پیدا کند. سپس `delegatecall` را فراخوانی میکند (با استفاده از تابع fallback) و فراخوانی را به قرارداد منطقی مناسب هدایت میکند.
+
+الگوی ارتقاء الماس دارای مزایایی نسبت به الگوهای ارتقاء پراکسی سنتی است:
+
+1. این به شما امکان می دهد بخش کوچکی از قرارداد را بدون تغییر تمام کد ارتقا دهید. استفاده از الگوی پراکسی برای ارتقاء مستلزم ایجاد یک قرارداد منطقی کاملاً جدید است، حتی برای ارتقاهای جزئی.
+
+2. همه قراردادهای هوشمند (از جمله قراردادهای منطقی مورد استفاده در الگوهای پراکسی) دارای محدودیت اندازه 24 کیلوبایت هستند که می تواند یک محدودیت باشد – به خصوص برای قراردادهای پیچیده که به عملکردهای بیشتری نیاز دارند. الگوی الماس حل این مشکل را با تقسیم توابع در چندین قرارداد منطقی آسان می کند.
+
+3. الگوهای پراکسی یک رویکرد همه جانبه را برای کنترل های دسترسی اتخاذ می کنند. یک نهاد با دسترسی به توابع ارتقا میتواند قرارداد _کل_ را تغییر دهد. اما الگوی الماس یک رویکرد مجوزهای مدولار را فعال می کند، که در آن می توانید موجودیت ها را به ارتقاء عملکردهای خاص در یک قرارداد هوشمند محدود کنید.
+
+[اطلاعات بیشتر در مورد الگوی الماس](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
+
+## مزایا و معایب ارتقای قراردادهای هوشمند {#pros-and-cons-of-upgrading-smart-contracts}
+
+| نقاط مثبت | نقاط منفی |
+| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ارتقای قرارداد هوشمند میتواند رفع آسیبپذیریهای کشف شده در مرحله پس از استقرار را آسانتر کند. | ارتقای قراردادهای هوشمند، ایده تغییرناپذیری کد را که پیامدهایی برای تمرکززدایی و امنیت دارد، نفی میکند. |
+| توسعه دهندگان می توانند از ارتقاء منطقی برای افزودن ویژگی های جدید به برنامه های غیرمتمرکز استفاده کنند. | کاربران باید به توسعه دهندگان اعتماد کنند که قراردادهای هوشمند را خودسرانه تغییر ندهند. |
+| ارتقاء قراردادهای هوشمند می تواند ایمنی را برای کاربران نهایی بهبود بخشد زیرا باگ ها را می توان به سرعت برطرف کرد. | برنامه نویسی عملکرد ارتقاء به قراردادهای هوشمند لایه دیگری از پیچیدگی را اضافه می کند و احتمال نقص های مهم را افزایش می دهد. |
+| ارتقاء قرارداد به توسعه دهندگان فضای بیشتری برای آزمایش ویژگی های مختلف و بهبود دپ ها در طول زمان می دهد. | فرصت ارتقای قراردادهای هوشمند ممکن است توسعهدهندگان را تشویق کند پروژهها را سریعتر راهاندازی کنند بدون اینکه در مرحله توسعه دقت لازم را انجام دهند. |
+| | کنترل دسترسی ناامن یا متمرکز شدن در قراردادهای هوشمند میتواند بهروزرسانیهای غیرمجاز را برای عوامل مخرب آسانتر کند. |
+
+## ملاحظات ارتقای قراردادهای هوشمند {#considerations-for-upgrading-smart-contracts}
+
+1. برای جلوگیری از ارتقاء قراردادهای هوشمند غیرمجاز، به ویژه اگر از الگوهای پراکسی، الگوهای استراتژی یا جداسازی داده ها استفاده می شود، از مکانیسم های کنترل دسترسی/مجوز دسترسی ایمن استفاده کنید. یک مثال محدود کردن دسترسی به عملکرد ارتقاء است، طوری که فقط مالک قرارداد می تواند آن را فراخوانی کند.
+
+2. ارتقای قراردادهای هوشمند یک فعالیت پیچیده است و برای جلوگیری از معرفی آسیبپذیریها نیاز به دقت بالایی دارد.
+
+3. کاهش مفروضات اعتماد با تمرکززدایی از فرآیند اجرای ارتقاء. استراتژیهای احتمالی شامل استفاده از [قرارداد کیف پول چند امضایی](/developers/docs/smart-contracts/#multisig) برای کنترل ارتقاء، یا الزام [اعضای DAO](/dao/) برای رای دادن به تایید ارتقاء است.
+
+4. از هزینه های مربوط به ارتقاء قراردادها آگاه باشید. به عنوان مثال، کپی کردن حالت (به عنوان مثال، موجودی کاربر) از یک قرارداد قدیمی به یک قرارداد جدید در طول انتقال قرارداد ممکن است به بیش از یک تراکنش نیاز داشته باشد، به این معنی که کارمزدهای گس بیشتر است.
+
+5. برای محافظت از کاربران، **قفل های زمانی** را در نظر بگیرید. قفل زمانی به تاخیر اعمال شده در تغییرات یک سیستم اشاره دارد. قفلهای زمانی را میتوان با یک سیستم حاکمیت چند امضایی برای کنترل ارتقاها ترکیب کرد: اگر یک اقدام پیشنهادی به آستانه تأیید لازم برسد، تا زمانی که دوره تاخیر از پیش تعریفشده سپری نشود، اجرا نمیشود.
+
+قفلهای زمانی به کاربران در صورت مخالفت با تغییر پیشنهادی (مثلاً ارتقاء منطقی یا طرحهای هزینه جدید) مدتی زمان میدهند تا از سیستم خارج شوند. بدون قفل زمانی، کاربران باید به توسعه دهندگان اعتماد کنند تا بدون اطلاع قبلی تغییرات دلخواه را در یک قرارداد هوشمند اعمال نکنند. اشکال در اینجا این است که قفل های زمانی توانایی اصلاح سریع آسیب پذیری ها را محدود می کنند.
+
+## منابع {#resources}
+
+**پلاگین های ارتقاء OpenZeppelin - _مجموعه ای از ابزارها برای استقرار و ایمنسازی قراردادهای هوشمند قابل ارتقا._**
+
+- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-upgrades)
+- [اسناد](https://docs.openzeppelin.com/upgrades)
+
+## آموزشها {#tutorials}
+
+- [به روز رسانی قراردادهای هوشمند | آموزش یوتیوب](https://www.youtube.com/watch?v=bdXJmWajZRY) از پاتریک کالینز
+- [آموزش انتقال قرارداد هوشمند اتریوم](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) توسط آستین گریفیث
+- [استفاده از الگوی پراکسی UUPS برای ارتقاء قراردادهای هوشمند](https://blog.logrocket.com/author/praneshas/) از Pranesh A.S
+- [آموزش Web3: نوشتن قرارداد هوشمند قابل ارتقا (پراکسی) با استفاده از OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) از fangjun.eth
+
+## بیشتر بخوانید {#further-reading}
+
+- [حالت ارتقاهای قرارداد هوشمند](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) از سانتیاگو پالادینو
+- [روش های متعدد برای ارتقاء قرارداد هوشمند سالیدیتی](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - وبلاگ Crypto Market Pool
+- [بیاموزید: ارتقای قراردادهای هوشمند](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - در اسناد OpenZeppelin
+- [الگوهای پراکسی برای ارتقای قراردادهای سالیدیتی: شفاف در مقابل پروکسی های UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) از نوین ساهو
+- [ ارتقاء الماس چگونه کار می کند](https://dev.to/mudgen/how-diamond-upgrades-work-417j) از نیک ماج
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md
new file mode 100644
index 00000000000..b88037cb5e7
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md
@@ -0,0 +1,119 @@
+---
+title: تأیید کردن قراردادهای هوشمند
+description: نگاهی بر تائید کردن کد قراردادهای هوشمند اتریوم
+lang: fa
+---
+
+[قراردادهای هوشمند](/developers/docs/smart-contracts/) به گونه ای طراحی شده اند که بی نیاز از اطمینان باشند، به این معنی که کاربرها پیش از برقراری ارتباط با یک کانترکت، نیازی نباشد به شخص یا اشخاص سوم شخص(خواه توسعه دهنده و خواه شرکت ها) اعتماد کنند. به عنوان یکی از نیازمندی های بی نیازی از اعتماد، کاربران و همینطور سایر توسعه دهنده باید بتوانند به راحتی به کدهای قراردادهای هوشمند دسترسی داشته باشند تا عملکرد آنها را بررسی و تائید کنند. وریفای یا تائید کد قرارداد هوشمند، این اطمینان خاطر را به کاربران و توسعه دهندگان میدهد که کد منتشر شده از قرارداد هوشمند، دقیقاً همان کدی است که در آدرس آن قرارداد بر بستر بلاکچین اتریوم وجود دارد.
+
+نکته مهمی که وجود دارد این است که باید بین تائید کردن کد و [تائید رسمی](/developers/docs/smart-contracts/formal-verification/) تمایز قائل شد. تائید کردن کد، که در ادامه به تفصیل آن را شرح خواهیم داد، به عملیاتی اطلاق میشود که کدهای یک قرارداد هوشمند در یک زبان سطح بالا (مثل سالیدیتی) دقیقاً به همان بایت کد اجرایی قرارداد هوشمند کامپایل شود. ولی تائید رسمی به توضیح صحیح بودن قرارداد هوشمند مطابق با عملکرد مورد انتظار میپردازد. اگرچه در مفاهیمی که در حال صحبت از آن هستیم، وریفای یا تائید کردن قرارداد عموماً به تائید کدها اطلاق میشود.
+
+## تائید کد چیست؟ {#what-is-source-code-verification}
+
+پیش از دیپلوی یک قرارداد هوشمند در [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)، توسعه دهنده ها کد قرارداد-دستورالعملهای [نوشته شده به زبان سالیدیتی](/developers/docs/smart-contracts/compiling/) یا سایر زبان های سطح بالا- را به بایت کد [کامپایل](/developers/docs/smart-contracts/languages/) می کنند. از آنجایی که EVM توانایی تفسیر دستورات سطح بالا را ندارد، به منظور اجرای منطق قرارداد بر روی EVM، کامپایل کردن کدها به بایت کد(دستورات سطح پایین و قابل درک برای ماشین) ضروری است.
+
+تائید کردن کد به معنای مقایسه ی کد قرارداد هوشمند و بایت کد کامپایل شده ای که در زمان ساخته شدن قرارداد استفاده میشود، و به منظور شناسایی هرگونه تفاوت می باشد. تائید کردن قرارداد هوشمند از این جهت حائز اهمیت است که کد قرارداد تبلیغ شده، ممکن است با آنچه که در حال اجرا بر روی بلاکچین است متفاوت باشد.
+
+تائید قرارداد هوشمند امکان بررسی و تحقیق کاری که قرارداد انجام می دهد را از طریق خواندن کدهای سطح بالا و بدون نیاز به خواندن کدهای ماشین فراهم می سازد. توابع، مقادیر، و عموماً اسامی متغیرها و کامنت ها عیناً مطابق کد اصلی ای هستند که قرارداد با آنها کامپایل و دیپلوی شده است. این موضوع، خواندن کد را بسیار راحت تر می کند. تائید کد، همچنین مستندات کد را فراهم آوری می کند و باعث میشود تا کاربران نهایی بتوانند متوجه شوند که قرارداد هوشمند مربوطه برای چه کاری طراحی شده است.
+
+### تائید کامل چیست؟ {#full-verification}
+
+بخش هایی از قرارداد هوشمند، از جمله کامنت ها یا اسامی متغیرها بر روی بایت کدهای کامپایل شده تاثیری ندارند. این موضوع بدین معناست که دو کد مختلف، با اسامی متغیر و همینطور کامنت های متفاوت، می توانند توسط یک قرارداد یکسان تائید شوند. با استفاده از این مسئله، یک کاربر بداندیش، می تواند با افزودن کامنت های فریبنده و یا نام گذاری گمراه کننده نام متغیرها در کد، کدی متفاوت از کد اصلی را تائید کند.
+
+به منظور جلوگیری از این اتفاق، می توان با افزودن یک داده اضافه به بایت کد که در حکم یک _تضمین رمزنگاری_ و به عنوان _ اثر انگشت_ عملیات کامپایل برای همسان بودن کد می باشد اقدام نمود. اطلاعات ضروری در [داده های متای قرارداد سالیدیتی](https://docs.soliditylang.org/en/v0.8.15/metadata.html) قابل دستیابی است، همچنین هش این فایل نیز به بایت کد قرارداد الحاق میشود. این مورد را می توانید به طور عملیاتی در [فضای بازی داده های متا](https://playground.sourcify.dev) مشاهده کنید
+
+فایل داده های متا یا متادیتا، حاوی اطلاعاتی در خصوص کامپایل شدن قرارداد هوشمند و شامل کدها و هش آنها می باشد. این بدین معناست که در صورت رخ دادن کوچکترین تغییری در تنظیمات کامپایل و یا حتی تغییر در یک بایت از کدها، فایل متادیتا تغییر خواهد کرد. همچنین متعاقباً، هش فایل متادیتا که به بایت کد الحاق شده است نیز تغییر خواهد کرد. این بدین معناست که اگر بایت کد یک قرارداد + هش متادیتای الحاص شده به آن، با کد داده شده و تنظیمات کامپایل یکسان باشد، می توانیم کاملاً مطمئن باشیم که حتی یک بایت نیز تغییری نکرده و این کد، کد اصلی کامپایل شده می باشد.
+
+به این نوع از تائید که از هش متادیتا بهره می برد، اصطلاحاً **[تائید کامل](https://docs.sourcify.dev/docs/full-vs-partial-match/)** (همچنین "تائید بی نقص") گفته می شود. اگر هش های متادیتا یکسان نبوده و یا به عنوان تائید شده نباشند، به آن "تطابق جزئی" گفته می شود، که در حال حاضر رایج ترین شیوه در تائید قراردادهاست. در صورتی که عملیات تائید کردن به صورت کامل نباشد، این امکان وجود دارد که [کد مخربی به قرارداد وارد شود](https://samczsun.com/hiding-in-plain-sight/) که در کد تائید شده قابل مشاهده نباشد. بیشتر توسعه دهنده ها از وجود تائیدیه کامل بی اطلاع اند و فایل متادیتای کامپایل خود را نگهداری نمی کنند، از این رو، عملاً تاکنون تائید جزئی به عنوان روش تائید قراردادها مورد استفاده قرار میگیرد.
+
+## چرا تائید کد مهم است؟ {#importance-of-source-code-verification}
+
+### بی نیازی از اعتماد {#trustlessness}
+
+بدون شک، بی نیازی از اعتماد یکی از بزرگترین وعده های قراردادهای هوشمند و [اپلیکیشن های غیرمتمرکز(dappها)](/developers/docs/dapps/) است. قراردادهای هوشمند "تغییر ناپذیر" بوده و امکان عوض کردن ندارند؛ یک قرارداد، تنها مسئول اجرای منطق کاری است که در زمان دیپلوی شدن، در کدش تعریف شده است. این موضوع به این معناست که توسعه دهندهها و شرکتها(و البته قابل بسط به سایر افراد نیز می باشد)، پس از دیپلوی(استقرار) بر روی شبکه اتریوم، نمیتوانند تغییری در کد قرارداد ایجاد کنند.
+
+به منظور بی نیاز بودن از اعتماد در یک قرارداد هوشمند، کد قرارداد باید جهت تائید شدن به صورت مستقل، قابل دسترس باشد. اگرچه بایتکد کامپایل شده ی قراردادهای هوشمند بهصورت عمومی بر روی بلاکچین قابل دسترسی است، اما درک زبان سطح پایین، هم برای توسعه دهنده ها و هم کاربران عادی سخت است.
+
+به منظور کاهش گمانه زنی ها در خصوص اعتمادپذیری، پروژه ها کد قراردادهای خود را منتشر می کنند. اما همین موضوع، باعث ایجاد یک مشکل دیگر می شود: تائید همسان بودن کد منتشر شده با بایت کدهای قرارداد مربوطه، سخت است. در این سناریو، بدلیل اینکه کاربران باید به توسعه دهنده اعتماد کنند که منطق کاری قرارداد (با تغییر دادن بایتکد) را پیش از دیپلوی بر روی بلاکچین تغییر نمیدهد، ارزش بی نیازی از اعتماد، در عمل از بین می رود.
+
+ابزارهای تائید کد، ضمانت می کنند که کد قرارداد هوشمند دقیقاً منطبق بر کد اسمبلی آن قرارداد باشد. نتیجه این امر، پدید آمدن یک اکوسیستم بی نیاز از اعتماد است، جایی که کاربران، چشم و گوش بسته به افراد یا نهادهای سوم شخص اعتماد نکرده و به جای آن، پیش از انجام هرگونه واریز دارایی به یک قرارداد، کدهای آن قرارداد را تائید می کنند.
+
+### امنیت کاربر {#user-safety}
+
+معمولاً هر جا که قراردادهای هوشمند باشند، پول زیادی نیز سپرده گذاری شده است. به همین خاطر پیش از استفاده از قراردادهای هوشمند، نیاز بیشتری به تضمین امنیت و تائید بودن منطق آن قرارداد بوجود می آید. مشکلی که در اینجا وجود دارد این است که توسعه دهنده های بی اخلاق و شرور، می توانند کاربران را با وارد کردن کدهای مخرب به قرارداد هوشمند، فریب دهند. بدون انجام تائیدیه، قراردادهای هوشمند مخرب میتوانند شامل کدهای مخربی از جمله: [در پشتی](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)، مکانیزمهای کنترل دسترسی ناجور، آسیبپذیریهای قابل سوء استفاده، و سایر مخاطراتی که امنیت کاربر را به خطر می اندازند بوده که این کدها قابل شناسایی نباشند.
+
+انتشار فایل کدهای قرارداد هوشمند، دسترسی به نواحی ای از قرارداد که پتانسیل مورد حمله واقع شدن را دارند را برای علاقه مندانی مثل حسابرسان کد تسهیل می کند. وجود اشخاص مستقل از هم که عملیات تائید قرارداد هوشمند را انجام دهند، تضمینی قوی تر برای امنیت کاربران به حساب می آید.
+
+## نحوه تائید کد قراردادهای هوشمند اتریومی {#source-code-verification-for-ethereum-smart-contracts}
+
+[استقرار قرارداد هوشمند بر روی اتریوم](/developers/docs/smart-contracts/deploying/) نیازمند ارسال یک تراکنش با پی لود حاوی داده(بایت کد کامپایل شده) به یک آدرس خاص است. پی لود داده، با کامپایل شدن کد قرارداد، به علاوه ی [آرگومانهای کانستراکتور](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) قرارداد که به پی لود داده در تراکنش الحاق شده است ساخته می شود. عملیات کامپایل قطعی است، به این معنا که اگر فایل کدها و تنظیمات کامپایل(از جمله نسخه کامپایلر، اپتیمایز، و ...) یکسان باشند، همیشه یک خروجی یکسان(بایتکد قرارداد) ایجاد خواهد شد.
+
+![دیاگرامی که نمایش دهنده کد وریفای شده قرارداد هوشمند میباشد](./source-code-verification.png)
+
+وریفای کردن یک قرارداد هوشمند اساساً شامل مراحل زیر می باشد:
+
+1. وارد کردن فایل کدها و تنظیمات کامپایل به یک کامپایلر.
+
+2. کامپایلر، بایتکد قرارداد را به عنوان خروجی بر میگرداند
+
+3. بایتکد قرارداد دیپلوی شده در یک آدرس مشخص شده قابل دستیابی است
+
+4. بایتکد دیپلوی شده با بایتکد حاصله از دیپلوی مجدد مقایسه می شود. در صورت تصاطبق کدها، قرارداد با کد داده شده و تنظیمات کامپایل مشخص شده تائید و وریفای می شود.
+
+5. علاوه بر این، در صورتی که هش داده های اضافی یا همان متا دیتای در انتهای بایتکد، منطبق باشند، یک تطابق کامل خواهیم داشت.
+
+توجه داشته باشید که در اینجا توضیح ساده ای از تائید کردن را به میان آورده ایم، و در این پروسه استثناهای بسیاری وجود دارند که ممکن است توضیحات متفاوتی با آنچه که در حال صحبت در اینجا هستیم داشته باشند، مثلاً در زمانی که
+
+متغیرهای از نوع immutable" داشته باشیم.
+
+
+
+## ابزارهای وریفای کد {#source-code-verification-tools}
+
+پروسه مرسوم وریفای کردن قراردادها می توانند پیچیده باشند. به همین علت است که ابزارهایی برای وریفای کد قراردادهای هوشمند مستفر شده بر روی اتریوم داریم. این ابزارها بهطور اتوماتیک بخش های بزرگی از کد را تائید و وریفای کرده و همچنین می توانند کدهای وریفای شده را برای انتفاع کاربرها گلچین کنند.
+
+
+
+### Etherscan {#etherscan}
+
+اگرچه اکثراً آنرا به عنوان [مرورگر بلاکچین اتریوم](/developers/docs/data-and-analytics/block-explorers/) می شناسند، اتراسکن همچنین [سرویس تائید کد](https://etherscan.io/verifyContract) برای توسعه دهندههای قراردادهای هوشمند و کاربران عادی را ارائه می دهد.
+
+اتراسکن اجازه کامپایل مجدد بایتکد قرارداد از پی لود داده اصلی (کد، آدرس کتابخانه، تنظیمات کامپایلر، آدرس قرارداد، و ...) را به شما می دهد در صورتی که بایتکد مجدد کامپایل شده، با بایتکد (و پارامترهای کانستراکتور) قراردادی بر روی بلاکچین (آن-چین) منطبق باشد، سپس [قرارداد وریفای می شود](https://info.etherscan.com/types-of-contract-verification/).
+
+هنگامی که قرارداد وریفای شود، کد قرارداد شما برچسب "verified" دریافت کرده و به منظور حسابرسی و آدیت شدن سایرین، بر روی اتراسکن منتشر می شود. همچنین به قسمت قراردادهای وریفای شده0> یا همان verified contracts -که مخزنی از قراردادهای هوشمند با کدهای وریفای شده است- اضافه می شود.
+
+اتر اسکن، پر استفاده ترین ابزار وریفای و تائید قراردادهای هوشمند است. هرچند، سرویس وریفای قراردادهای اتراسکن نواقصی نیز دارد: از جمله این نواقص می توان به ناتوانی در مقایسه **هش متادیتا**ی بایتکد آن-چین و بایتکد مجدد کامپایل شده اشاره کرد. بنابراین می توان گفت که تطابقهای اتراسکن از نوع تطابق جزئی است.
+
+[مطالب بیشتر در خصوص وریفای قراردادهای هوشمند در اتراسکن](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
+
+
+
+### Sourcify {#sourcify}
+
+ابزار دیگری که متن باز و غیرمتمرکز بوده و برای وریفای قراردادهای هوشمند به کار میرود، [Sourcify](https://sourcify.dev/#/verifier) میباشد. این ابزار، مرورگر بلاک ها نیست و فقط قراردادها را بر روی [انواع شبکه های منطبق بر ماشین مجازی اتریوم](https://docs.sourcify.dev/docs/chains) وریفای می کند. این ابزار به عنوان یک زیرساخت عمومی برای سایر ابزارها عمل می کند، و هدفش این است که ارتباط گیری با قراردادهای هوشمند را با استفاده از [ABI](/developers/docs/smart-contracts/compiling/#web-applications) و کامنتهای از نوع [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) که در فایل متادیتا یافت می شود، کاربر پسند تر کند.
+
+بر خلاف اتراسکن، Sourcify از تطابق کامل با هش متادیتا پشتیبانی می کند. قراردادهای تائید شده، در [مخزن عمومی](https://docs.sourcify.dev/docs/repository/) یا HTTP و [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) که یک فضای ذخیرهسازی غیر متمرکز [مبتنی بر آدرس](https://web3.storage/docs/concepts/content-addressing/) است قرار میگیرند. از آنجایی که هش متادیتای الحاق شده، یک هش IPFS است، این امر اجازه ی واکشی فایل متادیتای یک قرارداد از بستر IPFS را فراهم میآورد.
+
+به علاوه، از آنجایی که هش IPFS این فایلها همچنین در متادیتا نیز یافت میشود، هر کسی این امکان را دارد که فایل کد را از طریق IPFS دریافت کند. با فراهمسازی فایل متادیتا و فایل کدها از طریق API و یا [رابط کاربری](https://sourcify.dev/#/verifier)، و یا استفاده از پلاگینهای آن، می توان قرارداد را وریفای کرد. همچنین ابزار مانیتورینگ و رصد Sourcify گوش به زنگ ساخته شدن قراردادها در بلوکهای جدید بوده و اگر متادیتا و فایل کد قراردادی در IPFS منتشر شده است، سعی میکند آنرا وریفای کند.
+
+[مطالب بیشتر در خصوص وریفای قراردادها بر روی Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/).
+
+
+
+### Tenderly {#tenderly}
+
+پلتفرم [Tenderly](https://tenderly.co/) به توسعهدهندههای وب3 قابلیت ساخت، تست، مانیتور کردن، و اجرای قراردادهای هوشمند را میدهد. تندرلی، با مجموعه ای از ابزارهای اشکالزدایی، با ابزارهای قابل مشاهده پذیری و زیرساخت ساخته شدن بلوکها، در مسیر توسعه قرارداد هوشمند، به توسعه دهنده ها سرعت میبخشد. به منظور بهرهمندی از تمامی امکانات تندرلی، توسعهدهندهها نیاز به [وریفای کردن کدقرارداد](https://docs.tenderly.co/monitoring/contract-verification) دارند.
+
+امکان وریفای عمومی یا خصوصی یک قرارداد وجود دارد. در صورت وریفای بهصورت خصوصی، قرارداد هوشمند فقط برای شما (و افراد تیم پروژهی شما) قابل مشاهده است. وریفای کردن عمومی قرارداد، آنرا برای تمامی کاربران پلتفرم تندرلی قرار میدهد.
+
+شما می توانید با استفاده از [داشبورد کاربری](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract)، [پلاگین هاردهت تندرلی](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin)، و یا [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) قراردادهای خود را وریفای کنید.
+
+در صورتی که قرارداد خود را از طریق داشبورد کاربری وریفای کنید نیاز دارید که فایل کد یا فایل متادیتای ساخته شده توسط کامپایلر سالیدیتی، آدرس/شبکه، و تنظیمات کامپایلر را ایمپورت کنید.
+
+با استفاده از پلاگین هاردهت تندرلی، می توانید دسترسی های بیشتر با سختی کمتری در خلال پروسه وریفای کردن داشته باشید، و این باعث فعالسازی امکان انتخاب وریفای بین روش اتوماتیک (بدون کد) و دستی (نیازمند کدنویسی) میشود.
+
+
+
+## بیشتر بخوانید {#further-reading}
+
+- [وریفای کردن کد منبع قرارداد](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/fa/developers/docs/standards/index.md b/public/content/translations/fa/developers/docs/standards/index.md
new file mode 100644
index 00000000000..8e2c02ef379
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/index.md
@@ -0,0 +1,59 @@
+---
+title: استانداردهای توسعه اتریوم
+description:
+lang: fa
+incomplete: true
+---
+
+## مروری بر استانداردها {#standards-overview}
+
+جامعه اتریوم استانداردهای زیادی را اتخاذ کرده است تا کمک کند پروژه ها (همچون [کلاینت های اتریوم](/developers/docs/nodes-and-clients/) و کیف پول های دیجیتالی) در هنگام پیاده سازی، قابلیت اجرا داشته باشند و همچنین اطمینان حاصل می کند تا قراردادهای هوشمند و dapp ها هچنان ترکیب پذیر باقی بمانند.
+
+استانداردها عموما به صورت [پیشنهادات بهبود اتریوم](/eips/) (EIPها) معرفی می گردند که توسط اعضای جامعه از طریق یک [فرآیند استاندارد](https://eips.ethereum.org/EIPS/eip-1) مورد بحث قرار می گیرند.
+
+- [مقدمه ای بر EIPها](/eips/)
+- [لیست EIPها](https://eips.ethereum.org/)
+- [مخزن گیتهاب EIP](https://github.com/ethereum/EIPs)
+- [صفحه گفتگوی EIP](https://ethereum-magicians.org/c/eips)
+- [مقدمهای بر حاکمیت اتریوم](/governance/)
+- [مروری بر حاکمیت اتریوم](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _March 31, 2019 - Boris Mann_
+- [هماهنگسازی پروتکل توسعه پروتکل و ارتقا شبکه](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 مارس 2020 - هودسون جیمزسون_
+- [فهرست پخش تمامی جلسات توسعه هسته اتریوم](https://www.youtube.com/@EthereumProtocol) _(فهرست پخش در یوتیوب)_
+
+## انواع استانداردها {#types-of-standards}
+
+3 نوع EIP وجود دارد:
+
+- مسیر استانداردها: هر تغییری را توصیف میکند که بر اکثر یا همه نسخه های اتریوم تأثیر میگذارد
+- [مسیر ابرداده ها (Meta)](https://eips.ethereum.org/meta): پروسه های حول محور اتریوم را توصیف می کند یا تغییری را در یک پروسه پیشنهاد میکند
+- [مسیر اطلاعات](https://eips.ethereum.org/informational): یک مشکل طراحی اتریوم را شرح میدهد یا دستورالعملها یا اطلاعات کلی را در اختیار جامعه اتریوم قرار میدهد
+
+علاوه بر این، مسیر استانداردها به 4 دسته تقسیم میشود:
+
+- [هسته](https://eips.ethereum.org/core): بهبودهایی که نیاز به فورک اجماع دارند
+- [شبکهسازی](https://eips.ethereum.org/networking): بهبودهای حول محور devp2p و پروتکل های فرعی اتریوم رقیق و همچنین بهبودهای پیشنهادی برای مشخصات پروتکل شبکه whisper و swarm است.
+- [رابط](https://eips.ethereum.org/interface): بهبودهایی در مورد مشخصات و استانداردهای API/RPC کلاینت و استانداردهای خاص در سطح زبان مانند نام روشها و قراردادهای ABI است.
+- [ERC](https://eips.ethereum.org/erc): استانداردها و کنوانسیونهای سطح برنامه
+
+اطلاعات دقیقتر در مورد انواع و دستههای مختلف را میتوانید در [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) پیدا کنید
+
+### استانداردهای توکن {#token-standards}
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - یک رابط استاندارد برای توکنهای تعویضپذیر (قابل تعویض)، مانند توکنهای رایگیری، توکنهای شرطبندی یا ارزهای مجازی می باشد.
+ - [ERC-223](/developers/docs/standards/tokens/erc-223/) - نوعی استاندارد توکن تعویض پذیر است که رفتاری مشابه اتر دارد و از انتقال توکن هایی که در سمت گیرنده مدیریت می شوند، پشتیبانی می کند.
+ - [ERC-1363](https://eips.ethereum.org/EIPS/eip-1363) - یک رابط برقراری ارتباط با توکن، برای توکنهای ERC-20 توصیف میکند که از اجرای کد گیرنده پس از اجرای انتقال یا «انتقال از» و یا اجرای کد ارسال کننده پس از تایید، پشتیبانی میکند.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - یک رابط استاندارد برای توکنهای تعویض ناپذیر، مانند یک سند برای اثر هنری یا یک آهنگ است.
+ - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - یک رویداد استاندارد شده که هنگام ساخت یا انتقال یک یا چندین توکن تعویض ناپذیر، با استفاده از IDهای متوالی، اجرا و اطلاع رسانی میشود.
+ - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - افزونهای برای نقش مصرف کننده در رابط EIP-721.
+ - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - یک نقش دارای محدودیتهای دسترسی و زمانی را به توکنهای ERC-721 اضافه میکند.
+- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(توصیه نمیشود)** یک استاندارد توکن برای بهبود ERC-20.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - یک استاندارد توکنی است که میتواند دارای داراییهای تعویض پذیر و تعویض ناپذیر باشد.
+- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - یک استاندارد خزانه توکنیزه شده که برای بهینهسازی و یکسانسازی پارامترهای فنی خزانه های سودده طراحی شده است.
+
+درباره [استانداردهای توکن](/developers/docs/standards/tokens/) بیشتر بدانید.
+
+## بیشتر بخوانید {#further-reading}
+
+- [پیشنهادهای بهبود اتریوم (EIP)](/eips/)
+
+_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-1155/index.md
new file mode 100644
index 00000000000..54a9d121fc9
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-1155/index.md
@@ -0,0 +1,146 @@
+---
+title: استاندارد چند توکنی ERC-1155
+description:
+lang: fa
+---
+
+## معرفی {#introduction}
+
+یک رابط استاندارد برای قراردادهایی است که چندین نوع توکن را مدیریت می کنند. یک تک قرارداد هوشمند مستقر ممکن است شامل هر ترکیبی از توکنهای تعویض پذیر، توکنهای تعویض ناپذیر یا سایر پیکربندیها (مانند توکنهای نیمه تعویض پذیر) باشد.
+
+**منظور از استاندارد چند توکنی چیست؟**
+
+این ایده ساده است و به دنبال ایجاد یک رابط برنامه نویسی قرارداد هوشمند میباشد که می تواند هر تعداد توکن تعویض پذیر و تعویض ناپذیر را نشان دهد و کنترل کند. به این ترتیب، توکن ERC-1155 می تواند همان عملکردهای یک توکن [ERC-20](/developers/docs/standards/tokens/erc-20/) و [ERC-721](/developers/docs/standards/tokens/erc-721/) و حتی هر دو را به طور همزمان انجام دهد. این امر باعث بهبود عملکرد و کارآیی هر دو استاندارد ERC-20 و ERC-721 میشود و خطاهای واضح پیادهسازی را اصلاح میکند.
+
+توکن ERC-1155 به طور کامل در [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) توضیح داده شده است.
+
+## پیش نیاز ها {#prerequisites}
+
+برای درک بهتر این صفحه، توصیه می کنیم ابتدا در مورد [استانداردهای توکن](/developers/docs/standards/tokens/)، [ERC-20](/developers/docs/standards/tokens/erc-20/) و [ERC-721](/developers/docs/standards/tokens/erc-721/) مطالعه کنید.
+
+## توابع و ویژگی های ERC-1155: {#body}
+
+- [انتقال دستهای](#batch_transfers): چندین دارایی را در یک فراخوانی منتقل کنید.
+- [تراز دسته ای](#batch_balance): موجودی چندین دارایی را در یک فراخوانی دریافت کنید.
+- [تأیید دستهای](#batch_approval): همه توکن ها را برای یک آدرس تأیید کنید.
+- [قلابها](#receive_hook): قلاب توکنها را دریافت کنید.
+- [پشتیبانی NFT](#nft_support): اگر عرضه تنها ۱ باشد، با آن به عنوان NFT رفتار کنید.
+- [قوانین انتقال ایمن](#safe_transfer_rule): مجموعه قوانین برای انتقال ایمن.
+
+### انتقال دسته ای {#batch-transfers}
+
+عملیات انتقال دسته ای بسیار شبیه به انتقال معمولی ERC-20 است. بیایید نگاهی به تابع `transferFrom` استاندارد ERC-20 بیاندازیم:
+
+```solidity
+// ERC-20
+function transferFrom(address from, address to, uint256 value) external returns (bool);
+
+// ERC-1155
+function safeBatchTransferFrom(
+ address _from,
+ address _to,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external;
+```
+
+تنها تفاوت ERC-1155 در این است که مقادیر را به عنوان یک آرایه ارسال می کنیم و همچنین یک آرایه از id را نیز ارسال می کنیم. به عنوان مثال با توجه به `ids=[3, 6, 13]` و `values=[100, 200, 5]`، انتقالهای حاصل به صورت زیر می باشد
+
+1. 100 توکن با شناسه 3 را از `from_` به `to_` منتقل کنید.
+2. 200 توکن با شناسه 6 را از `from_` به `to_` منتقل کنید.
+3. 5 توکن با شناسه 13 را از `from_` به `to_` منتقل کنید.
+
+در ERC-1155 تنها تابع `transferFrom` را داریم و تابع `transfer` نداریم. برای استفاده از آن مانند یک `انتقال` معمولی، کافی است آدرس from را به آدرسی که تابع را فراخوانی میکند، تنظیم کنید.
+
+### موجودی دسته ای {#batch-balance}
+
+فراخوانی مربوط به ERC-20 `balanceOf` نیز به همین ترتیب تابع شریک خود را با پشتیبانی دسته ای دارد. به عنوان یک یادآوری، این نسخه ERC-20 است:
+
+```solidity
+// ERC-20
+function balanceOf(address owner) external view returns (uint256);
+
+// ERC-1155
+function balanceOfBatch(
+ address[] calldata _owners,
+ uint256[] calldata _ids
+) external view returns (uint256[] memory);
+```
+
+حتی سادهتر از فراخوانی موجودی، میتوانیم چندین موجودی را در یک فراخوانی بدست آوریم. آرایه از دارندگان حساب و به دنبال آن آرایه ای از شناسه های توکن را ارسال می کنیم.
+
+به عنوان مثال، با توجه به `_ids=[3, 6, 13]` و `_owners=[0xbeef..., 0x1337..., 0x1111...]`، مقدار بازگشتی برابر خواهد شد با
+
+```solidity
+[
+ balanceOf(0xbeef...),
+ balanceOf(0x1337...),
+ balanceOf(0x1111...)
+]
+```
+
+### تایید دسته ای {#batch-approval}
+
+```solidity
+// ERC-1155
+function setApprovalForAll(
+ address _operator,
+ bool _approved
+) external;
+
+function isApprovedForAll(
+ address _owner,
+ address _operator
+) external view returns (bool);
+```
+
+تاییدیه ها کمی با ERC-20 تفاوت دارند. به جای تأیید مبالغ خاص، یک اپراتور را از طریق `setApprovalForAll` روی تایید یا تایید نشده تنظیم می کنیم.
+
+خواندن وضعیت فعلی را می توان از طریق `isApprovedForAll` انجام داد. همانطور که مشاهده میکنید، این یک پاسخ صفر و یک است. شما نمی توانید تعیین کنید که چه تعداد توکن باید تایید شود یا حتی کدام کلاس توکن باید تایید شود.
+
+این مقوله عمدا با در نظر گرفتن سادگی طراحی شده است. شما فقط می توانید همه چیز را برای یک آدرس تایید کنید.
+
+### قلاب دریافت {#receive-hook}
+
+```solidity
+function onERC1155BatchReceived(
+ address _operator,
+ address _from,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external returns(bytes4);
+```
+
+با توجه به پشتیبانی [EIP-165](https://eips.ethereum.org/EIPS/eip-165)، پشتیبانی ERC-1155 تنها از قلابهای دریافت برای قرارداد هوشمند پشتیبانی میکند. تابع قلاب می بایست مقدار bytes4 از پیش تعریف شده جادویی را برگرداند که به صورت زیر داده می شود:
+
+```solidity
+bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
+```
+
+وقتی قرارداد دریافتکننده این مقدار را برمیگرداند، فرض بر این است که قرارداد انتقال را میپذیرد و میداند چگونه با توکنهای ERC-1155 کار کند. عالی است، دیگر هیچ توکنی در یک قرارداد گیر نمیکند!
+
+### پشتیبانی از NFT {#nft-support}
+
+وقتی عرضه فقط یک باشد، توکن اساساً یک توکن تعویض ناپذیر (NFT) است. و همانطور که برای ERC-721 استاندارد است، میتوانید یک URL اَبَرداده ای را تعریف کنید. URL را می توان توسط کلاینت ها خواند و تغییر داد، [اینجا](https://eips.ethereum.org/EIPS/eip-1155#metadata) را ببینید.
+
+### قانون انتقال ایمن {#safe-transfer-rule}
+
+ما قبلاً در توضیحات قبلی به چند قانون انتقال ایمن اشاره کردیم. اما بیایید مهم ترین قوانین را بررسی کنیم:
+
+1. تماسگیرنده می بایست برای خرج کردن توکن ها برای آدرس `from_` تأیید شود یا تماسگیرنده باید برابر با `from_` باشد.
+2. فراخوانی انتقال باید برگردانده شود اگر
+ 1. آدرس `to_` باشد.
+ 2. طول `_ids` با طول `_values` یکسان نباشد.
+ 3. هر یک از موجودی(های) دارنده(های) توکن(ها) در `_ids` کمتر از مقدار(های) مربوطه در `_values` ارسال شده به گیرنده باشد.
+ 4. هر خطای دیگری رخ دهد.
+
+_توجه_: همه توابع دستهای از جمله قلاب در نسخههای بدون دسته نیز وجود دارند. با توجه به اینکه انتقال تنها یک دارایی احتمالاً همچنان رایج ترین راه مورد استفاده خواهد بود، این کار به منظور بهره وری گاز انجام می شود. ما همگی آنها، از جمله قوانین انتقال ایمن را به خاطر سادگی در توضیحات کنار گذاشتیم. نام ها یکسان هستند، فقط "دسته ای" را حذف کنید.
+
+## بیشتر بخوانید {#further-reading}
+
+- [EIP-1155: استاندارد چند توکنی](https://eips.ethereum.org/EIPS/eip-1155)
+- [ERC-1155: مستندات Openzeppelin](https://docs.openzeppelin.com/contracts/3.x/erc1155)
+- [ERC-1155: در Repo گیت هاب](https://github.com/enjin/erc-1155)
+- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-20/index.md
new file mode 100644
index 00000000000..d8e06f7dc6a
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-20/index.md
@@ -0,0 +1,172 @@
+---
+title: استاندارد توکن ERC-20
+description:
+lang: fa
+---
+
+## معرفی {#introduction}
+
+**توکن چیست؟**
+
+توکن ها میتوانند هرچیزی را بصورت مجازی در اتریوم ارائه دهند:
+
+- امتیاز شهرت در یک پلتفرم آنلاین
+- مهارت های یک کاراکتر در یک بازی
+- دارایی های اقتصادی مانند سهام یک شرکت
+- یک ارز فیات مانند دلار
+- یک اونس طلا
+- و موارد دیگر...
+
+این نوع ویژگی قدرتمند اتریوم باید با یک استاندارد قوی اداره شود، اینطور نیست؟ این دقیقا همان جایی است که ERC-20 نقش خودش را اجرا میکند! این استانداردها به توسعه دهندگان این امکان را می دهد تا توکن اپلیکیشن هایی که با سایر محصولات و خدمات سازگار هستند را بسازند. همچنین این استاندارد عملکرد اضافهتری را برای اتر (واحد ارز داخلی اتریم یا ETH) فراهم میکند.
+
+**ERC-20 چیست؟**
+
+ERC-20 استانداردی را برای توکنهای تعویض پذیر معرفی می کند، به عبارت دیگر، آنها دارای خاصیتی هستند که باعث می شود هر توکن دقیقاً مشابه (از نظر نوع و مقدار) با توکن دیگر باشد. برای مثال توکن های ERC-20 دقیقا مثل اتر رفتار میکنند. به این معنی که 1 توکن همیشه با دیگر توکن ها برابر بوده و خواهد بود.
+
+## پیش نیاز ها {#prerequisites}
+
+- [حساب ها](/developers/docs/accounts)
+- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
+- [استانداردهای توکن](/developers/docs/standards/tokens/)
+
+## ساختار {#body}
+
+مفهوم توکن ERC-20 یا درخواست اتریوم برای نظرات 20 توسط فابیان ووگلستلر در نوامبر 2015 به عنوان استاندارد توکنی بیان شد که یک API برای توکن های قراردادهای هوشمند ارایه میکند.
+
+نمونه هایی از عملکردهای ERC-20 عبارتند از:
+
+- انتقال توکن ها از یک حساب به حساب دیگر
+- دریافت موجودی توکن یک حساب
+- دریافت کل عرضه توکن موجود در شبکه
+- تایید این که آیا مقداری توکن از یک حساب میتواند توسط یک حساب شخص ثالث خرج شود یا خیر
+
+اگر یک قرارداد هوشمند روشها و رویدادهای زیر را اجرا کند، میتوان آن را یک قرارداد توکن تعویض ناپذیر ERC-20 نامید و پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
+
+از [EIP-20](https://eips.ethereum.org/EIPS/eip-20):
+
+### روشها {#methods}
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
+function approve(address _spender, uint256 _value) public returns (bool success)
+function allowance(address _owner, address _spender) public view returns (uint256 remaining)
+```
+
+### رویدادها {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value)
+event Approval(address indexed _owner, address indexed _spender, uint256 _value)
+```
+
+### مثالها {#web3py-example}
+
+بیایید ببینیم سادگی یک استاندارد چقدر مهم است تا باعث شود هر گونه قرارداد توکن ERC-20 را در اتریوم بازرسی کنیم. ما برای ایجاد یک رابط در هر توکن ERC-20، فقط به رابط دوتایی برنامه قرارداد (ABI) نیاز داریم. همانطور که در زیر می بینید ما از یک ABI ساده شده استفاده می کنیم تا آن را به مثال قابل هضمی تبدیل کنیم.
+
+#### مثال Web3.py {#web3py-example}
+
+ابتدا مطمئن شوید که کتابخانه پایتون [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) را نصب کرده اید:
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
+weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
+
+acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
+
+# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract.
+# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply()
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'decimals',
+ 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi)
+symbol = dai_contract.functions.symbol().call()
+decimals = dai_contract.functions.decimals().call()
+totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# DAI
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+
+weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi)
+symbol = weth_contract.functions.symbol().call()
+decimals = weth_contract.functions.decimals().call()
+totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
+addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals
+
+# WETH
+print("===== %s =====" % symbol)
+print("Total Supply:", totalSupply)
+print("Addr Balance:", addr_balance)
+```
+
+## مشکلات شناخته شده {#erc20-issues}
+
+### مشکل دریافت توکن ERC-20 {#reception-issue}
+
+هنگامی که توکنهای ERC-20 به یک قرارداد هوشمند ارسال میشوند که برای مدیریت توکنهای ERC-20 طراحی نشده است، توکنها برای همیشه از دست خواهند رفت. این زمانی اتفاق میافتد که قرارداد هوشمند گیرنده، عملکرد لازم برای شناسایی یا پاسخ به توکنهای دریافتی را ندارد و هیچ مکانیزمی در استاندارد ERC-20 وجود ندارد که قرارداد دریافت کننده را از توکنهای دریافتی مطلع کند. راههای اصلی شکلگیری این موضوع:
+
+1. مکانیسم انتقال توکن
+ - توکنهای ERC-20 با استفاده از تابع transfer یا transferFrom انتقال مییابند
+ - هنگامی که کاربر با استفاده از این توابع، توکنها را به آدرس یک قرارداد هوشمند ارسال میکند، توکنها بدون در نظر گرفتن این که آیا قرارداد دریافت کننده برای رسیدگی به آنها طراحی شده است یا خیر، انتقال خواهند یافت
+2. عدم اطلاع رسانی
+ - قرارداد دریافتکننده اعلان یا تماسی مبنی بر ارسال توکن به آن دریافت نمیکند
+ - اگر قرارداد دریافتکننده مکانیزمی برای مدیریت توکنها نداشته باشد (به عنوان مثال، یک تابع بازگشتی یا یک تابع اختصاصی برای مدیریت دریافت توکن)، توکنها به طور مؤثر در آدرس قرارداد گیر میکنند
+3. بدون مدیریت داخلی
+ - استاندارد ERC-20 دارای یک تابع اجباری برای اجرای دریافت قراردادها نیست، که این امر منجر به وضعیتی میشود که بسیاری از قراردادها قادر به مدیریت صحیح توکنهای دریافتی نیستند
+
+برخی استانداردهای جایگزین بر این مشکل فائق آمدهاند، مانند [ERC-223](/developers/docs/standards/tokens/erc-223)
+
+## اطلاعات بیشتر {#further-reading}
+
+- [EIP-20: استاندارد توکن ERC-20](https://eips.ethereum.org/EIPS/eip-20)
+- [OpenZeppelin - توکن ها](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
+- [OpenZeppelin - پیادهسازی ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
+- [Alchemy - راهنمایی برای توکنهای ERC-20 نوشته شده با Solidity](https://www.alchemy.com/overviews/erc20-solidity)
+
+
+## سایر استانداردهای توکن قابل تعویض {#fungible-token-standards}
+
+- [ERC-223](/developers/docs/standards/tokens/erc-223)
+- [ERC-777](/developers/docs/standards/tokens/erc-777)
+- [ERC-4626 - خزانههای توکنیزه شده](/developers/docs/standards/tokens/erc-4626)
\ No newline at end of file
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md
new file mode 100644
index 00000000000..5bfacb62270
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md
@@ -0,0 +1,209 @@
+---
+title: استاندارد توکن ERC-223
+description: مروری بر استاندارد توکن تعویض پذیر ERC-223، طرز کار آن و مقایسه آن با ERC-20.
+lang: fa
+---
+
+## مقدمه {#introduction}
+
+### ERC-223 چیست؟ {#what-is-erc223}
+
+استاندارد ERC-223 همانند ERC-20، برای توکنهای تعویض پذیر است. تفاوت کلیدی آنها این است که ERC-223 علاوه بر API (رابط کاربری برنامه نویسی)، منطق انتقال توکنها از فرستنده به گیرنده را نیز تعریف مینماید. این استاندارد یک مدل ارتباطی را معرفی میکند که اجازه میدهد انتقال توکنها در طرف گیرنده انجام شود.
+
+### تفاوتها با ERC-20{#erc20-differences}
+
+ERC-223 به یک سری از محدودیتهای استاندارد ERC-20 پاسخ میدهد و شیوهی جدیدی از ارتباط بین قرارداد هوشمند منبع توکن و قرارداد هوشمندی که ممکن است دریافت کننده توکنها باشد را معرفی میکند. اینها برخی از مواردی هستند که با ERC-223 امکان پذیرند ولی با ERC-20 نه:
+
+- انجام و پردازش انتقال توکن در سمت گیرنده: گیرندهها میتوانند تشخیص دهند که یک توکن ERC-223 برای آنها واریز میشود.
+- رد کردن توکنهایی که به درستی ارسال نشدهاند: اگر کاربری توکنهای ERC-223 را به قرارداد اشتباهی واریز نماید، آن قرارداد میتواند تراکنش را رد کند و باعث جلوگیری از دست رفتن توکنها شود.
+- ابرداده در تراکنش ها: توکنهای ERC-223 میتوانند شامل ابرداده باشند و اجازه دهند تا اطلاعات دلخواه به تراکنش توکنها الصاق شود.
+
+## پیش نیازها {#prerequisites}
+
+- [حسابها](/توسعهدهندهها/اسناد/حساب)
+- [قراردادهای هوشمند](/توسعهدهندهها/اسناد/قراردادهای هوشمند/)
+- [Token standards](/developers/docs/standards/tokens/)
+- [ERC-20](/توسعهدهندهها/اسناد/استانداردها/توکنها/erc-20/)
+
+## ساختار{#body}
+
+ERC-223 یک استاندارد مخصوص توکن است که یک API برای توکنها در داخل قراردادهای هوشمند پیادهسازی میکند. همچنین یک API هم برای قراردادهایی که قرار است توکنهای ERC-223 دریافت کنند، تعریف میکند. قراردادهایی که از API گیرندهی ERC-223 پشتیبانی نمیکنند، قادر نخواهند بود توکنهای ERC-223 دریافت کنند و این باعث جلوگیری از خطای کاربر میشود.
+
+اگر یک قرارداد هوشمند توابع و رویدادهایی که قرار است مطرح شوند را پیادهسازی نماید، میتواند بهعنوان یک قرارداد توکن سازگار با ERC-223 شناخته شود. پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
+
+قرارداد ملزم نیست فقط توابع و عملکرد زیر را داشته باشد و یک توسعه دهنده میتواند هر قابلیت دیگری را از سایر استانداردهای توکن متفاوت به این قرارداد اضافه کند. برای مثال توابع `approve` (تائید) و `transferFrom` (انتقال از) جزئی از استاندارد ERC-223 نیستند، بلکه این توابع میتوانند در صورت نیاز پیادهسازی شوند.
+
+از [EIP-223](https://eips.ethereum.org/EIPS/eip-223):
+
+### روشها {#methods}
+
+توکن ERC-223 باید روشهای زیر را پیادهسازی کند:
+
+```solidity
+// تابع اسم
+function name() public view returns (string)
+// تابع سمبل
+function symbol() public view returns (string)
+// تابع اعشار
+function decimals() public view returns (uint8)
+// تابع عرضه کل
+function totalSupply() public view returns (uint256)
+// تابع موجودی (آدرس دلخواه)
+function balanceOf(address _owner) public view returns (uint256 balance)
+// تابع انتقال توکن
+function transfer(address _to, uint256 _value) public returns (bool success)
+// تابع انتقال توکن (همراه با متغیر اضافه برای انتقال داده)
+function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
+```
+
+قراردادی که قصد دارد توکنهای ERC-223 دریافت کند، باید روش زیر را پیادهسازی کند:
+
+```solidity
+// تابع قلاب دریافت توکن برای پیادهسازی توسط قرارداد هوشمند
+function tokenReceived(address _from, uint _value, bytes calldata _data)
+```
+
+اگر توکنهای ERC-223 به قراردادی ارسال شوند که تابع `tokenReceived(..)` را پیادهسازی نکرده باشد، تراکنش باید شکست بخورد و توکنها نباید از موجودی فرستنده منتقل شوند.
+
+### رویدادها {#events}
+
+```solidity
+// رویداد انتقال
+event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data)
+```
+
+### مثالها {#examples}
+
+رابط برنامهنویسی (API) توکن ERC-223 مشابه ERC-20 میباشد، بنابراین از نظر توسعه فرانت-اند هیچ تفاوتی ایجاد نمیشود. تنها تفاوت این است که احتمال دارد توکن ERC-223 توابع `approve` + `transferFrom` را نداشته باشد، چرا که آنها در این استاندارد اختیاری هستند.
+
+#### مثالهای Solidity{#solidity-example}
+
+مثالهای زیر نشان میدهد که چگونه یک قرارداد ساده و اولیه توکن ERC-223 عمل میکند:
+
+```solidity
+pragma solidity ^0.8.19;
+abstract contract IERC223Recipient {
+ function tokenReceived(address _from, uint _value, bytes memory _data) public virtual;
+}
+contract VeryBasicERC223Token {
+ event Transfer(address indexed from, address indexed to, uint value, bytes data);
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+ uint256 private _totalSupply;
+ mapping(address => uint256) private balances;
+ function name() public view returns (string memory) { return _name; }
+ function symbol() public view returns (string memory) {return _symbol; }
+ function decimals() public view returns (uint8) { return _decimals; }
+ function totalSupply() public view returns (uint256) { return _totalSupply; }
+ function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; }
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ assembly { size := extcodesize(account) }
+ return size > 0;
+ }
+ function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);
+ }
+ emit Transfer(msg.sender, _to, _value, _data);
+ return true;
+ }
+ function transfer(address _to, uint _value) public returns (bool success){
+ bytes memory _empty = hex"00000000";
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);
+ }
+ emit Transfer(msg.sender, _to, _value, _empty);
+ return true;
+ }
+}
+```
+
+حال ما به یک قرارداد دیگر نیاز داریم تا واریز `tokenA` را بپذیرد، با فرض اینکه توکن A یک توکن ERC-223 است. این قرارداد باید فقط توکن A را بپذیرد و هر توکن دیگری را رد کند. زمانی که قرارداد توکن A را دریافت میکند، باید یک رویداد `Deposit()` را اطلاع رسانی کند و مقدار متغیر داخلی `deposits` را افزایش دهد.
+
+کد مذکور به این شکل است:
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Deposit(address whoSentTheTokens);
+ uint256 deposits = 0;
+ address tokenA; // The only token that we want to accept.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ // It is important to understand that within this function
+ // msg.sender is the address of a token that is being received,
+ // msg.value is always 0 as the token contract does not own or send Ether in most cases,
+ // _from is the sender of the token transfer,
+ // _value is the amount of tokens that was deposited.
+ require(msg.sender == tokenA);
+ deposits += _value;
+ emit Deposit(_from);
+ }
+}
+```
+
+## سوالات متداول {#faq}
+
+### اگر مقداری از توکن B به قرارداد بفرستیم، چه اتفاقی خواهد افتاد؟ {#sending-tokens}
+
+تراکنش شکست خواهد خورد و انتقال توکنها انجام نخواهد شد. توکنها به آدرس فرستنده بازگشت داده خواهند شد.
+
+### چگونه میتوانیم به این قرارداد واریز انجام دهیم؟ {#contract-deposits}
+
+تابع `transfer(address,uint256)` یا `transfer(address,uint256,bytes)` از توکن ERC-223 را با مشخص کردن آدرس `RecipientContract`، فراخوانی کنید.
+
+### اگر یک توکن ERC-20 را به این قرارداد ارسال کنیم، چه اتفاقی خواهد افتاد؟ {#erc-20-transfers}
+
+اگر یک توکن ERC-20 به `RecipientContract` ارسال کنیم، توکنها انتقال خواهند یافت اما این انتقال شناسایی نخواهد شد (هیچ رویداد `Deposit()` اجرا نخواهد شد و مقدار واریزیها تغییر نخواهد کرد). از واریزهای ERC-20 ناخواسته نمیتوان جلوگیری کرد.
+
+### چه میشود اگر بخواهیم پس از تکمیل انتقال توکن، تابع دیگری را اجرا کنیم؟ {#function-execution}
+
+برای انجام دادن این کار راههای مختلف وجود دارد. در این مثال ما روشی را دنبال خواهیم کرد که باعث میشود انتقال ERC-223 مشابه انتقال اتر شود:
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Foo();
+ event Bar(uint256 someNumber);
+ address tokenA; // The only token that we want to accept.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ require(msg.sender == tokenA);
+ address(this).call(_data); // Handle incoming transaction and perform a subsequent function call.
+ }
+ function foo() public
+ {
+ emit Foo();
+ }
+ function bar(uint256 _someNumber) public
+ {
+ emit Bar(_someNumber);
+ }
+}
+```
+
+هنگامی که `RecipientContract` یک توکن ERC-223 را دریافت میکند، درست همانطور که تراکنشهای ارسال اتر فراخوانی توابع را بعنوان `data` در تراکنش کدنگاری میکنند، قرارداد نیز تابعی را که به عنوان متغیر `_data` در تراکنش توکن کدنگاری شده است اجرا خواهد کرد. برای اطلاعات بیشتر [دیتا فیلد](https://ethereum.org/en/developers/docs/transactions/#the-data-field) را مطالعه فرمائید.
+
+در مثال بالا، توکن ERC-223 باید با استفاده از تابع `transfer(address,uin256,bytes calldata _data)` به آدرس `RecipientContract` انتقال یابد. اگر مقدار پارامتر دیتا `0xc2985578` باشد (معادل امضاء تابع `foo()`)، بعد از دریافت توکن واریزی و اجراء رویداد Foo()، تابع foo() اجرا خواهد شد.
+
+پارامترها (متغیرهای ورودی) نیز میتوانند در `data` انتقال توکن کدنگاری شوند، برای مثال ما میتوانیم تابع bar() را با مقدار 12345 برای `_someNumber` اجرا کنیم. در این حالت مقدار `data` باید
+`0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` باشد به شکلی که
+`0x0423a132` امضاء تابع `bar(uint256)` است و
+`00000000000000000000000000000000000000000000000000000000000004d2` همان 12345 است در قالب uint256.
+
+## محدودیتها {#limitations}
+
+در حالی که ERC-223 به چندین مشکل پیدا شده در استاندارد ERC-20 میپردازد، خودش محدودیتهای خاص خود را دارد:
+
+- پذیرش و سازگاری: ERC-223 هنوز به صورت فراگیر پذیرفته و پیادهسازی نشده است که باعث محدود شدن سازگاری آن با ابزارها و پلتفرمهای موجود میشود.
+- پیش سازگاری: ERC-223 با ERC-20 پیش سازگار نیست، یعنی قراردادها و ابزارهای موجود برای ERC-20، باید برای کار کردن با ERC-223 اصلاح شوند.
+- هزینه گاز: بررسیها و عملکردهای اضافه در تراکنشهای انتقال ERC-223 میتوانند منجر به هزینههای گاز بیشتر در مقایسه با تراکنشهای ERC-20 شوند.
+
+## ادامه مطلب {#further-reading}
+
+- [EIP-223: استاندارد توکن ERC-223](https://eips.ethereum.org/EIPS/eip-223)
+- [پیشنهاد اولیه ERC-223](https://github.com/ethereum/eips/issues/223)
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-4626/index.md
new file mode 100644
index 00000000000..d63e8389c47
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-4626/index.md
@@ -0,0 +1,211 @@
+---
+title: ERC-4626 استاندارد خزانه توکنیزه شده
+description: استانداری برای خزانههای سودده.
+lang: fa
+---
+
+## مقدمه {#introduction}
+
+ERC-4626 استانداردی برای بهینهسازی و یکپارچهسازی متغیرهای فنی خزانههای سودده میباشد. این الگو یک API (وبسرویس) استاندارد را برای ارتباط با خزانههای سودده توکنیزه شده که نشانگر ارزش سهمی یک توکن ERC-20 پایه هستند، فراهم میکند. ERC-4626 همچنین یک افزونهی اختیاری را برای خزانههای توکنیزه شدهای که از توکنهای ERC-20 استفاده میکنند، ترسیم میکند که شامل عملکرد حداقلی برای سپردهگذاری، برداشت و نمایش موجودی توکنها است.
+
+**نقش استاندارد ERC-4626 در خزانههای سودده**
+
+بازارهای وامدهی، گردآورندگان و توکنهایی که ذاتا سودده هستند، به کاربران کمک میکنند تا با اجرای استراتژیهای متخلف، بهترین سود را برای توکنهای رمزارز پیدا کنند. این استراتژیها در انواع کم تفاوتی پیادهسازی میشوند که میتواند منجر به خطا یا هدر رفت منابع توسعه شود.
+
+استاندارد ERC-4626 با ایجاد الگوهای پیادهسازی پایدار و نبوغ آمیز، باعث کاهش زحمت یکپارچهسازی خزانههای سودده خواهد شد و امکان دسترسی به قابلیت کسب سود در اپلیکیشنهای مختلف را، با صرف کمترین دانش فنی از سوی برنامه نویسان فراهم میکند.
+
+توکن ERC-4626 به طور کامل در [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) توضیح داده شده است.
+
+## پیش نیاز ها {#prerequisites}
+
+برای درک بهتر مطالب این صفحه، به شما پیشنهاد میکنیم تا ابتدا دربارهی [استانداردهای توکن](/developers/docs/standards/tokens/) و [ERC-20](/developers/docs/standards/tokens/erc-20/) مطالعه بفرمائید.
+
+## توابع و ویژگی های ERC-4626: {#body}
+
+### روشها {#methods}
+
+#### asset {#asset}
+
+```solidity
+function asset() public view returns (address assetTokenAddress)
+```
+
+این تابع، آدرس توکن پایه را که در خزانه برای واریز، برداشت و حسابداری مورد استفاده قرار میگیرد، فراخوانی میکند.
+
+#### totalAssets {#totalassets}
+
+```solidity
+function totalAssets() public view returns (uint256)
+```
+
+این تابع، مجموع مقدار توکن پایه را که در خزانه نگهداری میشود نشان میدهد.
+
+#### convertToShares {#convertoshares}
+
+```solidity
+function convertToShares(uint256 assets) public view returns (uint256 shares)
+```
+
+این تابع مقدار `سهمی` که خزانه در ازای مقدار `دارایی` معاوضه خواهد کرد را نشان میدهد.
+
+#### convertToAssets {#convertoassets}
+
+```solidity
+function convertToAssets(uint256 shares) public view returns (uint256 assets)
+```
+
+این تابع مقدار `سهمی` که خزانه در ازای مقدار `دارایی (توکن پایه)` معاوضه خواهد کرد را نشان میدهد.
+
+#### maxDeposit {#maxdeposit}
+
+```solidity
+function maxDeposit(address receiver) public view returns (uint256 maxAssets)
+```
+
+این تابع حداکثر مقدار توکن پایه قابل واریز را که میتواند در یک تراکنش [`deposit`](#deposit) توسط `receiver` اجرا شود، نمایش میدهد.
+
+#### previewDeposit {#previewdeposit}
+
+```solidity
+function previewDeposit(uint256 assets) public view returns (uint256 shares)
+```
+
+این تابع به کاربران اجازه میدهد تاثیر تراکنش واریز خود را بر بلوک فعلی شبیهسازی کنند.
+
+#### deposit {#deposit}
+
+```solidity
+function deposit(uint256 assets, address receiver) public returns (uint256 shares)
+```
+
+این تابع `دارایی` یا همان توکن پایه را به خزانه واریز میکند و حق مالکیت `سهام (shares)` را به `گیرنده (receiver)` اعطا میکند.
+
+#### maxMint {#maxmint}
+
+```solidity
+function maxMint(address receiver) public view returns (uint256 maxShares)
+```
+
+این تابع حداکثر مقدار سهامی که در یک تراکنش [`mint`](#mint) توسط `receiver` میتواند ضرب شود را نمایش میدهد.
+
+#### previewMint {#previewmint}
+
+```solidity
+function previewMint(uint256 shares) public view returns (uint256 assets)
+```
+
+این تابع به کاربران اجازه میدهد تا تاثیر تراکنش ضرب دارایی خود را بر بلوک فعلی شبیهسازی کنند.
+
+#### ضرب سکه {#mint}
+
+```solidity
+function mint(uint256 shares, address receiver) public returns (uint256 assets)
+```
+
+این تابع با واریز مقدار `assets` از توکن پایه، دقیقاً به مقدار `shares` از سهام خزانه را برای آدرس `receiver` صادر میکند.
+
+#### maxWithdraw {#maxwithdraw}
+
+```solidity
+function maxWithdraw(address owner) public view returns (uint256 maxAssets)
+```
+
+این تابع حداکثر مقدار توکن پایه که در یک تراکنش برداشت یا [`withdraw`](#withdraw) توسط `owner` میتواند برداشت شود را نمایش میدهد.
+
+#### previewWithdraw {#previewwithdraw}
+
+```solidity
+function previewWithdraw(uint256 assets) public view returns (uint256 shares)
+```
+
+این تابع به کاربران اجازه میدهد تا تاثیر تراکنش برداشت دارایی (توکن پایه) خود را بر بلوک فعلی شبیهسازی کنند.
+
+#### عقب نشینی {#withdraw}
+
+```solidity
+function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
+```
+
+این تابع مقدار `shares` یا سهام را از آدرس `owner` میسوزاند و دقیقاً به مقدار `assets`، توکن پایه را از خزانه به آدرس `receiver` ارسال میکند.
+
+#### maxRedeem {#maxredeem}
+
+```solidity
+function maxRedeem(address owner) public view returns (uint256 maxShares)
+```
+
+این تابع حداکثر مقدار سهام را که از موجودی `owner`، از طریق اجرای تابع [`redeem`](#redeem) میتوان برداشت کرد، نشان میدهد.
+
+#### previewRedeem {#previewredeem}
+
+```solidity
+function previewRedeem(uint256 shares) public view returns (uint256 assets)
+```
+
+این تابع به کاربران اجازه میدهد تا تأثیر تراکنش بازخرید سهام (redeem) خود را بر روی بلوک فعلی شبیه سازی نمایند.
+
+#### redeem {#redeem}
+
+```solidity
+function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
+```
+
+این تابع مقدار مشخصی از `shares` را از جانب `owner` بازخرید میکند و به مقدار `assets`، توکن پایه از خزانه به آدرس `receiver` ارسال میکند.
+
+#### totalSupply {#totalsupply}
+
+```solidity
+function totalSupply() public view returns (uint256)
+```
+
+مقدار مجموع سهمهای خزانه بازخرید نشده که در گردش هستند را نشان میدهد.
+
+#### balanceOf {#balanceof}
+
+```solidity
+function balanceOf(address owner) public view returns (uint256)
+```
+
+مقدار مجموع سهمهای خزانه ای که `owner` در حال حاضر مالک آنها میباشد را نشان میدهد.
+
+### نقشه رابط برنامه نویسی {#mapOfTheInterface}
+
+![نقشه رابط برنامه نویسی ERC-4626](./map-of-erc-4626.png)
+
+### رویدادها {#events}
+
+#### رویداد واریز
+
+**باید** زمانی که توکنها از طریق توابع [`mint`](#mint) و [`deposit`](#deposit) به درون خزانه واریز میشوند، اجرا شود
+
+```solidity
+event Deposit(
+ address indexed sender,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+`sender` کاربری میباشد که مقدار `assets` را در ازای مقدار `shares` مبادله کرده و مقدار `shares` را به آدرس `owner` انتقال داده است.
+
+#### رویداد برداشت
+
+**باید** زمانی که سهمها توسط یک سپرده گذار با استفاده از توابع [`redeem`](#redeem) یا [`withdraw`](#withdraw) برداشت میشوند، اجرا شود.
+
+```solidity
+event Withdraw(
+ address indexed sender,
+ address indexed receiver,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+`sender` کاربری میباشد که تراکنش برداشت را اجرا نموده و مقدار `shares` را که `owner` مالک آن بوده، در ازای مقدار `assets` مبادله کرده است. `receiver` آدرس کاربری میباشد که مقدار `asset` را دریافت کرده است.
+
+## بیشتر بخوانید {#further-reading}
+
+- [ERC-4626 استاندارد خزانه توکنیزه شده](https://eips.ethereum.org/EIPS/eip-4626)
+- [ERC-4626: در Repo گیت هاب](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-721/index.md
new file mode 100644
index 00000000000..64dda3bab51
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-721/index.md
@@ -0,0 +1,244 @@
+---
+title: ERC-721 استاندارد توکن تعویض ناپذیر
+description:
+lang: fa
+---
+
+## معرفی {#introduction}
+
+**توکن تعویض ناپذیر چیست؟**
+
+از یک توکن تعویض ناپذیر (NFT) برای شناسایی چیزی یا شخصی به روشی منحصر به فرد استفاده می شود. این نوع توکن برای استفاده در پلتفرم هایی که آیتم های کلکسیونی، کلیدهای دسترسی، بلیط های بخت آزمایی، صندلی های شماره دار دارند و همچنین برای کنسرت ها و مسابقات ورزشی و غیره مناسب می باشد. این نوع خاص از توکن دارای امکانات شگفت انگیزی است، بنابراین سزاوار استانداردی مناسب است، بنابراین ERC-721 برای حل آن آمده است!
+
+**ERC-721 چیست؟**
+
+ERC-721 استانداردی را برای NFT معرفی می کند، به عبارت دیگر، شاید به دلیل قدمت، کمیاب بودن یا حتی چیز دیگری همچون ظاهر آن، این نوع توکن منحصر به فرد است و می تواند ارزش متفاوتی نسبت به توکن دیگری از همان قرارداد هوشمند را داشته باشد. صبر کنید، ظاهر؟
+
+بله! همه NFT ها دارای یک متغیر `uint256` به نام `tokenId` هستند، بنابراین برای هر قرارداد ERC-721، جفت `contract address، uint256 tokenId` باید در سطح جهانی یکتا باشد. گفته می شود، یک dapp می تواند یک "مبدل" داشته باشد که از `tokenId` به عنوان ورودی استفاده می کند و تصویری از چیز جالبی مانند زامبی ها، سلاح ها، مهارت ها یا بچه گربه های شگفت انگیز را خروجی می دهد!
+
+## پیش نیاز ها {#prerequisites}
+
+- [حساب ها](/developers/docs/accounts/)
+- [↳ قراردادهای هوشمند](/developers/docs/smart-contracts/)
+- [استانداردهای توکن](/developers/docs/standards/tokens/)
+
+## Body {#body}
+
+ERC-721 (درخواست اتریوم برای نظرات 721)، که توسط ویلیام انتریکن، دیتر شرلی، جیکوب ایوانز، ناستاسیا ساکس در ژانویه 2018 پیشنهاد شد، یک استاندارد توکن تعویض ناپذیر است که یک API برای توکنها در قراردادهای هوشمند پیادهسازی میکند.
+
+این ویژگی عملکردهایی مانند انتقال توکن ها از یک حساب به حساب دیگر، دریافت موجودی رمز فعلی یک حساب، به دست آوردن صاحب یک توکن خاص و نیز کل عرضه توکن موجود در شبکه را ارائه می دهد. علاوه بر اینها، عملکردهای دیگری همچون تأیید مقدار توکنی که از یک حساب می تواند توسط یک حساب شخص ثالث منتقل شود، را نیز در خود دارد.
+
+اگر یک قرارداد هوشمند، توابع و رویدادهای زیر را پیادهسازی کند، میتوان آن را یک قرارداد توکن تعویض ناپذیر ERC-721 نامید و پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
+
+از [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
+
+### روشها {#methods}
+
+```solidity
+ function balanceOf(address _owner) external view returns (uint256);
+ function ownerOf(uint256 _tokenId) external view returns (address);
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
+ function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
+ function approve(address _approved, uint256 _tokenId) external payable;
+ function setApprovalForAll(address _operator, bool _approved) external;
+ function getApproved(uint256 _tokenId) external view returns (address);
+ function isApprovedForAll(address _owner, address _operator) external view returns (bool);
+```
+
+### رویدادها {#events}
+
+```solidity
+ event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
+ event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
+ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
+```
+
+### مثالها {#web3py-example}
+
+بیایید ببینیم یک استاندارد چقدر مهم است که کار ما را برای بررسی قراردادهای هوشمند ERC-721 آسان میکند. ما فقط به رابط دوتایی برنامه قرارداد (ABI) برای ایجاد یک رابط برای هر توکن ERC-721 نیاز داریم. همانطور که در زیر می بینید ما از یک ABI ساده شده استفاده می کنیم تا آن را به عنوان مثالی با اصطکاک کم تبدیل کنیم.
+
+#### مثال Web3.py {#web3py-example}
+
+ابتدا مطمئن شوید که کتابخانه پایتون [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) را نصب کرده اید:
+
+```
+pip install web3
+```
+
+```python
+from web3 import Web3
+from web3._utils.events import get_event_data
+
+
+w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
+
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract
+
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction
+
+# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract.
+# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
+simplified_abi = [
+ {
+ 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
+ 'name': 'balanceOf',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'name',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'ownerOf',
+ 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'symbol',
+ 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [],
+ 'name': 'totalSupply',
+ 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
+ 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+]
+
+ck_extra_abi = [
+ {
+ 'inputs': [],
+ 'name': 'pregnantKitties',
+ 'outputs': [{'name': '', 'type': 'uint256'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ },
+ {
+ 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],
+ 'name': 'isPregnant',
+ 'outputs': [{'name': '', 'type': 'bool'}],
+ 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
+ }
+]
+
+ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
+name = ck_contract.functions.name().call()
+symbol = ck_contract.functions.symbol().call()
+kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
+print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}")
+
+pregnant_kitties = ck_contract.functions.pregnantKitties().call()
+print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}")
+
+# Using the Transfer Event ABI to get info about transferred Kitties.
+tx_event_abi = {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'from', 'type': 'address'},
+ {'indexed': False, 'name': 'to', 'type': 'address'},
+ {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}],
+ 'name': 'Transfer',
+ 'type': 'event'
+}
+
+# We need the event's signature to filter the logs
+event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
+
+logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [event_signature]
+})
+
+# Notes:
+# - Increase the number of blocks up from 120 if no Transfer event is returned.
+# - If you didn't find any Transfer event you can also try to get a tokenId at:
+# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
+# Click to expand the event's logs and copy its "tokenId" argument
+recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
+
+if recent_tx:
+ kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above
+ is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
+ print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}")
+```
+
+قرارداد CryptoKitties دارای رویدادهای جالبی به غیر از موارد استاندارد است.
+
+بیایید دو مورد از آنها، `حامله` و `تولد` را بررسی کنیم.
+
+```python
+# Using the Pregnant and Birth Events ABI to get info about new Kitties.
+ck_extra_events_abi = [
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],
+ 'name': 'Pregnant',
+ 'type': 'event'
+ },
+ {
+ 'anonymous': False,
+ 'inputs': [
+ {'indexed': False, 'name': 'owner', 'type': 'address'},
+ {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
+ {'indexed': False, 'name': 'genes', 'type': 'uint256'}],
+ 'name': 'Birth',
+ 'type': 'event'
+ }]
+
+# We need the event's signature to filter the logs
+ck_event_signatures = [
+ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
+]
+
+# Here is a Pregnant Event:
+# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
+pregnant_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[0]]
+})
+
+recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
+
+# Here is a Birth Event:
+# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
+birth_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[1]]
+})
+
+recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
+```
+
+## NFT های محبوب {#popular-nfts}
+
+- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) برترین NFT در اتریوم را بر اساس حجم نقل و انتقالات فهرست می کند.
+- [CryptoKitties](https://www.cryptokitties.co/) یک بازی حول موجودات قابل پرورش، کلکسیونی و بسیار شایان ستایش است که به آنها CryptoKitties می گوییم.
+- [Sorare](https://sorare.com/) یک بازی فوتبال فانتزی جهانی است که در آن میتوانید کلکسیونهای نسخههای محدودی را جمعآوری کنید، تیمهای خود را مدیریت کنید و برای کسب جوایز به رقابت بپردازید.
+- [سرویس نام اتریوم (ENS)](https://ens.domains/) یک & روش غیرمتمرکز برای آدرسدهی منابع هم در داخل و هم خارج از بلاک چین با استفاده از نامهای ساده و قابل خواندن برای انسان می باشد.
+- [POAP](https://poap.xyz) NFTهای رایگان را به افرادی که در رویدادها شرکت می کنند یا اقدامات خاصی را انجام می دهند ارائه می دهد. ایجاد و توزیع POAP ها رایگان است.
+- [Unstoppable Domains](https://unstoppabledomains.com/) یک شرکت مستقر در سانفرانسیسکو است که دامنههای خود را بر روی بلاک چین ها می سازد. دامنههای بلاک چین آدرسهای ارزهای دیجیتال را با نامهای قابل خواندن برای انسان جایگزین میکنند و میتوان از آنها برای فعال کردن وبسایتهای مقاوم در برابر سانسور استفاده کرد.
+- [Gods Unchained Cards](https://godsunchained.com/) یک TCG در بلاک چین اتریوم است که از NFT برای ایجاد مالکیت واقعی بر داراییهای درون بازی استفاده میکند.
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com) مجموعه ای از 10000 NFT منحصر به فرد است که علاوه بر اینکه یک اثر هنری نادر است، به عنوان نماد عضویت در باشگاه عمل می کند و امتیازات و مزایایی را برای اعضا فراهم می کند که در نتیجه تلاش های جامعه در طول زمان افزایش می یابد.
+
+## بیشتر بخوانید {#further-reading}
+
+- [EIP-721: استاندارد توکن تعویض ناپذیر ERC-721](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - مستندات ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - پیاده سازی ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..e9e07e78e33
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,77 @@
+---
+title: 'EIP-: استاندارد توکن ERC-777'
+description:
+lang: fa
+---
+
+## {#introduction}
+
+****
+
+****
+
+قلاب ها تابعی هستند که در کد یک قرارداد هوشمند توضیح داده شده است. هنگامی که توکن ها از طریق یک قرارداد ارسال یا دریافت می شوند، قلاب ها فراخوانی می شوند. این به یک قرارداد هوشمند اجازه می دهد تا به توکن های ورودی یا خروجی واکنش نشان دهد.
+
+## {#prerequisites}
+
+- []()
+- []()
+- []()
+
+## {#body}
+
+قلاب ها با استفاده از استاندارد [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)ثبت و کشف میشوند.
+
+این استاندارد همچنین ابهامی را که در مورد `اعشار` ایجاد شده در ERC-20 وجود دارد حل می کند. این شفافیت باعث بهبود تجربه توسعه دهنده می شود.
+
+می توان با قراردادهای ERC-777 به گونه ای تعامل کرد که انگار قراردادهای ERC-20 هستند.
+
+### {#methods}
+
+```solidity
+
+```
+
+### {#events}
+
+```solidity
+
+```
+
+### {#web3py-example}
+
+#### {#web3py-example}
+
+```
+
+```
+
+```python
+
+
+
+
+```
+
+```python
+
+
+```
+
+## {#popular-nfts}
+
+-
+-
+-
+-
+-
+-
+-
+-
+
+## اطلاعات بیشتر {#further-reading}
+
+- []()
+- []()
+- []()
+- []()
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/index.md b/public/content/translations/fa/developers/docs/standards/tokens/index.md
new file mode 100644
index 00000000000..ac7c811e1a5
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/standards/tokens/index.md
@@ -0,0 +1,39 @@
+---
+title: استانداردهای توکن
+description:
+lang: fa
+incomplete: true
+---
+
+## معرفی {#introduction}
+
+بسیاری از استانداردهای توسعه اتریوم بر روی رابط های توکن تمرکز دارند. این استانداردها کمک میکنند تا اطمینان حاصل شود که قراردادهای هوشمند قابل تنظیم باقی میمانند، بهعنوان مثال، زمانی که یک پروژه جدید یک توکن صادر میکند که با صرافیهای غیرمتمرکز موجود سازگار باقی بماند.
+
+## پیش نیاز ها {#prerequisites}
+
+- [استانداردهای توسعه اتریوم](/developers/docs/standards/)
+- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
+
+## استانداردهای توکن {#token-standards}
+
+در اینجا برخی از محبوب ترین استانداردهای توکن در اتریوم آمده است:
+
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - یک رابط استاندارد برای توکنهای تعویضپذیر (قابل تعویض)، مانند توکنهای رایگیری، توکنهای شرطبندی یا ارزهای مجازی می باشد.
+
+### استانداردهای NFT {#nft-standards}
+
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - یک رابط استاندارد برای توکنهای تعویض ناپذیر، مانند یک سند برای اثر هنری یا یک آهنگ است.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 امکان معاملات کارآمدتر و بستهبندی تراکنشها را فراهم میکند - بنابراین در هزینهها صرفهجویی میشود. این استاندارد توکن امکان ایجاد توکن های کاربردی (مانند $BNB یا $BAT) و توکن های تعویض ناپذیر مانند CryptoPunks را فراهم می کند.
+
+فهرست کامل پیشنهادهای [ERC](https://eips.ethereum.org/erc).
+
+## بیشتر بخوانید {#further-reading}
+
+_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
+
+## آموزش های مرتبط {#related-tutorials}
+
+- [چک لیست ادغام توکن ها](/developers/tutorials/token-integration-checklist/) _– چک لیستی از مواردی که باید هنگام تعامل با توکن ها در نظر بگیرید._
+- [با قرارداد هوشمند توکن ERC20 آشنا شوید](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– مقدمه ای برای استقرار اولین قرارداد هوشمندتان بر روی یک شبکه آزمایشی اتریوم._
+- [انتقال و تایید توکن های ERC20 از یک قرارداد هوشمند Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– نحوه استفاده از قرارداد هوشمند برای تعامل با توکن با استفاده از زبان Solidity._
+- [پیاده سازی یک بازار ERC721 [راهنمای نحوه انجام]](/developers/tutorials/how-to-implement-an-erc721-market/) _– چگونه اقلام توکن دار را برای فروش بر روی یک تابلوی طبقه بندی غیرمتمرکز قرار دهیم._
diff --git a/public/content/translations/fa/developers/docs/transactions/index.md b/public/content/translations/fa/developers/docs/transactions/index.md
index 469da018601..0430b80cc8b 100644
--- a/public/content/translations/fa/developers/docs/transactions/index.md
+++ b/public/content/translations/fa/developers/docs/transactions/index.md
@@ -23,7 +23,7 @@ lang: fa
تراکنش ارسالی شامل اطلاعات زیر است:
- `از` - آدرس فرستنده که تراکنش را امضا خواهد کرد. این یک حساب مالکیت خارجی خواهد بود، چون حساب قرارداد نمیتواند تراکنش ارسال کنند.
-- `دریافتکننده` - آدرس دریافتکننده (اگر یک حساب با مالکیت خارجی باشد، تراکنش یک ارزش را منتقل میکند. اگر یک حساب قرارداد باشد، تراکنش کد قرارداد را اجرا میکند)
+- `به` - آدرس دریافت کننده (اگر یک حساب با مالکیت خارجی باشد، تراکنش یک مقدار را منتقل خواهد کرد. اگر یک حساب قرارداد باشد، تراکنش کد قرارداد را اجرا میکند)
- `امضاء` - شناسه فرستنده. زمانی ایجاد میشود که کلید خصوصی فرستنده تراکنش را امضا کند و تأیید کند که فرستنده این تراکنش را مجاز کرده است
- `Nonce` - یک شمارنده که به شکل متوالی افزایش می یابد و تعداد تراکنش های حساب را نشان میدهد
- `ارزش` - مقدار اتر فرستاده شده از آدرس فرستنده تراکنش به گیرنده (این مقدار در واحد اندازه گیری WEI نمایش داده میشود، که هر اتر برابر با 1e+18 wei است)
@@ -125,7 +125,7 @@ lang: fa
با توجه به مشخصات ABI، مقادیر صحیح (مانند آدرسها که اعداد صحیح 20 بایتی هستند) در ABI به صورت کلمات 32 بایتی ظاهر میشوند که ممکن است یک یا چند صفر در ابتدای آنها قرار داده شود. بنابراین ما میدانیم که آدرس `«to»`
`4f6742badb049791cd9a302791cd9a302791cd99a32791cd99a310.com است.
-مقدار` 0x3b0559f4 = 990206452 است.
+مقدار` 0x3b0559f4 = 990206452 است.
@@ -162,14 +162,22 @@ lang: fa
اعتبارسنج انعام **+0.000210 ETH** را نگه می دارد
-گاز برای هر تعامل قرارداد هوشمند نیز لازم است.
-
![شکلی نشاندهندهی نحوهی بازپرداخت گاز مصرفنشده](./gas-tx.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
هر گازی که در تراکنش استفاده نشده باشد به حساب کاربری مسترد میشود.
+### تعاملات قرارداد هوشمند {#smart-contract-interactions}
+
+گاز برای هر تراکنشی که شامل یک قرارداد هوشمند است، لازم است.
+
+قراردادهای هوشمند همچنین میتوانند دارای عملکردهایی باشند که بهعنوان عملکردهای [`نما`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) یا [`خالص`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) شناخته میشوند، که وضعیت قرارداد را تغییر نمیدهند. به این ترتیب، فراخوانی این توابع از یک EOA نیازی به گاز ندارد. فراخوان RPC اصلی برای این سناریو [`eth_call`](/developers/docs/apis/json-rpc#eth_call) است
+
+برخلاف زمانی که با استفاده از `eth_call` قابل دسترسی است، این توابع `نما` یا `خالص` معمولاً به صورت داخلی نیز فراخوانده می شوند (یعنی از خود قرارداد یا از قرارداد دیگری) که کارمزد گس را به همراه دارد.
+
+
+
## چرخهی حیات تراکنش {#transaction-lifecycle}
هنگامی که تراکنش ارسال شد، موارد زیر اتفاق میافتد:
@@ -208,6 +216,16 @@ lang: fa
- `TransactionType` - عددی بین 0 و 0x7f، برای مجموع 128 نوع تراکنش ممکن.
- `TransactionPayload` - یک آرایهی بایت دلخواه که توسط نوع تراکنش تعریف شده است.
+بر اساس مقدار `TransactionType`، تراکنش را می توان به موارد زیر طبقهبندی کرد
+
+1. **تراکنش های نوع صفر (قدیمی):** فرمت تراکنش اصلی که از زمان راهاندازی اتریوم استفاده شده است. اینها شامل ویژگیهای [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) مانند محاسبات دینامیک هزینه گس یا لیست دسترسی برای قراردادهای هوشمند نمیشوند. تراکنشهای قدیمی فاقد پیشوند خاصی هستند که نوع آنها را به صورت سریالی نشان میدهد، و با بایت `0xf8` هنگام استفاده از رمزگذاری [پیشوند طول بازگشتی (RLP)](/developers/docs/data-structures-and-encoding/rlp) شروع میشوند. مقدار TransactionType برای این تراکنشها `0x0` است.
+
+2. **تراکنشهای نوع یک:**در [پیشنهاد EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) بهعنوان بخشی از [ارتقای برلین](/history/#berlin) اتریوم معرفی شدند، این تراکنشها شامل پارامتر `accessList` هستند. این فهرست اقدام به مشخصکردن آدرسها و کلیدهای ذخیرهسازی میکند که تراکنش انتظار دارد به آنها دسترسی داشته باشد، و به کاهش بالقوه هزینههای [گس](/developers/docs/gas/) برای تراکنشهای پیچیده شامل قراردادهای هوشمند کمک میکند. تغییرات بازار کارمزد EIP-1559 در تراکنشهای نوع یک گنجانده نشدهاند. تراکنشهای نوع 1 همچنین شامل یک پارامتر `yParity` هستند که میتواند `0x0` یا `0x1` باشد که نشاندهنده برابری مقدار y امضای secp256k1 است. تشخیص آنها اینطور است که با بایت `0x01` شناسایی می شوند و مقدار TransactionType آنها `0x1` است.
+
+3. **تراکنشهای نوع 2** که معمولاً به تراکنشهای EIP-1559 گفته میشوند، تراکنشهایی هستند که در [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)، در [بهروزرسانی لندن](/history/#london) اتریوم معرفی شدهاند. آنها به مدل تراکنش استاندارد در شبکه اتریوم تبدیل شدهاند. این تراکنشها یک مکانیزم جدید بازار کارمزد را معرفی میکنند که با تفکیک کارمزد معامله به کارمزد پایه و کارمزد اولویت، قابلیت پیشبینی را بهبود میبخشد. آنها با بایت `0x02` شروع می شوند و شامل فیلدهایی مانند `maxPriorityFeePerGas` و `maxFeePerGas` میشوند. تراکنشهای نوع 2 اکنون به دلیل انعطافپذیری و کارایی، پیشفرض هستند، بهویژه در دورههای شلوغی بالای شبکه به دلیل توانایی آنها در کمک به کاربران در مدیریت قابل پیشبینیتر کارمزد تراکنشها مورد توجه قرار میگیرند. مقدار TransactionType برای این تراکنش ها `0x2` است.
+
+
+
## بیشتر بخوانید {#further-reading}
diff --git a/public/content/translations/fa/developers/docs/wrapped-eth/index.md b/public/content/translations/fa/developers/docs/wrapped-eth/index.md
new file mode 100644
index 00000000000..e92be3f2ac5
--- /dev/null
+++ b/public/content/translations/fa/developers/docs/wrapped-eth/index.md
@@ -0,0 +1,65 @@
+---
+title: رپد اتر (WETH) چیست؟
+description: مقدمه ای بر رپد اتر (WETH) - یک پوشش سازگار با ERC20 برای اتر (ETH).
+lang: fa
+---
+
+# رپد اتر (WETH) {#intro-to-weth}
+
+اتر (ETH) ارز اصلی اتریوم است. از آن برای چندین هدف مانند سهام گذاری، به عنوان ارز، و پرداخت هزینه های گس برای محاسبه استفاده می شود. **WETH عملاً یک شکل ارتقا یافته از ETH با برخی عملکردهای اضافی مورد نیاز بسیاری از برنامهها و [ERC-20 tokens](/glossary/#erc-20)** است که انواع دیگری از داراییهای دیجیتال در اتریوم هستند. برای کار با این توکن ها، ETH باید از همان قوانینی که به عنوان استاندارد ERC-20 شناخته می شوند، پیروی کند.
+
+برای پر کردن این شکاف، رپد اتر (WETH) ایجاد شد. **رپد اتر (WETH) یک قرارداد هوشمند است که به شما اجازه میدهد هر مقدار اتر را به این قرارداد واریز کنید و به ازای هر اتر واریزی، مقدار برابر آن را به صورت توکن WETH ضرب شده دریافت کنید** که مطابق با استاندارد توکن ERC-20 است. WETH گونهای از ETH است که به شما امکان می دهد با آن به عنوان یک توکن ERC-20 تعامل داشته باشید، نه به عنوان ETH دارایی بومی. برای پرداخت هزینه های گس همچنان به ETH بومی نیاز دارید، بنابراین مطمئن شوید که هنگام واریز مقداری پس انداز کرده اید.
+
+با استفاده از قرارداد هوشمند WETH می توانید WETH را به ETH تبدیل کنید. با قرارداد هوشمند WETH می توانید هر مقدار WETH را بازخرید کنید و همان مقدار را به صورت اتریوم دریافت خواهید کرد. سپس WETH سپرده شده سوزانده میشود و از منبع در حال گردش WETH خارج می شود.
+
+**تقریباً 3٪ از عرضه ETH در گردش در قرارداد توکن WETH قفل شده است** و آن را به یکی از پرکاربردترین [قراردادهای هوشمند] تبدیل می کند (/glossary/#smart-contract). WETH به ویژه برای کاربرانی که با برنامههای کاربردی در امور مالی غیرمتمرکز (DeFi) تعامل دارند، مهم است.
+
+## چرا به رپد ETH به عنوان ERC-20 نیاز داریم؟ {#why-do-we-need-to-wrap-eth}
+
+[ERC-20](/developers/docs/standards/tokens/erc-20/) یک رابط استاندارد برای توکنهای قابل انتقال تعریف میکند، بنابراین هر کس میتواند توکنهایی ایجاد کند که به طور یکپارچه با برنامهها و توکنهایی که از این استاندارد در اکوسیستم اتریوم استفاده میکنند، تعامل داشته باشند. از آنجا که **ETH قبل از استاندارد ERC-20** ایجاد شده است، ETH با این مشخصات مطابقت ندارد. این به این معنی است که **شما نمی توانید به راحتی** ETH را با سایر توکنهای ERC-20 مبادله کنید یا **از ETH در برنامه ها با استفاده از استاندارد ERC-20 استفاده کنید**. رپ کردن ETH به شما این فرصت را می دهد که کارهای زیر را انجام دهید:
+
+- **مبادله ETH با توکن های ERC-20**: شما نمی توانید ETH را مستقیماً با سایر توکن های ERC-20 مبادله کنید. WETH گونهای اتر است که با استاندارد توکن قابل تعویض ERC-20 مطابقت دارد و می تواند با سایر توکن های ERC-20 مبادله شود.
+
+- **از ETH در dapp ها استفاده کنید**: از آنجا که ETH با ERC20 سازگار نیست، توسعه دهندگان باید رابط های جداگانه ای (یکی برای ETH و دیگری برای توکن های ERC-20) در dapp ها ایجاد کنند. رپ کردن ETH این مانع را برطرف میکند و توسعهدهندگان را قادر میسازد تا ETH و سایر توکنها را در همان dapp مدیریت کنند. بسیاری از برنامه های مالی غیرمتمرکز از این استاندارد استفاده می کنند و بازارهایی را برای مبادله این توکن ها ایجاد می کنند.
+
+## رپد اتر (WETH) در مقابل اتر (ETH): تفاوت در چیست؟ {#weth-vs-eth-differences}
+
+| | **اتر (ETH)** | **رپد اتر (WETH)** |
+| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| عرضه | عرضه ETH توسط پروتکل اتریوم مدیریت می شود. هنگام پردازش تراکنشها و ایجاد بلوک، [issuance](/roadmap/merge/issuance) اتر توسط اعتبارسنجهای اتریوم مدیریت میشود. | WETH یک توکن ERC-20 است که عرضه آن توسط یک قرارداد هوشمند مدیریت می شود. واحدهای جدید WETH پس از دریافت سپرده های ETH از کاربران توسط قرارداد صادر می شوند، یا زمانی که کاربر می خواهد WETH را برای ETH بازخرید کند، واحدهای WETH سوزانده می شوند. |
+| مالکیت | مالکیت توسط پروتکل اتریوم از طریق موجودی حساب شما مدیریت می شود. | مالکیت WETH توسط قرارداد هوشمند توکن WETH مدیریت می شود که توسط پروتکل اتریوم ایمن شده است. |
+| گاز | اتر (ETH) واحد پرداخت پذیرفته شده برای محاسبه در شبکه اتریوم است. هزینه های گس بر حسب gwei (واحد اتر) تعیین می شود. | پرداخت گس با توکن های WETH به صورت بومی پشتیبانی نمی شود. |
+
+## سوالات متداول {#faq}
+
+
+
+برای رپ یا آنرپ کردن ETH با استفاده از قرارداد WETH هزینه گس می پردازید.
+
+
+
+
+
+WETH به دلیل اینکه بر اساس یک قرارداد هوشمند ساده و آزمایششده ساخته شده است، به طور کلی امن در نظر گرفته میشود. قرارداد WETH نیز به طور رسمی تأیید شده است که بالاترین استاندارد امنیتی برای قراردادهای هوشمند در اتریوم است.
+
+
+
+
+
+علاوه بر پیادهسازی متعارفِ WETH[canonical implementation of WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) که در این صفحه توضیح داده شد، نسخههای دیگری از آن نیز وجود دارند. اینها ممکن است توکنهای سفارشی ایجاد شده توسط توسعهدهندگان اپلیکیشن یا نسخههای منتشر شده در سایر بلاک چینها باشند و ممکن است رفتار متفاوت یا ویژگیهای امنیتی متفاوت داشته باشند. **همیشه اطلاعات توکن را دوباره بررسی کنید تا بدانید با کدام اجرای WETH در حال تعامل هستید.**
+
+
+
+
+
+- [شبکه اصلی اتریوم](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
+- [آربیتروم](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
+- [آپتیمیزم](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
+
+
+
+## ادامه مطلب {#further-reading}
+
+- [آیا WTF WETH است؟](https://weth.tkn.eth.limo/)
+- [اطلاعات توکن WETH در Etherscan](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
+- [تأیید رسمی WETH](https://zellic.io/blog/formal-verification-weth)
diff --git a/public/content/translations/fa/eips/index.md b/public/content/translations/fa/eips/index.md
index 4a3ee59815c..837e2604bfb 100644
--- a/public/content/translations/fa/eips/index.md
+++ b/public/content/translations/fa/eips/index.md
@@ -54,10 +54,18 @@ EIPها در کنار ارائه مشخصات فنی برای تغییرات،
اگر علاقهمند به مطالعه بیشتر راجع به EIPها هستید، به [وبسایت EIPها](https://eips.ethereum.org/)و[EIP-1](https://eips.ethereum.org/EIPS/eip-1) سر بزنید. تعدادی مرجع مفید برای مطالعه بیشتر:
-- [لیست تمام EIPها](https://eips.ethereum.org/all)
+- [فهرستی از هر پیشنهاد بهبود اتریوم](https://eips.ethereum.org/all)
- [توضیح تمام انواع EIPها](https://eips.ethereum.org/EIPS/eip-1#eip-types)
- [توضیح وضعیت تمام EIPها](https://eips.ethereum.org/EIPS/eip-1#eip-process)
+### پروژه های آموزش جامعه {#community-projects}
+
+- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — پروژه *PEEPanEIP یک مجموعه ویدیویی آموزشی است که در مورد پیشنهاد بهبود اتریوم (EIP) و ویژگیهای کلیدی ارتقاهای آینده بحث میکند.*
+- [EIPs For Nerds](https://ethereum2077.substack.com/t/eip-research) — پروژه *EIPs For Nerds مروری جامع و به سبک ELI5 از پیشنهادهای مختلف بهبود اتریوم (EIPها)، از جمله EIP های اصلی و EIP های لایه کاربردی/زیرساختی (ERC) برای آموزش خوانندگان و ایجاد اجماع در مورد تغییرات پیشنهادی در پروتکل اتریوم، ارائه میکند.*
+- [EIPs.wtf](https://www.eips.wtf/) — پروژه *EIPs.wtf اطلاعات اضافی برای پیشنهادهای بهبود اتریوم (EIPها)، از جمله وضعیت، جزئیات پیادهسازی، درخواستهای ادغام مرتبط، و بازخورد جامعه ارائه میدهد.*
+- [EIP.Fun](https://eipfun.substack.com/) — پروژه *EIP.Fun آخرین اخبار در مورد پیشنهادهای بهبود اتریوم (EIP)، بهروزرسانیهای جلسات EIP و موارد دیگر را ارائه میدهد.*
+- [EIPs Insight](https://eipsinsight.com/) — پروژه *EIPs Insight نمایشی از وضعیت فرآیند پیشنهادهای بهبود اتریوم (EIPs) و & آمار بر اساس اطلاعات جمع آوری شده از منابع مختلف است.*
+
## مشارکت کنید {#participate}
هر کسی میتواند یک EIP تهیه کند. پیش از ثبت یک پیشنهاد، باید[EIP-1](https://eips.ethereum.org/EIPS/eip-1) را مطالعه کنید که روند و نحوه نوشتن یک EIP را تشریح میکند، و درخواست بازخورد در [Ethereum Magicians](https://ethereum-magicians.org/) کنید، جایی که پیش از ارسل پیشنویس، پیشنهادها ابتدا با جامعه در میان گذاشته میشوند.
diff --git a/public/content/translations/fa/energy-consumption/index.md b/public/content/translations/fa/energy-consumption/index.md
index ff27405aefe..01ba4a77081 100644
--- a/public/content/translations/fa/energy-consumption/index.md
+++ b/public/content/translations/fa/energy-consumption/index.md
@@ -1,63 +1,65 @@
---
title: مصرف انرژی اتریوم
-description: اطلاعات بنیادینی که برای درک مصرف انرژی اتریوم نیاز دارید.
+description: اطلاعات پایه که برای درک مصرف انرژی اتریوم نیاز دارید.
lang: fa
---
-# توزیع انرژی اتریوم {#proof-of-stake-energy}
+# هزینه انرژی اتریوم {#proof-of-stake-energy}
-اتریوم یک بلاک چین سبز است. [سیستم اثبات گواه سهام](/developers/docs/consensus-mechanisms/pos)اتریم از مکانیسم اجماع به جای [انرژی، برای امنیت شبکه استفاده میکند](/developers/docs/consensus-mechanisms/pow). مصرف انرژی اتریوم تقریبا [0.0026 تن ترا وات ساعت در سال](https://carbon-ratings.com/eth-report-2022)در کل شبکه جهانی می باشد.
+اتریوم یک بلاک چین سبز است. [سیستم اثبات گواه سهام](/developers/docs/consensus-mechanisms/pos) اتریم از مکانیسم اجماع به جای [انرژی برای امنیت شبکه](/developers/docs/consensus-mechanisms/pow) استفاده میکند. مصرف انرژی اتریوم تقریبا [~0.0026 ترا وات ساعت در سال](https://carbon-ratings.com/eth-report-2022)در کل شبکه جهانی می باشد.
-مصرف انرژی اتریوم بر اساس اطلاعات بدست آمده از [CCRI ( موسسه نرخ کربن ارزدیجیتال)](https://carbon-ratings.com) تخمین زده شده است. آنها تخمین انرژی الکتریکی و کربن معادل آن را که در شبکه اتریوم مصرف شده است گزارش کرده اند، ([گزارش را بینید](https://carbon-ratings.com/eth-report-2022)). آنها مصرف برق گرههای مختلف را با سخت افزار ها و پیکربندیهای متفاوت نرمافزار کاربران اندازه گرفته اند. مقدار تخمینی **2601 مگاوات ساعت** (0.0026 تراوات ساعت) برای مصرف سالیانه برق شبکه منجر به کاهش مقدار دی اکسید کربن تولیدی به مقدار **870 تن** می باشد، که در آن از فاکتورهای منطقهای شدت کربن استفاده میشود. این مقدار با ورود و خروج گرهها به شبکه تغییر می کند، شما می توانید یک مقدار میانگین برای 7 روز را که توسط[شاخص پایداری شبکه بلاکچین کمبریج](https://ccaf.io/cbnsi/ethereum) انجام گرفته مورد بررسی قرار دهید (آنها از یک روش متفاوت برای تخمین استفاده کرده اند که جزئیات مطالعه آنها در سایتشان در دسترس می باشد).
+تخمین مصرف انرژی اتریوم بر اساس اطلاعات بدست آمده از [CCRI ( موسسه نرخ کربن ارز دیجیتال)](https://carbon-ratings.com) تخمین زده شده است. آنها حداقل و حداکثر برآوردهای مصرف برق و ردپای کربن شبکه اتریوم را تولید کردند ([گزارش را ببینید](https://carbon-ratings.com/eth-report-2022)). آنها مصرف برق گرههای مختلف را با سخت افزار ها و پیکربندیهای متفاوت نرمافزار کاربران اندازه گرفته اند. مقدار تخمینی **2601 مگاوات ساعت** (0.0026 تراوات ساعت) برای مصرف سالیانه برق شبکه منجر به کاهش مقدار دی اکسید کربن تولیدی به مقدار **870 تن** می باشد، که در آن از فاکتورهای منطقهای شدت کربن استفاده میشود. این مقدار با ورود و خروج گرهها به شبکه تغییر می کند، می توانید یک مقدار میانگین برای 7 روز را که توسط[شاخص پایداری شبکه بلاکچین کمبریج](https://ccaf.io/cbnsi/ethereum) تخمین زده شده، مورد بررسی قرار دهید (آنها از یک روش متفاوت برای تخمین استفاده کرده اند که جزئیات مطالعه آنها در سایتشان موجود است).
-برای مطالعه اتریوم در زمینه مصرف انرژی می توان مصرف سالیانه برخی دیگر از صنایع را مورد مقایسه قرار داد. این به ما کمک می کند که بهنر درک کنیم که آیا تخمین اتریوم زیاد است یا کم.
+برای درک بهتر از میزان مصرف انرژی شبکه اتریوم، میتوانیم آن را با سرانه تخمینی سالانه مصرف انرژی برخی محصولات و صنایع دیگر مقایسه کنیم. این به ما کمک می کند که بهنر درک کنیم که آیا تخمین اتریوم زیاد است یا کم.
-نمودار بالا مصرف سالانه انرژی اتریوم را در مقایسه با چندین صنعت دیگر در مقیاس ترا وات ساعت در سال نمایش می دهد. این تخمینهای ارائه شده، از منابع قابل دسترس عموم در ماه می سال 2023 بدست آمده اند که لینک این منابع در جدول زیر آمده است:
+نمودار زیر، تخمینی از میران مصرف انرژی شبکه اتریوم بر اساس ترا وات ساعت در سال را در مقایسه با تعدادی صنایع و محصولات دیگر نمایش میدهد. آمار فراهم شده بر اساس اطلاعات عمومی موجود در ژوئیه 2023 بوده و لینک منابع آنها نیز در جدول زیر قابل مشاهده است.
-| | مصرف انرژی سالانه (ترا وات ساعت در سال) | مقایسه با اتریوم گواه سهام | منبع |
-| :------------------ | :-------------------------------------: | :------------------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| مراکز داده جهانی | 200 | 77,000x | [منبع](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) |
-| استخراج طلا | 131 | 50,000x | [منبع](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| بیت کوین | 131 | 50,000x | [منبع](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| اتریوم PoW | 78 | 30,000x | [منبع](https://digiconomist.net/ethereum-energy-consumption) |
-| یوتیوب (فقط مستقیم) | 12 | 4600x | [منبع](https://www.gstatic.com/gumdrop/sustainability/google-2020-environmental-report.pdf) |
-| بازی در آمریکا | 34 | 13,000x | [منبع](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) |
-| نتفلیکس | 0.451 | 173x | [منبع](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
-| پی پال | 0.26 | 100x | [منبع](https://app.impaakt.com/analyses/paypal-consumed-264100-mwh-of-energy-in-2020-24-from-non-renewable-sources-27261) |
-| AirBnB | 0.02 | 8x | [منبع]() |
-| اتریوم PoS | 0.0026 | 1x | [منبع](https://carbon-ratings.com/eth-report-2022) |
+| | مصرف انرژی سالانه (ترا وات ساعت در سال) | مقایسه با اتریوم گواه سهام | منبع |
+|:------------------------ |:---------------------------------------:|:--------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| مراکز داده جهانی | 190 | 73,000x | [منبع](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) |
+| بیت کوین | 149 | 53,000x | [منبع](https://ccaf.io/cbnsi/cbeci/comparisons) |
+| استخراج طلا | 131 | 50,000x | [منبع](https://ccaf.io/cbnsi/cbeci/comparisons) |
+| بازی در ایالات متحده\* | 34 | 13,000x | [منبع](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) |
+| اتریوم PoW | 21 | 8,100x | [منبع](https://ccaf.io/cbnsi/ethereum/1) |
+| گوگل | 19 | 7,300x | [منبع](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) |
+| نتفلیکس | 0.457 | 176x | [منبع](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
+| پی پال | 0.26 | 100x | [منبع](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-(1).pdf) |
+| AirBnB | 0.02 | 8x | [منبع](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-(Final).pdf) |
+| **اتریوم PoS** | **0.0026** | **1x** | [منبع](https://carbon-ratings.com/eth-report-2022) |
-دستیابی به تخمین دقیقی از مصرف انرژی کار بسیار پیچیده ای می باشد، مخصوصا زمانی که آن چیزی که دارد اندازه گیری می شود دارای مجموعه ای از زنجیره ها با جزئیات بسیار زیاد باشد که روی بازده و کارایی آن تاثیر می گذارد. به عنوان مثال نت فلیکس و یوتیوب را در نظر بگیرید. تخمینهای مصرف انرژی بسته به این که فقط شامل انرژی استفاده شده برای حفظ سیستمهایشان و تحویل محتوا به کاربران هستند یا نه (_هزینه مستقیم_) یا این که آیا شامل هزینه لازم برای تولید محتوا، اداره دفاتر سازمانی، تبلیغات و غیره (_هزینه غیرمستقیم_) هستند یا نه، متغیرند. استفاده غیرمستقیم می تواند همچنین شامل انرژی لازم برای مصرف محتوا در دستگاههای کاربر نهایی مانند تلویزیون، کامپیوتر و موبایل باشد که در نتیجه به این بستگی دارد که در کدام دستگاهها مورد استفاده قرار می گیرد.
+\*شامل دستگاههای کاربران نهایی مانند رایانههای شخصی، لپتاپ، و کنسولهای بازی است.
-در این آدرس بحثی در این خصوص انجام گرفته است [خلاصه کربن](https://www.carbonbrief.org/factcheck-what-is-the-carbon-footprint-of-streaming-video-on-netflix). در جدول بالا مقدار گزارش شده برای نتفلیکس شامل مصرف _مستقیم_ و _غیر مستقیم_ توسط خود شرکت ارائه شده است. یوتیوب فقط تخمینی از مصرف _مستقیم_ انرژی را ارایه میکند که حدود [12 تراوات ساعت در سال](https://www.gstatic.com/gumdrop/sustainability/google-2020-environmental-report.pdf) است.
+دستیابی به تخمینهای دقیق درباره مصرف انرژی امری پیچیده است، به خصوص زمانی که آنچه که اندازهگیری میشود دارای زنجیره تامین پیچیده یا جزئیات پیادهسازی است که بر کارایی آن تأثیر میگذارد. برای مثال، تخمین مصرف انرژی شرکتهای نتفلیکس و گوگل بسته به اینکه فقط انرژی مصرف شده برای نگهداری سیستمهایشان و ارائه محتوا به کاربران (_هزینه مستقیم_) را شامل میشوند یا اینکه شامل هزینههای لازم برای تولید محتوا، اداره دفاتر شرکت، تبلیغات و غیره (_هزینه غیرمستقیم_) میشوند متفاوت است. هزینههای غیرمستقیم همچنین میتوانند شامل انرژی مورد نیاز برای مصرف محتوا در دستگاههای کاربر نهایی مانند تلویزیون، کامپیوتر و موبایل باشند.
-جدول و نمودار بالا فوق همچنین شامل مقایسه های بیت کوین و اتریوم اثبات کار است. نکته حائز اهمیت این است که انرژی مصرفی شبکههای اثبات کار یک عدد ثابت نیست و روز به روز مقدار آن تغییر می کند. مقدار مصرف شده برای اثبات کار اتریوم فقط از زمان قبل از [ادغام](/roadmap/merge/) تا اثبات سهامگذاری معتبر بود، طبق پیشبینی [Digiconomist](https://digiconomist.net/ethereum-energy-consumption). منابع دیگر مثل [شاخص پایداری شبکه بلاک چین کمبریج](https://ccaf.io/cbnsi/ethereum/1) تخمین می زنند که مقدار انرژی مصرفی بسیار پایین تر بوده است (نزدیک 20 ترا وات ساعت در سال). تخمین مصرف انرژی شبکه بیتکوین نیز بین منابع مختلف بسیار متفاوت است و موضوعی است که [بحث](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) آشکار فراوانی را باعث شده است، نه فقط درباره میزان انرژی مصرف شده، بلکه درباره منبع انرژی مربوطه و اصول اخلاقی مربوطه. مصرف انرژی لزوما تاثیر مشخصی روی محیط زیست ندارد چرا که پروژه های مختلف از منابع متفاوت انرژی استفاده می کنند، مثلا نسبت کمتر یا بیشتر از منابع تجدیدپذیر. برای مثال [شاخص مصرف برق بیتکوین کمبریج](https://ccaf.io/cbnsi/cbeci/comparisons) نشان میدهد که تقاضای شبکه بیتکوین به صورت تئوریک میتوانست توسط مشعلهای گاز یا برقی که قابلیت استفاده و توزیع ندارد تامین شود. اما اتریوم راه حل دیگری را به عنوان مصرف انرژی سبز برای شبکه خود معرفی کرده است.
+تخمینهای فوقالذکر مقایسه کاملی نیستند. مقدار مخارج غیرمستقیم محاسبه شده، بر اساس منبع متفاوت است و به ندرت شامل انرژی دستگاههای کاربر نهایی میشوند. هر منبع زیربنایی، شامل جزئیات بیشتر در مورد آنچه اندازهگیری میشود است.
-می توانید مصرف انرژی و انتشار کربن برای صنایع مختلف را در [سایت شاخص پایداری شبکه بلاک چین کمبریج](https://ccaf.io/cbnsi/ethereum)ببینید.
+جدول و نمودار بالا فوق همچنین شامل مقایسه های بیت کوین و اتریوم اثبات کار است. توجه به این نکته ضروری است که مصرف انرژی شبکههای اثبات کار ثابت نیست و روز به روز تغییر میکند. تخمینها نیز ممکن است بین منابع بهطور گسترده متفاوت باشند. این موضوع نه تنها در مورد میزان انرژی مصرفشده، بلکه در مورد منابع آن انرژی و اصول اخلاقی مرتبط با آن، [مباحثات](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) ظریف را به خود جلب میکند. مصرف انرژی لزوماً دقیقاً به ردپای محیطزیستی مربوط نمیشود زیرا پروژههای مختلف ممکن است از منابع انرژی متفاوت استفاده کنند، از جمله انرژیهای تجدیدپذیر با نسبت کمتر یا بیشتر. برای مثال، [شاخص مصرف برق بیتکوین دانشگاه کمبریج](https://ccaf.io/cbnsi/cbeci/comparisons) یعنی شاخص Cbeci نشان میدهد که تقاضای شبکه بیتکوین از نظر تئوری میتواند با سوخت گاز یا برق تامین شود که در غیر این صورت در انتقال و توزیع از بین میرود. راه حل اتریوم در مسیر پایداری، جایگزینی بخش نیازمندِ انرژیِ شبکه با یک گزینه سبز بود.
+
+مصرف انرژی و انتشار کربن برای صنایع مختلف را می توانید در [سایت شاخص پایداری شبکه بلاک چین کمبریج ](https://ccaf.io/cbnsi/ethereum) ببینید.
## تخمینهای قبل از تراکنش {#per-transaction-estimates}
-بسیاری از مقالهها، مصرف انرژی «قبل از تراکنش» را برای بلاک چینها تخمین می زنند. این روش ممکن است گمراهکننده باشد، چون انرژی لازم برای پیشنهاد و تایید کردن یک بلوک، به تعداد تراکنشهای داخل آن ربط ندارد. انرژی به ازا هر تراکنش به این معنی است که تراکنش کمتر یعنی مصرف انرژی کمتر و برعکس، که این درست نیست. همچنین تخمین انرژی به ازا تراکنش، بسیار به این ربط دارد که یک تراکنش بلاکچین چگونه تعریف می شود، و با بازی کردن با این تعریف می توان مقدار انرژی را بزرگ تر یا کوچکتر جلوه داد.
+بسیاری از مقالهها، مصرف انرژی «قبل از تراکنش» را برای بلاک چینها تخمین می زنند. این روش ممکن است گمراهکننده باشد، چون انرژی لازم برای پیشنهاد و تایید کردن یک بلوک، به تعداد تراکنشهای داخل آن ربط ندارد. یک واحد از هزینه انرژی در هر تراکنش به این معنی است که تراکنشهای کمتر منجر به هزینه کمتر انرژی می شود و بالعکس، که اینطور نیست. همچنین تخمین انرژی به ازا تراکنش، بسیار به این ربط دارد که تعداد دادههای ورودی یک تراکنش بلاکچین چگونه تعریف می شود، و با بازی کردن با این تعریف می توان مقدار انرژی را بزرگ تر یا کوچکتر جلوه داد.
-به عنوان مثال در اتریوم تعداد داده های ورودی تراکنش فقط به لایه اصلی خلاصه نمی شود، بلکه تمام تعداد داده های ورودی همه رول آپهای [لایه 2](/layer-2/) را نیز شامل می شود. لایه 2ها به صورت کلی در محاسبات لحاظ نمی شوند، اما در نظر گرفتن انرژی اضافی مصرف شده از سوی ترتیب سنجها ( کوچک) و تعداد تراکنشهای مورد پردازش آنها (بزرگ)، تخمینهای پیش از تراکنش را به صورت قابل ملاحظه کاهش می دهند. این یکی از دلایلی است که مقایسههای مصرف انرژی بر اساس تراکنش در پلتفترمها ممکن است گمراهکننده باشند.
+بهعنوان مثال، در اتریوم تعداد دادههای ورودی تراکنش فقط مربوط به لایه پایه نیست - بلکه مجموع دادههای ورودی تراکنش در تمام رولآپهای "[لایه 2](/layer-2/)" آن است. لایه 2ها به صورت کلی در محاسبات لحاظ نمی شوند، اما در نظر گرفتن انرژی اضافی مصرف شده از سوی ترتیب سنجها ( کوچک) و تعداد تراکنشهای مورد پردازش آنها (بزرگ)، احتمالا تخمینهای پیش از تراکنش را به صورت قابل ملاحظه کاهش می دهند. این فقط یکی از دلایلی است که چرا مقایسه مصرف انرژی در هر تراکنش بین پلتفرمها میتواند گمراهکننده باشد.
## بدهی کربن مربوط به اتریوم {#carbon-debt}
-مصرف انرژی اتریوم خیلی پایین است، اما این همیشه مورد مهم نیست. اتریوم اصلی بر پایه اثبات کار بود که هزینه محیطی خیلی بیشتری نسبت به مکانیسم فعلی اثبات سهام داشت.
+مصرف انرژی اتریوم خیلی پایین است، اما این همیشه مورد مهم نیست. اتریوم اصلی بر پایه اثبات کار بود که هزینه زیستمحیط خیلی بیشتری نسبت به مکانیسم فعلی اثبات سهام داشت.
-اتریوم از همان آغاز برنامه داشت که مکانیزم اجماع مبتنی بر اثبات سهام را پیاده سازی کند ولی این امر با در نظر گرفتن امنیت و غیر متمرکز نگه داشتن شبکه، نیاز به سالها تحقیق و توسعه داشت. بنابراین از مکانیسم اثبات کار برای راهاندازی شبکه استفاده شد. اثبات کار استخراجگرها را ملزم میکند که از سختافزار محاسباتیشان برای محاسبه یک مقدار استفاده کنند و این فرایند نیازمند انرژی است.
+اتریوم از همان آغاز برنامه داشت مکانیزم اجماع مبتنی بر اثبات سهام را پیاده سازی کند ولی انجام این امر بدون قربانی کردن امنیت و غیر متمرکز نگه داشتن شبکه، نیاز به سالها تحقیق و توسعه داشت. بنابراین از مکانیسم اثبات کار برای راهاندازی شبکه استفاده شد. اثبات کار استخراجگرها را ملزم میکند از سختافزار محاسباتیشان برای محاسبه یک مقدار استفاده کنند و این فرایند نیازمند انرژی است.
-![مقایسه مصرف انرژی اتریوم قبل و بعد از ادغام با استفاده از برج ایفل (330 متر ارتفاع) در سمت چپ برای سمبولیزه کردن مصرف انرژی بالا پیش از ادغام، و یک شکل لگوی کوچک 4 سانتیمتری در سمت راست به نشانه کاهش شدید مصرف انرژی پس از ادغام](energy_consumption_pre_post_merge.png)
+![مقایسه مصرف انرژی اتریوم قبل و بعد از ادغام با استفاده از برج ایفل (با 330 متر ارتفاع) در سمت چپ برای سمبولیزه کردن مصرف بالای انرژی پیش از ادغام، و یک شکل لگوی کوچک 4 سانتیمتری در سمت راست به نشانه کاهش شدید مصرف انرژی پس از ادغام](energy_consumption_pre_post_merge.png)
-انجمن CCRI تخمین میزند که میزان مصرف انرژی از زمان ادغام اتریوم به میزان **99.988%** کاهش پیدا کرده است. به طور مشابه، مقدار تولید کربن نیز در حدود **99.992 %** کاهش پیدا کرده است (از 11016000 تن به 870 تن دی اکسید کربن). برای مشابه سازی تقاوت در آلودگی تولید شده، شبیه به این است که از برج ایفل به یک اسباب بازی کوچک پلاستیکی تغییر داشته ایم، همانطور که در شکل بالا نشان داده شده است. به عنوان نتیجه، هزینه زیست محیطی تامین امنیت شبکه به صورت عجیبی کاهش پیدا کرده است. همزمان، اعتقاد بر این است که امنیت شبکه نیز ارتقا پیدا کرده است.
+موسسه CCRI تخمین میزند که ادغام، مصرف سالانه برق اتریوم را بیش از **99.988٪** کاهش داده است. به طور مشابه، مقدار تولید کربن نیز در حدود **99.992 %** کاهش پیدا کرده است (از 11016000 تن به 870 تن دی اکسید کربن). برای مشابه سازی کاهش در آلودگی تولید شده، شبیه به رفتن از برج ایفل به یک اسباب بازی کوچک پلاستیکی است، همانطور که در شکل بالا نشان داده شده است. به عنوان نتیجه، هزینه زیست محیطی تامین امنیت شبکه به صورت قابل توجه کاهش پیدا کرده است. همزمان، اعتقاد بر این است که امنیت شبکه نیز ارتقا پیدا کرده است.
## یک لایه سبز اپلیکیشن {#green-applications}
-در حالی که مصرف انرژی اتریوم بسیار اندک است، یک مجموعه قابل توجه، در حال رشد و بسیار فعال[**احیاکننده مالی (ReFi)**](/refi/) در بستر اتریوم وجود دارد. اپلیکیشنهای ReFi از اجزای DeFi برای ساخت اپلیکیشنهای مالی استفاده میکنند که اثرات خارجی مثبتی برای محیط زیست دارند. RiFi بخشی از یک شبکه گسترده تر به نام ["solarpunk"](https://en.wikipedia.org/wiki/Solarpunk) است که همراه با اتریوم حرکت می کند و هدف آن رشد تکنولوژیکی و نظارت محیط زیستی است. ویژگی هایی مثل غیر متمرکز بودن، عدم نیاز به اجازه و قابلیت ترکیب اتریوم، باعث شده است لایه پایه ایدهآل برای گروه های RiFi و solarpunk باشد.
+در حالی که مصرف انرژی اتریوم بسیار اندک است، یک مجموعه قابل توجه، در حال رشد و بسیار فعال[**احیاکننده مالی (ReFi)**](/refi/) در بستر اتریوم وجود دارد. برنامههای ReFi از اجزای DeFi برای ساخت برنامههای مالی استفاده میکنند که اثرات خارجی مثبتی برای محیط زیست دارند. RiFi بخشی از یک جنبش گسترده تر به نام ["solarpunk"](https://en.wikipedia.org/wiki/Solarpunk) است که با هماهنگی نزدیک با اتریوم حرکت می کند و هدف آن رشد تکنولوژیکی و نظارت محیط زیستی است. ویژگی هایی مثل غیر متمرکز بودن، عدم نیاز به اجازه و قابلیت ترکیب اتریوم، باعث شده است لایه پایه ایدهآل برای گروه های RiFi و solarpunk باشد.
-پلتفرمهای بومی Web3 برای تامین هزینه کالاهای عمومی مثل [Gitcoin](https://gitcoin.co) میزگردهای مربوط به اقلیم را برای تحریک اجتماع محیط زیستی در بستر لایه اپلیکیشن اتریوم را اجرا میکنند. به خاطر این ابتکارها (و موارد دیگر مثل [DeSci](/desci/)) اتریوم از جنبه محیط زیستی و اجتماعی در حال تبدیل شدن به یک تکنولوژی کاملا مثبت است.
+پلتفرمهای بومی Web3 برای تامین هزینه کالاهای عمومی مثل [Gitcoin](https://gitcoin.co) میزگردهای مربوط به اقلیم را برای تحریک ساخت سازگار با محیط زیست در لایه اپلیکیشن اتریوم، اجرا میکنند. به خاطر این ابتکارها (و موارد دیگر مثل [DeSci](/desci/)) اتریوم از جنبه محیط زیستی و اجتماعی در حال تبدیل شدن به یک تکنولوژی کاملا مثبت است.
اگر فکر میکنید این صفحه میتواند دقیقتر شود، لطفاً آن را در قالب یک مشکل یا درخواست مطرح کنید. آمار این صفحه بر اساس داده های عمومی می باشد. آنها نشاندهنده اعلام رسمی یا قول تیم ethereum.org یا بنیاد اتریوم نیستند.
@@ -69,7 +71,7 @@ lang: fa
- [گزارش کاخ سفید درباره اثبات کار بلاکچینها](https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
- [انتشارات اتریوم: یک برآورد پایین به بالا](https://kylemcdonald.github.io/ethereum-emissions/) - _ کیلی مک دونالد_
- [شاخص مصرف انرژی اتریوم](https://digiconomist.net/ethereum-energy-consumption/) – _Digiconomist_
-- [ETHMerge.com](https://ethmerge.com/) — *[@InsideTheSim](https://twitter.com/InsideTheSim)*
+- [ETHMerge.com](https://ethmerge.com/) — _[@InsideTheSim](https://twitter.com/InsideTheSim)_
- [ادغام - مفاهیم مصرف برق و میزان انتشار کربن در شبکه اتریوم](https://carbon-ratings.com/eth-report-2022) - _CCRI_
- [مصرف انرژی اتریوم](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8)
diff --git a/public/content/translations/fa/enterprise/index.md b/public/content/translations/fa/enterprise/index.md
new file mode 100644
index 00000000000..23e1f61976a
--- /dev/null
+++ b/public/content/translations/fa/enterprise/index.md
@@ -0,0 +1,199 @@
+---
+title: تشکیلات سازمانی بر بستر شبکه اصلی اتریوم
+description: راهنماها، مقالات و ابزارهایی درباره برنامه های کاربردی سازمانی در بلاک چین عمومی اتریوم
+lang: fa
+---
+
+# اتریوم برای سازمان {#ethereum-for-enterprise}
+
+اتریوم میتواند به انواع مختلف شرکتها، از جمله شرکتهای بزرگ کمک کند:
+
+- افزایش اعتماد و کاهش هزینه های هماهنگی بین طرف های تجاری
+- بهبود پاسخگویی شبکه تجاری و کارایی عملیاتی
+- مدل های کسب و کار جدید و فرصت های خالق ارزش بسازید
+- سازمان آنها به طور رقابتی آینده نگر است
+
+در سالهای اولیه، بسیاری از برنامههای بلاک چین سازمانی بر روی زنجیرههای بلاک چین یا کنسرسیوم سازگار با اتریوم با مجوز خصوصی ساخته شدند. امروزه، به لطف پیشرفتهای فناوری که توان عملیاتی بیشتر، هزینه تراکنش کمتر و حفظ حریم خصوصی را ممکن میسازد، اکثر برنامههای کاربردی سازمانی که از فناوری اتریوم استفاده میکنند بر روی شبکه اصلی اتریوم یا روی
+
+زنجیره لایه 2.
+
+
+
+
+## منابع {#enterprise-resources}
+
+
+
+### بیشتر بخوانید {#further-reading}
+
+منابع غیر فنی برای درک اینکه چگونه کسب و کارها می توانند از اتریوم بهره ببرند
+
+- [چرا بلاک چین برای تجارت و بیزینس مفید است؟](https://entethalliance.org/why-are-blockchains-useful-for-business/) - _ در خصوص ارزش بلاک چینها از طریق لنز پیشبینیپذیری بحث کنید_
+- [گزارش آمادگی تجاری سال 2023 اتحادیه اتریوم](https://entethalliance.org/eea-ethereum-business-readiness-report-2023/) - _پتانسیل و قابلیتهای اتریوم عمومی و اکوسیستم گستردهتر اتریوم برای کسبوکارها را بررسی میکند._
+- [_اتریوم برای کسب و کار_ نوشته پل برادی](https://www.uapress.com/product/ethereum-for-business/)، _یک راهنمای ساده به زبان انگلیسی برای موارد کاربردی است که بازدهی از مدیریت دارایی تا پرداختها و زنجیرههای تأمین را ایجاد میکند._
+
+
+
+### سازمانها {#organizations}
+
+برخی تلاشهای مشترک برای مورد پسند کردن اتریوم سازمانی توسط سازمانهای مختلف انجام شده است
+
+- [اتحادیه اتریوم برای کسبوکارها](https://entethalliance.org/) - اتحادیه اتریوم (EEA) به سازمانها کمک میکند تا فناوری اتریوم را در عملیات روزانه کسبوکار خود انتخاب و استفاده کنند. هدف آن، تسریع کسب و کار اتریوم از طریق پشتیبانی حرفهای و تجاری، حمایت و ترویج، تحقیقات، توسعه استانداردها و خدمات اعتماد اکوسیستم است.
+- [شورای جهانی تجارت بلاکچین (GBBC)](https://www.gbbc.io/) - اتحادیهای صنعتی برای اکوسیستم فناوری بلاکچین است. با جلب توجه سیاستگذاران و نظارتکنندگان، برگزاری رویدادها و بحثهای گسترده، و انجام تحقیقات، GBBC به ترویج بیشتر بلاکچین برای ایجاد جوامعی امنتر، عادلانهتر و کارآمدتر متعهد است.
+
+
+
+
+## منابع توسعه دهنده سازمانی {#enterprise-developer-resources}
+
+
+
+### محصولات و خدمات {#products-and-services}
+
+- [4EVERLAND](https://www.4everland.org/) - _ خدمات RPC و APIها و ابزارهایی را برای میزبانی برنامههای غیرمتمرکز و فعال کردن ذخیرهسازی غیرمتمرکز در اتریوم ارائه میدهد_
+- [Alchemy](https://www.alchemy.com/) - _خدمات و ابزارهای API را برای ساخت و نظارت بر برنامههای کاربردی در اتریوم ارائه میکند_
+- [Blast](https://blastapi.io/) - _یک پلتفرم API که APIهای RPC/WSS را برای شبکه اصلی بایگانی اتریوم و شبکههای آزمایشی فراهم میکند._
+- [Blockapps](https://blockapps.net/) - _اجرای پروتکل اتریوم سازمانی، ابزار و APIهایی که پلتفرم STRATO را تشکیل می دهند._
+- [Chainstack](https://chainstack.com/) - _شبکه اصلی و شبکه آزمایشی زیرساخت اتریوم که در ابرهای عمومی & مجزای مشتریان میزبانی میشود._
+- [ConsenSys](https://consensys.io/) - _طیف وسیعی از محصولات و ابزارها را برای ساخت بر روی اتریوم و همچنین خدمات مشاوره و توسعه سفارشی ارائه می کند._
+- [Crossmint](http://crossmint.com/) _پلتفرم توسعه Web3 درجه سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از APIها برای ایجاد، توزیع، فروش، ذخیره و ویرایش NFTها._
+- [Envision Blockchain](https://envisionblockchain.com/) - _خدمات مشاوره و توسعه متمرکز بر سازمان را با تخصص در شبکه اصلی اتریوم ارائه می دهد_
+- [EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _با صدور RFQ، قراردادها، سفارشات خرید و فاکتورها در سراسر شبکه شرکای تجاری مورد اعتماد شما، گردش کار تدارکات را فراهم می کند._
+- [Hyperledger Besu](https://www.hyperledger.org/use/besu) - _یک مشتری منبع باز اتریوم متمرکز بر سازمان که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است_
+- [Infura](https://infura.io/) - _دسترسی API مقیاس پذیر به شبکه های اتریوم و IPFS_
+- [Kaleido](https://kaleido.io/) - _یک پلتفرم توسعه متمرکز بر سازمان که برنامه های کاربردی ساده شده بلاک چین و دارایی های دیجیتال را ارائه می دهد_
+- [NodeReal](https://nodereal.io/) - _ارائه دهنده زیرساخت مقیاسپذیر بلاکچین و خدمات API برای اکوسیستم Web3_
+- [Moralis](http://moralis.io/) - _گرهها و APIهای درجه سازمانی با گواهینامه SOC2 نوع 2_
+- [Provide](https://provide.services/) - _میانافزار دانش صفر برای کسبوکارها_
+- [QuickNode](https://www.quicknode.com/) - _ارائه دهنده نودهای قابل اعتماد و سریع با API های سطح بالا مانند API NFT، API Token و غیره، همچنین ارائه مجموعهای یکپارچه از محصولات و راهکارهای متناسب با شرکتها_
+- [Tenderly](https://tenderly.co) - _یک پلت فرم توسعه Web3 که اشکال زدایی، مشاهده پذیری و بلوک های ساختمان زیرساخت را برای توسعه، آزمایش، نظارت و اجرای قراردادهای هوشمند فراهم می کند_
+- [Unbright](https://unibright.io/) - _تیمی از متخصصان، معماران، توسعه دهندگان و مشاوران بلاک چین با بیش از 20 سال تجربه در فرآیندهای تجاری و یکپارچه سازی_
+- [Zeeve](https://www.zeeve.io/) - _مجموعه ای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساخت و API برای برنامه های Web3 سازمانی ارائه می دهد._
+
+
+
+### ابزار و کتابخانه ها {#tooling-and-libraries}
+
+- [Baseline Project](https://www.baseline-protocol.org/) - _مجموعه ای از ابزارها و کتابخانه ها است که به شرکت ها کمک می کند تا فرآیندهای تجاری پیچیده و چند جانبه و گردش کار را با حفظ حریم خصوصی هماهنگ کنند و در عین حال داده ها را در سیستم های ثبت مربوطه نگهداری کنند. این استاندارد دو یا چند ماشین حالت را قادر میسازد تا با استفاده از یک شبکه بهعنوان یک چارچوب مرجع مشترک، سازگاری دادهها و تداوم گردش کار را به دست آورند و حفظ کنند._
+- [Chainlens](https://www.chainlens.com/) - _SaaS و پلتفرم داده و تجزیه و تحلیل بلاک چین اولیه از آزمایشگاههای Web3_
+- [Ernst & Young's 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _برنامه ای برای انتقال برنامه های ERC20، ERC721 و ERC1155 با دانش صفر، با استفاده از یک جمعبندی خوش بینانه_
+- [Truffle Suite](https://trufflesuite.com) - _مجموعه توسعه بلاک چین (ترافل، گاناش، دریزل)_
+
+
+
+### راه حل های مقیاس پذیری {#scalability-solutions}
+
+اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/لایه دوم) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
+
+
+
+## برنامههای کاربردی سازمانی در شبکه اصلی اتریوم فعال میشوند {#enterprise-live-on-mainnet}
+
+در اینجا برخی از برنامههای کاربردی سازمانی که بر روی شبکه عمومی اتریوم و لایه دوم توسط شرکتهای سنتی غیربلاک چین ساخته شدهاند، آورده شده است.
+
+
+
+### پرداختها {#payments}
+
+- [مرورگر بریو (Brave)](https://basicattentiontoken.org/) - _به کاربران برای توجه آنها به تبلیغات، بیسیک اتنشن توکن (BAT) پرداخت میکند و کاربران نیز میتوانند از طریق BAT برای حمایت از ناشران پرداخت انجام دهند_
+- [شهر لوگانو، سوئیس](https://bitcoinsuisse.com/news/city-of-lugano-accepts-crypto-payments) - _پرداخت مالیات و سایر خدمات شهری_
+- [اتریوم ادز](https://ethereumads.com/) - _به اپراتورهای وبسایت اجازه میدهد فضای تبلیغاتی را بفروشند و از طریق اتریوم پول دریافت کنند_
+- [hCaptcha](https://www.hcaptcha.com/) - _سیستم CAPTCHA پیشگیری از ربات که به اپراتورهای وبسایت برای کارهای انجام شده توسط کاربران برای برچسب زدن دادهها برای یادگیری ماشین پرداخت میکند. اکنون توسط Cloudflare مستقر شده است_
+- [Opera MiniPay](https://www.opera.com/products/minipay) - _پرداختهای موبایلی را برای مردم آفریقا از طریق کیف پول غیرسرپرستی در دسترستر و ایمنتر میکند و از شماره تلفنها برای تراکنش آسان_ استفاده میکند
+- [Roxpay ](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
+- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p /13560384) - _پرداختهای بین المللی با استیبل کوین_
+- [Toku](https://www.toku.com/) - _دستمزد، مدیریت کمک هزینه توکنی، رعایت مالیات، استخدام محلی، مزایا و & راهحلهای منابع انسانی توزیع شده_
+- [Xerof](https://www.xerof.com/) - _پرداختهای سریع و ارزان بینالمللی (برون مرزی) B2B را تسهیل میکند_
+
+
+
+### امور مالی {#finance}
+
+- [ABN AMRO](https://tokeny.com/tokeny-fuels-abn-amro-bank-in-tokenizing-green-bonds-on-polygon/) - _با توکنی، مسیرهای سبز توکن شده_
+- [Crowdz](https://crowdz.io/) - _پلتفرم امور مالی و فاکتورهای دریافتنیها_
+- [Mata Capital](https://consensys.io/blockchain-use-cases/finance/mata-capital) - _توکنسازی سرمایهگذاری در املاک و مستغلات_
+- [Obligate](https://www.obligate.com/) - _ اوراق قرضه زنجیرهای و اوراق تجاری تحت نظارت و احراز هویت_
+- [زیمنس](https://press.siemens.com/global/en/pressrelease/siemens-issues-first-digital-bond-blockchain) - _ صدور مسیر_
+- [سیلا](https://silamoney.com/) - _بانکداری و پرداختهای ACH به عنوان سرویس، با استفاده از یک استیبل کوین_
+- [Societe Generale FORGE](https://www.sgforge.com/product/bonds/) - _صدور مسیر_
+- [Taurus](https://www.taurushq.com/) - _ضمانتهای توکن شده صادر میکند_
+
+
+
+### توکنیزه کردن دارایی {#tokenization}
+
+- [AgroToken](https://agrotoken.io/en/) - _توکنسازی و معامله کالاهای کشاورزی_
+- [بیت باند (Bitbond)](https://www.bitbond.com/) - _صدور، تسویه و نگهداری داراییهای مالی را با توکنسازی بهبود میبخشد_
+- [بلاک اسکوئر (Blocksquare)](https://blocksquare.io/) - _زیرساخت توکنسازی برای املاک و مستغلات_
+- [سانتریفیوژ (Centrifuge)](https://centrifuge.io/) - _تامین مالی، بدهی و داراییهای دریافتنیهای توکن شده_
+- [کلیرمتیک (Clearmatics)](https://www.clearmatics.com) - _پلتفرمهای شبکه غیرمتمرکز را برای مبادله همتا به همتای ارزش توکن میسازد_
+- [dClimate](https://www.dclimate.net/) - _اکوسیستم اطلاعات آب و هوایی غیرمتمرکز_
+- [Fabrica](https://www.fabrica.land/) - _پلتفرمی برای دیجیتالی کردن داراییهای املاک و مستغلات، وامگیری دیفای و معامله دارایی_
+- [Fasset](https://www.fasset.com/) - _پلتفرمی برای پشتیبانی از زیرساختهای پایدار_
+- [نوری](https://nori.com/) - _زیرساخت بازار منبع باز برای امکان اندازهگیری و کسب درآمد از فعالیتهای پروژههای حذف کربن_
+- [پراپی (Propy)](https://propy.com/) - _پلتفرمی برای خودکارسازی معاملات املاک مسکونی با قراردادهای هوشمند_
+- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند. _
+- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد em>
+
+ - [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات< /em>
+
+ - [تالو (Thallo)](https://www.thallo.io/) - _پلتفرمی برای ادغام اعتبارات کربن دیجیتال در معاملات تجاری_
+- [Tokenchampions](https://tokenchampions.com/) - _حقوق تصویر بازیکنان فوتبال اروپا را توکنیزه میکند_
+
+
+
+### ثبت دادهها {#notarization-of-data}
+
+- [ ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _خبرگزاری ایتالیایی با اخبار جعلی مبارزه میکند و خوانندگان را قادر میسازد تا منشأ اخبار را با ضبط آنها در شبکه اصلی تأیید کنند_
+- [Breitling](https://www.coindesk.com/breitling-arianee-all-new-watches-ethereum) - _منشأ و تاریخچه تعمیر را در اتریوم ثبت میکند_
+- [BRØK](https://www.xn--brk-1na.no/) - _پلتفرم جداول کپ برای شرکتهای ثبت نشده در بورس عمومی توسط دولت نروژ ارائه شده است _
+- [گواهی](https://certifaction.com/) - _امضاهای الکترونیکی معتبر قانونی با حریم خصوصی-by-design_
+- [EthSign](https://ethsign.xyz/) - _اسناد الکترونیکی امضا شده را در بلاکچین اتریوم ثبت میکند_
+- [Stacktical](https://stacktical.com/) - _توسعه نرمافزار، صدور و امضای دیجیتالی قراردادهای سطح سرویس (SLA) را با قابلیتهای بومی فعال میکند_
+- [وریزون](https://decrypt.co/46745/verizon-news-press-releases-ethereum-full-transparency) - _گزارشهای مطبوعاتی را در اتریوم برای اطمینان از مسئولیت پذیری و اعتماد شرکت نشان میدهد_
+- [ولف تون](https://www.mef.net/edge-view-blog/automated-secure-timely-sla-reporting-is-finally-a-reality/) - _توسط MEF و مدیریت Sage گزارشدهی توافقنامه سطح خدمات بین شرکتهای مخابراتی را خودکار میکند_
+
+
+
+### زنجیره تامین {#supply-chain}
+
+- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using -ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
+- [کارگوایکس](https://cargox.io/) - _ارائهدهنده بارنامه الکترونیکی و انتقال اسناد برای حمل و نقل_
+- [Circularize](https://www.circularise.com/) - _یک راهحل ردیابی سرتاسر برای مواد خام ساخته شده در محصولات است_
+- [مدیر قرارداد EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _شرکتها را قادر میسازد تا در جریان کاری تدارکات، صدور RFQ، قراردادها، سفارشها خرید و فاکتورها در شبکهای از شرکای تجاری شرکت کنند_
+- [ماین اسپایدر](https://www.minespider.com/) - _ردیابی و منشأ زنجیره تامین و ردیابی انتشار CO2_
+- [Morpheus.network](https://morpheus.network/) - _پلتفرم اتوماسیون زنجیره تامین_
+- [StaTwig](https://statwig.com/) - _عملیات زنجیره تامین_
+- [TradeTrust](https://www.tradetrust.io/) - _بارنامههای الکترونیکی (eBLs) را برای حمل و نقل بین المللی تأیید میکند_
+- [Transmute](https://transmute.industries/) - _پلتفرم تبادل داده برای معامله جهانی؛ از تراکنشهای با هویت غیرمتمرکز در اتریوم_ پشتیبانی میکند
+
+
+
+### بیمه {#insurance}
+
+- [آربول (Arbol)](https://www.arbolmarket.com/) - _بیمه پارمتریک برای پوشش خطرات مربوط به آب و هوا_
+- [Etherisc](https://etherisc.com/) - _بیمه غیرمتمرکز برای انواع خطرات_
+- [Nayms](https://www.nayms.com/) - _یک فضای دیجیتال برای ایجاد برنامههای بیمه، افزایش و معامله سرمایه، نوشتن ریسک و ریلهای پرداخت برای تراکنشهای حق بیمه و ادعا، ساخته شده با AON_
+
+
+
+### هویت، اعتبار و گواهینامه {#credentials}
+
+- [BCdiploma](https://www.bcdiploma.com/) - _دیپلمها، گواهیها و مدارک خرد را دیجیتالی و تأیید میکند_
+- [مدارک هایلند](https://www.hylandcredentials.com) - _دیپلمهای دیجیتال و سایر مدارک تحصیلی، مجوزها و گواهینامهها_
+- [برنامه اقامت دیجیتال پالائو](https://rns.id/) - _به شهروندان جهانی این امکان را میدهد که کارت شناسایی قانونی صادر شده توسط دولت پالائو داشته باشند em>
+
+ - [Spherity](https://www.spherity.com/) - _راهحلهای مدیریت هویت دیجیتال را برای ایجاد اعتماد دیجیتال در اکوسیستمها، با تمرکز بر هویتهای غیرمتمرکز و اعتبار قابل تأیید ارائه میدهد_
+- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
+
+
+
+### سرگرمی، NFT و وفاداری
+
+- [چرخ دنده مجازی آدیداس (Adidas Virtual Gear)](https://www.adidas.com/metaverse) - _مجموعه NFT چرخ دنده مجازی_
+- [سندباکس موزه بریتانیا](https://decrypt.co/150405/british-museum-enter-metaverse-via-sandbox) - _یک مجموعه توکن غیرقابل تعویض_
+- [Fruitlab](https://fruitlab.com/) - _پلتفرمی برای گیمرها برای کسب درآمد از تماشا، اشتراکگذاری و بازیهای آنلاین_
+- [Nike Swoosh](https://www.swoosh.nike/) - _یک پلتفرم انافتی_
+- [متاورس سوثبیز](https://metaverse.sothebys.com/) - _یک بازار دیجیتال هنر NFT توسط Sothebyها_
+
+اگر میخواهید به این فهرست اضافه کنید، لطفاً به [دستورالعملهای مشارکت](/contributing/) مراجعه کنید.
diff --git a/public/content/translations/fa/enterprise/private-ethereum/index.md b/public/content/translations/fa/enterprise/private-ethereum/index.md
new file mode 100644
index 00000000000..5992f822f04
--- /dev/null
+++ b/public/content/translations/fa/enterprise/private-ethereum/index.md
@@ -0,0 +1,26 @@
+---
+title: اتریوم خصوصی برای تشکیلات سازمانی
+description: منابعی برای اپلیکیشن تشکیلات سازمانی بر بستر بلاک چین های خصوصی اتریوم.
+lang: fa
+---
+
+# اتریوم خصوصی برای تشکیلات سازمانی {#private-ethereum-for-enterprise}
+
+اپلیکیشن های بلاک چین تشکیلات سازمانی میتوانند بر روی شبکه اصلی اتریوم بدون مجوز عمومی یا بر روی بلاک چین های خصوصی که مبتنی بر فناوری اتریوم هستند ساخته شوند. برای اطلاعات بیشتر در مورد ساخت اپلیکیشن بر بستر شبکه عمومی اصلی اتریوم، به [شبکه اصلی اتریوم برای شرکتها](/enterprise/) مراجعه کنید.
+
+## منابع توسعه دهندگان برای تشکیلات سازمانی اتریوم {#developer-resources-private-enterprise-ethereum}
+
+### سازمانها {#organisations}
+
+برخی از تلاشهای مشترک برای مورد پسند کردن تشکیلات سازمانی اتریوم توسط سازمانهای مختلف انجام شده است:
+
+- [اتحادیه تشکیلات سازمانی اتریوم](https://entethalliance.org/) EEA سازمانها را قادر میسازد تا فناوری اتریوم را در عملیات تجاری روزانه خود بپذیرند و از آن استفاده کنند. ما اکوسیستم اتریوم را برای ایجاد فرصتهای تجاری جدید، تشویق به پذیرش صنعت، و یادگیری و همکاری با یکدیگر توانمند میکنیم.
+- [Hyperledger](https://hyperledger.org) _Hyperledger یک تلاش مشترک منبع باز است که برای پیشرفت فناوریهای بلاک چین بینصنعتی ایجاد شده است. این یک همکاری جهانی است که توسط بنیاد لینوکس میزبانی می شود، از جمله رهبران امور مالی، بانکداری، اینترنت اشیا، زنجیره تامین، تولید و فناوری. این بنیاد پروژههایی در خود دارد که با پشته اتریوم کار میکنند، از جمله [Besu](https://www.hyperledger.org/use/besu)._
+
+### پروتکل و زیرساخت {#protocol-and-infrastructure}
+
+- [Chainstack](https://chainstack.com/) _پلتفرم میان ابری و چند پروتکلی بهعنوان سرویسی که به کسبوکارها اجازه میدهد تا به سرعت، استقرار و مدیریت شبکه ها و سرویس های غیرمتمرکز را ایجاد کنند_
+- [Clearmatics Autonity](https://www.clearmatics.com/about/) _مجموعه پروتکلهایی که پروتکلهای p2p را پیادهسازی میکند و اپلیکیشن و زیرساخت کلاینت را ارائه میکند_
+- [هایپرلجر بسو](https://www.hyperledger.org/use/besu) _کاربر منبع باز اتریوم که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است که شامل چندین الگوریتم اجماع از جمله اثبات کار و اثبات قدرت است (IBFT، IBFT 2.0، Ethash و Clique). طرح های مجوز جامع آن به طور خاص برای استفاده در یک محیط کنسرسیوم طراحی شده است._
+- [Kaleido](https://kaleido.io/) _پلتفرم فول-استک برای ساخت و اجرای اکوسیستمهای تشکیلات اقتصادی ترکیبی میان ابری_
+- [Zeeve](https://www.zeeve.io/) _مجموعهای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساختها و APIهای سازمانی برنامه های Web3 ارائه میکند_
diff --git a/public/content/translations/fa/foundation/index.md b/public/content/translations/fa/foundation/index.md
new file mode 100644
index 00000000000..f79f30dff9d
--- /dev/null
+++ b/public/content/translations/fa/foundation/index.md
@@ -0,0 +1,40 @@
+---
+title: بنیاد اتریوم
+description: درباره بنیاد اتریوم (EF) بیشتر بدانید که یک سازمان غیرانتفاعی است که وقف حمایت از اتریوم و فن آوری های مرتبط با آن است.
+hideEditButton: true
+lang: fa
+---
+
+# درباره بنیاد اتریوم {#about-the-ethereum-foundation}
+
+
+
+[بنیاد اتریوم](http://ethereum.foundation/)(EF) یک سازمان غیرانتفاعی است که وقف حمایت از [اتریوم](/what-is-ethereum/) و فن آوری های مرتبط با آن است.
+
+بنیاد اتریوم یک شرکت و یا حتی یک سازمان غیرانتفاعی سنتی نیست. نقش بنیاد، رهبری یا کنترل اتریوم نیست، و حتی بنیاد تنها نهادی نیست که به تامین مالی توسعه فن آوری های مرتبط با اتریوم میپردازد. بنیاد اتریوم بخشی از [اکوسیستمی](/community/) بسیار بزرگتر است.
+
+## ابتکارات بنیاد اتریوم {#ethereum-foundation-initiatives}
+
+### برنامه حمایت اکوسیستم {#ecosystem-support-program}
+
+[برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/) برای شتابدهی به رشد اکوسیستم، برای پروژه ها و افراد فعال در جامعه اتریوم حمایت مالی و غیر مالی فراهم میکند. برنامه پشتیبانی اکوسیستم نسخه ای گسترش داده شده از برنامه حمایت مالی اتریوم است که بر حمایت مالی از اکوسیستم تمرکز داشت.
+
+درباره برنامه پشتیبانی اتریوم، دریافت کنندگان قبلی پشتیبانی، و روند درخواست کمک هزینه در [esp.ethereum.foundation](https://esp.ethereum.foundation/) اطلاعات بیشتر دریافت کنید. همچنین برای آگاهی از آخرین اخبار و اطلاعیه ها میتوانید [ وبلاگ برنامه پشتیبانی اکوسیستم](https://blog.ethereum.org/category/ecosystem-support-program/) و یا [@EF_ESP](https://twitter.com/EF_ESP) را دنبال کنید.
+
+### Devcon {#devcon}
+
+از سال 2014، بنیاد اتریوم کنفرانس سالانه دِوکان، را برای تمام توسعه دهندگان، محققان، اندیشمندان و سازندگان اکوسیستم اتریوم برگزار میکند.
+
+شما میتوانید در [archive.devcon.org](https://archive.devcon.org/) به تمام محتوای ویدیویی مطالب ارائه شده در هر کنفرانس از زمان پیدایش آن دسترسی پیدا کنید.
+
+برای اطلاعات بیشتر، نگاه کنید به [devcon.org](https://devcon.org/)، و نگاهی به [وبلاگ دِوکان](https://devcon.org/en/blogs/) بیندازید، یا برای اخرین اطلاعیه ها، صفحه[@efdevcon](https://twitter.com/EFDevcon) را دنبال کنید.
+
+### برنامه فلوشیپ {#fellowship-program}
+
+[برنامه فلوشیپ بنیاد اتریوم](https://fellowship.ethereum.foundation/) ابتکاری است برای از بین بردن شکاف بین فرهنگ ها، ملت ها و طبقات اقتصادی مختلف. برنامه فلوشیپ بنیاد اتریوم با شناسایی و حمایت از افراد منحصر به فرد و بااستعداد باعث کوچک کردن این شکاف طبقاتی میشود، و موانع ورود برای افراد و جوامعی را که نمایندگان کمتری دارند که آینده Web3 را بسازند، از بین میبرد.
+
+[در fellowship.ethereum.foundation مطالب بیشتر را ببینید](https://fellowship.ethereum.foundation/).
+
+
+
+برای اطلاع بیشتر در مورد بنیاد و حوزه کاری آن، سایت [ethereum.foundation](http://ethereum.foundation/) را ببینید، و یا سری به [وبلاگ بنیاد اتریوم](https://blog.ethereum.org/) بزنید تا از اخرین اخبار بنیاد آگاه شوید.
diff --git a/public/content/translations/fa/governance/index.md b/public/content/translations/fa/governance/index.md
index fb42439d4e2..4234ad9c017 100644
--- a/public/content/translations/fa/governance/index.md
+++ b/public/content/translations/fa/governance/index.md
@@ -48,7 +48,7 @@ _گرچه در لایهی پروتکل حاکمیت اتریوم برون
- **اپراتورهای گره**: این افراد گرههایی را اجرا میکنند که بلوکها و تراکنشها را پخش میکنند و هر تراکنش یا بلوک نامعتبری که ظاهر میشود را رد میکنند. [درباره گرهها بیشتر بدانید](/developers/docs/nodes-and-clients/).
- **نویسندگان EIP**: این افراد پیشنهادهایی را برای تغییر پروتکل اتریوم در قالب پیشنهادهای بهبود اتریوم (EIPها) ارائه میدهند. [درباره EIP بیشتر بدانید](/eips/).
- **اعتبارسنج ها**: این افراد گره هایی را اجرا می کنند که می توانند بلوک های جدید را به زنجیره بلوکی اتریوم اضافه کنند.
-- **توسعهدهندگان پروتکل** (همان «توسعهدهندگان هستهای»): این افراد پیادهسازیهای مختلف اتریوم را نگهداری میکنند (مثل go-ethereum، Nethermind، Besu و Erigon در لایهی اجرا یا Prysm، Lighthouse، Nimbus، Teku و Lodestar در لایهی وفاق). [درباره کلاینتهای اتریوم بیشتر بدانید](/developers/docs/nodes-and-clients/).
+- **توسعهدهندگان پروتکل** (همان "توسعه دهندگان اصلی"): این افراد توسعه اجراهای مختلف اتریوم را در دست دارند (به عنوان مثال go-ethereum و Nethermind و Besu و Erigon و Reth در لایه اجرا یا Prysm و Lighthouse و Nimbus و Teku و Lodestar در لایه اجماع). [درباره کلاینتهای اتریوم بیشتر بدانید](/developers/docs/nodes-and-clients/).
_یادداشت: هر فردی میتواند عضوی از چند گروه مختلف باشد (مثلا یک توسعهدهندهی پروتکل میتواند EIP را نگهداری کند، و یک اعتبارسنج زنجیرهی بیکن را اجرا کند و از یک برنامهی DeFi استفاده کند). برای شفافیت مفهومی، بهتر است که آنها را از هم جدا کنیم._
@@ -120,7 +120,7 @@ _یادداشت: هر فردی میتواند عضوی از چند گروه
فورک DAO در واکنش به [حملهی DAO در سال 2016](https://www.coindesk.com/understanding-dao-hack-journalists) رخ داد که در آن در یک هک، یک قرارداد [DAO](/glossary/#dao) ناامن از بیش از 3.6 میلیون اتر تخلیه شد. این فورک سرمایهها را از قرارداد مشکلدار به یک قرارداد جدید منتقل کرد و به همهی کسانی که در هک سرمایه از دست داده بودند اجازه داد که آن را بازگردانند.
-این کار توسط جامعهی اتریوم رأیگیری شد. هر دارندهی اتر میتوانست از طریق یک تراکنش در یک [سکوی رأیگیری](http://v1.carbonvote.com/) رأی بدهد. تصمیم انجام فورک بیشتر از 85% از آرا را به خود اختصاص داد.
+این کار توسط جامعهی اتریوم رأیگیری شد. هر دارندهی اتر میتوانست از طریق یک تراکنش در یک [سکوی رأیگیری](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/) رأی بدهد. تصمیم انجام فورک بیشتر از 85% از آرا را به خود اختصاص داد.
لازم به ذکر است با اینکه پروتکل فورک کرد تا هک را برگرداند، تعداد آرا برای تصمیمگیری دربارهی فورک کردن به چند دلیل قابل بحث است:
@@ -174,7 +174,7 @@ _یادداشت: هر فردی میتواند عضوی از چند گروه
حاکمیت در اتریوم تعریف دشواری ندارد. مشارکتکنندگانِ جوامع مختلف دیدگاههای مختلفی دربارهی آن دارند. چند نمونه از آنها در ادامه ذکر شده است:
-- [یادداشتهایی درباره ی حاکمیت زنجیرهی بلوکی](https://vitalik.eth.limo/general/2017/12/17/voting.html) - _ویتالیک بوترین_
+- [یادداشتهایی درباره حاکمیت بلاکچین](https://vitalik.eth.limo/general/2017/12/17/voting.html) - _ویتالیک بوترین_
- [حاکمیت اتریوم چگونه کار میکند؟](https://cryptotesters.com/blog/ethereum-governance) - _Cryptotesters_
- [چگونگی کارکرد حاکمیت اتریوم](https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a) - _میکا زولتو_
- [توسعهدهنده اصلی اتریوم چیست؟](https://hudsonjameson.com/2020-06-22-what-is-an-ethereum-core-developer/) - _هادسون جیمز_
diff --git a/public/content/translations/fa/nft/index.md b/public/content/translations/fa/nft/index.md
index 1051156630e..8989820ca83 100644
--- a/public/content/translations/fa/nft/index.md
+++ b/public/content/translations/fa/nft/index.md
@@ -8,66 +8,66 @@ sidebarDepth: 2
image: /images/infrastructure_transparent.png
alt: لوگوی اتر که با هولوگرام نمایش داده شده است.
summaryPoint1: راهی برای نمایش دادن هر چیز بیهمتا بهعنوان یک دارایی مبتنی بر اتریوم.
-summaryPoint2: NFTها بیش از هر زمان دیگر به تولیدکنندگان محتوا قدرت میدهند.
+summaryPoint2: 'NFTها بیش از هر زمان دیگر به تولیدکنندگان محتوا قدرت میدهند.'
summaryPoint3: با پشتیبانی قراردادهای هوشمند روی زنجیره بلوکی اتریوم.
---
## NFTها چه هستند؟ {#what-are-nfts}
-NFTها هریک به صورت جداگانه توکنهای **منحصربهفردی** هستند. هر NFT ویژگی های متفاوتی دارد (غیرقابل معاوضه) و این دلیلی بر کمیاب بودن آن است. این با توکنهایی مانند [ETH](/glossary/#ether) یا سایر توکنهای مبتنی بر اتریوم مانند USDC که در آن هر توکن یکسان است و ویژگیهای یکسانی دارد ("قابلتعویض") متفاوت است. برای شما مهم نیست که کدام اسکناس دلار (یا اتریوم) را در کیف پول خود داشته باشید زیرا همه آنها یکسان هستند و ارزش یکسانی دارند. با این حال، شما به نوع NFT تحت مالکیتتان _اهمیت_ میدهید، زیرا هر کدام از آنها مشخصات متفاوتی دارند که آنها را نسبت به بقیه متمایز میکنند (معاوضهناپذیر).
+NFTها توکنهایی هستند که **منحصربهفرد** هستند. هر NFT ویژگی های متفاوت (غیرقابل معاوضه) دارد و به صورت قابل اثبات کمیاب است. این با توکنهایی مانند [ETH](/glossary/#ether) یا سایر توکنهای مبتنی بر اتریوم مانند USDC که در آن هر توکن یکسان است و ویژگیهای یکسان («قابلمعاوضه») دارد متفاوت است. برای شما مهم نیست که کدام اسکناس دلار (یا اتریوم) را در کیف پول خود داشته باشید زیرا همه آنها یکسان هستند و ارزش یکسان دارند. با این حال، شما به نوع NFT تحت مالکیتتان اهمیت _میدهید_، زیرا هر کدام از آنها مشخصات متفاوت دارند که آنها را نسبت به بقیه متمایز میکنند (معاوضهناپذیر).
-منحصربهفرد بودن هر NFT امکان توکنیزه کردن چیزهایی مانند آثار هنری، اشیاء کلکسیونی یا حتی املاک و مستغلات را فراهم میکند؛ به این صورت یک NFT منحصربهفرد نمودی از برخی اقلام خاص در دنیای واقعی یا اقلام دیجیتال است. مالکیت یک دارایی به صورت عمومی در [بلاکچین](/glossary/#blockchain) اتریوم قابل تأیید است.
+منحصربهفرد بودن هر NFT امکان توکنیزه کردن چیزهایی مانند آثار هنری، اشیاء کلکسیونی یا حتی املاک و مستغلات را فراهم میکند؛ در این حالت، یک NFT منحصربهفرد نمودی از برخی اقلام خاص در دنیای واقعی یا اقلام دیجیتال است. مالکیت یک دارایی به صورت عمومی در [بلاکچین](/glossary/#blockchain) اتریوم قابل تأیید است.
## اینترنت دارایی ها {#internet-of-assets}
-NFTها و اتریوم برخی از مشکلات موجود در اینترنت امروزی را حل میکنند. هرچه همه چیز دیجیتالیتر میشود، تکثیر ویژگیهای موجودیتهای فیزیکی مانند کمیت محدود، یکتایی و اثبات مالکیت ضرورت پیدا میکند به نحوی که تحت کنترل یک سازمان مرکزی قرار نگیرد. به عنوان مثال، با NFTها، میتوانید یک فایل mp3 موسیقی را در تمامی برنامههای مبتنی بر اتریوم داشته باشید و به یک برنامه موسیقی خاص مانند اسپاتیفای یا اپل موزیک وابسته نباشید. شما میتوانید یک دسته رسانه اجتماعی داشته باشید که میتوانید آن را بفروشید یا تعویض کنید، اما توسط ارائهدهنده پلتفرم **نمیتواند خودسرانه از شما سلب شود**.
+NFTها و اتریوم برخی از مشکلات موجود در اینترنت امروزی را حل میکنند. هرچه همه چیز دیجیتالیتر میشود، تکثیر ویژگیهای اقلام فیزیکی مانند تعداد محدود، یکتایی و اثبات مالکیت به نحوی که تحت کنترل یک سازمان مرکزی قرار نگیرد، ضرورت پیدا میکند. به عنوان مثال، با NFTها، میتوانید یک فایل mp3 موسیقی را در همه برنامههای مبتنی بر اتریوم داشته باشید و به یک برنامه موسیقی خاص مانند Spotify یا Apple Music وابسته نباشید. میتوانید یک نام کاربری رسانه اجتماعی داشته باشید که میتوانید آن را بفروشید یا معاوضه کنید، ولی ارائهدهنده پلتفرم **نمیتواند خودسرانه آن را از شما بگیرد**.
اینترنت NFTها در مقایسه با اینترنت امروزی که اکثر ما استفاده می کنیم چنین به نظر میرسد...
### یک مقایسه {#nft-comparison}
-| اینترنت یک توکن غیرمثلی | اینترنت امروزی |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **مالک داراییهای خود هستید!** فقط شما میتوانید آنها را بفروشید یا عوض کنید. | **یک دارایی را اجاره میکنید** از برخی سازمانها و ممکن که از شما پس گرفته شود. |
-| NFTها **یگانگی دیجیتالی** دارند، هیچ کدام از NFT ها مثل دیگری نیست. | **نسخه کپی را گاهی نمیتوان از نسخه اصلی تشخیص داد**. |
-| مالکیت یک NFT روی بلاکچین ذخیره شده تا هر کسی بتواند آن را **عموماً تایید کند**. | دسترسی به سوابق مالکیت اقلام دیجیتال **توسط موسسات کنترل میشود** - شما باید حرف آنها را قبول کنید. |
-| NFTها [قردادهای هوشمند](/glossary/#smart-contract) روی اتریوم هستند. بدین معنا که **استفاده آسان از آنها در دیگر قراردادهای هوشمند** و اپهای روی اتریوم امکانپذیر است! | شرکتهای دارای اقلام دیجیتال معمولاً **به زیرساخت "اکوسیستم بسته" خود نیاز دارند**. |
-| **تولیدکنندگان محتوا میتوانند آثار خود را در هر جایی بفروشند** و میتوانند به بازار جهانی دسترسی داشته باشند. | سازندگان به زیرساخت و توزیع پلتفرمهایی که ازشان استفاده میکنند متکی هستند. این موارد اغلب مشمول شرایط استفاده و **محدودیتهای جغرافیایی** هستند. |
-| سازندگان NFT **میتوانند حقوق مالکیت را بر کار خود حفظ کنند** و حق امتیاز را مستقیماً در قرارداد NFT برنامهریزی کنند. | پلتفرمهایی مانند **سرویسهای استریم موسیقی، بیشترین سود حاصل از فروش را در اختیار دارند**. |
+| یک اینترنت NFT | اینترنت امروزی |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| **مالک داراییهای خود هستید!** فقط شما میتوانید آنها را بفروشید یا معاوضه کنید. | از برخی سازمانها **یک دارایی را اجاره میکنید** که ممکن است از شما پس گرفته شود. |
+| NFTها **یگانگی دیجیتالی** دارند، هیچ کدام از NFT ها مثل دیگری نیست. | **نسخه کپی را گاهی نمیتوان از نسخه اصل تشخیص داد**. |
+| مالکیت یک NFT روی بلاکچین ذخیره شده است تا هر کس بتواند آن را **عموماً تایید کند**. | دسترسی به سوابق مالکیت اقلام دیجیتال **توسط موسسات کنترل میشود** - شما باید حرف آنها را قبول کنید. |
+| NFTها [قراردادهای هوشمند](/glossary/#smart-contract) روی اتریوم هستند. بدین معنا که **استفاده آسان از آنها در دیگر قراردادهای هوشمند** و اپهای روی اتریوم امکانپذیر است! | شرکتهای دارای اقلام دیجیتال معمولاً **به زیرساخت "محدوده بسته" خود نیاز دارند**. |
+| **تولیدکنندگان محتوا میتوانند آثار خود را در هر جا بفروشند** و میتوانند به بازار جهانی دسترسی داشته باشند. | سازندگان به زیرساخت و توزیع پلتفرمهایی که ازشان استفاده میکنند متکی هستند. اینها اغلب مشمول شرایط استفاده و **محدودیتهای جغرافیایی** هستند. |
+| سازندگان NFTها **میتوانند حقوق مالکیت را بر کار خود حفظ کنند** و حق امتیاز را مستقیماً در قرارداد NFT برنامهریزی کنند. | پلتفرمهایی مانند **سرویسهای پخش آنلاین موسیقی، بیشترین سود حاصل از فروش را در اختیار دارند**. |
## NFTها برای چه مواردی مورد استفاده قرار میگیرند؟ {#nft-use-cases}
NFTها کاربرد بسیاری دارند، از جمله:
- اثبات اینکه شما در یک رویداد شرکت کرده اید
-- گواهی میدهد که شما یک دوره ای را گزرانده اید
-- دارایی ها دیجیتال شما در بازی ها
+- گواهی میدهد که شما یک دوره را گذرانده اید
+- اقلام قابل مالکیت در بازیها
- اثر هنری دیجیتال
- توکنیزه کردن دارایی های جهان واقعی
- اثبات هویت دیجیتالی شما
- دریچه دسترسی به محتوا
-- صدور بلیط
+- صدور بلیت
- نام دامنه های اینترنتی غیرمتمرکز
- وثیقه در [امورمالی غیرمتمرکز](/glossary/#defi)
-شاید شما هنرمندی هستید که میخواهید با استفاده از NFT، و بدون از دست دادن کنترل و سودتان به واسطهها، آثارتان را به اشتراک بگذارید. میتوانید قرارداد هوشمند جدیدی بسازید و تعداد NFTها، مشخصات آنها و لینک ورود به برخی آثار هنری خاص را مشخص کنید. بهعنوان هنرمند، **میتوانید امتیازهایی که باید به شما پرداخت شود را در قرارداد هوشمند برنامهریزی کنید** (مثلاً هر بار که NFT معامله میشود 5٪ از قیمت فروش به صاحب قرارداد منتقل شود). همچنین همیشه میتوانید ثابت کنید که شما NFTها را تولید کردهاید، زیرا مالک [کیف پولی](/glossary/#wallet) هستید که قرارداد را منتشر کرده است. خریداران شما بهراحتی میتوانند ثابت کنند که دارای **NFT معتبر** متعلق به مجموعه شماست زیرا [آدرس](/glossary/#address) کیفپول آنها با یک رمز در قرارداد هوشمند شما مرتبط است. آنها میتوانند از آن در سراسر اکوسیستم اتریوم استفاده کنند و ضمناً از بابت اصالت آن خیالشان آسوده باشد.
+شاید هنرمندی هستید که میخواهید با استفاده از NFT، و بدون از دست دادن کنترل و سودتان به واسطهها، آثارتان را به اشتراک بگذارید. میتوانید قرارداد هوشمند جدیدی بسازید و تعداد NFTها، مشخصات آنها و لینک ورود به برخی آثار هنری خاص را مشخص کنید. بهعنوان هنرمند، **میتوانید امتیازهایی را در قرارداد هوشمند برنامهریزی کنید** که باید به شما پرداخت شود (مثلاً هر بار که یک NFT معامله میشود 5٪ از قیمت فروش به صاحب قرارداد منتقل شود). همچنین همیشه میتوانید ثابت کنید که شما NFTها را تولید کردهاید، زیرا مالک [کیف پولی](/glossary/#wallet) هستید که قرارداد را منتشر کرده است. خریداران شما بهراحتی میتوانند ثابت کنند که مالک **یک NFT معتبر** متعلق به مجموعه شما هستند زیرا [آدرس](/glossary/#address) کیفپول آنها با توکنی در قرارداد هوشمند شما مرتبط است. آنها میتوانند از آن در سراسر اکوسیستم اتریوم استفاده کنند و ضمناً از بابت اصالت آن خیالشان آسوده باشد.
- NFT اثر هنری/کلکسیونی خود را جستوجو کنید، بخرید یا بسازید...
+ NFT اثر هنری/کالاهای خود را جستجو کنید، بخرید یا بسازید...
- مشاهدهی آثار هنری NFT
+ کشف آثار هنری NFT
-و یا، یک بلیط مربوط به یک رویداد ورزشی را در نظر بگیرید. همانطور که **مدیر یک رویداد میتواند تعداد بلیطها را تعیین کند**، خالق یک NFT میتواند برای تعداد کپیهای موجود از آن تصمیم بگیرد. گاهی اینها کپیهایی کاملاً شبیه به هم هستند، مانند 5000 بلیت ورودی برای عموم. گاهی اوقات چندین مورد ضرب میشود که بسیار شبیه به هم هستند، اما هریک با دیگری کمی تفاوت دارد؛ مانند بلیط یک صندلی اختصاصی. بلیط ها را میتوان به شکل متناظر و بدون نیاز به واسطه خرید و فروش کرد و خریدار همیشه میتواند اصالت بلیتها را با چک کردن اعتبار آدرس قرارداد چک کند.
+و یا بلیت یک رویداد ورزشی را در نظر بگیرید. همانطور که **برگزارکننده یک رویداد میتواند تعداد بلیت ها برای فروش را تعیین کند**، سازنده یک NFT میتواند درباره تعداد کپیهای موجود از آن تصمیم بگیرد. گاهی اینها کپیهایی کاملاً شبیه به هم هستند، مانند 5000 بلیت ورودی بدون تعیین جای مشخص. گاهی چندین مورد ضرب میشود که بسیار شبیه به هم هستند، اما هریک با دیگری کمی تفاوت دارد؛ مانند بلیت یک صندلی اختصاصی. بلیت ها را میتوان به شکل متناظر و بدون نیاز به واسطه خرید و فروش کرد و خریدار همیشه میتواند اصالت بلیتها را با چک کردن اعتبار آدرس قرارداد چک کند.
-روی وبسایت ethereum.org، از کل **NFTها برای نشان دادن اینکه افراد به طور معناداری در مخزن گیتهاب ما مشارکت کردهاند (وبسایت را برنامهریزی کرده، مقالهای نوشته یا تغییر دادهاند و غیره)، محتوای ما را ترجمه کردهاند، یا در دورهمیهای انجمن ما شرکت کردهاند استفاده میشود، و ما حتی نام دامنه NFT خود را داریم. اگر به ethereum.org کمک میکنید، میتوانید یک NFT سبک [POAP](/glossary/#poap) دریافت کنید. بعضی دورهمیهای کریپتویی از PAOPها به عنوان بلیط استفاده کردهاند. [اطلاعات بیشتر در مورد مشارکت](/contributing/#poap).
+در وبسایت ethereum.org، از **کل NFTها برای نشان دادن اینکه افراد به طور معنادار در مخزن گیتهاب ما** مشارکت کردهاند (وبسایت را برنامهریزی کرده، مقالهای نوشته یا تغییر دادهاند و غیره)، محتوای ما را ترجمه کردهاند، یا در دورهمیهای انجمن ما شرکت کردهاند استفاده میشود، و ما حتی نام دامنه NFT خود را داریم. اگر به ethereum.org کمک کنید، میتوانید یک NFT سبک [POAP](/glossary/#poap) دریافت کنید. بعضی دورهمیهای کریپتویی از PAOPها به عنوان بلیط استفاده کردهاند. [اطلاعات بیشتر در مورد مشارکت](/contributing/#poap).
![ethereum.org POAP](./poap.png)
-همچنین این وبسایت یک دامنه جایگزین دارد که توسط NFTها پشتیبانی میشوند، **ethereum.eth**. آدرس `.org` ما اساساً توسط یک ارائهدهنده سیستم نام دامنه (DNS) مدیریت میشود، در حالی که ethereum`.eth` از طریق سرویس نام اتریوم (ENS) در اتریوم ثبت شده است. و ضمناً تحت مالکیت و مدیریت ما است. [یادداشتهای مربوط به ENS ما را بررسی کنید](https://app.ens.domains/name/ethereum.eth)
+همچنین این وبسایت یک نام دامنه جایگزین دارد که توسط NFTها پشتیبانی میشود، **ethereum.eth**. آدرس `.org` ما اساساً توسط یک ارائهدهنده «سیستم نام دامنه» (DNS) مدیریت میشود، در حالی که ethereum`.eth` از طریق سرویس نام اتریوم (ENS) در اتریوم ثبت شده است. و تحت مالکیت و مدیریت ما است. [سوابق ENS ما را بررسی کنید](https://app.ens.domains/name/ethereum.eth)
[اطلاعات بیشتر درباره ENS](https://app.ens.domains)
@@ -75,23 +75,23 @@ NFTها کاربرد بسیاری دارند، از جمله:
## NFTها چگونه کار میکنند؟ {#how-nfts-work}
-NFTها، مانند هر آیتم دیجیتالی در بلاکچین اتریوم، از طریق یک برنامه کامپیوتری ویژه مبتنی بر اتریوم به نام «قرارداد هوشمند» ایجاد میشوند. این قراردادها از قوانین خاصی پیروی می کنند، مانند استانداردهای [ERC-721](/glossary/#erc-721) یا [ERC-1155](/glossary/#erc-1155)، که تعیین میکنند قرارداد چه کاری را میتواند انجام دهد.
+NFTها، مانند هر آیتم دیجیتالی در بلاکچین اتریوم، از طریق یک برنامه کامپیوتری ویژه مبتنی بر اتریوم به نام «قرارداد هوشمند» ایجاد میشوند. این قراردادها از قوانین خاصی پیروی می کنند، مانند استانداردهای [ERC-721](/glossary/#erc-721) یا [ERC-1155](/glossary/#erc-1155)، که تعیین میکنند قرارداد چه کار میتواند انجام دهد.
قرارداد هوشمند NFT میتواند چند کار کلیدی را انجام دهد:
- **ایجاد NFTها:** میتواند NFTهای جدید تولید کند.
-- **تخصیص مالکیت:** با پیوند دادن آنها به آدرسهای خاص اتریوم، مالکیت هریک از NFTها را ردیابی میکند.
-- **اختصاص یک شناسه به هر NFT:** هر NFT شمارهای دارد که آن را منحصربهفرد میکند. علاوه بر این، معمولاً برخی از اطلاعات (متادیتا) به آن پیوست شده است که توضیح میدهد آن NFT نشانگر چی است.
+- **تخصیص مالکیت:** با پیوند دادن NFTها به آدرسهای خاص اتریوم، مالکیت هریک از آنها را ردیابی میکند.
+- **اختصاص یک شناسه به هر NFT:** هر NFT شمارهای دارد که آن را منحصربهفرد میکند. علاوه بر این، معمولاً برخی از اطلاعات (متادیتا) به آن پیوست شده است که توضیح میدهد آن NFT نشانگر چیست.
-وقتی شخصی یک NFT را «ایجاد» یا «تولید» میکند، اساساً به قرارداد هوشمند میگوید که مالکیت یک NFT خاص را به او بدهد. این اطلاعات به صورت امن و عمومی در بلاکچین ذخیره میشود.
+وقتی شخصی یک NFT را «ایجاد» یا «ضرب» میکند، اساساً به قرارداد هوشمند میگوید که مالکیت یک NFT خاص را به او بدهد. این اطلاعات به صورت امن و عمومی در بلاکچین ذخیره میشود.
علاوه بر این، تولیدکننده محتوا میتواند قوانین بیشتری اضافه کند. او ممکن است تعداد تولید یک NFT خاص را محدود کند یا مقرر نماید که با هربار دست به دست شدن NFT، حق امتیاز کوچکی دریافت کند.
### امنیت NFT {#nft-security}
-امنیت اتریوم از [اثبات سهام](/glossary/#pos) نشأت میگیرد. این سیستم به گونهای طراحی شده است که از لحاظ اقتصادی از اقدامات خرابکارانه جلوگیری کند و اتریوم را درمقابل دستکاری مقاوم سازد. این همان چیزی است که وجود NFTها را ممکن میکند. همین که [بلوک](/glossary/#block) حاوی تراکنش NFT شما [نهایی](/glossary/#finality) میشود برای یک مهاجم میلیونها اتر هزینه دارد تا بخواهد در آن تغییری ایجاد کند. هرکس که نرمافزار، اتریوم را اجرا میکند، فوراً میتواند متوجه دستکاری خرابکارانه در NFT شود و طرف خرابکار مشمول جریمه مالی قرار میگیرد و اخراج میشود.
+امنیت اتریوم از [اثبات سهام](/glossary/#pos) نشأت میگیرد. این سیستم به گونهای طراحی شده است که از لحاظ اقتصادی از اقدامات خرابکارانه جلوگیری کند و اتریوم را درمقابل دستکاری مقاوم سازد. این چیزی است که وجود NFTها را ممکن میکند. وقتی [بلوک](/glossary/#block) حاوی تراکنش NFT شما [نهایی](/glossary/#finality) میشود، تغییر دادن آن، برای یک مهاجم میلیونها اتر هزینه دارد. هرکس که نرمافزار اتریوم را اجرا میکند، فوراً میتواند متوجه دستکاری خرابکارانه در NFT شود و طرف خرابکار مشمول جریمه مالی و اخراج میشود.
-مسائل امنیتی مربوط به NFTها اغلب به کلاهبرداریهای فیشینگ، آسیبپذیریهای قرارداد هوشمند یا خطاهای کاربر (مانند افشای ناخواسته کلیدهای خصوصی) مربوط میشود، که امنیت خوب برای کیف پول را برای دارندگان NFT ضروری میکند.
+مسائل امنیتی مربوط به NFTها اغلب به کلاهبرداریهای فیشینگ، آسیبپذیریهای قرارداد هوشمند یا خطاهای کاربر (مانند افشای ناخواسته کلیدهای خصوصی) مربوط میشوند، که امنیت خوب برای کیف پول را برای دارندگان NFT حیاتی میکند.
اطلاعات بیشتر در مورد امنیت
@@ -99,10 +99,15 @@ NFTها، مانند هر آیتم دیجیتالی در بلاکچین اتری
## بیشتر بخوانید {#further-reading}
-- [راهنمای NFT برای مبتدیان](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _لیندا ژی(Linda Xie)، ژانویه 2020_
+- [راهنمای NFT برای مبتدیان](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _لیندا ژی (Linda Xie)، ژانویه 2020_
- [ردیاب EtherscanNFT](https://etherscan.io/nft-top-contracts)
- [استاندارد توکن ERC-721](/developers/docs/standards/tokens/erc-721/)
- [استاندارد توکن ERC-1155](/developers/docs/standards/tokens/erc-1155/)
+- [اپها و ابزارهای محبوب NFT](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts)
+
+## منابع دیگر {#other-resources}
+
+- [NFTScan](https://nftscan.com/)
diff --git a/public/content/translations/fa/refi/index.md b/public/content/translations/fa/refi/index.md
index a249b1d3236..0c3fa8385fe 100644
--- a/public/content/translations/fa/refi/index.md
+++ b/public/content/translations/fa/refi/index.md
@@ -14,25 +14,27 @@ summaryPoint3: ابزاری برای مقیاسپذیری قابل توجه
## Refi چیست؟ {#what-is-refi}
-**امور مالی بازتولیدکننده (ReFi)**مجموعه ای از ابزار ها و ایده ها است که بر روی بستر بلاکچین ساخته شده اند که هدف آن تولید اقتصادهایی است که بازتولیدکننده باشند، نه استخراجی یا استثمارگر. در نهایت، سیستم های استخراجی منابع موجود را استفاده کرده و از بین می برند که بدون هیچگونه ساز و کار بازتولیدکننده، فاقد قدرت خواهند بود. عملکرد ReFi بر این پنداشت است که ایجاد ارزش پولی باید از استخراج ناپایدار منابع از سیاره و از جوامع ما جدا شود.
+**سیستمهای مالی احیایی (ReFi)** مجموعهای از ابزارها و ایدههایی است که بر روی [بلاکچینها](/glossary/#blockchain) ساخته شدهاند و هدف آن ایجاد اقتصادهایی است که به جای استخراج یا بهرهکشی، احیاکننده هستند. در نهایت، سیستم های استخراجی منابع موجود را استفاده کرده و از بین می برند که بدون هیچگونه ساز و کار بازتولیدکننده، فاقد قدرت خواهند بود. عملکرد ReFi بر این پنداشت است که ایجاد ارزش پولی باید از استخراج ناپایدار منابع از سیاره و از جوامع ما جدا شود.
در عوض، هدف ReFi حل مشکلات محیط زیستی، همگانی، یا اجتماعی به وسیله ایجاد چرخه های بازتولیدکننده می باشد. این سیستم ها در حالی که برای شرکت کنندگان ارزش تولید می کنند، به طور همزمان به اکوسیستم ها و جوامع هم سود می رسانند.
-یکی از پایه های ReFi مفهوم اقتصاد بازتولیدکننده است که توسط جان فولرتون از [موسسه کاپیتال](https://capitalinstitute.org) مطرح شد. او 8 اصل به هم پیوسته را که زیربنای سلامت سیستماتیک را تشکیل می دهند پیشنهاد کرد:
+یکی از پایه های ReFi مفهوم اقتصاد بازتولیدکننده است که توسط جان فولرتون از موسسه Capital مطرح شد. او [هشت اصل به هم پیوسته](https://capitalinstitute.org/8-principles-regenerative-economy/) را پیشنهاد کرد که زیربنای سلامت سیستمیک هستند:
-![هشت اصل به هم پیوسته](./refi-regenerative-economy-diagram.png)
+![هشت اصل به هم پیوسته](refi-regenerative-economy-diagram.png)
-پروژه های Refi این اصول را هنگام استفاده از [قرارداد های هوشمند](/developers/docs/smart-contracts/) و اپلیکیشنهای[ سیستم های مالی غیر متمرکز (DeFi)](/defi/) به عنوان محرکی برای رفتارهای بازتولیدکننده به کار می گیرند. به عنوان مثال احیا اکوسیستم های تنزل یافته و تقویت همکاری ها در مقیاس بزرگ برای مسائل جهانی مانند تغییرات آب و هوا و تقلیل تنوع زیستی جانوری.
+پروژه های Refi این اصول را هنگام استفاده از [قرارداد های هوشمند](/glossary/#smart-contract) و اپلیکیشنهای [سیستم های مالی غیر متمرکز (DeFi)](/glossary/#defi) به عنوان محرکی برای رفتارهای بازتولیدکننده به کار می گیرند. به عنوان مثال احیا اکوسیستم های تنزل یافته و تقویت همکاری ها در مقیاس بزرگ برای مسائل جهانی مانند تغییرات آب و هوا و تقلیل تنوع زیستی جانوری.
ReFi همچنین با جنبش [دانش غیرمتمرکز (DeSci)](/desci/) همپوشانی دارد، که از اتریوم به عنوان پلتفرمی برای فراهم کردن سرمایه، تولید کردن، بررسی کردن، اعتبار دادن، ذخیره کردن، و منتشر کردن دانش علمی استفاده می کند. ابزارهای DeSci می توانند برای توسعه استاندارد ها و شیوه های تحقیق پذیر برای اجرا کردن و نظارت کردن بر فعالیت های بازتولیدکننده مانند کاشتن درختان، جمعآوری پلاستیک از اقیانوس، یا احیای یک اکوسیستم تخریب شده مفید باشند.
+
+
## توکنیزه کردن اعتبارات کربنی {#tokenization-of-carbon-credits}
-**[بازار داوطلبانه کربن (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** مکانیزمی است برای تامین مالی پروژه هائی که تاثیر مثبت تایید شده ای بر انتشار کربن می گذارند؛ یا مداوم انتشارشان را کاهش می دهند، یا گاز های گل خانه ای را که قبلا در جو منتشر شده اند حذف میکنند. پس از تایید این پروژه ها، آن ها یک دارائی به نام "اعتبارات کربن" دریافت می کنند، که می توانند آن ها را به افراد و سازمان هایی که میخواهند از اقدامات آب و هوایی حمایت کنند بفروشند.
+**[بازار داوطلبانه کربن (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** مکانیزمی است برای تامین مالی پروژه هائی که تاثیر مثبت تایید شده بر انتشار کربن دارند؛ یا انتشار مداوم را کاهش می دهند، یا گاز های گل خانه ای را که قبلا در جو منتشر شده اند حذف میکنند. پس از تایید این پروژه ها، آن ها یک دارائی به نام "اعتبارات کربن" دریافت می کنند، که می توانند آن ها را به افراد و سازمان هایی که میخواهند از اقدامات آب و هوایی حمایت کنند بفروشند.
علاوه بر VCM، چندین بازار کربن دستوری از طرف دولت («بازارهای سازگاری) وجود دارد که هدف آن ها تعیین قیمت کربن از طریق قوانین و مقررات در یک حوزه قضایی بخصوص (مثلا در یک کشور یا منطقه)، جهت کنترل صدور مجوزهایی است که باید توزیع شوند. بازارهای سازگاری، در حوزه حقوقی خود، آلایندگان را جهت کاهش انتشار گاز های گلخانه ای تشویق می کنند، اما قادر به پاک کردن گاز های گلخانه ای از قبل منتشر شده نیستند.
-علی رقم توسعه آن در دهه های اخیر، VCM هنوز با چالش های متعددی مواجه است:
+علی رقم توسعه آن در دهه های اخیر، VCM هنوز با چالش های متعدد مواجه است:
1. پراکندگی زیاد نقدینگی
2. مکانیزم های غیر شفاف تراکنش
@@ -40,14 +42,14 @@ ReFi همچنین با جنبش [دانش غیرمتمرکز (DeSci)](/desci/)
4. سرعت بسیار پایین معاملات
5. عدم مقیاس پذیری
-انتقال VCM به **بازار جدید کربن دیجیتال (DCM)** مبتنی بر بلاک چین ممکن است شانسی برای ارتقا دادن تکنولوژی موجود برای معتبر ساختن، معامله کردن و مصرف کردن اعتبارات کربن باشد. بلاکچینها به داده های قابل تایید عمومی اجازه دسترسی برای طیف گسترده ای از کاربرها، و نقدینگی بیشتر را می دهند.
+انتقال VCM به **بازار جدید کربن دیجیتال (DCM)** مبتنی بر بلاکچین، ممکن است فرصتی برای ارتقا دادن تکنولوژی موجود برای معتبر ساختن، معامله کردن و مصرف اعتبارات کربن باشد. بلاکچینها به داده های قابل تایید عمومی اجازه دسترسی برای طیف گسترده ای از کاربرها، و نقدینگی بیشتر را می دهند.
-پروژه های Refi با به کار گیری تکنولوژی بلاکچین تعداد زیادی از مشکلات بازار های سنتی را تسهیل می کنند:
+پروژه های Refi با به کارگیری تکنولوژی بلاکچین تعداد زیادی از مشکلات بازار های سنتی را تسهیل می کنند:
- ** نقدینگی در تعداد محدودی از استخر های نقدینگی متمرکز شده است** که هر شخص می تواند آزادانه آن را مبادله کند. تشکیلات بزرگ همانند اشخاص می توانند از این استخر های نقدینگی بدون جستجوی دستی فروشندگان و خریداران، پرداخت هزینه های مشارکت یا هزینه ثبت نام، استفاده کنند.
- **تمامی تراکنش ها به روی بلاکچینهای عمومی ثبت می شوند**. مسیری که هر یک از اعتبارات کربن جهت فعالیت مبادله طی می کند، به محض در دسترس بودن در DCM برای همیشه قابل ردیابی خواهد بود.
- **سرعت تراکنش تقریبا آنی می باشد**. تامین مقادیر زیاد اعتبارات کربن از طریق بازارهای ارثی می تواند چندین روز یا هفته به طول بینجامد، در حالی که از طریق DCM در عرض چند ثانیه میسر خواهد بود.
-- **فعالیت مبادله تجاری بدون هرگونه واسطه انجام می گیرد**، که کارمزد بالایی را درخواست می کنند. به توجه به داده های یک شرکت تحلیلی، اعتبارهای کربن دیجیتال باعث [ بهبود 62% هزینه نسبت به اعتبار های کربن سنتی](https://www.klimadao.finance/blog/klimadao-analysis-of-the-base-carbon-tonne) میشود.
+- **فعالیت مبادله تجاری بدون هرگونه واسطه انجام می گیرد**، که کارمزد بالایی را درخواست می کنند. اعتبارات کربن دیجیتال نشان دهنده کاهش قابل توجه هزینه در مقایسه با اعتبارات سنتی است.
- **DCM مقیاس پذیز است** و میتواند هم نیاز اشخاص و هم سازمان های بین المللی را بر طرف کند.
### اجزای کلیدی DCM {#key-components-dcm}
@@ -61,15 +63,15 @@ ReFi همچنین با جنبش [دانش غیرمتمرکز (DeSci)](/desci/)
2. پل های کربنی، با نام مستعار مبدل توکن های دیجیتال، یک فناوری برای نمایش دادن یا انتقال اعتبارات کربن از سازمان های قدیمی به DCM را فراهم می کنند. مثال های قابل توجه شامل [Toucan Protocol](https://toucan.earth/)، [C3](https://c3.app/)، و [Moss.Earth](https://moss.earth/) می شوند.
3. خدمات یکپارچه، اجتناب کربن و/یا حذف اعتبارات را به کاربران نهایی ارائه می کند بنابراین آن ها می توانند اعتبار مزایای زیست محیطی را مطالبه کنند و حمایت خود را از اقدامات آب و هوایی را با دنیا به اشتراک بگذارند.
-بعضی شرکت ها مثل [کلیما اینفینیتی (Klima Infinity)](https://www.klimadao.finance/infinity) و [سنکن (Senken)](https://senken.io/) طیف گسترده ای از پروژه های توسعه یافته توسط شرکت های ثالت و اعتبار کربن صادر شده زیر نظر استاندارد هایی مثل Verra را ارائه میدهند؛ دیگران مثل [نوری (Nori)](https://nori.com/) تنها پروژه های خاص را که زیر نظر استاندارد خودشان توسعه یافته اند ارائه میدهند، که صادر کننده اعتبار کربن خودشان هستند و برای هر کدام بازارچه مخصوص به خود را دارند.
+بعضی شرکت ها مثل [کلیما اینفینیتی (Klima Infinity)](https://www.klimadao.finance/infinity) و [سنکن (Senken)](https://senken.io/) طیف گسترده ای از پروژه های توسعه یافته توسط طرف های ثالت و اعتبار کربن صادر شده زیر نظر استاندارد هایی مثل Verra را ارائه میدهند؛ دیگران مثل [نوری (Nori)](https://nori.com/) تنها پروژه های خاص را ارائه می کنند که زیر نظر استاندارد اعتبار کربن خودشان توسعه یافته اند، آنها را صادر میکنند و برای هر کدام بازارچه مخصوص به خود را دارند.
4. چارچوب و زیرساخت اساسی که امکان مقیاسپذیری اثربخشی و بازده کل زنجیره تامین را در بازار کربن فراهم می کند. [KlimaDAO](http://klimadao.finance/) نقدینگی را به عنوان کالای عمومی تامین میکند (امکان خرید یا فروش اعتبار کربن با قیمتی شفاف را برای هر کس فراهم میکند)، مشوق برای افزایش فعالیت در بازارهای کربن و بازنشستگی اعتبارات را از طریق پاداشها، و ابزارهای ساده و همتراز برای دسترسی به اطلاعات و همچنین بهدست آوردن و بازنشستگی طیف گستردهای از اعتبارات کربن توکنسازیشده فراهم میکند.
## Refi فراتر از بازارهای کربن {#refi-beyond}
-با اینکه هم اکنون تاکید زیادی روی بازارهای کربن به طور کلی، و به خصوص انتقال VCM به DCM در این حوزه وجود دارد، Refi به کربن محدود نمیشود. دیگر داراییهای زیستمحیطی فراتر از اعتبارات کربن هم میتوانند توسعه و توکنیزه شوند، که امکان گنجاندن سایر اثرات جانبی نامطلوب را در سطوح پایه ای سیستمهای اقتصادی آینده فراهم میکند. علاوه بر این، جنبه بازتولیدکنندگی این مدل اقتصادی را میتوان برای سایر بخش نیز بکار برد مثل تامین سرمایه کالاهای عمومی از طریق پلتفرم های تامین مالی درجه دوم مثل [گیتکوین](https://gitcoin.co/). سازمان هایی که بنیاد آن ها بر اساس ایده مشارکت آزاد و توزیع منصفانه منابع نهادینه شده است همه را قادر میسازند سرمایه ها را به سمت پروژه های نرم افزاری منبع-باز، و نیز پروژههای آموزشی، محیط زیستی و پروژه های جامعه محور سرازیر کنند.
+با اینکه هم اکنون تاکید زیادی روی بازارهای کربن به طور کلی، و به خصوص انتقال VCM به DCM در این حوزه وجود دارد، Refi به کربن محدود نمیشود. دیگر داراییهای زیستمحیطی فراتر از اعتبارات کربن هم میتوانند توسعه و توکنیزه شوند، که امکان گنجاندن سایر اثرات جانبی نامطلوب را در سطوح پایه ای سیستمهای اقتصادی آینده فراهم میکند. علاوه بر این، جنبه بازتولیدکنندگی این مدل اقتصادی را میتوان برای سایر بخش ها نیز به کار برد، مثل تامین سرمایه کالاهای عمومی از طریق پلتفرم های تامین مالی درجه دوم مثل [گیتکوین](https://gitcoin.co/). سازمان هایی که بنیاد آنها بر اساس ایده مشارکت آزاد و توزیع منصفانه منابع نهادینه شده است همه را قادر میسازند سرمایه ها را به سمت پروژه های نرم افزاری منبع-باز، و نیز پروژههای آموزشی، محیط زیستی و پروژههای جامعه محور سرازیر کنند.
-با تغییر مسیر جریان سرمایه از فعالیتهای استخراجی به سوی جریان بازتولیدکننده، پروژهها و شرکتهایی که مزایای اجتماعی، زیست محیطی یا محلی ارائه میکنند - و ممکن است در سیستم سنتی تامین سرمایه ناموفق باشند - میتوانند از جا بلند شوند و تأثیرات مثبت جانبی را برای جامعه به شکل سریعتر و آسانتر ایجاد کنند. انتقال به این نوع تأمین سرمایه، همچنین فرصتی برای ایجاد سیستمهای اقتصادی فراگیر ایجاد میکند که در آنها افراد همه بافتهای جمعیتی میتوانند به صورت فعال مشارکت کنند، به جای اینکه فقط به طور غیرفعال ناظر باشند. ReFi چشم اندازی از اتریوم را ارائه میدهد که از آن به عنوان مکانیسمی برای هماهنگی مقابله با چالشهای پیش روی ما و حیات روی سیارهمان استفاده میشود- به عنوان لایه پایهای یک پارادایم اقتصادی جدید در آینده، این مکانیسم یک آینده فراگیرتر و پایدارتر برای قرون آینده را ممکن میسازد.
+با تغییر مسیر جریان سرمایه از فعالیتهای استخراجی به سوی جریان بازتولیدکننده، پروژهها و شرکتهایی که مزایای اجتماعی، زیست محیطی یا محلی ارائه میکنند - و ممکن است در سیستم سنتی تامین سرمایه ناموفق باشند - میتوانند از جا بلند شوند و تأثیرات مثبت جانبی را برای جامعه به شکل سریعتر و آسانتر ایجاد کنند. انتقال به این نوع تأمین سرمایه، همچنین فرصتی برای ایجاد سیستمهای اقتصادی فراگیر ایجاد میکند که در آنها افراد همه بافتهای جمعیتی میتوانند به صورت فعال مشارکت کنند، به جای اینکه فقط به طور غیرفعال ناظر باشند. ReFi چشم اندازی از اتریوم را ارائه میکند که از آن به عنوان مکانیسمی برای هماهنگی مقابله با چالشهای پیش روی ما و حیات روی سیارهمان استفاده میشود- به عنوان لایه پایه یک پارادایم اقتصادی جدید، این مکانیسم یک آینده فراگیرتر و پایدارتر برای قرون آینده را ممکن میسازد.
## مطالعه بیشتر درباره ReFi
diff --git a/public/content/translations/fa/roadmap/account-abstraction/index.md b/public/content/translations/fa/roadmap/account-abstraction/index.md
index bb263d0e800..58570d277d3 100644
--- a/public/content/translations/fa/roadmap/account-abstraction/index.md
+++ b/public/content/translations/fa/roadmap/account-abstraction/index.md
@@ -1,5 +1,5 @@
---
-title: تفکیک حساب
+title: انتزاع حساب
description: مروری بر برنامههای اتریوم برای سادهتر و ایمنتر کردن حسابهای کاربری
lang: fa
summaryPoints:
@@ -8,7 +8,7 @@ summaryPoints:
- کلیدهای گمشده و لورفته را میتوان با استفاده از چندین نسخه پشتیبان بازیابی کرد
---
-# تفکیک حساب {#account-abstraction}
+# انتزاع حساب {#account-abstraction}
کاربرانی که در تعامل با شبکۀ اتریوم هستند از **[حسابهای تحت مالکیت خارجی (EOA)](/glossary/#eoa)** استفاده میکنند. این تنها راه شروع یک تراکنش یا اجرای یک قرارداد هوشمند است. البته این امر نحوۀ تعامل کاربران با شبکۀ اتریوم را محدود میکند. برای مثال، انجام چندین تراکنش در یک آن توسط حسابهای EOA برای کاربران دشوار بوده و نیازمند آن است که کاربر همیشه به منظور تأمین گس یا همان کارمزد شبکه، موجودی ETH کافی در حسابش داشته باشد.
@@ -40,17 +40,17 @@ summaryPoints:
انتزاع حساب این مشکل را با استفاده از قراردادهای هوشمند برای نگهداری از داراییها و اعطای مجوز تراکنشها حل خواهد کرد. سپس، این قراردادهای هوشمند را میتوان توسط یک منطق سفارشی با هدف ایمنسازی و مناسبسازی با نیاز کاربران از نو آراسته نمود. به طور کلی، شما همچنان برای کنترلِ دسترسی به حسابتان از کلیدهای خصوصی استفاده میکنید، اما با این تفاوت که این کار توسط نوعی شبکههای ایمنی که استفاده و مدیریت آنها را آسانتر و ایمنتر میکند انجام میگیرد.
-برای مثال، کلیدهای پشتیبان میتوانند به کیفپول اضافه شوند در نتیجه اگر شما کلیدهای اصلی خود را گم کردید یا به طور اتفاقی در معرض دید سایرین قرار دادید، یک کلید جدید و ایمن میتواند با مجوز و تأیید کلیدهای پشتیبان جایگزین آن شود. شما ممکن است ایمنسازی هرکدام از کلیدها را به روشی دیگر انجام دهید یا آنها را بین چندین محافظ قابل اعتماد تقسیم کنید. این کار باعث میشود کنترل کامل وجوهتان برای سارق سختتر شود. به همین ترتیب، شما میتوانید قوانینی را به کیف پولتان اضافه کنید تا در صورت به خطر افتادن کلید اصلی، تأثیرات منفی ناشی از آن را کاهش دهد، برای مثال شما ممکن است اجازه دهید تا تراکنشهای کمارزش با تنها یک امضا تأیید شوند در حالی که تراکنشهایی با ارزش بالاتر نیاز به تأیید چندین امضاکننده داشته باشند. راههای دیگری نیز وجود دارد که کیف پولهای هوشمند میتوانند به شما در خنثی کردن سرقتها کمک کنند، برای مثال ایجاد یک لیست سفید میتواند برای مسدود نمودن هر تراکنشی استفاده شود مگر اینکه آدرس تراکنش قابل اعتماد بوده و یا توسط چندین کلید از پیش تأییدشده، اعتبار آن ثابت گردد.
+برای مثال، کلیدهای پشتیبان میتوانند به کیفپول اضافه شوند در نتیجه اگر شما کلیدهای اصلی خود را گم کردید یا به طور اتفاقی در معرض دید سایرین قرار دادید، یک کلید جدید و ایمن میتواند با مجوز و تأیید کلیدهای پشتیبان جایگزین آن شود. شما ممکن است ایمنسازی هرکدام از کلیدها را به روشی دیگر انجام دهید یا آنها را بین چندین محافظ قابل اعتماد تقسیم کنید. این کار باعث میشود کنترل کامل وجوهتان برای سارق سختتر شود. به همین ترتیب، شما میتوانید قوانینی را به کیف پولتان اضافه کنید تا در صورت به خطر افتادن کلید اصلی، تأثیرات منفی ناشی از آن را کاهش دهد، برای مثال ممکن است اجازه دهید تراکنشهای کمارزش با تنها یک امضا تأیید شوند در حالی که تراکنشهایی با ارزش بالاتر نیاز به تأیید چندین امضاکننده داشته باشند. راههای دیگری نیز وجود دارد که کیف پولهای هوشمند میتوانند به شما در خنثی کردن سرقتها کمک کنند، برای مثال ایجاد یک لیست سفید میتواند برای مسدود نمودن هر تراکنش استفاده شود مگر اینکه آدرس تراکنش قابل اعتماد بوده و یا توسط چندین کلید از پیش تأییدشده، اعتبار آن ثابت گردد.
### مثالهایی از منطق امنیت که میتواند بر روی کیف پول قرارداد هوشمند ساخته شود:
- **مجوز چند امضایی**: شما میتوانید اطلاعات امنیتی مجوز خود را بین چندین فرد یا دستگاه مورد اعتماد به اشتراک بگذارید. قراردادها را میتوان به گونهای پیکربندی کرد که برای تراکنشهایی با ارزشی بیشتر از حد تعیینشده، نیاز به تأیید نسبت معینی (مثلاً ۳ نفر از ۵ نفر) از طرفهای مورد اعتماد باشد. برای مثال، بسیاری از تراکنشهای دارای ارزش بالا ممکن است نیاز به تأیید از روی دستگاه موبایل و کیفپول سختافزاری یا حتی امضاهایی از حسابهای توزیعشده بین اعضای معتمد خانواده داشته باشند.
- **حسابهای فریزشده**: اگر دستگاه گم شد یا در معرض خطر قرار گرفت حساب موردنظر را میتوان از روی دستگاه تأییدشدۀ دیگری قفل کرد و بدین ترتیب از داراییهای کاربر محافظت نمود.
-- **بازیابی حساب**: دستگاه را گم کرده یا گذرواژه را فراموش کردهاید؟ در پارادایم فعلی، این موضوع بدین معناست که دارایی شما برای همیشه میتواند فریز شود. با استفاده از کیف پول قرارداد هوشمند شما میتوانید تعدادی حساب از پیش تأییدشده را تنظیم کنید که این حسابها میتوانند دستگاههای جدیدی را تأیید و دسترسی به آنها را برایتان بازنشانی کنند.
+- **بازیابی حساب**: دستگاه را گم کرده یا گذرواژه را فراموش کردهاید؟ در پارادایم فعلی، این موضوع بدین معناست که دارایی شما برای همیشه میتواند فریز شود. با استفاده از کیف پول قرارداد هوشمند شما میتوانید لیست سفید حسابهایی را ایجاد کنید که این حسابها میتوانند دستگاههای جدیدی را تأیید و دسترسی به آنها را برایتان بازنشانی کنند.
- **تعیین محدودیت تراکنش**: آستانههای روزانهای برای مقدار ارزشی که میتواند در روز/هفته/ماه از حساب انتقال یابد مشخص کنید. به عبارتی، اگر یک مهاجم به نحوی به حساب شما دسترسی پیدا کرد، نمیتواند به یکباره تمامی دارایی شما را بیرون بکشد و شما این فرصت را داشته باشید تا دسترسی به حسابتان را فریز و آن را مجدداً بازنشانی کنید.
-- **ایجاد لیست سفید**: با این کار، انجام تراکنشها را فقط به آدرسهای خاصی که میدانید امن است مجاز کنید. به عبارتی، _حتی اگر_ کلید خصوصی دزدیده شود هم مهاجم نتواند وجوهتان را به حسابهای مقصدی که خارج از لیست سفید هستند ارسال کند. این لیستهای سفید نیاز به چندین امضا برای ایجاد هرگونه تغییر دارند برای همین مهاجم یا هکر نمیتواند آدرسهای خودش را به این لیست اضافه کند مگر اینکه به چندین کلید پشتیبان شما دسترسی داشته باشد.
+- **ایجاد لیست سفید**: با این کار، انجام تراکنشها را فقط به آدرسهای خاصی که میدانید امن است مجاز کنید. به عبارتی، _حتی اگر_ کلید خصوصی دزدیده شود، مهاجم نتواند وجوهتان را به حسابهای مقصدی که خارج از لیست سفید هستند ارسال کند. این لیستهای سفید نیاز به چندین امضا برای ایجاد هرگونه تغییر دارند برای همین مهاجم یا هکر نمیتواند آدرسهای خودش را به این لیست اضافه کند مگر اینکه به چندین کلید پشتیبان شما دسترسی داشته باشد.
-## Better user experience {#better-user-experience}
+## تجربه کاربری بهتر {#better-user-experience}
انتزاع حساب **به طور کلی تجربۀ کاربری بهتر** و همچنین **بهبود در امنیت شبکه** را برای کاربرانش فراهم میکند زیرا پشتیبانی لازم را برای کیف پولهای قرارداد هوشمند در سطح پروتکل میافزاید. مهمترین دلیل برای ایجاد چنین پشتیبانی کاملی در سرتاسر شبکه این است که این ویژگی به توسعهدهندگان قراردادهای هوشمند، کیف پولها و برنامههای کاربردی، آزادی عمل بیشتری برای نوآوری در زمینه تجربه کاربری به روشهای جدید و خلاقانه ارائه میدهد. بعضی از پیشرفتهای مشهودی که همراه با انتزاع حساب بدست میآیند دستهبندی معاملات و تراکنشها برای حصول سرعت و کارایی است. برای مثال، یک مبادلۀ ساده فرآیندی است که باید با یک کلیک انجام گیرد، ولی امروزه قبل از اینکه مبادله اجرا شود، به منظور تأیید پرداخت و مصرف توکنها در این مبادله، به امضای چندین تراکنش نیاز است. انتزاع حساب این اصطکاک را با دستهبندی تراکنشها در یک مجموعه برطرف میکند. علاوهبراین، تراکنش دستهبندیشده میتواند به طور دقیق ارزش واقعی و درستی از توکنهایی را که برای هر معامله نیاز هست تأیید کرده و پس از تکمیل شدن معامله برای امنیت بیشتر، تمامی تأییدیهها را لغو کند.
diff --git a/public/content/translations/fa/roadmap/beacon-chain/index.md b/public/content/translations/fa/roadmap/beacon-chain/index.md
index d8159cfaa9f..e57d23f3644 100644
--- a/public/content/translations/fa/roadmap/beacon-chain/index.md
+++ b/public/content/translations/fa/roadmap/beacon-chain/index.md
@@ -4,6 +4,7 @@ description: در مورد زنجیرهی بیکن یاد بگیرید - ار
lang: fa
template: upgrade
image: /images/upgrades/core.png
+alt:
summaryPoint1: زنجیره بیکن اثبات سهام را برای اولین بار به اکوسیستم اتریوم وارد کرد.
summaryPoint2: این زنجیره در ماه سپتامبر 2022 با زنجیرۀ اصلی اثبات کار اتریوم ادغام شد.
summaryPoint3: زنجیره بیکن منطق اجماع و پروتکل شایعه (گاسیپ) را برای اولین بار ارائه کرد که اکنون امنیت اتریوم را تأمین میکند.
@@ -23,11 +24,11 @@ summaryPoint3: زنجیره بیکن منطق اجماع و پروتکل شای
## تأثیر زنجیره چین {#beacon-chain-features}
-### درباره سهامگذاری {#introducing-staking}
+### معرفی استیکینگ {#introducing-staking}
زنجیره بیکن [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) را برای اولین بار به اتریوم وارد کرد. این زنجیره شبکۀ اتریوم را امن نگه میدارد و در این فرایند، اعتبار اتریوم بیشتری را به اعتبارسنجها میرساند. در عمل، سهامگذاری شامل سهامگذاری روی اتریوم به منظور فعال کردن نرمافزار اعتبارسنج است. شما به عنوان یک سهامگذار، نرمافزاری را اجرا میکنید که بلوکهای جدیدی را در زنجیره ایجاد و تأیید میکند.
-سهامگذاری هدفی مشابه با [استخراج (ماینینگ)](/developers/docs/consensus-mechanisms/pow/mining/) دارد، اما از بسیاری جهات متفاوت است. استخراج نیاز به سرمایۀ اولیۀ زیادی در قالب سختافزار قدرتمند و مصرف انرژی داشت که منجر به صرفه به مقیاس (مزیت مقیاس) و افزایش متمرکزسازی میشد. ضمناً، استخراج هیچ الزامی برای قفل کردن داراییها به عنوان وثیقه نداشت و همین، توانایی پروتکل را برای مجازات نقشآفرینان بدکار پس از حمله محدود میکرد.
+سهامگذاری، هدفی مشابه با [استخراج (ماینینگ)](/developers/docs/consensus-mechanisms/pow/mining/) دارد، اما از بسیاری جهات متفاوت است. استخراج نیاز به سرمایۀ اولیۀ زیادی در قالب سختافزار قدرتمند و مصرف انرژی داشت که منجر به صرفه به مقیاس (مزیت مقیاس) و افزایش متمرکزسازی میشد. ضمناً، استخراج هیچ الزامی برای قفل کردن داراییها به عنوان وثیقه نداشت و همین، توانایی پروتکل را برای مجازات نقشآفرینان بدکار پس از حمله محدود میکرد.
جایگزینی اثبات سهام به جای اثبات کار، اتریوم را به طور قابل توجهی امنتر و غیرمتمرکزتر کرد. هرچه افراد بیشتری در شبکه شرکت کنند، غیرمتمرکزتر و در برابر حملات امنتر میشود.
diff --git a/public/content/translations/fa/roadmap/danksharding/index.md b/public/content/translations/fa/roadmap/danksharding/index.md
index 35212d71d03..63d136e8027 100644
--- a/public/content/translations/fa/roadmap/danksharding/index.md
+++ b/public/content/translations/fa/roadmap/danksharding/index.md
@@ -15,17 +15,19 @@ summaryPoints:
## Proto-Danksharding چیست؟ {#what-is-protodanksharding}
-Proto-Danksharding با نام [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) هم شناخته میشود و راهی است برای [رولآپها](/layer-2/#rollups) تا دادههای ارزانتری به بلوکها افزوده شوند. این اسم از نام دو محقق (Protolambda و Dankrad Feist) که این ایده را مطرح کردند گرفته شده است. درحال حاضر، رولآپها برای کمتر کردن هزینهها محدودیتهایی دارند چون تراکنشهای خود را با `CALLDATA` انتقال میدهند. این فرایند پرهزینه است چون تمام گرههای اتریوم باید آن را پردازش کنند و باید همیشه در زنجیره فعال باشند، گرچه رولآپها فقط برای مدت کوتاهی به دادهها نیاز دارند. Proto-Danksharding تودههایی از دادهها را ارائه میکند که قابل ارسال و الصاق به بلوکها هستند. EVM به این تودهها دسترسی ندارد و پس از یک دوره زمانی مشخص (1-3 ماه) به طور خودکار حذف میشوند. بهعبارتی، رولآپها اطلاعات را با هزینه کمتری ارسال میکنند و مقدار صرفهجوییشده را در قالب تراکنشهای ارزانتر به کاربران نهایی منتقل میکنند.
+بروتو-دنکشاردینگ با نام [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) هم شناخته میشود و راهی است برای [رولآپها](/layer-2/#rollups) تا دادههای ارزانتری به بلوکها افزوده شوند. این اسم از نام دو محقق (Protolambda و Dankrad Feist) که این ایده را مطرح کردند گرفته شده است. از لحاظ تاریخی، رولآپها به دلیل اینکه تراکنشهای خود را در `CALLDATA` پست میکنند، از نظر ارزان بودن تراکنشهای کاربر محدود بوده اند.
+
+این فرایند پرهزینه است چون تمام گرههای اتریوم باید آن را پردازش کنند و باید همیشه در زنجیره فعال باشند، گرچه رولآپها فقط برای مدت کوتاهی به دادهها نیاز دارند. پروتو-دنکشاردینگ تودههایی از دادهها را ارائه میکند که قابل ارسال و الصاق به بلوکها هستند. داده موجود در این تودهها برای EVM قابل دسترسی نیستند و پس از یک دوره زمانی ثابت (که بر روی 4096 ایپوک در زمان نوشتن یا حدود 18 روز تنظیم شده است) بهطور خودکار حذف میشوند. بهعبارتی، رولآپها اطلاعات را با هزینه کمتری ارسال میکنند و مقدار صرفهجوییشده را در قالب تراکنشهای ارزانتر به کاربران نهایی منتقل میکنند.
-رولآپها روشی برای مقیاسبندی اتریوم با دستهبندی تراکنشهای خارج از زنجیره و سپس ارسال نتایج به اتریوم است. یک رولآپ اساساً از دو بخش تشکیل شده است: دادهها و بررسی اجرا. دادهها دنباله کامل تراکنشهایی هستند که توسط یک رولآپ پردازش میشوند تا تغییر حالت در حال ارسال به اتریوم ایجاد شود. بررسی اجرا عبارت است از اجرای مجدد آن تراکنشها توسط یک بازیگر درستکار (یک «اثباتکننده») تا اطمینان حاصل شود که تغییر حالت پیشنهادی درست است. برای بررسی اجرا، دادههای تراکنش باید برای مدت طولانی در دسترس باشد تا هر کسی بتواند آن را دانلود و بررسی کند. این بدان معناست که هر رفتار فریبکارانه توسط توالیسنج رولآپ میتواند توسط اثباتکننده شناسایی و به چالش کشیده شود. با این حال، لازم نیست برای همیشه در دسترس باشد.
+رولآپها روشی برای مقیاسبندی اتریوم با دستهبندی تراکنشهای خارج از زنجیره و سپس ارسال نتایج به اتریوم است. یک رولآپ اساساً از دو بخش تشکیل شده است: دادهها و بررسی اجرا. دادهها دنباله کامل تراکنشهایی هستند که توسط یک رولآپ پردازش میشوند تا تغییر حالت در حال ارسال به اتریوم ایجاد شود. بررسی اجرا عبارت است از اجرای مجدد آن تراکنشها توسط یک بازیگر درستکار (یک «اثباتکننده») تا اطمینان حاصل شود که تغییر حالت پیشنهادی درست است. برای انجام بررسی اجرا، داده تراکنش باید به اندازه کافی در دسترس باشد تا هر کس بتواند آن را دانلود و بررسی کند. این بدان معناست که هر رفتار فریبکارانه توسط توالیسنج رولآپ میتواند توسط اثباتکننده شناسایی و به چالش کشیده شود. با این حال، لازم نیست برای همیشه در دسترس باشد.
-رولآپها تعهدات مربوط به دادههای تراکنش خود را روی زنجیره ارسال میکنند و همچنین دادههای واقعی را در تودههای داده در دسترس قرار میدهند. این بدان معناست که اثباتکنندگان میتوانند معتبر بودن تعهدات را بررسی کنند یا دادههایی را که فکر میکنند اشتباه هستند به چالش بکشند. در سطح گره، تودههای داده در کلاینت اجماع نگهداری میشوند. کلاینتهای اجماع تأیید میکنند که آنها دادهها را دیدهاند و در سراسر شبکه منتشر شده است. اگر دادهها برای همیشه حفظ میشد، این کلاینتها حجیم میشدند و منجر به نیازهای سختافزاری بزرگ برای اجرای گرهها میشدند. در عوض، دادهها هر 1-3 ماه یکبار به طور خودکار از گره حذف میشوند. گواهیهای کلاینت اجماع نشان میدهد که فرصت کافی برای تأیید دادهها ازسوی اثباتکنندهها وجود دارد. دادههای واقعی را میتوان در خارج از زنجیره توسط اپراتورهای رولآپ، کاربران یا دیگران ذخیره کرد.
+رولآپها تعهدات مربوط به دادههای تراکنش خود را روی زنجیره ارسال میکنند و همچنین دادههای واقعی را در تودههای داده در دسترس قرار میدهند. این بدان معناست که اثباتکنندگان میتوانند معتبر بودن تعهدات را بررسی کنند یا دادههایی را که فکر میکنند اشتباه هستند به چالش بکشند. در سطح گره، تودههای داده در کلاینت اجماع نگهداری میشوند. کلاینتهای اجماع تأیید میکنند که آنها دادهها را دیدهاند و در سراسر شبکه منتشر شده است. اگر دادهها برای همیشه حفظ میشد، این کلاینتها حجیم میشدند و منجر به نیازهای سختافزاری بزرگ برای اجرای گرهها میشدند. در عوض، داده به طور خودکار هر 18 روز از گره هرس می شود. گواهیهای کلاینت اجماع نشان میدهد که فرصت کافی برای تأیید دادهها ازسوی اثباتکنندهها وجود دارد. دادههای واقعی را میتوان در خارج از زنجیره توسط اپراتورهای رولآپ، کاربران یا دیگران ذخیره کرد.
@@ -35,15 +37,17 @@ Proto-Danksharding با نام [EIP-4844](https://eips.ethereum.org/EIPS/eip-484
### KZG چیست؟ {#what-is-kzg}
-KZG مخفف نام سه [نویسنده اصلی](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) Kate-Zaverucha-Goldberg طرحی است که یک توده از داده را در یک [تعهدنامه رمزنگاریشده](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) کوچک خلاصه میکند. برای اطمینان از این که رولآپها رفتار درست دارند، توده دادههای ارسالشده از طرف رولآپها باید تأیید شوند. در این فرایند، یک اثباتکننده تراکنشهای موجود در توده دادهها را مجدداً اجرا میکند تا معتبر بودن تعهد بررسی شود. از نظر مفهومی، این روش شبیه همان کاری است که کلاینتهای اجرا، با استفاده از اثباتهای Merkle، برای بررسی اعتبار تراکنشهای اتریوم در لایه 1 انجام میدهند. KZG روشی جایگزین برای اثبات است که یک معادله چند جملهای را به دادهها الصاق میکند. تعهد مذکور صحت این معادله را با برخی از دادههای مخفی ارزیابی میکند. یک اثباتکننده همان معادله چندجملهای را با همان مقادیر ارزیابی میکند تا یکسان بودن نتایج را بررسی کند. این فرایند روشی برای تأیید دادههایی سازگار با تکنیکهای دانش صفر است که بعضی از رولآپها و متعاقباً بخشهایی از پروتکل اتریوم بکار میبرند.
+KZG مخفف نام سه [نویسنده اصلی](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) Kate-Zaverucha-Goldberg طرحی است که تودهای از دادهها را در یک [تعهدنامه رمزنگاریشده](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) کوچک خلاصه میکند. برای اطمینان از این که رولآپها رفتار درست دارند، توده دادههای ارسالشده از طرف رولآپها باید تأیید شوند. در این فرایند، یک اثباتکننده تراکنشهای موجود در توده دادهها را مجدداً اجرا میکند تا معتبر بودن تعهد بررسی شود. از نظر مفهومی، این روش شبیه همان کاری است که کاربرهای اجرا، با استفاده از اثباتهای Merkle، برای بررسی اعتبار تراکنشهای اتریوم در لایه 1 انجام میدهند. KZG روشی جایگزین برای اثبات است که یک معادله چند جملهای را به دادهها الصاق میکند. تعهد مذکور صحت این معادله را در برخی مخفی نقاط داده ارزیابی میکند. یک اثباتکننده، همان معادله چندجملهای را روی داده الصاق میکند و با همان مقادیر ارزیابی میکند تا یکسان بودن نتایج را بررسی کند. این فرایند روشی برای تأیید دادههایی سازگار با تکنیکهای دانش صفر است که بعضی از رولآپها و متعاقباً بخشهایی از پروتکل اتریوم بکار میبرند.
+
+### مراسم KZG چه بود؟ {#what-is-a-kzg-ceremony}
-### تشریفات KZG چیست؟ {#what-is-a-kzg-ceremony}
+مراسم KZG راهی برای بسیاری از افراد از سراسر جامعه اتریوم بود تا به طور جمعی یک رشته تصادفی مخفی از اعداد را تولید کنند که میتواند برای تأیید برخی از دادهها استفاده شود. نکته بسیار مهم این است که این رشته از اعداد ناشناختهاند و کسی نمیتواند دوباره آنها را تولید کند. برای اطمینان از این امر، هر فردی که در مراسم شرکت کرد، یک رشته از شرکت کننده قبلی دریافت کرد. سپس مقادیر تصادفی جدیدی ایجاد کردند (مثلاً با اجازه دادن به مرورگر خود برای اندازه گیری حرکت ماوس) و آن را با مقدار قبلی ترکیب کردند. سپس عدد را برای شرکتکننده بعدی ارسال کردند و آن را از دستگاه محلی خود حذف کردند. تا زمانی که یک نفر در مراسم این کار را صادقانه انجام دهد، عدد نهایی برای مهاجم غیرقابل تشخیص خواهد بود.
-تشریفات KZG راهی است که با آن بسیاری از افراد جامعه اتریوم میتوانند یک رشته تصادفی مخفی از اعداد را با هم تولید و از آن برای تأیید برخی از دادهها استفاده کنند. نکته حائز اهمیت این است که این رشته از اعداد ناشناختهاند و کسی نمیتواند دوباره آنها را تولید کند. برای اطمینان از این امر، هر شرکتکننده در این تشریفات یک رشته از شرکتکننده قبلی دریافت میکنند. سپس میتوانند مقادیر تصادفی جدیدی (مثلاً با دادن اجازۀ بررسی حرکت ماوس به مرورگر خود) ایجاد آن را با مقدار قبلی ترکیب کنند. سپس، مقدار ساختهشده را برای شرکتکننده بعدی ارسال میکنند و آن را از دستگاه محلی خود از بین میبرند. مادامیکه یک نفر در تشریفات این اقدام را با درستکاری انجام دهد، مقدار نهایی برای مهاجم قابل تشخیص نخواهد بود. تشریفات EIP-4844 KZG برای عموم آزاد بود و دهها هزار نفر برای اضافه کردن آنتروپی خود در آن شرکت کردند. وقتی اعتبار تشریفات زیر سؤال میرود که 100 درصد شرکتکنندگان فعالیت خود را بهطور فعالانه از روی فریبکاری انجام دهند. از نقطهنظر شرکتکنندگان، اگر بدانند که کارشان را صادقانه انجام دادهاند، نیازی نیست به شخص دیگری اعتماد کنند زیرا میدانند که امنیت تشریفات را تأمین کردهاند (شرط یک شرکتکننده درستکار از میان N شرکتکننده را که لازمه صحت روند است شخصاً تضمین کردهاند).
+پمراسم EIP-4844 KZG برای عموم آزاد بود و ده ها هزار نفر برای اضافه کردن آنتروپی (انتخاب تصادفی) خود شرکت کردند. در مجموع بیش از 140،000 مشارکت کننده وجود داشت که آن مراسم را به بزرگترین مراسم از نوع خود در جهان تبدیل کردند. وقتی اعتبار تشریفات زیر سؤال میرود که 100 درصد شرکتکنندگان فعالیت خود را بهطور فعالانه از روی فریبکاری انجام دهند. از نقطهنظر شرکتکنندگان، اگر بدانند که کارشان را صادقانه انجام دادهاند، نیازی نیست به شخص دیگری اعتماد کنند زیرا میدانند که امنیت تشریفات را تأمین کردهاند (شرط یک شرکتکننده درستکار از میان N شرکتکننده را که لازمه صحت روند است شخصاً تضمین کردهاند).
-هنگامی که یک رولآپ دادههایی را در یک توده پست میکند، یک «تعهد» را ارائه میدهد که روی زنجیره پست میکند. این تعهد نتیجه ارزیابی یک معادله چندجملهای است که در نقاطی مشخص به دادهها الصاق شدهاند. این نقاط با اعداد تصادفی تولیدشده در تشریفات KZG تعریف میشوند. سپس اثباتکنندگان میتوانند معادله چندجملهای را در همان نقاط ارزیابی کنند تا دادهها را تأیید کنند - اگر به همان مقادیر برسند، دادهها درست است.
+هنگامی که یک رولآپ داده را در یک توده پست می کند، آنها یک "تعهد" را ارائه می دهند که روی زنجیره پست می کنند. این تعهد نتیجه ارزیابی یک معادله چندجملهای است که در نقاطی مشخص به دادهها الصاق شدهاند. این نقاط با اعداد تصادفی تولیدشده در تشریفات KZG تعریف میشوند. سپس اثباتکنندگان میتوانند معادله چندجملهای را در همان نقاط ارزیابی کنند تا دادهها را تأیید کنند - اگر به همان مقادیر برسند، دادهها درست است.
@@ -54,14 +58,14 @@ KZG مخفف نام سه [نویسنده اصلی](https://link.springer.com/cha
- Danksharding و Proto-Danksharding هیچکدام از مدل سنتی «شاردینگ» (زنجیرهایسازی) پیروی نمیکنند، مدلی که هدف آن تقسیم زنجیره بلوکی به چندین بخش بود. زنجیرههای شارد (خردهزنجیرهها) دیگر بخشی از نقشه راه نیستند. در عوض، Danksharding از نمونهگیری دادههای توزیعشده در تودهها برای مقیاسبندی اتریوم استفاده میکند. اجرای این بسیار سادهتر است. گاهی اوقات، از این مدل تحت عنوان «شاردینگ دادهها» یاد میشود.
+ نه دنکشاردینگ و نه پروتو-دنکشاردینگ از مدل سنتی "شاردینگ" پیروی نمیکنند که هدف آن تقسیم بلاکچین به چندین بخش است. زنجیرههای شارد (خردهزنجیرهها) دیگر بخشی از نقشه راه نیستند. در عوض، Danksharding از نمونهگیری دادههای توزیعشده در تودهها برای مقیاسبندی اتریوم استفاده میکند. اجرای این بسیار سادهتر است. گاهی اوقات، از این مدل تحت عنوان «شاردینگ دادهها» یاد میشود.
## Danksharding چیست؟ {#what-is-danksharding}
Danksharding تحقق کامل مقیاسبندی رولآپی است که با Proto-Danksharding آغاز شده بود. Danksharding در اتریوم فضای عظیمی را برای رولآپها فراهم میکند تا دادههای تراکنشهای فشردهشده را از شبکه بیرون کند. این بدان معناست که اتریوم میتواند با پشتیبانی آسان از صدها رولآپ جداگانه، رؤیای پردازش میلیونها تراکنش در ثانیه را به واقعیت تبدیل کند.
-روش کار این مکانیزم این گونه است که تودههای اطلاعات متصل به بلوکها را بسط میدهد، بهطوری که مقدار 1 در Proto-Danksharding به 64 در نسخه نهایی Danksharding میرسد. بقیه تغییرات مورد نیاز همگی بهروزرسانیهایی در نحوه عملکرد کلاینت اجماع است تا بتواند به تودههای اطلاعاتی جدید و بزرگ رسیدگی کند. تعدادی از این تغییراتی که هماکنون در نقشه راه وجود دارد برای اهداف دیگری مستقل از Danksharding عمل میکنند. به عنوان مثال، برای Danksharding لازم است تفکیک پیشنهاددهنده و سازنده اجرا شده باشد. این ارتقا وظایف ساخت بلوک و پیشنهاد بلوک را بین اعتبارسنجهای مختلف از هم تفکیک میکند. همچنین، در Danksharding نمونهگیری در دسترس بودن دادهها ضروری است، همانطور که برای توسعه تینکلاینتهایی که دادههای تاریخی زیادی ذخیره نمیکنند لازم است (کلاینتهای بدون حالت).
+روش کار این است که تودههای متصل به بلوک ها را از شش (6) در پروتو-دنکشاردینگ به 64 در دنکشاردینگ کامل گسترش می دهد. بقیه تغییرات مورد نیاز همگی بهروزرسانیهایی در نحوه عملکرد کلاینت اجماع است تا بتواند به تودههای اطلاعاتی جدید و بزرگ رسیدگی کند. تعدادی از این تغییراتی که هماکنون در نقشه راه وجود دارد برای اهداف دیگری مستقل از Danksharding عمل میکنند. به عنوان مثال، برای Danksharding لازم است تفکیک پیشنهاددهنده و سازنده اجرا شده باشد. این ارتقا وظایف ساخت بلوک و پیشنهاد بلوک را بین اعتبارسنجهای مختلف از هم تفکیک میکند. همچنین، در Danksharding نمونهگیری در دسترس بودن دادهها ضروری است، همانطور که برای توسعه تینکلاینتهایی که دادههای تاریخی زیادی ذخیره نمیکنند لازم است (کلاینتهای بدون حالت).
@@ -77,7 +81,7 @@ Danksharding تحقق کامل مقیاسبندی رولآپی است که
### پیشرفت فعلی {#current-progress}
-هنوز چند سالی با اجرای کامل Danksharding فاصله داریم. با این حال، Proto-Danksharding اصولاً کمی زودتر از راه خواهد رسید. در زمان نگارش این مقاله (فوریه 2023) تشریفات KZG هنوز فعال است و تاکنون بیش از 50,000 مشارکتکننده را جذب کرده است. [EIP](https://eips.ethereum.org/EIPS/eip-4844) در Proto-Danksharding کامل شده، بر سر مشخصات آن توافق شده، و کلاینتها نمونههای اولیه آن را که درحال حاضر تحت آزمایش بوده و برای مرحله تولید آماده شدهاند پیادهسازی کردهاند. گام بعدی این است که تغییرات در یک شبکه تست عمومی پیادهسازی شود. شما میتوانید با استفاده از [EIP 4844 چکلیست آمادگی](https://github.com/ethereum/pm/blob/master/Dencun/4844-readiness-checklist.md)بهروز باشید.
+هنوز چند سالی با اجرای کامل Danksharding فاصله داریم. در این بین، مراسم KZG با بیش از 140،000 مشارکت کننده به پایان رسید و [EIP](https://eips.ethereum.org/EIPS/eip-4844) مربوط به پروتو-دنکشاردینگ به بلوغ رسید. این پیشنهاد به طور کامل در همه شبکههای آزمایشی پیادهسازی شده و با ارتقای شبکه Cancun-Deneb ("Dencun") در مارس 2024 در شبکه اصلی پخش شد.
### بیشتر بخوانید {#further-reading}
diff --git a/public/content/translations/fa/roadmap/dencun/index.md b/public/content/translations/fa/roadmap/dencun/index.md
new file mode 100644
index 00000000000..eaa3d7d4664
--- /dev/null
+++ b/public/content/translations/fa/roadmap/dencun/index.md
@@ -0,0 +1,120 @@
+---
+title: سوالات متداول Cancun-Deneb (Dencun)
+description: سوالات متداول در مورد ارتقاء شبکه Cancun-Deneb (Dencun)
+lang: fa
+---
+
+# Cancun-Deneb (Dencun) {#dencun}
+
+Cancun-Deneb (Dencun) یک ارتقاء شبکه اتریوم است که **پروتو-دنکشاردینگ (پیشنهاد EIP-4844)** را فعال میکند و داده های موقت **تودهها** را برای ذخیرهسازی ارزانتر رولآپ [لایه 2 (L2)](/glossary/#layer-2) معرفی می کند.
+
+یک نوع تراکنش جدید که به ارائهدهندگان رولآپ امکان میدهد داده را به صورت مقرونبهصرفهتر در آنچه به عنوان "تودهها" شناخته میشوند، ذخیره کنند. تودهها به مدت حدود 18 روز نگهداری میشوند (به طور دقیقتر در طی 4096 [ایپوک](/glossary/#epoch). پس از این دوره زمانی، تودهها از شبکه حذف میشوند، اما برنامه ها همچنان می توانند اعتبار داده های خود را با استفاده از شواهد تأیید کنند.
+
+این امر به طور قابل توجه هزینه رولآپها را کاهش میدهد، رشد زنجیره را محدود میکند و به پشتیبانی از کاربران بیشتر در عین حفظ امنیت و مجموعه غیرمتمرکز اپراتورهای گره کمک میکند.
+
+## چه زمان انتظار داریم رولآپها منعکس کننده کارمزدهای کمتر به دلیل پروتو-دنکشاردینگ باشند؟ {#when}
+
+- این ارتقا در ایپوک شماره 269568، در **13-مارس-2024 ساعت 13:55 بعد از ظهر (UTC)** فعال شد
+- همه ارائه دهندگان اصلی رولآپ، مانند آربیتروم و آپتیمیزم، نشان داده اند که تودهها بلافاصله پس از ارتقا پشتیبانی می شوند
+- جدول زمانی پشتیبانی رولآپ انفرادی ممکن است متفاوت باشد، زیرا هر ارائهدهنده باید سیستمهای خود را بهروزرسانی کند تا از فضای توده جدید استفاده کند
+
+## چگونه می توان اتر را بعد از هارد فورک تبدیل کرد؟ {#scam-alert}
+
+- **برای اتر خود هیچ حرکتی لازم نیست بزنید**: پس از ارتقاء اتریوم Dencun، نیازی به تبدیل یا ارتقاء اترهای خود ندارید. موجودی حساب شما ثابت می ماند و اتری که در حال حاضر دارید پس از هارد فورک به شکل موجود خود قابل دسترسی خواهد بود.
+- **مراقب کلاهبرداری ها باشید!** **هرکس که به شما دستور "ارتقای" اترهایتان را بدهد، سعی دارد از شما کلاهبرداری کند.** هیچ کاری نیاز نیست در رابطه با این ارتقاء انجام بدهید. به طور کامل هیچ تاثیری روی دارایی های شما ندارد. به یاد داشته باشید، آگاه ماندن بهترین دفاع در برابر کلاهبرداری است.
+
+[اطلاعات بیشتر در مورد شناخت و جلوگیری از کلاهبرداری](/security/)
+
+## ارتقای شبکه Dencun چه مشکلی را حل می کند؟ {#network-impact}
+
+دنکان در درجه اول **مقیاسپذیری** (مدیریت کاربران بیشتر و تراکنشهای بیشتر) را با **کارمزدهای مقرون به صرفه** مورد توجه قرار میدهد، در حالی که به **حفظ عدمتمرکز** در شبکه میپردازد.
+
+جامعه اتریوم برای رشد خود یک رویکرد "رولآپ-محوری" را در پیش گرفته است، که رولآپهای لایه 2 را به عنوان ابزار اصلی برای پشتیبانی ایمن از کاربرانِ بیشتر، قرار میدهد.
+
+شبکههای رولآپ پردازش _processing_ (یا "اجرای") تراکنشها را جدا از شبکه اصلی انجام میدهند و سپس یک مدرک رمزنگارشده و/یا داده تراکنش فشرده از نتایج را برای نگهداری سوابق در شبکه اصلی منتشر میکنند. ذخیرهسازی این مدارک هزینهای را به همراه دارد (در قالب [گس]](/glossary/#gas))، که قبل از پروتو-دنکشاردینگ، باید به طور دائم توسط تمام اپراتورهای گره شبکه ذخیره می شد و این کار را به یک کار گران تبدیل می کرد.
+
+معرفی پروتو-دنکشاردینگ در ارتقای Dencun، ذخیرهسازی ارزانتر دادهها را برای این اثباتها اضافه میکند، زیرا تنها اپراتورهای گره را ملزم میکند تا این دادهها را برای حدود 18 روز ذخیره کنند، پس از آن میتوان دادهها را با خیال راحت حذف کرد تا از گسترش نیازمندیهای سختافزاری جلوگیری شود. از آنجا که رولآپها معمولاً یک دوره برداشت 7 روزه دارند، مدل امنیتی آنها تا زمانی که حبابها در لایه 1 برای این مدت در دسترس باشند، تغییر نمیکنند. فرصت هرس 18 روزه یک بافر قابل توجه برای این دوره فراهم می کند.
+
+[اطلاعات بیشتر در مورد مقیاسدهی اتریوم](/نقشه راه/مقیاسپذیری/)
+
+## چگونه دسترسی به داده های قدیمی توده پیدا می شود؟ {#historical-access}
+
+در حالی که گرههای معمولی اتریوم همیشه وضعیت فعلی شبکه را حفظ میکنند، دادههای تاریخی توده تقریباً 18 روز پس از معرفی آن حذف میشوند. قبل از دور انداختن این دادهها، اتریوم اطمینان حاصل میکند که در دسترس همه شرکتکنندگان شبکه قرار گرفته است، و همچنین جهت:
+
+- علاقه مندان برای دانلود و ذخیره داده ها.
+- تکمیل تمام دوره های چالش رولآپ.
+- نهاییسازی تراکنشهای رولآپ.
+
+داده های _Historical_ blob ممکن است به دلایل مختلف مورد نظر باشند و با استفاده از چندین پروتکل غیرمتمرکز قابل ذخیره و دسترسی باشند:
+
+- **پروتکلهای ایندکسینگ طرف ثالث**، مانند The Graph، این دادهها را از طریق یک شبکه غیرمتمرکز از اپراتورهای گره ذخیره میکنند که با مکانیزمهای ارزی-اقتصادی تشویق میشوند.
+- **بیتتورنت** یک پروتکل غیرمتمرکز است که در آن داوطلبان می توانند این داده ها را در اختیار دیگران قرار دهند.
+- هدف **[شبکه پورتال اتریوم](/developers/docs/networking-layer/portal-network/)** ارائه دسترسی به تمام داده های اتریوم از طریق شبکه غیرمتمرکز اپراتورهای گره با توزیع داده ها بین شرکتکنندگان مشابه بیت تورنت است.
+- **کاربران فردی** همیشه آزادند نسخه های خود را از هر داده ای که می خواهند برای مراجعه به سابقه ذخیره کنند.
+- **ارائهدهندگان رولآپ** تشویق میشوند این دادهها را ذخیره کنند تا تجربه کاربری از رولآپ خود را افزایش دهند.
+- **کاوشگرهای بلوک** معمولاً گرههای آرشیوی را اجرا میکنند که همه این اطلاعات را برای ارجاع آسان به تاریخچه، فهرستبندی و ذخیره میکنند و برای کاربران از طریق رابط وب در دسترس هستند.
+
+توجه به این نکته مهم است که بازیابی وضعیت سابقه، بر اساس مدل اعتماد **1-از-N** عمل می کند. این به این معنی است که برای تأیید صحت آن با استفاده از وضعیت فعلی شبکه، فقط به دادههایی از یک منبع قابل اعتماد نیاز دارید.
+
+## چگونه این ارتقا به نقشه راه گستردهتر اتریوم کمک میکند؟ {#roadmap-impact}
+
+پروتو-دنکشاردینگ زمینه را برای اجرای کامل [دنکشاردینگ](/نقشه راه/دنکشاردینگ/) فراهم می کند. دنکشاردینگ برای توزیع ذخیرهسازی داده های رولآپ در میان اپراتورهای گره طراحی شده است، بنابراین هر اپراتور فقط باید بخش کوچکی از کل داده ها را مدیریت کند. این توزیع تعداد تودههای داده در هر بلوک را افزایش میدهد، که برای مقیاسپذیری اتریوم برای مدیریت کاربران و تراکنشهای بیشتر ضروری است.
+
+این مقیاسپذیری برای [پشتیبانی از میلیاردها کاربر در اتریوم] (/نقشه راه/مقیاسپذیری/) با هزینههای مقرون به صرفه و برنامههای پیشرفتهتر، و در عین حال حفظ یک شبکه غیرمتمرکز، بسیار مهم است. بدون این تغییرات، تقاضاهای سخت افزاری برای اپراتورهای گره افزایش می یابد و منجر به نیاز به تجهیزات گرانقیمت فزاینده می شود. این میتواند اپراتورهای کوچکتر را قیمتگذاری کند و منجر به تمرکز کنترل شبکه در میان چند اپراتور بزرگ شود که در تضاد با اصل عدم تمرکز است.
+
+## آیا این ارتقا بر کل اجماع اتریوم و کاربرهای اعتبارسنج تأثیر میگذارد؟ {#client-impact}
+
+بله، پروتو-دنکشاردینگ (یعنی EIP-4844) به بهروزرسانیهایی برای کاربرهای اجرا و کاربرهای اجماع نیاز دارد. همه کاربرهای اصلی اتریوم نسخههایی را منتشر کردهاند که از این ارتقا پشتیبانی میکنند. برای حفظ همگام سازی با شبکه اتریوم پس از ارتقا، اپراتورهای گره باید اطمینان حاصل کنند که نسخه کاربر پشتیبانی شده را اجرا می کنند. توجه داشته باشید که اطلاعات مربوط به نسخه های کاربر به زمان حساس است و کاربران باید برای آخرین جزئیات به آخرین بهروزرسانیها مراجعه کنند. [به جزئیات نسخههای کاربر پشتیبانیشده مراجعه کنید](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases).
+
+کاربرهای اجماع نرمافزار _Validator_ را مدیریت می کنند، که همگی برای سازگاری با ارتقاء به روز شدهاند.
+
+## Cancun-Deneb (Dencun) چگونه بر گوئرلی (Goerli) یا سایر شبکه های آزمایشی اتریوم تأثیر می گذارد؟ {#testnet-impact}
+
+- Devnets و Goerli و Sepolia و Holesky همگی تحت ارتقای Dencun قرار گرفتهاند که نتیجتاً پروتو-دنکشاردینگ عملکرد کاملی دارد
+- توسعه دهندگان رولآپ می توانند از این شبکه ها برای آزمایش EIP-4844 استفاده کنند
+- اکثر کاربران، تحت تأثیر این تغییر در هر شبکه آزمایشی قرار نخواهند گرفت
+
+## آیا همه تراکنشهای لایه 2 اکنون از فضای توده موقت استفاده میکنند یا میتوانید حق انتخاب داشته باشید؟ {#calldata-vs-blobs}
+
+تراکنشهای رولآپ در لایه 2 (L2) اتریوم امکان استفاده از دو نوع ذخیرهسازی داده را دارند: فضای توده موقت یا calldata دائمی قرارداد هوشمند. فضای توده یک انتخاب اقتصادی است که ذخیرهسازی موقت را با هزینه کمتر فراهم می کند. در دسترس بودن داده ها را برای تمام دوره های چالشی ضروری تضمین می کند. از سوی دیگر، calldata قرارداد هوشمند ذخیرهسازی دائمی را ارائه می دهد اما گرانتر است.
+
+تصمیم بین استفاده از فضای توده یا calldata در درجه اول توسط ارائه دهندگان رولآپ اتخاذ میشود. آنها این تصمیم را بر اساس تقاضای فعلی برای فضای توده میگیرند. اگر فضای توده تقاضای زیادی داشته باشد، رولآپها ممکن است برای اطمینان از ارسال به موقع دادهها، calldata را انتخاب کنند.
+
+در حالی که از نظر تئوری این امکان برای کاربران وجود دارد که نوع ذخیرهسازی مورد نظر خود را انتخاب کنند، ارائه دهندگان رولآپ معمولاً این انتخاب را مدیریت می کنند. ارائه این گزینه به کاربران پیچیدگی را به خصوص در تراکنشهای بستهبندی مقرونبهصرفه میافزاید. برای جزئیات خاص در مورد این انتخاب، کاربران باید به اسناد ارائه شده توسط ارائهدهندگان فردی رولآپ مراجعه کنند.
+
+## آیا پیشنهاد 4844 گس لایه 1 را کاهش خواهد داد؟ {#l1-fee-impact}
+
+نه زیاد. یک بازار گس جدید به طور انحصاری برای فضای توده، برای استفاده توسط ارائه دهندگان رولآپ معرفی شده است. _اگرچه ممکن است کارمزدهای لایه 1 با بارگیری دادههای رولآپ به تودهها کاهش یابد، این ارتقا در درجه اول بر کاهش کارمزدهای لایه 2 تمرکز دارد. کاهش کارمزدها در لایه 1 (شبکه اصلی) ممکن است به عنوان یک اثر مرتبه دوم به میزان کمتر رخ دهد._
+
+- کاهش گس لایه 1 متناسب با پذیرش/استفاده از داده های توده توسط ارائه دهندگان رولآپ خواهد بود
+- گس لایه 1 احتمالاً از فعالیتهای غیر-رولآپی، رقابتی باقی میماند
+- رولآپهایی که از فضای توده استفاده میکنند، گس لایه 1 کمتری نیاز دارند و به کاهش کارمزدهای گس لایه 1 در کوتاهمدت کمک میکنند
+- فضای توده هنوز محدود است، بنابراین اگر تودههای داخل یک بلوک اشباع/پر باشند، ممکن است نیاز باشد که دادههای خود را بهعنوان دادههای دائمی پست کنند، که باعث افزایش قیمت گس لایه 1 و لایه 2 میشود
+
+## آیا این امر کارمزد سایر بلاکچینهای لایه 1 EVM را کاهش میدهد؟ {#alt-l1-fee-impact}
+
+خیر. مزایای پروتو-دنکشاردینگ، مخصوص رولآپهای لایه 2 اتریوم است که اثباتهای خود را در لایه 1 (شبکه اصلی) ذخیره میکنند.
+
+صرفاً سازگاری با ماشین مجازی اتریوم (EVM) به این معنی نیست که یک شبکه هرگونه سودی از این ارتقاء خواهد دید. شبکههایی که مستقل از اتریوم کار میکنند (خواه سازگار با EVM باشند یا نباشند) دادههای خود را در اتریوم ذخیره نمیکنند و هیچ سودی از این ارتقا نخواهند دید.
+
+[اطلاعات بیشتر در مورد رولآپهای لایه 2](/layer-2/)
+
+## با توضیحات تصویری راحتترید؟ {#visual-learner}
+
+
+
+_فعالسازی مقیاسپذیری اتریوم، EIP-4844 — فینماتیکس_
+
+
+
+_آموزش فضای توده با دوموتی — توسط Bankless_
+
+## ادامه مطلب {#further-reading}
+
+- [وبسایت EIP4844.com](https://www.eip4844.com/)
+- [پیشنهاد EIP-4844: تراکنشهای توده شارد (پروتو-دنکشاردینگ)] (https://eips.ethereum.org/EIPS/eip-4844)
+- [اعلامیه شبکه اصلی دنکان](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _وبلاگ بنیاد اتریوم_
+- [راهنمای سفر به اتریوم: پروتو-دنکشاردینگ](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _توسط Jon Charbonneau_
+- [سؤالات متداول پروتو-دنکشاردینگ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _توسط ویتالیک بوترین_
+- [شرح عمیق پیشنهاد EIP-4844: هسته ارتقاء کنکان](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core- of-the-cancun-upgrade-de7b13761d2c) - _توسط Ebunker_
+- [گزارش تمام توسعههای ریشهای شماره 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _توسط تیم بیکو_
diff --git a/public/content/translations/fa/roadmap/future-proofing/index.md b/public/content/translations/fa/roadmap/future-proofing/index.md
index 4fb4f241d9e..05ac6598f41 100644
--- a/public/content/translations/fa/roadmap/future-proofing/index.md
+++ b/public/content/translations/fa/roadmap/future-proofing/index.md
@@ -11,11 +11,11 @@ template: roadmap
## مقاومت کوانتومی {#quantum-resistance}
-زمانیکه محاسبات کوانتومی به واقعیت تبدیل شوند، به طور یقین برخی از عملیات رمزنگاری که سبب ایمنسازی شبکۀ اتریوم در مقطع فعلی میگردند در معرض خطر قرار خواهند گرفت. اگرچه احتمالاً دهها سال طول بکشد تا کامپیوترهای کوانتومی تهدیدی واقعی برای رمزنگاری مدرن بهشمار آیند، اتریوم در طول این مدت به گونهای ساخته میشود که برای قرنهای آتی ایمن باشد. این بدین معنی است که [مقاومت کوانتومی اتریوم](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) به زودی محتمل خواهد بود.
+زمانی که محاسبات کوانتومی به واقعیت تبدیل شود، برخی از [رمزنگاریهای](/glossary/#cryptography) کنونی که اتریوم را ایمن ساختهاند به خطر میافتند. اگرچه احتمالاً دهها سال طول بکشد تا کامپیوترهای کوانتومی تهدیدی واقعی برای رمزنگاری مدرن بهشمار آیند، اتریوم در طول این مدت به گونهای ساخته میشود که برای قرنهای آتی ایمن باشد. این بدین معنی است که [مقاومت کوانتومی اتریوم](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) به زودی محتمل خواهد بود.
-چالش پیشِ روی توسعهدهندگان اتریوم این است که پروتکل اثبات سهام فعلی متکی بر یک مدل امضای بسیار کارآمد به نام BLS است که برای جمعآوری آرا در بلوکهای معتبر مورد استفاده قرار میگیرد. این مدل امضا در برابر کامپیوترهای کوانتومی شکننده است، اما جایگزینهای مقاوم در برابر کوانتوم نیز آنچنان کارآمد نیستند.
+چالش پیش روی توسعه دهندگان اتریوم این است که پروتکل [اثبات سهام](/glossary/#pos) کنونی بر یک طرح امضای بسیار کارآمد به نام BLS برای گردآوری آرا در [بلوک](/glossary/#block) معتبر متکی است. این مدل امضا در برابر کامپیوترهای کوانتومی شکننده است، اما جایگزینهای مقاوم در برابر کوانتوم نیز آنچنان کارآمد نیستند.
-[مدلهای تعهدی KZG](/roadmap/danksharding/#what-is-kzg) که در چندین جا در سرتاسر شبکۀ اتریوم برای تولید رازهای رمزنگاریشده استفاده میشوند از جمله مدلهایی هستند که آسیبپذیریشان در برابر کوانتوم شناختهشده است. درحال حاضر، این مسئله با استفاده از «تنظیمات قابل اعتماد» دور زده میشود، یعنی جایی که در آن بسیاری از کاربران قابلیت انتخاب تصادفی را ایجاد میکنند و انجام مهندسی معکوس روی این قابلیت توسط کامپیوترهای کوانتومی امکانپذیر نیست. با این حال، راهحل ایدهآل این است که خیلی ساده به جای این روشها از رمزنگاری ایمن کوانتومی استفاده شود. دو رویکرد پیشرو در این زمینه وجود دارند که میتوانند جایگزینهای کارآمدی برای مدل BLS باشند: مدلهای امضا به نامهای [STARK-based](https://hackmd.io/@vbuterin/stark_aggregation) و [lattice-based](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). این دو مدل همچنان در مرحلۀ تحقیق و نمونهسازی اولیه هستند.
+[مدلهای تعهدی KZG](/roadmap/danksharding/#what-is-kzg) که در چندین جا در سرتاسر شبکۀ اتریوم برای تولید رازهای رمزنگاریشده استفاده میشوند از جمله مدلهایی هستند که آسیبپذیریشان در برابر کوانتوم شناختهشده است. درحال حاضر، این مسئله با استفاده از «تنظیمات قابل اعتماد» دور زده میشود، یعنی جایی که در آن بسیاری از کاربران قابلیت انتخاب تصادفی را ایجاد میکنند و انجام مهندسی معکوس روی این قابلیت توسط کامپیوترهای کوانتومی امکانپذیر نیست. با این حال، راهحل ایدهآل این است که خیلی ساده به جای این روشها از رمزنگاری ایمن کوانتومی استفاده شود. دو رویکرد پیشرو در این زمینه وجود دارند که میتوانند جایگزینهای کارآمدی برای مدل BLS باشند: مدلهای امضا به نامهای [STARK-based](https://hackmd.io/@vbuterin/stark_aggregation) و [lattice-based](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **اینها هنوز در مرحله تحقیق و نمونه سازی هستند**.
درباره KZG و تنظیمات مورد اعتماد بخوانید
@@ -23,16 +23,16 @@ template: roadmap
پیچیدگیِ یک شبکه فرصتهای زیادی برای انواع باگها یا آسیبپذیریها ایجاد میکند که میتواند سبب سوءاستفاده مهاجمان شود. بنابراین، بخشی از نقشۀ راه را سادهسازیِ شبکۀ اتریوم و حذف کدهایی تشکیل میدهد که از طریق بهروزرسانیهای مختلف گریبانگیر شبکه شدهاند ولی دیگر نه مورد نیاز هستند و نه میتوان آنها را بهبود بخشید. نگهداری و استدلال یک پایگاه کد کوچکتر و سادهتر برای توسعهدهندگان آسانتر است.
-چندین بهروزرسانی در راه است تا روی [ماشین مجازی اتریوم (EVM)](/developers/docs/evm) اعمال شود و آن را سادهتر و کارآمدتر کند. یکی از این بهروزرسانیها [حذف کد عملیاتی SELFDESTRUCT](https://hackmd.io/@vbuterin/selfdestruct) است – دستوری که به ندرت مورد استفاده قرار میگیرد و دیگر مورد نیاز نیست و حتی در برخی از شرایط استفاده از آن میتواند خطرناک هم باشد، مخصوصاً زمانی که با سایر ارتقاهای مدلهای ذخیرهسازی اتریوم در آینده ترکیب شود. کلاینتهای اتریوم نیز هنوز از تعدادی مدلهای تراکنشیِ قدیمی که اکنون میتوان آنها را کاملاً حذف نمود، پشتیبانی میکنند. روشی که در آن گس شبکه محاسبه میشود نیز میتواند بهبود یابد و حتی روشهای کارآمدتری برای محاسبات زیربناییِ تعدادی از عملیات رمزنگاری ایجاد گردد.
+چندین بهروزرسانی در راه است تا روی [ماشین مجازی اتریوم (EVM)](/developers/docs/evm) اعمال شود و آن را سادهتر و کارآمدتر کند. یکی از این بهروزرسانیها [حذف کد عملیاتی SELFDESTRUCT](https://hackmd.io/@vbuterin/selfdestruct) است – دستوری که به ندرت مورد استفاده قرار میگیرد و دیگر مورد نیاز نیست و حتی در برخی از شرایط استفاده از آن میتواند خطرناک هم باشد، مخصوصاً زمانی که با سایر ارتقاهای مدلهای ذخیرهسازی اتریوم در آینده ترکیب شود. [کاربرهای اتریوم](/glossary/#consensus-client) همچنین از برخی از انواع تراکنشهای قدیمی پشتیبانی میکنند که اکنون میتوانند به طور کامل حذف شوند. نحوه محاسبه [گس](/glossary/#gas) نیز می تواند بهبود یابد و روش های کارآمدتری برای محاسبات زیربنای برخی عملیات رمزنگاری ارائه شود.
به همین ترتیب، بهروزرسانیهایی وجود دارند که میتوانند برای بخشهای دیگری از کلاینتهای امروزی اتریوم اعمال شوند. یک مثال در رابطه با این موضوع این است که در حال حاضر کلاینتهای اجرا و اجماع از نوع متفاوتی از فشردهسازی دادهها استفاده میکنند. هنگامی که یکپارچهسازیِ طرح فشردهسازی در کل شبکه انجام بگیرد، اشتراکگذاریِ دادهها بین کلاینتها بسیار سادهتر و شهودیتر خواهد شد.
## پیشرفت فعلی {#current-progress}
-بیشتر ارتقاهای مورد نیاز برای آیندۀ شبکۀ اتریوم هنوز در مرحلۀ تحقیقاتی هستند و ممکن است چندین سال تا اجرایی شدنشان فاصله داشته باشند. ارتقاهایی مثل حذف کد SELF-DESTRUCT و هماهنگ کردنِ طرح فشردهسازی مورد استفاده در کلاینتهای اجرا و اجماع به احتمال زیاد زودتر از رمزنگاریِ مقاوم در برابر کوانتوم ایجاد شوند.
+بسیاری از ارتقاهای مورد نیاز برای اتریومِ مقاوم در آینده **هنوز در مرحله تحقیقاتی هستند و ممکن است چندین سال تا اجرای آن فاصله داشته باشد**. بهروزرسانیهایی مانند حذف SELFDESTRUCT و هماهنگ کردن طرح فشردهسازی مورد استفاده در کاربرهای لایههای اجرا و اجماع احتمالاً زودتر از رمزنگاری مقاوم در برابر کوانتوم انجام میشوند.
**بیشتر بخوانید**
- [گاز](/developers/docs/gas)
- [ماشین مجازی اتریوم (EVM)](/developers/docs/evm)
-- [Data structures](/developers/docs/data-structures-and-encoding)
+- [ساختارهای داده](/developers/docs/data-structures-and-encoding)
diff --git a/public/content/translations/fa/roadmap/index.md b/public/content/translations/fa/roadmap/index.md
index c8ecb487b48..6b73bbeb746 100644
--- a/public/content/translations/fa/roadmap/index.md
+++ b/public/content/translations/fa/roadmap/index.md
@@ -61,7 +61,7 @@ buttons:
-عمدۀ این نقشۀ راه حاصل سالها تلاش پژوهشگران و توسعهدهندگان است، زیرا این پروتکل بسیار تخصصی است. با این حال، هر فرد باانگیزهای میتواند در این مسیر سهیم باشد. خاستگاه اصلی ایدهها معمولا بحثهایی است که در انجمنهای مختلف شکل میگیرد، ازجمله [ethresear.ch](https://ethresear.ch/)، [جادوگران اتریوم] (https://www.figma.com/exit?url=https%3A%2F%2Fethereum-magicians.org%2F) یا سرور دیسکورد تحقیق و توسعۀ اتریوم. این بحثها ممکن است در پی کشف آسیبهای جدید شبکه شکل بگیرد یا ممکن است پیشنهاداتی از طرف سازمانهای فعال در لایۀ برنامه (مثل dappها یا صرافیها) یا از اصطحلاکات شناختهشدهای باشد که کاربران نهایی متحمل میشوند (مثل هزینهها یا سرعت تراکنشها). زمانی که این ایدهها تکامل یافتند، میتوانند در قالب [پیشنهاد بهبود اتریوم] مطرح شوند (https://eips.ethereum.org/). تمام این فرآیند به شکل عمومی صورت میگیرد تا هر فردی از این جامعه بتواند هر زمانی در آن نقش داشته باشد.
+عمدۀ این نقشۀ راه حاصل سالها تلاش پژوهشگران و توسعهدهندگان است، زیرا این پروتکل بسیار تخصصی است. با این حال، هر فرد باانگیزهای میتواند در این مسیر سهیم باشد. ایدهها معمولاً با بحث در انجمنی مانند [ethresear.ch](https://ethresear.ch/)، انجمن [Ethereum Magicians] (https://ethereum-magicians.org/) یا سرور دیسکورد Eth R&D شروع میشوند. آنها ممکن است پاسخی به آسیبپذیریهای جدیدی باشند که کشف میشوند، پیشنهادات سازمانهایی باشند که در لایه برنامه کار میکنند (مانند [دپ ها](/glossary/#dapp) و صرافی ها) یا از اصطکاکهای شناخته شده برای کاربران نهایی (مانند هزینهها یا سرعتهای تراکنش) باشند. زمانی که این ایدهها تکامل یافتند، میتوانند در قالب [پیشنهاد بهبود اتریوم] مطرح شوند (https://eips.ethereum.org/). تمام این فرآیند به شکل عمومی صورت میگیرد تا هر فردی از این جامعه بتواند هر زمانی در آن نقش داشته باشد.
[مطالب بیشتر درباره حاکمیت اتریوم](/governance/)
@@ -70,42 +70,42 @@ buttons:
ETH2 چه بود؟
- اصطلاح «Eth2» به طور متداول در توصیف آیندۀ اتریوم به کار برده میشد پیش از اینکه به مکانیزم اثبات سهام انتقال یابد، اما به تدریج با ظهور اصطلاحات دقیقتر، این واژه کنار گذاشته شد.این اصطلاح درابتدا برای توضیح تمایز بین شبکه اتریوم قبل از انتقال به مکانیزم اثبات سهام با وضعیت بعد از آن، و گاهی هم برای اشاره به تمایز بین فعالیت کلاینتها مورد استفاده قرار میگرفت (گاهی از اصطلاح کلاینت ETH1 برای اطلاق به کلاینتهای اجرا و از کلاینت ETH2 برای اطلاق به کلاینتهای اجماع استفاده میشد.).
+ اصطلاح "Eth2" معمولا برای توصیف آینده اتریوم قبل از تغییر به اثبات سهام استفاده میشد، اما در راستای اصطلاحات دقیقتر حذف شد. در ابتدا برای متمایز کردن شبکه اتریوم قبل از تغییر به اثبات سهام و شبکه بعد از آن استفاده می شد، یا گاهی اوقات برای اشاره به کاربرهای مختلف اتریوم (کلاینتهای اجرا) به نام کاربرهای ETH1 شناخته میشدند و کاربرهای اجماع گاهی اوقات به عنوان کاربرهای ETH2 شناخته می شدند.
## آیا نقشه راه اتریوم به مرور زمان تغییر خواهد کرد؟ {#will-ethereums-roadmap-change-over-time}
-بله، تقریباً قطعی است. نقشه راه اتریوم درواقع همان طرح کنونی برای ارتقای اتریوم است که هم طرحهای میانمدت را شامل میشود و هم طرحهای بلندمدت را. با در دسترس شدن اطلاعات و فناری جدید انتظار داریم که تغییراتی در نقشه راه ایجاد شود.
+**بله—تقریباً قطعاً**. نقشه راه اتریوم درواقع همان طرح کنونی برای ارتقای اتریوم است که هم طرحهای میانمدت را شامل میشود و هم طرحهای بلندمدت را. با در دسترس شدن اطلاعات و فناری جدید انتظار داریم که تغییراتی در نقشه راه ایجاد شود.
-نقشه راه اتریوم را میتوان به عنوان مجموعهای از ایدهها و تصمیمگیریها برای ارتقای شبکه اتریوم در نظر گرفت. در واقع، این مجموعه در قلب بهترین فرضیههای محققان و توسعهدهندگان درخصوص بهینهترین مسیر پیش روی اتریوم قرار دارد.
+به نقشه راه اتریوم به عنوان مجموعه ای از اهداف برای بهبود اتریوم فکر کنید. این بهترین فرضیه اصلی محققان و توسعهدهندگان در مورد بهینه ترین مسیر پیشروی اتریوم است.
## نقشه راه کی به پایان میرسد؟ {#when-will-the-roadmap-be-finished}
-برخی از ارتقاهای شبکه اتریوم طی شش ماه آینده پیادهسازی خواهد شد (مثل امکان خارج کردن سهام اتریوم)؛ اما برخی دیگر، در اولویت پایینتری بوده و احتمالاً طی 5 تا 10 سال آتی اجرایی نخواهند شد (مثل پروژه مقاومت کوانتومی). تخمین اینکه هر کدام از ارتقاهای اتریوم دقیقاً در چه تاریخی رخ خواهد داد کار دشواری است، چراکه روی بسیاری از عناصر نقشۀ راه به شکل همزمان کار میشود و توسعه آنها با سرعتهای متفاوتی انجام میشود. از طرفی، اولویت پیادهسازی یک ارتقا نیز ممکن است با توجه به عوامل خارجی تغییر کند (به عنوان نمونه، جهش ناگهانی در عملکرد و دسترسیپذیری به کامپیوترهای کوانتومی میتواند رمزنگاری با مقاومت کوانتومی را در اولویت بالاتری قرار دهد).
+برخی از ارتقاء ها اولویت پایینتری دارند و احتمالاً تا 5 تا 10 سال آینده اجرا نخواهند شد (مثلاً مقاومت در برابر محاسبات کوانتومی). **ارائه زمان دقیق برای هر ارتقا پیشبینی را پیچیده میکند** زیرا بسیاری از موارد نقشه راه به صورت موازی کار میشوند و با سرعتهای مختلف توسعه مییابند. از طرفی، اولویت پیادهسازی یک ارتقا نیز ممکن است با توجه به عوامل خارجی تغییر کند (به عنوان نمونه، جهش ناگهانی در عملکرد و دسترسیپذیری به کامپیوترهای کوانتومی میتواند رمزنگاری با مقاومت کوانتومی را در اولویت بالاتری قرار دهد).
یکی از راههای ادراک فرآیند توسعه اتریوم مقایسه آن با تکامل زیستی است. شبکهای که در مواجهه با چالشهای جدید، قدرت سازگاری و تطبیقپذیری بالاتری دارد شانس موفقیت بیشتری نسبت به شبکهای دارد که در مقابل تغییرات مقاومت میکند، البته هرچه شبکه قدرت بیشتری در عملکرد پیدا کند، تغییرات کمتری برای مقیاسپذیری و تأمین امنیت روی پروتکل لازم خواهد بود.
## آیا لازم است در مواجهه با ارتقای شبکه کاری صورت دهم؟ {#do-i-have-to-do-anything-when-there-is-an-upgrade}
-ارتقاهای شبکه معمولاً تأثیر مستقیمی بر کاربران نهایی شبکه ندارد، جز اینکه کاربران نهایی میتوانند تجربه کاربری بهتر، پرتوکلی امنتر یا شاید امکانات بیشتری برای تعامل با شبکه اتریوم را تجربه کنند. در واقع کاربران نهایی شبکه نیاز نیست برای ارتقای شبکه کار در عمل اقدامی صورت دهند یا کاری برای تأمین امنیت داراییهای خود انجام دهند. اپراتورهای گره باید کلاینتهایشان را درجهت آمادگی برای ارتقا بهروزرسانی کنند. برخی از ارتقاها ممکن است موجب تغییراتی در روند کار توسعهدهندگان برنامههای کاربردی شود. به عنوان نمونه، ارتقاهای مربوط به دوره اتمام تاریخچه ممکن است توسعهدهندگان را به سمت کسب دادههای پیشینهای از منابع جدید سوق دهد.
+ارتقاهای شبکه معمولاً تأثیر مستقیمی بر کاربران نهایی شبکه ندارد، جز اینکه کاربران نهایی میتوانند تجربه کاربری بهتر، پرتوکلی امنتر یا شاید امکانات بیشتری برای تعامل با شبکه اتریوم را تجربه کنند. **کاربران عادی نیازی به مشارکت فعال در ارتقاء ندارند و از آنها نیز خواسته نمیشود کاری انجام دهند** که داراییهای خود را حفظ کنند. اپراتورهای [گره](/glossary/#node) باید کاربرهای خود را بهروز کنند تا برای ارتقا آماده شوند. برخی از ارتقاها ممکن است موجب تغییراتی در روند کار توسعهدهندگان برنامههای کاربردی شود. به عنوان نمونه، ارتقاهای مربوط به دوره اتمام تاریخچه ممکن است توسعهدهندگان را به سمت کسب دادههای پیشینهای از منابع جدید سوق دهد.
## ارتقاهای Verge و Splurge و غیره، چه نقشی در بهبود شبکه ایفا میکنند؟ {#what-about-the-verge-splurge-etc}
-[«ویتالیک بوترین» چشماندازی را برای نقشه راه اتریوم پیشنهاد داد.](https://twitter.com/VitalikButerin/status/1588669782471368704) این چشمانداز شامل طبقهبندیهای مختلفی بود که ازلحاظ اثراتشان روی ساختار شبکه اتریوم به هم متصل بودند. این چشمانداز شامل موارد زیر میشد:
+[«ویتالیک بوترین» چشماندازی را برای نقشه راه اتریوم پیشنهاد داد.](https://twitter.com/VitalikButerin/status/1741190491578810445) این چشمانداز شامل طبقهبندیهای مختلف بود که از لحاظ اثراتشان روی ساختار شبکه اتریوم به هم متصل بودند. این چشمانداز شامل موارد زیر میشد:
-- • Merge: ارتقاهایی در ارتباط با تغییر مکانیزم شبکه از اثبات کار به اثبات سهام
-- • Surge: ارتقای مرتبط با افزایش مقیاسپذیری با استفاده از رولآپها و شاردینگ دادهها (زنجیرهایسازی)
-- • Scourge: ارتقای مرتبط با مقاومت در برابر سانسور اطلاعات، غیرمتمرکزسازی و خطرات پروتکل از MEV
-- • Verge: ارتقاهای مرتبط با تسهیل تأیید اعتبار بلوکها
-- • Purge: ارتقاهای مرتبط با کاهش هزینههای محاسباتی اجرای گرهها و سادهسازی پروتکل
-- • Splurge: برخی دیگر از ارتقاهای اتریوم که در دستهبندیهای پیشین نمیگنجد.
+- **ادغام**: ارتقاهای مربوط به تغییر از [اثبات کار](/glossary/#pow) به [اثبات سهام](/glossary/#pos)
+- **موج بلند**: ارتقاهای مربوط به مقیاس پذیری توسط [رولآپها](/glossary/#rollups) و شاردینگ داده
+- **شلاق**: ارتقاهای مربوط به مقاومت در برابر سانسور، عدم تمرکز و خطرات پروتکل از سمت [MEV](/glossary/#mev)
+- **نزدیکی**: ارتقاهای مربوط به تأیید آسانتر [بلوکها](/glossary/#block)
+- **پالایش**: ارتقاهای مربوط به کاهش هزینههای محاسباتی گرههای در حال اجرا و سادهسازی پروتکل
+- **ریخت و پاش**: ارتقاءهای دیگر که به خوبی در دسته های قبلی قرار نمی گیرند.
ما تصمیم گرفتیم از این اصطلاحات استفاده نکنیم چراکه میخواستیم از یک مدل سادهتر و کاربرپسندتر استفاده کنیم. اگرچه از زبانی با محوریت کاربران استفاده میکنیم، اما اصل چشمانداز همان است که «ویتالیک» پیشنهاد داد.
## درباره شاردینگ چه میدانید؟ {#what-about-sharding}
-مکانیزم شاردینگ به معنای تقسیم زنجیره بلوکی اتریوم به طوری که زیرمجموعههای اعتبارسنجها تنها مسئولیت کسری از کل دادهها را برعهده دارند. قصد این مکانیزم در ابتدا این بود که راهی برای افزایش مقیاسپذیری اتریوم باشد. با این حال، رولآپهای لایه دوم با سرعت بسیار بیشتر از حد مورد انتظار توسعه یافتهاند و تاکنون مقیاسپذیری زیادی را فراهم کرده است. این توان مقیاسپذیری پس از پیادهسازی Proto-Danksharding بسیار بیشتر هم خواهد شد. به عبارتی، «خردهزنجیرهها» دیگر به کار نخواهد آمد و از نقشه راه اتریوم حذف شدهاند.
+شاردینگ یعنی تقسیم بلاکچین اتریوم طوری که زیرمجموعههای [اعتبارسنجها](/glossary/#validator) تنها مسئول کسری از کل داده هستند. قصد این مکانیزم در ابتدا این بود که راهی برای افزایش مقیاسپذیری اتریوم باشد. با این حال، رولآپهای [لایه 2](/glossary/#layer-2) بسیار سریعتر از آنچه انتظار میرفت توسعه یافتهاند و در حال حاضر مقیاسگذاری زیادی را ارائه کردهاند، و پس از اجرای پروتو-دنکشاردینگ بسیار بیشتر خواهند بود. به عبارتی، «خردهزنجیرهها» دیگر به کار نخواهد آمد و از نقشه راه اتریوم حذف شدهاند.
## به دنبال ارتقاهای فنی خاصی میگردید؟ {#looking-for-specific-technical-upgrades}
diff --git a/public/content/translations/fa/roadmap/merge/index.md b/public/content/translations/fa/roadmap/merge/index.md
index a494e0ac963..1e87ad09518 100644
--- a/public/content/translations/fa/roadmap/merge/index.md
+++ b/public/content/translations/fa/roadmap/merge/index.md
@@ -4,6 +4,7 @@ description: توضیحاتی درباره ادغام (The Merge) - وقتی ش
lang: fa
template: upgrade
image: /images/upgrades/merge.png
+alt:
summaryPoint1: '«شبکه اصلی اتریوم» از مکانیزم اثبات سهام استفاده میکند، اما همیشه اینگونه نبوده است.'
summaryPoint2: به ارتقایی که مکانیزم اصلی اثبات کار را به اثبات سهام تغییر داد ادغام گفته میشود.
summaryPoint3: رویداد «ادغام» به ادغام شدن شبکه اصلی اتریوم و یک زنجیره بلوکی جداگانه اثبات سهام به اسم زنجیره بیکن (Beacon Chain) اشاره دارد که اکنون به صورت یک زنجیره واحد وجود دارند.
@@ -105,7 +106,7 @@ id="developers">
## ادغام و مصرف انرژی {#merge-and-energy}
-«ادغام» پایان مکانیزم اثبات کار برای اتریوم و شروع عصر تازهای از اتریوم پایدارتر و دوستدار محیط زیست را رقم زد. مصرف انرژی اتریوم 99/95 درصد کاهش یافت و اتریوم را به یک زنجیره بلوکی سبز تبدیل کرد. دربارۀ [مصرف انرژی اتریوم](/energy-consumption/) بیشتر بدانید.
+ادغام پایان اثبات کار برای اتریوم بود و عصر اتریوم پایدارتر و سازگارتر با محیط زیست را آغاز کرد. مصرف انرژی اتریوم 99/95 درصد کاهش یافت و اتریوم را به یک زنجیره بلوکی سبز تبدیل کرد. دربارۀ [مصرف انرژی اتریوم](/energy-consumption/) بیشتر بدانید.
## «ادغام» و مقیاسپذیری {#merge-and-scaling}
diff --git a/public/content/translations/fa/roadmap/pbs/index.md b/public/content/translations/fa/roadmap/pbs/index.md
index 0099fcdcc49..3e50e33d583 100644
--- a/public/content/translations/fa/roadmap/pbs/index.md
+++ b/public/content/translations/fa/roadmap/pbs/index.md
@@ -20,7 +20,7 @@ lang: fa
-سازمانهای قدرتمند میتوانند اعتبارسنجها را تحت فشار قرار دهند که تراکنشها را از آدرسهایی مشخص یا به آدرسهایی مشخص سانسور کنند. اعتبارسنجها با شناسایی آدرسهای لیست سیاه در استخر تراکنشها و حذف آنها از بلوکهای پیشنهادی، از این فشار جلوگیری میکنند. پس از PBS این دیگر امکانپذیر نخواهد بود، چراکه پیشنهاددهندگان بلوک نمیدانند کدام تراکنشها را در بلوکهای خود پخش میکنند. ممکن است برای افراد یا برنامههای خاصی رعایت قوانین سانسور مهم باشد، برای مثال زمانی که این قانون در منطقه آنها اجرایی شده است. در این موارد، پیروی از قوانین در سطح برنامه اتفاق میافتد، در حالی که پروتکل بدون مجوز و بدون سانسور باقی میماند.
+سازمانهای قدرتمند میتوانند اعتبارسنجها را تحت فشار قرار دهند که تراکنشها را از آدرسهایی مشخص یا به آدرسهایی مشخص سانسور کنند. اعتبارسنجها با شناسایی آدرسهای لیست سیاه در مخزن تراکنشها و حذف آنها از بلوکهایی که پیشنهاد میکنند، با این فشار سازگار میشوند. پس از PBS این دیگر امکانپذیر نخواهد بود، چراکه پیشنهاددهندگان بلوک نمیدانند کدام تراکنشها را در بلوکهای خود پخش میکنند. ممکن است برای افراد یا برنامههای خاصی رعایت قوانین سانسور مهم باشد، برای مثال زمانی که این قانون در منطقه آنها اجرایی شده است. در این موارد، پیروی از قوانین در سطح برنامه اتفاق میافتد، در حالی که پروتکل بدون مجوز و بدون سانسور باقی میماند.
diff --git a/public/content/translations/fa/roadmap/scaling/index.md b/public/content/translations/fa/roadmap/scaling/index.md
index 56fd49cccc4..9d34b178fbd 100644
--- a/public/content/translations/fa/roadmap/scaling/index.md
+++ b/public/content/translations/fa/roadmap/scaling/index.md
@@ -1,6 +1,6 @@
---
title: مقیاسپذیری اتریوم
-description: رولآپها تراکنشها را خارج از زنجیره گردآوری میکنند و هزینه را برای کاربر کاهش میدهند. با این حال، روش فعلی رولآپها در استفاده از اطلاعات بسیار گران است و میزان ارزان شدن تراکنشها را محدود میکند. Proto-Danksharding مشکل را برطرف خواهد کرد.
+description: رولآپها تراکنشها را خارج از زنجیره گردآوری میکنند و هزینه را برای کاربر کاهش میدهند. با این حال، روشی که در حال حاضر رولآپها از داده استفاده میکنند، بسیار گران است و میزان ارزان بودن تراکنشها را محدود میکند. Proto-Danksharding مشکل را برطرف خواهد کرد.
lang: fa
image: /images/roadmap/roadmap-transactions.png
alt: "نقشه راه اتریوم"
@@ -11,7 +11,7 @@ template: roadmap
- - در حال حاضر رولآپها تقریباً 3 تا 8 برابر ارزانتر از لایه 1 اتریوم هستند
+ - رولآپهای امروزی حدود 5 تا 20 برابر ارزانتر از لایه 1 اتریوم هستند
- رولآپهای ZK به زودی کارمزدها را 40 تا 100 برابر ارزانتر خواهد کرد
- تغییرات آتی اتریوم مقیاسپذیری را تقریباً بین 100 تا 1000 برابر افزایش خواهد داد
- کاربران باید از تراکنشهایی با هزینه کمتر از 0.001 دلار بهرهمند شوند
@@ -24,26 +24,28 @@ template: roadmap
### Proto-Danksharding {#proto-danksharding}
-دادههای رولآپ به صورت دائمی در اتریوم ذخیره شده است، که هزینهبر است. بیش از 90 درصد از هزینه تراکنشهایی که کاربران در رولآپها پرداخت میکنند به دلیل ذخیرهسازی این دادهها پرداخت میشود. برای کاهش هزینههای تراکنش، میتوانیم اطلاعات را به یک حافظه موقت جدید از نوع «تودهای» انتقال دهیم. تودهها ارزانتر هستند چراکه دائمی نیستند؛ زمانی که دیگر مورد نیاز نباشند از اتریوم حذف میشوند. ذخیرهسازی دادههای رولآپ در بلندمدت به عهده افرادی است که به آن نیاز دارند، مانند اپراتورهای رولآپ، صرافیها، خدمات نمایهسازی و غیره. افزودن تراکنشهای تودهای به اتریوم بخشی از ارتقای شناختهشده تحت عنوان «Proto-Danksharding» است. انتظار میرود به زودی—شاید در اواخر سال 2023—محقق شود.
+داده رولآپ در گذشته بهطور دائم در اتریوم ذخیره شده است که البته گران است. بیش از 90 درصد از هزینه تراکنشهایی که کاربران در رولآپها پرداخت میکنند به دلیل ذخیرهسازی این دادهها پرداخت میشود. برای کاهش هزینههای تراکنش، میتوانیم اطلاعات را به یک حافظه موقت جدید از نوع «تودهای» انتقال دهیم. تودهها ارزانتر هستند چراکه دائمی نیستند؛ زمانی که دیگر مورد نیاز نباشند از اتریوم حذف میشوند. ذخیرهسازی داده رولآپ در درازمدت به عهده افرادی است که به آن نیاز دارند، مانند اپراتورهای رولآپ، صرافی ها، خدمات ایندکسینگ و غیره. افزودن تراکنشهای تودهای به اتریوم بخشی از ارتقای شناختهشده تحت عنوان «Proto-Danksharding» است.
-پس از اینکه تراکنشهای تودهای از طریق Proto-Danksharding بخشی از پروتکل اتریوم شدند، اضافه کردن تعداد زیادی توده به بلوکهای اتریوم امکانپذیر خواهد بود. این یک افزایش قابل توجه دیگر (>100 برابر) برای تعداد دادههای ورودی اتریوم و کاهش هزینههای تراکنش خواهد بود.
+با پروتو-دنکشاردینگ، میتوان تعداد زیادی Blob به بلوکهای اتریوم اضافه کرد. این امر، یک افزایش قابل توجه (>100برابری) دیگر در مقیاسدهی به اتریوم و کاهش هزینههای تراکنش را ممکن می کند.
### دانکشاردینگ {#danksharding}
-مرحله دومِ گسترش دادههای تودهای پیچیده است، چراکه به روشهای جدیدی برای بررسی وجود اطلاعات جمعبندی شده در شبکه نیاز دارد و به اعتبارسنجهایی متکی است که مسئولیتهای بلوکسازی را از مسئولیتهای پیشنهاد دادن بلوک جدا کردهاند. همچنین نیاز به روشی دارد که بهصورت رمزنگاری ثابت کند اعتبارسنجها زیرمجموعههای کوچکی از دادههای تودهای را تأیید کردهاند.
+مرحله دوم گسترش داده blob پیچیده است زیرا به روشهای جدیدی برای بررسی وجود داده رولآپ در شبکه نیاز دارد و به [اعتبارسنجها](/glossary/#validator) متکی است که مسئولیتهای ساخت بلوک و مسئولیتهای پیشنهاد [بلوک](/glossary/#block) آن را از هم جدا میکنند. همچنین نیاز به روشی دارد که بهصورت رمزنگاری ثابت کند اعتبارسنجها زیرمجموعههای کوچکی از دادههای تودهای را تأیید کردهاند.
-این مرحلۀ دوم به عنوان [Danksharding](/roadmap/danksharding/) شناخته میشود. احتمالاً چندین سال تا اجرای کامل آن باقی مانده است. Danksharding به پیشرفتهای دیگری مانند [تفکیک مسئولیت بلوکسازی و پیشنهاد بلوک](/roadmap/pbs) و طرحهای جدید شبکه متکی است که شبکه را قادر میسازد تا با نمونهبرداری تصادفی چند کیلوبایتی در لحظه، به طور مؤثر تأیید کند که دادهها در دسترس هستند. این روند تحت عنوان [نمونهگیری دسترسیپذیری به دادهها (DAS)](/developers/docs/data-availability) شناخته میشود.
+این مرحلۀ دوم به عنوان [Danksharding](/roadmap/danksharding/) شناخته میشود. **احتمالاً چندین سال** تا اجرای کامل آن فاصله وجود دارد. Danksharding به پیشرفتهای دیگری مانند [تفکیک مسئولیت بلوکسازی و پیشنهاد بلوک](/roadmap/pbs) و طرحهای جدید شبکه متکی است که شبکه را قادر میسازد تا با نمونهبرداری تصادفی چند کیلوبایتی در لحظه، به طور مؤثر تأیید کند که دادهها در دسترس هستند. این روند تحت عنوان [نمونهگیری دسترسیپذیری به دادهها (DAS)](/developers/docs/data-availability) شناخته میشود.
اطلاعات بیشتر در مورد Danksharding
## غیرمتمرکزسازی رولآپها {#decentralizing-rollups}
-[رولآپها](/layer-2) اکنون نیز در حال افزایش مقیاسپذیری اتریوم هستند. یک [اکوسیستم غنی از پروژههای رولآپ](https://l2beat.com/scaling/tvl) به کاربران امکان میدهد تا تراکنشها را با سرعت بیشتر و هزینه ارزانتر، با طیف وسیعی از ضمانتهای امنیتی انجام دهند. با این حال، رولآپها با استفاده از توالیگرهای متمرکز (رایانههایی که تمام پردازش تراکنشها و گردآوری را قبل از ارسال به اتریوم انجام میدهند) بوت استرپ شدهاند. این امر در برابر سانسور آسیبپذیر است، زیرا اپراتورهای توالیگر میتوانند تحریم شوند، رشوه بگیرند یا بهشکل دیگری در معرض خطر قرار گیرند. همزمان، [رولآپها عملکرد متفاوتی](https://l2beat.com) در روش معتبر ساختن دادههای ورودی دارند. بهترین راه این است که «اثباتکنندگان»، اثبات تقلب یا اثبات اعتبار ارائه کنند، اما هنوز همه رولآپها حضور ندارند. حتی آن دسته از رولآپهایی که از اثبات اعتبار/تقلب استفاده میکنند، از مجموعه کوچکی از اثباتکنندههای شناختهشده استفاده میکنند. بنابراین، گام مهم بعدی در مقیاسپذیری اتریوم این است که مسئولیت اجرای توالیگرها و اثباتکنندهها بین افراد بیشتری توزیع شود.
+[رولآپها](/layer-2) اکنون نیز در حال افزایش مقیاسپذیری اتریوم هستند. یک [اکوسیستم غنی از پروژههای رولآپ](https://l2beat.com/scaling/tvl) به کاربران امکان میدهد تا تراکنشها را با سرعت بیشتر و هزینه ارزانتر، با طیف وسیعی از ضمانتهای امنیتی انجام دهند. با این حال، رولآپها با استفاده از توالیگرهای متمرکز (رایانههایی که تمام پردازش تراکنشها و گردآوری را قبل از ارسال به اتریوم انجام میدهند) بوت استرپ شدهاند. این امر در برابر سانسور آسیبپذیر است، زیرا اپراتورهای توالیگر میتوانند تحریم شوند، رشوه بگیرند یا بهشکل دیگری در معرض خطر قرار گیرند. همزمان، [رولآپها عملکرد متفاوتی](https://l2beat.com) در روش معتبر ساختن دادههای ورودی دارند. بهترین راه این است که "اثبات کننده ها" [اثبات تقلب](/glossary/#fraud-proof) یا اثبات اعتبار ارائه کنند، اما هنوز همه رولآپها وجود ندارد. حتی آن دسته از رولآپهایی که از اثبات اعتبار/تقلب استفاده میکنند، از مجموعه کوچکی از اثباتکنندههای شناختهشده استفاده میکنند. بنابراین، گام مهم بعدی در مقیاسپذیری اتریوم این است که مسئولیت اجرای توالیگرها و اثباتکنندهها بین افراد بیشتری توزیع شود.
اطلاعات بیشتر درباره رولآپها
## پیشرفت فعلی {#current-progress}
-Proto-Danksharding احتمالاً یکی از موارد اولیۀ نقشه راه است که پیادهسازی خواهد شد. مراحل محاسبات غیرمتمرکز مورد نیاز برای راهاندازی آن در حال انجام است و چندین کلاینت نمونههای اولیه را برای مدیریت دادههای تودهای پیادهسازی کردهاند. اجرای کامل Danksharding احتمالاً چندین سال دیگر زمان نیاز داشته باشد، چراکه مستلزم اجرای موارد دیگری از نقشه راه است. غیرمتمرکزسازی زیرساخت رولآپ احتمالاً یک فرآیند تدریجی است - رولآپهای متفاوت زیادی وجود دارند که در حال ساختن سیستمهایی با تفاوت جزئی هستند و به طور کامل با نرخهای متفاوت غیرمتمرکز میشوند.
+پروتو-دنکشاردینگ اولین مورد از این موارد نقشه راه است که به عنوان بخشی از ارتقاء شبکه Cancun-Deneb ("Dencun") در مارس 2024 اجرا میشود. **دنکشاردینگ کامل احتمالاً چندین سال دیگر رخ میدهد**، زیرا متکی بر چندین مورد دیگر نقشه راه است که ابتدا باید تکمیل شوند. غیرمتمرکزسازی زیرساخت رولآپ احتمالاً یک فرآیند تدریجی است - رولآپهای متفاوت زیادی وجود دارند که در حال ساختن سیستمهایی با تفاوت جزئی هستند و به طور کامل با نرخهای متفاوت غیرمتمرکز میشوند.
+
+[اطلاعات بیشتر درباره ارتقا Dencun](/roadmap/dencun/)
diff --git a/public/content/translations/fa/roadmap/secret-leader-election/index.md b/public/content/translations/fa/roadmap/secret-leader-election/index.md
index bd25b288345..c9467f5a2bd 100644
--- a/public/content/translations/fa/roadmap/secret-leader-election/index.md
+++ b/public/content/translations/fa/roadmap/secret-leader-election/index.md
@@ -16,7 +16,7 @@ summaryPoints:
چندین راه حل برای رفع این مسئله وجود دارد. یکی از آنها [فناوری اعتبارسنجی توزیعشده](https://github.com/ethereum/distributed-validator-specs) است که هدفش توزیع وظایف مختلف مربوط به اجرای یک اعتبارسنجی در چندین ماشین، با تزائد است، به طوری که جلوگیری از پیشنهاد یک بلوک در یک اسلات خاص برای یک مهاجم بسیار دشوارتر شود. با این حال، موثرترین راه حل **انتخاب رهبر مخفی منفرد (SSLE)** است.
-## انتخاب رهبر مخفی منفرد {#secret-leader-election}
+## انتخابات تکرهبر پنهان {#secret-leader-election}
در SSLE، از رمزنگاری هوشمندانهای استفاده میشود تا اطمینان حاصل شود که فقط اعتبارسنج انتخابشده از انتخاب شدنش اطلاع داشته باشد. این کار به این صورت انجام میشود که هر اعتبارسنج تعهدی را به عبارت محرمانهای که همگی به طور مشترک دارند، ارائه کند. تعهدات به شکل تصادفی تغییر میکنند و مجدداً پیکربندی میشوند تا هیچکس نتواند تعهدات را به اعتبارسنجیها مرتبط کند، اما هریک از اعتبارسنجها میدانند که کدام تعهد متعلق به آنهاست. پس از آن، یک تعهد به شکل تصادفی انتخاب میشود. اگر اعتبارسنج تشخیص دهد که تعهد او انتخاب شده است، متوجه میشود که نوبت اوست که یک بلوک را پیشنهاد کند.
diff --git a/public/content/translations/fa/roadmap/security/index.md b/public/content/translations/fa/roadmap/security/index.md
index cb64e04113b..d1c808caedf 100644
--- a/public/content/translations/fa/roadmap/security/index.md
+++ b/public/content/translations/fa/roadmap/security/index.md
@@ -7,27 +7,27 @@ alt: "نقشه راه اتریوم"
template: roadmap
---
-در حال حاضر اتریوم یک پلتفورم قرارداد هوشمند بسیار ایمن و غیرمتمرکز است. با این حال، همچنان میتوان آن را بهبود بخشید تا اتریوم بتواند در آینده در مقابل همه انواع حملات مقاوم باشد. این بهبودها شامل تغییرات ظریف در نحوه تعامل کلاینتهای اتریوم با بلوکهای رقیب و افزایش سرعت در [قطعی شدن](/developers/docs/consensus-mechanisms/pos/#finality) بلوکها توسط شبکه است. (به این معنی که آنها را نمیتوان بدون ضرر اقتصادی شدید برای مهاجم تغییر داد).
+**اتریوم در حال حاضر یک پلت فرم بسیار امن** و غیرمتمرکز [قرارداد هوشمند](/glossary/#smart-contract) است. با این حال، همچنان میتوان آن را بهبود بخشید تا اتریوم بتواند در آینده در مقابل همه انواع حملات مقاوم باشد. اینها شامل تغییرات ظریف در نحوه برخورد [کاربرهای اتریوم](/glossary/#consensus-client) با [بلوکهای رقیب](/glossary/#block) و همچنین افزایش سرعتی است که شبکه بلوکها را ["نهایی"](/developers/docs/consensus-mechanisms/pos/#finality) میداند. (به این معنی که آنها را نمی توان بدون خسارات اقتصادی شدید به یک مهاجم تغییر داد).
-علاوه بر این بهبودهایی وجود دارد که سانسور کردن تراکنشها را با نابینا کردن ارائهدهندگان بلوک نسبت به محتوای واقعی بلوکهایشان و راههای جدید شناسایی در مواقعی که یک کلاینت سانسور اعمال میکند، سخت میکند. این بهبودها در کنار هم پروتکل اثبات سهام را ارتقا میدهند تا کاربران - از افراد عادی گرفته تا شرکتها - به اپلیکیشنها، دادهها و داراییهای روی شبکه اتریوم اعتماد فوری داشته باشند.
+علاوه بر این بهبودهایی وجود دارد که سانسور کردن تراکنشها را با نابینا کردن ارائهدهندگان بلوک نسبت به محتوای واقعی بلوکهایشان و راههای جدید شناسایی در مواقعی که یک کلاینت سانسور اعمال میکند، سخت میکند. این پیشرفتها باهم، پروتکل [اثبات سهام](/glossary/#pos) را ارتقا میدهند تا کاربران - از افراد گرفته تا شرکتها - به برنامهها، دادهها و داراییهای خود در اتریوم اعتماد فوری داشته باشند.
## برداشتها از سهامگذاری {#staking-withdrawals}
-ارتقای شبکه از اثبات کار به اثبات سهام با سهامگذاری ETH در یک قرارداد سپرده توسط پیشتازان شبکه اتریوم شروع شد. آن ETH برای محافظت از شبکه استفاده میشود. با این حال، هنوز آن ETHهای سهامگذاری شده قابل آزادسازی و برگشت به کاربران نیستند. مجوز برداشت ETH یک بخش مهم در ارتقای اثبات سهام است. علاوه بر اینکه برداشتها یک مولفه مهم در پروتکل کاملاً کاربردی اثبات سهام است، مجوز برداشتها نیز برای امنیت اتریوم مفید است، زیرا به سهامگذاران اجازه استفاده از پاداشهای ETH برای اهداف خارج از سهامگذاری را فراهم میکند. این بدان معناست که کاربرانی که خواهان نقدینگی هستند، مجبور نیستند به مشتقات سهامگذاری نقدی (LSD) که میتواند یک نیروی متمرکزکننده اتریوم باشند، تکیه کنند. این ارتقا قرار است در تاریخ 12 آوریل 2023 تکمیل شود.
+ارتقاء از الگوریتم [اثبات کار](/glossary/#pow) به اثبات سهام با پیشگامان اتریوم شروع شد که اتر خود را در یک قرارداد سهام گذاری کردند. آن ETH برای محافظت از شبکه استفاده میشود. دومین بهروز رسانی در 12 آوریل 2023 انجام شده تا امکان برداشت اتر سهامگذاری شده را فراهم کند. از آن زمان اعتبارسنجها میتوانند آزادانه اتر را سهامگذاری یا برداشت کنند.
خواندن در مورد برداشتها
## دفاع در برابر حملات {#defending-against-attacks}
-حتی پس از برداشتها هم، میتوان پروتکل [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) اتریوم را بهبود بخشید. یکی از این بهبودها با عنوان [«view-merge»](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) شناخته میشود - یک الگوریتم انتخاب فورک ایمنتر است که انواع معینی از حملات پیچیده را دشوارتر میکند.
+پیشرفتهایی وجود دارد که میتوان در پروتکل اثبات سهام اتریوم ایجاد کرد. یکی به عنوان [مشاهده-ادغام](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) شناخته می شود که یک الگوریتم انتخاب [فورک](/glossary/#fork) ایمن تر است که انواع خاصی از حملات پیچیده را دشوارتر می کند.
-کاهش مدت زمانی که اتریوم برای قطعی کردن بلوکها صرف میکند، تجربه کاربری بهتری را فراهم میکند و در جاهایی که مهاجمان سعی دارند بلوکهای اخیر را تغییر دهند تا سود استخراج کنند یا برخی تراکنشها را سانسور کنند از حملات پیچیده «reorg» جلوگیری میکند. [**قطعیت اسلات منفرد (SSF)**](/roadmap/single-slot-finality/) راهی برای کاهش تأخیر در قطعی کردن تراکنشها است. در حال حاضر بلوکهای 15 دقیقهای وجود دارد که مهاجم میتواند از نظر تئوری، اعتبارسنجهای دیگر را متقاعد کند که دوباره پیکربندی کنند. با SSF احتمال این کار به صفر میرسد. کاربران، از افراد عادی گرفته تا برنامهها و صرافیها، از تضمین سریع و عدم بازگشت تراکنشهایشان منتفع میشوند و از طرف دیگر شبکه با از بین بردن یک دسته کامل از حملات سود میبرد.
+کاهش مدت زمانی که اتریوم برای [نهایی کردن](/glossary/#finality) بلوکها صرف میکند، تجربه کاربری بهتری را فراهم میکند و از حملات پیچیده "reorg" جلوگیری می کند، که در آن مهاجمان سعی می کنند بلوکهای اخیر را تغییر دهند تا سود استخراج کنند یا تراکنش های خاص را سانسور کنند. [**قطعیت شکاف منفرد (SSF)**](/roadmap/single-slot-finality/) **روشی برای به حداقل رساندن تاخیر در نهایی سازی** است. در حال حاضر بلوکهای 15 دقیقهای وجود دارد که مهاجم میتواند از نظر تئوری، اعتبارسنجهای دیگر را متقاعد کند که دوباره پیکربندی کنند. با SSF احتمال این کار به صفر میرسد. کاربران، از افراد عادی گرفته تا برنامهها و صرافیها، از تضمین سریع و عدم بازگشت تراکنشهایشان منتفع میشوند و از طرف دیگر شبکه با از بین بردن یک دسته کامل از حملات سود میبرد.
خواندن در مورد قطعیت اسلات منفرد
## دفاع در برابر سانسور {#defending-against-censorship}
-غیرمتمرکزسازی از تأثیرگذاری بیش از حد افراد عادی یا گروههای کوچک اعتبارسنجها جلوگیری میکند. فناوریهای جدید سهامگذاری میتوانند به تضمین اعتبارسنجهای اتریوم کمک کنند که تا حد امکان غیرمتمرکز بماند و در عین حال از آنها در برابر اختلالات سختافزار، نرمافزار و شبکه دفاع کنند. این شامل نرمافزاری است که مسئولیتهای اعتبارسنجی را در چندین گره به اشتراک میگذارد. این مفهوم با عنوان **تکنولوژی اعتبارسنجی توزیعشده (DVT)** شناخته میشود. استخرهای سهامگذاری تشویق میشوند تا از DVT استفاده کنند، چراکه این مفهوم به چندین کامپیوتر اجازه میدهد به شکل جمعی در اعتبارسنجی شرکت کنند و تزائد و تحمل خطا را به سیستم اضافه کنند. همچنین به جای اینکه اپراتورهای منفرد چند اعتبارسنج را اجرا کنند، کلیدهای اعتبارسنجی را در چندین سیستم تقسیم میکند. این امر هماهنگی حملات به اتریوم را برای اپراتورهای متقلب دشوارتر میکند. به طور کلی، ایده این است که با اجرای اعتبارسنجی به صورت _جمعی_ به جای فردی، از مزایای امنیتی بهرهمند شویم.
+تمرکززدایی، از مافیابازی افراد یا گروههای کوچک [اعتبارسنج](/glossary/#validator) جلوگیری میکند. فناوریهای جدید سهامگذاری میتوانند به تضمین اعتبارسنجهای اتریوم کمک کنند که تا حد امکان غیرمتمرکز بماند و در عین حال از آنها در برابر اختلالات سختافزار، نرمافزار و شبکه دفاع کنند. این شامل نرمافزاری میشود که مسئولیتهای اعتبارسنج را در چندین [گره](/glossary/#node) به اشتراک میگذارد. این مفهوم با عنوان **تکنولوژی اعتبارسنجی توزیعشده (DVT)** شناخته میشود. [استخرهای سهامگذاری](/glossary/#staking-pool) برای استفاده از DVT تشویق میشوند زیرا به چندین رایانه اجازه میدهند به طور جمعی در اعتبارسنجی شرکت کنند که تزائد و تحمل خطا را اضافه میکند. همچنین به جای اینکه اپراتورهای منفرد چند اعتبارسنج را اجرا کنند، کلیدهای اعتبارسنجی را در چندین سیستم تقسیم میکند. این امر هماهنگی حملات به اتریوم را برای اپراتورهای متقلب دشوارتر میکند. به طور کلی، ایده این است که با اجرای اعتبارسنجی به صورت _جمعی_ به جای فردی، از مزایای امنیتی بهرهمند شویم.
خواندن در مورد تکنولوژی اعتبارسنجی توزیعشده
@@ -45,4 +45,4 @@ template: roadmap
## پیشرفت فعلی {#current-progress}
-ارتقاهایی امنیت در نقشه راه در مراحل تکمیلی تحقیقات است، اما انتظار نمیرود فعلاً پیادهسازی شود. مراحل بعدی برای view-merge، PBS، SSF و SLE نهایی کردن ویژگیها و شروع ساخت نمونههای اولیه آنها است.
+**ارتقاهای امنیتی در نقشه راه در مراحل پیشرفتهای از تحقیقات است**، اما تا مدتی انتظار نمی رود اجرا شوند. مراحل بعدی برای view-merge، PBS، SSF و SLE نهایی کردن ویژگیها و شروع ساخت نمونههای اولیه آنها است.
diff --git a/public/content/translations/fa/roadmap/statelessness/index.md b/public/content/translations/fa/roadmap/statelessness/index.md
index c7063fb5d1c..022bacdf28c 100644
--- a/public/content/translations/fa/roadmap/statelessness/index.md
+++ b/public/content/translations/fa/roadmap/statelessness/index.md
@@ -14,7 +14,7 @@ lang: fa
## کاهش حافظه مورد نیاز گرهها {#reducing-storage-for-nodes}
-راههای مختلفی برای کاهش مقدار داده ذخیرهسازی مورد نیاز هر گره وجود دارد که هرکدام نیازمند بروزرسانیها با اندازه مختلف در پروتکل اصلی اتریوم میباشند:
+راههای مختلفی برای کاهش حجم دادهای که هر گره باید ذخیره کند وجود دارد، که هر کدام نیازمند بهروزرسانی پروتکل اصلی اتریوم به میزان متفاوت هستند:
- **انقضای تاریخچه**: به گرهها امکان میدهد تا دادههای حالت قدیمیتر از حالت بلوکهای X را حذف کنند، اما چگونگی نحوه مدیریت دادههای حالت توسط کلاینتها اتریوم را تغییر نمیدهد
- **انقضای حالت**: اجازه میدهد دادههای حالتی که بهطور متداول استفاده نمیشوند غیرفعال شوند. کلاینتها میتوانند تا زمان فراخوانی مجدد، دادههای غیرفعال را نادیده بگیرند.
@@ -81,7 +81,7 @@ EIP-4444 درحال حاضر آماده عرضه نیست، اما تحت بحث
### بیحالتی قوی {#strong-statelessness}
-بیحالتی قوی نیاز به ذخیرهسازی دادههای حالت را رفع میکند. درعوض، تراکنشها با شاهدهایی ارسال میشوند که میتوان آنها را با ایجادکنندههای بلوک گردآوری کرد. از این رو، ایجادکنندههای بلوک درقبال ذخیرهسازی آن حالتی که برای ایجاد شاهدهای حسابهای مربوطه مورد نیاز است مسئول هستند. مسئولیت حالت تقربیاً بهطور کل به کاربران انتقال داده شده است، زیرا آنها شاهدها و «لیستهای دسترسی» را برای اعلام حسابها و کلیدهای ذخیرهسازی ارسال میکنند که با آنها تعامل دارند. این کار گرههای بسیار سبک را ممکن خواهد کرد، اما ریسکهایی وجود دارد، از جمله اینکه تعامل با قراردادهای هوشمند را مشکلتر میسازد.
+بیحالتی قوی، نیاز به هرگونه گره برای ذخیره داده های حالت را از بین می برد. درعوض، تراکنشها با شاهدهایی ارسال میشوند که میتوان آنها را با ایجادکنندههای بلوک گردآوری کرد. از این رو، ایجادکنندههای بلوک درقبال ذخیرهسازی آن حالتی که برای ایجاد شاهدهای حسابهای مربوطه مورد نیاز است مسئول هستند. مسئولیت حالت تقربیاً بهطور کل به کاربران انتقال داده شده است، زیرا آنها شاهدها و «لیستهای دسترسی» را برای اعلام حسابها و کلیدهای ذخیرهسازی ارسال میکنند که با آنها تعامل دارند. این کار گرههای بسیار سبک را ممکن خواهد کرد، اما ریسکهایی وجود دارد، از جمله اینکه تعامل با قراردادهای هوشمند را مشکلتر میسازد.
محققین بیحالتی قوی را مورد تحقیق قرار دادهاند، اما انتظار نمیرود اکنون بخشی از نقشهٔ راه اتریوم باشد - به احتمال بیشتر بیحالتی ضعیف برای نیازهای مقیاسپذیری اتریوم کافی است.
diff --git a/public/content/translations/fa/roadmap/user-experience/index.md b/public/content/translations/fa/roadmap/user-experience/index.md
index e9d6342d6d1..24880bdf3cc 100644
--- a/public/content/translations/fa/roadmap/user-experience/index.md
+++ b/public/content/translations/fa/roadmap/user-experience/index.md
@@ -7,19 +7,19 @@ alt: "نقشه راه اتریوم"
template: roadmap
---
-استفاده از اتریوم نیازمند سادهسازی است؛ از مدیریت کلیدها و کیف پولها گرفته تا ایجاد تراکنشها. برای فراهم شدن بستر پذیرش انبوه، اتریوم باید به شدت سهولت استفاده را افزایش دهد که به کاربران اجازه دهد با تجربه بدون اصطکاک استفاده از برنامههای Web2، دسترسی غیرمتمرکز، بدون نیاز به مجوز و مقاوم در برابر سانسور به اتریوم را تجربه کنند.
+**استفاده از اتریوم باید ساده شود**؛ از مدیریت [کلیدها](/glossary/#key) و [کیف پول](/glossary/#wallet) تا شروع تراکنش ها. برای تسهیل پذیرش عمومی، اتریوم باید سهولت استفاده را به شدت افزایش دهد و به کاربران اجازه دهد با استفاده از برنامههای [Web2](/glossary/#web2) دسترسی بینیاز به مجوز طرف ثالث و مقاوم در برابر سانسور به اتریوم را تجربه کنند.
## فراتر از کلمات بازیابی {#no-more-seed-phrases}
حسابهای اتریوم توسط یک جفت کلید برای تایید اصالت حسابها (کلید عمومی) و امضا زدن روی پیامها (کلید خصوصی)، محافظت میشوند. کلید خصوصی مثل شاهکلید است. این کلید به شما اجازه میدهد به یک حساب اتریوم دسترسی کامل داشته باشید. این یک روش مجزا است برای کسانی که بیشتر با بانکها و برنامههای Web2 که حسابها را از طرف یک کاربر مدیریت میکنند آشنا هستند. برای اینکه اتریوم بدون نیاز به اشخاص ثالث متمرکز به پذیرش انبوه برسد، باید راهی ساده و بدون اصطکاک برای کاربر وجود داشته باشد تا بتواند از داراییهای خود نگهداری کند و کنترل دادههایشان را بدون نیاز به آشنایی با رمزنگاری کلید خصوصی-عمومی و مکانیزم مدیریت کلید، در دست داشته باشد.
-راه حل این مشکل، استفاده از کیف پولهای قرارداد هوشمند برای تعامل با اتریوم است. کیف پولهای قرارداد هوشمند راههایی برای محافظت از حسابها در صورت گم یا دزدیده شدن ایجاد میکند، بستر مناسب را برای تشخیص و دفاع بهتر در مقابل کلاهبرداری فراهم میکند و به کیف پولها این امکان را میدهد تا عملکرد جدیدی داشته باشند. اگرچه در حال حاضر کیف پولهای قرارداد هوشمند وجود دارند، اما ساخت آنها دشوار است. چراکه پروتکل اتریوم باید پشتیانی بهتری برای آن فراهم کند. این پشتیبانی تکمیلی تحت عنوان انتزاع حساب شناخته میشود.
+راهکار این امر، استفاده از کیف پول های [قرارداد هوشمند](/glossary/#smart-contract) برای تعامل با اتریوم است. کیف پولهای قرارداد هوشمند راههایی برای محافظت از حسابها در صورت گم یا دزدیده شدن ایجاد میکند، بستر مناسب را برای تشخیص و دفاع بهتر در مقابل کلاهبرداری فراهم میکند و به کیف پولها این امکان را میدهد تا عملکرد جدیدی داشته باشند. اگرچه در حال حاضر کیف پولهای قرارداد هوشمند وجود دارند، اما ساخت آنها دشوار است. چراکه پروتکل اتریوم باید پشتیانی بهتری برای آن فراهم کند. این پشتیبانی تکمیلی تحت عنوان انتزاع حساب شناخته میشود.
اطلاعات بیشتر در مورد انتزاع حساب
## گرهها برای همه
-کاربران اجراکننده گرهها نباید برای ارائه دادهها به اشخاص ثالث اعتماد کنند و میتوانند به سرعت،به طور ایمن و بدون دریافت مجوز با زنجیره بلوکی اتریوم تعامل داشته باشند. با این وجود، در حال حاضر اجرای یک گره به دانش فنی و فضای دیسک چشمگیر نیاز دارد، به عبارتی بسیاری از افراد مجبورند در عوض به واسطهها اعتماد کنند.
+کاربرانی که [گرهها](/glossary/#node) را اجرا میکنند لازم نیست به طرفهای ثالث برای ارائه دادهها به آنها اعتماد کنند و میتوانند سریع، خصوصی و بدون مجوز با [بلاکچین](/glossary/#blockchain) اتریوم تعامل داشته باشند. با این وجود، در حال حاضر اجرای یک گره به دانش فنی و فضای دیسک چشمگیر نیاز دارد، به عبارتی بسیاری از افراد مجبورند در عوض به واسطهها اعتماد کنند.
ارتقاهایی وجود دارد که اجرای گرهها را بسیار سادهتر و میزان منابع لازم را به شدت کمتر خواهد کرد. شیوه ذخیرهسازی دادهها در جهت استفاده یک ساختار بهینهتر از فضا تغییر میکند که به عنوان **درخت ورکل** شناخته میشود. علاوه بر این، با [بیحالتی](/roadmap/statelessness) یا [انقضای دادهها](/roadmap/statelessness/#data-expiry)، گرههای اتریوم دیگر نیازی به ذخیرهسازی یک کپی از کل دادههای حالت اتریوم نخواهند داشت که نیاز به فضای هارد دیسک را به شدت کاهش میدهد. [گرههای سبک](/developers/docs/nodes-and-clients/light-clients/) مزایای زیادی از اجرای یک گره کامل ارائه میدهند اما میتوانند به آسانی روی موبایلها یا داخل برنامههای مرورگر ساده اجرا شوند.
@@ -29,8 +29,8 @@ template: roadmap
## پیشرفت فعلی {#current-progress}
-کیف پولهای قرارداد هوشمند درحال حاضر در دسترس هستند، ولی ارتقا و بهروزرسانیهای بیشتری لازم است تا آنها را تا حد ممکن غیرمتمرکز و بینیاز به مجوز کند. EIP-4337 یک پیشنهاد کامل است که نیاز به هیچ تغییری در پروتکل اتریوم ندارد. قرارداد هوشمند اساسی مورد نیاز برای EIP-4337 در ماه مارس 2023 پیادهسازی شد.
+کیف پولهای قرارداد هوشمند درحال حاضر در دسترس هستند، ولی ارتقا و بهروزرسانیهای بیشتری لازم است تا آنها را تا حد ممکن غیرمتمرکز و بینیاز به مجوز کند. EIP-4337 یک پیشنهاد کامل است که نیاز به هیچ تغییری در پروتکل اتریوم ندارد. قرارداد هوشمند اصلی مورد نیاز برای پیشنهاد EIP-4337 **در مارس 2023 پیادهسازی شد**.
-بیحالتی کامل هنوز در مرحله تحقیق است و احتمالاً چندین سال از پیادهسازی فاصله دارد. چندین نقطهعطف از جمله انقضای دادهها، در مسیر تحقق بیحالتی کامل وجود دارد که ممکن است زودتر پیادهسازی شود. بخشهای دیگر نقشه راه مثل [درختان ورکل](/roadmap/verkle-trees/) و [جداسازی پیشنهاددهندگان-ایجادکنندگان](/roadmap/pbs/) باید ابتدا تکمیل شوند.
+**بی حالتی کامل هنوز در مرحله تحقیق است** و احتمالا چندین سال تا اجرای آن فاصله دارد. چندین نقطهعطف از جمله انقضای دادهها، در مسیر تحقق بیحالتی کامل وجود دارد که ممکن است زودتر پیادهسازی شود. بخشهای دیگر نقشه راه مثل [درختان ورکل](/roadmap/verkle-trees/) و [جداسازی پیشنهاددهندگان-ایجادکنندگان](/roadmap/pbs/) باید ابتدا تکمیل شوند.
در حال حاضر شبکههای تست درخت ورکل راجرا شدهاند و مرحله بعدی اجرای کلاینتهای مبتنی بر درخت ورکل در شبکههای آزمایشی خصوصی و پس از آن در شبکههای تست عمومی است. میتوانید با بهکارگیری قراردادها در شبکههای تست یا اجرای کلاینتهای شبکه تست، پیشرفت آن را سرعت دهید.
diff --git a/public/content/translations/fa/roadmap/verkle-trees/index.md b/public/content/translations/fa/roadmap/verkle-trees/index.md
index e28c63b58e0..aeadcd6c7ef 100644
--- a/public/content/translations/fa/roadmap/verkle-trees/index.md
+++ b/public/content/translations/fa/roadmap/verkle-trees/index.md
@@ -33,7 +33,7 @@ summaryPoints:
-حجم هر شاهد به تعداد برگهایی که دربر دارد وابسته است. تصور کنید یک شاهد 1000 برگ را پوشش دهد. حجم یک شاهد برای یک ترای مرکل در حدود 3.5 مگابایت میشود (با فرض وجود 7 سطح تا رسیدن به ترای). حجم یک شاهد برای همان دادهها در درختان ورکل (با فرض وجود 4 سطح تا رسیدن به درخت)، در حدود 150 کیلوبایت خواهد بود، یعنی تقریباً **23 برابر کوچکتر**. این کاهش حجم در شاهدها به شاهدهای کلاینتهای بیحالت این امکان را میدهد که در حد قابل قبولی کوچک شوند. شاهدهای چندجملهای با توجه به نوع تعهد چندجملهای مورد استفادهشان بین 0/128 تا 1 کیلوبایت حجم دارند.
+حجم هر شاهد به تعداد برگهایی که دربر دارد وابسته است. تصور کنید یک شاهد 1000 برگ را پوشش دهد. حجم یک شاهد برای یک ترای مرکل در حدود 3.5 مگابایت میشود (با فرض وجود 7 سطح تا رسیدن به ترای). حجم یک شاهد برای همان دادهها در درختان ورکل (با فرض وجود 4 سطح تا رسیدن به درخت)، در حدود 150 کیلوبایت خواهد بود، یعنی تقریباً **23 برابر کوچکتر**. این کاهش حجم در شاهدها به شاهدهای کلاینتهای بیحالت این امکان را میدهد که در حد قابل قبولی کوچک شوند. شاهدهای چند جمله ای بسته به اینکه کدام تعهد چند جمله ای خاص استفاده می شود بین 0.128 تا 1 کیلوبایت هستند.
@@ -60,7 +60,7 @@ summaryPoints:
- [Guillaume Ballet درباره درختان ورکل در ETHGlobal توضیح میدهد](https://www.youtube.com/watch?v=f7bEtX3Z57o)
- [«چگونه درختان ورکل اتریوم را مختصر و مفید میکنند» از Guillaume Ballet در دِوکان 6](https://www.youtube.com/watch?v=Q7rStTKwuYs)
- [Piper Merriam از ETHDenver 2020 درباره کلاینتهای بیحالت میگوید](https://www.youtube.com/watch?v=0yiZJNciIJ4)
-- [Dankrad Fiest در پادکست Zero Knowledge، درباره درختان ورکل و بیحالتی توضیح میدهد](https://zeroknowledge.fm/episode-202-stateless-ethereum-verkle-tries-with-dankrad-feist/)
+- [دانکارد فیست در پادکست Zero Knowledge درختان ورکل و بیحالتی را توضیح میدهد](https://zeroknowledge.fm/episode-202-stateless-ethereum-verkle-tries-with-dankrad-feist/)
- [Vitalik Buterin درباره درختان ورکل میگوید](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
- [Dankrad Feist درباره درختان ورکل میگوید](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)
- [مستندات مربوط به EIP درختان ورکل](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration)
diff --git a/public/content/translations/fa/security/index.md b/public/content/translations/fa/security/index.md
index 3c461049e4c..88cf61e40e5 100644
--- a/public/content/translations/fa/security/index.md
+++ b/public/content/translations/fa/security/index.md
@@ -6,105 +6,15 @@ lang: fa
# امنیت اتریوم و جلوگیری از کلاهبرداری {#introduction}
-با رشد علاقه به ارزهای رمزنگاریشده، یادگیری بهترین روشهای استفاده از آنها ضروری است. استفاده از ارزهای رمزنگاریشده میتواند هیجانانگیز و جذاب باشد، ولی در عین حال ریسکهای خاص خود را دارد. اگر این چند نکتهی کوچک را در نظر داشته باشید، میتوانید این ریسکها را کاهش دهید.
+افزایش علاقه به رمزارز ریسک فزایندهای را از سوی کلاهبرداران و هکرها به همراه دارد. این مقاله برخی از بهترین شیوهها برای کاهش این خطرات را ارائه میدهد.
-## مبانی امنیت شبکه {#web-security}
-
-### از گذرواژههای قوی استفاده کنید {#use-strong-passwords}
-
-[بیش از 80% هک شدن حسابهای کاربری ناشی از گذرواژههای ضعیف یا بهسرقترفته است](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). یک ترکیب طولانی از حروف، اعداد و نمادها میتواند حسابهای شما را ایمن نگه دارد.
-
-یک اشتباه متداول این است که افراد ترکیبی از دو یا سه کلمهی متداول و مرتبط را از لغتنامه انتخاب میکنند. چنین گذرواژههایی ناامن هستند ،چرا که در مقابل یک تکنیک سادهی هک به نام [حملهی لغتنامهای](https://wikipedia.org/wiki/Dictionary_attack) آسیبپذیر هستند.
-
-```md
-نمونهی یک گذرواژهی ضعیف: CuteFluffyKittens!
-
-نمونهی یک گذرواژهی قوی: ymv\*azu.EAC8eyp8umf
-```
-
-یک اشتباه متداول دیگر، استفاده از رمزی است که میتوان آن را حدس زد یا با [مهندسی اجتماعی]() پیدا کرد. استفاده از نام خانوادگی مادرتان پیش از ازدواج، نام فرزندان یا حیوانات خانگیتان و یا تاریخ تولد در گذرواژهْ ایمن نیست و ریسک هک شدن حساب شما را افزایش میدهد.
-
-#### ویژگیهای گذرواژهی خوب: {#good-password-practices}
-
-- تا جایی که برنامهی گذرواژهساز شما یا فرمی که مشغول پُر کردن آن هستید اجازه میدهد، گذرواژهتان را طولانی بنویسید
-- از ترکیب حروف بزرگ، کوچک، اعداد و نمادها استفاده کنید
-- از اطلاعات شخصی، مانند نام خانوادگی، در گذرواژهی خود استفاده نکنید
-- از کلمات متداول لغتنامه استفاده نکنید
-
-[اطلاعات بیشتر دربارهی ساخت گذرواژهی قدرتمند](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/)
-
-### از گذرواژههای منحصربهفرد برای همهچیز استفاده کنید {#use-unique-passwords}
-
-اگر گذرواژهای در یک نشت اطلاعاتی افشا شده باشد، حتی اگر قوی هم باشد چندان نمیتواند امنیت را برایتان فراهم آورد. با وبسایت [Have I Been Pwned](https://haveibeenpwned.com) میتوانید بررسی کنید که آيا حسابهای شما در فهرست حسابهای لو رفته در نشتهای اطلاعاتی بودهاند یا خیر. اگر چنین باشد، **باید فوراً رمز خود را عوض کنید**. استفاده از گذرواژههای منحصربهفرد برای همهی حسابهایتان میتواند ریسک دسترسی هکرها به همهی حسابهایتان در صورت افشای یکی از گذرواژهها را کاهش دهد.
-
-### از یک برنامهی مدیریت گذرواژه استفاده کنید {#use-password-manager}
-
-
-
- استفاده از برنامههای مدیریت گذرواژه میتواند خیال شما را از حیث ساخت گذرواژههای قوی و منحصربهفرد و بهخاطرسپاری آنها راحت کند! ما قویاً توصیه میکنیم که از یک برنامهی مدیریت گذرواژه استفاده کنید. بیشتر این برنامهها رایگان هستند!
-
-
-
-بهخاطرسپاری گذرواژههای قوی و منحصربهفرد برای هر حساب راهکار ایدهآلی نیست. یک برنامهی مدیریت گذرواژه، محلی امن و رمزنگاریشده برای تمام گذرواژهها در اختیارتان قرار میدهد که میتوانید از طریق یک گذرواژهی مادر به آن دسترسی داشته باشید. بهعلاوه، این برنامهها هنگام ثبتنام در یک سرویس جدید به شما گذرواژههای قوی پیشنهاد میدهند تا لازم نباشد خودتان گذرواژه بسازید. بسیاری از برنامههای مدیریت گذرواژه همچنین به شما خواهند گفت که اطلاعاتتان در نشت اطلاعاتی درز کردهاست یا خیر. در این صورت میتوانید پیش از هرگونه حملهی خرابکارانه گذرواژههایتان را عوض کنید.
-
-![مثالی برای استفاده از برنامهی مدیریت گذرواژه](./passwordManager.png)
-
-#### یک برنامهی مدیریت گذرواژه را امتحان کنید: {#try-password-manager}
-
-- [Bitwarden](https://bitwarden.com/)
-- [KeePass](https://keepass.info/)
-- [1Password](https://1password.com/)
-- و یا دیگر [نرم افزارهای مدیریت پسورد توصیه شده](https://www.privacytools.io/secure-password-manager) را بررسی کنید
-
-### از احراز هویت دو عاملی استفاده کنید {#two-factor-authentication}
-
-برای اثبات این که شما واقعاً خودتان هستید، آزمونهای منحصربهفرد مختلفی برای احراز هویت وجود دارد. به اینها **عامل** میگویند و سه عامل اصلی عبارتند از:
-
-- چیزی که میدانید (مانند یک گذرواژه یا سؤال امنیتی)
-- چیزی که هستید (مانند اثر انگشت یا اسکنر قرنیه/صورت)
-- چیزی که دارید (مانند یک کلید امنیتی یا برنامههای احراز هویت روی تلفن همراه)
-
-استفاده از **احراز هویت دو عاملی (2FA)** یک _عامل امنیتی_ اضافه برای حسابهای آنلاین شما فراهم میآورد تا دانستن گذرواژهی شما به تنهایی (چیزی که میدانید) برای دسترسی به حساب کافی نباشد. عامل دوم معمولاً یک کد 6 رقمی تصادفی است که به آن **گذرواژهی یکبارمصرف زماندار (TOTP)** میگویند و با یک برنامهی احراز هویت مثل Google Authenticator یا Authy میتوانید به آن دسترسی داشته باشید. اینها بهعنوان عامل «چیزی که دارید» عمل میکنند، چون هستهای که کد زماندار را میسازد روی دستگاه شما نگهداری میشود.
-
-
-
- توجه: استفاده از 2FA مبتنی بر پیامک خطر سرقت شمارهی تلفن همراه دارد و ایمن نیست. برای برخورداری از بیشترین امنیت، از سرویسی مانند{" "}
-
- Google Authenticator
-
- یا Authy استفاده کنید.
-
-
-
-#### کلید امنیتی {#security-keys}
-
-برای کسانی که میخواهند احراز هویت دو عاملی را پیشرفتهتر انجام دهند، استفاده از کلید امنیتی پیشنهاد میشود. کلید امنیتی یک دستگاه احراز هویت سختافزاری است که همانند برنامههای احراز هویت کار میکند. استفاده از کلید امنیتی امنترین روش برای احراز هویت دو عاملی است. بسیاری از این کلیدها از استاندارد عامل دوم جهانی (U2F) FIDO استفاده میکنند. [اطلاعات بیشتر دربارهی FIDO U2F](https://www.yubico.com/authentication-standards/fido-u2f/).
-
-دربارهی 2FA بیشتر تماشا کنید:
-
-
-
-### افزونههای مرورگر را پاک کنید {#uninstall-browser-extensions}
-
-افزونههای مرورگر مثل افزونههای Chrome یا Firefox میتوانند قابلیتهای مفیدی به مرورگر اضافه کنند و تجربهی کاربری را بهبود بخشند، اما ریسکهایی هم دارند. بهطور پیشفرض، اکثر افزونههای مرورگرها برای «خواندن و تغییر دادههای سایت» دسترسی میخواهند که به آنها اجازه میدهد با دادههایتان تقریباً هر کاری بکنند. افزونههای Chrome معمولاً بهطور خودکار بهروزرسانی میشوند. در نتیجه، افزونهای که اکنون امن است، ممکن است پس از بهروزرسانی به یک افزونهی خرابکار تبدیل شود. اکثر افزونههای مرورگر قصد ندارند دادههای شما را بدزدند، اما باید بدانید که میتوانند این کار را بکنند.
-
-#### با این کارها ایمن بمانید: {#browser-extension-safety}
-
-- افزونههای مرورگر را تنها از منابع مطمئن نصب کنید
-- افزونههای مرورگر بیاستفاده را پاک کنید
-- افزونههای Chrome را بهصورت محلی نصب کنید تا از بهروزرسانی خودکار جلوگیری کنید (پیشرفته)
-
-[اطلاعات بیشتر دربارهی ریسکهای افزونههای مرورگر](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/)
-
-
-
-## مبانی امنیت ارزهای رمزنگاریشده {#crypto-security}
+## امنیت رمزارزها 101 {#crypto-security}
### دانش خود را ارتقا دهید {#level-up-your-knowledge}
-یکی از مهمترین دلایلی که مردم در دنیای ارزهای رمزنگاریشده کلاه سرشان میرود، نبود دانش است. برای مثال اگر درک نکنید که شبکهی اتریوم غیرمتمرکز است و مال هیچکس نیست، بهسادگی قربانی کسی میشوید که خود را نمایندهی خدمات مشتریان معرفی میکند و به شما وعده میدهد اتر ازدسترفتهتان در صرافی را در ازای کلید خصوصیتان به شما برمیگرداند. بالا بردن دانش خود در مورد نحوهی کار اتریوم یک سرمایهگذاری ارزشمند است.
+سوءتفاهمها در مورد نحوه عملکرد رمزارز میتواند منجر به اشتباهات پرهزینه شود. به عنوان مثال، اگر شخصی وانمود کند که یک نماینده خدمات مشتری است که میتواند در ازای کلیدهای خصوصی شما اتر از دست رفته را برگرداند، افرادی را که نمیدانند اتریوم یک شبکه غیرمتمرکز و فاقد این نوع عملکرد است، شکار میکند. بالا بردن دانشتان در مورد نحوه کار اتریوم یک سرمایهگذاری ارزشمند است.
اتریوم چیست؟
@@ -121,32 +31,32 @@ lang: fa
**هیچگاه به هیچ دلیلی کلید خصوصیتان را بهاشتراک نگذارید!**
-کلید خصوصی کیف پول شما در مقام گذرواژهی کیف پول اتریوم شما عمل میکند. این تنها چیزی است که نمیگذارد افرادی که آدرس کیف پول شما را میدانند تمام داراییهای حسابتان را خالی کنند!
+کلید خصوصی کیفپول شما، رمزعبور کیفپول اتریوم شما است. این تنها چیزی است که نمیگذارد افرادی که آدرس کیف پول شما را میدانند تمام داراییهای حسابتان را خالی کنند!
کیف پول اتریوم چیست؟
-#### از کلید خصوصی/عبارت seed خود اسکرینشات نگیرید {#screenshot-private-keys}
+#### از کلید خصوصی/عبارت بذر خود اسکرینشات نگیرید {#screenshot-private-keys}
-با اسکرینشات گرفتن از عبارت seed یا کلید خصوصی، ریسک بارگزاری آنها روی فضای ابری و قرار گرفتن آنها در دسترس هکرها را میپذیرید. به دست آوردن کلید خصوصی از فضای ابری یک مسیر حملهی متداول برای هکرها است.
+اسکرینشات گرفتن از عبارات بذر یا کلیدهای خصوصی شما ممکن است آنها را با یک ارائه دهنده خدمات دیتای ابری همگام کند، که ممکن است آنها را در معرض دسترسی هکرها قرار دهد. دستیابی به کلید خصوصی از فضای ابری یک مسیر متداول حمله برای هکرها است.
### از کیف پول سختافزاری استفاده کنید {#use-hardware-wallet}
-کیف پول سختافزاری یک حافظهی آفلاین برای کلید خصوصی است. آنها امن ترین روش برای نگهداری امن کلید خصوصی کیف پول شما به حساب می آیند: کلید خصوصی شما هرگز به اینترنت متصل نمیشود و کاملا بر روی دستگاه محلی شما ذخیره میشود.
+کیف پول سختافزاری یک حافظه آفلاین برای کلید خصوصی است. آنها امن ترین روش برای نگهداری امن کلید خصوصی کیف پول شما به حساب می آیند: کلید خصوصی شما هرگز به اینترنت متصل نمیشود و کاملا در دستگاه محلی شما میماند.
نگهداری کلیدهای خصوصی بهصورت آفلاین به شدت ریسک هک شدن را پایین میآورد، حتی اگر هکر بتواند کنترل کامپیوتر شما را به دست آورد.
#### یک کیف پول سختافزاری را امتحان کنید: {#try-hardware-wallet}
-- [Ledger](https://www.ledger.com/)
+- [دفتر کل](https://www.ledger.com/)
- [Trezor](https://trezor.io/)
### پیش از ارسال تراکنش، صحت آن را دوباره بررسی کنید {#double-check-transactions}
-فرستادن ارز رمزنگاریشده به آدرس کیف پول نادرست، اشتباهی رایج است. **تراکنشی که روی اتریوم فرستاده شود غیرقابل بازگشت است.** هیچ راهی برای بازگرداندن سرمایهتان ندارید، مگر اینکه دارندهی آن آدرس را بشناسید و بتوانید قانعش کنید که سرمایهی شما را بازگرداند.
+فرستادن ارز رمزنگاریشده به آدرس کیف پول نادرست، اشتباهی رایج است. **تراکنش ارسال شده در اتریوم برگشتناپذیر است.** مگر اینکه مالک آدرس را بشناسید و بتوانید او را متقاعد کنید که وجوه شما را پس بدهد، وگرنه نمیتوانید وجوهتان را باز گردانید.
-همیشه مطمئن شوید آدرسی که میخواهید به آن وجه ارسال کنید، با آدرسی که در حال ارسال وجه به آن هستید دقیقاً تطابق داشته باشد. همچنین توصیه میشود هنگام ارتباط با قرارداد هوشمند، پیام تراکنش را پیش از امضا کردن بخوانید.
+همیشه مطمئن شوید آدرسی که میخواهید به آن وجه ارسال کنید، با آدرسی که در حال ارسال وجه به آن هستید دقیقاً تطابق داشته باشد. هنگام تعامل با یک قرارداد هوشمند، خواندن پیام تراکنش قبل از امضا، روش خوبی است.
### برای قرارداد هوشمند محدودیت خرج کردن وضع کنید {#spend-limits}
@@ -160,121 +70,216 @@ lang: fa
## کلاهبرداریهای رایج {#common-scams}
-کلاهبرداران همیشه به دنبال راهی برای دزدیدن پول شما هستند. مقابله کامل با کلاهبرداران غیرممکن است، اما با آگاهی از عمده تکنیکهای مورد استفاده میتوان تلاش آنها را کماثر کرد. روشهای زیادی برای کلاهبرداری وجود دارد، اما آنها بهطور کلی الگوهای سطح بالای مشابهی را دنبال میکنند. در هر صورت، به یاد داشته باشید:
+جلوگیری کامل از کلاهبرداران غیرممکن است، ولی میتوانیم با آگاهی از تکنیکهای مورد استفاده کلاهبرداران، اثربخشی آنها را کاهش دهیم. روشهای زیادی برای کلاهبرداری وجود دارد، اما آنها بهطور کلی الگوهای سطح بالای مشابهی را دنبال میکنند. در هر صورت، به یاد داشته باشید:
- همیشه محتاط باشید
- هیچکس نمیخواهد به شما اتریوم رایگان یا با تخفیف بدهد
- هیچکس به کلید خصوصی و اطلاعات شخصی شما نیاز ندارد
+### توییتر و فیشینگ {#ad-phishing}
+
+![فیشینگ لینک توییتر](./twitterPhishingScam.png)
+
+روشی برای جعل کردن ویژگی پیشنمایش (باز کردن) لینک توییتر (همان X) وجود دارد تا کاربران را به طور بالقوه فریب دهد فکر کنند در حال بازدید از یک وبسایت قانونی هستند. این تکنیک، از مکانیزم توییتر برای ایجاد پیشنمایش آدرسهای اینترنتی به اشتراک گذاشته شده در توییتها سوءاستفاده میکند و برای مثال عبارت _از ethereum.org_ (نشان داده شده در بالا) را نشان میدهد، در حالی که در واقع به یک سایت مخرب هدایت میشوند.
+
+همیشه مطمئن شوید که به یک دامنه درست هدایت شدهاید، به خصوص پس از کلیک کردن روی یک لینک.
+
+[اطلاعات بیشتر در اینجا](https://harrydenley.com/faking-twitter-unfurling).
+
### کلاهبرداری ارسال هدیه {#giveaway}
-یکی از شایعترین انواع کلاهبرداری مربوط به ارزهای رمزنگاریشده، کلاهبرداری ارسال هدیه است. این کلاهبرداری انواع مختلفی دارد، اما وعده کلی به این صورت است که اگر به آدرس کیف پول گفتهشده اتر بفرستید، دو برابر آن به شما برگردانده میشود. *به همین دلیل، به کلاهبرداری 2 به 1 نیز معروف است.*
+یکی از شایعترین انواع کلاهبرداری مربوط به ارزهای رمزنگاریشده، کلاهبرداری ارسال هدیه است. کلاهبرداری با وعده واریز پاداش، میتواند اشکال مختلف داشته باشد، اما ایده کلی این است که اگر اتر را به آدرس کیفپول ارائه شده ارسال کنید، دو برابر اتر ارسالی خود را دریافت خواهید کرد. *به همین دلیل، به کلاهبرداری 2 به 1 نیز معروف است.*
-این کلاهبرداریها معمولاً ایده «مدت زمان محدود برای مطالبه جایزه» را طرح میکنند تا افرادی را که قدرت تصمیمگیری ضعیفی دارند با تلقین حس اضطرار نابهجا تهییج کنند.
+برای ایجاد احساس کاذب فوریت، این کلاهبرداریها معمولاً فرصت محدودی را برای درخواست واریز مبلغ تعیین میکنند.
-#### هک شبکههای اجتماعی {#social-media-hacks}
+### هکهای رسانههای اجتماعی {#social-media-hacks}
-یک مورد معروف این نوع کلاهبرداری در ژوئیه 2020 اتفاق افتاد که حساب توییتر افراد مشهور و سازمانها هک شدند. هکر بهطور همزمان یک هدیه بیتکوینی را در شبکههای هکشده ارسال کرد. علیرغم اقدام سریع و حذف توییتهای فریبنده، هکرها توانستند 11 بیت کوین (معادل 500،000 دلار در سپتامبر 2021) را به جیب بزنند.
+یک مورد معروف این نوع کلاهبرداری در ژوئیه 2020 اتفاق افتاد که حساب توییتر افراد مشهور و سازمانها هک شدند. هکر بهطور همزمان یک هدیه بیتکوینی را در شبکههای هکشده ارسال کرد. علیرغم کشف سریع و حذف توییتهای فریبنده، هکرها توانستند 11 بیت کوین (معادل 500،000 دلار در سپتامبر 2021) را به جیب بزنند.
![یک کلاهبرداری در توییتر](./appleTwitterScam.png)
-#### کلاهبرداری در قالب هدیهی افراد مشهور {#celebrity-giveaway}
+### هدیه افراد مشهور {#celebrity-giveaway}
-کلاهبرداری در قالب هدیه از افراد مشهور یکی دیگر از انواع رایج کلاهبرداری هدیه است. کلاهبرداران یک مصاحبه ویدیویی ضبطشده یا سخنرانی در همایش با حضور یک فرد مشهور را در یوتوب بهصورت زنده پخش میکنند - جوری که به نظر برسد آن فرد مشهور یک مصاحبه ویدیویی زنده دارد که در آن هدیهای در قالب ارز رمزنگاریشده را تأیید میکند.
+کلاهبرداری در قالب هدیه افراد مشهور یکی دیگر از انواع رایج کلاهبرداری هدیه است. کلاهبرداران یک مصاحبه ویدیویی ضبطشده یا سخنرانی در همایش با حضور یک فرد مشهور را در یوتوب بهصورت زنده پخش میکنند - جوری که به نظر برسد آن فرد مشهور یک مصاحبه ویدیویی زنده دارد که در آن هدیهای در قالب ارز رمزنگاریشده را تأیید میکند.
ویتالیک بوترین بیشتر اوقات در این کلاهبرداری مورد استفاده قرار میگیرد، اما بسیاری از افراد مطرح دیگر در حوزه ارزهای رمزنگاریشده نیز استفاده میشوند (مثال ایلان ماسک و چارلز هاسکینسون). دخیل کردن یک فرد بسیار مشهور میتواند به پخش زنده ویدیویی کلاهبرداران نوعی حس مشروعیت ببخشد (به نظر بودار میآید، اما پای ویتالیک هم وسط است، پس نباید مشکلی باشد!).
**هدیهها همیشه کلاهبرداری هستند. اگر پولتان را به این حسابها بفرستید، آن را برای همیشه از دست خواهید داد.**
-![یک کلاهبرداری در یوتوب](./youtubeScam.png)
+![یک کلاهبرداری در یوتیوب](./youtubeScam.png)
-### کلاهبرداری پشتیبانی {#support-scams}
+### کلاهبرداریهای پشتیبانی {#support-scams}
-ارز رمزنگاری شده یک فناوری نسبتاً نوپا است که خیلی وقتها درست فهمیده نمیشود. یکی از کلاهبرداریهای رایج که از این موضوع سوء استفاده میکند کلاهبرداری پشتیبانی است که در آن، کلاهبرداران خود را بهعنوان عامل پشتیبانی کیف پولها، صرافیها یا بلاکچینهای شناختهشده جا میزند.
+ارز رمزنگاری شده یک فناوری نسبتاً نوپا است که خیلی وقتها درست فهمیده نمیشود. یکی از کلاهبرداریهای رایج که از این موضوع سوء استفاده میکند کلاهبرداری پشتیبانی است که در آن، کلاهبرداران خود را بهعنوان عامل پشتیبانی کیف پولها، صرافیها یا بلاکچینهای شناختهشده جا میزنند.
اکثر بحث و گفتگوها درباره اتریوم روی Discord انجام میشود. کلاهبرداران پشتیبانی معمولاً افراد هدف خود را با جستجوی کسانی که در کانالهای عمومی Discord سؤالات مربوط به پشتیبانی مطرح میکنند پیدا میکنند، و سپس جهت ارائه پشتیبانی به آنها پیام خصوصی میفرستند. کلاهبرداران پشتیبانی با اعتمادسازی سعی میکنند شما را فریب دهند تا کلید خصوصیتان را افشا کنید یا پولتان را به کیف پول آنها بفرستید.
![یک کلاهبرداری پشتیبانی در Discord](./discordScam.png)
-بهعنوان یک قانون کلی، کارکنان هرگز ار راههای خصوصی و غیررسمی با شما ارتباط برقرار نمیکنند. چند نکتهی ساده که در برخورد با کلاهبرداری پشتیبانی باید در ذهن داشت از این قرار است:
+بهعنوان یک قانون کلی، کارکنان هرگز ار راههای خصوصی و غیررسمی با شما ارتباط برقرار نمیکنند. چند نکته ساده که در برخورد با کلاهبرداری پشتیبانی باید در ذهن داشت از این قرار است:
-- هیچگاه کلید خصوصی، عبارت seed یا گذرواژهی خود را بهاشتراک نگذارید
-- به هیچکس اجازهی دسترسی از راه دور به کامپیوترتان را ندهید
+- هیچگاه کلید خصوصی، عبارت seed یا گذرواژه خود را به اشتراک نگذارید
+- به هیچکس اجازه دسترسی از راه دور به کامپیوترتان را ندهید
- هیچگاه خارج از کانالهای اختصاصی یک سازمان با آن ارتباط برقرار نکنید
- آگاه باشید: درست است که کلاهبرداریهای پشتیبانی عموماً در دیسکورد رخ میدهند، اما امکان رخ دادن آنها در هر برنامهی پیامرسان که در آن بحث و گفتگو با محوریت ارزهای رمزنگاریشده انجام میشود نیز وجود دارد؛ از جمله ایمیل.
+ آگاه باشید: درست است که کلاهبرداریهای پشتیبانی عموماً در Discord رخ میدهند، اما امکان رخ دادن آنها در هر برنامه پیامرسان که در آن بحث و گفتگو با محوریت ارزهای رمزنگاریشده انجام میشود نیز وجود دارد؛ از جمله ایمیل.
### کلاهبرداری توکن 'Eth2' {#eth2-token-scam}
-در آستانه [ادغام](/roadmap/merge/)، کلاهبرداران از سردرگمی در مورد عبارت "Eth2" استفاده کردند و سعی کردند کاربران را وادار کنند که ETH خود را در قبال "ETH2" بازخرید کنند. هیچ «ETH2» وجود ندارد، و هیچ توکن قانونی دیگری با The Merge معرفی نشد. ETH که قبل از The Merge مالک آن بودید، اکنون همان ETH است. **نیازی به انجام هیچ گونه اقدام در رابطه با اتریوم شما برای محاسبه تغییر از اثبات کار به اثبات سهام وجود ندارد**.
+در آستانه [ادغام](/roadmap/merge/)، کلاهبرداران از سردرگمی در مورد عبارت "Eth2" استفاده کردند و سعی کردند کاربران را وادار کنند ETH خود را در قبال "ETH2" بازخرید کنند. «ETH2» وجود ندارد، و هیچ توکن قانونی دیگری با ادغام معرفی نشد. ETH که قبل از ادغام مالک آن بودید، اکنون همان ETH است. **نیازی به انجام هیچ گونه اقدام در رابطه با اتریوم شما برای محاسبه تغییر از اثبات کار به اثبات سهام وجود ندارد**.
-کلاهبرداران ممکن است به عنوان "پشتیبانی" ظاهر شوند و به شما می گویند که اگر ETH خود را واریز کنید، "ETH2" پس خواهید گرفت. [پشتیبانی رسمی اتریوم](/community/support/) وجود خارجی ندارد و هیچ توکن جدیدی در کار نیست. هرگز عبارت بذر کیف پول خود را با کسی به اشتراک نگذارید.
+کلاهبرداران ممکن است به عنوان "پشتیبانی" ظاهر شوند و به شما بگویند اگر ETH خود را واریز کنید، "ETH2" پس خواهید گرفت. [پشتیبانی رسمی اتریوم](/community/support/) وجود خارجی ندارد و هیچ توکن جدیدی در کار نیست. هرگز عبارت بذر کیف پول خود را با کسی به اشتراک نگذارید.
-_توجه: توکنها/تیکرهای مشتقی وجود دارند که ممکن است نشاندهنده اتر سهام گذاریشده (یعنی rETH از استخر Rocket و stETH از Lido و ETH2 از Coinbase) باشد، اما اینها چیزی نیستند که شما نیاز به «مهاجرت به آن» داشته باشید._
+_توجه: توکنها/تیکرهای مشتقی وجود دارند که ممکن است نشاندهنده اتر سهام گذاریشده (یعنی rETH از استخر Rocket و stETH از Lido و ETH2 از Coinbase) باشند، اما اینها چیزی نیستند که شما نیاز به «مهاجرت به آن» داشته باشید._
### کلاهبرداری فیشینگ {#phishing-scams}
کلاهبرداریهای فیشینگ روش در حال رواج دیگری بین کلاهبرداران است که سعی میکنند از طریق آن موجودی کیف پول شما را بدزدند.
-برخی ایمیلهای فیشینگ از کاربران میخواهند روی لینکهایی کلیک کنند که آنها را به سایتهایی میبرند که از آنها میخواهد عبارت بذر را وارد کنند، گذرواژهشان را بازیابی کنند یا اتر بفرستند. برخی دیگر ممکن است از شما بخواهند ناآگاهانه بدافزاری را نصب کنید تا کامپیوترتان را آلوده کند و دسترسی به فایلهایتان را در اختیار کلاهبرداران قرار بدهد.
+برخی ایمیلهای فیشینگ از کاربران میخواهند روی لینکهایی کلیک کنند که آنها را به سایتهایی میبرند که از آنها میخواهند عبارت بذر را وارد کنند، گذرواژهشان را بازیابی کنند یا اتر بفرستند. برخی دیگر ممکن است از شما بخواهند ناآگاهانه بدافزاری را نصب کنید تا کامپیوترتان را آلوده کند و دسترسی به فایلهایتان را در اختیار کلاهبرداران قرار بدهد.
اگر ایمیلی از فرستندهای ناشناس دریافت کردید، به یاد داشته باشید:
-- هیچگاه پیوند یا پیوست ارسالی از آدرسهای ایمیل ناشناس را باز نکنید
-- هیچگاه گذرواژه یا اطلاعات شخصیتان را برای کسی فاش نکنید
+- هیچگاه لینک یا پیوست ارسالی از آدرسهای ایمیل ناشناس را باز نکنید
+- هیچگاه رمزها یا اطلاعات شخصیتان را برای کسی فاش نکنید
- ایمیلهای افراد ناشناس را پاک کنید
[اطلاعات بیشتر درباره پرهیز از کلاهبرداری فیشینگ](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico)
### کلاهبرداری کارگزاری معامله ارزهای رمزنگاریشده {#broker-scams}
-کارگزارهای تقلبی معامله ارزهای رمزنگاریشده ادعا میکنند که کارگزار تخصصی ارزهای رمزنگاری شده هستند و به شما پیشنهاد میدهند که پولتان را بگیرند و به جای شما سرمایهگذاری کنند. قول بازگشت سرمایه غیرواقعی نیز به همراه این پیشنهاد مطرح میشود. پس از آن که کلاهبردار سرمایه شما را گرفت، ممکن است رفتار شما را هدایت کند و از شما بخواهد سرمایه بیشتری به آنها بدهید تا از دریافت سود بیشتر جا نمانید، یا اینکه ممکن است به کلی ناپدید شوند.
+کارگزارهای جعلی معامله رمزارز ادعا می کنند کارگزارهای تخصصی رمزارز هستند و پیشنهاد می کنند پول شما را بگیرند تا از طرف شما سرمایهگذاری کنند. پس از آن که کلاهبردار سرمایه شما را گرفت، ممکن است رفتار شما را هدایت کند و از شما بخواهد سرمایه بیشتری به او بدهید تا از دریافت سود بیشتر جا نمانید، یا اینکه ممکن است به کلی ناپدید شود.
-این کارگزاریهای جعلی با استفاده از حسابهای جعلی در یوتیوب اهداف خود را پیدا میکنند تا بتوانند در مورد کارگزاری شان یک صحبت ظاهرا طبیعی داشته باشند. این صحبتها عموما به شدت رای مثبت دریافت میکنند تا وجهه آنها بهتر نشان داده شود اما این رأیهای مثبت از طرف حسابهای روباتی هستند.
+این کلاهبرداران اغلب با استفاده از حسابهای جعلی در یوتیوب طعمههایی را پیدا میکنند تا مکالمات به ظاهر طبیعی درباره «کارگزاری» را شروع کنند. این صحبتها عموما به شدت رای مثبت دریافت میکنند تا وجهه آنها بهتر نشان داده شود اما این رأیهای مثبت از طرف حسابهای روباتی هستند.
-**به غریبههای اینترنتی برای سرمایهگذاری بهجای خودتان اعتماد نکنید. ارز رمزنگاریشده خود را از دست خواهید داد.**
+**به غریبههای اینترنتی برای سرمایهگذاری بهجای شما اعتماد نکنید. رمزارز خود را از دست خواهید داد.**
![یک کلاهبرداری کارگزاری معاملاتی در یوتیوب](./brokerScam.png)
-### کلاهبرداریهای استخر استخراج ارز رمزنگاریشده {#mining-pool-scams}
+### کلاهبرداریهای استخر استخراج رمزارز {#mining-pool-scams}
-از سپتامبر 2022، استخراج در اتریوم دیگر امکان پذیر نیست. با این حال، کلاهبرداری استخر استخراج هنوز وجود دارد. کلاهبرداری استخر استخراج از افرادی سر میزند که به طور ناخواسته با شما تماس می گیرند و ادعا می کنند که می توانید با پیوستن به یک استخر استخراج اتریوم بازدهی زیادی داشته باشید. کلاهبردار ادعاهایی را مطرح میکند و تا وقتی لازم باشد با شما در ارتباط باقی میماند. اساساً کلاهبردار شما را قانع میکند که اگر به استخر استخراج اتریوم بپیوندید، ارزهای رمزنگاریشدهتان برای ساخت اتر استفاده خواهد شد و شما سود خود را به شکل اتر دریافت خواهید کرد. آن چه نهایتاً اتفاق میافتد این است که متوجه میشوید ارزهای رمزنگاری شدهتان بازگشت سرمایهی بسیار کمی دارند. هدف صرفاً ترغیب کردن شما به سرمایهگذاری بیشتر است. در نهایت، تمام وجوه شما به یک آدرس نامعلوم ارسال میشود و کلاهبردار یا ناپدید میشود یا در برخی موارد مانند یک مورد اخیر در تماس باقی میماند.
+از سپتامبر 2022، استخراج در اتریوم دیگر امکان پذیر نیست. با این حال، کلاهبرداری استخر استخراج هنوز وجود دارد. کلاهبرداری استخر استخراج از افرادی سر میزند که به طور ناخواسته با شما تماس می گیرند و ادعا می کنند که می توانید با پیوستن به یک استخر استخراج اتریوم، بازدهی زیادی داشته باشید. کلاهبردار ادعاهایی را مطرح میکند و تا وقتی لازم باشد با شما در ارتباط باقی میماند. در اصل، کلاهبردار سعی میکند شما را متقاعد کند وقتی به یک استخر استخراج اتریوم میپیوندید، از رمزارز شما برای تولید اتر استفاده میشود و سود سهامگذاری اتر به شما پرداخت میشود. سپس خواهید دید که رمزارز شما بازدهی کمی دارد. هدف صرفاً ترغیب شما به سرمایهگذاری بیشتر است. در نهایت، تمام وجوه شما به یک آدرس نامعلوم ارسال میشود و کلاهبردار یا ناپدید میشود یا در برخی موارد مانند موردی که اخیرا رخ داده، در تماس باقی میماند.
-جان کلام، مراقب افرادی باشید که در رسانههای اجتماعی به شما پیام میدهند و از شما میخواهند عضو یک استخر استخراج شوید. وقتی ارز رمزنگاریشدهتان را از دست بدهید، دیگر نمیتوان آن را برگرداند.
+موضوع اساسی: مراقب افرادی باشید که در رسانههای اجتماعی با شما ارتباط میگیرند و از شما میخواهند عضوی از یک استخر استخراج باشید. وقتی رمزارزتان را از دست بدهید، دیگر نمیتوانید آن را برگردانید.
چند نکته برای بهخاطرسپاری:
-- در مقابل کسانی که به شما دربارهی پول درآوردن از ارز رمزنگاریشدهتان پیام میدهند هشیار باشید
-- در مورد سهامگذاری، استخرهای نقدینگی یا هر روش دیگر سرمایهگذاری با ارزهای رمزنگاریشده خودتان تحقیق کنید
-- اگر نخواهیم بگوییم هرگز، چنین طرحهایی بهندرت موجه هستند. اگر موجه بودند، احتمالاً بهشدت رایج بودند و شما دربارهی آنها میشنیدید.
+- در مقابل کسانی که به شما درباره پول درآوردن از رمزارزتان پیام میدهند هشیار باشید
+- در مورد سهامگذاری، استخرهای نقدینگی یا هر روش دیگر سرمایهگذاری با رمزارزهایتان تحقیق کنید
+- اگر نخواهیم بگوییم هرگز، چنین طرحهایی بهندرت موجه هستند. اگر موجه بودند، احتمالاً بهشدت رایج بودند و شما درباره آنها میشنیدید.
[مردی 200 هزار دلار را در یک کلاهبرداری استخر استخراج از دست داد](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/)
-### کلاهبرداری ایردراپ {#airdrop-scams}
+### کلاهبرداریهای ایردراپ {#airdrop-scams}
-کلاهبرداریهای ایردراپ پروژههای جعلیای هستند که یک دارایی (NFT، توکن) را به کیف پول شما ایردراپ میکنند و شما را به یک وبسایت کلاهبرداری هدایت میکنند تا دارایی ایردراپشده را دریافت کنید. از شما خواسته میشود که با کیف پول اتریومتان وارد وبسایت شوید و با یک تراکنش برای پذیرش آن دارایی «موافقت کنید». این تراکنش با فرستادن کلیدهای خصوصی و عمومی شما به کلاهبردار، حسابتان را فاش میکند. شکل دیگر این کلاهبرداری اینگونه است که شما تراکنشی را تأیید کنید که مبلغی را به حساب کلاهبردار واریز میکند.
+کلاهبرداریهای ایردراپ پروژههای جعلی هستند که یک دارایی (NFT، توکن) را به کیف پول شما ایردراپ میکنند و شما را به یک وبسایت کلاهبرداری هدایت میکنند تا دارایی ایردراپشده را دریافت کنید. از شما خواسته میشود با کیف پول اتریومتان وارد وبسایت شوید و با یک تراکنش برای پذیرش آن دارایی «موافقت کنید». این تراکنش با فرستادن کلیدهای خصوصی و عمومی شما به کلاهبردار، حسابتان را فاش میکند. شکل دیگر این کلاهبرداری اینگونه است که شما تراکنشی را تأیید کنید که مبلغی را به حساب کلاهبردار واریز میکند.
[اطلاعات بیشتر درباره کلاهبرداری ایردراپ](https://www.youtube.com/watch?v=LLL_nQp1lGk)
+## امنیت شبکه 101 {#web-security}
+
+### از رمزهای قوی استفاده کنید {#use-strong-passwords}
+
+[بیش از 80% هک شدن حسابهای کاربری ناشی از رمزهای ضعیف یا بهسرقترفته است](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). ترکیب طولانی کاراکترها، اعداد و نمادها به حفظ امنیت حسابهای شما کمک میکند.
+
+یک اشتباه رایج استفاده از ترکیب چند کلمه رایج و مرتبط است. رمزهای شبیه این ناامن هستند زیرا مستعد یک تکنیک هک به نام حمله دیکشنری هستند.
+
+```md
+نمونه یک رمز ضعیف: CuteFluffyKittens!
+
+نمونه یک رمز قوی: ymv\*azu.EAC8eyp8umf
+```
+
+یکی دیگر از اشتباهات رایج استفاده از رمزهایی است که بهراحتی میتوان آنها را از طریق [مهندسی اجتماعی](https://wikipedia.org/wiki/Social_engineering_(security)) حدس زد یا کشف کرد. گنجاندن نام مادر، نام فرزندان یا حیوانات خانگی یا تاریخ تولد در رمز عبور، خطر هک شدن را افزایش میدهد.
+
+#### ویژگیهای رمز خوب: {#good-password-practices}
+
+- تا جایی که برنامه رمزساز شما یا فرمی که مشغول پُر کردن آن هستید اجازه میدهد، رمزتان را طولانی بنویسید
+- از ترکیب حروف بزرگ، کوچک، اعداد و علامت ها استفاده کنید
+- از اطلاعات شخصی، مانند نام خانوادگی، در رمز خود استفاده نکنید
+- از کلمات رایج بپرهیزید
+
+[اطلاعات بیشتر درباره ساخت رمز قدرتمند](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/)
+
+### برای همهچیز، از گذرواژههای منحصربهفرد استفاده کنید {#use-unique-passwords}
+
+رمز قوی که در لو رفتن اطلاعات فاش شده باشد، دیگر یک رمز قوی نیست. از طریق وبسایت [Have I Been Pwned](https://haveibeenpwned.com) میتوانید بررسی کنید که آیا حسابهای شما در هر گونه نشت دادههای عمومی لو رفتهاند یا نه. اگر لو رفتهاند، **آن رمزها را فوراً تغییر دهید**. استفاده از رمزهای منحصر به فرد برای هر حساب، خطر دسترسی هکرها به تمام حسابهای شما را در صورت به خطر افتادن یکی از رمزهایتان، کاهش میدهد.
+
+### از یک برنامه مدیریت رمز استفاده کنید {#use-password-manager}
+
+
+
+ استفاده از برنامههای مدیریت رمز میتواند خیال شما را از حیث ساخت رمزهای قوی و منحصربهفرد و بهخاطرسپاری آنها راحت کند! ما قویاً توصیه میکنیم از یک برنامه مدیریت رمز استفاده کنید. بیشتر این برنامهها رایگان هستند!
+
+
+
+بهخاطرسپاری رمزهای قوی و منحصربهفرد برای هر حساب راهکار ایدهآلی نیست. یک برنامه مدیریت رمز، محلی امن و رمزنگاریشده برای تمام رمزها در اختیارتان قرار میدهد که میتوانید از طریق یک رمز مادر به آن دسترسی داشته باشید. بهعلاوه، این برنامهها هنگام ثبتنام در یک سرویس جدید به شما رمزهای قوی پیشنهاد میدهند تا لازم نباشد خودتان رمز بسازید. بسیاری از برنامههای مدیریت رمز همچنین به شما خواهند گفت که اطلاعاتتان در نشت داده ها درز کرده است یا خیر. در این صورت میتوانید پیش از هرگونه حمله خرابکارانه رمزهایتان را عوض کنید.
+
+![مثالی برای استفاده از برنامه مدیریت رمز](./passwordManager.png)
+
+#### یک برنامه مدیریت رمز را امتحان کنید: {#try-password-manager}
+
+- [Bitwarden](https://bitwarden.com/)
+- [KeePass](https://keepass.info/)
+- [1Password](https://1password.com/)
+- و یا دیگر [نرم افزارهای مدیریت رمز توصیه شده](https://www.privacytools.io/secure-password-manager) را بررسی کنید
+
+### از احراز هویت دو عاملی استفاده کنید {#two-factor-authentication}
+
+گاهی اوقات ممکن است از شما خواسته شود هویتتان را از طریق مدارک انحصاری تأیید کنید. به اینها میگوییم **عوامل**. سه عامل مهم شامل این مواردند:
+
+- چیزی که میدانید (مانند یک رمز یا سؤال امنیتی)
+- چیزی که هستید (مانند اثر انگشت یا اسکنر قرنیه/صورت)
+- چیزی که دارید (مانند یک کلید امنیتی یا برنامههای احراز هویت روی تلفن همراه)
+
+استفاده از **احراز هویت دوعاملی (2FA)** یک *عامل امنیتی* اضافی را برای حسابهای آنلاین شما فراهم میکند. احراز هویت دوعاملی تضمین میکند که صرف داشتن رمز برای دسترسی به یک حساب کاربری کافی نیست. عامل دوم معمولاً یک کد 6 رقمی تصادفی است که به آن **رمز یکبارمصرف زماندار (TOTP)** میگویند و با یک برنامه احراز هویت مثل Google Authenticator یا Authy میتوانید به آن دسترسی داشته باشید. اینها بهعنوان عامل «چیزی که دارید» عمل میکنند، چون هستهای که کد زماندار را میسازد روی دستگاه شما نگهداری میشود.
+
+
+
+ توجه: استفاده از 2FA پیامکی، در معرض استراق سمع سیم کارت است و ایمن نیست. برای بهترین امنیت، از سرویسی مانند Google Authenticator یا Authy استفاده کنید.
+
+
+
+#### کلید امنیتی {#security-keys}
+
+کلید امنیتی نوع پیشرفته و ایمن 2FA است. کلیدهای امنیتی نوعی دستگاههای احراز هویت با سختافزار فیزیکی هستند که مانند برنامههای احراز هویت کار میکنند. استفاده از کلید امنیتی امنترین روش برای احراز هویت دو عاملی است. بسیاری از این کلیدها از استاندارد عامل دوم جهانی (U2F) FIDO استفاده میکنند. [اطلاعات بیشتر دربارهی FIDO U2F](https://www.yubico.com/authentication-standards/fido-u2f/).
+
+بیشتر درباره 2FA ببینید:
+
+
+
+### افزونههای مرورگر را پاک کنید {#uninstall-browser-extensions}
+
+افزونههای مرورگر، مانند افزونههای کروم یا افزونههای فایرفاکس، میتوانند عملکرد مرورگر را بهبود بخشند، اما خطراتی نیز دارند. بهطور پیشفرض، اکثر افزونههای مرورگرها برای «خواندن و تغییر دادههای سایت» دسترسی میخواهند که به آنها اجازه میدهد با دادههایتان تقریباً هر کاری بکنند. افزونههای Chrome معمولاً بهطور خودکار بهروزرسانی میشوند. در نتیجه، افزونهای که اکنون امن است، ممکن است پس از بهروزرسانی به یک افزونهی خرابکار تبدیل شود. اکثر افزونههای مرورگر قصد ندارند دادههای شما را بدزدند، اما باید بدانید که میتوانند این کار را بکنند.
+
+#### با این کارها ایمن بمانید: {#browser-extension-safety}
+
+- افزونههای مرورگر را تنها از منابع مطمئن نصب کنید
+- افزونههای مرورگر بیاستفاده را پاک کنید
+- افزونههای Chrome را بهصورت محلی نصب کنید تا از بهروزرسانی خودکار جلوگیری کنید (پیشرفته)
+
+[اطلاعات بیشتر دربارهی ریسکهای افزونههای مرورگر](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/)
+
+
+
## بیشتر بخوانید {#further-reading}
### امنیت وب {#reading-web-security}
-- [به این دلیل نباید از پیامک برای احراز هویت دو عاملی استفاده کنید](https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin) - _The Verge_
-- [نزدیک به 3 میلیون دستگاه به بدافزاری روی افزونههای Chrome و Edge آلوده شدند](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) - _ دن گودین_
-- [چگونه گذرواژهای قوی بسازیم که فراموش نکنیم](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) - _AVG_
+- [نزدیک به 3 میلیون دستگاه به بدافزاری روی افزونههای Chrome و Edge آلوده شدند](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) - _دن گودین_
+- [چگونه رمزی قوی بسازیم که فراموش نکنیم](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) - _AVG_
- [کلید امنیتی چیست؟](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) - _Coinbase_
### امنیت ارزهای رمزنگاریشده {#reading-crypto-security}
- [حفاظت از خود و سرمایهی خود](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) - _MyCrypto_
-- [4 راه برای ایمن ماندن در جهان ارزهای رمزنگاریشده](https://www.coindesk.com/tech/2021/04/20/4-ways-to-stay-safe-in-crypto/) - _CoinDesk_
+- [مشکلات امنیتی رایج در نرم افزار معمول ارتباطی رمزنگاری](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) - _Salus_
- [راهنمای امنیت برای تازهواردها و همچنین باهوشها](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) - _MyCrypto_
- [امنیت ارزهای رمزنگاریشده: گذرواژهها و احراز هویت](https://www.youtube.com/watch?v=m8jlnZuV1i4) - _آندرس ام. آنتوپولوس_
diff --git a/public/content/translations/fa/smart-contracts/index.md b/public/content/translations/fa/smart-contracts/index.md
index ebf6e83bad3..f1914381563 100644
--- a/public/content/translations/fa/smart-contracts/index.md
+++ b/public/content/translations/fa/smart-contracts/index.md
@@ -6,11 +6,15 @@ lang: fa
# مقدمهای بر قراردادهای هوشمند {#introduction-to-smart-contracts}
-قرارداد های هوشمند بنیادیترین اجزای سازنده لایه اپلیکیشن اتریوم هستند. آن ها برنامه های کامپیوتری دخیره شده بر روی بستر بلاکچین هستند که از منطق "اگر این بنابراین آن" پیروی می کنند و تضمین می شوند که بر اساس قوانین تعریف شده از سوی کد آن اجرا شوند و زمانی که ایجاد شدند دیگر قابل تغییر نخواهند بود.
+قرارداد های هوشمند بنیادیترین اجزای سازنده لایه اپلیکیشن اتریوم هستند. آن ها برنامه های کامپیوتری دخیره شده بر روی بستر [بلاکچین](/glossary/#blockchain) هستند که از منطق "اگر این بنابراین آن" پیروی می کنند و تضمین می شود که بر اساس قوانین تعریف شده از سوی کد آن اجرا شوند و زمانی که ایجاد شدند دیگر قابل تغییر نخواهند بود.
نیک سابو برای اولین بار آنها را «قرارداد هوشمند» نامید. او در سال 1994 اینگونه نوشت [مقدمه ای بر مفهوم قرارداد های هوشمند](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html)، و در 1996 نوشت [کاوشی بر آنچه قرارداد های هوشمند می توانند انجام دهند](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html).
-سابو یک بازار دیجیتال را تجسم کرد که در آن فرایندهای خودکار و امن از نظر رمزنگاری، تراکنش ها و وظایف کسب و کار را قادر میسازند بدون واسطه های مورد اعتماد رخ دهند. قراردادهای هوشمند در اتریوم به این تجسم جامه عمل میپوشانند.
+سابو یک بازار دیجیتال را متصور بود که در آن فرایندهای [رمزنگارانه ایمن](/glossary/#cryptography) و خودکار امکان انجام معاملات و عملکردهای تجاری را بدون نیاز به واسطههای مورد اعتماد فراهم میکنند. قراردادهای هوشمند در اتریوم به این تجسم جامه عمل میپوشانند.
+
+Watch Finematics قراردادهای هوشمند را توضیح میدهد:
+
+
## اعتماد در قراردادهای متعارف {#trust-and-contracts}
@@ -40,11 +44,11 @@ lang: fa
بهعنوان مثال، میتوانید یک قرارداد هوشمند بنویسید که مبلغی را برای یک کودک نزد شخص ثالث نگه دارد و به او اجازه دهد پس از یک تاریخ خاص مبلغ را برداشت کند. اگر سعی کند وجه را قبل از تاریخ مشخص شده برداشت کند، قرارداد هوشمند اجرا نمیشود. یا میتوانید قراردادی بنویسید که نسخهی دیجیتالی سند خودرو را هنگام پرداخت قیمت معامله به فروشنده بهطور خودکار به شما بدهد.
-## خروجیهای قابل پیشبینی {#predictability}
+## نتایج قابل پیشبینی {#predictability}
قراردادهای سنتی مبهم هستند زیرا تفسیر و اجرای آنها به عهده انسان است. برای مثال، دو قاضی ممکن است تفسیر متفاوتی از یک قرارداد یکسان داشته باشند،که میتواند منجر به تصمیمات ناسازگار و نتیجه نهایی نابرابر شود. قراردادهای هوشمند این احتمال را از بین میبرند. در عوض، قراردادهای هوشمند دقیقاً بر اساس شرایط نوشته شده در کد قرارداد اجرا میشوند. این دقت به این معنی است که در شرایط یکسان، قرارداد هوشمند نتیجه یکسان را به همراه خواهد داشت.
-## سابقهی عمومی {#public-record}
+## سابقه عمومی {#public-record}
قراردادهای هوشمند برای حسابرسی و ردیابی مفید هستند. از آنجایی که قراردادهای هوشمند اتریوم بر روی یک بلاکچین عمومی قرار دارند، هر کس میتواند فوراً انتقال داراییها و سایر اطلاعات مرتبط را ردیابی کند. برای مثال، شما میتوانید چک کنید که آیا کسی به آدرس شما پول فرستاده است یا نه.
@@ -60,7 +64,7 @@ lang: fa
قراردادهای هوشمند اصولاً قادرند هر کاری را که توسط نرمافزارهای رایانهای قابل انجام است انجام دهند.
-این کار دیگر میتواند انجام محاسبات، ایجاد واحد پولی، ذخیره داده، استخراج توکنهای غیرقابل معاوضه، برقراری ارتباط یا حتی ایجاد تصاویر گرافیکی باشد. در ادامه چند مثال معمول از دنیای واقعی آورده شده است:
+آنها میتوانند محاسبات، ایجاد ارز، ذخیره کردن داده، ضرب کردن [NFTها](/glossary/#nft)، ایجاد ارتباط و حتی تولید گرافیک را انجام دهند. در ادامه چند مثال معمول از دنیای واقعی آورده شده است:
- [پایدارزها](/stablecoins/)
- [ایجاد و توزیع داراییهای یکتای دیجیتال](/nft/)
@@ -69,12 +73,6 @@ lang: fa
- [یک بیمهنامه که بهصورت خودکار پرداخت میکند.](https://etherisc.com/)
- [استانداردی که به افراد امکان میدهد ارزهای سفارشیشده و قابل تعامل ایجاد کنند](/developers/docs/standards/tokens/)
-## فردی هستید که با توضیحات تصویری راحتترید؟ {#visual-learner}
-
-Watch Finematics قراردادهای هوشمند را توضیح میدهد:
-
-
-
## بیشتر بخوانید {#further-reading}
- [چگونه قراردادهای هوشمند دنیا را تغییر خواهند داد](https://www.youtube.com/watch?v=pA6CGuXEKtQ)
diff --git a/public/content/translations/fa/social-networks/index.md b/public/content/translations/fa/social-networks/index.md
index c9c6640427f..e3352a79d85 100644
--- a/public/content/translations/fa/social-networks/index.md
+++ b/public/content/translations/fa/social-networks/index.md
@@ -15,86 +15,74 @@ summaryPoint3: توکن ها و نیفتی ها راه های جدیدی برا
## شبکه های اجتماعی غیرمتمرکز چی هستند؟ {#what-are-decentralized-social-networks}
-شبکههای اجتماعی غیرمتمرکز پلتفرمهایی مبتنی بر بلاک چین هستند که به کاربران امکان تبادل اطلاعات و همچنین انتشار و توزیع محتوا برای مخاطبان را میدهند. از آنجایی که این برنامهها بر روی بلاک چین اجرا میشوند، میتوانند غیرمتمرکز باشند و در برابر سانسور و کنترل بیرویه مقاوم باشند.
+شبکههای اجتماعی غیرمتمرکز پلتفرمهایی [مبتنی بر بلاک چین](/glossary/#blockchain) هستند که به کاربران امکان تبادل اطلاعات و نیز انتشار و توزیع محتوا برای مخاطبان را میدهند. از آنجایی که این برنامهها بر روی بلاک چین اجرا میشوند، میتوانند غیرمتمرکز باشند و در برابر سانسور و کنترل بیرویه مقاوم باشند.
بسیاری از شبکههای اجتماعی غیرمتمرکز بهعنوان جایگزینی برای سرویسهای رسانههای اجتماعی موجود تاسیس شده اند. مانند فیسبوک، لینکدین، توییتر و مدیوم . اما شبکه های اجتماعی مبتنی بر بلاک چین دارای تعدادی ویژگی هستند که آنها را از پلتفرم های اجتماعی سنتی برتری می دهد.
+
+
### شبکه های اجتماعی غیرمتمرکز چگونه کار می کنند؟ {#decentralized-social-networks-overview}
-شبکههای اجتماعی غیرمتمرکز دستهای از [برنامههای کاربردی غیرمتمرکز (dapps)](/dapps/) هستند که توسط [قراردادهای هوشمند](/developers/docs/smart-contracts/) مستقر در بلاک چین قدرت میگیرند. کد قرارداد به عنوان پشتیبان این برنامه ها عمل می کند و منطق تجاری آنها را تعریف می کند.
+شبکههای اجتماعی غیرمتمرکز دستهای از [ برنامههای کاربردی غیرمتمرکز (dapps) ](/dapps/) هستند که توسط [ قراردادهای هوشمند ](/glossary/#smart-contract) مستقر در بلاک چین پشتیبانی می شوند. کد قرارداد به عنوان پشتیبان این برنامه ها عمل می کند و منطق تجاری آنها را تعریف می کند.
-پلتفرمهای رسانههای اجتماعی سنتی برای ذخیره اطلاعات کاربر، کد برنامه و سایر اشکال داده به پایگاههای داده متکی هستند. که این باعث ایجاد نقاط شکست واحد می شود و خطر قابل توجهی را ایجاد می کند. به عنوان مثال، سرورهای فیس بوک سال گذشته به طرز بدنامی [برای ساعت ها آفلاین شدند](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) و کاربران را از پلتفرم قطع کردند.
+پلتفرمهای رسانههای اجتماعی سنتی برای ذخیره اطلاعات کاربر، کد برنامه و سایر اشکال داده به پایگاههای داده متکی هستند. ولی این باعث ایجاد نقاط شکست واحد می شود و خطر قابل توجهی را ایجاد می کند. به عنوان مثال، سرورهای فیس بوک در اکتبر 2021 به طرز بدنامی [ برای ساعت ها آفلاین شدند ](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) و کاربران را از پلتفرم قطع کردند.
-شبکه های اجتماعی غیرمتمرکز در یک شبکه همتا به همتا (peer-to-peer) وجود دارند که شامل هزاران گره در سراسر جهان است حتی اگر برخی از گره ها از کار بیفتند، شبکه بدون وقفه اجرا می شود و برنامه ها را در برابر خرابی ها و قطعی ها مقاوم می کند.
+شبکه های اجتماعی غیرمتمرکز در یک [شبکه همتا به همتا (peer-to-peer)](/glossary/#peer-to-peer-network) وجود دارند که شامل هزاران گره (nodes) در سراسر جهان است حتی اگر برخی از گره ها از کار بیفتند، شبکه بدون وقفه اجرا می شود و برنامه ها را در برابر خرابی ها و قطعی ها مقاوم می کند.
-با استفاده از سیستمهای ذخیرهسازی غیرمتمرکز مانند [سیستم فایل بین سیارهای (IPFS به معنای فایل سیستم بین سیاره ای است که در واقع یک سیستم توزیع فایل همتا به همتا و غیر متمرکز است)](https://ipfs.io/)، شبکههای اجتماعی ساخته شده بر روی اتریوم میتوانند از اطلاعات کاربر در برابر سوء استفاده و استفاده مخرب محافظت کنند هیچ کس اطلاعات شخصی شما را به تبلیغ کنندگان نمی فروشد و هکرها نیز نمی توانند اطلاعات محرمانه شما را بدزدند.
+با استفاده از سیستمهای ذخیرهسازی غیرمتمرکز مانند [ سیستم فایل بین سیارهای (IPFS به معنای فایل سیستم بین سیاره ای است که در واقع یک سیستم توزیع فایل همتا به همتا و غیر متمرکز است)](https://ipfs.io/)، شبکههای اجتماعی ساخته شده بر روی اتریوم میتوانند از اطلاعات کاربر در برابر سوء استفاده و استفاده مخرب محافظت کنند. هیچ کس اطلاعات شخصی شما را به تبلیغ کنندگان نمی فروشد و هکرها نیز نمی توانند اطلاعات محرمانه شما را بدزدند.
-بسیاری از پلتفرمهای اجتماعی مبتنی بر بلاک چین دارای توکنهای بومی هستند که در غیاب درآمد تبلیغاتی به کسب درآمد کمک میکنند. کاربران میتوانند این توکنها را برای دسترسی به برخی ویژگیها، تکمیل خریدهای درونبرنامهای یا انعام به سازندگان محتوای مورد علاقه خود خریداری کنند.
+بسیاری از پلتفرمهای اجتماعی مبتنی بر بلاک چین دارای توکنهای بومی هستند که در غیاب درآمد تبلیغاتی به کسب درآمد کمک میکنند. کاربران میتوانند این توکنها را برای دسترسی به برخی ویژگیها، تکمیل خریدهای درونبرنامهای یا انعام دادن به سازندگان محتوای مورد علاقه خود خریداری کنند.
## مزایای شبکه های اجتماعی غیر متمرکز؟ {#benefits}
-1. شبکه های اجتماعی غیرمتمرکز در برابر سانسور مقاوم هستند و به روی همه باز هستند. این بدان معناست که کاربران را نمی توان خودسرانه ممنوع کرد، تغییر شکل داد یا محدود کرد.
+1. شبکه های اجتماعی غیرمتمرکز در برابر سانسور مقاوم هستند و به روی همه باز هستند. یعنی کاربران را **نمی توان خودسرانه ممنوع کرد**، پلتفرم آنها را تغییر داد، یا محدود کرد.
-2. شبکه های اجتماعی غیرمتمرکز بر اساس ایده آل های اپن سورس ساخته شده اند و سورس کد برنامه ها را برای بازرسی عمومی در دسترس قرار می دهند. با حذف اجرای الگوریتمهای غیرشفاف رایج در رسانههای اجتماعی سنتی، شبکههای اجتماعی مبتنی بر بلاک چین میتوانند علایق کاربران و سازندگان پلتفرم را همسو کنند.
+2. شبکه های اجتماعی غیرمتمرکز بر اساس **ایده آل های منبع باز ساخته شده اند** و کد منبع برنامه ها را برای بازرسی عمومی در دسترس قرار می دهند. با حذف اجرای الگوریتمهای غیرشفاف رایج در رسانههای اجتماعی سنتی، شبکههای اجتماعی مبتنی بر بلاک چین میتوانند علایق کاربران و سازندگان پلتفرم را همسو کنند.
-3. شبکه های اجتماعی غیرمتمرکز «مرد میانی» (middle-man) را حذف می کنند. سازندگان محتوا مالکیت مستقیمی بر محتوای خود دارند و مستقیماً با دنبالکنندگان، طرفداران، خریداران و سایر طرفها درگیر میشوند و چیزی جز یک قرارداد هوشمند در این بین ندارند.
+3. شبکه های اجتماعی غیرمتمرکز «مرد میانی» (middle-man) را حذف می کنند. **سازندگان محتوا مالکیت مستقیم بر محتوای خود دارند** و مستقیماً با دنبالکنندگان، طرفداران، خریداران و سایر طرفها درگیر میشوند و چیزی جز یک قرارداد هوشمند در این بین وجود ندارد.
-4. از آنجایی که برنامههایی که در شبکه اتریوم اجرا میشوند، که توسط یک شبکه جهانی و همتا به همتا از گرهها پشتیبانی میشود، شبکههای اجتماعی غیرمتمرکز کمتر در معرض خرابی و قطعی سرور هستند.
+4. مثل برنامههای غیرمتمرکز اجرا شده در شبکه اتریوم که توسط یک شبکه جهانی و همتا به همتا از گرهها پشتیبانی میشود، **شبکههای اجتماعی غیرمتمرکز کمتر در معرض خرابی** و قطعی سرور هستند.
-5. پلتفرمهای اجتماعی غیرمتمرکز یک چارچوب بهبودیافته درآمدزایی را برای سازندگان محتوا از طریق توکنهای غیرقابل تعویض (NFT)، پرداختهای رمزنگاری درون برنامهای و موارد دیگر ارائه میکنند.
+5. پلتفرمهای اجتماعی غیرمتمرکز یک چارچوب **بهبودیافته درآمدزایی** را برای سازندگان محتوا از طریق [توکنهای غیرقابل تعویض (NFT)](/glossary/#nft)، پرداختهای رمزارزی درون برنامه و موارد دیگر ارائه میکنند.
-6. شبکه های اجتماعی غیرمتمرکز سطح بالایی از حریم خصوصی و ناشناس بودن را برای کاربران فراهم می کند. به عنوان مثال، یک فرد میتواند با استفاده از نمایه یا کیف پول ENS به یک شبکه اجتماعی مبتنی بر اتریوم وارد شود - بدون اینکه نیازی به اشتراکگذاری اطلاعات شناسایی شخصی (PII) مانند نام، آدرس ایمیل و غیره باشد.
+6. شبکه های اجتماعی غیرمتمرکز **سطح بالایی از حریم خصوصی و ناشناس بودن** را برای کاربران فراهم می کند. مثلا یک فرد میتواند با استفاده از نمایه یا [کیف پول](/glossary/#wallet) [ENS](/glossary/#ens) به یک شبکه اجتماعی مبتنی بر اتریوم وارد شود - بدون اینکه نیازی به اشتراکگذاری اطلاعات شناسایی شخصی (PII) مانند نام، آدرس ایمیل و غیره باشد.
7. شبکههای اجتماعی غیرمتمرکز به ذخیرهسازی غیرمتمرکز متکی هستند، نه پایگاههای داده متمرکز، که برای حفاظت از دادههای کاربر بسیار بهتر هستند.
## شبکه های اجتماعی غیرمتمرکز در اتریوم {#ethereum-social-networks}
-شبکه اتریوم به دلیل محبوبیت توکنهای آن (ERC-20/ERC-721) و پایگاه کاربر عظیم آن، به ابزاری مطلوب برای توسعهدهندگانی تبدیل شده است که رسانههای اجتماعی غیرمتمرکز ایجاد میکنند. در اینجا چند نمونه از شبکه های اجتماعی مبتنی بر اتریوم آورده شده است:
-
-### Peepeth {#peepeth}
-
-[Peepeth](https://peepeth.com/) یک پلت فرم microblogging مشابه توییتر است. بر روی بلاک چین اتریوم اجرا می شود و از IPFS (IPFS به معنای فایل سیستم بین سیاره ای است که در واقع یک سیستم توزیع فایل همتا به همتا و غیر متمرکز است) برای ذخیره داده های کاربر استفاده می کند.
-
-کاربران می توانند پیام های کوتاهی به نام "Peeps" ارسال کنند که قابل حذف یا تغییر نیستند. میتوانید بدون ترک برنامه، نکاتی را جمعآوری کنید یا به هر کسی در پلتفرم در اتر (ETH) انعام دهید.
+شبکه اتریوم به دلیل محبوبیت توکنهای آن (ERC) و پایگاه کاربر عظیم آن، به ابزاری مطلوب برای توسعهدهندگانی تبدیل شده است که رسانههای اجتماعی غیرمتمرکز ایجاد میکنند. در اینجا چند نمونه از شبکه های اجتماعی مبتنی بر اتریوم آورده شده است:
### Mirror {#mirror}
-[Mirror](https://mirror.xyz/) یک پلتفرم نوشتاری دارای web3 فعال است که هدف آن غیرمتمرکز بودن و مالکیت کاربر است. کاربران می توانند با اتصال کیف پول خود به صورت رایگان در Mirror بخوانند و بنویسند. کاربران همچنین می توانند نوشته ها را درخواست کرده و همچنین نویسندگان مورد علاقه خود را دنبال کنند.
+[ Mirror](https://mirror.xyz/) یک پلتفرم نوشتاری دارای web3 فعال است که هدف آن غیرمتمرکز بودن و مالکیت کاربر است. کاربران می توانند با اتصال کیف پول خود به صورت رایگان در Mirror بخوانند و بنویسند. کاربران همچنین می توانند نوشته ها را درخواست کرده و همچنین نویسندگان مورد علاقه خود را دنبال کنند.
-پستهای منتشر شده در Mirror بهطور دائم در Arweave، یک پلتفرم ذخیرهسازی غیرمتمرکز، ذخیره میشوند و میتوانند بهعنوان [توکنهای غیرقابل تعویض قابل جمعآوری (NFT)](/nft/) به نام Writing NFT ذخیره شوند. گذاشتن NFT برای نویسندگان کاملاً رایگان است و جمعآوری آن بر روی Ethereum L2 انجام میشود – باعث میشود تراکنشها ارزان، سریع و سازگار با محیطزیست باشند.
+پستهای منتشر شده در Mirror بهطور دائم در Arweave، یک پلتفرم ذخیرهسازی غیرمتمرکز، ذخیره میشوند و میتوانند بهعنوان [ توکنهای غیرقابل تعویض قابل جمعآوری (NFT) ](/nft/) به نام Writing NFT ذخیره شوند. نوشتن NFT برای نویسندگان کاملاً رایگان است و جمعآوری آن در [لایه 2](/glossary/#layer-2) اتریوم انجام میشود - که باعث میشود تراکنشها ارزان، سریع و سازگار با محیطزیست باشند.
### MINDS {#minds}
[MINDS](https://www.minds.com/) یکی از پرکاربردترین شبکه های اجتماعی غیرمتمرکز است. مانند فیس بوک کار می کند و تاکنون میلیون ها کاربر را جذب کرده است.
-کاربران از رمز بومی ERC-20 پلتفرم $MIND برای پرداخت هزینه اقلام استفاده می کنند. کاربران همچنین می توانند با انتشار محتوای محبوب، کمک به اکوسیستم و ارجاع دیگران به پلتفرم، توکن های $MIND کسب کنند.
-
-## شبکه های اجتماعی Web2 در اتریوم {#web2-social-networks-and-ethereum}
+کاربران جهت انجام پرداخت برای آیتمها، از توکن بومی و مبتنی بر [ERC-20](/glossary/#erc-20) پلتفرم به نام $MIND استفاده میکنند. کاربران همچنین می توانند با انتشار محتوای محبوب، کمک به اکوسیستم و ارجاع دیگران به پلتفرم، توکن های $MIND کسب کنند.
-پلتفرمهای اجتماعی بومی [Web3](/web3/) تنها پلتفرمهایی نیستند که تلاش میکنند فناوری بلاک چین را در رسانههای اجتماعی بگنجانند. بسیاری از پلتفرم های متمرکز نیز در حال برنامه ریزی برای ادغام اتریوم در زیرساخت خود هستند:
-
-### Reddit {#reddit}
-
-Reddit [امتیازات جامعه را تبلیغ کرده است](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) ، که [توکنهای ERC-20](/developers/docs/standards/tokens/erc-20/) هستند که کاربران میتوانند با ارسال محتوای با کیفیت و مشارکت در انجمنهای آنلاین (subreddits) کسب کنند. برای دریافت امتیازات و امتیازات انحصاری، [میتوانید این توکنها را در یک Subreddit بازخرید کنید](https://www.reddit.com/community-points/). برای این پروژه، Reddit با Arbitrum کار میکند، یک مجموعه [لایه ۲](/layer-2/) که برای مقیاسبندی تراکنشهای اتریوم طراحی شده است.
-
-این برنامه در حال حاضر فعال است و زیر ردیت r/CryptoCurrency نسخه Community Points خود را به نام ["Moons"](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki) اجرا می کند. طبق توضیحات رسمی، Moons "به پوسترها، نظر دهندگان و ناظران برای مشارکت آنها در subreddit پاداش می دهد." زیرا این توکن ها هستند از آنجایی که این توکن ها روی بلاک چین قرار دارند (کاربران آنها را در کیف پول دریافت می کنند)، مستقل از Reddit هستند و نمی توان آنها را برداشت.
+## از شبکه های اجتماعی غیرمتمرکز استفاده کنید {#use-decentralized-social-networks}
-پس از پایان مرحله بتا در شبکه آزمایشی Rinkeby، امتیازات انجمن Reddit اکنون در [Arbitrum Nova](https://nova.arbitrum.io/)قرار دارند، یک زنجیره بلوکی که ویژگیهای یک [جانبی](/developers/docs/scaling/sidechains/) خوشبینانه [و یک مجموعه](/developers/docs/scaling/optimistic-rollups/)ترکیب میکند. علاوه بر استفاده از امتیازات انجمن برای باز کردن قفل ویژگیهای خاص، کاربران همچنین میتوانند آنها را با فیات در صرافیها مبادله کنند. همچنین، میزان امتیازات انجمنی که یک کاربر در اختیار دارد، تأثیر آنها را بر فرآیند تصمیمگیری در جامعه تعیین میکند.
+- **[Status.im](https://status.im/)** - _ یک برنامه پیام رسانی امن است که از یک پروتکل منبع باز، همتا به همتا و رمزگذاری سرتاسر برای محافظت از پیام های شما در برابر اشخاص ثالث استفاده می کند_.
+- **[Mirror.xyz](https://mirror.xyz/)** - _ یک پلتفرم انتشار غیرمتمرکز و متعلق به کاربر است که بر پایه اتریوم ساخته شده است تا کاربران بتوانند بر روی ایدههای خود سرمایهگذاری کنند، از محتوا کسب درآمد کنند و جوامع با ارزش بالا بسازند _.
+- **[Lens Protocol](https://lens.xyz/)** - _ پروتکل لنز یک نمودار اجتماعی قابل ترکیب و غیرمتمرکز است که به سازندگان کمک میکند تا هر کجا که در باغ دیجیتال اینترنت غیرمتمرکز میروند، مالکیت محتوای خود را در دست بگیرند_.
+- **[Farcaster](https://farcaster.xyz/)** - _Farcaster یک شبکه اجتماعی به اندازه کافی غیر متمرکز است. این یک پروتکل باز است که می تواند بسیاری از مشتریان را پشتیبانی کند، درست مانند ایمیل._
-### Twitter {#twitter}
+## شبکه های اجتماعی Web2 در اتریوم {#web2-social-networks-and-ethereum}
-در ژانویه 2021، توییتر آبی [از NFTها پشتیبانی کرد](https://mashable.com/article/twitter-blue-nft-profile-picture) و به کاربران این امکان را داد تا کیف پول خود را به هم متصل کنند و NFTها را به عنوان عکس نمایه نمایش دهند. در زمان نگارش این مقاله، این شرکت رسانه های اجتماعی همچنین [از برنامه های](https://www.theverge.com/2021/8/16/22627435/twitter-bluesky-lead-jay-graber-decentralized-social-web) خود برای ایجاد یک شبکه اجتماعی غیرمتمرکز در آینده خبر داده است.
+پلتفرمهای اجتماعی بومی [ Web3](/glossary/#web3) تنها پلتفرمهایی نیستند که تلاش میکنند فناوری بلاک چین را در رسانههای اجتماعی بگنجانند. بسیاری از پلتفرم های متمرکز نیز در حال برنامه ریزی برای ادغام اتریوم در زیرساخت خود هستند:
-### Instagram {#instagram}
+### Reddit {#reddit}
-در می 2022، [اینستاگرام از NFT ها](https://about.instagram.com/blog/announcements/instagram-digital-collectibles) در اتریوم و Polygon پشتیبانی کرد. کاربران می توانند با اتصال کیف پول اتریوم خود، NFT ها را مستقیماً به اینستاگرام ارسال کنند.
+ردیت دارای[امتیازهای تبلیغشده در انجمن](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) است که توکنهای ERC-20 هستند که کاربران میتوانند آنها را با ارسال محتوای با کیفیت و مشارکت در انجمنهای آنلاین (سابردیتها) کسب کنند. برای دریافت امتیازات و امتیازات انحصاری، میتوانید این توکنها را در یک سابردیت بازخرید کنید. برای این پروژه، ردیت با آربیتروم کار میکند، که یک شبکه [لایه 2](/glossary/#layer-2) است که برای مقیاسبندی تراکنشهای اتریوم طراحی شده است.
-## از شبکه های اجتماعی غیرمتمرکز استفاده کنید {#use-decentralized-social-networks}
+این برنامه در حال حاضر فعال است و زیر ردیت r/CryptoCurrency نسخه Community Points خود را به نام [ "Moons" ](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki) اجرا می کند. طبق توضیحات رسمی، Moons "به پوسترها، نظر دهندگان و ناظران برای مشارکت آنها در subreddit پاداش می دهد." زیرا این توکن ها هستند از آنجایی که این توکن ها روی بلاک چین قرار دارند (کاربران آنها را در کیف پول دریافت می کنند)، مستقل از Reddit هستند و نمی توان آنها را برداشت.
-- **[Status.im](https://status.im/)** - _ یک برنامه پیام رسانی امن است که از یک پروتکل منبع باز، همتا به همتا و رمزگذاری سرتاسر برای محافظت از پیام های شما در برابر اشخاص ثالث استفاده می کند_.
-- **[Mirror.xyz](https://mirror.xyz/)** - _ یک پلتفرم انتشار غیرمتمرکز و متعلق به کاربر است که بر پایه اتریوم ساخته شده است تا کاربران بتوانند بر روی ایدههای خود سرمایهگذاری کنند، از محتوا کسب درآمد کنند و جوامع با ارزش بالا بسازند _.
-- **[Lens Protocol](https://lens.xyz/)** - _ پروتکل لنز یک نمودار اجتماعی قابل ترکیب و غیرمتمرکز است که به سازندگان کمک میکند تا هر کجا که در باغ دیجیتال اینترنت غیرمتمرکز میروند، مالکیت محتوای خود را در دست بگیرند_.
-- **[Farcaster](https://farcaster.xyz/)** - _Farcaster یک شبکه اجتماعی به اندازه کافی غیر متمرکز است. این یک پروتکل باز است که می تواند بسیاری از مشتریان را پشتیبانی کند، درست مانند ایمیل._
+علاوه بر استفاده از امتیازات انجمن برای باز کردن قفل ویژگیهای خاص، کاربران میتوانند آنها را با فیات در صرافیها مبادله کنند. همچنین، امتیازات انجمن که یک کاربر در اختیار دارد، تأثیر او را بر فرآیند تصمیمگیری در جامعه تعیین میکند.
## بیشتر بخوانید {#further-reading}
@@ -105,7 +93,6 @@ Reddit [امتیازات جامعه را تبلیغ کرده است](https://coi
- [Web3 نوید شبکه های اجتماعی غیرمتمرکز و مبتنی بر جامعه را دارد](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_
- [مروری بر چشم انداز رسانه های اجتماعی بلاک چین](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_
- [چگونه بلاک چین می تواند حریم خصوصی رسانه های اجتماعی را حل کند](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_
-- [شبکه های رسانه های اجتماعی به بلاک چین می آیند](https://businesstechguides.co/what-are-decentralized-social-networks) — _Emmanuel Awosika_
- [عدم تمرکز کافی برای شبکه های اجتماعی](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_
### ویدیوها {#videos}
@@ -116,6 +103,4 @@ Reddit [امتیازات جامعه را تبلیغ کرده است](https://coi
### جوامع {#communities}
-- [سرور دیسکورد Status](https://discord.com/invite/3Exux7Y)
-- [سرور دیسکورد Mirror](https://discord.com/invite/txuCHcE8wV)
- [ساب ردیت r/CryptoCurrency subreddit](https://www.reddit.com/r/CryptoCurrency/)
diff --git a/public/content/translations/fa/staking/dvt/index.md b/public/content/translations/fa/staking/dvt/index.md
index dcd9caa4580..80b81f13a7c 100644
--- a/public/content/translations/fa/staking/dvt/index.md
+++ b/public/content/translations/fa/staking/dvt/index.md
@@ -68,7 +68,7 @@ DVT با سهامگذاری غیرحضانتی به شما امکان مید
DVT مسئولیت مدیریت کلید را در بین چندین گره تقسیم میکند، یعنی برخی هزینههای عملیاتی را نیز میتوان تقسیم کرد. DVT همچنین میتواند خطر عملیاتی و هزینههای بیمه را برای ارائهدهندگان سهامگذاری کاهش دهد.
-### Staking pools {#staking-pools}
+### استخرهای سهامگذاری {#staking-pools}
با توجه به تنظیمات استاندارد اعتبارسنج، استخرهای سهامگذاری و ارائهدهندگان سهامگذاری نقدینگی مجبورند سطوح مختلفی از اعتماد به یک اپراتور را داشته باشند زیرا سود و زیان در سراسر استخر به همه میرسد. آنها همچنین به اپراتورها از جهت محافظت از کلیدهای امضا متکی هستند، زیرا تاکنون هیچ گزینه دیگری برای آنها وجود نداشته است.
diff --git a/public/content/translations/fa/staking/pools/index.md b/public/content/translations/fa/staking/pools/index.md
index 884af093136..7436b3f3c8d 100644
--- a/public/content/translations/fa/staking/pools/index.md
+++ b/public/content/translations/fa/staking/pools/index.md
@@ -1,6 +1,6 @@
---
title: سهامگذاری مشترک
-description: مروری بر نحوه آغاز به کار سهامگذاری مشترک اتر
+description: مروری بر شروع سهامگذاری مشترک اتر
lang: fa
template: staking
emoji: ":money_with_wings:"
@@ -8,12 +8,12 @@ image: /images/staking/leslie-pool.png
alt: لسلی اسب آبی در حال شنا در استخر.
sidebarDepth: 2
summaryPoints:
- - از طریق تجمیع قوا با دیگران، هر چقدر اتریوم که میخواهید سهامگذاری کنید و پاداش کسب کنید
+ - از طریق تجمیع قوا با دیگران، هر چقدر اتر که میخواهید سهامگذاری کنید و پاداش کسب کنید
- بخش سخت را رها کنید و عملیات اعتبارسنجی را به شخص ثالث بسپارید
- توکنهای سهامگذاری را در کیفپول خودتان نگه دارید
---
-## استخر سهامگذاری چیست؟ {#what-are-staking-pools}
+## استخر سهامگذاری چیست؟ {#what-are-staking-pools}
استخر سهامگذاری یک رویکرد مبتنی بر همکاری است که به افراد بسیاری که مقادیر اتر کمتری دارند امکان میدهد 32 اتر لازم برای فعال کردن مجموعهای از کلیدهای اعتبارسنجی را به دست آورند. عملکرد ادغام بهطور بومی در پروتکل پشتیبانی نمیشود، بنابراین راه حلهایی بهطور جداگانه برای رفع این نیاز ساخته شدند.
@@ -53,14 +53,14 @@ summaryPoints:
-لطفاً از اهمیت انتخاب سرویسی که [تنوع کاربر](/developers/docs/nodes-and-clients/client-diversity/) را جدی بگیرد غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. سرویسهایی که مدارکی از محدود کردن استفاده اکثریت کاربران را دارند با عنوان "تنوع کاربر اجرایی" و "تنوع کاربر اجماعی" نشان داده میشوند.
+لطفاً از اهمیت انتخاب سرویسی که [تنوع کاربر](/developers/docs/nodes-and-clients/client-diversity/) را جدی بگیرد غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. سرویسهایی که شواهدی از محدود کردن استفاده اکثریت کاربران دارند با عنوان "تنوع کاربر اجرایی" و "تنوع کاربر اجماعی" نشان داده میشوند
ابزار سهامگذاری میشناسید که نگنجاندهایم؟ [سیاست فهرستبندی محصول](/contributing/adding-staking-products/) ما را برای اطمینان از مناسب بودن آن و ثبت آن جهت بررسی مشاهده کنید.
## پرسشهای متداول {#faq}
-معمولاً توکنهای سهامگذاری ERC-20 برای سهامگذارانی چاپ میشوند که نمایانگر ارزش اتر سهامگذاری شده آنها بهعلاوه پاداش باشند. در نظر داشته باشید که روش استخرهای مختلف برای توزیع پاداشهای سهامگذاری بین کاربرانشان کمی با هم متفاوت است، اما این رویکرد رایج است.
+معمولاً توکنهای سهامگذاری شده ERC-20 برای سهامگذاران صادر میشوند و ارزش اتر به اضافه پاداشهای سهامگذاری شده آنها را نشان میدهند. در نظر داشته باشید که استخرهای مختلف با روشهای کمی متفاوت، پاداشهای سهامگذاری را بین کاربرانشان توزیع خواهند کرد، که البته امری رایج است.
@@ -72,14 +72,15 @@ summaryPoints:
-شباهتهای زیادی بین این گزینههای سهامگذاری مشترک و صرافیهای متمرکز وجود دارد؛ نظیر توانایی سهامگذاری مقادیر کم اتر و ترکیب کردن آنها برای فعالسازی اعتبارسنجها.
+شباهتهای زیادی بین این گزینههای سهامگذاری مشترک و صرافیهای متمرکز وجود دارد؛ مانند توانایی سهامگذاری مقادیر کم اتر و ترکیب کردن آنها با یکدیگر برای فعالسازی اعتبارسنجها.
-برخلاف صرافیهای متمرکز، بسیاری دیگر از گزینههای سهامگذاری مشترک از قراردادهای هوشمند و/یا توکنهای سهامگذاری استفاده میکنند که معمولاً توکنهای ERC-20 هستند که میتوانید آنها را در کیفپول خود نگه دارید، و درست همانند هر توکن دیگری آنها را بخرید یا بفروشید. این کار با اعطای کنترل توکنهایتان به شما، لایهای از حاکمیت و امنیت را ارائه میدهد، اما در عین حال روی کاربر اعتبارسنجی که از طرف شما در پسزمینه تصدیق میکند، کنترل مستقیمی ارائه نمیدهد.
+برخلاف صرافیهای متمرکز، بسیاری دیگر از گزینههای سهامگذاری مشترک از قراردادهای هوشمند و/یا توکنهای سهامگذاری استفاده میکنند که معمولاً توکنهای ERC-20 هستند که میتوانید آنها را در کیفپول خود نگه دارید، و درست همانند هر توکن دیگری آنها را بخرید یا بفروشید. این کار با اعطای کنترل توکنهایتان به شما لایهای از حاکمیت و امنیت را ارائه میدهد، اما درعینحال به شما کنترل مستقیمی بر کلاینت اعتبارسنج که از طرف شما در پسزمینه اقدام به امضا کردن میکند ارائه نمیدهد.
-برخی از گزینههای ادغام از حیث گرههایی که آنها را پشتیبانی میکنند غیرمتمرکزتر از سایرین هستند. برای ارتقای سلامت و عدم تمرکز شبکه، به سهامگذاران همواره توصیه میشود که سرویس ادغامی را انتخاب کنند که یک مجموعه غیرمتمرکز بدون مجوز از عملگرهای گره را فعال میکند.
+برخی از گزینههای مشترکسازی از لحاظ نودهایی که آنها را پشتیبانی میکنند غیرمتمرکزتر از سایرین هستند. برای ارتقای سلامت و عدمتمرکز شبکه، همواره به سهامگذاران توصیه میشود که یک سرویس مشترکسازی را انتخاب کنند که یک مجموعه غیرمتمرکز بدون مجوز از اپراتورهای نود را فعال میکند.
## بیشتر بخوانید {#further-reading}
+- [فهرست سهامگذاری اتریوم](https://www.staking.directory/) - _Eridian و Spacesider_
- [ سهامگذاری با Rocket Pool - بررسی کلی سهامگذاری](https://docs.rocketpool.net/guides/staking/overview.html) _مستندات RocketPool _
- [ سهامگذاری اتریوم با لیدو](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) _مستندات کمکی لیدو_
diff --git a/public/content/translations/fa/staking/saas/index.md b/public/content/translations/fa/staking/saas/index.md
index 64ad0cbb44f..304a56433f1 100644
--- a/public/content/translations/fa/staking/saas/index.md
+++ b/public/content/translations/fa/staking/saas/index.md
@@ -22,7 +22,7 @@ summaryPoints:
پروتکل اتریوم بهطور بومی از تفویض سهام پشتیبانی نمیکند، بنابراین این سرویسها برای برطرف کردن این تقاضا ساخته شدهاند. اگر 32 اتر برای سهامگذاری در اختیار دارید، اما در مواجهه با سختافزار احساس راحتی نمیکنید، سرویسهای SaaS به شما امکان میدهند تا زمانی که پاداشهای بلوک بومی را دریافت میکنید، بخش سخت را تفویض کنید.
-
+
@@ -39,7 +39,7 @@ summaryPoints:
## ارائهدهندگان خدمات سهامگذاری را مشاهده و بررسی کنید {#saas-providers}
-در زیر برخی از ارائهدهندگان SaaS قید شدهاند. از شاخصهای بالا برای راهنمایی درباره این خدمات استفاده کنید
+در زیر برخی از ارائهدهندگان موجود SaaS قید شدهاند. از شاخصهای بالا برای راهنمایی درباره این خدمات استفاده کنید
@@ -47,7 +47,7 @@ summaryPoints:
-لطفاً از اهمیت انتخاب سرویسی که [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) را جدی بگیرد غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. سرویسهایی که مدارکی از محدود کردن استفاده اکثریت کاربران را دارند با عنوان "تنوع کاربر اجرایی" و "تنوع کاربر اجماعی" نشان داده میشوند.
+لطفاً از اهمیت انتخاب سرویسی که [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) را جدی بگیرد غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. سرویسهایی که شواهدی از محدود کردن استفاده اکثریت کاربران دارند با عنوان "تنوع کاربر اجرایی" و "تنوع کاربر اجماعی" نشان داده میشوند
### تولیدکنندگان کلید
@@ -69,7 +69,7 @@ summaryPoints:
بروزرسانی اطلاعات رمز برداشت، یک اقدام لازم برای فعالسازی امکان برداشت است. این فرایند شامل تولید کلیدهای برداشت با استفاده از عبارت بازیابی شما است.
مطمئن شوید که پشتیبان امنی از این عبارت بازیابی دارید یا در هر زمان ممکن نخواهید توانست کلیدهای برداشت خود را تولید کنید.
-/\*سهامگذارانی که آدرس برداشت را با واریز اولیه تدارک دیدهاند نیازی به تنظیم این مورد ندارند. با ارائه دهنده سرویس SaaS خود برای راهنمایی در مورد نحوه راه اندازی اعتبار سنج خود تماس بگیرید.
+/*سهامگذارانی که آدرس برداشت را با واریز اولیه تدارک دیدهاند نیازی به تنظیم این مورد ندارند. با ارائه دهنده سرویس SaaS خود برای راهنمایی در مورد نحوه راه اندازی اعتبار سنج خود تماس بگیرید.
@@ -81,7 +81,7 @@ summaryPoints:
-با استفاده از یک ارائهدهنده SaaS، عملیات گره خود را به شخص دیگری تفویض میکنید. این کار، خطر عملکرد ضعیف گره را به همراه دارد، که در کنترل شما نیست. در صورتی که اعتبارسنج شما مشمول تقطیع شود، موجودی اعتبارسنج شما جریمه میشود و قاطعانه از استخر اعتبارسنج حذف میشود.
+شما با استفاده از یک ارائهدهنده SaaS عملیات نود خود را به شخص دیگری تفویض میکنید. این کار، خطر عملکرد ضعیف گره را به همراه دارد، که در کنترل شما نیست. در صورتی که اعتبارسنج شما مشمول تقطیع شود، موجودی اعتبارسنج شما جریمه میشود و قاطعانه از استخر اعتبارسنج حذف میشود.
پس از تکمیل فرایند اسلشینگ/خروج، این وجوه به آدرس برداشت اختصاص یافته به اعتبارسنج منتقل خواهند شد. این امر نیاز به ارائه یک آدرس برداشت برای فعالسازی دارد. آدرس برداشت ممکن است در واریز اولیه ارائه شده باشد. اگر آدرس برداشت ارائه نشده بود، لازم است از کلیدهای برداشت اعتبارسنج برای امضای پیام مشخص کننده آدرس برداشت استقاده شود. اگر آدرس برداشت ارائه نشده باشد، وجوه تا زمان ارائه آدرس، غیر قبل برداشت خواهند بود.
@@ -90,4 +90,5 @@ summaryPoints:
## بیشتر بخوانید {#further-reading}
+- [فهرست سهامگذاری اتریوم](https://www.staking.directory/) - _Eridian و Spacesider_
- [ارزیابی سرویسهای سهامگذاری](https://www.attestant.io/posts/evaluating-staking-services/) - _جیم مکدونالد 2020_
diff --git a/public/content/translations/fa/staking/solo/index.md b/public/content/translations/fa/staking/solo/index.md
index ca1b2fde925..fb58f459331 100644
--- a/public/content/translations/fa/staking/solo/index.md
+++ b/public/content/translations/fa/staking/solo/index.md
@@ -195,8 +195,13 @@ Staking Launchpad یک برنامه منبعباز است که به شما ک
## بیشتر بخوانید {#further-reading}
-- [مشکل تنوع کلاینت اتریوم](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
+- [فهرست سهامگذاری اتریوم](https://www.staking.directory/) - _Eridian و Spacesider_
+- [مشکل تنوع کلاینت اتریوم](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
- [کمک به تنوع کلاینتها](https://www.attestant.io/posts/helping-client-diversity/) - _جیم مکدونالد 2022_
-- [ تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_
-- [گامبهگام: نحوهی پیوستن به شبکهی آزمایشی اتریوم 2.0](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) - _بوتا_
-- [نکات پیشگیری از برخورد شدید Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _راول جردن 2020_
+- [ تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_
+- نحوهی خرید سختافزار اعتبارسنج اتریوم - _EthStaker 2022_
+
+ - [گامبهگام: نحوهی پیوستن به شبکهی آزمایشی اتریوم 2.0](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) - _ بوتا_
+- [نکات پیشگیری از برخورد شدید Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _راول جردن 2020 _
+
+
diff --git a/public/content/translations/fa/staking/withdrawals/index.md b/public/content/translations/fa/staking/withdrawals/index.md
index f3d11cbb505..b07c027121f 100644
--- a/public/content/translations/fa/staking/withdrawals/index.md
+++ b/public/content/translations/fa/staking/withdrawals/index.md
@@ -72,7 +72,7 @@ summaryPoints:
اینکه آیا یک اعتبارسنج مشخص واجد شرایط برداشت است یا نه، توسط وضعیت خود حساب اعتبارسنج تعیین میشود. هیچ اطلاعاتی از سوی کاربر در هر زمان معین برای تعیین اینکه آیا یک حساب باید شروع به برداشت کند یا نه لازم نیست - کل فرآیند به طور خودکار توسط لایه اجماع در یک حلقه پیوسته انجام میشود.
-### فردی هستید که با توضیحات تصویری راحتترید؟ {#visual-learner}
+### با توضیحات تصویری راحتترید؟ {#visual-learner}
این توضیحات برداشتهای سهامگذاری اتریوم ارائه شده از سوی Finematics را مرور کنید:
@@ -114,12 +114,12 @@ summaryPoints:
| شمار برداشت ها | زمان تکمیل |
-| :------------: | :--------: |
-| 400,000 | 3.5 روز |
-| 500,000 | 4.3 روز |
-| 600,000 | 5.2 روز |
-| 700,000 | 6.1 روز |
-| 800,000 | 7.0 روز |
+| :-------------------: | :--------------: |
+| 400,000 | 3.5 روز |
+| 500,000 | 4.3 روز |
+| 600,000 | 5.2 روز |
+| 700,000 | 6.1 روز |
+| 800,000 | 7.0 روز |
@@ -194,9 +194,9 @@ eventCategory="FAQ"
eventAction="I operate a validator. Where can I find more information on enabling withdrawals?"
eventName="read more">
-به اپراتورهای اعتبارسنج توصیه میشود از صفحه برداشتهای سکوی پرتاب سهامگذاری بازدید کنند، که در آنجا جزئیات بیشتری درباره نجوه آمادهسازی اعتبارسنج خود برای برداشتها پیدا خواهید کرد. تهیه شده، زمانبندی رویدادها و اطلاعات بیشتر درباره چگونگی کار برداشتها.
+به اپراتورهای اعتبارسنج توصیه میشود که صفحه برداشتهای پلتفرم سهامگذاری را مشاهده کنند، که در آن جزئیات بیشتری در مورد نحوه آمادهسازی اعتبارسنج خود برای برداشت، زمان رویدادها، و جزئیات بیشتر در مورد نحوه عملکرد برداشت ها پیدا خواهند کرد.
-برای امتحان اولیه تنظیمات خود در یک شبکه آزمایشی، به صفحه سکوی پرتاب سهامگذاری شبکه آزمایشی Holesky برای شروع مراجعه کنید.
+برای اینکه ابتدا تنظیمات خود را در یک شبکه تست امتحان کنید، برای شروع به پلتفرم سهامگذاری شبکه تستHolesky مراجعه کنید.
@@ -214,5 +214,5 @@ eventName="read more">
- [پروتکل EIP-4895: برداشتهای زنجیره بیکن بهعنوان عملیاتها](https://eips.ethereum.org/EIPS/eip-4895)
- [تیم ویراستاران اتریوم - شانگهای](https://www.ethereumcatherders.com/shanghai_upgrade/index.html)
- [PEEPanEIP شماره 94: برداشت اتر سهامگذاری شده (آزمایشی) با Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE)
-- [PEEPanEIP شماره 68: پروپوزال EIP-4895: برداشتهای خودکار زنجیره بیکن بهعنوان عملیات با الکس استوکس](https://www.youtube.com/watch?v=CcL9RJBljUs)
+- [PEEPanEIP شماره 68: پیشنهاد شماره 4895: زنجیره بیکن برداشتها را بهعنوان عملیات با Alex Stokes مخابره میکند](https://www.youtube.com/watch?v=CcL9RJBljUs)
- [آشنایی با موجودی مؤثر اعتبارسنج](https://www.attestant.io/posts/understanding-validator-effective-balance/)
diff --git a/public/content/translations/fa/web3/index.md b/public/content/translations/fa/web3/index.md
index cc81640c567..5da8790eb68 100644
--- a/public/content/translations/fa/web3/index.md
+++ b/public/content/translations/fa/web3/index.md
@@ -59,7 +59,7 @@ lang: fa
وب 3 مالکیت داراییهای دیجیتال خود را به روشی بیسابقه به شما میدهد. بهعنوان مثال، فرض کنیم که در حال انجام یک بازی وب 2 هستید. اگر یک آیتم درون بازی خریداری کنید، مستقیماً به حساب شما مرتبط خواهد بود. اگر سازندگان بازی حساب کاربری شما را حذف کنند، این موارد را از دست خواهید داد. یا اگر بازی را متوقف کنید، ارزشی را که روی آیتمهای درون بازی خود سرمایهگذاری کردهاید از دست میدهید.
-وب 3 امکان مالکیت مستقیم را از طریق [توکنهای غیرقابل معاوضه (NFTها)](/nft/) میدهد. هیچکس، حتی سازندگان بازی، قدرت سلب مالکیت شما را ندارند. و اگر بازی را متوقف کنید، میتوانید آیتمهای درون بازی خود را در بازارهای آزاد بفروشید یا معامله کنید و ارزش آنها را بازپس بگیرید.
+Web3 امکان مالکیت مستقیم را از طریق [توکنهای غیرقابل معاوضه (NFTها)](/glossary/#nft) فراهم می کند. هیچکس، حتی سازندگان بازی، قدرت سلب مالکیت شما را ندارند. و اگر بازی را متوقف کنید، میتوانید آیتمهای درون بازی خود را در بازارهای آزاد بفروشید یا معامله کنید و ارزش آنها را بازپس بگیرید.
دربارهی NFTها بیشتر بدانید
@@ -82,7 +82,7 @@ OnlyFans یک سایت محتوای ویژهی بزرگسالان است که
علاوه بر مالکیت دادههای خود در Web3، میتوانید با استفاده از توکنهایی که مانند سهام یک شرکت عمل میکنند، پلتفرم را به عنوان یک گروه در اختیار داشته باشید. DAO به شما امکان می دهد مالکیت غیرمتمرکز یک پلتفرم را هماهنگ کنید و در مورد آینده آن تصمیم بگیرید.
-DAOها از نظر فنی به عنوان قراردادهای هوشمند توافق شده تعریف می شوند که تصمیمگیری غیرمتمرکز را بر روی استخری از منابع (توکن ها) خودکار می کنند. کاربران دارای توکن در مورد نحوه مصرف منابع رای می دهند و کد به طور خودکار نتیجه رایگیری را اجرا میکند.
+DAOها از نظر فنی با عنوان [قراردادهای هوشمند](/glossary/#smart-contract) توافق شده تعریف میشوند که تصمیمگیری غیرمتمرکز را بر روی مجموعهای از منابع (توکنها)، خودکار میکنند. کاربران دارای توکن در مورد نحوه مصرف منابع رای می دهند و کد به طور خودکار نتیجه رایگیری را اجرا میکند.
با این حال، مردم، بسیاری از جوامع Web3 را به عنوان DAO تعریف می کنند. همه این جوامع، سطوح مختلفی از تمرکززدایی و اتوماسیون با کد دارند. در حال حاضر، ما در حال بررسی این هستیم که DAO چیست و چگونه ممکن است در آینده تکامل یابد.
@@ -97,15 +97,11 @@ DAOها از نظر فنی به عنوان قراردادهای هوشمند ت
بهطور سنتی، شما در هر پلتفرمی که استفاده میکنید یک حساب کاربری میسازید. برای مثال، ممکن است یک حساب توییتر، یک حساب یوتیوب و یک حساب ردیت داشته باشید. میخواهید نام نمایشدادهشده یا تصویر نمایه خود را تغییر دهید؟ باید این کار را برای هر حساب انجام دهید. در برخی موارد میتوانید از حسابهای خود در شبکههای اجتماعی برای ورود استفاده کنید، اما این موضوع یک مشکل آشنا را به همراه دارد - سانسور. با یک کلیک، این پلتفرمها میتوانند شما را از کل زندگی آنلاینتان محروم کنند. حتی بدتر از آن، بسیاری از پلتفرمها از شما میخواهند که برای ایجاد یک حساب کاربری به آنها اعتماد کنید و اطلاعات هویتی خود را در اختیارشان قرار دهید.
-Web3 با فراهمسازی امکان کنترل هویت دیجیتال برای شما با آدرس اتریوم و نمایه ENS، این مشکلات را حل میکند. استفاده از یک آدرس اتریوم، یک حساب کاربری واحد برای ورود را در سراسر پلتفرم ها فراهم میکند که امن، مقاوم در برابر سانسور و ناشناس است.
-
-
- با اتریوم وارد شوید
-
+Web3 با اجازه دادن به شما برای کنترل هویت دیجیتال خود از طریق یک آدرس اتریوم و پروفایل [Ethereum Name Service (ENS)](/glossary/#ens) این مشکلات را حل میکند. استفاده از یک آدرس اتریوم، یک حساب کاربری واحد برای ورود را در سراسر پلتفرم ها فراهم میکند که امن، مقاوم در برابر سانسور و ناشناس است.
### پرداختهای بومی {#native-payments}
-زیرساخت پرداخت Web2 به بانکها و پردازشگرهای پرداخت متکی است، به استثنای افرادی که حساب بانکی ندارند یا کسانی که درون مرزهای کشور اشتباهی زندگی میکنند. Web3 از توکنهایی مانند [اتر](/eth/) برای ارسال مستقیم پول در مرورگر استفاده میکند و به شخص ثالث قابلاعتمادی نیاز ندارد.
+زیرساخت پرداخت Web2 به بانکها و پردازشگرهای پرداخت متکی است، به استثنای افرادی که حساب بانکی ندارند یا کسانی که درون مرزهای کشور اشتباهی زندگی میکنند. Web3 از توکنهایی مانند [اتر](/glossary/#ether) برای ارسال مستقیم پول در مرورگر استفاده میکند و به طرف ثالث قابلاعتماد نیاز ندارد.
اطلاعات بیشتر دربارهی اتر
@@ -117,7 +113,7 @@ Web3 با فراهمسازی امکان کنترل هویت دیجیتال ب
### قابلیت دسترسی {#accessibility}
-ویژگیهای مهم Web3، مانند ورود به سیستم با اتریوم، در حال حاضر برای همه بدون هزینه در دسترس است. اما، هزینه نسبی تراکنشها هنوز برای بسیاری گران است. به دلیل کارمزدهای بالای تراکنش، احتمال کمتری وجود دارد که Web3 در کشورهای کمتر ثروتمند و در حال توسعه مورد استفاده قرار گیرد. در اتریوم، این چالشها از طریق پیادهسازی [نقشه راه](/roadmap/) و [راهحلهای مقیاسپذیری لایه 2](/developers/docs/scaling/) حل میشوند. این فناوری آماده است، اما ما به سطوح بالاتری از پذیرش در لایه 2 نیاز داریم تا Web3 را برای همه در دسترس قرار دهیم.
+ویژگیهای مهم Web3، مانند ورود به سیستم با اتریوم، در حال حاضر برای همه بدون هزینه در دسترس است. اما، هزینه نسبی تراکنشها هنوز برای بسیاری گران است. به دلیل کارمزدهای بالای تراکنش، احتمال کمتری وجود دارد که Web3 در کشورهای کمتر ثروتمند و در حال توسعه مورد استفاده قرار گیرد. در اتریوم، این چالشها از طریق پیادهسازی [نقشه راه](/roadmap/) و [راهحلهای مقیاسپذیری لایه 2](/glossary/#layer-2) حل میشوند. این فناوری آماده است، اما ما به سطوح بالاتری از پذیرش در لایه 2 نیاز داریم تا Web3 را برای همه در دسترس قرار دهیم.
### تجربهی کاربری {#user-experience}
diff --git a/public/content/translations/fa/whitepaper/index.md b/public/content/translations/fa/whitepaper/index.md
new file mode 100644
index 00000000000..42e678b2a6f
--- /dev/null
+++ b/public/content/translations/fa/whitepaper/index.md
@@ -0,0 +1,610 @@
+---
+title: برگه سفید اتریوم
+description: مقاله مقدماتی اتریوم که در سال 2013 قبل از راهاندازی آن منتشر شد.
+lang: fa
+sidebarDepth: 2
+hideEditButton: true
+---
+
+# برگه سفید اتریوم {#ethereum-whitepaper}
+
+_این مقاله مقدماتی در ابتدا در سال ۲۰۱۳ توسط ویتالیک بوترین، بنیانگذار [اتریوم](/what-is-ethereum/)، پیش از راهاندازی پروژه در سال ۲۰۱۵ منتشر شد. شایان ذکر است که اتریوم، مانند بسیاری از پروژه های جامعه محور، پروژه های نرم افزاری منبع باز، از زمان نقطه آغازینش تکامل پیدا کرده است._
+
+_با وجود عمری چندین ساله، ما این مقاله را حفظ میکنیم چون میتواند به عنوان مرجعی مفید و نمودی دقیق از اتریوم و چشم اندازش عمل کند. برای اطلاع از آخرین پیشرفتهای اتریوم و اینکه تغییرات در پروتکل چگونه اعمال میشوند، [این راهنما](/learn/) را توصیه میکنیم._
+
+[محققان و دانشگاهیان که به دنبال یک نسخه تاریخی یا متعارف از وایت پیپر [از دسامبر 2014] هستند، باید از این PDF استفاده کنند.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf)
+
+## یک پلتفرم قرارداد هوشمند و برنامهی غیرمتمرکز نسل بعدی {#a-next-generation-smart-contract-and-decentralized-application-platform}
+
+توسعه بیت کوین توسط ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب به عنوان یک تحول اساسی درصنعت پول و رمزارز مورد استقبال قرار گرفته است، اولین نمونه یک دارایی دیجیتال که به طور همزمان نه هیچ پشتوانه یا "[ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" دارد و نه هیچ مرجع عرضه متمرکز یا کنترل کننده. با این حال، یکی از بخشهای - شاید مهم تر - تجربه بیت کوین زیربنای فناوری زنجیره بلوکی آن به عنوان ابزاری برای اجماع توزیع شده است، و توجهات به سرعت در حال شروع به تغییر به این جنبه دیگر بیت کوین است. کاربردهای جایگزین رایج فناوری بلاک چین شامل استفاده از دارایی های دیجیتال درون بلاک چین برای نشان دادن ارزهای سفارشی و ابزارهای مالی ("[سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lBEoW2T ویرایش)")، مالکیت یک دستگاه فیزیکی زیربنایی ("[اموال هوشمند](https://en.bitcoin.it/wiki/Smart_Property)")، داراییهای غیرقابل تعویض مانند نامهای دامنه ("[Namecoin](http://namecoin.org)")، و همچنین برنامههای پیچیدهتر شامل داشتن داراییهای دیجیتال که مستقیماً توسط یک قطعه کد کنترل میشوند. اجرای قوانین دلخواه ("[هوشمند قراردادها](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") یا حتی "
+
+سازمان های مستقل غیرمتمرکز" (DAOs). آنچه اتریوم قصدش را دارد فراهمسازی یک زنجیره بلوکی با یک زبان برنامه نویسی توکار تورینگ-کامل تمام عیار است که بتوان از آن برای ساخت "قرارداد" هایی که میتوانند برای کد کردن توابع انتقال وضعیت دلخواه مورد استفاده قرار بگیرند بهره برد، که به کاربرها اجازه ساخت هر کدام از سیستم های پیشتر ذکر شده را و همچنین بسیاری از انواع دیگری که حتی تصورشان را هم هنوز نکرده ایم میدهد، صرفاً با به نوشته در آوردن منطق آن در چند خط کد.
+
+
+
+## مقدمه ای بر بیت کوین و مفاهیم موجود {#introduction-to-bitcoin-and-existing-concepts}
+
+
+
+### تاریخچه {#history}
+
+مفهوم ارز دیجیتال نامتمرکز و همچنین برنامه های جایگزین مانند ثبت اموال، برای دهه ها وجود داشته است. پروتکلهای پول نقد الکترونیکی ناشناس در دهههای 1980 و 1990، عمدتاً متکی به یک رمزنگاری بدوی به نام کورکننده چاومین، ارزی با درجه بالایی از حریم خصوصی ارائه می شدند، اما پروتکلها عمدتاً به دلیل اتکا به یک واسطه متمرکز نتوانستند مورد توجه قرار گیرند. در سال 1998، [b-money](http://www.weidai.com/bmoney.txt) از Wei Dai نخستین طرحی شد که ایده ساخت پول از طریق حل معما های محاسباتی و نیز اجماع نامتمرکز را معرفی میکرد، اما جزئیات طرح پیرامون اینکه اجماع نامتمرکز در واقع چگونه میتوانست تعبیه شود ناچیز بود. در سال 2005، هال فینی مفهوم [اثبات کار قابل استفاده مجدد](https://nakamotoinstitute.org/finney/rpow/) را معرفی کرد، سیستمی که از ایدههایی از b-money به همراه پازلهای سخت محاسباتی Hashcash آدام بک برای ایجاد مفهومی برای یک ارز دیجیتال بهره میبرد، اما بار دیگر به دلیل تکیه بر محاسبات قابل اعتماد به عنوان یک بکاند، دور از ایدهآل قرار گرفت. در سال 2009، یک ارز غیرمتمرکز برای اولین بار در عمل توسط ساتوشی ناکاموتو پیادهسازی شد، که ترکیبی از اصول اولیه برای مدیریت مالکیت از طریق رمزنگاری کلید عمومی همچنین الگوریتم اجماع برای پیگیری صاحبان سکهها، معروف به "اثبات کار" اجرا شد.
+
+سازوکار پشت اثبات کار پیشرفت شگفت انگیزی بود چون به طور همزمان دو مشکل را حل میکرد. در وهله اول يك الگوريتم اجماع و ساده و موثر را ارائه مي كرد و به گره ها در شبكه اجازه مي دهد كه بصورت جامع و متمركز بر حالت به روز شده دفتر حساب بيتكوين توافق كنند. دوماً، مکانیسمی را برای ورود آزادانه به فرآیند اجماع ارائه داد که مشکل تصمیم گیری برای اینکه چه کسی هم بر اجماع تاثیر بگذارد و هم از حملات sybil جلوگیری کند. این کار را با جایگزین کردن یک مانع رسمی برای مشارکت، مانند الزام به ثبت نام به عنوان یک موجودیت منحصر به فرد در یک لیست خاص، با یک مانع اقتصادی انجام می دهد - وزن یک گره واحد در فرآیند رای گیری اجماع مستقیماً با قدرت محاسباتی که گره به ارمغان می آورد، متناسب است. از آن زمان، یک رویکرد جایگزین به نام _اثبات سهام_ پیشنهاد شده است که وزن یک گره را متناسب با دارایی های ارز آن محاسبه می کند و نه منابع محاسباتی. بحث در مورد مزایای نسبی دو رویکرد خارج از محدوده این مقاله است، اما باید توجه داشت که هر دو رویکرد می توانند به عنوان ستون فقرات یک رمزارز مورد استفاده قرار گیرند.
+
+
+
+### بیت کوین به عنوان یک سیستم انتقال حالت {#bitcoin-as-a-state-transition-system}
+
+![انتقال حالت اتریوم](./ethereum-state-transition.png)
+
+از نقطه نظر فنی، دفتر کل رمزارزهایی مانند بیتکوین را می توان به عنوان یک سیستم انتقال حالت در نظر گرفت، که در آن یک "حالت" متشکل از وضعیت مالکیت تمام بیتکوین های موجود و یک "تابع انتقال حالت" که یک حالت و یک تراکنش را می گیرد و یک حالت جدید را که نتیجه آن است، خروجی می دهد. به عنوان مثال، در یک سیستم بانکی استاندارد، حالت یک صفحهی موجودی است، تراکنش یک درخواست برای انتقال x ریال از آ به ب، و تابع انتقال حالت از حساب آ مقدار x ریال را کسر میکند و به حساب ب مقدار x ریال را میافزاید. اگر حساب آ از پیش کمتر از $X داشته باشد، تابع انتقال حالت یک خطا بازمیگرداند. سرآخر میتوان به شکل استاندارد تعریف کرد:
+
+
+
+```
+APPLY(S,TX) -> S' or ERROR
+```
+
+
+در سیستم بانکی که بالا تعریف شد:
+
+
+
+```js
+APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
+```
+
+
+اما:
+
+
+
+```js
+APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
+```
+
+
+"وضعیت" در بیت کوین مجموعه ای از تمام کوین ها (از لحاظ فنی، "خروجی های تراکنش خرج نشده" یا UTXO) است که ضرب شده اند و هنوز خرج نشده اند، با هر UTXO دارای یک اسم و یک مالک (که با یک آدرس 20 بایتی تعریف می شود. اساسا یک کلید عمومی رمزنگاری است[fn1](#notes)). یک تراکنش شامل یک یا چند ورودی است که هر ورودی حاوی ارجاع به یک UTXO موجود و یک امضای رمزنگاری شده توسط کلید خصوصی مرتبط با آدرس مالک است و یک یا چند خروجی که هر خروجی حاوی یک UTXO جدید است که باید به آن حالت اضافه شود.
+
+تابع انتقال حالت `APPLY(S,TX) -> S'` را می توان تقریباً به صورت زیر تعریف کرد:
+
+
+ -
+ برای هر ورودی در
TX
:
+
+ -
+ اگر UTXOی ارجاعی در
S
نیست، خطا را برگردان.
+
+ -
+ اگر امضای ارائه شده با صاحب UTXO مطابقت ندارد، خطا را برگردان.
+
+
+
+ -
+ اگر مجموع نامهای تمام UTXO ورودی کمتر از مجموع نامهای همه UTXO خروجی باشد، خطا را برگردان.
+
+ -
+
S
را با حذف تمام ورودی UTXO و اضافه شدن تمام خروجی UTXO برگردان.
+
+
+
+نیمهی اول از گام اول مانع از این میشود که فرستندهها کوینهایی که وجود ندارند را خرج کنند، نیمهی دوم از گام اول مانع از این میشود که فرستندهها کوینهای دیگر افراد را خرج نکنند، و گام دوم فرستنده را مجبور میکند که ارزش را حفظ کند. برای این که از این برای پرداخت استفاده کنیم، پروتکل به شکل زیر است. فرض کنید که آلیس میخواهد ۱۱٬۷ BTC را به باب بفرستد. ابتدا آلیس به دنبال یک مجموعه از UTXO از آنهایی که خود مالک آنهاست میگردد که مجموعشان حداقل ۱۱٬۷ BTC شود. واقعبینانه، آلیس نخواهد توانست که دقیقا ۱۱٬۷ BTC را بیابد؛ فرض کنید کمترین میزانی که آلیس میتواند بسازد ۶+۴+۲=۱۲ باشد. در گام بعدی او یک تراکنش با سه ورودی گفتهشده و دو خروجی میسازد. اولین خروجی ۱۱٬۷ BTC به آدرس باب خواهد بود و دومین خروجی مقدار ۰٬۳ BTC باقیمانده به عنوان «پول خرد»، به آدرس خود آلیس است.
+
+
+
+### استخراج {#mining}
+
+![بلوک های اتریوم](./ethereum-blocks.png)
+
+اگر ما به یک سرویس متمرکز قابل اعتماد دسترسی داشتیم، ساخت این سیستم بدیهی بود و میتوانست دقیقا به صورتی که توصیف شد با استفاده از سختافزار سرور متمرکز برای نگهداری حالتها برنامهنویسی شود. هر چند، با بیتکوین ما میخواهیم یک ارز غیرمتمرکز بسازیم، در نتیجه نیاز داریم که سیستم انتقال حالت را با یکی سیستم اجماع بسازیم که همه بر روی ترتیب تراکنشها توافق داشتهباشند. پروسهی اجماع غیرمتمرکز بیتکوین نیاز به گرههایی در شبکه دارد که به طور مرتب پکیجهایی به نام «بلوک» را بسازند. این شبکه قرار است تقریبا هر ۱۰ دقیقه یک بلوک بسازد که در هر بلوک یک برچسب زمان (Timestamp)، یک نانس و یک ارجاع (هش) به بلاک قبلی و لیستی از همهی تراکنشهایی که از بلوک قبلی تا به حال اتفاق افتادهاند، وجود دارد. در طی زمان، این موضوع یک «زنجیرهی بلوکی» پایدار و رشدکننده میسازد که به طور مرتب بروز میشود تا آخرین حالت دفترکل بیتکوین را نمایش دهد.
+
+الگوریتمی که نشان میدهد یک بلوک معتبر است به صورت زیر توضیح داده میشود:
+
+1. بررسی کنید که آیا بلوک قبلی که توسط بلوک به آن ارجاع داده شده وجود دارد و معتبر است یا خیر.
+2. بررسی کنید که مُهر زمانی بلوک بزرگتر از بلوک قبلی باشد[fn2](#notes) و کمتر از 2 ساعت در آینده باشد
+3. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
+4. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
+5. فرض کن `TX` لیست تراکنشهای بلوک با تعداد `n` تراکنش است. برای همه `i` در `0...n-1`، `S[i+1] = APPLY(S[i], TX[i]) را تنظیم کنید /code> اگر هر برنامه ای خطا را برمیگرداند، از آن خارج شوید و false را برگردانید.
+True را برگردانید و S[n]` را به عنوان وضعیت در انتهای این بلوک ثبت کنید.
+
+در واقع هر تراکنش در بلوک باید یک انتقال حالت معتبر را از حالت قبل از انجام تراکنش به حالت جدید انجام دهد. باید توجه کرد که حالت به هیچ صورتی در بلوک ثبت نمیشود؛ این یک موضوع تماما انتزاعی است برای این که توسط گرههای اعتبارسنج به خاطر سپرده شود و تنها میتوان (به صورت ایمن) با شروع از حالت بلوک پیدایش و حرکت بر روی تراکنشهای هر بلوک، حالت بلوک فعلی را به دست آورد. علاوه بر این، توجه کنید که ترتیبی که استخراجگر تراکنشها را در بلوک ثبت میکند مهم است؛ اگر دو تراکنش آ و ب وجود داشته باشند به طوری که ب یک UTXOی ساختهشده از آ را خرج کند، در این صورت بلوک معتبر است اگر آ قبل از ب ثبت شود و نه برعکس.
+
+شرط صحتی که در دیگر سیستمها دیده نمیشود و در لیست بالا به آن اشاره شد، لازمهی «اثبات کار» است. شرط دقیق به این شکل است که هش double-SHA256 هر بلوک، به عنوان یک عدد ۲۵۶ بیتی، باید کمتر از یک هدف به شکل پویا متغیر باشد، که در زمان نوشتن این مقاله ۲۱۸۷ است. هدف از این امر "سخت کردن" ساخت بلوک از لحاظ محاسباتی و در نتیجه باز داشتن مهاجمان sybil از بازسازی کل زنجیره بلوکی به نفع خودشان است. چون SHA256 طراحی شده تا یک تابع کاملا شبه تصادفی غیرقابل پیشبینی باشد، تنها راه ساخت یک بلوک معتبر صرفا آزمون و خطا، اضافه کردن نانس و دیدن این است که آیا هش جدید تطابق میکند یا خیر.
+
+در هدف کنونی \~۲۱۸۷، شبکه باید به طور میانگین اقدام به \~۲۶۹ آزمون پیش از یافتن یک بلوک معتبر بکند; به طور کلی، هدف به ازای هر ۲۰۱۶ بلوک توسط شبکه بازتنظیم میشود به شکلی که به طور میانگین هر ۱۰ دقیقه یک بلوک جدید توسط یک گره در شبکه تولید شود. به منظور جبران کار ماینرها برای این محاسبات ، استخراجگر هر بلوک حق دارد یک تراکنش را شامل شود که به خودشان 12.5 بیت کوین می دهد. بهعلاوه، اگر هر تراکنشی در ورودیهای خود ارزش کل بالاتری نسبت به خروجیهای خود داشته باشد، تفاوت نیز به عنوان «کارمزد تراکنش» به ماینر میرسد. اتفاقاً این تنها مکانیزمی است که توسط آن BTC صادر می شود. در اول ایجاد این شبکه هیچ سکه ای وجود نداشت.
+
+برای درک بهتر هدف استخراج، اجازه دهید بررسی کنیم که در صورت بروز یک هجوم مخرب چه اتفاقی می افتد. از آنجایی که رمزنگاری زیربنایی بیت کوین امن است، مهاجم قسمتی از سیستم بیت کوین را که مستقیماً توسط رمزنگاری محافظت نمی شود، هدف قرار می دهد: ترتیب تراکنش ها. استراتژی مهاجم ساده است:
+
+1. تعداد 100 بیتکوین را به یک صرافی در ازای مقداری محصول بفرستید (ترجیحاً کالای دیجیتالی با تحویل سریع)
+2. منتظر تحویل محصول میماند
+3. یک تراکنش دیگر ایجاد کرده و همان 100 بیت کوین را برای خودش ارسال میکند
+4. سعی کنید شبکه را متقاعد کنید که تراکنش او با خودش اولین معامله بوده است.
+
+هنگامی که مرحله (1) انجام شد، پس از چند دقیقه برخی از ماینرها تراکنش را در یک بلوک، مثلاً بلوک شماره 270000، وارد می کنند. بعد از حدود یک ساعت، پنج بلوک دیگر به زنجیره پس از آن بلوک، اضافه میشود که هر کدام از این بلوک ها به طور غیر مستقیم به تراکنش اشاره کرده و بنابراین آن را تایید میکنند. در این نقطه، تاجر پرداخت را نهایی تلقی میکند و محصول را تحویل میدهد. همچنان که فرض کردیم این کالا دیجیتال است و تحویل آن فوری است. حال مهاجم تراکنش دیگری را ایجاد میکند و 100 بیت کوین را به خودش ارسال میکند. اگر مهاجم به سادگی آن را رها کند، تراکنش پردازش نخواهد شد. استخراج کنندگان تلاش میکنند که `APPLY(S, TX)` را اعمال کنند و متوجه میشوند که `TX` یک UTXO را مصرف میکند که دیگر در آن حالت نیست. بنابراین در عوض آن، مهاجم یک انشعاب (فورک) از زنجیره بلوکی را ایجاد میکند که با استخراج نسخه دیگری از بلوک 270 شروع میشود که به همان بلوک 269، به عنوان بلوک مادر اشاره میکند، اما با معرفی تراکنش جدید در جای تراکنش قدیمی. از آنجا که داده های بلوک متفاوت است، این مستلزم انجام مجدد اثبات کار است. علاوه بر این، نسخه جدید بلوک 270 مهاجم دارای هش متفاوتی است، بنابراین بلوک های اصلی 271 تا 275 به آن اشاره نمی کنند. بنابراین، زنجیره اصلی و زنجیره جدید مهاجم کاملاً جدا هستند. قانون این است که در یک فورک طولانیترین زنجیره بلوکی حقیقی در نظر گرفته میشود، و بنابراین ماینرهای قانونی روی زنجیره ۲۷۵ کار میکنند در حالی که مهاجم به تنهایی روی زنجیره ۲۷۰ کار میکند. برای اینکه مهاجم بتواند زنجیره بلوکی خود را تبدیل به طولانیترین رنجیره کند، باید قدرت محاسباتی بیشتری نسبت به مجموع سایر شبکهها داشته باشد تا بتواند به آنها برسد (یعنی، "حمله 51٪").
+
+
+
+### درختان Merkle {#merkle-trees}
+
+![SPV در بیتکوین](./spv-bitcoin.png)
+
+_طرف چپ: کافی است که فقط تعداد کمی از گره ها را در یک درخت Merkle ارائه داد تا اثبات اعتبار شاخه ایجاد شود._
+
+_طرف راست: هر تلاشی برای تغییر هر بخشی از درخت Merkle سرانجام منجر به عدم سازگاری در جایی در بالای زنجیره میشود._
+
+یک ویژگی مقیاس پذیری مهم بیت کوین این است که بلوک مورد نظر در یک ساختار دادهی چند لایه ذخیره میشود. هش یک بلوک در واقع تنها هش بلوک اصلی است، تقریبا 200 بایت اطالعات شامل ثبت زمان، نانس، هش بلوک قبلی و هش ریشه ساختار داده که درخت Merkle نامیده میشود و همه تراکنش ها را در بلوک ذخیره میکند. درخت Merkle نوعی درخت باینری است که متشکل از مجموعه ای گره است که همراه با تعداد زیادی گره برگی در پایین درخت میباشد که شامل داده های زیربنایی میشوند. یک مجموعه از گره های میانجی هم هستند که هر کدام از آنها هش دو بچه خود میباشند و بخش بالایی درخت را ارائه میدهند. مقصود از درخت Merkle، مجوز دادن به داده های یک بلوک برای تحویل تدریجی است. یک گره از یک منبع، فقط هدر (header) بلوک را دانلود میکند. بخش کوچک درخت از طریق منبع دیگری به آنها مربوط میشود و با این وجود اطمینان حاصل میشود که همه داده ها صحیح هستند. دلیل این کار این است که هش ها به سمت بالا منتشر می شوند: اگر یک کاربر بداندیش تلاش کند که در یک تراکنش جعلی به پایین درخت Merkle تغییر وضعیت دهد، این تغییر منجر به تغییر در گره بالا میشود و سپس تغییر در گره بالاتر آن و سرانجام ریشه درخت را تغییر میدهد و بنابراین هش بلوک، سبب میشود که پروتکل آن را به عنوان یک بلوک کامل متفاوت ثبت کند (با احتمال قریب به یقین به عنوان یک اثبات کار غیر معتبر).
+
+پروتکل درخت Merkle به طور قابل دفاعی در ماندگاری دراز مدت نقش اساسی دارد. یک گره کامل در شبکه بیت کوین، گره ای است که کلیت یک بلوک را ذخیره و پردازش میکند و حدود 15 گیگابایت از فضای دیسک شبکه بیت کوین را در آپریل 2014 اشغال میکرد و هر ماه حدود یک گیگابایت به این مقدار اضافه میشد. در حال حاضر، این برای برخی از رایانههای دسکتاپ و نه تلفنها قابل اجرا است و بعداً در آینده فقط مشاغل و علاقهمندان میتوانند در آن شرکت کنند. پروتکلی به نام "تأیید پرداخت ساده" (SPV) اجازه می دهد تا کلاس دیگری از گره ها به نام "گره های سبک" وجود داشته باشد که هدرهای بلوک را دانلود می کنند، اثبات کار روی هدرهای بلوک را تأیید می کنند و سپس فقط "شاخه ها"ی مرتبط با تراکنش هایی که به آنها مربوط است را دانلود می کنند. این به گرههای سبک اجازه میدهد تا با ضمانت امنیتی قوی، وضعیت هر تراکنش بیتکوین و موجودی فعلی آنها را تعیین کنند، در حالی که تنها بخش بسیار کوچکی از کل زنجیره بلوکی را دانلود میکنند.
+
+
+
+### کاربردهای جایگزین زنجیره بلوکی {#alternative-blockchain-applications}
+
+ایده گرفتن ایده اصلی زنجیره بلوکی و اعمال آن در مفاهیم دیگر نیز سابقه طولانی دارد. در سال 2005، نیک زابو به مفهوم [عناوین ملکی ایمن با اختیار مالک](https://nakamotoinstitute.org/secure-property-titles/)، سندی که چگونگی "پیشرفت های جدید در فناوری پایگاه داده تکراری" را توضیح می دهد اشاره کرد. یک سیستم مبتنی بر بلاکچین برای ذخیره یک رجیستری از اینکه چه کسی امکانپذیر است که مالک چه زمینی است و یک چارچوب مفصل از جمله مفاهیمی از این قبیل ایجاد می کند به عنوان خانه داری، مالکیت نامناسب و مالیات زمین میلادی ایجاد می کند. با این حال، متأسفانه هیچ سیستم پایگاه داده تکثیر شده مؤثری در آن زمان موجود نبود، و بنابراین این پروتکل هرگز در عمل اجرا نشد. با این حال، پس از سال 2009، هنگامی که اجماع غیرمتمرکز بیت کوین توسعه یافت، تعدادی از برنامه های کاربردی جایگزین به سرعت شروع به ظهور کردند.
+
+- **Namecoin** - ایجاد شده در سال 2010، [Namecoin](https://namecoin.org/) به بهترین وجه به عنوان یک پایگاه داده ثبت نام غیرمتمرکز توصیف می شود. در پروتکل های غیرمتمرکز مانند Tor، Bitcoin و BitMessage، باید راهی برای شناسایی حساب ها وجود داشته باشد تا افراد دیگر بتوانند با آنها تعامل داشته باشند، اما در همه راه حل های موجود، تنها نوع شناسه موجود یک هش شبه تصادفی مانند `1LW79wp5ZBqaHW1jL5TCiBCrhWQYHagUt` است. در حالت ایده آل، شخصی ممکن است دوست داشته باشد که بتواند یک حساب کاربری با نامی مانند "جورج" داشته باشد. با این حال، مشکل این است که اگر یک نفر بتواند یک حساب کاربری به نام "جورج" ایجاد کند، شخص دیگری نیز می تواند از همین فرآیند برای ثبت "جورج" برای خود و جعل هویت آنها استفاده کند. تنها راه حل یک پارادایم اول به فایل است که در آن ثبت کننده اول موفق می شود و دومی شکست می خورد - مشکلی که کاملاً برای پروتکل اجماع بیتکوین متناسب است. Namecoin قدیمی ترین و موفق ترین مدل پیاده سازی شده سیستم ثبت نام با استفاده از چنین ایده ای است.
+- **سکه های رنگی** - هدف [سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) این است که به عنوان پروتکلی عمل کند تا به مردم اجازه دهد رمزارزهای خود را ایجاد کنند - یا در مورد مهم پیش پا افتاده ارز با یک واحد، توکن های دیجیتال، در بلاکچین بیت کوین. در پروتکل کوینهای رنگی، یک ارز جدید با اختصاص دادن یک رنگ به یک بیت کوین UTXO خاص به صورت عمومی یک ارز جدید صادر میکند و پروتکل به صورت بازگشتی رنگ سایر UTXOها را با رنگ ورودیهایی که تراکنش ایجاد میکند، مشخص میکند. (برخی قوانین خاص در مورد ورودیهای رنگی مخلوط اعمال میشود). این مورد به کاربران اجازه میدهد تا کیف پولهایی را که فقط حاوی UTXO با یک رنگ خاص هستند نگهداری کنند و آنها را مانند بیتکوینهای معمولی به اطراف بفرستند و از طریق بلاکچین به عقب برگردند تا رنگ هر UTXO دریافتی را تعیین کنند.
+- **Metacoins** - ایده پشت متاکوین داشتن پروتکلی است که بر روی بستر بیتکوین زندگی می کند، از تراکنش های بیتکوین برای ذخیره تراکنش های متاکوین استفاده می کند، اما دارای یک تابع انتقال حالت متفاوت یعنی `APPLY'` است،. از آنجایی که پروتکل متاکوین نمی تواند از نمایش تراکنش های متاکوین نامعتبر در بلاکچین بیتکوین جلوگیری کند، قانونی اضافه می شود که اگر `APPLY'(S,TX)` خطایی را برگرداند، پروتکل به طور پیش فرض به `APPLY'( S,TX) = S` بر می گردد. این مورد یک مکانیسم آسان برای ایجاد یک پروتکل ارز دیجیتال دلخواه، با ویژگیهای پیشرفته است که نمیتواند در داخل بیتکوین با هزینه توسعه بسیار پایین پیادهسازی شود، زیرا پیچیدگیهای استخراج و شبکهسازی قبلاً توسط پروتکل بیتکوین مدیریت میشود. متاکوینها برای اجرای برخی از کلاسهای قراردادهای مالی، ثبت نام و مبادلات غیرمتمرکز استفاده شدهاند.
+
+بنابراین، به طور کلی، دو رویکرد برای ایجاد یک پروتکل اجماع وجود دارد: ایجاد یک شبکه مستقل، و ساخت یک پروتکل در بالای بیت کوین. رویکرد قبلی، اگرچه در مورد برنامههایی مانند Namecoin به طور معقولی موفق بود، اما پیادهسازی آن دشوار است. هر پیادهسازی جداگانه نیاز به راهاندازی یک زنجیره بلوکی مستقل و همچنین ساخت و آزمایش تمام انتقال وضعیت و کد شبکه دارد. علاوه بر این، ما پیشبینی میکنیم که مجموعه برنامههای کاربردی برای فناوری اجماع غیرمتمرکز از یک توزیع قانون قدرت پیروی میکنند که در آن اکثریت قریب به اتفاق برنامهها برای تضمین زنجیره بلوکی خود بسیار کوچک هستند، و توجه داریم که کلاسهای بزرگی از برنامههای غیرمتمرکز، بهویژه مستقل غیرمتمرکز وجود دارد، سازمان هایی که نیاز به تعامل با یکدیگر دارند.
+
+از سوی دیگر، رویکرد مبتنی بر بیتکوین دارای این نقص است که ویژگیهای تأیید پرداخت ساده بیتکوین را به ارث نمیبرد. SPV برای بیت کوین کار می کند زیرا می تواند از عمق بلاک چین به عنوان یک پروکسی برای اعتبار استفاده کند. زمانی که پیشینههای یک تراکنش به اندازه کافی به عقب بروند، می توان با اطمینان گفت که آنها به طور قانونی بخشی از وضعیت بودند. از سوی دیگر، فراپروتکلهای مبتنی بر زنجیرهی بلوکی نمیتوانند زنجیرهی بلوکی را مجبور کنند که تراکنشهایی را که در چارچوب پروتکلهای خود معتبر نیستند، در بر نگیرد. از این رو، اجرای فراپروتکل SPV کاملاً ایمن باید تا ابتدای زنجیرهی بلوکی بیت کوین را به عقب اسکن کند تا مشخص شود که آیا تراکنش های خاصی معتبر هستند یا خیر. در حال حاضر، تمام پیادهسازیهای «سبک» فراپروتکلهای مبتنی بر بیتکوین برای ارائهی دادهها به یک سرور قابل اعتماد متکی هستند، که مسلماً نتیجهای بسیار نابهینه است، بهویژه زمانی که یکی از اهداف اصلی یک ارز دیجیتال حذف نیاز به اعتماد باشد.
+
+
+
+### اسکریپت نویسی {#scripting}
+
+درواقع پروتکل بیت کوین حتی بدون هیچ گونه افزونهای، نسخه ضعیفی از قرارداد های هوشمند را تسهیل میکند. UTXO در بیت کوین فقط با یک کلید عمومی مالکیت پیدا نمیکند، بلکه همچنین اسکریپت پیچیده تری در زبان برنامه نویسی بر پایهی پشتهی ساده ابراز میشود. در این الگو، تراکنشی که آن UTXO را خرج میکند، باید داده هایی را فراهم کند که اسکریپت را قانع کند. در واقع حتی مکانیزم مالکیت کلید عمومی اصلی، از طریق یک اسکریپت پیاده میشود. این اسکریپت یک امضای منحنی بیضوی را به عنوان ورودی اعمال میکند که آن را در برابر تراکنش و آدرسی که مالک UTXO است، تایید میکند و اگر تایید موفق باشد، 1 و در غیر این صورت 0 ارجاع داده میشود. اسکریپت های پیچیدهتر دیگری برای موارد استفاده اضافی متعددی موجود هستند. به عنوان مثال فرد میتواند اسکریپتی بسازد که نیازمند امضاهایی شامل دو از سه کلید خصوصی باشد تا اعتبارسنجی انجام شود. (multisig) این چیدمان برای اکانت های سازمانی، اکانت های پس انداز ایمن و موقعیت های شخص ثالث بازرگان، مفید است. اسکریپت ها همچنین میتوانند برای پرداخت جایزه هایی که برای راه حل های محاسباتی داده میشوند، استفاده شوند و فرد میتواند حتی اسکریپتی بسازد که چیزی مانند این که UTXO بیت کوین متعلق به چه کسی است، نشان داده شود. اگر بتوان یک مدرک SPV فراهم کرد که فرد یک تراکنش دوجکوین را فرستاده است، در اساس این امر مجوز یک تراکنش متقابل غیر متمرکز رمزارز را میدهد.
+
+اما زبان اسکریپت، آنچنان که در بیت کوین پیاده شده، محدودیت های مهمی هم دارد:
+
+- **عدم کامل بودن تورینگ** - یعنی در حالی که زیرمجموعه بزرگی از محاسبات وجود دارد که زبان برنامه نویسی بیتکوین از آن پشتیبانی می کند، تقریباً همه چیز را پشتیبانی نمی کند. دسته اصلی که گم شده است حلقه ها هستند. این کار برای جلوگیری از حلقه های بی نهایت در حین تأیید تراکنش انجام می شود. از نظر تئوری، این یک مانع قابل عبور برای برنامه نویسان اسکریپت است، زیرا هر حلقه را می توان با تکرار چندین بار کد اصلی با یک دستور if شبیه سازی کرد، اما منجر به اسکریپت هایی می شود که بسیار کم فضا هستند. به عنوان مثال، اجرای یک الگوریتم امضای منحنی بیضوی جایگزین احتمالاً به 256 دور ضرب مکرر نیاز دارد که همه به صورت جداگانه در کد گنجانده شده است.
+- **کوری مقدار** - هیچ راهی برای اسکریپت UTXO وجود ندارد که بتواند کنترل دقیقی بر مقدار قابل برداشت ارائه دهد. به عنوان مثال، یکی از موارد استفاده قدرتمند از یک قرارداد اوراکل، قرارداد پوشش ریسک است، که در آن A و B مقدار 1000 دلار بیتوین وارد می کنند و پس از 30 روز، اسکریپت 1000 دلار بیتکوین را به A و بقیه را به B ارسال می کند. اوراکل برای تعیین ارزش 1 بیتکوین به دلار آمریکا، اما حتی در آن زمان نیز از نظر اعتماد و نیاز به زیرساخت نسبت به راه حل های کاملاً متمرکزی که در حال حاضر در دسترس هستند، یک پیشرفت عظیم است. با این حال، از آنجایی که UTXO همه یا هیچ هستند، تنها راه برای دستیابی به این هدف از طریق هک بسیار ناکارآمد داشتن تعداد زیادی UTXO با ارزشهای مختلف است (مثلاً یک UTXO از 2k برای هر k تا 30) و اوراکل انتخاب کنید که کدام UTXO به A و کدام به B ارسال شود.
+- **عدم وضعیت** - UTXO می تواند خرج شود یا خرج نشده باشد. هیچ فرصتی برای قراردادها یا قراردادهای چند امضایی وجود ندارد که هر حالت داخلی دیگری را فراتر از آن حفظ کند. این امر بستن قراردادهای گزینههای چند مرحلهای، پیشنهادها مبادله غیرمتمرکز یا پروتکلهای تعهد رمزنگاری دو مرحلهای (ضروری برای پاداشهای محاسباتی ایمن) را دشوار میکند. همچنین به این معنی است که UTXO فقط میتواند برای ایجاد قراردادهای ساده و یکبار استفاده شود و نه قراردادهای پیچیدهتر مانند سازمانهای غیرمتمرکز، و اجرای فراپروتکلها را دشوار میکند. حالت دودویی همراه با ارزش کوری همچنین به این معنی است که یک برنامه مهم دیگر، محدودیتهای برداشت، غیرممکن است.
+- **کوری بلاکچین** - UTXO نسبت به داده هایبلاک چین مانند نانس، مهر زمانی و هش بلوک قبلی کور است. این امر با محروم کردن زبان برنامهنویسی از منبع بالقوه با ارزش تصادفی، برنامههای کاربردی در قمار و چندین دسته دیگر را به شدت محدود میکند.
+
+بنابراین، ما سه رویکرد برای ایجاد برنامه های کاربردی پیشرفته در بالای آن می بینیم ارز دیجیتال: ساخت یک بلاکچین جدید، استفاده از اسکریپت در بالای بیت کوین و ساخت یک فرا پروتکل در بالای بیت کوین. ساخت یک زنجیرهی بلوکی جدید آزادی نامحدودی را در ساخت مجموعه ویژگیها امکانپذیر میکند، اما به قیمت زمان توسعه، تلاش و امنیت راهاندازی. استفاده از اسکریپت برای پیادهسازی و استانداردسازی آسان است، اما در قابلیت های آن بسیار محدود است و فرا پروتکل ها، در عین سادگی، از اشکالاتی در مقیاس پذیری رنج می برند. با اتریوم، ما قصد داریم یک چارچوب جایگزین بسازیم که دستاوردهای بزرگتری را در سهولت توسعه و همچنین ویژگیهای کلاینت سبک حتی قویتر فراهم میکند و در عین حال به برنامهها اجازه میدهد محیط اقتصادی و امنیت زنجیرهی بلوکی را به اشتراک بگذارند.
+
+
+
+## اتریوم {#ethereum}
+
+هدف اتریوم ایجاد یک پروتکل جایگزین برای ساخت برنامههای غیرمتمرکز است که مجموعهای متفاوت از معاوضهها را ارائه میکند که معتقدیم برای کلاس بزرگی از برنامههای غیرمتمرکز بسیار مفید خواهد بود، با تاکید ویژه بر موقعیتهایی که زمان توسعه سریع، امنیت برای کوچک و برنامههایی که به ندرت استفاده میشوند و توانایی برنامههای مختلف برای تعامل بسیار کارآمد، مهم هستند. اتریوم این کار را با ساختن لایه اساسی انتزاعی نهایی انجام می دهد: یک بلاک چین با زبان برنامه نویسی داخلی کامل تورینگ، که به هر کسی اجازه می دهد قراردادهای هوشمند و برنامه های غیرمتمرکز بنویسد که در آن می توانند قوانین دلخواه خود را برای مالکیت، فرمت های تراکنش و توابع انتقال حالت ایجاد کنند. توابع انتقال حالت یک نسخه بدون استخوان Namecoin را می توان در دو خط کد نوشت و سایر پروتکل ها مانند ارزها و سیستم های شهرت را می توان در کمتر از بیست خط ایجاد کرد. قراردادهای هوشمند، "جعبه های" رمزنگاری که حاوی مقدار باشد و فقط در صورت رعایت شرایط خاص، می تواند قفل آن را باز کند در بالای پلت فرم ساخته شود، با قدرت بسیار بیشتر از آن ارائه شده توسط اسکریپت بیت کوین به دلیل قدرت های اضافه شده تورینگ-کامل بودن، آگاهی از ارزش، آگاهی از بلاک چین و وضعیت.
+
+
+
+### حساب های اتریوم {#ethereum-accounts}
+
+در اتریوم، حالت از اشیایی به نام «حسابها» تشکیل میشود که هر حساب دارای یک آدرس 20 بایتی است و انتقال حالت، انتقال مستقیم ارزش و اطلاعات بین حسابها است. یک حساب اتریوم شامل چهار فیلد است:
+
+- **نانس**، یک شمارنده برای اطمینان از اینکه هر تراکنش فقط یک بار قابل پردازش است استفاده می شود
+- میزان اتریوم فعلی موجود در کیف پول
+- **کد قرارداد** کیف پول، در صورت موجود بودن
+- **فضای ذخیرهسازی** حساب (به طور پیش فرض خالی است)
+
+"اتر" اصلی ترین سوخت رمزارزی داخلی اتریوم است و برای پرداخت هزینه تراکنش استفاده می شود. به طور کلی، دو نوع حساب وجود دارد: **حسابهای متعلق به خارجی** که توسط کلیدهای خصوصی کنترل میشوند، و **حسابهای قرارداد** که توسط کد قرارداد آنها کنترل میشود. یک حساب دارای مالکیت خارجی هیچ کدی ندارد و می توان با ایجاد و امضای یک تراکنش، از یک حساب دارای مالکیت خارجی پیام ارسال کرد. در یک حساب قراردادی، هر بار که حساب قرارداد پیامی دریافت میکند، کد آن فعال میشود و به آن اجازه میدهد در حافظه داخلی بخواند و بنویسد و پیامهای دیگری ارسال کند یا به نوبه خود قرارداد ایجاد کند.
+
+توجه داشته باشید که "قراردادها" در اتریوم نباید به عنوان چیزی که باید "پر شده" یا "منطبق با" تلقی شود. در عوض، آنها بیشتر شبیه «عاملهای مستقل» هستند که در محیط اجرای اتریوم زندگی میکنند، همیشه یک قطعه کد خاص را هنگام «صدا زدن» توسط یک پیام یا تراکنش اجرا میکنند و کنترل مستقیم بر تعادل اتر خود و ذخیره کلید/مقدار خود برای پیگیری متغیرهای پایدار دارند.
+
+
+
+### پیغام ها و تراکنش ها {#messages-and-transactions}
+
+واژه "تراکنش" در اتریوم برای اشاره به بسته داده امضا شده ای استفاده می شود که پیغامی را ذخیره می کند تا از یک حساب مالکیت خارجی ارسال شود. معاملات شامل:
+
+- گیرنده پیام
+- امضایی برای شناسایی فرستنده
+- مقدار اتر برای انتقال از فرستنده به گیرنده
+- یک فیلد داده اختیاری
+- یک مقدار `STARTGAS`، نشان دهنده حداکثر تعداد مراحل محاسباتی است که اجرای تراکنش مجاز به انجام آن است
+- مقدار `GASPRICE`، نشان دهنده هزینه ای است که فرستنده در هر مرحله محاسباتی می پردازد
+
+سه مورد اول، فیلدهای استاندارد مورد انتظار در هر ارز دیجیتال هستند. فیلد داده به طور پیش فرض عملکردی ندارد، اما ماشین مجازی دارای یک کد عملیاتی است که با استفاده از آن قرارداد می تواند به داده ها دسترسی داشته باشد. به عنوان مثال، اگر قراردادی به عنوان یک سرویس ثبت دامنه روی بلاکچین عمل می کند، ممکن است بخواهد داده های ارسال شده به آن را به عنوان حاوی دو "فیلد" تفسیر کند. فیلد اول دامنه ای برای ثبت نام و فیلد دوم آدرس IP برای ثبت آن است. قرارداد این مقادیر را از داده های پیام خوانده و به طور مناسب آنها را در فضای ذخیرهسازی قرار می دهد.
+
+فیلدهای `STARTGAS` و `GASPRICE` برای مدل ضد انکار خدمات اتریوم بسیار مهم هستند. به منظور جلوگیری از حلقههای نامحدود تصادفی یا متخاصم یا سایر اتلافهای محاسباتی در کد، هر تراکنش باید محدودیتی برای تعداد مراحل محاسباتی اجرای کد تعیین کند. واحد اساسی محاسبات "گس" است. معمولاً، یک مرحله محاسباتی 1 گس هزینه دارد، اما برخی از عملیات ها به دلیل اینکه از نظر محاسباتی گرانتر هستند یا مقدار داده هایی را که باید به عنوان بخشی از حالت ذخیره شوند افزایش می دهند، مقدار گس بیشتری را هزینه می کنند. همچنین برای هر بایت در داده های تراکنش 5 گس کارمزد دریافت می شود. هدف سیستم کارمزد این است که از مهاجم بخواهد به ازای هر منبعی که مصرف میکند، از جمله محاسبات، پهنای باند و ذخیرهسازی، به نسبت هزینه پرداخت کند. از این رو، هر تراکنشی که منجر به مصرف شبکه مقدار بیشتری از هر یک از این منابع شود، باید هزینه گس تقریباً متناسب با افزایش داشته باشد.
+
+
+
+### پیامها {#messages}
+
+قراردادها قابلیت ارسال «پیام» به سایر قراردادها را دارند. پیام ها اشیای مجازی هستند که هرگز سریالی نمی شوند و فقط در محیط اجرای اتریوم وجود دارند. یک پیام شامل موارد زیر است:
+
+- فرستنده پیام (ضمنی)
+- گیرنده پیام
+- مقدار اتر برای انتقال در کنار پیام
+- یک فیلد داده اختیاری
+- یک مقدار `STARTGAS`
+
+اساساً یک پیام مانند یک معامله است، با این تفاوت که توسط یک قرارداد تولید می شود نه یک عامل خارجی. یک پیام زمانی تولید می شود که قراردادی که در حال حاضر کد را اجرا می کند، اپکد `CALL` را اجرا می کند، که پیامی را تولید و اجرا می کند. مانند یک تراکنش، یک پیام به حساب گیرنده منتهی می شود که کد آن را اجرا می کند. بنابراین، قراردادها می توانند دقیقاً به همان شکلی که بازیگران خارجی می توانند با سایر قراردادها رابطه داشته باشند.
+
+توجه داشته باشید که کمک هزینه گس تعیین شده توسط یک معامله یا قرارداد برای کل گس مصرف شده توسط آن معامله و کلیه اجراهای فرعی اعمال می شود. به عنوان مثال، اگر یک بازیگر خارجی A یک تراکنش را با 1000 گس به B ارسال کند، و B قبل از ارسال پیام به C، مقدار 600 گس مصرف کند، و اجرای داخلی C قبل از بازگشت، 300 گس مصرف کند، B می تواند قبل از تمام شدن گس 100 گس دیگر خرج کند.
+
+
+
+### تابع انتقال حالت اتریوم {#ethereum-state-transition-function}
+
+![انتقال حالت اتر](./ether-state-transition.png)
+
+تابع انتقال حالت اتریوم، `APPLY(S,TX) -> S'` را می توان به صورت زیر تعریف کرد:
+
+1. بررسی کنید که آیا تراکنش به خوبی شکل گرفته است (یعنی تعداد مقادیر مناسبی دارد)، امضا معتبر است، و نانس با نانس در حساب فرستنده مطابقت دارد. اگر اینطور نیست، یک خطا بازگردان.
+2. کارمزد تراکنش را به صورت `STARTGAS * GASPRICE` محاسبه کنید و آدرس ارسال را از روی امضا تعیین کنید. کارمزد را از موجودی حساب فرستنده کم کنید و نانس فرستنده را افزایش دهید. اگر موجودی کافی برای خرج کردن وجود ندارد، یک خطا را برگردان.
+3. `GAS = STARTGAS` را راهاندازی کنید و مقدار مشخصی گس را در هر بایت بردارید تا هزینه بایتهای موجود در تراکنش را بپردازید.
+4. انتقال ارزش تراکنش از حساب فرستنده به حساب دریافت کننده. اگر حساب دریافت کننده هنوز وجود ندارد، آن را ایجاد کنید. اگر اکانت دریافت کننده قراردادی است، کد قرارداد را تا پایان یا تا زمانی که گس موجود است اجرا کن.
+5. اگر انتقال ارزش به دلیل نداشتن پول کافی فرستنده انجام نشد، یا بنزین اجرای کد تمام شد، همه تغییرات حالت به جز پرداخت هزینه ها را برگردان و هزینه ها را به حساب ماینر اضافه کن.
+6. در غیر این صورت، هزینه تمام گس باقیمانده را به فرستنده بازپرداخت کن و هزینه های پرداخت شده برای گس مصرف شده را برای ماینر ارسال کن.
+
+به عنوان مثال، فرض کنید که کد قرارداد این است:
+
+
+
+```py
+if !self.storage[calldataload(0)]:
+ self.storage[calldataload(0)] = calldataload(32)
+```
+
+
+توجه داشته باشید که در واقع کد قرارداد در کد EVM سطح پایین نوشته شده است. این مثال برای وضوح در Serpent، یکی از زبان های سطح بالای ما، نوشته شده است و می توان آن را به کد EVM کامپایل کرد. فرض کنید ذخیرهسازی قرارداد خالی شروع میشود و تراکنشی با 10 مقدار اتر، 2000 گس، 0.001 اتر قیمت گس و 64 بایت داده ارسال میشود، با بایتهای 0-31 نشان دهنده عدد `2` و بایت است. 32-63 نشان دهنده رشته `CHARLIE` است. فرآیند تابع انتقال حالت در این مورد به شرح زیر است:
+
+1. بررسی کنید که تراکنش معتبر و به خوبی شکل گرفته است.
+2. بررسی کنید که فرستنده تراکنش حداقل 2000 \* 0.001 = 2 اتر داشته باشد. اگر اینطور است، 2 اتر از حساب فرستنده کم کنید.
+3. گس اولیه = 2000; با فرض اینکه تراکنش 170 بایت و هزینه بایت 5 باشد، 850 را کم کنید تا 1150 گس باقی بماند.
+4. مقدار 10 اتر دیگر از حساب فرستنده کم کنید و آن را به حساب قرارداد اضافه کنید.
+5. کد را اجرا کنید. `GAS = STARTGAS` را راهاندازی کنید و مقدار مشخصی از گس را در هر بایت برداشت تا هزینه بایتهای موجود در تراکنش را بپردازید. فرض کنید این 187 گس می گیرد، بنابراین مقدار گس باقیمانده 1150 - 187 = 963 است
+6. 963 \* 0.001 = 0.963 اتر را دوباره به حساب فرستنده اضافه کنید و حالت حاصل را برگردانید.
+
+اگر قراردادی در پایان تراکنش وجود نداشت، کل کارمزد تراکنش به سادگی برابر با `GASPRICE` ارائه شده ضرب در طول تراکنش بر حسب بایت و داده های ارسال شده در کنار تراکنش بی ربط خواهد بود.
+
+توجه داشته باشید که پیامها از نظر بازگردانیها مانند تراکنشها کار میکنند: اگر گس اجرای پیام تمام شود، اجرای آن پیام و همه اجرایهای دیگر که توسط آن اجرا آغاز میشوند، برمیگردند، اما اجرای والد نیازی به برگرداندن ندارد. این بدان معناست که برای قراردادی "ایمن" است که قرارداد دیگری را فراخوانی کند، زیرا اگر A با گس G برود B را صدا کند، اجرای A تضمین شده است که حداکثر گس G را از دست می دهد. در نهایت، توجه داشته باشید که یک opcode وجود دارد، `CREATE`، که یک قرارداد ایجاد می کند. مکانیک اجرای آن به طور کلی شبیه `CALL` است، با این استثنا که خروجی اجرا کد یک قرارداد جدیدآً ایجاد شده را تعیین می کند.
+
+
+
+### اجرای کد {#code-execution}
+
+کد در قراردادهای اتریوم به زبان بایت کد مبتنی بر پشته، سطح پایین نوشته می شود که به آن «کد ماشین مجازی اتریوم» یا «کد EVM» گفته می شود. کد شامل یک سری بایت است که هر بایت نشان دهنده یک عملیات است. به طور کلی، اجرای کد یک حلقه بی نهایت است که شامل انجام مکرر عملیات در شمارنده برنامه فعلی (که از صفر شروع می شود) و سپس افزایش شمارنده برنامه به یک اندازه، تا رسیدن به انتهای کد یا یک خطا یا < دستورالعمل 0>STOP
یا `RETURN` شناسایی شد. عملیات به سه نوع فضای ذخیرهسازی دادهها دسترسی دارند:
+
+- این **پشته**، محفظهای که میتوان آنها را به بیرون فرستاد و مقادیر را به آن منتقل کرد
+- **Memory**، یک آرایه بایت بی نهایت قابل گسترش است
+- **ذخیره** طولانی مدت قرارداد، یک ذخیره از کلید/ارزش. برخلاف پشته و حافظه که پس از پایان محاسبات بازنشانی میشوند، ذخیرهسازی برای طولانی مدت باقی میماند.
+
+این کد همچنین میتواند به مقدار، فرستنده و دادههای پیام دریافتی و همچنین دادههای هدر بلوک دسترسی داشته باشد و کد همچنین میتواند یک آرایه بایتی از دادهها را به عنوان خروجی برگرداند.
+
+مدل اجرای رسمی کد EVM به طرز شگفت آوری ساده است. در حالی که ماشین مجازی اتریوم در حال اجرا است، حالت محاسباتی کامل آن را میتوان با چند `(block_state، تراکنش، پیام، کد، حافظه، پشته، کامپیوتر، گس)` تعریف کرد، جایی که `block_state 0> حالت جهانی است که شامل تمام حساب ها و شامل موجودی ها و ذخیرهسازی است. در شروع هر دور اجرا، دستورالعمل فعلی با گرفتن pc`امین بایت `کد` (یا 0 اگر `pc >= len(code)`)، و هر دستورالعمل از نظر نحوه تأثیرگذاری بر تاپل، تعریف خاص خود را دارد. برای مثال، `ADD` دو مورد را از پشته بیرون میآورد و مجموع آنها را فشار میدهد، `گس` را به 1 کاهش میدهد و `pc` را به 1 افزایش میدهد و ` SSTORE` دو مورد بالا را از پشته بیرون میآورد و مورد دوم را در فهرستی که مورد اول مشخص کرده است در محل ذخیره قرارداد قرار میدهد. اگرچه راههای زیادی برای بهینهسازی اجرای ماشین مجازی اتریوم از طریق کامپایلسازی بهموقع وجود دارد، پیادهسازی اولیه اتریوم را میتوان در چند صد خط کد انجام داد.
+
+
+
+### بلاکچین و ماینینگ {#blockchain-and-mining}
+
+![بلوک دیاگرام اتریوم اعمال میشود](./ethereum-apply-block-diagram.png)
+
+بلاکچین اتریوم از بسیاری جهات شبیه بلاکچین بیتکوین است، اگرچه تفاوتهایی نیز دارد. تفاوت اصلی بین اتریوم و بیتکوین در معماری بلاکچین این است که بر خلاف بیتکوین، بلاکهای اتریوم شامل یک کپی از لیست تراکنشها و آخرین وضعیت هستند. به غیر از آن، دو مقدار دیگر، شماره بلوک و سختی نیز در بلوک ذخیره میشوند. الگوریتم اصلی اعتبارسنجی بلوک در اتریوم به شرح زیر است:
+
+1. بررسی کنید که آیا بلوک قبلی ارجاع شده وجود دارد و معتبر است.
+2. بررسی کنید که مهر زمانی بلوک بزرگتر از بلوک قبلی ارجاع شده و کمتر از 15 دقیقه در آینده باشد
+3. بررسی کنید که شماره بلوک، سختی، ریشه تراکنش، ریشه عمو و محدودیت گس (مفاهیم مختلف سطح پایین ویژه اتریوم) معتبر هستند.
+4. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
+5. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
+6. اجازه دهید `TX` لیست تراکنش بلوک با `n` تراکنش باشد. برای همه `iها` در `0...n-1`، `S[i+1] = APPLY(S[i],TX[i]) را تنظیم کنید /0>. اگر هر برنامهای خطایی را برمیگرداند، یا اگر کل گس مصرفشده در بلوک تا این نقطه از GASLIMIT` بیشتر شود، یک خطا را برگردانید.
+7. بگذارید `S_FINAL` `S[n]` باشد، اما پاداش بلوک پرداختی به ماینر را اضافه کنید.
+8. بررسی کنید که آیا ریشه درخت مرکل حالت `S_FINAL` با ریشه حالت نهایی ارائه شده در هدر بلوک برابر است یا خیر. اگر چنین باشد، بلوک معتبر است. در غیر این صورت معتبر نیست.
+
+این رویکرد ممکن است در نگاه اول بسیار ناکارآمد به نظر برسد، زیرا باید کل حالت را با هر بلوک ذخیره کند، اما در واقع کارایی باید با بیتکوین قابل مقایسه باشد. دلیل آن این است که حالت در ساختار درختی ذخیره می شود و بعد از هر بلوک فقط قسمت کوچکی از درخت باید تغییر کند. بنابراین، به طور کلی، بین دو بلوک مجاور، اکثریت قریب به اتفاق درخت باید یکسان باشد، و بنابراین داده ها را می توان یک بار ذخیره کرد و دو بار با استفاده از نشانگرها (به عنوان مثال هش درختان فرعی) ارجاع داد. نوع خاصی از درخت که به نام "درخت پاتریشیا" شناخته می شود برای انجام این کار استفاده می شود، از جمله اصلاح مفهوم درخت مرکل که به گره ها اجازه می دهد تا درج و حذف شوند، و نه تنها به طور مؤثر تغییر کنند. علاوه بر این، از آنجایی که تمام اطلاعات وضعیت بخشی از آخرین بلوک است، نیازی به ذخیره کل تاریخچه بلاکچین نیست - استراتژی که اگر بتوان آن را در بیتکوین اعمال کرد، میتوان آن را محاسبه کرد تا 5 تا 20 برابر در فضا صرفهجویی کند.
+
+یک سوال متداول این است که کد قرارداد از نظر سخت افزار فیزیکی "کجا" اجرا می شود. جواب هم ساده است: فرآیند اجرای کد قرارداد بخشی از تعریف تابع انتقال حالت است که بخشی از الگوریتم اعتبارسنج بلوک است، بنابراین اگر تراکنش به بلوک `B` اضافه شود، کد اجرای ایجاد شده توسط آن تراکنش توسط همه گرهها، در حال حاضر و در آینده، که بلوک `B` دانلود و اعتبارسنج میکنند، اجرا خواهد شد.
+
+
+
+## برنامههای کاربردی {#applications}
+
+به طور کلی، سه نوع برنامه سوار بر اتریوم هستند: دسته اول برنامه های مالی هستند که روش های قدرتمندتری را برای مدیریت و عقد قراردادها با استفاده از پول در اختیار کاربران قرار می دهند. این شامل ارزهای فرعی، مشتقات مالی، قراردادهای پوشش ریسک، کیف پول های پس انداز، وصیت نامه و در نهایت حتی برخی از کلاس های قراردادهای کار در مقیاس کامل است. دسته دوم برنامه های نیمه مالی است که در آن پول درگیر است، اما جنبه غیر پولی سنگینی نیز برای کاری که انجام می شود وجود دارد. یک مثال عالی، پاداش های خود-اجباری برای راه حل های مسائل محاسباتی است. در نهایت، برنامه هایی مانند رای گیری آنلاین و حاکمیت غیرمتمرکز وجود دارند که اصلاً مالی نیستند.
+
+
+
+### سیستمهای توکن {#token-systems}
+
+سیستمهای توکن درون بلاکچین کاربردهای زیادی دارند، از ارزهای فرعی که داراییهایی مانند دلار یا طلا را نشان میدهند تا سهام شرکت، توکنهای فردی که نشان دهنده دارایی هوشمند، کوپنهای غیرقابل جعل امن و حتی سیستمهای رمزی بدون هیچ ارتباطی با ارزش متعارف، به عنوان سیستمهای نقطهای برای ایجاد انگیزه استفاده میشوند. پیاده سازی سیستم های توکن در اتریوم به طرز شگفت انگیزی آسان است. نکته کلیدی برای درک این است که تمام یک ارز یا سیستم توکن، اساساً یک پایگاه داده با یک عملیات است: X واحدها را از A کم کنید و واحدهای X را به B بدهید، با این شرط که (i) A حداقل X واحد داشته باشد. قبل از تراکنش و (2) تراکنش توسط A تأیید شود. تمام آنچه برای پیاده سازی یک سیستم توکن نیاز است، پیاده سازی این منطق در یک قرارداد است.
+
+کد اصلی برای پیاده سازی یک سیستم توکن در Serpent به صورت زیر است:
+
+
+
+```py
+def send(to, value):
+ if self.storage[msg.sender] >= value:
+ self.storage[msg.sender] = self.storage[msg.sender] - value
+ self.storage[to] = self.storage[to] + value
+```
+
+
+این اساساً اجرای تحت اللفظی تابع انتقال حالت "سیستم بانکی" است که در بالا در این سند شرح داده شد. چند خط کد اضافی باید اضافه شود تا مرحله اولیه توزیع واحدهای ارزی در وهله اول و چند مورد لبه دیگر فراهم شود، و در حالت ایدهآل تابعی اضافه میشود که به قراردادهای دیگر اجازه میدهد تا تعادل یک آدرس را جستجو کنند. اما این تمام چیزی است که وجود دارد. از نظر تئوری، سیستمهای توکن مبتنی بر اتریوم که بهعنوان ارزهای فرعی عمل میکنند، میتوانند به طور بالقوه ویژگی مهم دیگری را داشته باشند که متا ارزهای مبتنی بر بیتکوین روی زنجیره فاقد آن هستند: توانایی پرداخت مستقیم هزینههای تراکنش در آن ارز. روش اجرای این امر به این صورت است که قرارداد دارای تعادل اتری است که با آن اتری که برای پرداخت هزینهها به فرستنده استفاده میشود بازپرداخت میکند، و این موجودی را با جمعآوری واحدهای ارز داخلی که کارمزد دریافت میکند و فروش مجدد آنها در یک حراج دائمی دوباره پر میکند. بنابراین کاربران باید حساب های خود را با اتر "فعال کنند"، اما زمانی که اتر وجود دارد، قابل استفاده مجدد خواهد بود زیرا قرارداد هر بار آن را بازپرداخت می کند.
+
+
+
+### مشتقات مالی و ارزهای با ارزش ثابت {#financial-derivatives-and-stable-value-currencies}
+
+مشتقات مالی رایج ترین کاربرد "قرارداد هوشمند" و یکی از سادهترین آنها برای پیادهسازی در کد هستند. چالش اصلی در اجرای قراردادهای مالی این است که اکثر آنها نیاز به ارجاع به شاخص قیمت خارجی دارند. به عنوان مثال، یک برنامه بسیار مطلوب، یک قرارداد هوشمند است که در برابر نوسانات اتر (یا یک رمزارز دیگر) با توجه به دلار آمریکا محافظت می کند، اما انجام این کار مستلزم آن است که قرارداد بداند ارزش ETH/USD چقدر است. ساده ترین راه برای انجام این کار، از طریق قرارداد «فید داده» است که توسط یک طرف خاص (مثلاً NASDAQ) نگهداری می شود که به گونه ای طراحی شده است که آن طرف توانایی بهروزرسانی قرارداد را در صورت نیاز داشته باشد، و ارائه رابطی که به سایر قراردادها اجازه می دهد تا یک پیام ارسال کنند. به آن قرارداد پیام دهید و پاسخی دریافت کنید که قیمت را ارائه می دهد.
+
+با توجه به آن عنصر حیاتی، قرارداد پوشش ریسک به شرح زیر است:
+
+1. منتظر بمانید تا طرف اول 1000 اتر را وارد کند.
+2. منتظر بمانید تا طرف دوم 1000 اتر را وارد کند.
+3. ارزش دلاری 1000 اتر را که با کوئری زدن به قرارداد خوراک داده محاسبه می شود، در فضای ذخیرهسازی ثبت کنید، بگویید این مقدار $x است.
+4. پس از 30 روز، به طرف اول و دوم اجازه دهید تا قرارداد را "دوباره فعال کنند" تا اتر به ارزش $x (که با کوئری زدن مجدد به قرارداد خوراک داده برای دریافت قیمت جدید محاسبه می شود) به طرف اول و بقیه به طرف دوم ارسال شود.
+
+چنین قراردادی پتانسیل قابل توجهی در تجارت کریپتویی خواهد داشت. یکی از اصلیترین مشکلاتی که در مورد رمزارزها به آن اشاره میشود، فرِار بودن آن است. اگرچه بسیاری از کاربران و بازرگانان ممکن است امنیت و راحتی کار با دارایی های رمزنگاری شده را بخواهند، اما بسیاری از آنها نمی خواهند با این چشم انداز از دست دادن 23٪ از ارزش سرمایه خود در یک روز روبرو شوند. تا کنون، متداولترین راهحل پیشنهادی، داراییهای دارای پشتوانه صادرکننده بوده است. ایده این است که یک ناشر یک ارز فرعی ایجاد می کند که در آن حق صدور و ابطال واحدها را دارد و یک واحد ارز را به هر کسی که (آفلاین) یک واحد از یک دارایی اساسی مشخص (مثلاً طلا، دلار) را در اختیار آنها قرار می دهد، ارائه دهید. سپس صادرکننده قول میدهد که یک واحد از دارایی پایه را به هر کسی که یک واحد از دارایی رمزنگاری شده را پس میفرستد، ارائه دهد. این مکانیزم به هر دارایی رمزنگارینشده اجازه می دهد تا به یک دارایی رمزنگاری "سربلند" تبدیل شود، مشروط بر اینکه بتوان به صادرکننده اعتماد کرد.
+
+با این حال، در عمل، ناشران همیشه قابل اعتماد نیستند و در برخی موارد زیرساخت بانکی برای وجود چنین خدماتی بسیار ضعیف یا بسیار خصمانه است. مشتقات مالی یک جایگزین را ارائه می دهند. در اینجا، به جای اینکه یک صادرکننده واحد پولی را برای پشتیبانگیری از یک دارایی فراهم کند، یک بازار غیرمتمرکز از سفتهبازان که شرط میبندند قیمت یک دارایی مرجع رمزنگاری (مثلا اتر) بالا خواهد رفت، این نقش را ایفا میکند. بر خلاف صادرکننده، سفته بازان هیچ گزینه ای برای نکول در معامله خود ندارند زیرا قرارداد پوشش ریسک وجوه آنها را در امان نگه می دارد. توجه داشته باشید که این رویکرد کاملاً غیرمتمرکز نیست، زیرا هنوز یک منبع قابل اعتماد برای ارائه شاخص قیمت مورد نیاز است، اگرچه احتمالاً حتی هنوز هم این یک پیشرفت بزرگ از نظر کاهش الزامات زیرساختی است (برخلاف صادرکننده بودن، صدور خوراک قیمت نیازی به مجوز ندارد. و احتمالاً می تواند به عنوان آزادی بیان طبقه بندی شود) و پتانسیل تقلب را کاهش می دهد.
+
+
+
+### سیستم های هویت و شهرت {#identity-and-reputation-systems}
+
+اولین رمزارز جایگزین، [Namecoin](http://namecoin.org/)، تلاش کرد از یک بلاکچین مانند بیتکوین برای ارائه یک سیستم ثبت نام استفاده کند، جایی که کاربران می توانند نام خود را در یک پایگاه داده عمومی در کنار سایر داده ها ثبت کنند. مورد استفاده عمده ذکر شده متعلق به یک سیستم [DNS](https://wikipedia.org/wiki/Domain_Name_System) است که نام های دامنه مانند "bitcoin.org" (یا در مورد Namecoin، "bitcoin.bit") را به یک آدرس IP نگاشت می کند. موارد استفاده دیگر عبارتند از احراز هویت ایمیل و سیستم های شهرت بالقوه پیشرفتهتر. در اینجا قرارداد اصلی برای ارائه یک سیستم ثبت نام مشابه Namecoin در اتریوم است:
+
+
+
+```py
+def register(name, value):
+ if !self.storage[name]:
+ self.storage[name] = value
+```
+
+
+قرارداد بسیار ساده است. همه اینها یک پایگاه داده در داخل شبکه اتریوم است که می توان به آن اضافه کرد، اما نمی توان آن را تغییر داد یا حذف کرد. هر کسی می تواند نامی با مقداری را ثبت کند و آن ثبت نام برای همیشه باقی می ماند. یک قرارداد پیچیدهتر ثبت نام همچنین دارای یک «بند عملکرد» است که به سایر قراردادها امکان میدهد آن را پرس و جو کنند، و همچنین مکانیزمی برای «مالک» (یعنی اولین ثبتکننده) نام برای تغییر داده یا انتقال مالکیت. حتی می توان شهرت و قابلیت های شبکه ای از اعتماد را در بالای آن اضافه کرد.
+
+
+
+### ذخیره سازی غیرمتمرکز فایل {#decentralized-file-storage}
+
+در چند سال گذشته، تعدادی راهانداز ذخیرهسازی فایل آنلاین، معروفترین آنها Dropbox به وجود آمدهاند که به دنبال اجازه دادن به کاربران برای آپلود یک نسخه پشتیبان از هارد دیسک خود و اینکه سرویس پشتیبان را ذخیره کند و به کاربر اجازه دهد در ازای پرداخت هزینه ماهانه به آن دسترسی داشته باشد هستند. با این حال، در این مرحله، بازار ذخیرهسازی فایل در زمانهایی نسبتاً ناکارآمد است. نگاهی گذرا به راهحلهای مختلف موجود نشان میدهد که، بهویژه در سطح 20-200 گیگابایتی «دره غیرعادی» که نه سهمیههای رایگان و نه تخفیفهای سطح سازمانی آغاز میشود، قیمت های ماهانه هزینه های ذخیره سازی فایل اصلی به گونه ای است که شما بیش از هزینه کل هارد دیسک در یک ماه پرداخت می کنید. قراردادهای اتریوم میتوانند به توسعه یک اکوسیستم ذخیرهسازی فایل غیرمتمرکز اجازه دهند، که در آن کاربران فردی میتوانند با اجاره هارد دیسکهای خود مقادیر کمی پول به دست آورند و از فضای بلااستفاده برای کاهش بیشتر هزینههای ذخیرهسازی فایل استفاده شود.
+
+بخش کلیدی زیربنای چنین دستگاهی همان چیزی است که ما آن را "قرارداد غیرمتمرکز Dropbox" نامیده ایم. این قرارداد به شرح زیر عمل می کند. ابتدا، دادههای مورد نظر را به بلوکها تقسیم میکند، هر بلوک را برای حفظ حریم خصوصی رمزگذاری میکند و درخت مرکل را از آن میسازد. سپس یک قرارداد با این قانون منعقد میکند که، هر N بلوک، قرارداد یک شاخص تصادفی در درخت مرکل انتخاب میکند (با استفاده از هش بلوک قبلی، قابل دسترسی از کد قرارداد، به عنوان منبع تصادفی)، و X اتر را به اولین نهادی که یک تراکنش را با یک سند تأیید پرداخت ساده شده مبنی بر مالکیت بلوک در آن شاخص خاص در درخت ارائه می کند، می دهد. هنگامی که کاربر می خواهد فایل خود را دوباره دانلود کند، می تواند از پروتکل کانال پرداخت خرد (مثلاً پرداخت 1 زابو در هر 32 کیلوبایت) برای بازیابی فایل استفاده کند. کارآمدترین رویکرد این است که پرداخت کننده تراکنش را تا پایان منتشر نکند، در عوض تراکنش را با تراکنش کمی سودآورتر با همان نانس پس از هر 32 کیلوبایت جایگزین کند.
+
+یکی از ویژگی های مهم پروتکل این است که، اگرچه ممکن است به نظر برسد که یک نفر به بسیاری از گره های تصادفی اعتماد دارد تا تصمیم به فراموش کردن فایل نداشته باشد، و یک نفر میتواند با تقسیم کردن فایل به قطعات متعدد از طریق اشتراکگذاری مخفی، این ریسک را به نزدیک به صفر کاهش دهد و تماشای قراردادها برای دیدن هر قطعه هنوز در اختیار برخی از گرهها است. اگر یک قرارداد همچنان پولی را پرداخت میکند، این یک مدرک رمزنگاری شده است که نشان میدهد یک نفر هنوز در آنجا دارد فایل را ذخیره میکند.
+
+
+
+### سازمان خودمختار غیرمتمرکز {#decentralized-autonomous-organizations}
+
+مفهوم کلی "سازمان خودمختار غیرمتمرکز" عبارت است از یک نهاد مجازی که دارای مجموعه معینی از اعضا یا سهامداران است که شاید با اکثریت 67 درصدی، حق دارند وجوه آن واحد را خرج کرده و کد آن را اصلاح کنند. اعضا به طور جمعی در مورد نحوه تخصیص بودجه توسط سازمان تصمیم می گیرند. روشهای تخصیص وجوه یک DAO میتواند از جوایز، حقوق گرفته تا مکانیسمهای عجیبتری مانند ارز داخلی برای پاداش دادن به کار متغیر باشد. این اساساً موارد قانونی یک شرکت سنتی یا غیرانتفاعی را تکرار می کند، اما تنها از فناوری بلاکچین رمزنگاری شده برای اجرا استفاده می کند. تاکنون بسیاری از صحبتها در مورد DAOها حول مدل «سرمایهداری» یک «شرکت مستقل غیرمتمرکز» (DAC) با سهامداران دریافتکننده سود سهام و سهام قابل معامله بوده است. یک جایگزین، که شاید به عنوان «جامعه خودمختار غیرمتمرکز» توصیف شود، این است که همه اعضا سهم برابری در تصمیمگیری دارند و 67 درصد از اعضای موجود باید با اضافه کردن یا حذف یک عضو موافقت کنند. این شرط که یک نفر فقط می تواند یک عضویت داشته باشد باید به طور جمعی توسط گروه اجرا شود.
+
+یک طرح کلی برای نحوه کدنویسی یک DAO به شرح زیر است. سادهترین طرح صرفاً یک قطعه کد خود اصلاحکننده است که در صورت توافق دو سوم اعضا بر روی تغییرات تغییر میکند. اگرچه کد از نظر تئوری تغییرناپذیر است، اما با داشتن تکههایی از کد در قراردادهای جداگانه، و ذخیره آدرس قراردادهای فراخوانی ذخیره شده در ذخیرهسازی قابل تغییر، میتوان به راحتی از این موضوع عبور کرد و تغییرپذیری واقعی داشت. در اجرای ساده چنین قرارداد DAO، سه نوع تراکنش وجود دارد که با داده های ارائه شده در تراکنش متمایز می شوند:
+
+- `[0,i,K,V]` برای ثبت پیشنهاد با نمایه `i` برای تغییر آدرس در فهرست ذخیرهسازی `K` به مقدار ` V`
+- برای ثبت رای به نفع پیشنهاد `[1,i]` `i`
+- `[2,i]` برای نهایی کردن پیشنهاد `i` اگر رای کافی داده شده باشد
+
+سپس قرارداد برای هر یک از اینها بندهایی خواهد داشت. این یک رکورد از همه تغییرات فضای باز را به همراه فهرستی از افرادی که به آنها رای داده اند حفظ می کند. همچنین فهرستی از همه اعضا را خواهد داشت. هنگامی که هر تغییر فضای ذخیرهسازی به دو سوم اعضا می رسد که به آن رأی می دهند، یک تراکنش نهایی می تواند تغییر را اجرا کند. یک اسکلت پیچیدهتر همچنین میتواند قابلیت رایگیری داخلی برای ویژگیهایی مانند ارسال تراکنش، افزودن اعضا و حذف اعضا داشته باشد، و حتی ممکن است امکان تفویض رأی به سبک [دموکراسی نقد](https://wikipedia.org/wiki/Liquid_democracy) را فراهم کند (یعنی هرکسی میتواند شخصی را به رای دادن به او اختصاص دهد، و انتساب انتقالی است، بنابراین اگر A به B و B به C اختصاص دهد، C رای A را تعیین میکند). این طراحی به DAO اجازه می دهد تا به صورت ارگانیک به عنوان یک جامعه غیرمتمرکز رشد کند، و به مردم این امکان را می دهد تا در نهایت وظیفه فیلتر کردن اعضای آن را به متخصصان محول کنند، اگرچه برخلاف «سیستم فعلی»، متخصصان به راحتی می توانند در طول زمان وارد و خارج شوند همانطور که افراد جامعه صف بندی خود را تغییر می دهند.
+
+یک مدل جایگزین برای یک شرکت غیرمتمرکز است، که در آن هر حسابی میتواند دارای سهام صفر یا بیشتر باشد و دو سوم سهام برای تصمیمگیری لازم است. یک اسکلت کامل شامل عملکرد مدیریت دارایی، توانایی ارائه پیشنهاد برای خرید یا فروش سهام، و توانایی پذیرش پیشنهادها (ترجیحا با مکانیزم تطبیق سفارش در داخل قرارداد) است. تفویض اختیار نیز به سبک دموکراسی مایع وجود خواهد داشت که مفهوم "هیئت مدیره" را تعمیم می دهد.
+
+
+
+### برنامههای کاربردهای بیشتر {#further-applications}
+
+**1. کیفهای پول پسانداز**. فرض کنید که آلیس (Alice) میخواهد سرمایه خود را ایمن نگه دارد، اما نگران است که از دست بدهد یا کسی کلید خصوصی او را هک کند. او اتر را در یک قرارداد با باب، یک بانک، به شرح زیر قرار می دهد:
+
+- آلیس به تنهایی میتواند حداکثر 1 درصد از وجوه را در روز برداشت کند.
+- باب به تنهایی میتواند حداکثر 1 درصد از وجوه را در روز برداشت کند، اما آلیس این توانایی را دارد که با کلید خود معامله کند و این توانایی را خاموش کند.
+- آلیس و باب با هم میتوانند هر چیزی را پس بگیرند.
+
+به طور معمول، 1 درصد در روز برای آلیس کافی است، و اگر آلیس بخواهد بیشتر برداشت کند، میتواند برای کمک با باب تماس بگیرد. اگر کلید آلیس هک شود، او به سراغ باب میرود تا سرمایه را به یک قرارداد جدید منتقل کند. اگر او کلید خود را گم کند، باب در نهایت وجوه را بیرون خواهد آورد. اگر معلوم شود که باب بدخواه است، او می تواند دسترسی باب را برای برداشت خاموش کند.
+
+**2. بیمه محصول**. می توان به راحتی قرارداد مشتقات مالی منعقد کرد، اما به جای هر شاخص قیمت، از داده های آب و هوا استفاده کرد. اگر یک کشاورز در آیووا مشتقی را خریداری کند که بر اساس بارندگی در آیووا به طور معکوس پرداخت می کند، اگر خشکسالی وجود داشته باشد، کشاورز به طور خودکار پول دریافت می کند و اگر باران کافی باشد، کشاورز خوشحال خواهد شد زیرا محصولات آنها به خوبی انجام می شود. این را می توان به طور کلی به بیمه بلایای طبیعی گسترش داد.
+
+**3. یک خوراک دیتای غیرمتمرکز**. برای قراردادهای مالی برای تفاوت، ممکن است واقعاً بتوان فید داده را از طریق پروتکلی به نام "[SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) غیرمتمرکز کرد". شلینگ کوین (SchellingCoin) اساساً به این صورت عمل میکند: N طرف همه ارزش یک داده معین (مثلاً قیمت اتر/USD) را در سیستم قرار میدهند، مقادیر مرتب میشوند، و هر کس بین صدک 25 و 75 یک توکن به عنوان پاداش دریافت میکند. همه انگیزه ای برای ارائه پاسخی دارند که دیگران ارائه خواهند کرد، و تنها ارزشی که تعداد زیادی از بازیکنان می توانند به طور واقع بینانه روی آن توافق کنند، پیش فرض آشکار است: حقیقت. این مورد یک پروتکل غیرمتمرکز ایجاد میکند که از نظر تئوری میتواند مقادیر زیادی از جمله قیمت اتر/USD، دمای برلین یا حتی نتیجه یک محاسبه سخت خاص را ارائه دهد.
+
+**4. ضمانت چند امضایی هوشمند**. بیتکوین به قراردادهای تراکنش چند امضایی اجازه میدهد که برای مثال، سه کلید از پنج کلید معین میتوانند وجوه را خرج کنند. اتریوم به جزئیات بیشتر اجازه میدهد. به عنوان مثال، از هر پنج نفر چهار نفر میتوانند همه چیز را خرج کنند، از هر پنج نفر سه نفر میتوانند تا 10 درصد در روز و از هر پنج نفر دو نفر میتوانند تا 0.5 درصد در روز خرج کنند. علاوه بر این، اتریوم مالتی سیگ ناهمزمان است - دو طرف میتوانند امضاهای خود را در زمانهای مختلف روی بلاکچین ثبت کنند و آخرین امضا به طور خودکار تراکنش را ارسال میکند.
+
+**5. پردازش ابری**. فناوری EVM همچنین میتواند برای ایجاد یک محیط محاسباتی قابل تأیید استفاده شود و به کاربران این امکان را میدهد که از دیگران بخواهند محاسبات را انجام دهند و سپس بهصورت اختیاری، مدارکی بخواهند که محاسبات در نقاط بازرسی بهطور تصادفی انتخاب شده به درستی انجام شده است. این مورد امکان ایجاد یک بازار رایانش ابری را فراهم میکند که در آن هر کاربر میتواند با دسکتاپ، لپتاپ یا سرور تخصصی خود در آن شرکت کند و از چک کردن اسپات همراه با سپردههای امنیتی میتوان برای اطمینان از قابل اعتماد بودن سیستم استفاده کرد (یعنی گرهها یا نودها نمیتوانند به طور سودآوری تقلب کنند). اگرچه چنین سیستمی ممکن است برای همه کارها مناسب نباشد. به عنوان مثال، کارهایی که به سطح بالایی از ارتباطات بین فرآیندی نیاز دارند، نمیتوانند به راحتی بر روی یک ابر بزرگ از گرهها یا نودها انجام شوند. با این حال، موازی سازی سایر وظایف بسیار آسان تر است. پروژه هایی مانند SETI@home، folding@home و الگوریتم های ژنتیک را می توان به راحتی بر روی چنین پلتفرمی پیادهسازی کرد.
+
+**6. قمار همتا به همتا**. هر تعداد پروتکل قمار همتا به همتا مانند [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Frank Stajano و Richard Clayton را می توان در بلاکچین اتریوم پیادهسازی کرد. سادهترین پروتکل قمار در واقع صرفاً یک قرارداد برای تفاوت در هش بلوک بعدی است و پروتکلهای پیشرفتهتری را میتوان از آنجا ایجاد کرد و خدمات قمار با هزینههای تقریباً صفر ایجاد کرد که توانایی تقلب ندارند.
+
+**7. بازارهای پیش بینی**. به شرط یک اوراکل یا شلینگ کوین، پیادهسازی بازارهای پیشبینی نیز آسان است، و بازارهای پیشبینی همراه با شلینگ کوین ممکن است اولین کاربرد جریان اصلی [futarchy](http://hanson.gmu.edu/futarchy.html) به عنوان پروتکل حاکمیتی برای سازمانهای غیرمتمرکز باشد.
+
+**8. بازارهای غیرمتمرکز زنجیرهای**، با استفاده از سیستم هویت و شهرت به عنوان پایگاه.
+
+
+
+## مسائل متفرقه و نگرانیها {#miscellanea-and-concerns}
+
+
+
+### پروتکل اصلاح شده ی GHOST {#modified-ghost-implementation}
+
+پروتکل "طماعترین زیردرخت مشاهده شده" (GHOST) یک نوآوری است که برای اولین بار توسط Yonatan Sompolinsky و Aviv Zohar در [دسامبر 2013](https://eprint.iacr.org/2013/881.pdf) معرفی شد. انگیزه پشت GHOST این است که بلاک چینهایی با زمان تایید سریع در حال حاضر به دلیل نرخ قدیمی بالا از امنیت کمتری رنج میبرند - زیرا بلوکها زمان مشخصی را برای انتشار در شبکه میطلبند، اگر ماینر A یک بلوک را استخراج کند و سپس ماینر B بلوک دیگری را استخراج کند. قبل از انتشار بلوک ماینر A به B، بلوک ماینر B به هدر می رود و به امنیت شبکه کمک نمی کند. علاوه بر این، یک مشکل متمرکز وجود دارد: اگر ماینر A یک استخر استخراج با 30٪ قدرت هش و B دارای 10٪ قدرت هش باشد، A در 70٪ مواقع (از 30٪ بقیه مواقع) خطر تولید یک بلوک قدیمی را خواهد داشت. A آخرین بلوک را تولید می کند و بنابراین بلافاصله داده های استخراج را دریافت می کند) در حالی که B در 90٪ مواقع خطر تولید یک بلوک قدیمی را دارد. بنابراین، اگر فاصله بلوک به اندازهای کوتاه باشد که نرخ بیات بالا باشد، A بهدلیل اندازهاش به طور قابلتوجهی کارآمدتر خواهد بود. با ترکیب این دو اثر، بلاکچینهایی که بلوکها را به سرعت تولید میکنند، به احتمال زیاد منجر به یک استخر ماینینگ میشوند که درصد زیادی از قدرت هش شبکه را داشته باشد تا بتواند بالفعل بر فرآیند استخراج کنترل داشته باشد.
+
+همانطور که توسط Sompolinsky و Zohar توضیح داده شد، GHOST اولین مشکل از دست دادن امنیت شبکه را با گنجاندن بلوک های قدیمی در محاسبه اینکه کدام زنجیره "طولانی ترین" است را حل می کند. به این معنا که نه تنها والدین و اجداد بعدی یک بلوک، بلکه نوادگان قدیمی اجداد بلوک (در اصطلاح اتریومی، "عمو ها") به محاسباتی اضافه می شوند که کدام بلوک دارای بزرگترین اثبات کار است. برای حل مسئله دوم سوگیری متمرکزسازی، ما فراتر از پروتکل توصیف شده توسط Sompolinsky و Zohar میرویم، و همچنین پاداشهای بلوک را برای قدیمیها ارائه میکنیم: یک بلوک قدیمی 87.5٪ از پاداش پایه خود را دریافت میکند و برادرزاده که شامل بلوک قدیمی است، 12.5 درصد بقیه را دریافت میکند. با این حال، کارمزد تراکنش به عموها تعلق نمی گیرد.
+
+اتریوم نسخه ساده شده GHOST را پیاده سازی می کند که تنها در هفت سطح پایین می آید. به طور مشخص به صورت زیر تعریف می شود:
+
+- یک بلوک باید یک والد را مشخص کند و باید 0 یا چند عمو را مشخص کند
+- عموی موجود در بلوک B باید دارای ویژگی های زیر باشد:
+ - این باید یک فرزند مستقیم از اجداد نسل k ام B باشد که در آن `2 <= k <= 7`.
+ - نمی تواند جد B باشد
+ - عمو باید یک هدر بلوک معتبر باشد، اما نیازی نیست که قبلاً یک بلوک تأیید شده یا حتی معتبر باشد
+ - یک عمو باید با همه عموهای موجود در بلوک های قبلی و سایر عموهای موجود در همان بلوک متفاوت باشد (غیر شامل دوگانه)
+- به ازای هر عموی U در بلوک B، ماینر B 3.125٪ اضافی به پاداش کوینبیس خود اضافه می کند و ماینر U 93.75٪ از پاداش استاندارد کوینبیس را دریافت می کند.
+
+این نسخه محدود GHOST، با عموهایی که فقط تا 7 نسل را شامل می شود، به دو دلیل استفاده شد. اولاً، GHOST نامحدود شامل پیچیدگی های بسیار زیادی در محاسبه است که عموهای یک بلوک معین معتبر هستند. دوم، GHOST نامحدود با جبرانی که در اتریوم استفاده میشود، انگیزه استخراجکننده را برای استخراج از زنجیره اصلی و نه زنجیره مهاجم عمومی را از بین میبرد.
+
+
+
+### کارمزدها {#fees}
+
+از آنجایی که هر تراکنش منتشر شده در بلاکچین، هزینه دانلود و تأیید آن را بر شبکه تحمیل میکند، برای جلوگیری از سوء استفاده، نیاز به مکانیزمی نظارتی وجود دارد که معمولاً شامل کارمزد تراکنش است. رویکرد پیشفرض، که در بیتکوین استفاده میشود، داشتن هزینههای کاملاً داوطلبانه است، با تکیه بر ماینرها که به عنوان دروازهبان عمل میکنند و حداقلهای پویا را تعیین میکنند. این رویکرد در جامعه بیتکوین با استقبال بسیار خوبی مواجه شده است، بهویژه به این دلیل که «مبتنی بر بازار» است و به عرضه و تقاضای بین ماینرها و فرستندگان تراکنش اجازه میدهد تا قیمت را تعیین کنند. با این حال، مشکل این خط استدلال این است که پردازش معاملات یک بازار نیست. اگرچه به طور شهودی درک پردازش تراکنش به عنوان خدماتی که ماینر به فرستنده ارائه میدهد جذاب است، در واقع هر تراکنشی که توسط ماینر شامل میشود باید توسط هر گره یا نود در شبکه پردازش شود، بنابراین اکثریت قریب به اتفاق هزینه تراکنش پردازش به عهده اشخاص ثالث است و نه ماینری که تصمیم می گیرد که آن را شامل شود یا نه. از این رو، مشکلات تراژدی رایج بسیار محتمل است.
+
+با این حال، همانطور که مشخص است این نقص در مکانیسم مبتنی بر بازار، زمانی که یک فرض سادهسازی نادرست خاص داده میشود، به طور جادویی خود را خنثی میکند. استدلال به شرح زیر است. فرض کنید که:
+
+1. یک تراکنش به عملیات `k` منتهی میشود، و پاداش `kR` را به هر استخراجکنندهای که شامل آن میشود، ارائه میکند، جایی که `R` توسط فرستنده و `k تنظیم شده است. ` و `R` از قبل (تقریبا) برای ماینر قابل مشاهده هستند.
+2. یک عملیات دارای هزینه پردازش `C` برای هر گره است (یعنی همه گره ها کارایی یکسانی دارند)
+3. تعداد `N` گره ماینینگ وجود دارد که هر کدام دقیقاً قدرت پردازشی برابری دارند (یعنی `1/N` از کل)
+4. هیچ گره کامل غیر ماینینگی وجود ندارد.
+
+اگر پاداش مورد انتظار بیشتر از هزینه باشد، یک ماینر مایل به پردازش یک تراکنش است. بنابراین، پاداش مورد انتظار `kR/N` است زیرا ماینر شانس `1/N` برای پردازش بلوک بعدی را دارد و هزینه پردازش برای ماینر به سادگی ` است. kC`. بنابراین، ماینرها شامل تراکنشهایی میشوند که در آنها `kR/N > kC`، یا `R > NC` باشد. توجه داشته باشید که `R` کارمزد هر عملیات ارائه شده توسط فرستنده است، و بنابراین یک حد پایینتر برای سودی است که فرستنده از تراکنش کسب میکند،و `NC` هزینه کل شبکه برای پردازش یک عملیات است. از این رو، ماینرها این انگیزه را دارند که فقط آن دسته از تراکنشهایی را بگنجانند که کل سود از هزینه آن بیشتر باشد.
+
+با این حال، چندین انحراف مهم از این فرضیات در واقعیت وجود دارد:
+
+1. ماینر هزینه بیشتری را برای پردازش تراکنش نسبت به سایر گرهها یا نودهای تأیید کننده پرداخت میکند، زیرا زمان تأیید اضافی انتشار بلوک را به تأخیر میاندازد و در نتیجه احتمال بسته شدن بلوک را افزایش میدهد.
+2. گره یا نودهای کامل غیر ماینینگ وجود دارد.
+3. توزیع نیروی استخراج ممکن است در عمل به شدت نابرابر شود.
+4. دلالان، دشمنان سیاسی و دیوانههایی که عملکرد مفید آنها شامل ایجاد آسیب به شبکه است، وجود دارند، و میتوانند هوشمندانه قراردادهایی را تنظیم کنند که هزینه آنها بسیار کمتر از هزینه پرداخت شده توسط سایر گرهها یا نودهای تأیید کننده باشد.
+
+(1) تمایلی را برای ماینر فراهم می کند که تراکنش های کمتری را شامل شود، و (2) `NC` را افزایش می دهد. بنابراین، این دو اثر حداقل تا حدی یکدیگر را خنثی می کنند.[چگونه؟] https://github.com/ethereum/wiki/issues/447#issuecomment-316972260) (3) و (4) موضوع اصلی هستند. برای حل آنها به سادگی یک سرمایه شناور ایجاد می کنیم: هیچ بلوکی نمی تواند بیش از `BLK_LIMIT_FACTOR` برابر میانگین متحرک نمایی بلندمدت عملیات داشته باشد. به خصوص:
+
+
+
+```js
+blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
+floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)
+```
+
+
+`BLK_LIMIT_FACTOR` و `EMA_FACTOR` ثابتهایی هستند که فعلاً روی 65536 و 1.5 تنظیم میشوند، اما احتمالاً پس از تجزیه و تحلیل بیشتر تغییر خواهند کرد.
+
+عامل دیگری نیز وجود دارد که اندازه بلوکهای بزرگ را در بیتکوین از بین میبرد: بلوکهایی که بزرگ هستند زمان بیشتری طول میکشد تا انتشار پیدا کنند و در نتیجه احتمال بیات شدن آنها بیشتر است. در اتریوم، انتشار بلوکهای بسیار مصرفکننده گس هم به دلیل بزرگتر بودن و هم به دلیل اینکه پردازش انتقالهای حالت تراکنش برای تأیید اعتبار بیشتر طول میکشد، ممکن است بیشتر طول بکشد. این بازدارنده تاخیر در بیتکوین مورد توجه قرار می گیرد، اما در اتریوم به دلیل پروتکل GHOST کمتر مورد توجه قرار می گیرد. از این رو، تکیه بر محدودیت های بلوک تنظیم شده، پایه پایدارتری را فراهم می کند.
+
+
+
+### محاسبات و تورینگ کامل بودن {#computation-and-turing-completeness}
+
+یک نکته مهم این است که ماشین مجازی اتریوم تورینگ کامل است. این بدان معنی است که کد EVM می تواند هر محاسباتی را که می توان انجام داد، از جمله حلقه های بی نهایت، رمزگذاری کند. کد EVM به دو صورت امکان حلقه زدن را می دهد. اول، یک دستورالعمل `JUMP` وجود دارد که به برنامه اجازه می دهد به نقطه قبلی در کد بازگردد، و یک دستور `JUMPI` برای انجام پرش شرطی، اجازه می دهد تا عباراتی مانند `در حالی که x < 27: x = x * 2` است. دوم، قراردادها میتوانند قراردادهای دیگری را فراخوانی کنند، که امکان چرخش از طریق بازگشت را فراهم میکند. این مورد به طور طبیعی منجر به یک مشکل میشود: آیا کاربران مخرب اساساً میتوانند ماینرها و گره یا نودهای کامل را با مجبور کردن آنها برای ورود به یک لوپ (loop) بینهایت ببندند؟ این موضوع به دلیل مشکلی در علم کامپیوتر به نام مشکل توقف به وجود میآید: در حالت کلی، هیچ راهی برای تشخیص اینکه آیا یک برنامه مشخص هرگز متوقف میشود یا خیر وجود ندارد.
+
+همانطور که در بخش انتقال وضعیت توضیح داده شد، راهحل ما با نیاز به یک تراکنش برای تنظیم حداکثر تعداد مراحل محاسباتی که مجاز به انجام آن هستند، کار میکند، و اگر اجرا طول بکشد، محاسبات برگردانده میشود اما هنوز هزینهها پرداخت میشود. پیامها به همین صورت عمل میکنند. برای نشان دادن انگیزه راه حل ما، مثالهای زیر را در نظر بگیرید:
+
+- یک مهاجم قراردادی ایجاد میکند که یک حلقه بینهایت اجرا میکند، و سپس یک تراکنش فعالسازی آن حلقه را برای ماینر ارسال میکند. ماینر تراکنش را پردازش می کند، حلقه بی نهایت را اجرا می کند و منتظر می ماند تا گس آن تمام شود. حتی اگر گس اجرا تمام شود و در نیمه راه متوقف شود، تراکنش هنوز معتبر است و ماینر همچنان هزینه هر مرحله محاسباتی را از مهاجم مطالبه می کند.
+- یک مهاجم یک حلقه بینهایت بسیار طولانی ایجاد می کند که قصد دارد ماینر را مجبور کند که محاسبات را برای مدت طولانی ادامه دهد تا زمانی که محاسبات به پایان برسد، چند بلوک دیگر بیرون آمده و برای ماینر امکان گنجاندن تراکنش برای مطالبه کارمزد وجود نخواهد داشت. با این حال، مهاجم باید مقداری را برای `STARTGAS` ارسال کند که تعداد مراحل محاسباتی را که اجرا میتواند انجام دهد محدود میکند. بنابراین ماینر از قبل میداند که محاسبه تعداد بسیار زیادی از مراحل را طی میکند.
+- مهاجم قراردادی را با کدهایی مانند `send(A,contract.storage[A]) می بیند. contract.storage[A] = 0`، و تراکنش را با گس کافی برای اجرای مرحله اول ارسال می کند اما مرحله دوم را نه (یعنی برداشت انجام می دهد اما اجازه نمی دهد موجودی پایین بیاید). نویسنده قرارداد نیازی به نگرانی در مورد محافظت در برابر چنین حملاتی ندارد، زیرا اگر اجرا در نیمه راه متوقف شود، تغییرات برگردانده می شوند.
+- یک قرارداد مالی با استفاده از میانه 9 خوراک دیتای اختصاصی به منظور به حداقل رساندن ریسک کار می کند. مهاجم یکی از فیدهای داده را در اختیار می گیرد که به گونه ای طراحی شده است که از طریق مکانیسم متغیر-آدرس-فراخوانی توضیح داده شده در بخش DAO قابل تغییر باشد، و آن را به یک حلقه بی نهایت تبدیل می کند، در نتیجه تلاش می کند هر گونه تلاش برای مطالبه وجوه از قرارداد مالی را مجبور به تمام شدن گاز کند. با این حال، قرارداد مالی می تواند برای جلوگیری از این مشکل محدودیتی برای پیام تعیین کند.
+
+تورینگ کامل نبودن جایگزین تورینگ کامل بودن است، که در آن `JUMP` و `JUMPI` وجود ندارند و فقط یک نسخه از هر قرارداد مجاز است در هر زمان معین در پشته تماس وجود داشته باشد. با این سیستم، سیستم کارمزد توصیف شده و عدم اطمینان در مورد اثربخشی راه حل ما ممکن است ضروری نباشد، زیرا هزینه اجرای یک قرارداد به اندازه آن محدود می شود. علاوه بر این، ناقص بودن تورینگ حتی یک محدودیت بزرگ هم نیست. از بین تمام نمونههای قراردادی که به صورت داخلی تصور کردهایم، تا کنون تنها یک مورد نیاز به یک حلقه داشت، و حتی آن حلقه را می توان با ایجاد 26 تکرار از یک قطعه کد یک خطی حذف کرد. با توجه به پیامدهای جدی تورینگ کامل بودن و مزایای محدود، چرا به سادگی یک زبان تورینگ ناکامل نداشته باشیم؟ با این حال، در واقعیت، تورینگ ناکامل به دور از یک راه حل ساده برای مشکل است. برای اینکه بفهمید چرا، قراردادهای زیر را در نظر بگیرید:
+
+
+
+```sh
+C0: call(C1); call(C1);
+C1: call(C2); call(C2);
+C2: call(C3); call(C3);
+...
+C49: call(C50); call(C50);
+C50: (run one step of a program and record the change in storage)
+```
+
+
+اکنون یک تراکنش به A ارسال کنید. بنابراین، در 51 تراکنش، قراردادی داریم که 250 مرحله محاسباتی را طی می کند. ماینرها میتوانند با حفظ مقداری در کنار هر قرارداد که حداکثر تعداد مراحل محاسباتی را که میتواند انجام دهد، این بمبهای منطقی را پیش از موعد شناسایی کنند، و محاسبه این برای قراردادهایی که قراردادهای دیگر را به صورت بازگشتی فراخوانی میکنند، اما این امر مستلزم آن است که ماینرها قراردادهایی را که قراردادهای دیگری ایجاد میکنند ممنوع کنند (از آنجایی که ایجاد و اجرای تمام 26 قرارداد فوق به راحتی می تواند در یک قرارداد واحد تبدیل شود). نکته مشکلساز دیگر این است که فیلد آدرس یک پیام یک متغیر است، بنابراین به طور کلی ممکن است حتی نتوان گفت که یک قرارداد معین با کدام قراردادهای دیگر پیش از موعد تماس خواهد گرفت. بنابراین، در مجموع، ما یک نتیجه شگفتانگیز داریم: مدیریت کامل بودن تورینگ بهطور شگفتانگیزی آسان است، و مدیریت عدم وجود تورینگ کامل بودن به همان اندازه دشوار است، مگر اینکه دقیقاً همان کنترلها وجود داشته باشد - اما در این مورد چرا نه فقط اجازه دهید پروتکل تورینگ کامل باشد?
+
+
+
+### ارز و صدور {#currency-and-issuance}
+
+شبکه اتریوم شامل ارز داخلی خود به نام اتر است که هدف دوگانه ارائه یک لایه نقدینگی اولیه را برای تبادل کارآمد بین انواع مختلف داراییهای دیجیتال و مهمتر از آن، ارائه مکانیزمی برای پرداخت هزینه تراکنشها دارد. برای سهولت و اجتناب از استدلال های آینده (به بحث فعلی mBTC/uBTC/satoshi در بیتکوین مراجعه کنید)، مقادیر ارزش از قبل نامگذاری گذاری خواهند شد:
+
+- 1: wei
+- 1012: szabo
+- 1015: finney
+- 1018: ether
+
+این باید به عنوان یک نسخه توسعه یافته از مفهوم "دلار" و "سنت" یا "بیتکوین" و "ساتوشی" در نظر گرفته شود. در آینده نزدیک، ما انتظار داریم که "اتر" برای تراکنش های معمولی، "finney" برای تراکنش های خرد و "szabo" و "wei" برای بحث های فنی در مورد هزینه ها و اجرای پروتکل استفاده شود. ارزشهای باقیمانده ممکن است بعداً مفید باشند و در این مرحله نباید در مشتریان گنجانده شوند.
+
+مدل صدور به صورت زیر خواهد بود:
+
+- اتر در فروش ارزی با قیمت 1000 تا 2000 اتر در هر بیتکوین عرضه خواهد شد، مکانیزمی که برای تامین مالی سازمان اتریوم و پرداخت هزینه توسعه در نظر گرفته شده است که با موفقیت توسط پلتفرمهای دیگری مانند مسترکوین (Mastercoin) و NXT استفاده شده است. خریداران اولیه از تخفیفهای بیشتری بهرهمند خواهند شد. بیت کوین دریافتی از فروش کامل برای پرداخت حقوق و جوایز به توسعهدهندگان و سرمایهگذاری در پروژههای مختلف انتفاعی و غیرانتفاعی در اتریوم و اکوسیستم ارزهای دیجیتال استفاده میشود.
+- 0.099 برابر کل مبلغ فروخته شده (60102216 اتر) برای جبران خسارت مشارکتکنندگان اولیه و پرداخت هزینههای اتر قبل از بلوک پیدایش به سازمان تخصیص داده میشود.
+- 0.099 برابر کل مبلغ فروخته شده به عنوان ذخیره بلند مدت نگهداری میشود.
+- 0.26 برابر کل مبلغ فروخته شده برای همیشه پس از آن نقطه به ماینرها در سال اختصاص می یابد.
+
+| گروه | در زمان راهاندازی | بعد از 1 سال | بعد از 5 سال |
+| ------------------------ | ------------------ | ------------ | ------------ |
+| واحدهای ارزی | 1.198X | 1.458X | 2.498X |
+| خریداران | 83.5% | 68.6% | 40.0% |
+| رزرو صرف شده در پیش فروش | 8.26% | 6.79% | 3.96% |
+| رزرو صرف شده پس از فروش | 8.26% | 6.79% | 3.96% |
+| ماینرها | 0% | 17.8% | 52.0% |
+
+
+
+
+#### نرخ رشد عرضه بلندمدت (درصد)
+
+![تورم اتریوم](./ethereum-inflation.png)
+
+_با وجود انتشار ارز خطی، درست مانند بیتکوین در طول زمان، نرخ رشد عرضه با این وجود به صفر میرسد._
+
+دو انتخاب اصلی در مدل فوق عبارتند از (1) وجود و اندازه یک استخر وقف، و (2) وجود یک عرضه خطی دائما در حال رشد، در مقابل عرضه سقفی مانند بیتکوین. توجیه استخر وقف به شرح زیر است. اگر استخر وقف وجود نداشت، و انتشار خطی به 0.217 برابر کاهش می یافت تا نرخ تورم یکسانی ارائه شود، آنگاه مقدار کل اتر 16.5٪ کمتر می شد و بنابراین هر واحد 19.8٪ ارزش بیشتری داشت. بنابراین، در حالت تعادل 19.8٪ اتر بیشتر در فروش خریداری می شود، بنابراین هر واحد دوباره دقیقاً به اندازه قبل ارزشمند خواهد بود. این سازمان همچنین 1.198 برابر همان بیتکوین خواهد داشت که می توان آن را به دو بخش تقسیم کرد: بیتکوین اصلی و 0.198 برابر دیگر. از این رو، این وضعیت _دقیقاً معادل_ با وقف است، اما با یک تفاوت مهم: سازمان صرفاً BTC را در اختیار دارد، و بنابراین انگیزه ای برای حمایت از ارزش واحد اتر ندارد.
+
+مدل رشد عرضه خطی دائمی خطر آنچه را که برخی به عنوان تمرکز بیش از حد ثروت در بیتکوین می دانند، کاهش می دهد. و به افرادی که در دوران کنونی و آینده زندگی می کنند فرصت مناسبی برای بدست آوردن واحدهای ارزی می دهد، در حالی که در عین حال انگیزه قوی برای به دست آوردن و نگهداری اتر حفظ می شود زیرا "نرخ رشد عرضه" به عنوان درصد همچنان در طول زمان به صفر تمایل دارد. ما همچنین این نظریه را مطرح می کنیم که چون سکه ها همیشه در طول زمان به دلیل بی احتیاطی، مرگ و غیره گم می شوند، و زیان سکه را می توان به صورت درصدی از کل عرضه در سال مدل کرد، که در واقع عرضه کل ارز در گردش در نهایت در ارزشی برابر با انتشار سالانه تقسیم بر نرخ ضرر تثبیت می شود. (به عنوان مثال، با نرخ ضرر 1٪، هنگامی که عرضه به 26X رسید، 0.26X استخراج می شود و 0.26X هر سال از دست می رود و تعادل ایجاد می کند).
+
+توجه داشته باشید که در آینده، این احتمال وجود دارد که اتریوم برای امنیت به مدل اثبات سهام روی بیاورد و نیاز صدور را بین صفر تا 0.05 برابر در سال کاهش دهد. در صورتی که سازمان اتریوم بودجه خود را از دست بدهد یا به هر دلیل دیگری ناپدید شود، یک "قرارداد اجتماعی" را باز می گذاریم: هر کسی حق دارد یک نسخه کاندید آینده اتریوم ایجاد کند، تنها شرط این است که مقدار اتر باید حداکثر برابر با `60102216 * (1.198 + 0.26 * n)` باشد که در آن `n` تعداد سالهای پس از بلوک پیدایش است. سازندگان مختارند که به صورت انبوه بفروشند یا برخی یا تمام تفاوت بین گسترش عرضه مبتنی بر PoS و حداکثر گسترش عرضه مجاز را برای پرداخت هزینه توسعه اختصاص دهند. نامزدهای ارتقا که با قرارداد اجتماعی مطابقت ندارند، ممکن است به طور موجه در نسخه های سازگار تقسیم شوند.
+
+
+
+### تمرکزگرایی ماینینگ {#mining-centralization}
+
+الگوریتم استخراج بیتکوین به این صورت کار می کند که ماینرها SHA256 را بر روی نسخه های کمی تغییر یافته هدر بلوک میلیون ها بار و بارها محاسبه کنند تا اینکه در نهایت یک گره نسخه ای را ارائه می دهد که هش آن کمتر از هدف است (در حال حاضر حدود 2192 ). با این حال، این الگوریتم استخراج در برابر دو شکل از تمرکزگرایی آسیب پذیر است. اول، اکوسیستم ماینینگ تحت تسلط ASIC ها (مدارهای مجتمع ویژه برنامه)، تراشه های کامپیوتری طراحی شده و در نتیجه هزاران بار کارآمدتر در وظایف خاص استخراج بیتکوین قرار گرفته است. این به این معنی است که استخراج بیتکوین دیگر یک پیگیری بسیار غیرمتمرکز و برابری طلبانه نیست و برای مشارکت موثر در آن به میلیون ها دلار سرمایه نیاز دارد. دوم، اکثر ماینرهای بیتکوین در واقع اعتبارسنج بلوک را به صورت محلی انجام نمی دهند. در عوض، آنها به یک استخر استخراج متمرکز برای ارائه هدرهای بلوک متکی هستند. این مشکل مسلماً بدتر است: تا زمان نگارش این مقاله، سه استخر استخراج برتر به طور غیرمستقیم تقریباً 50 درصد از قدرت پردازش در شبکه بیتکوین را کنترل میکنند، اگر چه اگر یک استخر یا ائتلاف حمله ای 51 درصدی انجام دهد، این امر با این واقعیت کاهش می یابد که ماینرها می توانند به استخرهای استخراج دیگر روی آورند.
+
+هدف فعلی اتریوم استفاده از یک الگوریتم استخراج است که در آن ماینرها باید دادههای تصادفی را از حالت واکشی کنند، برخی از تراکنشهای انتخابی تصادفی را از آخرین N بلوک در بلاکچین محاسبه کنند و هش نتیجه را برگردانند. این امر دو فایده مهم دارد. اول، قراردادهای اتریوم می توانند شامل هر نوع محاسباتی باشند، بنابراین یک ASIC اتریوم اساساً یک ASIC برای محاسبات عمومی خواهد بود - یعنی CPU بهتر. دوم، ماینینگ نیاز به دسترسی به کل بلاک چین دارد و ماینرها را مجبور می کند کل بلاکچین را ذخیره کنند و حداقل بتوانند هر تراکنش را تأیید کنند. این امر نیاز به استخرهای استخراج متمرکز را از بین می برد. اگرچه استخرهای ماینینگ همچنان میتوانند نقش مشروع توزیع تصادفی پاداش را ایفا کنند، این عملکرد میتواند به همان اندازه توسط استخرهای همتا به همتا و بدون کنترل مرکزی انجام شود.
+
+این مدل آزمایش نشده است و ممکن است هنگام استفاده از اجرای قرارداد به عنوان یک الگوریتم استخراج، مشکلاتی در اجتناب از بهینهسازی های هوشمندانه وجود داشته باشد. با این حال، یکی از ویژگیهای جالب توجه این الگوریتم این است که به هر کسی اجازه میدهد «در چاه آب سم بریزد»، با وارد کردن تعداد زیادی قرارداد به بلاکچینی که بهطور خاص برای جلوگیری از ASICهای خاص طراحی شدهاند. انگیزه های اقتصادی برای سازندگان ASIC وجود دارد تا از چنین ترفندی برای حمله به یکدیگر استفاده کنند. بنابراین، راه حلی که ما در حال توسعه آن هستیم، در نهایت یک راه حل اقتصادی سازگار انسانی است تا صرفاً فنی.
+
+
+
+### قابل مقیاس {#scalability}
+
+یکی از نگرانیهای رایج در مورد اتریوم مسئله مقیاسپذیری است. مانند بیتکوین، اتریوم نیز از این نقص رنج میبرد که هر تراکنش باید توسط هر گره یا نود در شبکه پردازش شود. با بیتکوین، اندازه بلاکچین فعلی در حدود 15 گیگابایت است که حدود 1 مگابایت در ساعت افزایش مییابد. اگر شبکه بیتکوین 2000 تراکنش ویزا را در ثانیه پردازش کند، 1 مگابایت در هر سه ثانیه (1 گیگابایت در ساعت، 8 ترابایت در سال) رشد میکند. اتریوم احتمالاً از الگوی رشد مشابهی رنج میبرد، که با این واقعیت بدتر شده است که برنامههای کاربردی زیادی بر روی بستر بلاکچین اتریوم به جای ارز مانند بیتکوین وجود خواهد داشت، اما با این واقعیت که گره های کامل اتریوم به جای کل تاریخچه بلاکچین، فقط وضعیت را ذخیره می کنند، بهبود یافته است.
+
+مشکل چنین اندازه بلاکچین بزرگی، ریسک تمرکزگرایی است. اگر اندازه بلاکچین به مثلاً 100 ترابایت افزایش یابد، سناریوی محتمل این خواهد بود که تنها تعداد بسیار کمی از کسبوکارهای بزرگ گرههای کامل را اجرا کنند و همه کاربران عادی از گرههای SPV سبک استفاده کنند. در چنین شرایطی، این نگرانی وجود دارد که گره یا نودهای کامل میتوانند به یکدیگر متصل شوند و همه توافق کنند که به شیوهای سودآور تقلب کنند (مثلاً پاداش بلوک را تغییر دهند، به خود بیتکوین بدهند). گره های سبک هیچ راهی برای تشخیص فوری این موضوع ندارند. البته، حداقل یک گره کامل صادقانه احتمالا وجود خواهد داشت، و پس از چند ساعت اطلاعات مربوط به کلاهبرداری از طریق کانالهایی مانند ردیت منتشر میشود، اما در آن مرحله دیگر خیلی دیر شده است: این ساماندهی بر عهده کاربران عادی است که تلاشی را برای فهرست سیاه بلوک های داده شده سازماندهی کنند، یک مشکل هماهنگی عظیم و احتمالا غیرقابل اجرا در مقیاسی مشابه با انجام یک حمله موفق 51 درصدی. در مورد بیتکوین، این در حال حاضر یک مشکل است، اما یک اصلاح بلاکچینی [پیشنهاد شده توسط پیتر تاد](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) وجود دارد که این مشکل را کاهش می دهد.
+
+در کوتاه مدت، اتریوم از دو استراتژی اضافی برای مقابله با این مشکل استفاده خواهد کرد. اولاً، به دلیل الگوریتمهای استخراج مبتنی بر بلاکچین، حداقل هر ماینر مجبور میشود که یک گره کامل باشد و یک حد پایینتر برای تعداد گرههای کامل ایجاد کند. دوم و مهمتر، با این حال، ما پس از پردازش هر تراکنش، یک ریشه درخت حالت میانی را در بلاکچین قرار می دهیم. حتی اگر اعتبار سنجی بلوک متمرکز باشد، تا زمانی که یک گره یا نود راستیآزمایی صادقانه وجود داشته باشد، مشکل متمرکزسازی را میتوان از طریق یک پروتکل تأیید دور زد. اگر یک ماینر یک بلوک نامعتبر منتشر کند، آن بلوک یا باید بد قالب باشد یا وضعیت `S[n]` نادرست است. از آنجایی که `S[0]` به عنوان صحیح شناخته شده است، باید اولین حالت `S[i]` وجود داشته باشد که در جایی که `S[i-1]> نادرست است 0> صحیح است. گره تأیید کننده شاخص i` را به همراه یک "اثبات عدم اعتبار" شامل زیرمجموعه گره های درخت پاتریشیا که نیاز به پردازش `APPLY(S[i-1],TX[i) را ارائه می کند.]) -> S[i]`. گره ها می توانند از آن گره ها برای اجرای آن قسمت از محاسبات استفاده کنند و ببینند که `S[i]` تولید شده با `S[i]` ارائه شده مطابقت ندارد.
+
+حمله دیگر، پیچیدهتر، شامل ماینرهای مخرب است که بلوکهای ناقص را منتشر میکنند، بنابراین اطلاعات کامل حتی برای تعیین معتبر بودن یا نبودن بلوکها وجود ندارد. راهحل این یک پروتکل پاسخ به چالش است: گرههای تأیید «چالشها» را در قالب شاخصهای تراکنش هدف ایجاد میکنند. و با دریافت یک گره، یک گره نوری، بلوک را تا زمانی که گره دیگری غیرقابل اعتماد است، در نظر می گیرد. چه ماینر یا تایید کننده دیگر، زیرمجموعه ای از گره های پاتریشیا را به عنوان اثبات اعتبار ارائه می دهد.
+
+
+
+## نتيجه گيری {#conclusion}
+
+پروتکل اتریوم در ابتدا به عنوان یک نسخه ارتقا یافته از یک ارز رمزنگاری شده در نظر گرفته شد که ویژگیهای پیشرفتهای مانند سپرده روی بلاکچین، محدودیتهای برداشت، قراردادهای مالی، بازارهای شرط بندی و موارد مشابه را از طریق یک زبان برنامهنویسی بسیار تعمیمیافته ارائه میدهد. پروتکل اتریوم مستقیماً از هیچ یک از برنامهها پشتیبانی نمیکند، اما وجود یک زبان برنامهنویسی کامل تورینگ به این معنی است که از نظر تئوری میتوان قراردادهای دلخواه را برای هر نوع تراکنش یا برنامهای ایجاد کرد. اما آنچه در مورد اتریوم جالبتر است این است که پروتکل اتریوم بسیار فراتر از ارز است. پروتکلهای حول ذخیرهسازی غیرمتمرکز فایل، محاسبات غیرمتمرکز و بازارهای پیشبینی غیرمتمرکز، در میان دهها مفهوم دیگر، پتانسیل افزایش قابلتوجهی کارایی صنعت محاسبات را دارند، و با افزودن برای اولین بار یک لایه اقتصادی، تقویت گسترده ای برای سایر پروتکل های همتا به همتا فراهم می کند. در نهایت، مجموعهای از برنامههای کاربردی نیز وجود دارد که اصلاً ربطی به پول ندارند.
+
+مفهوم یک تابع انتقال حالت دلخواه که توسط پروتکل اتریوم پیاده سازی شده است، یک پلتفرم با پتانسیل منحصر به فرد را فراهم می کند. به جای اینکه اتریوم یک پروتکل بسته و تک منظوره باشد که برای مجموعه ای از برنامه های کاربردی در ذخیره سازی داده ها، قمار یا امور مالی در نظر گرفته شده است، اتریوم از نظر طراحی دارای پایان باز است. و ما معتقدیم که برای خدمت به عنوان یک لایه اساسی برای تعداد بسیار زیادی از پروتکل های مالی و غیر مالی در سال های آینده بسیار مناسب است.
+
+
+
+## یادداشت ها و مطالعه بیشتر {#notes-and-further-reading}
+
+
+
+### یادداشت ها {#notes}
+
+1. یک خواننده آگاه ممکن است متوجه شود که در واقع یک آدرس بیتکوین هش کلید عمومی منحنی بیضوی است و نه خود کلید عمومی. با این حال، در واقع اصطلاحات رمزنگاری کاملاً قانونی است که به هش پابکی (pubkey) به عنوان خود کلید عمومی اشاره شود. این به این دلیل است که رمزنگاری بیتکوین را می توان یک الگوریتم امضای دیجیتال سفارشی در نظر گرفت، که در آن کلید عمومی از هش کلید pubkey ECC تشکیل شده است، امضا شامل کلید pubkey ECC است که با امضای ECC پیوند خورده است. و الگوریتم تأیید شامل بررسی ECC pubkey در امضا در برابر هش ECC pubkey ارائه شده به عنوان کلید عمومی و سپس تأیید امضای ECC در برابر کلید pubkey ECC است.
+2. از نظر فنی، میانه 11 بلوک قبلی.
+3. از نظر داخلی، 2 و "CHARLIE" هر دو اعداد هستند[fn3](#notes)، که دومی در نمایش پایه 256 بیگ ایندین قرار دارد. اعداد می توانند حداقل 0 و حداکثر 2256-1 باشند.
+
+
+
+### اطلاعات بیشتر {#further-reading}
+
+1. [ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)
+2. [دارایی هوشمند](https://en.bitcoin.it/wiki/Smart_Property)
+3. [قراردادهای هوشمند](https://en.bitcoin.it/wiki/Contracts)
+4. [B-money](http://www.weidai.com/bmoney.txt)
+5. [شواهد کار قابل استفاده مجدد](https://nakamotoinstitute.org/finney/rpow/)
+6. [عناوین ملکی را با اختیار مالک تضمین کنید](https://nakamotoinstitute.org/secure-property-titles/)
+7. [برگه سفید بیت کوین](http://bitcoin.org/bitcoin.pdf)
+8. [Namecoin](https://namecoin.org/)
+9. [مثلت زوکو](https://wikipedia.org/wiki/Zooko's_triangle)
+10. [وایت پیپر سکههای رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)
+11. [وایت پیپر مسترکوین](https://github.com/mastercoin-MSC/spec)
+12. [شرکت های مستقل غیرمتمرکز، مجله بیت کوین](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)
+13. [تأیید پرداخت ساده](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)
+14. [درختان مرکل](https://wikipedia.org/wiki/Merkle_tree)
+15. [درختان پاتریشیا](https://wikipedia.org/wiki/Patricia_tree)
+16. [GHOST](https://eprint.iacr.org/2013/881.pdf)
+17. [StorJ و ایجنت های خودمختار، جف گارزیک](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html)
+18. [مایک هرن در مورد املاک هوشمند در جشنواره تورینگ](https://www.youtube.com/watch?v=MVyv4t0OKe4)
+19. [Ethereum RLP](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP)
+20. [درخت مرکل پاتریشیا اتریوم](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree)
+21. [پیتر تاد درباره درختان مرکل](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/)
+
+_برای تاریخچه وایت پیپر، [این ویکی](https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md) را ببینید._
+
+_اتریوم، مانند بسیاری از پروژههای نرمافزاری متنباز و مبتنی بر کامیونیتی، از زمان شروع اولیه خود تکامل یافته است. برای اطلاع از آخرین پیشرفتهای اتریوم و اینکه تغییرات در پروتکل چگونه اعمال میشوند، [این راهنما](/learn/) را توصیه میکنیم._
diff --git a/public/content/translations/fa/zero-knowledge-proofs/index.md b/public/content/translations/fa/zero-knowledge-proofs/index.md
index 1df97ca54b6..cb47fa9a1c9 100644
--- a/public/content/translations/fa/zero-knowledge-proofs/index.md
+++ b/public/content/translations/fa/zero-knowledge-proofs/index.md
@@ -4,93 +4,27 @@ description: یک مقدمه غیرتخصصی درباره اثبات دانش
lang: fa
---
-# اثبات دانش صفر چیست؟ {#what-are-zk-proofs}
+# اثبات های دانش صفر چیست؟ {#what-are-zk-proofs}
اثبات دانش صفر، روشی برای اثبات اعتبار یک گزاره بدون افشای خود گزاره است. «ثابت کننده» طرفی است که تلاش می کند ادعایی را ثابت کند، در حالی که «تایید کننده» مسئولیت تایید آن ادعا را دارد.
اثبات دانش صفر اولین بار در سال 1985 در مقالهای با عنوان [«پیچیدگی دانش سیستمهای اثبات تعاملی»](http://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf) مطرح شد که تعریفی از اثبات دانش صفر ارائه میدهد که امروز به طور گسترده مورد ارجاع قرار میگیرد:
-> یک پروتکل دانش صفر روشی است که به وسیلۀ آن یک طرف (اثباتکننده) میتواند به طرف دیگر (تاییدکننده) ثابت کند که چیزی درست است، بدون این که هیچ اطلاعاتی جز این واقعیت که این عبارت خاص درست است فاش کند.
+> پروتکل دانش صفر روشی است که توسط آن یک طرف (اثبات کننده) **میتواند به طرف دیگر (تأیید کننده)** ثابت کند **که یک چیزی درست است، بدون افشای هیچ اطلاعاتی**، جدا از این واقعیت که این بیانیه خاص درست است یا خیر.
اثباتهای دانش صفر در طول سالیان بهبود یافتهاند و اکنون در چندین اپلیکیشن در دنیای واقعی مورد استفاده قرار میگیرند.
-## چرا به اثبات دانش صفر نیاز داریم؟ {#why-zero-knowledge-proofs-are-important}
-
-اثبات دانش صفر نشاندهندۀ یک پیشرفت چشمگیر در رمزنگاری کاربردی بود، زیرا وعدۀ بهبود امنیت اطلاعات برای افراد را میداد. در نظر بگیرید که چگونه میتوانید ادعای خود (مثلاً «من شهروند کشور X هستم») را به یک طرف دیگر (مثلاً یک ارائهدهندۀ خدمات) اثبات کنید. برای اثبات ادعای خود میبایست «شواهدی» مانند پاسپورت ملی یا گواهینامۀ رانندگی ارائه دهید.
-
-اما این شیوه مشکلاتی دارد، بیش از همه، فقدان حریم خصوصی. زیرا اطلاعات شناسایی شخصی یا بهاختصار PII اشتراکگذاریشده با سرویسهای شخص ثالث، در پایگاههای دادۀ مرکزی ذخیره میشود که در برابر هک آسیبپذیرند. همزمان با اهمیت یافتن سرقت هویت، درخواستها برای ابزارهایی با قابلیت حفاظت بیشتر از حریم خصوصی به هنگام اشتراکگذاری اطلاعات حساس افزایش یافته است.
-
-اثبات دانش صفر با حذف نیاز به افشای اطلاعات برای اثبات اعتبار ادعاها، این مشکل را حل میکند. پروتکل دانش صفر، از گزاره (که «شاهد» نامیده میشود) به عنوان ورودی استفاده میکند تا یک اثبات موجز برای اعتبار آن ایجاد کند. این اثبات، تضمینهای محکمی برای صحت یک گزاره بدون افشای اطلاعات مورد استفاده در ایجاد آن ارائه میدهد.
-
-با رجوع به مثال قبلی، تنها مدرکی که برای اثبات ادعای شهروندی خود نیاز دارید، اثبات دانش صفر است. تاییدکننده تنها میبایست بررسی کند که آیا برخی از ویژگیهای اثبات درست است یا نه تا متقاعد شود که گزارۀ اصلی نیز درست است.
-
-## اثبات دانش صفر چکونه کار میکند؟ {#how-do-zero-knowledge-proofs-work}
-
-اثبات دانش صفر به شما امکان میدهد که صحت یک گزاره را اثبات کنید، بدون اینکه محتوای آن گزاره را به اشتراک بگذارید یا چگونگی کشف حقیقت را فاش کنید. برای ممکن ساختن این امر، پروتکلهای دانش صفر بر الگوریتمهایی تکیه میکنند که برخی دادهها را به عنوان ورودی میگیرند و «درست» یا «نادرست» را به عنوان خروجی برمیگردانند.
-
-یک پروتکل دانش صفر باید معیارهای زیر را برآورده کند:
-
-1. **کامل بودن**: اگر ورودی معتبر باشد، پروتکل دانش صفر همیشه پاسخ «درست» را برمیگرداند. از این رو، اگر گزارۀ اصلی درست باشد و اثباتکننده و تاییدکننده صادقانه عمل کنند، اثبات را میتوان پذیرفت.
-
-2. **صحت:** اگر ورودی نامعتبر باشد، از نظر تئوری غیرممکن است که پروتکل دانش صفر فریب بخورد تا پاسخ «درست» را بازگرداند. از این رو، یک اثباتکنندۀ دروغگو نمیتواند یک تاییدکنندۀ صادق را فریب دهد تا یک گزارۀ نامعتبر را معتبر بداند (مگر با یک احتمال ناچیز).
-
-3. **دانش صفر**: تاییدکننده، چیزی دربارۀ یک گزاره فراتر از اعتبار یا نادرستی آن یاد نمیگیرد (آنها از گزاره، «دانش صفر» دارند). این الزام همچنین مانع میشود که تاییدکننده از طریق اثبات، به ورودی اصلی (محتوای گزاره) دست یابد.
-
-در شکل اولیه، یک اثبات دانش صفر از سه عنصر تشکیل شده است: **شاهد**،**چالش**، و **پاسخ**.
-
-- **شاهد**: با استفاده از اثبات دانش صفر، اثباتکننده میخواهد آگاهی خود از برخی اطلاعات محرمانه را اثبات کند. اطلاعات محرمانه، «شاهد» اثبات است، و آگاهی مفروض اثباتکننده درباره شاهد، مجموعهای از پرسشها را تعیین میکند که تنها از سوی یک طرف مطلع میتواند پاسخ داده شود. بنابراین، اثباتکننده فرایند اثبات را با انتخاب تصادفی یک پرسش، برآورد پاسخ و ارسال آن برای تاییدکننده آغاز میکند.
-
-- **چالش**: تاییدکننده به طور تصادفی پرسش دیگری را از مجموعه انتخاب میکند و از اثباتکننده میخواهد که به آن پاسخ دهد.
-
-- **پاسخ**: اثباتکننده پرسش را میپذیرد، پاسخ را برآورد میکند و به تاییدکننده بازمیگرداند. پاسخ اثباتکننده، به تاییدکننده اجازه میدهد که بررسی کند آیا اولی واقعاً به شاهد دسترسی دارد یا خیر. برای اطمینان از اینکه اثباتکننده حدسهای کورکورانه نمیزند و پاسخهای صحیحش از سر تصادف و شانس نیست، تاییدکننده سؤالهای بیشتری میپرسد. با تکرار چندبارۀ این تعامل تا زمانی که رضایت تاییدکننده جلب شود، احتمال جعل شدن دانش شاهد از سوی اثبات کننده به میزان قابل توجهی کاهش مییابد.
-
-موارد بالا، ساختار یک «اثبات دانش صفر تعاملی» را شرح میدهد. پروتکلهای اولیۀ دانش صفر از اثبات تعاملی استفاده میکردند، طبق این پروتکلها، تایید اعتبار یک گزاره نیازمند ارتباط رفت و برگشتی میان اثباتکنندهها و تاییدکنندهها بود.
-
-یک مثال خوب که نحوۀ کار اثباتهای تعاملی را روشن میکند، داستان معروف [غار علی بابا](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave) از ژان ژاک کویسکوتر است. در این داستان، پگی (اثباتکننده) میخواهد بدون فاش کردن عبارت رمز، به ویکتور (تاییدکننده) ثابت کند که آن عبارت را میداند تا دری جادویی را باز کند.
-
-### اثبات دانش صفر غیرتعاملی {#non-interactive-zero-knowledge-proofs}
-
-هرچند اثبات تعاملی یک انقلاب محسوب میشد، اما کارایی چندانی نداشت، زیرا مستلزم این بود که دو طرف در دسترس باشند و به طور مکرر با هم تعامل داشته باشند. حتی اگر یک تاییدکننده به صداقت یک اثباتکننده اعتقاد داشته باشد، اثبات برای تایید مستقل در دسترس نخواهد بود (محاسبۀ یک اثبات جدید نیازمند مجموعۀ جدیدی از پیامها بین اثباتکننده و تاییدکننده است).
-
-برای حل این مشکل، مانوئل بلوم، پل فلدمن و سیلویو میکالی اولین [اثباتهای دانش صفر غیرتعاملی](https://dl.acm.org/doi/10.1145/62212.62222) را پیشنهاد کردند که در آن اثباتکننده و تاییدکننده یک کلید مشترک دارند. این کلید اجازه میدهد که اثباتکننده دانش خود از برخی اطلاعات (به عنوان مثال شاهد) را بدون ارائۀ خود اطلاعات اثبات کند.
-
-برخلاف اثباتهای تعاملی، اثباتهای غیرتعاملی فقط به یک دور ارتباط بین شرکتکنندگان (اثباتکننده و تاییدکننده) نیاز دارند. اثباتکننده، برای محاسبۀ اثبات دانش صفر، اطلاعات محرمانه را به یک الگوریتم ویژه میفرستد. این اثبات برای تاییدکننده ارسال میشود، و تاییدکننده با استفاده از الگوریتم دیگری بررسی میکند که آیا اثباتکننده اطلاعات محرمانه را میداند یا خیر.
-
-اثبات غیرتعاملی، ارتباط بین اثباتکننده و تاییدکننده را کاهش میدهد و اثباتکنندههای دانش صفر را کارآمدتر میکند. علاوه بر آن، بهمحض تولید هر اثبات، برای تایید اشخاص دیگر (به شرط داشتن کلید مشترک و الگوریتم تایید) در دسترس است.
-
-اثبات غیرتعاملی پیشرفتی برای فناوری دانش صفر محسوب میشد و باعث توسعۀ سیستمهای اثبات مورد استفادۀ امروزی شد. در زیر به معرفی انواع آن میپردازیم:
-
-### انواع اثبات دانش صفر {#types-of-zero-knowledge-proofs}
+
-#### ZK-SNARKs {#zk-snarks}
-
-ZK-SNARK مخفف عبارت **Zero-Knowledge Succinct Non-Interactive Argument of Knowledge** است. پروتکل ZK-SNARK دارای ویژگیهای زیر است:
-
-- **دانش صفر**: یک تاییدکننده میتواند یکپارچگی یک گزاره را بدون دانستن چیز دیگری در مورد آن گزاره تایید کند. تنها دانش تاییدکننده از گزاره، درست یا نادرست بودن آن است.
-
-- **موجز**: اثبات دانش صفر کوچکتر از شاهد، و بهسرعت قابل تایید است.
-
-- **غیرتعاملی**: اثبات «غیرتعاملی» است، زیرا اثباتکننده و تاییدکننده فقط یک دور باهم تعامل دارند، برخلاف اثباتهای تعاملی که به چندین دور ارتباط نیاز دارند.
-
-- **استدلال**: اثبات، شرط «صحت» را برآورده میکند، بنابراین تقلب بسیار بعید است.
-
-- **(از) دانش**: اثبات دانش صفر بدون دسترسی به اطلاعات محرمانه (شاهد) قابل ساخت نیست. برای اثباتکنندهای که شاهد ندارد، اگر نگوییم غیرممکن، اما دشوار است که یک اثبات دانش صفر معتبر را محاسبه کند.
-
-«کلید مشترک» که قبلاً به آن اشاره کردیم، به پارامترهای عمومی اشاره دارد که اثباتکننده و تاییدکننده توافق میکنند از آنها در تولید و تایید شواهد استفاده کنند. تولید پارامترهای عمومی (که در مجموع، به عنوان رشتۀ مرجع مشترک یا بهاختصار CRS شناخته میشود) به دلیل اهمیت آن در امنیت پروتکل، یک عملیات حساس است. اگر آنتروپی (تصادفی بودن) مورد استفاده در تولید CRS به دست یک اثباتکنندۀ نااهل بیفتد، ممکن است اثباتهای تقلبی را محاسبه کنند.
-
-[محاسبات چندجانبه که بهاختصار MPC گفته میشود](https://en.wikipedia.org/wiki/Secure_multi-party_computation)، راهی برای کاهش ریسک در تولید پارامترهای عمومی است. در این نوع محاسبات، چندین طرف در یک [مراسم راهاندازی مورد اعتماد](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) شرکت میکنند، که در آن هر فرد مقادیری تصادفی برای تولید CRS ارائه میکند. تا زمانی که یک طرف صادق بخشی از آنتروپی خود را از بین ببرد، پروتکل ZK-SNARK سلامت محاسباتی را حفظ میکند.
-
-راهاندازیهای مورد اعتماد، کاربران را ملزم میکنند در تولید پارامتر به شرکتکنندگان اعتماد کنند. با این حال، توسعۀ ZK-STARKs پروتکلهای اثباتی را فعال کرده است که با یک راهاندازی غیرمعتمد کار میکنند.
-
-#### ZK-STARKs {#zk-starks}
+## چرا به اثبات دانش صفر نیاز داریم؟ {#why-zero-knowledge-proofs-are-important}
-ZK-STARK مخفف عبارت **Zero-Knowledge Scalable Transparent Argument of Knowledge** است. ZK-STARKها مشابه ZK-SNARKها هستند، با این تفاوت که ویژگیهای زیر را دارند:
+اثبات دانش صفر نشاندهندۀ یک پیشرفت چشمگیر در رمزنگاری کاربردی بود، زیرا وعدۀ بهبود امنیت اطلاعات برای افراد را میداد. در نظر بگیرید که چگونه میتوانید ادعای خود (مثلاً «من شهروند کشور X هستم») را به یک طرف دیگر (مثلاً یک ارائهدهندۀ خدمات) اثبات کنید. برای اثبات ادعای خود باید «شواهدی» مانند پاسپورت ملی یا گواهینامۀ رانندگی ارائه دهید.
-- **مقیاسپذیر**: در مواقعی که اندازۀ شاهد بزرگتر است، ZK-STARK در ایجاد و تایید مدارک، سریعتر از ZK-SNARK عمل میکند. با بزرگتر شدن شاهد، زمان مورد نیاز برای اثبات و تایید توسط اثباتهای STARK تنها اندکی افزایش پیدا میکند (زمانهای اثباتکننده و تاییدکنندۀ SNARK با افزایش اندازۀ شاهد به صورت خطی افزایش مییابند).
+اما این شیوه مشکلاتی دارد، بیش از همه، فقدان حریم خصوصی. زیرا اطلاعات شناسایی شخصی (PII) اشتراکگذاریشده با سرویسهای طرف ثالث، در پایگاههای دادۀ مرکزی ذخیره میشود که در برابر هک آسیبپذیرند. همزمان با اهمیت یافتن سرقت هویت، درخواستها برای ابزارهایی با قابلیت حفاظت بیشتر از حریم خصوصی به هنگام اشتراکگذاری اطلاعات حساس افزایش یافته است.
-- **شفاف**: برای ایجاد پارامترهای عمومی به منظور اثبات و تایید، ZK-STARK به جای اینکه به راهاندازی مورد اعتماد متکی باشد، به تصادف قابل تایید عمومی متکی است. بنابراین، در مقایسه با ZK-SNARK شفافتر هستند.
+اثباتهای دانش صفر این مشکل را با **حذف نیاز به افشای اطلاعات برای اثبات اعتبار ادعاها** حل میکنند. پروتکل دانش صفر، از گزاره (که «شاهد» نامیده میشود) به عنوان ورودی استفاده میکند تا یک اثبات موجز برای اعتبار آن ایجاد کند. این اثبات، تضمینهای محکمی برای صحت یک گزاره بدون افشای اطلاعات مورد استفاده در ایجاد آن ارائه میدهد.
-ZK-STARKها، نسبت به ZK-SNARKها اثباتهای بزرگتری تولید میکنند، به این معنی که معمولاً منابع/هزینۀ بیشتری برای تایید نیاز دارند. با این حال، ممکن است در برخی موارد (مانند اثبات مجموعه دادههای بزرگ)، ZK-STARK نسبت به ZK-SNARK مقرونبهصرفهتر باشد.
+با رجوع به مثال قبلی، تنها مدرکی که برای اثبات ادعای شهروندی خود نیاز دارید، اثبات دانش صفر است. تاییدکننده تنها باید بررسی کند که آیا برخی از ویژگیهای اثبات درست است یا نه تا متقاعد شود که گزارۀ اصلی نیز درست است.
## موارد استفادۀ اثبات دانش صفر {#use-cases-for-zero-knowledge-proofs}
@@ -102,9 +36,9 @@ ZK-STARKها، نسبت به ZK-SNARKها اثباتهای بزرگتری
«سکههای حریم خصوصی» خاصی وجود دارد که برای تراکنشهای کاملاً ناشناس طراحی شدهاند. بلاکچینهای متمرکز بر حریم خصوصی، مانند Zcash و Monero، از جزئیات تراکنش، از جمله آدرسهای فرستنده/گیرنده، نوع دارایی، مقدار، و جدول زمانی تراکنش محافظت میکنند.
-شبکههای بلاکچین متمرکز بر حریم خصوصی با استفاده از فناوری دانش صفر در پروتکل، به گرهها اجازه میدهند تا تراکنشها را بدون نیاز به دسترسی به دادههای تراکنش تایید کنند.
+با استفاده از فناوری دانش صفر در پروتکل، شبکههای [بلاکچین](/glossary/#blockchain) متمرکز بر حریم خصوصی به [گرهها](/glossary/#node) اجازه میدهند تراکنشها را بدون نیاز به دسترسی به دادههای تراکنش تأیید کنند.
-اثبات دانش صفر همچنین برای ناشناس کردن تراکنشها در بلاکچینهای عمومی استفاده میشود. به عنوان مثال، Tornado Cash یک سرویس غیرمتمرکز و غیرسرپرستی است که به کاربران اجازه میدهد تا تراکنشهای محرمانه را در اتریوم انجام دهند. Tornado Cash از اثبات دانش صفر برای مخفی کردن جزئیات تراکنش و تضمین حریم خصوصی مالی استفاده میکند. متأسفانه، به این دلیل که ابزارهای حفظ حریم خصوصی «انتخابی» هستند، با فعالیتهای غیرقانونی همراهند. برای غلبه بر این امر، حریم خصوصی در نهایت باید به پیشفرض در بلاکچینهای عمومی تبدیل شود.
+**شواهد دانش صفر نیز برای ناشناس کردن تراکنشها در بلاکچینهای عمومی اعمال میشوند**. به عنوان مثال، Tornado Cash یک سرویس غیرمتمرکز و غیرسرپرستی است که به کاربران اجازه میدهد تا تراکنشهای محرمانه را در اتریوم انجام دهند. Tornado Cash از اثبات دانش صفر برای مخفی کردن جزئیات تراکنش و تضمین حریم خصوصی مالی استفاده میکند. متأسفانه، به این دلیل که ابزارهای حفظ حریم خصوصی «انتخابی» هستند، با فعالیتهای غیرقانونی همراهند. برای غلبه بر این امر، حریم خصوصی در نهایت باید به پیشفرض در بلاکچینهای عمومی تبدیل شود.
### حفاظت از هویت {#identity-protection}
@@ -122,7 +56,7 @@ ZK-STARKها، نسبت به ZK-SNARKها اثباتهای بزرگتری
محاسبات قابل تایید یکی دیگر از کاربردهای فناوری اثبات دانش صفر برای بهبود طرحهای بلاکچین است. محاسبه قابل تایید به ما امکان میدهد ضمن حفظ نتایج قابل تایید، محاسبات را به نهاد دیگری برونسپاری کنیم. آن نهاد نتیجه را همراه با اثباتی که تایید میکند برنامه بهدرستی اجرا شده است، ارسال میکند.
-اهمیت اساسی محاسبه قابل تایید، در بهبود سرعت پردازش بلاکچینها بدون کاهش امنیت است. درک این موضوع مستلزم دانستن تفاوتهای راهحلهای پیشنهادی برای مقیاسپذیری اتریوم است.
+محاسبه قابل تأیید **برای بهبود سرعت پردازش در بلاکچینها** بدون کاهش امنیت بسیار مهم است. درک این موضوع مستلزم دانستن تفاوتهای راهحلهای پیشنهادی برای مقیاسپذیری اتریوم است.
[راهحلهای مقیاسپذیری آنچین](/developers/docs/scaling/#on-chain-scaling)، مانند شاردینگ، نیاز به اصلاح گستردۀ لایۀ پایۀ بلاکچین دارند. با این حال، این رویکرد بسیار پیچیده است و اشتباهات در پیادهسازی میتواند مدل امنیتی اتریوم را تضعیف کند.
@@ -174,39 +108,107 @@ ZK-STARKها، نسبت به ZK-SNARKها اثباتهای بزرگتری
استفاده از MACI نیازمند اعتماد به هماهنگکننده مبنی بر تبانی نکردن با رشوهدهندگان یا تلاش برای رشوه دادن رایدهندگان از سوی او است. هماهنگکننده میتواند پیامهای کاربران را رمزگشایی کند (برای ایجاد اثبات لازم است)، بنابراین آنها میتوانند نحوۀ رای دادن هر فرد را به طور دقیق تایید کنند.
-اما در مواردی که هماهنگکننده صادق است، MACI ابزاری قدرتمند برای تضمین سلامت رایگیری آنچین است. این امر بیانکنندۀ دلیل محبوبیت آن در میان برنامههای تامین مالی ثانویه (مانند [clr.fund](https://clr.fund/#/about/maci)) است که بهشدت بر صحت آرای تکتک افراد متکی است.
+اما در مواردی که هماهنگکننده صادق است، MACI ابزاری قدرتمند برای تضمین سلامت رایگیری آنچین است. این امر بیانکنندۀ دلیل محبوبیت آن در میان برنامههای تامین مالی ثانویه (مانند [↗clr.fund](https://clr.fund/#/about/maci)) است که بهشدت بر صحت آرای تکتک افراد متکی است.
-[درباره MACI بیشتر بیاموزید](https://github.com/privacy-scaling-explorations/maci/blob/master/specs/01_introduction.md).
+[درباره MACI بیشتر بدانید](https://privacy-scaling-explorations.github.io/maci/).
+
+## اثبات دانش صفر چگونه کار میکند؟ {#how-do-zero-knowledge-proofs-work}
+
+اثبات دانش صفر به شما امکان میدهد که صحت یک گزاره را اثبات کنید، بدون اینکه محتوای آن گزاره را به اشتراک بگذارید یا چگونگی کشف حقیقت را فاش کنید. برای ممکن ساختن این امر، پروتکلهای دانش صفر بر الگوریتمهایی تکیه میکنند که برخی دادهها را به عنوان ورودی میگیرند و «درست» یا «نادرست» را به عنوان خروجی برمیگردانند.
+
+یک پروتکل دانش صفر باید معیارهای زیر را برآورده کند:
+
+1. **کامل بودن**: اگر ورودی معتبر باشد، پروتکل دانش صفر همیشه پاسخ «درست» را برمیگرداند. از این رو، اگر گزارۀ اصلی درست باشد و اثباتکننده و تاییدکننده صادقانه عمل کنند، اثبات را میتوان پذیرفت.
+
+2. **صحت:** اگر ورودی نامعتبر باشد، از نظر تئوری غیرممکن است که پروتکل دانش صفر فریب بخورد تا پاسخ «درست» را بازگرداند. از این رو، یک اثباتکنندۀ دروغگو نمیتواند یک تاییدکنندۀ صادق را فریب دهد تا یک گزارۀ نامعتبر را معتبر بداند (مگر با یک احتمال ناچیز).
+
+3. **دانش صفر**: تاییدکننده، چیزی دربارۀ یک گزاره فراتر از اعتبار یا نادرستی آن یاد نمیگیرد (آنها از گزاره، «دانش صفر» دارند). این الزام همچنین مانع میشود که تاییدکننده از طریق اثبات، به ورودی اصلی (محتوای گزاره) دست یابد.
+
+در شکل اولیه، یک اثبات دانش صفر از سه عنصر تشکیل شده است: **شاهد**،**چالش**، و **پاسخ**.
+
+- **شاهد**: با استفاده از اثبات دانش صفر، اثباتکننده میخواهد آگاهی خود از برخی اطلاعات محرمانه را اثبات کند. اطلاعات محرمانه، «شاهد» اثبات است، و آگاهی مفروض اثباتکننده درباره شاهد، مجموعهای از پرسشها را تعیین میکند که تنها از سوی یک طرف مطلع میتواند پاسخ داده شود. بنابراین، اثباتکننده فرایند اثبات را با انتخاب تصادفی یک پرسش، برآورد پاسخ و ارسال آن برای تاییدکننده آغاز میکند.
+
+- **چالش**: تاییدکننده به طور تصادفی پرسش دیگری را از مجموعه انتخاب میکند و از اثباتکننده میخواهد که به آن پاسخ دهد.
+
+- **پاسخ**: اثباتکننده پرسش را میپذیرد، پاسخ را برآورد میکند و به تاییدکننده بازمیگرداند. پاسخ اثباتکننده، به تاییدکننده اجازه میدهد که بررسی کند آیا اولی واقعاً به شاهد دسترسی دارد یا خیر. برای اطمینان از اینکه اثباتکننده حدسهای کورکورانه نمیزند و پاسخهای صحیحش از سر تصادف و شانس نیست، تاییدکننده سؤالهای بیشتری میپرسد. با تکرار چندبارۀ این تعامل تا زمانی که رضایت تاییدکننده جلب شود، احتمال جعل شدن دانش شاهد از سوی اثبات کننده به میزان قابل توجهی کاهش مییابد.
+
+موارد بالا، ساختار یک «اثبات دانش صفر تعاملی» را شرح میدهد. پروتکلهای اولیۀ دانش صفر از اثبات تعاملی استفاده میکردند، طبق این پروتکلها، تایید اعتبار یک گزاره نیازمند ارتباط رفت و برگشتی میان اثباتکنندهها و تاییدکنندهها بود.
+
+یک مثال خوب که نحوۀ کار اثباتهای تعاملی را روشن میکند، داستان معروف [غار علی بابا](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave) از ژان ژاک کویسکوتر است. در این داستان، پگی (اثباتکننده) میخواهد بدون فاش کردن عبارت رمز، به ویکتور (تاییدکننده) ثابت کند که آن عبارت را میداند تا دری جادویی را باز کند.
+
+### اثبات دانش صفر غیرتعاملی {#non-interactive-zero-knowledge-proofs}
+
+هرچند اثبات تعاملی یک انقلاب محسوب میشد، اما کارایی چندانی نداشت، زیرا مستلزم این بود که دو طرف در دسترس باشند و به طور مکرر با هم تعامل داشته باشند. حتی اگر یک تاییدکننده به صداقت یک اثباتکننده اعتقاد داشته باشد، اثبات برای تایید مستقل در دسترس نخواهد بود (محاسبۀ یک اثبات جدید نیازمند مجموعۀ جدیدی از پیامها بین اثباتکننده و تاییدکننده است).
+
+برای حل این مشکل، مانوئل بلوم، پل فلدمن و سیلویو میکالی اولین [اثباتهای دانش صفر غیرتعاملی](https://dl.acm.org/doi/10.1145/62212.62222) را پیشنهاد کردند که در آن اثباتکننده و تاییدکننده یک کلید مشترک دارند. این کلید اجازه میدهد که اثباتکننده دانش خود از برخی اطلاعات (به عنوان مثال شاهد) را بدون ارائۀ خود اطلاعات اثبات کند.
+
+برخلاف اثباتهای تعاملی، اثباتهای غیرتعاملی فقط به یک دور ارتباط بین شرکتکنندگان (اثباتکننده و تاییدکننده) نیاز دارند. اثباتکننده، برای محاسبۀ اثبات دانش صفر، اطلاعات محرمانه را به یک الگوریتم ویژه میفرستد. این اثبات برای تاییدکننده ارسال میشود، و تاییدکننده با استفاده از الگوریتم دیگری بررسی میکند که آیا اثباتکننده اطلاعات محرمانه را میداند یا خیر.
+
+اثبات غیرتعاملی، ارتباط بین اثباتکننده و تاییدکننده را کاهش میدهد و اثباتکنندههای دانش صفر را کارآمدتر میکند. علاوه بر آن، بهمحض تولید هر اثبات، برای تایید اشخاص دیگر (به شرط داشتن کلید مشترک و الگوریتم تایید) در دسترس است.
+
+اثبات غیرتعاملی پیشرفتی برای فناوری دانش صفر محسوب میشد و باعث توسعۀ سیستمهای اثبات مورد استفادۀ امروزی شد. در زیر به معرفی انواع آن میپردازیم:
+
+### انواع اثبات دانش صفر {#types-of-zero-knowledge-proofs}
+
+#### اسنارکهای دانش-صفر {#zk-snarks}
+
+ZK-SNARK مخفف عبارت **Zero-Knowledge Succinct Non-Interactive Argument of Knowledge** است. پروتکل ZK-SNARK دارای ویژگیهای زیر است:
+
+- **دانش صفر**: یک تاییدکننده میتواند یکپارچگی یک گزاره را بدون دانستن چیز دیگری در مورد آن گزاره تایید کند. تنها دانش تاییدکننده از گزاره، درست یا نادرست بودن آن است.
+
+- **موجز**: اثبات دانش صفر کوچکتر از شاهد، و بهسرعت قابل تایید است.
+
+- **غیرتعاملی**: اثبات «غیرتعاملی» است، زیرا اثباتکننده و تاییدکننده فقط یک دور باهم تعامل دارند، برخلاف اثباتهای تعاملی که به چندین دور ارتباط نیاز دارند.
+
+- **استدلال**: اثبات، شرط «صحت» را برآورده میکند، بنابراین تقلب بسیار بعید است.
+
+- **(از) دانش**: اثبات دانش صفر بدون دسترسی به اطلاعات محرمانه (شاهد) قابل ساخت نیست. برای اثباتکنندهای که شاهد ندارد، اگر نگوییم غیرممکن، اما دشوار است که یک اثبات دانش صفر معتبر را محاسبه کند.
+
+«کلید مشترک» که قبلاً به آن اشاره کردیم، به پارامترهای عمومی اشاره دارد که اثباتکننده و تاییدکننده توافق میکنند از آنها در تولید و تایید شواهد استفاده کنند. تولید پارامترهای عمومی (که در مجموع، به عنوان رشتۀ مرجع مشترک یا بهاختصار CRS شناخته میشود) به دلیل اهمیت آن در امنیت پروتکل، یک عملیات حساس است. اگر آنتروپی (تصادفی بودن) مورد استفاده در تولید CRS به دست یک اثباتکنندۀ نااهل بیفتد، ممکن است اثباتهای تقلبی را محاسبه کنند.
+
+[محاسبات چندجانبه که بهاختصار MPC گفته میشود](https://en.wikipedia.org/wiki/Secure_multi-party_computation)، راهی برای کاهش ریسک در تولید پارامترهای عمومی است. در این نوع محاسبات، چندین طرف در یک [مراسم راهاندازی مورد اعتماد](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) شرکت میکنند، که در آن هر فرد مقادیری تصادفی برای تولید CRS ارائه میکند. تا زمانی که یک طرف صادق بخشی از آنتروپی خود را از بین ببرد، پروتکل ZK-SNARK سلامت محاسباتی را حفظ میکند.
+
+راهاندازیهای مورد اعتماد، کاربران را ملزم میکنند در تولید پارامتر به شرکتکنندگان اعتماد کنند. با این حال، توسعۀ ZK-STARKs پروتکلهای اثباتی را فعال کرده است که با یک راهاندازی غیرمعتمد کار میکنند.
+
+#### استارکهای دانش-صفر {#zk-starks}
+
+ZK-STARK مخفف عبارت **Zero-Knowledge Scalable Transparent Argument of Knowledge** است. ZK-STARKها مشابه ZK-SNARKها هستند، با این تفاوت که ویژگیهای زیر را دارند:
+
+- **مقیاسپذیر**: در مواقعی که اندازۀ شاهد بزرگتر است، ZK-STARK در ایجاد و تایید مدارک، سریعتر از ZK-SNARK عمل میکند. با بزرگتر شدن شاهد، زمان مورد نیاز برای اثبات و تایید توسط اثباتهای STARK تنها اندکی افزایش پیدا میکند (زمانهای اثباتکننده و تاییدکنندۀ SNARK با افزایش اندازۀ شاهد به صورت خطی افزایش مییابند).
+
+- **شفاف**: برای ایجاد پارامترهای عمومی به منظور اثبات و تایید، ZK-STARK به جای اینکه به راهاندازی مورد اعتماد متکی باشد، به تصادف قابل تایید عمومی متکی است. بنابراین، در مقایسه با ZK-SNARK شفافتر هستند.
+
+ZK-STARKها، نسبت به ZK-SNARKها اثباتهای بزرگتری تولید میکنند، به این معنی که معمولاً منابع/هزینۀ بیشتری برای تایید نیاز دارند. با این حال، ممکن است در برخی موارد (مانند اثبات مجموعه دادههای بزرگ)، ZK-STARK نسبت به ZK-SNARK مقرونبهصرفهتر باشد.
## معایب استفاده از اثبات دانش صفر {#drawbacks-of-using-zero-knowledge-proofs}
### هزینههای سختافزاری {#hardware-costs}
-تولید اثباتهای دانش صفر شامل محاسبات بسیار پیچیدهای است که تنها در ماشینهای تخصصی به بهترین وجه انجام میشود. از آنجایی که این ماشینها گرانقیمتاند، اغلب در دسترس افراد عادی نیستند. بهعلاوه، برنامههایی که میخواهند از فناوری دانش صفر استفاده کنند، میبایست هزینههای سختافزاری را لحاظ کنند، که احتمال دارد باعث افزایش هزینهها برای کاربران نهایی شود.
+تولید اثباتهای دانش صفر شامل محاسبات بسیار پیچیدهای است که تنها در ماشینهای تخصصی به بهترین وجه انجام میشود. از آنجا که این ماشینها گرانقیمتاند، اغلب در دسترس افراد عادی نیستند. بهعلاوه، برنامههایی که میخواهند از فناوری دانش صفر استفاده کنند، میبایست هزینههای سختافزاری را لحاظ کنند، که احتمال دارد باعث افزایش هزینهها برای کاربران نهایی شود.
### هزینههای تایید اثبات {#proof-verification-costs}
-تایید اثباتها همچنین نیازمند محاسبه پیچیده است و هزینههای پیادهسازی فناوری دانش صفر در برنامهها را افزایش میدهد. این هزینه بهویژه در زمینۀ اثبات محاسبه است. به عنوان مثال، رولآپهای ZK برای تایید یک اثبات ZK-SNARK در اتریوم حدود 500000 گس هزینه برمیدارد و هزینههای ZK-STARKها از این رقم هم بالاتر است.
+تایید اثباتها همچنین نیازمند محاسبه پیچیده است و هزینههای پیادهسازی فناوری دانش صفر در برنامهها را افزایش میدهد. این هزینه بهویژه در زمینۀ اثبات محاسبه متناسب است. به عنوان مثال، رولآپهای ZK برای تایید یک اثبات ZK-SNARK در اتریوم حدود 500000 گس هزینه برمیدارد و هزینههای ZK-STARKها از این رقم هم بالاتر است.
### مفروضات اعتماد {#trust-assumptions}
-در ZK-SNARK، رشته مرجع مشترک (Common Reference String) یا همان پارامترهای عمومی، یک بار تولید میشود و از آن پس، برای استفادۀ طرفهایی که مایل به شرکت در پروتکل دانش صفر هستند در دسترس خواهند بود. پارامترهای عمومی از طریق یک مراسم راهاندازی مورد اعتماد ایجاد میشوند، که در آن شرکتکنندگان مورد اعتمادند.
+در ZK-SNARK، رشته مرجع مشترک (Common Reference String) یا همان پارامترهای عمومی، یک بار تولید میشود و از آن پس، برای استفادۀ طرفهایی که مایل به شرکت در پروتکل دانش صفر هستند در دسترس خواهد بود. پارامترهای عمومی از طریق یک مراسم راهاندازی مورد اعتماد ایجاد میشوند، که در آن شرکتکنندگان مورد اعتمادند.
-اما در واقع، هیچ راهی برای کاربران وجود ندارد تا صداقت شرکا را ارزیابی کنند و آنها ناگزیدند به قول توسعهدهندگان اطمینان کنند. اما ZK-STARKها نیازی به مفروضات اعتماد ندارند زیرا تصادفی بودن استفادهشده در تولید رشته (استرینگ) به طور عمومی قابل تایید است. در همین حال، محققان در حال کار بر روی راهاندازی بدون اعتماد برای ZK-SNARKها هستند تا امنیت مکانیسمهای اثبات را افزایش دهند.
+اما در واقع، هیچ راهی برای کاربران وجود ندارد تا صداقت شرکا را ارزیابی کنند و آنها ناگزیدند به قول توسعهدهندگان اطمینان کنند. اما ZK-STARKها نیازی به مفروضات اعتماد ندارند زیرا تصادفی بودن استفاده شده در تولید رشته به طور عمومی قابل تایید است. در همین حال، محققان در حال کار بر روی راهاندازی بدون اعتماد برای ZK-SNARKها هستند تا امنیت مکانیسمهای اثبات را افزایش دهند.
### تهدیدات محاسبات کوانتومی {#quantum-computing-threats}
-ZK-SNARK از الگوریتمهای رمزنگاری انحنای بیضوی ([ECDSA](/glossary/#ecdsa)) برای رمزگذاری استفاده میکند. هرچند الگوریتم ECDSA در حال حاضر امن است، توسعۀ رایانههای کوانتومی میتواند مدل امنیتی آن را در آینده با شکست مواجه کند.
+ZK-SNARK از رمزنگاری منحنی بیضوی برای رمزگذاری استفاده میکند. در حالی که فرض میشود مشکل لگاریتم گسسته منحنی بیضوی در حال حاضر غیرقابل حل است، توسعه رایانههای کوانتومی میتواند این مدل امنیتی را در آینده شکست دهد.
-ZK-STARK در برابر تهدید محاسبه کوانتومی مصون در نظر گرفته می شود، زیرا برای رمزگذاری از هشهای مقاوم در برابر برخورد استفاده میکند. برخلاف جفت کلیدهای عمومی-خصوصی که در رمزنگاری انحنای بیضوی استفاده میشوند، شکستن هش مقاوم در برابر برخورد، برای الگوریتمهای محاسبات کوانتومی دشوارتر است.
+ZK-STARK در مقابل تهدید محاسبات کوانتومی مصون در نظر گرفته میشود، زیرا برای امنیت خود فقط به توابع هش ضدتصادم متکی است. برخلاف جفت کلیدهای عمومی-خصوصی که در رمزنگاری منحنی بیضوی استفاده میشوند، شکستن هش مقاوم در برابر تصادم، برای الگوریتمهای محاسبات کوانتومی دشوارتر است.
## بیشتر بخوانید {#further-reading}
-- [دانشمند کامپیوتر یک مفهوم را در 5 سطح دشواری توضیح میدهد](https://www.youtube.com/watch?v=fOGdb1CTu5c) - _کانال یوتیوب Wired_
-- [بررسی اجمالی موارد استفاده برای اثبات دانش صفر](https://appliedzkp.org/#Projects) - _تیم کاوشهای حریم خصوصی و مقیاسپذیری_
+- [بررسی اجمالی موارد استفاده برای اثبات دانش صفر](https://pse.dev/projects) - _تیم کاوشهای حریم خصوصی و مقیاسپذیری_
- [SNARKها در مقایسه با STARKها و SNARKهای بازگشتی](https://www.alchemy.com/overviews/snarks-vs-starks) — _خلاصههای کیمیاگری_
- [اثبات دانش صفر: بهبود حریم خصوصی در یک بلاکچین](https://www.altoros.com/blog/zero-knowledge-proof-improving-privacy-for-a-blockchain/) - _دیمیتری لاورنوف_
- [zk-SNARKها - یک مثال واقعی از دانش صفر و بررسی جامع آن](https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c) - _آدام لوسیانو_
- [ZK-STARKها - ایجاد اعتماد قابل تایید، حتی نسبت به رایانههای کوانتومی](https://medium.com/coinmonks/zk-starks-create-verifiable-trust-even-against-quantum-computers-dd9c6a2bb13d) - _آدام لوسیانو_
-- [مقدمهای تقریبی دربارۀ چگونگی امکان zk-SNARKها](https://vitalik.eth.limo/general/2021/01/26/snarks.html) - _ویتالیک بوترین_
-- [اثبات دانش صفر و نقش آن در بلاکچین چیست؟](https://www.leewayhertz.com/zero-knowledge-proof-and-blockchain/) - _لیوی هرتز_
+- [مقدمهای تقریبی دربارۀ ممکن بودن zk-SNARKها](https://vitalik.eth.limo/general/2021/01/26/snarks.html) - _ویتالیک بوترین_
+- [چرا اثباتهای دانش صفر (ZKPs) یک عامل مهم برای هویت خودمختار هستند؟](https://frankiefab.hashnode.dev/why-zero-knowledge-proofs-zkps-is-a-game-changer-for-self-sovereign-identity) — _فرانکلین اوهاگبولام_
+
diff --git a/src/intl/fa/glossary-tooltip.json b/src/intl/fa/glossary-tooltip.json
new file mode 100644
index 00000000000..f9e9883dfad
--- /dev/null
+++ b/src/intl/fa/glossary-tooltip.json
@@ -0,0 +1,164 @@
+{
+ "51%-attack-term": "حمله ۵۱ درصدی",
+ "51%-attack-definition": "نوعی حمله که در آن یک گروه کنترل اکثر گرهها را به دست میگیرد. این امر به آنها اجازه میدهد با معکوس کردن تراکنشها و دابل اسپندینگ اتر و سایر توکن ها، از بلاکچین کلاهبرداری کنند.",
+ "abi-term": "رابط باینری برنامه (ABI)",
+ "abi-definition": "یک فایل JSON که توابع و متغیرهایی که در یک قرارداد هوشمند وجود دارند را توصیف میکند. ABI اجازه میدهد تا بایتکد به فرمتهای قابل خواندن توسط انسانها ترجمه شود.",
+ "account-term": "حساب کاربری",
+ "account-definition": "حساب اتریوم یک هویت دیجیتالی در بلاکچین اتریوم است که به کاربران امکان ارسال، دریافت اتر یا سایر دارایی های دیجیتالی و تعامل با قراردادهای هوشمند را می دهد.",
+ "address-term": "آدرس",
+ "address-definition": "آدرس اتریوم یک شناسه منحصربهفرد است که برای دریافت توکنها استفاده میشود، عملکردی مشابه شماره حساب بانکی برای ارزهای دیجیتال. برای شناسایی حساب اتریوم شما استفاده می شود.",
+ "anti-sybil-term": "ضد-سیبیل",
+ "anti-sybil-definition": "راه هایی برای جلوگیری از تظاهر افراد به تعداد زیادی کاربر در اینترنت به طور همزمان، تضمین می کند که هر کاربر یک شخص واقعی و جداگانه است. این کمک می کند تا تعاملات آنلاین منصفانه و صادقانه باقی بماند.",
+ "apr-term": "نرخ بهره سالانه",
+ "apr-definition": "APR یا نرخ بهره سالانه، نمایانگر هزینه استقراض پول، از جمله بهره و کارمزدها، به شکل درصد است.",
+ "attestation-term": "تصدیق",
+ "attestation-definition": "ادعایی که توسط یک نهاد مطرح می شود مبنی بر اینکه چیزی درست است. در زمینه اتریوم، تایید کنندگان اجماع باید ادعا کنند که حالت زنجیره چگونه است. در زمانهای تعیینشده، هر اعتبارسنج مسئول انتشار گواهیهای مختلف است که به طور رسمی دیدگاه این اعتبارسنج را از زنجیره اعلام میکند، از جمله آخرین ایست بازرسی نهایی و رئیس فعلی زنجیره. اطلاعات بیشتر در مورد امضاها.",
+ "block-term": "بلوک",
+ "block-definition": "بلوک جایی است که تراکنش ها یا اقدامات دیجیتالی ذخیره می شوند. هنگامی که یک بلوک پر شد، به بلوک قبلی متصل می شود و زنجیره ای از بلوک ها یا یک \"بلاکچین\" ایجاد می کند. اطلاعات بیشتر در مورد بلوکها.",
+ "blockchain-term": "زنجیرهی بلوکی",
+ "blockchain-definition": "یک بلاکچین پایگاه داده ای از تراکنش ها است که در تمام رایانه های موجود در شبکه تکرار شده و به اشتراک گذاشته می شود و اطمینان حاصل می کند که داده ها نمی توانند به صورت ماسبق تغییر کنند.",
+ "bridge-term": "پل",
+ "bridge-definition": "یک پل بلاکچین برای انتقال دارایی ها از یک شبکه بلاکچین به شبکه دیگر استفاده می شود.",
+ "consensus-term": "اجماع",
+ "consensus-definition": "هنگامی که بیش از 2/3 کامپیوترهای یک شبکه موافق هستند که مجموعه رکوردهای یکسانی دارند، مطمئن شوید که همه در یک صفحه هستند. این مربوط به قوانینی نیست که آنها از آنها پیروی می کنند، بلکه باید مطمئن شوند که همه آنها اطلاعات یکسانی دارند.",
+ "consensus-client-term": "کلاینت اجماع",
+ "consensus-client-definition": "کلاینتهای اجماع (مانند Prysm، Teku، Nimbus، Lighthouse، Lodestar) الگوریتم اجماع اثبات سهام اتریوم را اجرا میکنند که به شبکه اجازه میدهد تا در مورد هد زنجیره بیکن به توافق برسد. کلاینت های اجماع در اعتبارسنجی/مخابره تراکنش ها یا اجرای انتقال حالت شرکت نمی کنند. این کار توسط کلاینت های اجرا انجام میشود. کلاینت های اجماع، بلوکهای جدید را تأیید نمیکنند یا پیشنهاد نمیکنند. این کار توسط کلاینت اعتبارسنج انجام می شود که یک افزونه اختیاری برای کلاینت اجماع است.",
+ "consensus-layer-term": "لایهی اجماع",
+ "consensus-layer-definition": "لایه اجماع شبکه اتریوم متشکل از کلاینت های اجماع است.",
+ "cryptoeconomics-term": "اقتصادهای رمزارزی",
+ "cryptoeconomics-definition": "مطالعهی اصول اقتصاد و ریاضیات به منظور طراحی پلتفرمهای دیجیتالی امن و قابل اتکاء. هدف این است که اطمینان حاصل شود تمامی شرکت کنندگان از قوانین پیروی میکنند و برای مشارکت در انجام عملیاتهای شبکه و ایجاد امنیت، پاداش دریافت میکنند. ",
+ "cryptography-term": "رمزنگاری",
+ "cryptography-definition": "این عمل خصوصی و ایمن کردن ارتباط است، طوری که فقط کسانی که اطلاعات برای آنها در نظر گرفته شده است بتوانند آن را بخوانند.",
+ "dao-term": "سازمان خودمختار غیرمتمرکز (DAO)",
+ "dao-definition": "DAO یک سازمان دیجیتالی است که توسط قوانین کدگذاری شده روی بلاکچین اداره می شود، جایی که تصمیمات توسط رای اعضا گرفته می شود، نه یک مرجع مرکزی. اطلاعات بیشتر در مورد سازمانهای مستقل غیرمتمرکز (DAO).",
+ "dapp-term": "برنامه غیر متمرکز",
+ "dapp-definition": "دپ (dApp) یک برنامه غیرمتمرکز است که روی یک شبکه بلاکچین اجرا می شود و خدماتی را بدون یک مرجع کنترل مرکزی ارائه می دهد. اطلاعات بیشتر در مورد برنامه های غیرمتمرکز.",
+ "data-availability-term": "دسترسی به دادهها",
+ "data-availability-definition": "هر گره می تواند به طور مستقل تراکنش های یک بلاکچین را به منظور حفظ شفافیت و اعتماد در سیستم تأیید کند.",
+ "defi-term": "DeFi",
+ "defi-definition": "دسته وسیعی از برنامههای اتریوم با هدف ارائه خدمات مالی با پشتیبانی بلاکچین، بدون هیچ واسطهای. اطلاعات بیشتر در مورد امور مالی غیرمتمرکز (DeFi)",
+ "dex-term": "صرافی غیرمتمرکز (DEX)",
+ "dex-definition": "نوعی برنامه اتریوم که به شما امکان می دهد توکن ها را با همتایان در شبکه مبادله کنید. DEX ها مشمول محدودیت های جغرافیایی مانند صرافی های متمرکز نیستند - هر کسی می تواند شرکت کند.",
+ "difficulty-bomb-term": "بمب سختی",
+ "difficulty-bomb-definition": "افزایش تصاعدی برنامه ریزی شده در تنظیم اثبات کار سختی که برای ایجاد انگیزه در انتقال طراحی شده است برای اثبات سهام، کاهش شانس فورک. بمب دشواری با ارتقاء مرج منسوخ شد.",
+ "ecdsa-term": "الگوریتم منحنی امضای دیجیتال (ECDSA)",
+ "ecdsa-definition": "یک الگوریتم رمزنگاری که توسط اتریوم استفاده میشود تا اطمینان حاصل شود داراییها فقط توسط صاحبان آنها خرج شود. این روش ترجیحی برای ایجاد کلیدهای عمومی و خصوصی میباشد. از این الگوریتم در تولید آدرس حساب کاربری و تائید تراکنش استفاده میشود.",
+ "ens-term": "سرویس دامنه اتریوم (ENS)",
+ "ens-definition": "سرویس نام اتریوم مانند یک دفترچه تلفن اینترنتی برای آدرسهای اتریوم است. به جای استفاده از آدرسهای کیف پول طولانی، ENS به شما امکان میدهد از نامهای سادهای مانند «john.eth» برای ارسال و دریافت پول و داراییهای دیجیتال استفاده کنید.",
+ "epoch-term": "ایپاک",
+ "epoch-definition": "دوره ای از 32 اسلات، که هر اسلات 12 ثانیه است، در مجموع 6.4 دقیقه. کمیتههای اعتبارسنج در هر ایپاک به دلایل امنیتی مخدوش میشوند. هر ایپاک فرصتی برای نهایی شدن زنجیره دارد. به هر اعتبارسنج در شروع هر ایپاک مسئولیت های جدیدی اختصاص داده می شود. اطلاعات بیشتر در مورد اثبات سهام",
+ "eoa-term": "حسابی که توسط یا برای کاربران انسانی شبکه Ethereum ایجاد شده است",
+ "eoa-definition": "حساب های دارای مالکیت خارجی (EOAها) رایج ترین نوع حساب اتریوم هستند. آنها توسط یک شخص از طریق کلیدهای خصوصی/عبارت بازیابی کنترل می شوند. اطلاعات بیشتر در مورد کیف پول اتریوم.",
+ "erc-term": "درخواست اتریوم برای نظرات (ERC)",
+ "erc-definition": "ERC (درخواست اتریوم برای نظرات) نوعی اسناد فنی است که در انجمن اتریوم برای پیشنهاد استانداردهای جدید استفاده برای شبکه اتریوم استفاده می شود.",
+ "erc-1155-term": "ERC-1155",
+ "erc-1155-definition": "نوعی استاندارد توکن اتریوم مشابه NFT (مانند اقلام کلکسیونی منحصر به فرد) که همچنین امکان ایجاد اقلام قابل تعویض (مانند ارز) را در یک قرارداد هوشمند واحد فراهم می کند.",
+ "erc-20-term": "ERC-20",
+ "erc-20-definition": "مجموعه استانداردی از قوانین است که اکثر توکن ها در شبکه اتریوم با آن ایجاد می شوند.",
+ "erc-721-term": "ERC-721",
+ "erc-721-definition": "مجموعه ای استاندارد از قوانین مورد استفاده برای ایجاد NFT (توکن های غیرقابل تعویض).",
+ "ether-term": "اتر",
+ "ether-definition": "رمزارز بومی اتریوم که معمولاً به آن «ETH» میگویند. در هنگام استفاده از اکوسیستم و برنامه های کاربردی اتریوم برای پوشش کارمزد تراکنش ها استفاده می شود. اطلاعات بیشتر در مورد اتر.",
+ "events-term": "رویدادها",
+ "events-definition": "استفاده از امکانات گزارش EVM را ممکن می سازد. دپ ها میتوانند به رویدادها گوش دهد و از آنها برای راهاندازی فراخوان های JavaScript در رابط کاربری استفاده کنند. اطلاعات بیشتر در مورد رویدادها و گزارشها",
+ "execution-client-term": "کلاینت اجرا",
+ "execution-client-definition": "کلاینت های اجرا (که قبلا به عنوان \"کلاینت های Eth1\" شناخته می شدند)، مانند Besu، Erigon، Go-Ethereum (Geth)، Nethermind، وظیفه پردازش و پخش تراکنش ها و مدیریت وضعیت اتریوم را بر عهده دارند. آنها محاسبات را برای هر تراکنش با استفاده از ماشین مجازی اتریوم اجرا میکنند تا از رعایت قوانین پروتکل اطمینان حاصل کنند.",
+ "execution-layer-term": "لایهی اجرا",
+ "execution-layer-definition": "لایه اجرای اتریوم شبکه متشکل از کلاینت های اجراست.",
+ "finality-term": "قطعیت",
+ "finality-definition": "نهایی شدن تضمینی است که مجموعه ای از تراکنش ها را نمی توان بدون از دست رفتن مقدار زیادی از ETH تغییر داد.",
+ "fork-term": "فورک",
+ "fork-definition": "تغییر در پروتکل باعث ایجاد یک زنجیره جایگزین می شود.",
+ "fraud-proof-term": "اثبات تقلب",
+ "fraud-proof-definition": "یک مدل امنیتی برای راهحلهای خاص لایه 2 که در آن، برای افزایش سرعت، تراکنشها قرار میشوند a> به دسته ها تبدیل شده و در یک تراکنش به اتریوم ارسال می شود. سایر شرکتکنندگان شبکه میتوانند تراکنشها را مجدداً اجرا کنند تا بررسی کنند که آیا صادقانه اجرا شدهاند. اگر آنها اختلاف بین داده های ارسال شده و نسخه خود را کشف کنند، می توانند یک مدرک رمزنگاری شده ارسال کنند که نشان می دهد در کجا تقلب صورت گرفته است. برخی از مجموعهها از شواهد اعتبار استفاده میکنند.",
+ "gas-term": "گاز",
+ "gas-definition": "گس هزینه ای است که برای تراکنش ها و قراردادهای هوشمند در یک بلاکچین، مانند اتریوم، پرداخت می شود. اطلاعات بیشتر در مورد گس و کارمزدها.",
+ "genesis-block-term": "بلوک ایجاد",
+ "genesis-block-definition": "اولین بلوک در زنجیرهی بلوکی برای راهاندازی یک شبکه خاص و ارزهای رمزنگاری شده آن استفاده می شد.",
+ "gwei-term": "Gwei",
+ "gwei-definition": "مخفف gigawei، نامی از اتر، که معمولاً برای قیمت گاز استفاده میشود. 1 gwei = 109 wei. 109 gwei = 1 اتر.",
+ "hash-term": "هش",
+ "hash-definition": "یک اثر با طول ثابت ورودی با اندازه متغیر که توسط یک تابع هش تولید میشود. (به keccak-256 مراجعه کنید).",
+ "holographic-consensus-term": "اجماع هولوگرافیک",
+ "holographic-consensus-definition": "به نحوه تصمیم گیری گروهی بزرگ با اجازه دادن به گروه کوچکتری از نمایندگان مردم اشاره دارد. سپس همه قبول میکنند که با آن همراهی کنند، به شرطی که اعتماد داشته باشند که گروه کوچک کار خوبی انجام داده است.",
+ "index-term": "ایندکس",
+ "index-definition": "ساختار شبکه ای به منظور بهینهسازی استعلام اطلاعات از سراسر بلاکچین با ارائه یک مسیر کارآمد به منبع ذخیره آن.",
+ "key-term": "کلید",
+ "key-definition": "در زمینه اتریوم، کلیدها کدهای دیجیتال هستند: یک کلید عمومی برای دریافت تراکنش ها و یک کلید خصوصی برای دسترسی و ارسال وجوه.",
+ "layer-2-term": "لایه 2",
+ "layer-2-definition": "لایه 2 ها شبکه های دیگری هستند که بر روی شبکه اصلی اتریوم ساخته شده اند تا تراکنش ها را سریعتر و ارزانتر کنند. اطلاعات بیشتر در مورد لایه 2.",
+ "liquidity-tokens-term": "توکنهای نقدینگی",
+ "liquidity-tokens-definition": "توکنهای نقدینگی (LT) توکنهای دیجیتالی هستند که برای شرکتکنندگانی صادر میشوند که داراییها را در یک استخر نقدینگی سپردهگذاری میکنند، که مجموعهای از وجوه قفل شده در یک قرارداد هوشمند است و برای تسهیل تجارت در یک صرافی غیرمتمرکز (DEX) استفاده میشود.",
+ "mainnet-term": "شبکه اصلی",
+ "mainnet-definition": "مخفف کلمه \"شبکه اصلی\"، همان بلاکچین اصلی اتریوم است.",
+ "mev-term": "MEV",
+ "mev-definition": "مکانیزمی که اقدامات خاصی را بر روی یک بلاکچین در ازای کارمزد اولویت بندی می کند و بر نتایج و ترتیب تراکنش ها تأثیر می گذارد.",
+ "multisig-term": "قابلیت چندامضایی",
+ "multisig-definition": "Multisig (چند امضایی) به یک کیف پول یا حساب دیجیتالی اشاره دارد که برای انجام تراکنش ها به چندین امضا یا تایید نیاز دارد و امنیت را افزایش می دهد.",
+ "nft-term": "توکن غیرقابل تعویض (NFT)",
+ "nft-definition": "توکن غیرقابل تعویض (NFT) یک آیتم دیجیتال منحصر به فرد است که می توانید آن را داشته باشید، مانند آثار هنری یا کلکسیونی که توسط فناوری بلاکین تأیید شده است. اطلاعات بیشتر در مورد توکنهای غیرقابل تعویض (NFT).",
+ "node-term": "گره",
+ "node-definition": "یک کلاینت نرم افزاری که در شبکه شرکت می کند. اطلاعات بیشتر در مورد گره ها و کلاینت ها.",
+ "ommer-term": "بلوک Ommer (عمو)",
+ "ommer-definition": "وقتی یک miner اثبات کار، یک بلوک معتبر پیدا میکند، ممکن است معدنچی دیگری منتشر کرده باشد. یک بلوک رقیب که ابتدا به نوک بلاکچین اضافه می شود. این بلوک معتبر، اما قدیمی، میتواند توسط بلوکهای جدیدتر بهعنوان ommers گنجانده شود و یک پاداش بلوک جزئی دریافت کند. اصطلاح \"ommer\" اصطلاح ترجیحی از نظر جنسیتی خنثی برای خواهر یا برادر بلوک والدین است، اما گاهی اوقات به آن \"عمو\" نیز گفته می شود. زمانی که اتریوم یک شبکه اثبات کار بود، این برای اتریوم رایج بود. اکنون که اتریوم از اثبات سهام استفاده میکند، تنها یک پیشنهاد دهنده بلوک در هر اسلات انتخاب میشود.",
+ "on-chain-term": "روی زنجیره",
+ "on-chain-definition": "به اقدامات یا تراکنشهایی اشاره دارد که روی بلاکچین اتفاق میافتند و در دسترس عموم هستند.",
+ "optimistic-rollup-term": "رول آپ خوش بینانه",
+ "optimistic-rollup-definition": "رولآپ خوشبینانه یک راه حل لایه 2 است که به تراکنش ها در اتریوم سرعت می بخشد، با این فرض که به طور پیش فرض معتبر هستند مگر اینکه به چالش کشیده شوند. اطلاعات بیشتر در مورد رولآپ خوشبینانه.",
+ "peer-to-peer-network-term": "شبکه همتا به همتا",
+ "peer-to-peer-network-definition": "شبکه ای از رایانه ها (همتاها) که به عنوان یک مجموعه، قادر به انجام عملکردها بدون نیاز به خدمات متمرکزِ بر پایه سرور می باشد.",
+ "permissionless-term": "بدون نیاز به مجوز",
+ "permissionless-definition": "برای استفاده از سیستمی مانند اتریوم نیازی به مجوز یا تایید نیست و هیچ کس نمی تواند شما را از استفاده از آن باز دارد. به طور 24/7 برای مشارکت کردن همه باز است.",
+ "private-key-term": "کلید خصوصی",
+ "private-key-definition": "کلید خصوصی یک کد مخفی است که ثابت می کند شما صاحب پول دیجیتال خود هستید و به شما امکان می دهد آن را خرج کنید، مانند یک پین برای حساب خود. آن را به اشتراک نگذارید.",
+ "poap-term": "POAP",
+ "poap-definition": "پروتکل اثبات حضور برای ایجاد یک مجموعه دیجیتال (NFT) استفاده می شود که ثابت می کند در یک رویداد یا فعالیت خاص شرکت کرده اید.",
+ "pos-term": "اثبات سهام (PoS)",
+ "pos-definition": "روشی که با آن هدف پروتکل بلاک چین ارز دیجیتال دستیابی به اجماع توزیع شده است. اثبات هام از کاربران میخواهد که مالکیت مقدار معینی از ارزهای دیجیتال («سهم» آنها در شبکه) را اثبات کنند تا بتوانند در اعتبارسنجی تراکنشها شرکت کنند. اطلاعات بیشتر در مورد اثبات سهام.",
+ "pow-term": "اثبات کار (PoW)",
+ "pow-definition": "یک مکانیسم امنیتی برای بلاک چین که به گرهها نیاز دارد تا انرژی را در قالب محاسبات برای یافتن یک مقدار مشخص صرف کنند.",
+ "public-goods-term": "کالاهای عمومی",
+ "public-goods-definition": "کالاهای عمومی چیزهایی هستند که همه می توانند به صورت رایگان از آن استفاده کنند، مانند پارک ها یا هوای پاک، و استفاده از آنها مانع استفاده دیگران از آنها نمی شود. دولتها اغلب این موارد را ارائه میدهند، زیرا کسبوکارها معمولاً این کار را نمیکنند، زیرا نمیتوانند به راحتی از مردم برای استفاده از آنها هزینه دریافت کنند.",
+ "public-key-term": "کلید عمومی",
+ "public-key-definition": "کلید عمومی مجموعهای از نویسهها است که به دیگران اجازه میدهد ارز دیجیتالی را به صورت امن برای شما ارسال کنند، مانند آدرس ایمیل برای پول.",
+ "quadratic-voting-term": "رای گیری درجه دوم",
+ "quadratic-voting-definition": "یک روش رای گیری است که در آن رای دهندگان احساس خود را نسبت به مسائل ابراز می کنند. به رای دهندگان این امکان را می دهد که نه تنها ترجیح خود را نشان دهند، بلکه شدت ترجیح خود را نیز نشان دهند.",
+ "recovery-phrase-term": "عبارت سید / عبارت بازیابی",
+ "recovery-phrase-definition": "لیستی از کلماتی که هنگام ایجاد یک کیف پول دیجیتال به شما داده می شود. این رمز عبور مانند رمز عبور عمل می کند که می تواند به شما کمک کند در صورت از دست دادن دسترسی به کیف پول خود بازگردید و مطمئن شوید که پول دیجیتال یا توکن های خود را از دست نمی دهید.",
+ "rollups-term": "رولآپ ها",
+ "rollups-definition": "نوعی راه حل مقیاسپذیری لایه2 که چندین تراکنش را دسته بندی می کند و آنها را در یک تراکنش به شبکه اصلی اتریوم ارسال می کند. این امکان کاهش در هزینههای گس و افزایش توان عملیاتی تراکنش را فراهم میکند. رولآپ های خوشبینانه و دانش صفر وجود دارند که از روشهای امنیتی مختلفی برای ارائه این دستاوردهای مقیاسپذیری استفاده میکنند.\n اطلاعات بیشتر در مورد رولآپ.",
+ "rpc-term": "فراخوانی روش از راه دور (RPC)",
+ "rpc-definition": "RPC به یک کامپیوتر اجازه میدهد تا داده یا اقدامی را از طریق شبکه از دیگری درخواست کند، مانند درخواست اطلاعات با کنترل از راه دور.",
+ "sequencer-term": "ترتیب دهنده",
+ "sequencer-definition": "مرتب کننده، برنامه ای است که مسئول مرتب کردن تراکنش ها در یک شبکه بلاکچین است.",
+ "smart-contract-term": "قرارداد هوشمند",
+ "smart-contract-definition": "قرارداد هوشمند برنامهای است که بهطور خودکار توافقنامهها را روی یک بلاکچین اجرا میکند، مانند یک قرارداد دیجیتالی خوداجرا. مقدمه ای بر قراردادهای هوشمند.",
+ "stablecoin-term": "استیبل کوین",
+ "stablecoin-definition": "استیبل کوین نوعی رمزارز است که برای داشتن یک ارزش پایدار طراحی شده است که اغلب به یک ارز یا کالا (مانند دلار آمریکا) متصل می شود تا نوسان قیمت را به حداقل برساند. اطلاعات بیشتر در مورد استیبل کوین.",
+ "staking-term": "سهام گذاری",
+ "staking-definition": "سپرده گذاری مقداری اتر (سهم شما) برای تبدیل شدن به یک اعتبارسنج و ایمن کردن شبکه. یک اعتبارسنج تراکنشها را بررسی میکند و بلوکها را تحت یک مدل اجماع به نام اثابت سهام پیشنهاد میکند. سهامگذاری به شما انگیزه اقتصادی می دهد تا در راستای منافع شبکه عمل کنید. برای انجام وظایف اعتبارسنج خود جوایزی دریافت خواهید کرد، اما اگر این کار را نکنید مقادیر متفاوتی از ETH را از دست خواهید داد. اطلاعات بیشتر در مورد سهامگذاری در اتریوم.",
+ "staking-pool-term": "استخر سهامگذاری",
+ "staking-pool-definition": "ETH ترکیبی بیش از یک سهامگذار اتریوم، برای رسیدن به 32 اتریوم مورد نیاز برای فعال کردن مجموعه ای از کلیدهای اعتبارسنج استفاده می شود. یک اپراتور گره از این کلیدها برای شرکت در اجماع استفاده می کند و پاداش های بلوک بین سهامگذاران مشارکت کننده تقسیم می شود. استخرهای سهامگذاری یا سهامگذاری نیابتی برای پروتکل اتریوم بومی نیستند، اما راهکارهای زیادی توسط جامعه ایجاد شده است.\nاطلاعات بیشتر در مورد سهامگذاری دستهجمعی.",
+ "sybil-attack-term": "حمله Sybil",
+ "sybil-attack-definition": "حملات Sybil به افرادی اشاره دارد که یک سیستم را فریب می دهند تا فکر کنند چندین نفر هستند تا نفوذ خود را افزایش دهند.",
+ "terminal-total-difficulty-term": "سختی کل ترمینال (TTD)",
+ "terminal-total-difficulty-definition": "سختی کل مجموع دشواری استخراج Ethash برای همه بلوک ها تا یک نقطه خاص در زنجیره بلوک است. سختی کل ترمینال یک مقدار مشخص برای سختی کل است که به عنوان محرک برای کلاینتهای اجرا برای خاموش کردن ماینینگ و مسدود کردن توابع شایعه استفاده میشود و شبکه را قادر میسازد تا به اثبات سهام تبدیل شود. این واژه دیگر کاربرد ندارد زیرا اتریوم به اثبات سهام تغییر یافت.",
+ "transaction-fee-term": "کارمزد تراکنش",
+ "transaction-fee-definition": "هزینه ای که هر زمان که از شبکه اتریوم استفاده می کنید باید پرداخت کنید. مثلاً ارسال وجوه از کیف پول شما یا تعامل با یک دپ، مانند تعویض توکن یا خرید یک کلکسیون. شما می توانید به این موضوع همانند هزینه خدمات فکر کنید. این هزینه بر اساس شلوغی شبکه تغییر خواهد کرد. این به این دلیل است که اعتبارسنجها، یعنی افرادی که مسئول پردازش تراکنش شما هستند، احتمالاً تراکنشهایی با کارمزد بالاتر را در اولویت قرار میدهند - بنابراین ازدحام باعث افزایش قیمت میشود.
در سطح فنی، کارمزد تراکنش شما به میزان گس مورد نیاز تراکنش شما مربوط می شود.
کاهش کارمزد تراکنش موضوعی است که در حال حاضر بسیار مورد توجه است. به لایه 2 مراجعه کنید.",
+ "trust-assumptions-term": "مفروضات اعتماد",
+ "trust-assumptions-definition": "مفروضات اعتماد، باورهای اساسی در مورد ایمنی و قابل اعتماد بودن یک سیستم هستند که به آنچه ما اعتماد داریم برای عملکرد سیستم راهنمایی می کنند.",
+ "validator-term": "اعتبارسنج",
+ "validator-definition": "یک گره در سیستم اثبات سهام مسئول ذخیره دادهها، پردازش تراکنشها، و اضافه کردن بلوک های جدید به بلاکچین است. برای فعال کردن نرمافزار اعتبارسنج، باید بتوانید 32 عدد ETH را سهامگذاری کنید. اطلاعات بیشتر در مورد سهامگذاری در اتریوم.",
+ "validity-proof-term": "اثبات اعتبار",
+ "validity-proof-definition": "یک مدل امنیتی برای راهکارهای خاص لایه2 که برای افزایش سرعت، تراکنشها به صورت دستهای جمع میشوند و در یک تراکنش به اتریوم ارسال میشوند.\nمحاسبه تراکنش خارج از زنجیره انجام می شود و سپس با اثبات اعتبار آنها به زنجیره اصلی ارائه می شود.\nاین روش با حفظ امنیت، میزان تراکنش های ممکن را افزایش می دهد.\nبرخی از رولآپها از اثبات تقلب استفاده میکنند.\nاطلاعات بیشتر در مورد رولآپهای دانش-صفر.",
+ "wallet-term": "کیف پول",
+ "wallet-definition": "یک کیف پول یک ابزار دیجیتالی برای ذخیره، ارسال و دریافت رمزارز است، مانند یک کیف پول مجازی برای پول آنلاین شما. اطلاعات بیشتر در مورد کیف پول اتریوم.",
+ "web2-term": "Web2",
+ "web2-definition": "آیا اینترنت فعلی متمرکز بر محتوای تولید شده توسط کاربر و رسانه های اجتماعی است که توسط شرکت های کمی کنترل می شود.\n وی3 یک اعتقاد رمزینه است که کاربران باید داده ها و تراکنش های خود را به جای آن کنترل کنند.",
+ "web3-term": "Web3",
+ "web3-definition": "وب3 اینترنت جدید با بلاکچین است که در آن کاربران داده ها و تراکنش های خود را کنترل می کنند نه شرکت ها. نیازی به اشتراک گذاری اطلاعات شخصی نیست. جزئیات بیشتر درباره وب3.",
+ "wei-term": "Wei",
+ "wei-definition": "کوچکترین اسم اتر. 1018 وی = 1 اتر.",
+ "zk-proof-term": "اثبات دانش-صفر",
+ "zk-proof-definition": "اثبات دانش صفر یک روش رمزنگاری است که به فرد اجازه میدهد بدون ارائه اطلاعات اضافی صحت یک جمله را ثابت کند. اطلاعات بیشتر در مورد رولآپهای دانش-صفر."
+}
diff --git a/src/intl/fa/glossary.json b/src/intl/fa/glossary.json
new file mode 100644
index 00000000000..ab3ef28ca5b
--- /dev/null
+++ b/src/intl/fa/glossary.json
@@ -0,0 +1,400 @@
+{
+ "51%-attack-term": "حمله ۵۱ درصدی",
+ "51%-attack-definition": "نوعی از حمله که در آن یک گروه، کنترل اکثریت گرهها را به دست می آورد. این کار به آنان اجازه میدهد با معکوس کردن تراکنشها و خرج مجدد اتر و سایر توکنها، زنجیرهی بلوکی را فریب دهند.
در اتریوم با سیستم اثبات سهام، این هدف با اندوختن بیش از نیمی از مجموع اترهای سهام گذاری شده محقق میشود. این به مهاجم اجازه میدهد تا تصمیم بگیرد که کدام بلوکهای جدید به زنجیرهی بلوکها در شبکه اضافه شود. با این حال، برای برگرداندن زنجیرهی شبکه یا خرج مجدد داراییها، یک مهاجم حداقل به 66% از مجموع مقدار اترهای سهامگذاری شده نیاز دارد.",
+ "account-term": "حساب کاربری",
+ "account-definition": "حساب کاربری اتریوم، یک هویت دیجیتال در شبکهی بلاکچین اتریوم است که به کاربران امکان ارسال و دریافت اتر و تعامل با قراردادهای هوشمند را میدهد.
توضیح فنی:
یک شیء است که شامل آدرس، موجودی، نانس و دو فیلد اختیاری کد و حافظه میباشد. یک حساب میتواند یک قرارداد هوشمند یا حساب با مالکیت خارج شبکهای (EOA) باشد.",
+ "address-term": "آدرس",
+ "address-definition": "آدرس اتریوم یک شناسهی منحصر به فرد است که برای دریافت توکنها استفاده میشود و عملکردی مانند شماره حساب بانکی را برای ارزهای دیجیتال دارد. از آن برای شناسائی حساب اتریوم شما استفاده میشود.
این شناسه از اعمال تابع رمزنگاری Keccak بر روی کلید عمومی بدست آمده از الگوریتم ECDSA یا الگوریتم امضای دیجیتال منحنی بیضوی، و سپس جدا کردن 160 رقم سمت راست آن، بدست میآید.",
+ "anti-sybil-term": "ضد-سیبیل",
+ "anti-sybil-definition": "راه هایی برای جلوگیری از تظاهر افراد به تعداد زیادی کاربر در اینترنت به طور همزمان، تضمین می کند که هر کاربر یک شخص واقعی و جداگانه است. این کمک می کند تا تعاملات آنلاین منصفانه و صادقانه باقی بماند.",
+ "abi-term": "رابط باینری برنامه (ABI)",
+ "abi-definition": "یک فایل JSON که توابع و متغیرهایی که در یک قرارداد هوشمند وجود دارند را توصیف میکند. ABI اجازه میدهد تا بایتکد به فرمتهای قابل خواندن توسط انسانها ترجمه شود.",
+ "api-term": "رابط برنامه نویسی نرمافزار (API)",
+ "api-definition": "Application Programming Interface (API) مجموعه ای از تعاریف برای نحوه استفاده از یک نرم افزار است. یک API بین یک برنامه کاربردی و یک وب سرور قرار می گیرد و انتقال داده ها را بین آنها تسهیل می کند.",
+ "apr-term": "نرخ بهره سالانه",
+ "apr-definition": "APR یا نرخ بهره سالانه، نمایانگر هزینه استقراض پول، از جمله بهره و کارمزدها، به شکل درصد است.",
+ "asic-term": "اسیک (ASIC)",
+ "asic-definition": "مدار مجتمع مخصوص کاربرد این معمولاً به یک مدار مجتمع اشاره دارد که به صورت سفارشی برای استخراج رمزارزها ساخته شده است.",
+ "assert-term": "assert",
+ "assert-definition": "در Solidity، «assert(false)» به «0xfe»، یک کد عملیات نامعتبر، که از همه gas و همه تغییرات را برمی گرداند. هنگامی که عبارت «assert()» ناموفق باشد، اتفاقی بسیار اشتباه و غیرمنتظره در حال رخ دادن است و شما باید کد خود را اصلاح کنید. شما باید از «assert()» استفاده کنید تا از شرایطی که هرگز نباید رخ دهد اجتناب کنید. اطلاعات بیشتر در مورد امنیت قراردادهای هوشمند.",
+ "attestation-term": "تصدیق",
+ "attestation-definition": "ادعایی که توسط یک نهاد مطرح می شود مبنی بر اینکه چیزی درست است. در زمینه اتریوم، تایید کنندگان اجماع باید ادعا کنند که حالت زنجیره چگونه است. در زمانهای تعیینشده، هر اعتبارسنج مسئول انتشار گواهیهای مختلف است که به طور رسمی دیدگاه این اعتبارسنج را از زنجیره اعلام میکند، از جمله آخرین ایست بازرسی نهایی و رئیس فعلی زنجیره. اطلاعات بیشتر در مورد امضاها.",
+ "base-fee-term": "کارمزد پایه",
+ "base-fee-definition": "هر بلوک دارای یک قیمت رزرو است که به عنوان \"کارمزد پایه\" شناخته می شود. این حداقل کارمزد گاز است که کاربر باید برای گنجاندن تراکنش در بلوک بعدی بپردازد. اطلاعات بیشتر در مورد گس و کارمزدها.",
+ "beacon-chain-term": "بیکن چین",
+ "beacon-chain-definition": "بیکن چین، بلاکچینی بود که اثبات کننده سهام و اعتبار سنج را به اتریوم معرفی کرد. از دسامبر 2020 تا زمانی که این دو زنجیره در سپتامبر 2022 ادغام شدند و اتریوم امروزی را تشکیل دادند، در کنار شبکه اصلی اتریوم اثبات کار اجرا شد. اطلاعات بیشتر در مورد بیکن چین.",
+ "big-endian-term": "ترتیب قرارگیری بایت ها از کم ارزش ترین قسمت مموری",
+ "big-endian-definition": "یک نمایش عددی موقعیتی که در آن مهمترین رقم اول در حافظه است. برعکس little-endian، جایی که کمترین رقم اول است.",
+ "block-term": "بلوک",
+ "block-definition": "بلوک جایی است که تراکنش ها یا اقدامات دیجیتالی ذخیره می شوند. هنگامی که یک بلوک پر شد، به بلوک قبلی متصل می شود و زنجیره ای از بلوک ها یا یک \"بلاکچین\" ایجاد می کند.\nاطلاعات بیشتر در مورد بلوکها.
بلوک یک واحد اطلاعات همراه است که شامل فهرستی از تراکنشها و اطلاعات مربوط به اجماع است..\nبلوکها توسط اعتبارسنجای اثبات سهام پیشنهاد میشوند، در این مرحله آنها در سراسر شبکه همتا به همتا به اشتراک گذاشته میشوند، جایی که به راحتی میتوانند بهطور مستقل توسط تمام گرههای دیگر تأیید شوند.\nقواعد اجماع بر محتویات یک بلوک معتبر است و هر بلوک نامعتبر توسط شبکه نادیده گرفته می شود.\nترتیب این بلوک ها و تراکنش های موجود در آن زنجیره ای قطعی از رویدادها را ایجاد می کند که انتهای آن نشان دهنده وضعیت فعلی شبکه است.",
+ "block-explorer-term": "جستجوگر بلوک",
+ "block-explorer-definition": "رابطی که به کاربر اجازه می دهد اطلاعاتی را از زنجیره بلوکی و در مورد آن جستجو کند. این شامل بازیابی تراکنش های فردی، فعالیت های مرتبط با آدرس های خاص و اطلاعات مربوط به شبکه است.",
+ "block-header-term": "هدر بلوک",
+ "block-header-definition": "هِدِر یا شناسه منحصر به فرد بلوک مجموعه ای است از فراداده هایی در مورد یک بلوک و خلاصه ای از تراکنش های موجود در پیلود اجرایی.",
+ "block-propagation-term": "انتشار بلوک",
+ "block-propagation-definition": "فرآیند انتقال یک بلوک تایید شده به تمامی گره های دیگر در شبکه.",
+ "block-proposer-term": "پیشنهاد کنندهی بلوک",
+ "block-proposer-definition": "یک اعتبارسنج مشخص انتخاب شده به منظور ایحاد یک اسلات خاص.",
+ "block-reward-term": "پاداش بلوک",
+ "block-reward-definition": "مقدار اِتِر پاداش داده شده به پیشنهاد دهنده ی یک بلوک جدید معتبر می باشد.",
+ "block-status-term": "وضعیت بلوک",
+ "block-status-definition": "حالت هایی که یک بلوک می تواند در آنها وجود داشته باشد. حالت های ممکن عبارتند از:
- پیشنهاد شده: بلوک توسط اعتبارسنج پیشنهاد شده است
- زمانبندیشده: اعتبارسنجها در حال ارسال دادهها هستند
- از دست رفته/رد شده: پیشنهاد دهنده بلوکی را در چارچوب زمانی واجد شرایط پیشنهاد نکرده است
- یتیم ani: بلوک توسط الگوریتم انتخاب فورک
دوبارهچینی شده است",
+ "block-time-term": "زمان بلوک",
+ "block-time-definition": "فاصله زمانی بین اضافه شدن بلوک ها به زنجیرهی بلوکی.",
+ "block-validation-term": "اعتبار سنجی بلوک",
+ "block-validation-definition": "فرآیند بررسی اینکه یک بلوک جدید حاوی تراکنشها و امضاهای معتبر است، بر سنگینترین زنجیره تاریخی (به معنای زنجیرهای است که بیشترین گواهیها را در تاریخ خود جمعآوری کرده است) ساخته میشود و از همه قوانین اجماع دیگر پیروی میکند. بلوک های معتبر به سر زنجیره اضافه می شوند و به دیگران در شبکه منتشر می شوند. بلوک های نامعتبر نادیده گرفته می شوند.",
+ "blockchain-term": "زنجیرهی بلوکی",
+ "blockchain-definition": "یک بلاک چین پایگاه داده ای از تراکنش ها است که در همه رایانه های موجود در شبکه تکرار شده و به اشتراک گذاشته می شود و تضمین می کند که داده ها نمی توانند به صورت ماسبق تغییر کنند.
دنباله ای از بلوک، هرکدام با ارجاع به هش بلوک قبلی، تمام راه را به بلوک جنسیس لینک میدهند. یکپارچگی بلاکچین با استفاده از مکانیسم اجماع مبتنی بر اثبات سهام از لحاظ اقتصادی رمزنگاری شده است. بلاکچین چیست؟",
+ "bootnode-term": "بوت نود",
+ "bootnode-definition": "گره هایی که می توانند برای شروع فرآیند کشف هنگام اجرای یک گره استفاده شوند. بوت نودها، گره های جدید را به سایر گره های موجود «معرفی می کنند» تا بتوانند به جای جستجوی همتای اولیه، به سرعت همتایان را به دست آورند. نقاط پایانی این گرهها معمولاً در کد منبع مشتری اتریوم ارائه میشوند، اما کاربران میتوانند لیست بوتنودهای خود را ارائه دهند.",
+ "bridge-term": "پل",
+ "bridge-definition": "یک پل بلاکچین برای انتقال دارایی ها از یک شبکه بلاکچین به دیگر شبکه ها استفاده می شود. برای مثال میتوانید از پل برای انتقال اتریوم از شبکه اصلی اتریوم به راهحلهای مقیاسپذیری لایه ۲ ارزانتر استفاده کنید.",
+ "bytecode-term": "بایت کد",
+ "bytecode-definition": "کد به شکلی فشرده و عددی بیان شده است تا بتوان آن را به طور موثر توسط EVM اجرا کرد.",
+ "byzantium-fork-term": "فورک بیزانتیوم",
+ "byzantium-fork-definition": "اولین مورد از دو هاردفورک برای مرحله توسعه متروپلیس. این شامل EIP-649 Metropolis بمب سختی تاخیر و بلوک کاهش پاداش است، که در آن Ice Age به مدت 1 سال به تعویق افتاد و پاداش بلوک از 5 به 3 اتر کاهش یافت.",
+ "casper-ffg-term": "Casper FFG",
+ "casper-ffg-definition": "Casper-FFG یک پروتکل اجماع اثبات سهام است که در ارتباط با الگوریتم انتخاب فورک LMD-GHOST استفاده میشود تا به کلاینت های اجماع اجازه دهند تا در مورد رئیس بیکن چین به توافق برسند.",
+ "checkpoint-term": "نقطه بازرسی",
+ "checkpoint-definition": "بیکن چین دارای سرعتی است که به اسلات (12 ثانیه) و ایپاک (32 شکاف) تقسیم میشود.\nاولین اسلات در هر ایپاک یک ایست بازرسی است. هنگامی که اَبَراکثریت اعتبارسنج ها ارتباط بین دو نقطه بازرسی را تأیید میکنند، میتوان آنها را توجیه کرد و سپس وقتی یک ایست بازرسی دیگر در بالا توجیه شد، میتوان آنها را نهایی سازی کرد.",
+ "compiling-term": "کامپایل کردن",
+ "compiling-definition": "تبدیل کد نوشته شده در یک زبان برنامه نویسی سطح بالا (به عنوان مثال، سالیدیتی) به یک زبان سطح پایین تر (به عنوان مثال، EVM بایت کد).اطلاعات بیشتر در مورد کامپایل قراردادهای هوشمند",
+ "committee-term": "کمیته",
+ "committee-definition": "گروهی متشکل از حداقل 128 اعتبارسنج اختصاص داده شده برای اعتبارسنجی بلوک ها در هر اسلات. ییکی از اعتبارسنجها در کمیته، جمعآورنده است که مسئول جمعآوری امضای تمام اعتبارسنج های دیگر در کمیتهای است که در مورد تأییدیه توافق میکنند. نباید با کمیته همگامسازی اشتباه گرفته شود.",
+ "computational-infeasibility-term": "عدم امکان محاسباتی",
+ "computational-infeasibility-definition": "یک پردازش اگر زمان زیادی را طول بکشد (به عنوان مثال میلیاردها سال) از نظر محاسباتی غبر ممکن خواهد بود، حتی اگر کسی به طور قابل تصوری علاقمند به انجام آن باشد.",
+ "consensus-term": "اجماع",
+ "consensus-definition": "هنگامی که بیش از 2/3 کامپیوترهای یک شبکه موافق هستند که مجموعه رکوردهای یکسانی دارند، مطمئن شوید که همه در یک صفحه هستند. این مربوط به قوانینی نیست که آنها از آنها پیروی می کنند، بلکه باید مطمئن شوند که همه آنها اطلاعات یکسانی دارند.",
+ "consensus-client-term": "کلاینت اجماع",
+ "consensus-client-definition": "کلاینتهای اجماع (مانند Prysm، Teku، Nimbus، Lighthouse، Lodestar) الگوریتم اجماع اثبات سهام اتریوم را اجرا میکنند که به شبکه اجازه میدهد تا در مورد هد زنجیره بیکن به توافق برسد. کلاینت های اجماع در اعتبارسنجی/مخابره تراکنش ها یا اجرای انتقال حالت شرکت نمی کنند. این کار توسط کلاینت های اجرا انجام میشود. کلاینت های اجماع، بلوکهای جدید را تأیید نمیکنند یا پیشنهاد نمیکنند. این کار توسط کلاینت اعتبارسنج انجام می شود که یک افزونه اختیاری برای کلاینت اجماع است.",
+ "consensus-layer-term": "لایهی اجماع",
+ "consensus-layer-definition": "لایه اجماع شبکه اتریوم متشکل از کلاینت های اجماع است.",
+ "consensus-rules-term": "قوانین توافق عمومی",
+ "consensus-rules-definition": "اعتبارسنجی بلوک شامل مجموعه دستورالعملهایی است که گرههای کامل دنبال میکنند تا با سایر گرهها همگام باشند. این عمل با اجماع تفاوت دارد.",
+ "cfi-term": "برای گنجاندن در نظر گرفته شده (CFI)",
+ "cfi-definition": "EIP اصلی که هنوز در شبکه اصلی فعال نیست و توسعه دهندگان کلاینت عموماً نسبت به این ایده مثبت نگاه میکنند. با فرض اینکه تمام الزامات برای گنجاندن شبکه اصلی را برآورده می کند، به طور بالقوه می تواند در ارتقاء شبکه (نه لزوماً بعدی) گنجانده شود.",
+ "constantinople-fork-term": "فورک قسطنطنیه",
+ "constantinople-fork-definition": "قسمت دوم مرحله متروپلیس، که در ابتدا برای اواسط سال 2018 برنامه ریزی شده بود. انتظار می رود شامل تغییر به یک اثبات کار/اثبات سهام ، الگوریتم اجماع، در میان سایر تغییرات باشد.",
+ "contract-account-term": "حساب قرارداد",
+ "contract-account-definition": "حسابی حاوی کدی که هر زمان که یک تراکنش از یک حساب دیگر دریافت میکند، اجرا میشود (EOA] یاقرارداد).",
+ "contract-creation-transaction-term": "معامله ایجاد قرارداد",
+ "contract-creation-transaction-definition": "یک تراکنش ویژه که شامل کد شروع قرارداد است. گیرنده روی \"null\" تنظیم می شود و قرارداد به آدرسی که از آدرس کاربر و \"نانس\" تولید می شود مستقر می شود. که برای ثبت قرارداد و ثبت آن در بلاکچین اتریوم استفاده می شود.",
+ "cryptoeconomics-term": "اقتصادهای رمزارزی",
+ "cryptoeconomics-definition": "مطالعهی اصول اقتصاد و ریاضیات به منظور طراحی پلتفرمهای دیجیتالی امن و قابل اتکاء. هدف این است که اطمینان حاصل شود تمامی شرکت کنندگان از قوانین پیروی میکنند و برای مشارکت در انجام عملیاتهای شبکه و ایجاد امنیت، پاداش دریافت میکنند. ",
+ "cryptography-term": "رمزنگاری",
+ "cryptography-definition": "عمل ایمن سازی ارتباطات و داده ها از طریق استفاده از کدها است، به طوری که تنها کسانی که اطلاعات برای آنها در نظر گرفته شده است می توانند آن را بخوانند و پردازش کنند.
شامل تکنیک هایی برای رمزگذاری (تبدیل اطلاعات قابل خواندن به فرمت غیرقابل خواندن) و رمزگشایی (تبدیل مجدد آن به فرمت قابل خواندن) است که محرمانه بودن را تضمین می کند.",
+ "doge-d-term": "Đ",
+ "doge-d-definition": "Đ (D با خط وسط) در انگلیسی باستان، انگلیسی میانه، ایسلندی، و فاروئی برای مخفف یک حرف بزرگ \"Eth\" استفاده می شود. در کلماتی مانند ĐEV یا Đapp (برنامه غیرمتمرکز) استفاده می شود، که در آن Đ حرف نورس \"eth\" است. از eth بزرگ (Ð) نیز برای نماد ارز دیجیتال دوج کوین استفاده می شود. معمولاً در ادبیات قدیمی اتریوم دیده می شود، اما امروزه کمتر مورد استفاده قرار می گیرد.",
+ "dag-term": "DAG",
+ "dag-definition": "DAG مخفف Directed Acyclic Graph است. یک ساختار داده است که از گره ها و پیوندهای بین آنها تشکیل شده است. قبل از مرج، اتریوم در الگوریتم اثبات کار خود، Ethash از DAG استفاده میکرد. ، اما دیگر در اثبات سهام استفاده نمیشود.",
+ "dapp-term": "برنامه غیر متمرکز",
+ "dapp-definition": "دپ، یک برنامه غیرمتمرکز است که بر روی یک شبکه بلاکچین اجرا می شود و خدماتی را بدون یک مرجع کنترل مرکزی ارائه می دهد. اطلاعات بیشتر در مورد برنامه های غیرمتمرکز.
یک دپ حداقل دارای یک قرارداد هوشمند متصل به یک رابط وب است. علاوه بر این، بسیاری از برنامهها شامل فضای ذخیرهسازی غیرمتمرکز و/یا پروتکل و پلتفرم پیام هستند.",
+ "data-availability-term": "دسترسی به دادهها",
+ "data-availability-definition": "هر گره می تواند به طور مستقل تراکنش های یک بلاکچین را به منظور حفظ شفافیت و اعتماد در سیستم تأیید کند.",
+ "decentralization-term": "غیرمتمرکزسازی",
+ "decentralization-definition": "به مفهوم سلب قدرت و اجرای فرآیندها از یک نهاد مرکزی می باشد.",
+ "dao-term": "سازمان خودمختار غیرمتمرکز (DAO)",
+ "dao-definition": "DAO یک سازمان دیجیتالی است که توسط قوانین کدگذاری شده روی بلاکچین اداره می شود، جایی که تصمیمات توسط رای اعضا گرفته می شود، نه یک مرجع مرکزی. اطلاعات بیشتر در مورد سازمانهای مستقل غیرمتمرکز (DAOها).
قدرت رای هر عضو اغلب به تعداد نشانههایی که در اختیار دارند بستگی دارد. هدف DAOها دموکراتیک کردن تصمیم گیری و عملیات، با تمرکز بر شفافیت و اداره جامعه است.",
+ "dex-term": "صرافی غیرمتمرکز (DEX)",
+ "dex-definition": "نوعی برنامه اتریوم که به شما امکان می دهد توکن ها را با همتایان در شبکه مبادله کنید. DEX ها مشمول محدودیت های جغرافیایی مانند صرافی های متمرکز نیستند - هر کسی می تواند شرکت کند.",
+ "deposit-contract-term": "قرارداد واریز",
+ "deposit-contract-definition": "دروازه ای برای سهامگذاری روی اتریوم. قرارداد سپرده گذاری یک قرارداد هوشمند روی اتریوم است که سپردههای ETH را میپذیرد و موجودی اعتبارسنج را مدیریت میکند. اعتبارسنج بدون واریز ETH به این قرارداد نمیتواند فعال شود. قرارداد به ETH و داده های ورودی نیاز دارد. این دادههای ورودی شامل کلید عمومی اعتبارسنج و کلید عمومی برداشت است که توسط کلید خصوصی اعتبارسنج امضا شده است. این دادهها برای شناسایی و تأیید اعتبار توسط شبکه اثبات سهام مورد نیاز هستند.",
+ "defi-term": "DeFi",
+ "defi-definition": "دسته وسیعی از برنامههای اتریوم با هدف ارائه خدمات مالی با پشتیبانی بلاکچین، بدون هیچ واسطهای. اطلاعات بیشتر در مورد امور مالی غیرمتمرکز (DeFi)",
+ "difficulty-term": "سختی",
+ "difficulty-definition": "تنظیمی در سراسر شبکه در شبکههای اثبات کار که میزان متوسط محاسبه مورد نیاز برای یافتن یک نانس معتبر را کنترل میکند. دشواری با تعداد صفرهای اصلی نشان داده می شود که در هش بلوک به دست آمده برای معتبر تلقی شدن آن لازم است. این مفهوم از زمان انتقال به اثبات سهام در اتریوم منسوخ شده است.",
+ "difficulty-bomb-term": "بمب سختی",
+ "difficulty-bomb-definition": "افزایش تصاعدی برنامه ریزی شده در تنظیم اثبات کار سختی که برای ایجاد انگیزه در انتقال طراحی شده است برای اثبات سهام، کاهش شانس فورک. بمب دشواری با ارتقاء مرج منسوخ شد.",
+ "digital-signatures-term": "امضای دیجیتال",
+ "digital-signatures-definition": "یک رشته کوتاه از دادههایی که کاربر برای یک سند با استفاده از کلید خصوصی تولید میکند، بهطوریکه هر کسی با کلید عمومی، یعنی امضا، و سند می تواند تأیید کند که (1) سند توسط مالک آن کلید خصوصی خاص \"امضا\" شده است، و (2) سند پس از امضای آن تغییر نکرده است.",
+ "discovery-term": "اکتشاف",
+ "discovery-definition": "فرآیندی که توسط آن یک نود اتریوم نودهای دیگری را برای اتصال پیدا می کند.",
+ "distributed-hash-table-term": "جدول هش توزیع شده (DHT)",
+ "distributed-hash-table-definition": "یک ساختار داده حاوی جفتهای «(کلید، مقدار)» که توسط گرههای اتریوم برای شناسایی همتایان برای اتصال و تعیین پروتکلهایی برای برقراری ارتباط استفاده میشود.",
+ "double-spend-term": "خرج مجدد",
+ "double-spend-definition": "یک فورک عمدی بلاکچین، که در آن کاربر با مقدار کافی قدرت/سهم ماینینگ، تراکنشی را ارسال میکند که مقداری ارز را خارج از زنجیره انتقال میدهد (مثلاً خروج از پول فیات یا خرید خارج از زنجیره) و سپس بلاکچین را سازماندهی مجدد میکند تا آن تراکنش را حذف کند. یک خرج مجدد موفق، مهاجم را با داراییهای درون و خارج از زنجیره خود رها میکند.",
+ "ecdsa-term": "الگوریتم منحنی امضای دیجیتال (ECDSA)",
+ "ecdsa-definition": "یک الگوریتم رمزنگاری که توسط اتریوم استفاده میشود تا اطمینان حاصل شود داراییها فقط توسط صاحبان آنها خرج شود. این روش ترجیحی برای ایجاد کلیدهای عمومی و خصوصی میباشد. از این الگوریتم در تولید آدرس حساب کاربری و تائید تراکنش استفاده میشود.",
+ "encryption-term": "رمزنگاری",
+ "encryption-definition": "رمزگذاری عبارت است از تبدیل داده های الکترونیکی به فرمی غیرقابل خواندن برای هر کس به جز صاحب \n داده با داشتن کلید رمزگشایی.",
+ "entropy-term": "آنتروپی",
+ "entropy-definition": "در مفهوم رمزنگاری، آنتروپی به معنای سطحی از تصادفی بودن و عدم امکان پیش بینی است. هنگام تولید اطلاعات محرمانه مانند کلید خصوصی، الگوریتمها معمولاً به منبعی با آنتروپی بالا نیازمندند تا از غیرقابل پیش بینی بودن خروجی اطمینان حاصل شود.",
+ "epoch-term": "ایپاک",
+ "epoch-definition": "دوره ای از 32 اسلات، که هر اسلات 12 ثانیه است، در مجموع 6.4 دقیقه. کمیتههای اعتبارسنج در هر ایپاک به دلایل امنیتی مخدوش میشوند. هر ایپاک فرصتی برای نهایی شدن زنجیره دارد. به هر اعتبارسنج در شروع هر ایپاک مسئولیت های جدیدی اختصاص داده می شود. اطلاعات بیشتر در مورد اثبات سهام",
+ "equivocation-term": "مبهمسازی",
+ "equivocation-definition": "وضعیتی که در آن یک اعتبارسنج دو پیام میفرستد که یکدیگر را نقض میکنند. یک مثال ساده این است که فرستنده تراکنش، دو تراکنش با شماره منحصربفرد (nonce) یکسان ارسال کند. مثال دیگر زمانی میباشد که یک پیشنهادکنندهی بلوک، دو بلوک با اندازه و ارتفاع یکسان پیشنهاد دهد (یا برای یک اسلات پیشنهاد دهد).",
+ "eth1-term": "اتر1",
+ "eth1-definition": "'Eth1' اصطلاحی است که به شبکه اصلی اتریوم، یعنی بلاکچین اثبات کار موجود اشاره دارد. این اصطلاح از آن زمان به لطف \"لایه اجرا\" منسوخ شده است. درباره این تغییر نام بیشتر بدانید.",
+ "eth2-term": "Eth2",
+ "eth2-definition": "'Eth2' اصطلاحی است که به مجموعه ای از ارتقاهای پروتکل اتریوم، از جمله انتقال اتریوم به اثبات سهام اشاره دارد. این اصطلاح از آن زمان به لطف \"لایه اجماع\" منسوخ شده است. درباره این تغییر نام بیشتر بدانید.",
+ "eip-term": "پیشنهاد بهبود اتریوم (EIP)",
+ "eip-definition": "یک سند طراحی که اطلاعاتی را به جامعه اتریوم ارائه میکند و یک ویژگی جدید پیشنهادی یا فرآیندها یا محیط آن را توصیف میکند (به ERC مراجعه کنید). معرفی EIP",
+ "ens-term": "سرویس دامنه اتریوم (ENS)",
+ "ens-definition": "سرویس نام اتریوم مانند یک دفترچه تلفن اینترنتی برای آدرسهای اتریوم است. به جای استفاده از آدرس کیف پول های طولانی، ENS به شما امکان می دهد از نام های ساده ای مانند \"john.eth\" برای ارسال و دریافت پول و دارایی های دیجیتال استفاده کنید.
فنی:
رجیستری ENS یک قرارداد که همانطور که در EIP-137 توضیح داده شده است، نقشه برداری از نام دامنه به مالکان و حل کننده ها ارائه می کند. درباره ens.domains بیشتر بخوانید.",
+ "erc-1155-term": "ERC-1155",
+ "erc-1155-definition": "ERC-1155 نوع جدیدی از استاندارد توکن اتریوم مشابه NFT (مانند موارد کلکسیونی منحصر به فرد) است که همچنین امکان ایجاد اقلام قابل تعویض (مانند ارز) را در یک قرارداد هوشمند واحد فراهم می کند.
این امر مدیریت انواع مختلف دارایی های دیجیتال را آسان تر و کارآمدتر می کند، به ویژه برای برنامه هایی مانند بازی های ویدیویی یا مجموعه های دیجیتال.",
+ "erc-20-term": "ERC-20",
+ "erc-20-definition": "ERC-20 استانداردی میباشد که برای ایجاد بیشتر توکنهای شبکه اتریوم از آن استفاده شده است.
نمونهی معروف آن، استیبل کوینهایی مانند DAI و USDC یا توکنهای مبادلهای مانند UNI برای صرافی یونیسواپ میباشد. این توکنها مشابه دارایی و پولی است که در سیستم سنتی استفاده میشود، مانند امتیازات، سیستمهای اعتباری، سهام و غیره.",
+ "erc-721-term": "ERC-721",
+ "erc-721-definition": "NFTها (توکنهای غیرمثلی) با استفاده از مجموعهای استاندارد از قوانین به نام ERC-721 ایجاد میشوند.
توکنهای NFT میتوانند مالکیت هر چیزی منحصربهفرد مانند هنر دیجیتال یا کلکسیونها را نشان دهند و هر توکن ویژگیها و ارزش خاص خود را دارد. هر NFT منحصر به فرد است و به راحتی از هر NTF دیگری قابل تشخیص است.",
+ "execution-client-term": "کلاینت اجرا",
+ "execution-client-definition": "کلاینت های اجرا (که قبلا به عنوان \"کلاینت های Eth1\" شناخته می شدند)، مانند Besu، Erigon، Go-Ethereum (Geth)، Nethermind، وظیفه پردازش و پخش تراکنش ها و مدیریت وضعیت اتریوم را بر عهده دارند. آنها محاسبات را برای هر تراکنش با استفاده از ماشین مجازی اتریوم اجرا میکنند تا از رعایت قوانین پروتکل اطمینان حاصل کنند.",
+ "execution-layer-term": "لایهی اجرا",
+ "execution-layer-definition": "لایه اجرای اتریوم شبکه متشکل از کلاینت های اجراست.",
+ "eoa-term": "حسابی که توسط یا برای کاربران انسانی شبکه Ethereum ایجاد شده است",
+ "eoa-definition": "حساب های دارای مالکیت خارجی (EOAها) رایج ترین نوع حساب اتریوم هستند. آنها توسط یک شخص از طریق کلیدهای خصوصی/عبارت بازیابی کنترل می شوند. اطلاعات بیشتر در مورد کیف پول اتریوم.",
+ "erc-term": "درخواست اتریوم برای نظرات (ERC)",
+ "erc-definition": "ERC (درخواست اتریوم برای نظرات) نوعی مستندات فنی است که در انجمن اتریوم برای پیشنهاد استانداردهای جدید استفاده برای شبکه اتریوم استفاده میشود.
این پیشنهادها میتوانند طیف وسیعی از موضوعات، از جمله استانداردهای جدید توکن (مانند ERC-20 مورد استفاده برای توکنها و ERC-721 برای NFT) را پوشش دهند.",
+ "ethash-term": "Ethash",
+ "ethash-definition": "یک الگوریتم اثبات کار که قبل از انتقال به اثبات سهام بر روی اتریوم از آن استفاده شد. بیشتر بخوانید",
+ "ether-term": "اتر",
+ "ether-definition": "رمزارز بومی اتریوم که معمولاً به آن «ETH» میگویند. در هنگام استفاده از اکوسیستم و برنامه های کاربردی اتریوم برای پوشش کارمزد تراکنش ها استفاده می شود. اطلاعات بیشتر در مورد اتر.",
+ "events-term": "رویدادها",
+ "events-definition": "استفاده از امکانات گزارش EVM را ممکن می سازد. دپ ها میتوانند به رویدادها گوش دهد و از آنها برای راهاندازی فراخوان های JavaScript در رابط کاربری استفاده کنند. اطلاعات بیشتر در مورد رویدادها و گزارشها",
+ "evm-term": "ماشین مجازی اتریوم (EVM)",
+ "evm-definition": "یک ماشین مجازی مبتنی بر پشته که بایت کد را اجرا می کند. در اتریوم، مدل اجرا مشخص میکند که چگونه وضعیت سیستم با توجه به یک سری دستورالعملهای بایت کد و تعداد کمی از دادههای محیطی تغییر میکند. این از طریق یک مدل رسمی از یک ماشین حالت مجازی مشخص می شود. اطلاعات بیشتر در مورد ماشین مجازی اتریوم.",
+ "evm-assembly-language-term": "زبان مونتاژ ماشین مجازی اتریوم - EVM assembly language",
+ "evm-assembly-language-definition": "شکلی از بایت کد EVM که برای انسان قابل خواندن است.",
+ "fallback-function-term": "تابع Fallback",
+ "fallback-function-definition": "یک تابع پیش فرض که در نبود داده یا نام تابع اعلام شده فراخوانی می شود.",
+ "faucet-term": "فاست",
+ "faucet-definition": "سرویسی که از طریققرارداد هوشمند انجام می گیرد و وجوهی را به شکل اتر تست رایگان که بر روی شبکه تست قابل استفاده است عرضه می کند.",
+ "finality-term": "قطعیت",
+ "finality-definition": "نهایی شدن تضمینی است که مجموعه ای از تراکنش ها را نمی توان بدون از دست رفتن مقدار زیادی از ETH تغییر داد.",
+ "finney-term": "فینی",
+ "finney-definition": "یک نام از اتر. 1 finney = 1015 wei. 103 finney = 1 ether.",
+ "fork-term": "فورک",
+ "fork-definition": "تغییر در پروتکل باعث ایجاد یک زنجیره جایگزین می شود.",
+ "fork-choice-algorithm-term": "الگوریتم انتخاب فورک",
+ "fork-choice-algorithm-definition": "الگوریتم مورد استفاده برای شناسایی سر بلاکچین. در اتریوم، سر زنجیره بهعنوان چنگالی با بیشترین «وزن» گواهیها شناخته میشود. وزن حاصل ضرب تعداد تصدیق ها و تراز موثر تایید کننده های تصدیق کننده است.\nاین به این معنی است که سر واقعی زنجیره همانی است که اترهای سهامدار به آن رای داده اند.\nدر لایه اجماع، الگوریتم انتخاب فورک LMD_GHOST نامیده میشود.",
+ "fraud-proof-term": "اثبات تقلب",
+ "fraud-proof-definition": "یک مدل امنیتی برای راهحلهای خاص لایه 2 که در آن، برای افزایش سرعت، تراکنشها قرار میشوند a> به دسته ها تبدیل شده و در یک تراکنش به اتریوم ارسال می شود. سایر شرکتکنندگان شبکه میتوانند تراکنشها را مجدداً اجرا کنند تا بررسی کنند که آیا صادقانه اجرا شدهاند. اگر آنها اختلاف بین داده های ارسال شده و نسخه خود را کشف کنند، می توانند یک مدرک رمزنگاری شده ارسال کنند که نشان می دهد در کجا تقلب صورت گرفته است. برخی از مجموعهها از شواهد اعتبار استفاده میکنند.",
+ "frontier-term": "مرز (فرانتیر)",
+ "frontier-definition": "مرحله توسعه آزمایشی اولیه اتریوم که از ژوئیه 2015 تا مارس 2016 به طول انجامید.",
+ "gas-term": "گاز",
+ "gas-definition": "گس هزینه ای است که برای تراکنش ها و قراردادهای هوشمند در یک بلاکچین، مانند اتریوم، پرداخت می شود. اطلاعات بیشتر در مورد گس و کارمزدها.",
+ "gas-limit-term": "حد گاز",
+ "gas-limit-definition": "بیشترین مقدار گس که یک تراکنش یا بلوک ممکن است مصرف کند.",
+ "gas-price-term": "قیمت گس",
+ "gas-price-definition": "قیمت یک واحد از گس به اتر که در موقع ارسال تراکنش تعیین میشود.",
+ "genesis-block-term": "بلوک ایجاد",
+ "genesis-block-definition": "اولین بلوک در زنجیرهی بلوکی برای راهاندازی یک شبکه خاص و ارزهای رمزنگاری شده آن استفاده می شد.",
+ "geth-term": "Geth",
+ "geth-definition": "Go Ethereum یکی از برجستهترین زیرساخت های پروتکل اتریوم است که با زبان Go نوشته شده است. در geth.ethereum.org بیشتر بخوانید",
+ "gwei-term": "Gwei",
+ "gwei-definition": "مخفف gigawei، نامی از اتر، که معمولاً برای قیمت گاز استفاده میشود. 1 gwei = 109 wei. 109 gwei = 1 اتر.",
+ "hard-fork-term": "فورک سخت",
+ "hard-fork-definition": "واگرایی دائمی در بلاکچین؛ همچنین به عنوان تغییر هاردفورکینگ شناخته می شود.\nیکی از این موارد معمولاً زمانی اتفاق میافتد که گرههای ارتقا نیافته نمیتوانند بلوکهای ایجاد شده توسط گرههای ارتقا یافته را که از قوانین اجماع جدیدتر پیروی میکنند، تأیید کنند. نباید با فورک، سافت فورک، فورک نرم افزاری یا فورک گیت اشتباه گرفته شود.",
+ "hash-term": "هش",
+ "hash-definition": "یک اثر با طول ثابت ورودی با اندازه متغیر که توسط یک تابع هش تولید میشود. (به keccak-256 مراجعه کنید).",
+ "hash-rate-term": "هشریت",
+ "hash-rate-definition": "تعداد محاسبات هش انجام شده در هر ثانیه توسط کامپیوترهایی که نرم افزارهای استخراج را اجرا می کنند.",
+ "homestead-term": "میهن",
+ "holographic-consensus-term": "اجماع هولوگرافیک",
+ "holographic-consensus-definition": "به نحوه تصمیم گیری یک گروه بزرگ با اجازه دادن به گروه کوچکتری از نمایندگان مردم اشاره دارد. سپس همه قبول میکنند که با آن همراهی کنند، به شرطی که اعتماد داشته باشند که گروه کوچک کار خوبی انجام داده است.
در برخی از جوامع آنلاین برای تصمیمگیری سریع بدون نیاز به رأی دادن همه در مورد همه چیز استفاده میشود، در حالی که هنوز مطمئن میشوید که تصمیمها منصفانه هستند و نشاندهنده آن چیزی هستند که بیشتر مردم میخواهند.",
+ "homestead-definition": "مرحله دوم توسعه اتریوم، در مارس 2016 در بلوک 1,150,000 آغاز شد.",
+ "index-term": "ایندکس",
+ "index-definition": "ساختار شبکه ای به منظور بهینهسازی استعلام اطلاعات از سراسر بلاکچین با ارائه یک مسیر کارآمد به منبع ذخیره آن.",
+ "ide-term": "رابط کاربری که معمولاً ترکیبی از ویرایشگر کد ، کامپایلر ، زمان اجرا و اشکال زدایی است",
+ "ide-definition": "یک رابط کاربری که معمولاً یک ویرایشگر کد، کامپایلر، زمان اجرا و دیباگر را ترکیب می کند. اطلاعات بیشتر در مورد محیط های توسعه یکپارچه.",
+ "immutable-deployed-code-problem-term": "مشکل کد مستقر غیرقابل تغییر",
+ "immutable-deployed-code-problem-definition": "هنگامی که کد قرارداد (یا کتابخانه) مستقر شد، تغییر ناپذیر می شود. وشهای استاندارد توسعه نرمافزار متکی بر توانایی رفع اشکالات احتمالی و افزودن ویژگیهای جدید است. نابراین این یک چالش برای توسعه قراردادهای هوشمند است. اطلاعات بیشتر در مورد استقرار قراردادهای هوشمند.",
+ "internal-transaction-term": "تراکنش داخلی",
+ "internal-transaction-definition": "یک تراکنش ارسال شده از یک حساب قرارداد به یک حساب قراردادی دیگر یا یک EOA (به پیام مراجعه کنید).",
+ "issuance-term": "صدور",
+ "issuance-definition": "ضرب اتر جدید برای پاداش دادن به پیشنهاد دهنده بلوک، تصدیق و اطلاع دادن به بقیه شبکه.",
+ "kdf-term": "تابع استخراج کلید (KDF)",
+ "kdf-definition": "همچنین به عنوان \"الگوریتم کشش پسورد\" شناخته می شود، توسط قالب های keystore برای محافظت در برابر حملات بروتفورس، فرهنگ لغت، و جدول رنگین کمان در رمزگذاری عبارت بازیابی با هش کردن مکرر عبارت بازیابی استفاده می شود.",
+ "keystore-term": "Keystore",
+ "keystore-definition": "جفت کلید/آدرس خصوصی هر حساب به صورت یک فایل کلیدی در یک کلاینت اتریوم وجود دارد. اینها فایل های متنی JSON هستند که حاوی کلید خصوصی رمزگذاری شده حساب هستند که فقط با رمز ورود وارد شده در هنگام ایجاد حساب قابل رمزگشایی هستند.",
+ "keccak-256-term": "Keccak-256",
+ "keccak-256-definition": "تابع رمزنگاری هش مورد استفاده در اتریوم. Keccak-256 به عنوان SHA-3 استاندارد شد.",
+ "key-term": "کلید",
+ "key-definition": "در زمینه اتریوم، کلیدها کدهای دیجیتالی هستند: یک کلید عمومی برای دریافت تراکنش ها و یک کلید خصوصی برای دسترسی و ارسال وجوه.
کلیدهای عمومی: این کلیدها را می توان آشکارا به اشتراک گذاشت.
کلیدهای خصوصی: این کلیدها توسط مالک مخفی نگه داشته می شوند.",
+ "layer-1-term": "لایه 1",
+ "layer-1-definition": "لایه 1 به بلاکچین اصلی در یک شبکه بلاکچین چند سطحی اشاره دارد. به عنوان مثال، اتریوم و بیتکوین بلاکچین های لایه یک هستند. بسیاری از بلاکچین های لایه دو، تراکنشهای پرمصرف منابع را در بلاکچین جداگانه خود بارگذاری میکنند، در حالی که همچنان به استفاده از بلاکچین لایه یک اتریوم یا بیتکوین برای اهداف امنیتی ادامه میدهند.",
+ "layer-2-term": "لایه 2",
+ "layer-2-definition": "لایه 2 ها شبکه های دیگری هستند که بر روی شبکه اصلی اتریوم ساخته شده اند تا تراکنش ها را سریعتر و ارزانتر کنند. اطلاعات بیشتر در مورد لایه 2.",
+ "library-term": "کتابخانه",
+ "library-definition": "نوع خاصی از قرارداد که هیچ عملکرد قابل پرداخت، تابع fallback و ذخیره داده ای ندارد. بنابراین، نمی تواند اتر را دریافت یا نگهداری کند یا داده ها را ذخیره کند.\nیک کتابخانه به عنوان کدی که قبلاً مستقر شده است عمل می کند که سایر قراردادها می توانند برای محاسبات فقط خواندنی فراخوانی کنند.\nاطلاعات بیشتر در مورد کتابخانه های قراردادهای هوشمند.",
+ "light-client-term": "کلاینت سبک",
+ "light-client-definition": "یک کلاینت اتریوم که یک کپی محلی از بلاکچین را ذخیره نمیکند، یا بلوکها و تراکنشهاکیف پول را ارائه میکند و میتواند تراکنشها را ایجاد و پخش کند.",
+ "liquidity-term": "نقدینگی",
+ "liquidity-definition": "نقدینگی عبارت است از اینکه یک دارایی چقدر سریع و آسان به پول نقد یا دارایی دیگر تبدیل می شود. صرافی های غیرمتمرکز مانند Uniswap دارای چندین استخر نقدینگی هستند که دارندگان دارایی می توانند دارایی های خود را در آنجا سپرده گذاری کنند که معامله گران می توانند آنها را به روش غیرمتمرکز در ازای دریافت پاداش بخرند و بفروشند.",
+ "liquidity-tokens-term": "توکنهای نقدینگی",
+ "liquidity-tokens-definition": "توکنهای نقدینگی (LST) توکنهای دیجیتالی هستند که برای شرکتکنندگانی صادر میشوند که داراییها را به یک استخر نقدینگی سپرده میکنند، که مجموعهای از وجوه قفل شده در یک قرارداد هوشمند است و برای تسهیل تجارت در یک صرافی غیرمتمرکز (DEX) استفاده میشود.\n
این توکنها نشاندهنده سهم شرکتکننده از استخر هستند و میتوانند بعداً برای سپرده اولیه به اضافه بخشی از کارمزد معاملاتی که توسط فعالیت استخر ایجاد میشود، بازخرید شوند.\nاساساً، توکنهای نقدینگی به عنوان اثبات مالکیت یا سهام در یک استخر نقدینگی عمل میکنند و به دارندگان این امکان را میدهند که پاداشهایی کسب کنند در حالی که نقدینگی لازم را برای دیگران فراهم میکنند تا جفتهای مختلف ارزهای دیجیتال را به طور موثر معامله کنند.",
+ "lmd-ghost-term": "LMD-GHOST",
+ "lmd-ghost-definition": "الگوریتم فورک انتخاب که توسط کلاینت های اجماع اتریوم برای شناسایی رئیس زنجیره استفاده میشود. LMD-GHOST مخفف عبارت Latest Message Driven Greediest Heaviest Observed Subtree است. به این معنی که سر زنجیره بلوکی با بیشترین تجمع امضاها در تاریخ خود است.",
+ "mainnet-term": "شبکه اصلی",
+ "mainnet-definition": "مخفف کلمه \"شبکه اصلی\"، همان بلاکچین اصلی اتریوم است.",
+ "max-fee-per-gas-term": "حداکثر کارمزد در گس",
+ "max-fee-per-gas-definition": "حداکثر کارمزد، حداکثر مطلق مبلغی است که کاربر مایل است به ازای هر واحد گس (gwei) برای دریافت تراکنش گنجانده شده در یک بلوک بپردازد.",
+ "merkle-patricia-tree-term": "درخت مرکل پاتریشیا (MPT)",
+ "merkle-patricia-tree-definition": "ساختار داده ای که در اتریوم برای ذخیره موثر جفت های کلید-مقدار استفاده می شود.",
+ "merkle-root-term": "ریشه مرکل",
+ "merkle-root-definition": "ریشه مرکل هش منفرد بالای درخت مرکل است. تمام تراکنش های داخل یک بلوک را تایید می کند.",
+ "message-term": "پیام",
+ "message-definition": "یک تراکنش داخلی که هرگز سریالی نمیشود و فقط در EVM ارسال میشود.",
+ "message-call-term": "پیام تلفنی",
+ "message-call-definition": "عمل ارسال پیام از یک حساب به حساب دیگر. اگر حساب مقصد با کد EVM مرتبط باشد، ماشین مجازی با وضعیت آن شی شروع می شود و پیام بر اساس آن عمل می کند.",
+ "mev-term": "حداکثر ارزش قابل استخراج (MEV)",
+ "mev-definition": "حداکثر مقدار قابل استخراج از تولید بلوک مازاد بر پاداش استاندارد بلوک و کارمزد گس با گنجاندن، حذف و تغییر ترتیب معاملات در یک بلوک. اطلاعات بیشتر در مورد حداکثر مقدار قابل استخراج (MEV).",
+ "mining-term": "استخراج",
+ "mining-definition": "فرآیند هش کردن مکرر هدر بلوک در حالی که یک nonce افزایش مییابد تا زمانی که نتیجه شامل تعداد دلخواه صفرهای باینری پیشرو باشد. این فرآیندی است که در آن بلوکهای جدید به یک بلاکچین اثبات کار اضافه میشوند. اینگونه بود که اتریوم قبل از انتقال به اثبات سهام ایمن شد.",
+ "miner-term": "استخراجگر",
+ "miner-definition": "یک شبکه گره که با عبور مکرر اثبات کار معتبری را برای بلوکهای جدید پیدا میکند. هش کردن (به Ethash مراجعه کنید). ماینرها دیگر بخشی از اتریوم نیستند - زمانی که اتریوم به اثبات سهام منتقل شد، توسط اعتبارسنج ها جایگزین شدند.",
+ "mint-term": "ضرب سکه",
+ "mint-definition": "مینت/ضرب کردن، فرآیند ایجاد توکن های جدید و به گردش درآوردن آنها است تا بتوان از آنها استفاده کرد. این یک مکانیسم غیرمتمرکز برای ایجاد یک توکن جدید بدون دخالت شخص ثالث است.",
+ "multisig-term": "قابلیت چندامضایی",
+ "multisig-definition": "Multisig (چند امضا) به کیف پول یا حساب دیجیتالی اطلاق میشود که برای انجام تراکنشها به چندین امضا یا تأیید نیاز دارد و امنیت را افزایش میدهد.
این در مقایسه با حسابهای سنتی تک امضایی که تنها به تأیید یک نفر نیاز است، امنیت بیشتری میافزاید.",
+ "network-term": "شبکه",
+ "network-definition": "اشاره به شبکه اتریوم، یک شبکه همتا به همتا که تراکنش ها و بلوک ها را به هر گره اتریوم (شرکت کننده شبکه) منتشر می کند. اطلاعات بیشتر در مورد شبکهها.",
+ "network-hashrate-term": "هشریت شبکه",
+ "network-hashrate-definition": "هش ریت جمعی که توسط کل شبکه استخراج تولید می شود. زمانی که اتریوم به سمت اثبات سهام رفت، استخراج در اتریوم تعطیل شد.",
+ "nft-term": "توکن غیرقابل تعویض (NFT)",
+ "nft-definition": "توکن غیرقابل تعویض (NFT) یک آیتم دیجیتال منحصر به فرد است که می توانید آن را داشته باشید، مانند آثار هنری یا کلکسیونی که توسط فناوری بلاکین تأیید شده است. اطلاعات بیشتر در مورد توکنهای غیرقابل تعویض (NFT).",
+ "node-term": "گره",
+ "node-definition": "یک کلاینت نرم افزاری که در شبکه شرکت می کند. اطلاعات بیشتر در مورد گره ها و کلاینت ها.",
+ "nonce-term": "Nonce",
+ "nonce-definition": "در مبحث رمزنگاری، مقداری که فقط یک بار قابل استفاده است. نانس یک حساب یک شمارنده تراکنش در هر حساب است که برای جلوگیری از حملات مجدد استفاده می شود.",
+ "off-chain-term": "برونزنجیرهای",
+ "off-chain-definition": "برونزنجیره ای یا آفچین به معنای هر تراکنش یا دادهای است که خارج از بلاکچین وجود دارد. از آنجایی که انجام هر تراکنش در زنجیره می تواند گران و ناکارآمد باشد، ابزارهای شخص ثالث مانند اوراکل ها که داده های قیمت گذاری را مدیریت می کنند، یا راهکارهای لایه2 که توان عملیاتی بالاتری از تراکنشها را انجام میدهند، بخش عمدهای از کارهای پردازشی را خارج از زنجیره انجام میدهند و اطلاعات آنچین را در فواصل زمانی کمتر ارسال میکنند.",
+ "ommer-term": "بلوک Ommer (عمو)",
+ "ommer-definition": "وقتی یک miner اثبات کار، یک بلوک معتبر پیدا میکند، ممکن است معدنچی دیگری منتشر کرده باشد. یک بلوک رقیب که ابتدا به نوک بلاکچین اضافه می شود. این بلوک معتبر، اما قدیمی، میتواند توسط بلوکهای جدیدتر بهعنوان ommers گنجانده شود و یک پاداش بلوک جزئی دریافت کند. اصطلاح \"ommer\" اصطلاح ترجیحی از نظر جنسیتی خنثی برای خواهر یا برادر بلوک والدین است، اما گاهی اوقات به آن \"عمو\" نیز گفته می شود. زمانی که اتریوم یک شبکه اثبات کار بود، این برای اتریوم رایج بود. اکنون که اتریوم از اثبات سهام استفاده میکند، تنها یک پیشنهاد دهنده بلوک در هر اسلات انتخاب میشود.",
+ "on-chain-term": "آنچین",
+ "on-chain-definition": "به اقدامات یا تراکنشهایی اشاره دارد که روی بلاک چین اتفاق میافتند و به صورت عمومی در دسترس هستند.
فکر کنید چیزی در یک دفترچه یادداشت مشترک و بزرگ مینویسید که همه میتوانند ببینند و بررسی کنند، و مطمئن شوید که هر چیزی نوشته شده است (مانند ارسال پول دیجیتال یا بستن قرارداد) دائمی است و قابل تغییر یا پاک کردن نیست.",
+ "optimistic-rollup-term": "رول آپ خوش بینانه",
+ "optimistic-rollup-definition": "رولآپ خوشبینانه یک راه حل لایه 2 است که به تراکنش ها در اتریوم سرعت می بخشد، با این فرض که به طور پیش فرض معتبر هستند مگر اینکه به چالش کشیده شوند. اطلاعات بیشتر در مورد رولآپ خوشبینانه.",
+ "oracle-term": "اوراکل",
+ "oracle-definition": "اوراکل پلی است بین بلاکچین و دنیای واقعی. آنها بهعنوان APIهای زنجیرهای عمل میکنند که میتوان برای اطلاعات جستجو کرد و در قراردادهای هوشمند استفاده کرد.. اطلاعات بیشتر در مورد اوراکل.",
+ "peer-term": "همتا",
+ "peer-definition": "رایانه های به هم متصل شده که نرمافزار کلاینت اتریوم را اجرا می کنند که دارای نسخه های یکسانی از زنجیرهی بلوکی هستند.",
+ "peer-to-peer-network-term": "شبکه همتا به همتا",
+ "peer-to-peer-network-definition": "شبکهای از رایانهها (همتایان) که در مجموع قادر به انجام عملکردها بدون نیاز به سرویسهای متمرکز و مبتنی بر سرور هستند.
این راهاندازی اغلب استفاده میشود. برای به اشتراک گذاری فایل ها (یعنی بیت تورنت)، اطلاعات یا ارزهای دیجیتال، امکان تبادل مستقیم تر و بالقوه کارآمدتر بین کاربران را فراهم می کند.",
+ "permissionless-term": "بدون نیاز به مجوز",
+ "permissionless-definition": "بدون مجوز یعنی هر کسی می تواند به سیستمی مانند اتریوم بپیوندد و از آن استفاده کند. شرکت برای همه آزاد است و نیازی به تایید ندارد.",
+ "plasma-term": "پلاسما",
+ "plasma-definition": "یک راهحل مقیاسبندی خارج از زنجیره که از اثبات تقلب استفاده میکند، مانند رولآپ خوشبینانه. پلاسما محدود به تراکنشهای ساده مانند انتقال توکن و مبادله است. اطلاعات بیشتر در مورد پلاسما.",
+ "private-key-term": "کلید خصوصی",
+ "private-key-definition": "کلید خصوصی یک کد مخفی است که ثابت می کند شما صاحب پول دیجیتال خود هستید و به شما امکان می دهد آن را خرج کنید، مانند یک پین برای حساب خود. آن را به اشتراک نگذارید.",
+ "public-goods-term": "کالاهای عمومی",
+ "public-goods-definition": "کالاهای عمومی چیزهایی هستند که همه می توانند به صورت رایگان از آن استفاده کنند، مانند پارک ها یا هوای پاک، و استفاده از آنها مانع استفاده دیگران از آنها نمی شود. دولتها اغلب این موارد را ارائه میدهند، زیرا کسبوکارها معمولاً این کار را نمیکنند، زیرا نمیتوانند به راحتی از مردم برای استفاده از آنها هزینه دریافت کنند.",
+ "private-chain-term": "زنجیره خصوصی",
+ "private-chain-definition": "یک زنجیره بلوکی کاملا خصوصی که تنها افرادی که اجازه دارند میتوانند به آن دسترسی پیدا کنند، که به شکل عمومی قابل دسترس ما نیست.",
+ "poap-term": "POAP",
+ "poap-definition": "پروتکل اثبات حضور برای ایجاد یک مجموعه دیجیتال (NFT) استفاده می شود که ثابت می کند در یک رویداد یا فعالیت خاص شرکت کرده اید.",
+ "pos-term": "اثبات سهام (PoS)",
+ "pos-definition": "روشی که با آن هدف پروتکل بلاک چین ارز دیجیتال دستیابی به اجماع توزیع شده است. اثبات هام از کاربران میخواهد که مالکیت مقدار معینی از ارزهای دیجیتال («سهم» آنها در شبکه) را اثبات کنند تا بتوانند در اعتبارسنجی تراکنشها شرکت کنند. اطلاعات بیشتر در مورد اثبات سهام.",
+ "pow-term": "اثبات کار (PoW)",
+ "pow-definition": "یک مکانیسم امنیتی برای بلاک چین که به گرهها نیاز دارد تا انرژی را در قالب محاسبات برای یافتن یک مقدار مشخص صرف کنند.",
+ "proto-danksharding-term": "Proto-Danksharding",
+ "proto-danksharding-definition": "یک نوع تراکنش جدید که \"حباب\" داده ها را برای اتریوم می پذیرد. این دادههای \"حباب\" بهمدت 4096 دوره (~18.2 روز) بهطور موقت در زنجیره بیکن ذخیره میشوند و میتوانند به صورت اختیاری پس از آن هرس شوند تا به کاهش نیازهای سختافزاری برای اپراتورهای گره کمک کند.",
+ "public-key-term": "کلید عمومی",
+ "public-key-definition": "کلید عمومی مجموعهای از نویسهها است که به دیگران اجازه میدهد ارز دیجیتالی را به صورت امن برای شما ارسال کنند، مانند آدرس ایمیل برای پول.",
+ "quadratic-voting-term": "رای گیری درجه دوم",
+ "quadratic-voting-definition": "یک روش رای گیری است که در آن رای دهندگان احساس خود را نسبت به مسائل ابراز می کنند. به رای دهندگان این امکان را می دهد که نه تنها ترجیح خود را نشان دهند، بلکه شدت ترجیح خود را نیز نشان دهند.",
+ "receipt-term": "رسید",
+ "receipt-definition": "دادههایی که توسط یک کلاینت اتریوم برای نشان دادن نتیجه یک تراکنش خاص، از جمله یک هش بازگردانده میشود. از تراکنش، شماره block آن، مقدار گاز استفاده شده، و در صورت از استقرار یک قرارداد هوشمند، آدرس قرارداد.",
+ "recovery-phrase-term": "عبارت سید / عبارت بازیابی",
+ "recovery-phrase-definition": "لیستی از کلماتی که هنگام ایجاد یک کیف پول دیجیتال به شما داده می شود. این رمز عبور مانند رمز عبور عمل می کند که می تواند به شما کمک کند در صورت از دست دادن دسترسی به کیف پول خود بازگردید و مطمئن شوید که پول دیجیتال یا توکن های خود را از دست نمی دهید.",
+ "re-entrancy-attack-term": "حمله ورود دوباره",
+ "re-entrancy-attack-definition": "حمله ای که متشکل از یک قرارداد مهاجم است که تابع قرارداد قربانی را فراخوانی می کند، به گونه ای که در طول اجرا، قربانی دوباره به صورت بازگشتی، قرارداد مهاجم را فراخوانی می کند. به عنوان مثال، این امر میتواند منجر به سرقت وجوه با نادیده گرفتن بخشهایی از قرارداد قربانی شود که موجودیها را بهروزرسانی میکند یا مبالغ برداشت را محاسبه میکند. جزئیات بیشتر درباره حمله reentrancy.",
+ "reward-term": "پاداش",
+ "reward-definition": "مقداری اتر اعطا شده به اعتبارسنج که عملکردهای خاصی را انجام می دهد، از جمله پیشنهاد یک بلوک یا شرکت در یک کمیته همگام سازی، در هر اسلات.",
+ "rlp-term": "پیشوند طول بازگشتی (RLP)",
+ "rlp-definition": "یک استاندارد رمزگذاری که توسط توسعه دهندگان اتریوم طراحی شده است تا اشیا (ساختارهای داده) با پیچیدگی و طول دلخواه را رمزگذاری و سریال سازی کند.",
+ "rollups-term": "رولآپ ها",
+ "rollups-definition": "نوعی راه حل مقیاسپذیری لایه2 که چندین تراکنش را دسته بندی می کند و آنها را در یک تراکنش به شبکه اصلی اتریوم ارسال می کند. این امکان کاهش در هزینههای گس و افزایش توان عملیاتی تراکنش را فراهم میکند. رولآپ های خوشبینانه و دانش صفر وجود دارند که از روشهای امنیتی مختلفی برای ارائه این دستاوردهای مقیاسپذیری استفاده میکنند.\n اطلاعات بیشتر در مورد رولآپ.",
+ "rpc-term": "فراخوانی روش از راه دور (RPC)",
+ "rpc-definition": "RPC به یک کامپیوتر اجازه میدهد تا داده یا اقدامی را از طریق شبکه از دیگری درخواست کند، مانند درخواست اطلاعات با کنترل از راه دور.",
+ "sha-term": "الگوریتم هش امن (SHA)",
+ "sha-definition": "خانواده ای از تابع های رمزنگاری هش که توسط National Institute of Standards and Technology (NIST) منتشر شده است.",
+ "serialization-term": "سریالی کردن",
+ "serialization-definition": "فرآیند تبدیل یک ساختار داده به دنباله ای از بایت ها.",
+ "sequencer-term": "ترتیب دهنده",
+ "sequencer-definition": "ترتیبدهنده برنامهای است که مسئول سفارش تراکنشها در شبکه بلاک چین است، به ویژه در راهحلهای مقیاسپذیری لایه2.",
+ "shard-term": "شارد / خردهزنجیره",
+ "shard-definition": "زنجیرههای تکهای بخشهای مجزایی از کل بلاک چین هستند که زیرمجموعههای اعتبارسنج میتوانند مسئول آن باشند. در ابتدا در نظر گرفته شده بود که اتریوم به میلیونها تراکنش در ثانیه مقیاس شود، اما اکنون با توسعه سریع مقیاسگذاری با استفاده از رولآپ ها جایگزین شده است.",
+ "sidechain-term": "زنجیره جانبی",
+ "sidechain-definition": "یک راه حل مقیاسپذیری که از یک زنجیره جداگانه با قوانین اجماع متفاوت و اغلب سریعتر استفاده میکند.\nبرای اتصال این زنجیره های جانبی به شبکه اصلی به یک پل نیاز است.\nرول آپ ها نیز از زنجیرههای جانبی استفاده میکنند، اما در عوض با شبکه اصلی همکاری میکنند.\nاطلاعات بیشتر در مورد زنجیرههای جانبی.",
+ "signing-term": "امضا کردن",
+ "signing-definition": "نشان دادن از لحاظ رمزنگاری این که یک تراکنش توسط دارنده یک کلید خصوصی خاص تایید شده است.",
+ "singleton-term": "Singleton",
+ "singleton-definition": "یک اصطلاح برنامه نویسی کامپیوتری که شیئی را توصیف می کند که فقط یک نمونه از آن می تواند وجود داشته باشد.",
+ "slasher-term": "جریمه کننده",
+ "slasher-definition": "جریمه کننده موجودیتی است که گواهینامه ها را برای جست و جوی جرایم قابل جریمه اسکن می کند. جریمه کردن در شبکه پخش می شود، و پیشنهاد دهنده بلوک بعدی، گواهی را به بلوک اضافه می کند. سپس پیشنهاد دهنده بلوک برای جریمه کردن اعتبارسنج مخرب پاداشی دریافت می کند.",
+ "slot-term": "اسلات",
+ "slot-definition": "دوره زمانی (12 ثانیه) که در آن بلوکهای جدید میتوانند توسط اعتبارسنج در سیستم اثبات سهام پیشنهاد شوند.\nیک اسلات ممکن است خالی باشد. 32 اسلات یک ایپاک را تشکیل میدهند. جزئیات بیشتر در مورد اثبات سهام.",
+ "smart-contract-term": "قرارداد هوشمند",
+ "smart-contract-definition": "قرارداد هوشمند برنامهای است که بهطور خودکار توافقنامهها را روی یک بلاکچین اجرا میکند، مانند یک قرارداد دیجیتالی خوداجرا. مقدمه ای بر قراردادهای هوشمند.",
+ "snark-term": "SNARK",
+ "snark-definition": "SNARK مخفف «برهان مختصر غیر تعاملی دانش»، نوعی اثبات دانش صفر است. اطلاعات بیشتر در مورد رولآپهای دانش-صفر .",
+ "soft-fork-term": "فورک نرم",
+ "soft-fork-definition": "یک واگرایی در بلاکچین که زمانی رخ میدهد که قوانین اجماع تغییر کند. برخلاف هارد فورک، سافت فورک با عقبگرد سازگار است. گره های ارتقا یافته می توانند بلوک های ایجاد شده توسط گره های ارتقا نیافته را تا زمانی که از قوانین اجماع جدید پیروی کنند اعتبارسنجی کنند.",
+ "solidity-term": "Solidity",
+ "solidity-definition": "یک زبان برنامه نویسی رویه ای (ضروری) با نحوی که شبیه جاوا اسکریپت، C++ یا جاوا است. محبوب ترین و پرکاربردترین زبان برای قراردادهای هوشمند اتریوم. ایجاد شده توسط دکتر گاوین وود. اطلاعات بیشتر در مورد سالیدیتی.",
+ "solidity-inline-assembly-term": "Solidity inline assembly",
+ "solidity-inline-assembly-definition": "زبان اسمبلی EVM در برنامه سالیدیتی. پشتیبانی سالیدیتی از اسمبلی درون خطی نوشتن عملیات خاص را آسان تر می کند.",
+ "stablecoin-term": "استیبل کوین",
+ "stablecoin-definition": "استیبل کوین نوعی رمزارز است که برای داشتن یک ارزش پایدار طراحی شده است که اغلب به یک ارز یا کالا (مانند دلار آمریکا) متصل می شود تا نوسان قیمت را به حداقل برساند. اطلاعات بیشتر در مورد استیبل کوین.",
+ "staking-term": "سهام گذاری",
+ "staking-definition": "سپرده گذاری مقداری اتر (سهم شما) برای تبدیل شدن به یک اعتبارسنج و ایمن کردن شبکه. یک اعتبارسنج تراکنشها را بررسی میکند و بلوکها را تحت یک مدل اجماع به نام اثابت سهام پیشنهاد میکند. سهامگذاری به شما انگیزه اقتصادی می دهد تا در راستای منافع شبکه عمل کنید. برای انجام وظایف اعتبارسنج خود جوایزی دریافت خواهید کرد، اما اگر این کار را نکنید مقادیر متفاوتی از ETH را از دست خواهید داد. اطلاعات بیشتر در مورد سهامگذاری در اتریوم.",
+ "staking-pool-term": "استخر سهامگذاری",
+ "staking-pool-definition": "ETH ترکیبی بیش از یک سهامگذار اتریوم، برای رسیدن به 32 اتریوم مورد نیاز برای فعال کردن مجموعه ای از کلیدهای اعتبارسنج استفاده می شود. یک اپراتور گره از این کلیدها برای شرکت در اجماع استفاده می کند و پاداش های بلوک بین سهامگذاران مشارکت کننده تقسیم می شود. استخرهای سهامگذاری یا سهامگذاری نیابتی برای پروتکل اتریوم بومی نیستند، اما راهکارهای زیادی توسط جامعه ایجاد شده است.\nاطلاعات بیشتر در مورد سهامگذاری دستهجمعی.",
+ "stark-term": "استارک",
+ "stark-definition": "STARK مخفف «استدلال شفاف مقیاسپذیر دانش»، نوعی اثبات دانش صفر است. اطلاعات بیشتر در مورد رولآپهای دانش-صفر.",
+ "state-term": "وضعیت",
+ "state-definition": "یک تصویر از تمام موجودی ها و داده ها در یک نقطه خاص از زمان در بلاکچین، که معمولاً به شرایط یک بلوک خاص اشاره دارد.",
+ "state-channels-term": "عملیاتهای برونزنجیرهای",
+ "state-channels-definition": "یک راهکار لایه 2 که در آن کانالی بین شرکتکنندگان راهاندازی میشود، جایی که میتوانند آزادانه و ارزان تراکنش کنند. فقط یک تراکنش برای راهاندازی کانال و بستن کانال به شبکه اصلی ارسال میشود. این امکان انجام تراکنش بسیار بالایی را فراهم می کند، اما به دانستن تعداد شرکت کنندگان از قبل و قفل کردن وجوه متکی است. اطلاعات بیشتر در مورد کانالهای حالت.",
+ "supermajority-term": "اکثریت مطلق",
+ "supermajority-definition": "اکثریت مطلق اصطلاحی است که برای مقداری بیش از دوسوم (66%) از کل اتر سهامگذاری شده که اتریوم را ایمن می کند، داده می شود. برای نهایی شدن بلوک ها در بیکن چین، رأی اکثریت مطلق لازم است.",
+ "sybil-attack-term": "حمله Sybil",
+ "sybil-attack-definition": "حملات Sybil به افرادی اشاره دارد که یک سیستم را فریب می دهند تا فکر کنند چندین نفر هستند تا نفوذ خود را افزایش دهند.",
+ "syncing-term": "همگامسازی",
+ "syncing-definition": "فرآیند بارگذاریِ آخرین نسخه ی کامل یک زنجیرهی بلوکی به یک گره.",
+ "sync-committee-term": "کمیته همگامسازی",
+ "sync-committee-definition": "یک کمیته همگامسازی گروهی از اعتبارسنجها بهطور تصادفی انتخاب شده است که هر 27 ساعت یکبار تازهسازی میشود. هدف آنها افزودن امضای خود به هدرهای بلوک معتبر است. کمیتههای همگامسازی به کلاینتهای سبک اجازه میدهند تا بدون نیاز به دسترسی به کل مجموعه اعتبارسنج، سر زنجیره را زیر نظر داشته باشند.",
+ "szabo-term": "سابو",
+ "szabo-definition": "یک نام از اتر. 1 زابو= 1012 وی. 106 زابو= 1 اتر.",
+ "terminal-total-difficulty-term": "سختی کل ترمینال (TTD)",
+ "terminal-total-difficulty-definition": "سختی کل مجموع دشواری استخراج Ethash برای همه بلوک ها تا یک نقطه خاص در زنجیره بلوک است. سختی کل ترمینال یک مقدار مشخص برای سختی کل است که به عنوان محرک برای کلاینتهای اجرا برای خاموش کردن ماینینگ و مسدود کردن توابع شایعه استفاده میشود و شبکه را قادر میسازد تا به اثبات سهام تبدیل شود. این واژه دیگر کاربرد ندارد زیرا اتریوم به اثبات سهام تغییر یافت.",
+ "testnet-term": "شبکهی تست",
+ "testnet-definition": "مخفف «شبکه آزمایشی»، شبکهای که برای شبیهسازی رفتار شبکه اصلی اتریوم استفاده میشود.",
+ "token-term": "توکن",
+ "token-definition": "یک کالای مجازی قابل معامله که توسط قرارداد ihd هوشمند در زنجیرهی بلوکی اتریوم تعریف شده است.",
+ "transaction-term": "تراکنش",
+ "transaction-definition": "دادههای متعهد به بلاکچین اتریوم که توسط حساب مبدا امضا شدهاند و یک آدرس خاص را هدف قرار میدهند. این تراکنش حاوی ابردادههایی مانند محدودیت گاز برای آن تراکنش است. اطلاعات بیشتر در مورد تراکنشها.",
+ "transaction-fee-term": "کارمزد تراکنش",
+ "transaction-fee-definition": "هزینه ای که هر زمان که از شبکه اتریوم استفاده می کنید باید پرداخت کنید. مثلاً ارسال وجوه از کیف پول شما یا تعامل با یک دپ، مانند تعویض توکن یا خرید یک کلکسیون. شما می توانید به این موضوع همانند هزینه خدمات فکر کنید. این هزینه بر اساس شلوغی شبکه تغییر خواهد کرد. این به این دلیل است که اعتبارسنجها، یعنی افرادی که مسئول پردازش تراکنش شما هستند، احتمالاً تراکنشهایی با کارمزد بالاتر را در اولویت قرار میدهند - بنابراین ازدحام باعث افزایش قیمت میشود.
در سطح فنی، کارمزد تراکنش شما به میزان گس مورد نیاز تراکنش شما مربوط می شود.
کاهش کارمزد تراکنش موضوعی است که در حال حاضر بسیار مورد توجه است. به لایه 2 مراجعه کنید.",
+ "trust-assumptions-term": "مفروضات اعتماد",
+ "trust-assumptions-definition": "مفروضات اعتماد، باورهای اساسی در مورد ایمنی و قابل اعتماد بودن یک سیستم هستند که به آنچه ما اعتماد داریم برای عملکرد سیستم راهنمایی می کنند.",
+ "trustlessness-term": "بی نیازی از اعتماد",
+ "trustlessness-definition": "توانایی یک شبکه برای میانجیگری تراکنش ها بدون اینکه هیچ یک از طرفین درگیر نیاز به اعتماد به شخص ثالث داشته باشند.",
+ "turing-complete-term": "Turing complete",
+ "turing-complete-definition": "مفهومی که از نام ریاضیدان انگلیسی و دانشمند کامپیوتر آلن تورینگ نامگذاری شده است - سیستمی از قوانین دستکاری داده ها (مانند مجموعه دستورات رایانه، زبان برنامه نویسی یا خودکار سلولی) به عنوان \"تورینگ کامل\" یا \"از نظر محاسباتی جهانی\" گفته می شود. می توان از آن برای شبیه سازی هر ماشین تورینگ استفاده کرد.",
+ "validator-term": "اعتبارسنج",
+ "validator-definition": "یک گره در سیستم اثبات سهام مسئول ذخیره دادهها، پردازش تراکنشها، و اضافه کردن بلوک های جدید به بلاکچین است. برای فعال کردن نرمافزار اعتبارسنج، باید بتوانید 32 عدد ETH را سهامگذاری کنید. اطلاعات بیشتر در مورد سهامگذاری در اتریوم.",
+ "validator-lifecycle-term": "چرخه حیات اعتبارسنج",
+ "validator-lifecycle-definition": "دنباله ای از حالت هایی که اعتبارسنج می تواند در آنها وجود داشته باشد. این موارد عبارتند از:
\n- واریز شده: حداقل 32 سکه ETH به قرارداد سپردهگذاری توسط اعتبارسنج واریز شده است
- درانتظار: اعتبارسنج در صف فعالسازی است و منتظر است تا توسط اعتبارسنجهای موجود به شبکه به او رای داده شود
- فعال: در حال حاضر در حال تأیید و پیشنهاد بلوک ها است
- جریمه شده: اعتبارسنج رفتار نادرست داشته و در حال جریمه شدن است
- خروج: اعتبارسنج برای خروج داوطلبانه یا به دلیل اخراج از شبکه علامتگذاری شده است.
",
+ "validity-proof-term": "اثبات اعتبار",
+ "validity-proof-definition": "یک مدل امنیتی برای راهکارهای خاص لایه2 که برای افزایش سرعت، تراکنشها به صورت دستهای جمع میشوند و در یک تراکنش به اتریوم ارسال میشوند.\nمحاسبه تراکنش خارج از زنجیره انجام می شود و سپس با اثبات اعتبار آنها به زنجیره اصلی ارائه می شود.\nاین روش با حفظ امنیت، میزان تراکنش های ممکن را افزایش می دهد.\nبرخی از رولآپها از اثبات تقلب استفاده میکنند.\nاطلاعات بیشتر در مورد رولآپهای دانش-صفر.",
+ "validium-term": "ولیدیوم",
+ "validium-definition": "راه حلی خارج از زنجیره که از اثبات اعتبار برای بهبود توان عملیاتی تراکنش استفاده می کند. برخلاف رولآپهای دانش صفر، دادههای اعتباری در شبکه اصلی لایه1 ذخیره نمیشوند. اطلاعات بیشتر در مورد validium.",
+ "vyper-term": "Vyper",
+ "vyper-definition": "یک زبان برنامه نویسی سطح بالا با سینتکس شبیه پایتون. قصد دارد به یک زبان کاربردی خالص نزدیک شود. توسط ویتالیک بوترین خلق شده است. جزئیات بیشتر در مورد Vyper.",
+ "wallet-term": "کیف پول",
+ "wallet-definition": "یک کیف پول یک ابزار دیجیتالی برای ذخیره، ارسال و دریافت رمزارز است، مانند یک کیف پول مجازی برای پول آنلاین شما. اطلاعات بیشتر در مورد کیف پول اتریوم.",
+ "web2-term": "Web2",
+ "web2-definition": "آیا اینترنت فعلی متمرکز بر محتوای تولید شده توسط کاربر و رسانه های اجتماعی است که توسط شرکت های کمی کنترل می شود.\n وی3 یک اعتقاد رمزینه است که کاربران باید داده ها و تراکنش های خود را به جای آن کنترل کنند.",
+ "web3-term": "Web3",
+ "web3-definition": "وب3 اینترنت جدید با بلاکچین است که در آن کاربران داده ها و تراکنش های خود را کنترل می کنند نه شرکت ها. نیازی به اشتراک گذاری اطلاعات شخصی نیست. جزئیات بیشتر درباره وب3.",
+ "wei-term": "Wei",
+ "wei-definition": "کوچکترین اسم اتر. 1018 وی = 1 اتر.",
+ "zero-address-term": "آدرس صفر",
+ "zero-address-definition": "یک آدرس اتریوم که به طور کامل از صفر تشکیل شده است که اغلب به عنوان آدرسی برای حذف توکن ها از گردش مالکیت استفاده می شود.\nتمایزی بین توکن هایی که به طور رسمی از فهرست قراردادهای هوشمند از طریق روش burn() حذف می شوند و آنهایی که به این آدرس ارسال می شوند، مشخص می شوند.",
+ "zk-proof-term": "اثبات دانش-صفر",
+ "zk-proof-definition": "اثبات دانش صفر یک روش رمزنگاری است که به فرد اجازه میدهد بدون ارائه اطلاعات اضافی صحت یک جمله را ثابت کند. اطلاعات بیشتر در مورد رولآپهای دانش-صفر.",
+ "zk-rollup-term": "رول آپ دانش صفر",
+ "zk-rollup-definition": "یک رولآپ از تراکنشها که از اثباتهای اعتبار برای ارائه افزایش توان عملیاتی تراکنش لایه2 در حین استفاده از امنیت ارائه شده توسط شبکه اصلی (لایه1) استفاده میکند. اگرچه آنها نمیتوانند انواع تراکنشهای پیچیده، مانند رولآپهای آپتیمیستیک و خوشبینانه را مدیریت کنند، اما مشکل تأخیر ندارند زیرا تراکنشها هنگام ارسال به طور قابل اثباتی معتبر هستند. اطلاعات بیشتر در مورد رولآپهای دانش صفر."
+}
diff --git a/src/intl/fa/learn-quizzes.json b/src/intl/fa/learn-quizzes.json
index 295f0e73137..9f5a467c2cf 100644
--- a/src/intl/fa/learn-quizzes.json
+++ b/src/intl/fa/learn-quizzes.json
@@ -10,7 +10,8 @@
"explanation": "توضیح",
"next-question": "سوال بعدی",
"next-quiz": "امتحان بعدی",
- "page-assets-merge": "ادغام",
+ "question-number": "سؤال شماره {{number}}:",
+ "page-assets-merge": "The Merge (ادغام)",
"passed": "شما قبول شدید!",
"questions": "سؤالات",
"questions-answered": "سوالات پاسخ داده شده:",
@@ -49,7 +50,7 @@
"a003-prompt": "چه کسی اتریوم را اجرا می کند?",
"a003-a-label": "توسعهدهندگان",
"a003-a-explanation": "توسعهدهندگان نقش اساسی در ساخت و بهبود اتریوم دارند، اما آنها گروهی نیستند که باعث ادامه اجرای اتریوم میشود.",
- "a003-b-label": "Miners",
+ "a003-b-label": "ماینرها",
"a003-b-explanation": "استخراج، دیگر در اتریوم بعد از «ادغام» ممکن نبوده است. دیگر «استخراجگرها» در شبکه اتریوم وجود ندارند.",
"a003-c-label": "بنیاد اتریوم",
"a003-c-explanation": "بنیاد اتریوم دیگر نقش عمدهای در اجرای روزانه گرههای شبکه اتریوم ندارد.",
@@ -97,24 +98,24 @@
"b003-c-explanation": "سهام گذاران نیاز به سختافزار قدرتمند برای سهام گذاری اتر ندارند. اتریوم بعد از «ادغام» دیگر از مکانیزم اثبات کار استفاده نمی کند.",
"b003-d-label": "سهام گذاران، پیش از قبول شدن به عنوان اعتبارسنج، تحت فرایند تایید هویت قرار میگیرند",
"b003-d-explanation": "سهام گذاری در شبکه اتریوم بدون نیاز به مجوز و احراز هویت است.",
- "b004-prompt": "اتر با ارزش است چون:",
- "b004-a-label": "اتر برای انجام هر کار در شبکه اتریوم مورد نیاز است",
- "b004-a-explanation": "این پاسخ تا حدی درست است، اما این تنها یکی از دلایل با ارزش بودن اتر است.",
- "b004-b-label": "اتر یک رمزارز همتا-به-همتای سانسورنشدنی است",
- "b004-b-explanation": "این پاسخ تا حدی درست است، اما این تنها یکی از دلایل با ارزش بودن اتر است.",
- "b004-c-label": "ETH به عنوان وثیقه برای گرفتن وام در کریپتو استفاده میشود",
- "b004-c-explanation": "این پاسخ تا حدی درست است، اما این تنها یکی از دلایل با ارزش بودن اتر است.",
+ "b004-prompt": "اتر میتواند برای موارد زیر استفاده شود:",
+ "b004-a-label": "پرداخت کارمزد تراکنش روی اتریوم",
+ "b004-a-explanation": "این پاسخ تا حدی درست است، اما این تنها یکی از بسیاری از مواردی است که اتر میتواند برای آن استفاده شود.",
+ "b004-b-label": "پرداختهای همتا به همتای غیرقابل سانسور",
+ "b004-b-explanation": "این پاسخ تا حدی درست است، اما این تنها یکی از بسیاری از مواردی است که اتر میتواند برای آن استفاده شود.",
+ "b004-c-label": "وثیقه برای وامهای رمزارزی",
+ "b004-c-explanation": "این پاسخ تا حدی درست است، اما این تنها یکی از بسیاری از مواردی است که اتر میتواند برای آن استفاده شود.",
"b004-d-label": "تمام موارد فوق",
"b004-d-explanation": "تراکنش های اتریوم سانسور نمیشوند، برای انجام تراکنش در اتریوم همیشه ETH لازم است، و آن یک قسمت بنیادی در پایداری اکوسیستم غیرمتمرکز است.",
- "c001-prompt": "Web3 برای کاربران امکان مالکیت دارایی های دیجیتال را فراهم میکند، آن هم مستقیما از طریق:",
- "c001-a-label": "DAOها",
- "c001-a-explanation": "DAOها (سازمان های مستقل غیرمتمرکز) توسط اعضا اداره و رهبری میشوند بدون وجود رهبری متمرکز.",
+ "c001-prompt": "کاربران با Web3 امکان داشتن داراییهای دیجیتالی را دارند از طریق:",
+ "c001-a-label": "توکن ها",
+ "c001-a-explanation": "توکنها راهی برای نشان دادن واحدهایی از ارزش ارائه میدهند که قابل تعویض با یکدیگر هستند و متعلق به یک حساب اتریوم هستند. در حالی که آنها نشان دهنده مالکیت هستند، راههای بیشتری برای داشتن داراییهای دیجیتال در اتریوم وجود دارند.",
"c001-b-label": "توکن های غیرقابل تعویض",
- "c001-b-explanation": "NFTها (توکن های غیرقابل معاوضه) مسیری را فراهم آورده اند تا هر چیز منحصر به فرد را به عنوان یک دارایی مبتنی بر اتریوم ارائه داد.",
+ "c001-b-explanation": "NFTها (توکنهای غیرقابل تعویض) راهی برای نمایش هر چیز منحصر به فردی بهعنوان دارایی مبتنی بر اتریوم ارائه میدهند. در حالی که آنها نشان دهنده مالکیت هستند، راههای بیشتری برای داشتن داراییهای دیجیتال در اتریوم وجود دارند.",
"c001-c-label": "ENS",
- "c001-c-explanation": "ENS (Ethereum Name Service) سرویس نامگذاری غیرمتمرکز برای بلاکچین اتریوم است.",
- "c001-d-label": "گیتهاب",
- "c001-d-explanation": "گیتهاب یک پلتفرم متمرکز است که در درجه اول برای ذخیره کد با استفاده از کنترل نسخه توزیع شده است. گیت هاب به شما اجازه مالکیت داده یا دارایی های دیجیتال را نمیدهد.",
+ "c001-c-explanation": "ENS (سرویس نام اتریوم) یک سرویس نامگذاری غیرمتمرکز برای بلاکچین اتریوم است. در حالی که آنها نشان دهنده مالکیت هستند، راههای بیشتری برای داشتن دارایی های دیجیتال در اتریوم وجود دارند.",
+ "c001-d-label": "تمام موارد فوق",
+ "c001-d-explanation": "همه گزینهها راههایی را برای داشتن داراییهای دیجیتال در اتریوم ارائه میدهند. توکن ها، NFT ها و ENS همگی راههایی برای نشان دادن مالکیت داراییهای دیجیتال هستند.",
"c002-prompt": "Web1 فقط قابل خواندن بود، Web2 برای خواندن و نوشتن است، Web3 به این شکل توصیف میشود:",
"c002-a-label": "خواندن-نوشتن-فروش",
"c002-a-explanation": "Web3 اینطور توصیف نشده است.",
@@ -160,15 +161,15 @@
"d001-c-explanation": "کیف پول های وب از امنیت کمتری به نسبت کیف پول های سخت افزاری برخوردار هستند زیرا کلید های خصوصی روی دستگاهی متصل به اینترنت ذخیره می شود.",
"d001-d-label": "کیف پول دستکاپ",
"d001-d-explanation": "کیف پول های دسکتاپ کلید های خصوصی را بر روی هارد دیسک کامپیوتری نگه می دارند، که معمولا به اینترنت متصل است، و بهطور بالقوه توسط نرمافزار های دیگر در معرض خطر قرار می گیرد.",
- "d002-prompt": "از میان گزینه های مطرح شده، کدام یک ایمن ترین راه برای ذخیر کردن عبارت بذر شماست؟",
+ "d002-prompt": "چطور باید عبارت بذر را ذخیره کنید؟",
"d002-a-label": "در یک عکس روی گوشی شما",
"d002-a-explanation": "این امن ترین گزینه نیست. اگر این عکس در حافظه ابری آپلود شود، یک هکر این تصویر را دریافت کرده و به حساب شما دسترسی پیدا می کند.",
"d002-b-label": "در یک فایل در کامپیوتر شما",
"d002-b-explanation": "این امن ترین گزینه نیست. هکرها به طور فزاینده به دنبال اطلاعات مرتبط با کریپتو بر روی دستگاه هدف می گردند. اگر هکری به فایلی با عبارت بذر شما دسترسی داشته باشد، به حساب شما دسترسی خواهد داشت.",
- "d002-c-label": "نوشتن روی کاغذ",
- "d002-c-explanation": "از بین گزینه های موجود، نوشتن عبارت بذر خود روی یک تکه کاغذ امن ترین است.",
- "d002-d-label": "در یک پیام متنی به یکی از اعضای مورد اعتماد خانواده",
- "d002-d-explanation": "هرگز نباید عبارت بذر خود را برای کسی پیام دهید. پیام می تواند بوسیله یک شخص ثالث رهگیری شود، و حتی اگر شما به آن شخص کاملا اعتماد داشته باشید، نمی دانید چه کسی ممکن است بتواند به تلفن آن ها دسترسی داشته باشد.",
+ "d002-c-label": "در یک پیام متنی به یکی از اعضای مورد اعتماد خانواده",
+ "d002-c-explanation": "هرگز نباید عبارت بذر خود را برای کسی پیام دهید. پیام می تواند بوسیله یک شخص ثالث رهگیری شود، و حتی اگر شما به آن شخص کاملا اعتماد داشته باشید، نمی دانید چه کسی ممکن است بتواند به تلفن او دسترسی داشته باشد.",
+ "d002-d-label": "هیچ کدام از گزینه های فوق",
+ "d002-d-explanation": "عبارت بذر شما باید به صورت ایمن و در حالت ایده آل آفلاین ذخیره شود. نوشتن آن روی کاغذ اغلب به این دلیل توصیه میشود، اما یک نرمافزار ایمن مدیریت رمز هم جایگزین خوبی است.",
"d003-prompt": "عبارت بذر/کلیدهای خصوصی خود را در اختیار چه کسی میتوانید قرار دهید؟",
"d003-a-label": "کسی که به او پولی پرداخت میکنید",
"d003-a-explanation": "هرگز نباید عبارت بذر یا کلید های خصوصی خود را به کسی بدهید. در عوض، از طریق یک تراکنش توکن ها را به آدرس کیف پول آن ها ارسال کنید.",
@@ -268,11 +269,11 @@
"g002-d-explanation": "اکثر شبکه های جایگزین لایه 1 امنیت و عدم تمرکز را فدای مقیاس پذیری بالا میکنند.",
"g003-prompt": "کدام یک از موارد زیر به عنوان لایه 2 در نظر گرفته نمی شود؟",
"g003-a-label": "والیدیوم (Validium)",
- "g003-a-explanation": "والیدیوم ها به عنوان راهکارهای لایه 2 شناخته نمیشوند زیرا امنیت یا در دسترس بودن داده خود را از اتریوم تامین نمیکنند",
+ "g003-a-explanation": "ولیدیومها بهعنوان راهکارهای لایه 2 در نظر گرفته نمیشوند زیرا امنیت یا دسترسیپذیری داده را از اتریوم بدست نمیآورند. این تنها پاسخ صحیح نیست.",
"g003-b-label": "زنجیرههای جانبی",
- "g003-b-explanation": "زنجیره های جانبی به عنوان لایه 2 شناخته نمیشوند زیرا امنیت یا در دسترس بودن داده خود را از اتریوم تامین نمیکنند.",
+ "g003-b-explanation": "زنجیره های جانبی بهعنوان راهکارهای لایه 2 در نظر گرفته نمیشوند زیرا امنیت یا دسترسیپذیری را از اتریوم بدست نمیآورند. این تنها پاسخ صحیح نیست.",
"g003-c-label": "بلاکچینهای جایگزین لایه 1",
- "g003-c-explanation": "دیگر بلاکچینهای لایه 1 به عنوان راهکارهای لایه 2 شناخته نمیشوند.",
+ "g003-c-explanation": "بلاکچین های جایگزین لایه 1 بهعنوان راهکارهای لایه 2 در نظر گرفته نمیشوند. این تنها پاسخ صحیح نیست.",
"g003-d-label": "تمام موارد فوق",
"g003-d-explanation": "زنجیره های مبتنی بر راه حل والیدیوم، زنجیره های جانبی، و دیگر بلاکچینهای لایه 1 به عنوان لایه 2 شناخته نمیشوند زیرا امنیت یا در دسترس بودن داده خود را از اتریوم تامین نمیکنند.",
"g004-prompt": "چرا اتریوم یک لایه 2 \"رسمی\" ندارد؟",
@@ -289,7 +290,7 @@
"h001-a-explanation": "مکانیزم اجماع استفاده شده توسط اتریوم قبل از Merge اثبات-کار بود.",
"h001-b-label": "اثبات سهام",
"h001-b-explanation": "درست است! The Merge مکانیزم اجماع اتریوم را به اثبات سهام تغییر داد.",
- "h001-c-label": "Proof-of-authority",
+ "h001-c-label": "اثبات صلاحیت (PoA)",
"h001-c-explanation": "اتریوم هیچوقت از مکانیزم اجماع اثبات اعتبار در اتریوم استفاده نکرده و نمیکند.",
"h001-d-label": "تمام موارد فوق",
"h001-d-explanation": "اتریوم نمیتواند از تمام این این مکانیزم های اجماع همزمان استفاده کند.",
@@ -305,8 +306,8 @@
"h003-prompt": "ادغام چه زمانی اتفاق افتاد؟",
"h003-a-label": "15 سپتامبر 2022",
"h003-a-explanation": "ادغام روز 15 سپتامبر 2022 ساعت 06:42:42 صبح (ساعت جهانی) رخ داد.",
- "h003-b-label": "1 دسامبر 2021",
- "h003-b-explanation": "ادغام بعد از این رخ داد. 1 دسامبر 2022 روزی بود که زنجیره بیکن شروع به کار کرد.",
+ "h003-b-label": "1 دسامبر 2020",
+ "h003-b-explanation": "ادغام بعد از این رخ داد. 1 دسامبر 2020 روزی بود که زنجیره بیکن شروع به کار کرد.",
"h003-c-label": "27 نوامبر 2013",
"h003-c-explanation": "ادغام بعدها اتفاق افتاد. 27 نوامبر 2013 روزی بود که وایت پیپر اتریوم منتشر شد.",
"h003-d-label": "31 اکتبر 2008",
@@ -324,5 +325,143 @@
"h005-c-label": "اتر1",
"h005-c-explanation": "اتر 1 نام اصلی بود که به لایه اجرا داده شده، نه لایه اجماع.",
"h005-d-label": "سهام گذاری",
- "h005-d-explanation": "سهام گذاری، واریز کردن ETH در یک قرارداد هوشمند برای کمک به افزایش امنیت زنجیره است."
+ "h005-d-explanation": "سهام گذاری، واریز کردن ETH در یک قرارداد هوشمند برای کمک به افزایش امنیت زنجیره است.",
+ "i001-prompt": "گزینه صحیح درباره DAOها کدام است؟",
+ "i001-a-label": "DAO ها بهطور جمعی از طریق توکن های حاکمیتی تحت مالکیت هستند",
+ "i001-a-explanation": "مالکیت DAOها به طور جمعی است، اما این تنها جمله صحیح نیست.",
+ "i001-b-label": "آنها توسط اعضایشان اداره میشوند",
+ "i001-b-explanation": "آنها توسط اعضایشان اداره میشوند، اما این تنها جمله صحیح نیست.",
+ "i001-c-label": "آنها برای یک ماموریت مشترک کار میکنند",
+ "i001-c-explanation": "DAOها برای یک ماموریت مشترک کار میکنند، اما این تنها جمله صحیح نیست.",
+ "i001-d-label": "تمام موارد فوق",
+ "i001-d-explanation": "درست است، یک DAO یک سازمان تحت مالکیت جمعی و تحت کنترل بلاکچین است که برای یک ماموریت مشترک کار میکند.",
+ "i002-prompt": "نمونه های عملی نحوه استفاده از DAO چیست؟",
+ "i002-a-label": "پروتکلهای غیرمتمرکز، اعضا در مورد مسائل مربوط به پروتکل یا نحوه توسعه محصول رای میدهند",
+ "i002-a-explanation": "DAOهای پروتکل یک مثال هستند، اما DAOها به آن مورد محدود نمیشوند.",
+ "i002-b-label": "مالکیت جمعی، به عنوان مثال، برای NFTها یا داراییهای فیزیکی",
+ "i002-b-explanation": "DAOهای جمعکننده یک مثال هستند، اما DAOها به آنها محدود نمیشوند.",
+ "i002-c-label": "ونچرها و بخششها، سرمایه جمع میکنند و به پروژههایی برای تامین مالی رای میدهند",
+ "i002-c-explanation": "DAOهای ونچر و بخشش یک مثال هستند، اما DAOها به آنها محدود نمیشوند.",
+ "i002-d-label": "تمام موارد فوق",
+ "i002-d-explanation": "یک DAO میتواند «ماموریتهای» زیادی داشته باشد.",
+ "i003-prompt": "بر خلاف سازمانهای سنتی، DAOها…",
+ "i003-a-label": "معمولاً به صورت سلسلهمراتبی",
+ "i003-a-explanation": "DAOها معمولاً یکپارچه و کاملاً دموکراتیک هستند.",
+ "i003-b-label": "شفاف و کاملاً عمومی در مورد فعالیتهای خود",
+ "i003-b-explanation": "به لطف رای گیری روی زنجیره، تصمیمات در بلاکچین شفاف هستند. بحث و گفتگو و سایر عناصر فرآیند تصمیمگیری برای همه اعضا باز است.",
+ "i003-c-label": "کنترل شده توسط یک طرف مرکزی",
+ "i003-c-explanation": "تغییرات نیاز به رای اعضا دارند. خدمات ارائه شده به صورت خودکار و به صورت غیرمتمرکز انجام میشوند.",
+ "i003-d-label": "محدود به افرادی که میتوانند تغییرات را پیشنهاد دهند",
+ "i003-d-explanation": "معمولاً هر عضو DAO می تواند تغییراتی را پیشنهاد دهد.",
+ "i004-prompt": "چه چیزی در مورد قراردادهای هوشمند برای DAOها ضروری است؟",
+ "i004-a-label": "کد قرارداد هوشمند قابل تغییر است",
+ "i004-a-explanation": "هنگامی که قرارداد در اتریوم به صورت زنده اجرا می شود، هیچ کس نمی تواند قوانین را تغییر دهد مگر با رای دادن. این به DAO اجازه می دهد طبق قوانینی که با آن برنامه ریزی شده است اجرا شود.",
+ "i004-b-label": "یک مالکِ انفرادی دارد که اختیار ایجاد تغییرات و ارسال از خزانه را دارد.",
+ "i004-b-explanation": "خزانه با قرارداد هوشمند تعریف می شود. برای صرف پول، به تایید گروه نیاز است.",
+ "i004-c-label": "به اجماع توزیع شده متعلق به بلاکچین زیربنایی اعتماد کنید",
+ "i004-c-explanation": "برای یک DAO مهم است که بلاکچین اصلی قابل دستکاری نباشد. اجماع خود اتریوم به اندازه کافی توزیع و ایجاد شده است که سازمانها به شبکه اعتماد کنند.",
+ "i004-d-label": "DAOها به قراردادهای هوشمند نیاز ندارند",
+ "i004-d-explanation": "شالوده اصلی هر DAO، قرارداد هوشمند آن است که قوانین این سازمان را تعیین و خزانه گروه را نگه میدارد.",
+ "i005-prompt": "کدام مورد یک مکانیزم حاکمیت DAO نیست؟",
+ "i005-a-label": "عضویت مبتنی بر توکن",
+ "i005-a-explanation": "حاکمیت مبتنی بر توکن بسیار مورد استفاده قرار میگیرد. معمولاً کاملاً بدون مجوز است و معمولاً برای کنترل پروتکلها و/یا خود توکنهای غیرمتمرکز گسترده استفاده میشود.",
+ "i005-b-label": "عضویت مبتنی بر سهم",
+ "i005-b-explanation": "DAOهای مبتنی بر سهم، کمی بیشتر نیاز به اجازه دارند اما همچنان باز و آزاد هستند. هر عضو احتمالی میتواند پیشنهادی را برای پیوستن به DAO ارائه کند که معمولاً نوعی ارزش را به شکل توکن یا کار ارائه میدهد.",
+ "i005-c-label": "عضویت مبتنی بر شهرت",
+ "i005-c-explanation": "برخلاف عضویت مبتنی بر توکن یا سهم، DAOهای مبتنی بر شهرت، مالکیت را به مشارکت کنندگان منتقل نمیکنند. اعضا DAO باید از طریق مشارکت، شهرت کسب نمایند.",
+ "i005-d-label": "هیئت مدیره و مدیریت خارج زنجیره خزانه",
+ "i005-d-explanation": "این رویکرد، از مکانیسمهای بسیار متمرکز و غیرشفاف مدیریت استفاده میکند. در عوض DAOها از مکانیسمهای رأی گیری قابل تائید و مدیریت دارایی بر روی شبکه استفاده میکنند تا از شفافیت و پذیرش مسئولیت اطمینان حاصل نمایند.",
+ "j001-prompt": "کدام یک از موارد زیر درمورد اسلشینگ صحیح میباشد؟",
+ "j001-a-label": "جریمه برای آفلاین بودن و دریافت پاداش، پس از آنلاین شدن ادامه خواهد یافت",
+ "j001-a-explanation": "آفلاین بودن سبب اسلشینگ نمیشود. جریمههای کوچکی برای آفلاین بودن درنظر گرفته میشود و زمانی که اعتبارسنج دوباره آنلاین شود و به تصدیقهای خود ادامه دهد، پاداشها ادامه خواهند یافت.",
+ "j001-b-label": "جریمه برای آفلاین بودن، اعتبارسنج بلافاصله به صورت دائم از تصدیق کردن منع میشود",
+ "j001-b-explanation": "آفلاین بودن سبب اسلشینگ نمیشود. با این وجود اسلشینگ باعث خواهد شد که اعتبارسنج به صورت دائمی از تصدیق دوباره منع شود و در نهایت به طور اجباری از شبکه بیرون خواهد افتاد، اما آفلاین بودن باعث بیرون افتادن از شبکه نخواهد شد.",
+ "j001-c-label": "جریمه برای نقض قوانین مشخص اجماع، پاداشها پس از اسلشینگ ادامه خواهند یافت",
+ "j001-c-explanation": "جریمه کردن یک مجازات جدی برای شکستن قوانین اجماع خاص است که تهدیدی برای شبکه است. به این ترتیب، هنگامی که یک اعتبارسنج کاهش می یابد، بلافاصله از تأیید بیشتر منع می شود، و در نهایت به زور از شبکه خارج می شود و ETH باقیمانده به مالک پس گرفته می شود.",
+ "j001-d-label": "جریمه برای شکستن قواعد اجماع خاص، اعتبارسنج بلافاصله از تأیید مجدد منع می شود",
+ "j001-d-explanation": "جریمه کردن یک مجازات جدی برای شکستن قوانین اجماع خاص است که تهدیدی برای شبکه است. به این ترتیب، هنگامی که یک اعتبارسنج کاهش می یابد، بلافاصله از تأیید بیشتر منع می شود، و در نهایت به زور از شبکه خارج می شود و ETH باقیمانده به مالک پس گرفته می شود.",
+ "j002-prompt": "اگر اعتبارسنج آفلاین شود چه اتفاقی میافتد؟",
+ "j002-a-label": "هیچ تاثیری روی پاداش ها ندارد",
+ "j002-a-explanation": "جریمهها زمانی اعمال میشوند که اعتبارسنج برای تأیید وضعیت زنجیره برای هر دوره معین در دسترس نباشد. اندازه این جریمه ها تقریباً برابر با 75 درصد پاداشی است که برای یک گواهینامه مناسب می شد. زمانی که اعتباسنج آنلاین شود و هیچ اسلشینگی رخ ندهد، پاداشها از سر گرفته میشوند.",
+ "j002-b-label": "جریمه های عدم فعالیت فقط در صورت در دسترس نبودن اعمال می شود",
+ "j002-b-explanation": "در حالی که اعتبارسنج در دسترس نیست، جریمههای عدم فعالیت کوچکی را متحمل میشود که تقریباً برابر با 75٪ پاداشی است که برای یک گواهی مناسب میبود. در موارد نادر/بسیار شدید که شبکه نهایی نمی شود (یعنی بیش از 1/3 شبکه نیز آفلاین است)، این جریمه ها به طور قابل توجه بیشتر است. وقتی اعتبارسنج آنلاین شود و هیچ اسلشینگی رخ ندهد، پاداشها از سر گرفته میشوند.",
+ "j002-c-label": "جریمه و حذف فوری از شبکه",
+ "j002-c-explanation": "این یک تصور غلط رایج است، اما آفلاین بودن منجر به اسلشینگ نمی شود! اسلشینگ نوع خاصی از مجازات برای تخلفات جدی تر است، که مجازات های بزرگتر و همچنین حذف از مجموعه اعتبارسنج ها را به همراه دارد.",
+ "j002-d-label": "یک هفته تاخیر قبل از اسلشینگ و اخراج شدن",
+ "j002-d-explanation": "آفلاین بودن حتی پس از مدت زمان طولانی منجر به اسلشینگ نمی شود. از نظر تئوری، اعتبارسنج میتواند برای سالها آفلاین باشد، بدون اینکه اسلشینگ شود، اگرچه در صورت عدم خروج اعتبارسنج، جریمههای عدم فعالیت افزایش مییابند.",
+ "j003-prompt": "حداکثر تراز مؤثر اعتبارسنج چقدر است؟",
+ "j003-a-explanation": "اعتبار سنج هایی که به تعادل موثر 16 ETH کاهش می یابند به طور خودکار از زنجیره بیکن خارج می شوند.",
+ "j003-b-explanation": "مقدار 32 اتر، هم حداقل اتریوم مورد نیاز برای فعال کردن یک اعتبارسنج جدید است و هم حداکثر «موجودی مؤثر» (وزن رأی) برای آن اعتبارسنج. پاداشهای بالاتر از 32 را ممکن است باشد، اما این موجودی به وزن رأی اعتبارسنج ها در شبکه کمک نمیکند و پاداشها افزایش نمییابد.",
+ "j003-c-label": "بسته به اپراتور متغیر است",
+ "j003-c-explanation": "قوانین اجماع برای هر حساب اعتبارسنج به طور یکسان اعمال می شوند و به فردی که گره را اداره می کند وابسته نیست. حداکثر موجودی موثر تمام اعتبارسنج ها 32 ETH است.",
+ "j003-d-label": "نامحدود",
+ "j003-d-explanation": "هر حساب اعتبارسنج محدود به موجودی موثر 32 ETH است که قدرت کلی هر اعتبارسنج منفرد را در شبکه محدود می کند. این همچنین میزان ETH را که میتوان در یک دوره زمانی معین سهامگذاری یا حذف کرد، محدود میکند، زیرا فعالسازیها و خروجیهای اعتبارسنج از طریق یک صف با نرخ محدود پردازش میشوند.",
+ "j004-a-label": "پاداش بلوک",
+ "j004-b-label": "انعام های کارمزد / MEV",
+ "j004-b-explanation": "انعام کارمزد (بخش نسوخته کارمزد) و درآمدهای MEV از طریق آدرس گیرنده هزینه ارائه شده توسط آن اعتبارسنج به پیشنهاد دهنده بلوک (سهام گذار/اعتبارکننده) توزیع می شود. این پاداشها جدا از پاداش بلوکی هستند که هنگام پیشنهاد بلوک به دست میآیند.",
+ "j004-c-label": "پاداش تایید سر زنجیره",
+ "j004-c-explanation": "اعتبارسنج ها پاداشهایی را در قالب صدور ETH جدید برای تأیید صحیح و سریع سر زنجیره، سر ایپوک توجیهشده فعلی و سر ایپوک نهایی فعلی دریافت میکنند.",
+ "j005-a-label": "100%",
+ "j005-c-label": "~50%",
+ "j007-prompt": "کدام مورد، روش محافظت/جلوگیری از جریمهشدن اعتبارسنج شما نیست؟",
+ "j007-a-label": "از تنظیمات بیش از حد اضافی خودداری کنید و کلیدهای خود را هر بار فقط با یک کاربر اعتبارسنج ذخیره کنید",
+ "j007-a-explanation": "اکثر جریمه ها تا به امروز مربوط به اپراتورهایی بودهاند که کلیدهای امضای خود را در بیش از یک ماشین به عنوان یک پشتیبان اضافی ذخیره می کنند. این کار بسیار خطرناک است، زیرا هر گونه نقص میتواند منجر به رأی گیری مضاعف و جریمه شدن شود.",
+ "j007-b-label": "نرمافزار کاربر را همانطور که هست بدون تغییر کد اجرا کنید",
+ "j007-b-explanation": "نرمافزار کاربر برای محافظت در برابر انجام اقدامات قابل جریمه نوشته و آزمایش میشود. برای اجرای یک اقدام قابل جریمه شدن، معمولاً نیاز به تغییر کد کاربر به روشی مخرب از سوی خودتان دارد.",
+ "j007-c-label": "کاربری را اجرا کنید که توسط اکثر اعتبارسنجهای دیگر استفاده میشود",
+ "j007-c-explanation": "استفاده از کاربر یکسان همانند اکثریت باقی اعضای شبکه، شما را در معرض خطر جریمه شدن در صورت بروز اشکال نرمافزاری در آن کاربر قرار میدهد. اجرای یک کاربر اقلیت از این امر محافظت می کند.",
+ "j007-d-label": "قبل از انتقال کلیدها به دستگاه جدید، اعتبارسنج را برای 2 تا 4 ایپوک غیرفعال کنید",
+ "j007-d-explanation": "این امر اجازه میدهد زمانی که گره شما آفلاین است، زنجیره نهایی شود تا خطر دوبار رایگیری تصادفی و جریمه شدن آن در حین انتقال کلید به حداقل برسد.",
+ "j008-prompt": "کدام مورد برای دریافت پاداش / برداشت جزئی مورد نیاز نیست؟",
+ "j008-a-label": "ارائه یک آدرس برداشت یکباره لایه اجرا",
+ "j008-a-explanation": "این یک بار برای فرآیند برداشت لازم است تا بدانیم وجوه لایه اجماع را به کجا ارسال کنیم",
+ "j008-b-label": "داشتن موجودی موثر 32 اتر",
+ "j008-b-explanation": "قبل از شروع هرگونه برداشت جزئی، موجودی موثر شما باید حداکثر 32 اتر شود.",
+ "j008-c-label": "داشتن موجودی کل بیش از 32 اتر",
+ "j008-c-explanation": "قبل از شروع هرگونه برداشت جزئی، موجودی کل شما باید بیش از 32 اتر شود.",
+ "j008-d-label": "ثبت مبلغ برداشت درخواستی با پرداخت گس",
+ "j008-d-explanation": "پس از برآورده شدن سایر معیارها، پرداخت پاداش به صورت خودکار انجام می شود. گیرندگان نیازی به ارائه تراکنش یا پرداخت گس ندارند. مبلغ برداشت شده برابر با موجودی اعتبارسنج بیش از 32 است. مقادیر سفارشی قابل درخواست نیست.",
+ "k001-prompt": "اتریوم از کدام یک از موارد زیر برای مقیاسپذیری استفاده می کند؟",
+ "k001-a-label": "رولآپهای لایه 2",
+ "k001-a-explanation": "اینها با دستهبندی تراکنشها، اجرای آنها و سپس ارسال نتایج به اتریوم برای اعتبارسنجی و ایمن شدن، به مقیاسپذیری اتریوم کمک میکنند. نمونهها یا رولآپها عبارتند از آربیتروم یا آپتیمیزم. این تنها راهی نیست که اتریوم مقیاسپذیری میکند.",
+ "k001-b-label": "Proto-Danksharding",
+ "k001-b-explanation": "این یک گزینه ذخیرهسازی موقت و ارزان برای ذخیره دادههای جمعآوری در شبکه اصلی فراهم میکند، که در حال حاضر تقریباً 90٪ هزینهای را که کاربر در یک رولآپ با آن مواجه میشود، بر عهده دارد. این تنها راهی نیست که اتریوم مقیاسپذیری میکند.",
+ "k001-c-label": "دانکشاردینگ",
+ "k001-c-explanation": "این امر نیاز به هر اعتبارسنج و گره در شبکه را از ذخیره 100٪ داده برای همه رولآپها حذف میکند و نیازهای سختافزاری را برای اپراتورهای گره کاهش میدهد. این تنها راهی نیست که اتریوم مقیاسپذیری میکند.",
+ "k001-d-label": "تمام موارد فوق",
+ "k001-d-explanation": "رولآپهای لایه 2 تراکنشها را جمعبندی میکند، پروتو-دنکشاردینگ فضای ذخیرهسازی موقت ارزان را برای این داده ایجاد میکند، و دنکشاردینگ بار ذخیرهسازی را در میان همه اعتبارسنجها تقسیم میکند که همگی به مقیاسپذیری اتریوم کمک میکنند.",
+ "k002-prompt": "پس از بستهبندی تراکنشها و اجرای آنها، رولآپهای لایه 2 در مرحله بعد چه میکنند؟",
+ "k002-a-label": "ذخیره داده روی یک سرور خصوصی",
+ "k002-a-explanation": "نتایج برای شفافیت و در دسترس بودن عمومی به شبکه اصلی ارسال میشوند و به سرورهای خصوصی وابسته نیستند.",
+ "k002-b-label": "مدرک را برای ذخیرهسازی به کاربر ارسال میکند",
+ "k002-b-explanation": "از کاربران انتظار نمی رود نتایج تراکنش خود را نگه دارند. این اطلاعات به شبکه اصلی ارسال می شوند.",
+ "k002-c-label": "ارسال نتایج به اتریوم",
+ "k002-c-explanation": "رولآپهای لایه 2 نتایج اجرای تراکنش خود را به شبکه اصلی ارسال میکنند و آن را در تاریخچه اتریوم ایمن میکنند",
+ "k002-d-label": "حذب نتیجه برای کاهش هزینهها",
+ "k002-d-explanation": "رولآپهای لایه 2 نتایج اجرای تراکنش خود را به شبکه اصلی ارسال می کنند. صرفه جویی در هزینه به دست آمده با این رویکرد، با جمعبندی و فشردهسازی دادههای تراکنش و در نهایت ذخیره کردن آن در فضای ذخیرهسازی ارزانقیمت انجام میشود که پس از در دسترس قرار گرفتن برای کسانی که به آن نیاز دارند، منقضی میشود.",
+ "k003-prompt": "پروتو-دنکشاردینگ چگونه هزینه تراکنش رولآپ روی رولآپها را کاهش میدهد؟",
+ "k003-a-label": "افزایش مستقیم سایز بلوک",
+ "k003-a-explanation": "پروتو-دنکشاردینگ به طور مستقیم محدودیت گس را افزایش نمی دهد، اما با در دسترس قرار دادن فضای ذخیرهسازی موقت، عملیات ذخیرهسازی داده رولآپ را کمهزینهتر میکند",
+ "k003-b-label": "از هم جدا کردن به شکلی که کدام اعتبارسنجها باید داده را ذخیره کنند",
+ "k003-b-explanation": "اگرچه انتظار میرود دنکشاردینگ کامل لزوم ذخیرهسازی داده از سوی اعتبارسنجها را کاهش دهد، پیش از آن پروتو-دنکشاردینگ وجود دارد که یک گزینه ذخیرهسازی موقت و کمهزینه برای داده های تولید شده توسط رولآپها را تشکیل میدهد.",
+ "k003-c-label": "افزایش قابل توجه نیازهای سختافزاری برای اپراتورهای گره",
+ "k003-c-explanation": "این به طور کلی گزینه قابل قبولی برای مقیاس پذیری اتریوم در نظر گرفته نمی شود. تلاش های زیادی برای به حداقل رساندن نیازهای سخت افزاری برای عملکرد یک گره انجام می شود تا آن را تا حد امکان در دسترس نگه دارد.",
+ "k003-d-label": "ذخیره دادههای آن در فضای ذخیرهسازی ارزانتر و موقت «Blob»",
+ "k003-d-explanation": "پروتو-دنکشاردینگ یک گزینه ذخیرهسازی موقت داده را برای رولآپها معرفی میکند تا به آنها اجازه دهد نتایج خود را با قیمت ارزانتر در شبکه اصلی ارسال کنند",
+ "k004-prompt": "گام حیاتی بعدی رولآپها برای مقیاسپذیری اتریوم چیست؟",
+ "k004-a-label": "تشویق نهادهای دارای کامپیوترهای قدرتمند برای مدیریت همه مرتبسازیها",
+ "k004-a-explanation": "یکی از مشکلات رولآپهای کنونی، ماهیت متمرکز کسانی است که ترتیبدهندهها را اجرا میکنند (کسانی که در مورد گنجاندن و ترتیب تراکنشها در یک مجموعه تصمیم میگیرند). هدف این است که به هر کس اجازه مشارکت داده شود و به هیچ وجه به یک گروه یا نهاد تکیه نشود.",
+ "k004-b-label": "تقسیم مسئولیت اجرای ترتیبدهندهها و اثباتکنندهها بین افراد بیشتر",
+ "k004-b-explanation": "کنترل روی یک رولآپ معمولاً به صورت متمرکز شروع می شود، که به شروع کار کمک می کند، اما شبکه را مستعد سانسور می کند. غیرمتمرکز کردن فرآیند شامل تراکنش ها طوری که هر کس بتواند در آن شرکت کند برای جلوگیری از احتمال به خطر افتادن شبکه ضروری است.",
+ "k004-c-label": "مطابقت دادن همه رولآپها با همان روش امنیتی",
+ "k004-c-explanation": "اتریوم از داشتن طیف گستردهای از رویکردهای امنیتی در اکوسیستم رولآپ خود به عنوان نوعی انعطافپذیری سود میبرد.",
+ "l002-a-label": "0",
+ "l002-b-label": "8",
+ "l003-a-label": "مقاومت در برابر سانسور",
+ "l003-b-label": "حق حاکمیت",
+ "l003-d-label": "تمام موارد فوق",
+ "l004-c-label": "2 ترابایت درایو حالت جامد (SSD)",
+ "l004-d-label": "8 ترابایت درایو حالت جامد (SSD)",
+ "l006-a-label": "صحیح",
+ "l006-b-label": "غلط"
}
diff --git a/src/intl/fa/page-about.json b/src/intl/fa/page-about.json
new file mode 100644
index 00000000000..1fa7287e936
--- /dev/null
+++ b/src/intl/fa/page-about.json
@@ -0,0 +1,35 @@
+{
+ "page-about-h2": "درخواست یک ویژگی",
+ "page-about-h3": "کار در حال پیشرفت",
+ "page-about-h3-1": "ویژگیهای اجرا شده",
+ "page-about-h3-2": "ویژگیهای برنامهریزی شده",
+ "page-about-li-1": "در حال پیشرفت",
+ "page-about-li-2": "برنامه ریزی شده",
+ "page-about-li-3": "اجرا شده",
+ "page-about-li-4": "پیاده سازی شده",
+ "page-about-link-1": "منبع این مخزن تحت لیسانس MIT است",
+ "page-about-link-2": "گیت هاب",
+ "page-about-link-3": "لیست کامل کارهای در حال انجام را در گیت هاب ببینید",
+ "page-about-link-4": "به سرور دیسکورد ما بپیوندید",
+ "page-about-link-5": "در توییتر به ما بپیوندید",
+ "page-about-link-6": "لیست کامل کارهای پیاده سازی شده را در گیت هاب ببینید",
+ "page-about-link-7": "یک مسئله در گیت هاب بسازید",
+ "page-about-p-1": "ما از زمان راه اندازی ethereum.org میکوشیم در روش عمل خود شفاف باشیم، این یکی ارزش های اصلی ماست، باور ما بر این است که شفافیت برای موفقیت اتریوم حیاتی است.",
+ "page-about-p-2": "ما از",
+ "page-about-p-3": "به عنوان ابزار مدیریت پروژه اصلی مان استفاده میکنیم. ما کارها را به 3 دسته تقسیم میکنیم:",
+ "page-about-p-4": "ما تلاشمان را میکنیم که جامعه را از آخرین وضعیت هر کار خاص مطلع نگه داریم.",
+ "page-about-p-5": "کارهایی که داریم اجرا میکنیم.",
+ "page-about-p-6": "کارهایی که در صف اجرا قرار دارند.",
+ "page-about-p-7": "کارهایی که اخیرا تمام شده اند.",
+ "page-about-p-8": "آیا ایده ای برای بهبود ethereum.org دارید؟ ما مشتاق همکاری با شما هستیم!",
+ "page-what-is-ethereum-energy-consumption-chart-legend": "مصرف سالانه انرژی بر حسب کیلووات ساعت در سال",
+ "energy-consumption-chart-global-data-centers-label": "مراکز داده جهانی",
+ "energy-consumption-chart-airbnb-label": "AirBnB",
+ "energy-consumption-gold-mining-cbeci-label": "استخراج طلا",
+ "energy-consumption-chart-btc-pow-label": "BTC PoW",
+ "energy-consumption-chart-netflix-label": "نتفلیکس",
+ "energy-consumption-chart-eth-pow-label": "ETH PoS",
+ "energy-consumption-chart-gaming-us-label": "بازی در ایالات متحده",
+ "energy-consumption-chart-paypal-label": "پی پال",
+ "energy-consumption-chart-eth-pos-label": "ETH PoS"
+}
diff --git a/src/intl/fa/page-assets.json b/src/intl/fa/page-assets.json
new file mode 100644
index 00000000000..f0ccfe537e7
--- /dev/null
+++ b/src/intl/fa/page-assets.json
@@ -0,0 +1,61 @@
+{
+ "page-assets-bazaar": "بازار اتریوم",
+ "page-assets-beacon-chain": "زنجیره بیکن",
+ "page-assets-blocks": "بلوکهای سازنده",
+ "page-assets-dao": "DAO",
+ "page-assets-defi": "DeFi",
+ "page-assets-merge": "ادغام",
+ "page-assets-doge": "دوج در حال استفاده از پخشافزار",
+ "page-assets-download-artist": "هنرمند:",
+ "page-assets-download-download": "دانلود",
+ "page-assets-enterprise": "اتریوم سازمانی",
+ "page-assets-eth": "اتر (ETH)",
+ "page-assets-eth-diamond-color": "اتریوم الماس (رنگ)",
+ "page-assets-eth-diamond-glyph": "اتریوم الماس (گلیف)",
+ "page-assets-eth-diamond-gray": "اتریوم الماس (خاکستری)",
+ "page-assets-eth-diamond-purple": "اتریوم الماس (بنفش)",
+ "page-assets-eth-diamond-white": "اتریوم الماس (سفید)",
+ "page-assets-eth-diamond-colored": "اتریوم الماس (پر رنگ)",
+ "page-assets-eth-diamond-colored-svg": "اتریوم الماس (پر رنگ، SVG)",
+ "page-assets-eth-glyph-video-dark": "اتریوم گلیف ویدیو (تیره)",
+ "page-assets-eth-glyph-video-light": "اتریوم گلیف ویدیو (روشن)",
+ "page-assets-eth-logo-landscape-gray": "لوگوی افقی اتریوم (خاکستری)",
+ "page-assets-eth-logo-landscape-purple": "لوگوی افقی اتریوم (بنفش)",
+ "page-assets-eth-logo-landscape-white": "لوگوی افقی اتریوم (سفید)",
+ "page-assets-eth-logo-portrait-gray": "لوگوی اتریوم عمودی (خاکستری)",
+ "page-assets-eth-logo-portrait-purple": "لوگوی اتریوم عمودی (بنفش)",
+ "page-assets-eth-logo-portrait-white": "لوگوی اتریوم افقی (سفید)",
+ "page-assets-eth-wordmark-gray": "نمادواژه اتریوم (خاکستری)",
+ "page-assets-eth-wordmark-purple": "نمادواژه اتریوم (بنفش)",
+ "page-assets-eth-wordmark-white": "نمادواژه اتریوم (سفید)",
+ "page-assets-ethereum-brand-assets": "داراییهای \"برند\" اتریوم",
+ "page-assets-finance": "تامین مالی",
+ "page-assets-future": "آینده",
+ "page-assets-h1": "دارایی های ethereum.org",
+ "page-assets-hero": "قهرمان ethereum.org",
+ "page-assets-hero-panda": "قهرمان ethereum.org با ادغام پاندا",
+ "page-assets-merge-panda": "ادغام پاندا",
+ "page-assets-merge-panda-svg": "ادغام پاندا SVG",
+ "page-assets-hero-particles": "عکس تکههای اتریوم",
+ "page-assets-historical-artwork": "اثر هنری تاریخی",
+ "page-assets-illustrations": "تصاویر",
+ "page-assets-impact": "تاثیر",
+ "page-assets-infrastructure": "زیرساخت",
+ "page-assets-leslie-the-rhino": "Leslie the rhino",
+ "page-assets-meta-desc": "داراییهای برند، تصاویر و رسانههای ethereum.org و Ethereum را جستجو و دانلود کنید.",
+ "page-assets-meta-title": "داراییهای \"برند\" اتریوم",
+ "page-assets-mainnet": "شبکه اصلی",
+ "page-assets-page-assets-solid-background": "پس زمینه خالص",
+ "page-assets-page-assets-transparent-background": "پس زمینه شفاف",
+ "page-assets-robot": "کیف پول ربات",
+ "page-assets-sharding": "خرد کردن",
+ "page-assets-hackathon": "هکاتون",
+ "page-assets-learn-hero-name": "دانشگاهی با محوریت آینده",
+ "page-assets-community-hero-name": "گردهمایی جامعه",
+ "page-assets-quizzes-hero-name": "محل بازی بی انتها",
+ "page-assets-developers-hero-name": "ساختن آینده",
+ "page-assets-garden-name": "باغ اتریوم",
+ "page-assets-roadmap-hero-name": "جاده(هایی) به سوی آینده",
+ "page-assets-layer-2-hero-name": "ساخت اتریوم",
+ "page-assets-guides-hero-name": "آزمایشگاه اتریوم"
+}
diff --git a/src/intl/fa/page-bug-bounty.json b/src/intl/fa/page-bug-bounty.json
index 1146f8eb614..44a3279b0cd 100644
--- a/src/intl/fa/page-bug-bounty.json
+++ b/src/intl/fa/page-bug-bounty.json
@@ -1,34 +1,44 @@
{
"page-upgrades-bug-bounty-annotated-specs": "مشخصات پاورقی",
"page-upgrades-bug-bounty-annotations": "بررسی پاورقیهای زیر میتواند سودمند باشد:",
- "page-upgrades-bug-bounty-client-bugs": "باگهای کلاینت لایهی اجماع",
- "page-upgrades-bug-bounty-client-bugs-desc": "کلاینتها پس از استقرار ارتقا، زنجیرهی بیکن را راهاندازی خواهند کرد. کلاینتها ملزم به پیگیری منطق مذکور در مشخصات و همینطور ایمنی در برابر حملات احتمالی هستند. باگهایی که میخواهیم پیدا کنیم به راهاندازی پروتکل مربوط هستند.",
- "page-upgrades-bug-bounty-client-bugs-desc-2": "در حال حاضر اشکالات Lighthouse، Nimbus، Teku و Prysm واجد شرایط دریافت پاداش کامل جایزه هستند. Lodestar نیز واجد شرایط است، اما تا زمانی که ممیزیهای بیشتر تکمیل نشده باشد، امتیازات و پاداش ها به 10% محدود میشود (حداکثر پرداخت 5000 DAI است). با تکمیل ممیزی و آماده شدن برای تولید، ممکن است کلاینتهای بیشتری اضافه شوند.",
- "page-upgrades-bug-bounty-clients": "کلاینتهای ویژه در باونتیها",
- "page-upgrades-bug-bounty-clients-type-1": "عیبیابی مشکلات عدم همخوانی",
- "page-upgrades-bug-bounty-clients-type-2": "کرشهای غیرمنتظره یا آسیبپذیریهای ممانعت از سرویس (DOS)",
- "page-upgrades-bug-bounty-clients-type-3": "هر مشکلی که سبب جدایی تعمیرناپذیر اجماع از سایر شبکه شود",
+ "page-upgrades-bug-bounty-client-bugs": "اشکالات مشتری",
+ "page-upgrades-bug-bounty-client-bugs-desc": "مشتریان شبکه اتریوم را اجرا می کنند و باید از منطق تعیین شده در مشخصات پیروی کنند و در برابر حملات احتمالی ایمن باشند. اشکالاتی که می خواهیم پیدا کنیم مربوط به اجرای پروتکل است.",
+ "page-upgrades-bug-bounty-client-bugs-desc-2": "در حال حاضر کاربرهای لایه اجرا (Besu و Erigon و Geth و Nethermind و Reth) و کاربرهای لایه اجماع (Lighthouse و Lodestar و Nimbus و Teku و Prysm) در برنامه باگباونتی گنجانده شده اند. با تکمیل ممیزی و آماده شدن برای تولید، ممکن است کاربرهای بیشتری اضافه شوند.",
+ "page-upgrades-bug-bounty-clients": "کاربرهای ویژه در باونتیها",
+ "page-upgrades-bug-bounty-clients-type-1": "مشکلات عدم همخوانی مشخصات",
+ "page-upgrades-bug-bounty-clients-type-2": "خرابی های غیرمنتظره، آسیب پذیری RCE یا رد سرویس (DOS)",
+ "page-upgrades-bug-bounty-clients-type-3": "هر مشکلی که سبب جدایی تعمیرناپذیر اجماع از بقیه شبکه شود",
+ "page-upgrades-bug-bounty-misc-bugs": "باگهای Solidity",
+ "page-upgrades-bug-bounty-misc-bugs-desc": "برای جزئیات بیشتر در مورد آنچه در این محدوده گنجانده شده است به Solidity SECURITY.MD مراجعه کنید.",
+ "page-upgrades-bug-bounty-misc-bugs-desc-2": "Solidity دارای ضمانتهای امنیتی در مورد ایجاد ورودی نامعتبر نیست - و ما برای خرابی کامپایلر solc در دادههای تولید شده به طور مخرب پاداشی صادر نمیکنیم.",
+ "page-upgrades-bug-bounty-deposit-bugs": "اشکالات قرارداد واریز",
+ "page-upgrades-bug-bounty-deposit-bugs-desc": "مشخصات و کد منبع قرارداد سپرده زنجیره ای بیکن بخشی از برنامه پاداش باگ است.",
+ "page-upgrades-bug-bounty-dependency-bugs": "باگ های وابستگی",
+ "page-upgrades-bug-bounty-dependency-bugs-desc": "وابستگی های خاصی برای عملکرد شبکه اتریوم بسیار مهم هستند و برخی از این وابستگی ها به برنامه پاداش باگ اضافه شده اند. در حال حاضر، لیست وابستگیهای موجود در برنامه پاداش باگ عبارت است از C-KZG-4844 و Go-KZG-4844.",
"page-upgrades-bug-bounty-docking": "ادغام",
"page-upgrades-bug-bounty-email-us": "به ما ایمیل بزنید:",
"page-upgrades-bug-bounty-help-links": "لینکهای سودمند",
"page-upgrades-bug-bounty-hunting": "قوانین شکار باگ",
- "page-upgrades-bug-bounty-hunting-desc": "برنامهی پاداش برای باگ یک برنامهی جایزهدار آزمایشی و داوطلبانه برای اعضای فعال ما در انجمن اتریوم جهت تشویق و جایزه دادن به کسانی است که به تقویت پلتفرم کمک میکنند. این یک رقابت نیست. شما باید آگاه باشید که ما میتوانیم هر زمانی برنامه را لغو کنیم و اعطای جوایز به صلاحدید پنل پاداش برای باگ بنیاد اتریوم است. علاوه بر آن، ما قادر به جایزه دادن به افرادی که در لیست تحریمها هستند یا کشورهایی که در لیست تحریمها هستند نیستیم (مثلاً: کره شمالی، ایران و غیره). مسئولیت تمام مالیات شما با خودتان است. تمام جوایز مشمول قوانین اجرایی هستند. نهایتاً، آزمایش شما نباید هیچ قانونی را شکسته یا هیچ دادهای که متعلق به شما نیست را افشا کند.",
- "page-upgrades-bug-bounty-hunting-leaderboard": "جدول امتیازات پاداش برای باگ",
- "page-upgrades-bug-bounty-hunting-leaderboard-subtitle": "باگهای لایهی اجماع را بیابید تا به این جدول امتیازات اضافه شوید",
- "page-upgrades-bug-bounty-hunting-li-1": "مشکلاتی که قبلاً توسط کاربری دیگر فرستاده شده باشد یا گردانندگان کلاینتها و تیمهای عیب یابی از قبل بر آن واقف بوده باشند واجد دریافت پاداش برای باگ نیستند.",
- "page-upgrades-bug-bounty-hunting-li-2": "افشای عمومی یک آسیبپذیری باعث میشود که دیگر واجد شرایط دریافت پاداش نباشد.",
- "page-upgrades-bug-bounty-hunting-li-3": "تیم پژوهشگران بنیاد اتریوم و کارمندان کلاینتهای لایهی اجماع واجد شرایط جوایز نیستند.",
- "page-upgrades-bug-bounty-hunting-li-4": "برنامه پاداش اتریوم تعدادی مؤلفه را در تعیین جوایز مدنظر قرار میدهد. تعیین صلاحیت، امتیازها و تمام امور مرتبط با یک پاداش در اختیار تمام و کمال پنل پاداش برای باگ بنیاد اتریوم است.",
- "page-upgrades-bug-bounty-leaderboard": "مشاهدهی جدول کامل امتیازها",
+ "page-upgrades-bug-bounty-hunting-desc": "برنامه پاداش باگ یک برنامه جایزه گرفته آزمایشی و داوطلبانه برای اعضای فعال ما در جامعه اتریوم است جهت تشویق و جایزه دادن به آنهایی که به تقویت پلتفرم کمک میکنند. این یک رقابت نیست. باید توجه داشته باشید که ما میتوانیم هر زمان برنامه را لغو کنیم و اعطای جوایز به صلاحدید پنل پاداش باگ بنیاد اتریوم است. علاوه بر آن، ما قادر به جایزه دادن به افرادی که در لیست تحریم ها هستند یا کشور هایی که در لیست تحریم ها هستند نیستیم (مثلا: کره شمالی، ایران و...). مسئولیت تمام مالیات شما با شماست. تمام جوایز مشمول قوانین اجرایی هستند. نهایتا، آزمایش شما نباید هیچ قانونی را نقض کرده یا هیچ داده ای را که متعلق به شما نیست افشا کند.",
+ "page-upgrades-bug-bounty-hunting-leaderboard": "تابلوی امتیازات لایه اجماع پاداش باگ",
+ "page-upgrades-bug-bounty-hunting-execution-leaderboard": "تابلوی امتیازات پاداش باگ لایه اجرا",
+ "page-upgrades-bug-bounty-hunting-leaderboard-subtitle": "باگهای لایه اجماع را بیابید تا به این جدول امتیازات اضافه شوید",
+ "page-upgrades-bug-bounty-hunting-execution-leaderboard-subtitle": "اشکالات لایه اجرا را پیدا کنید تا به این تابلوی امتیازات اضافه شوید",
+ "page-upgrades-bug-bounty-hunting-li-1": "مشکلاتی که سابقا توسط کاربری دیگر فرستاده شده باشد یا کاربرهای نگهدارنده و تیم های عیب یابی از قبل بر آن واقف بوده باشند واجد پاداش باگ نیستند.",
+ "page-upgrades-bug-bounty-hunting-li-2": "افشای عمومی یک آسیبپذیری یا گزارش آن به طرفهای دیگر بدون توافق قبلی باعث میشود که این آسیبپذیری واجد شرایط نباشد.",
+ "page-upgrades-bug-bounty-hunting-li-3": "کارمندان و پیمانکاران بنیاد اتریوم یا تیمهای مشتری در محدوده برنامه پاداش میتوانند فقط در انباشت امتیاز در برنامه شرکت کنند و پاداش پولی دریافت نخواهند کرد.",
+ "page-upgrades-bug-bounty-hunting-li-4": "برنامه پاداش اتریوم تعدادی مؤلفه را در تعیین جوایز مدنظر قرار میدهد. تعیین صلاحیت، امتیازها و تمام امور مرتبط با یک پاداش در اختیار تمام و کمال پنل پاداش باگ بنیاد اتریوم است.",
+ "page-upgrades-bug-bounty-leaderboard": "دیدن جدول کامل امتیاز ها",
+ "page-upgrades-bug-bounty-leaderboard-list": "جدول امتیازات پاداش باگ",
"page-upgrades-bug-bounty-leaderboard-points": "امتیازها",
- "page-upgrades-bug-bounty-ledger-desc": "مشخصات زنجیرهی بیکن منطق طراحی و تغییرات پیشنهادشده به اتریوم از طریق ارتقای زنجیرهی بیکن را شرح میدهد.",
- "page-upgrades-bug-bounty-ledger-title": "باگهای مشخصات زنجیرهی بیکن",
- "page-upgrades-bug-bounty-meta-description": "مروری بر برنامهی پاداش برای باگ لایهی اجماع: نحوهی مشارکت و اطلاعات جوایز.",
- "page-upgrades-bug-bounty-meta-title": "برنامهی جوایز شکار باگ لایهی اجماع",
- "page-upgrades-bug-bounty-not-included": "مشمول نشده",
- "page-upgrades-bug-bounty-not-included-desc": "ادغام و ارتقاهای خردهزنجیره همچنان به شکل فعال در حال توسعهاند و در نتیجه هنوز مشمول برنامهی پاداش نیستند.",
+ "page-upgrades-bug-bounty-ledger-desc": "مشخصات اتریوم منطق طراحی لایه اجرا و لایه اجماع را شرح می دهد.",
+ "page-upgrades-bug-bounty-ledger-title": "اشکالات مشخصات",
+ "page-upgrades-bug-bounty-meta-description": "مروری بر برنامه پاداش باگ اتریوم: نحوه مشارکت و پاداش دادن به اطلاعات.",
+ "page-upgrades-bug-bounty-meta-title": "برنامه پاداش باگ اتریوم",
+ "page-upgrades-bug-bounty-not-included": "خارج از دامنه",
+ "page-upgrades-bug-bounty-not-included-desc": "فقط اهدافی که در محدوده فهرست شده اند، بخشی از برنامه پاداش باگ هستند. این بدان معناست که برای مثال زیرساخت های ما مانند صفحات وب، dns، ایمیل و غیره، بخشی از محدوده پاداش نیستند. باگ های قرارداد ERC20 معمولاً در محدوده پاداش گنجانده نمی شوند. با این حال، ما میتوانیم در ارتباط با طرفهای آسیبدیده، مانند نویسندگان یا صرافی ها در چنین مواردی، کمک کنیم. ENS توسط بنیاد ENS نگهداری می شود، و بخشی از محدوده پاداش نیست. آسیبپذیریهایی که کاربر را ملزم به افشای عمومی یک API، مانند JSON-RPC یا Beacon API میکند، خارج از محدوده برنامه پاداش باگ است.",
"page-upgrades-bug-bounty-owasp": "مشاهده روش OWASP",
- "page-upgrades-bug-bounty-points": "بنیاد همچنین امتیازاتی را به شرح زیر اهدا میکند:",
+ "page-upgrades-bug-bounty-points": "بنیاد همچنین پاداشهایی را به شرح زیر اهدا میکند:",
"page-upgrades-bug-bounty-points-error": "خطا در بارگذاری داده... لطفا بازنشانی کنید.",
"page-upgrades-bug-bounty-points-exchange": "تبادل امتیازها",
"page-upgrades-bug-bounty-points-loading": "در حال بارگیری دادهها...",
@@ -40,40 +50,41 @@
"page-upgrades-bug-bounty-quality-desc": ": به ارسالیهای تمیز و خوانا جوایز بیشتری تعلق میگیرد.",
"page-upgrades-bug-bounty-quality-fix": "کیفیت رفع مشکل، در صورت شمول: به ارسالیهایی که شامل توضیح شفاف درباره چگونگی رفع مشکل باشند پاداش بیشتری تعلق میگیرد.",
"page-upgrades-bug-bounty-quality-repro": "کیفیت تکرارپذیری",
- "page-upgrades-bug-bounty-quality-repro-desc": ": لطفا کد آزمایشی، اسکریپتها و دستورالعملها را با جزئیات ضمیمه کنید. هرچه تکرارپذیری و تشخیص آسیبپذیری برای ما سادهتر باشد، پاداش بیشتر خواهند بود.",
+ "page-upgrades-bug-bounty-quality-repro-desc": ": برای واجد شرایط بودن برای جوایز، باید یک اثبات مفهوم (POC) گنجانده شود. لطفا کد تست، اسکریپت ها و دستورالعمل های دقیق را وارد کنید. هرچه بازتولید و تأیید آسیبپذیری برای ما آسانتر باشد، پاداش بالاتری خواهد داشت.",
"page-upgrades-bug-bounty-questions": "سؤالی دارید؟",
- "page-upgrades-bug-bounty-rules": "خواندن قوانین",
- "page-upgrades-bug-bounty-slogan": "پیدا کردن باگ لایهی اجماع",
- "page-upgrades-bug-bounty-specs": "خواندن مشخصات جامع",
- "page-upgrades-bug-bounty-specs-docs": "اسناد و مدارک مشخصات",
+ "page-upgrades-bug-bounty-rules": "قوانین را بخوانید",
+ "page-upgrades-bug-bounty-slogan": "برنامه پاداش باگ",
+ "page-upgrades-bug-bounty-specs": "مشخصات لایه اجماع",
+ "page-upgrades-bug-bounty-execution-specs": "مشخصات لایه اجرا",
+ "page-upgrades-bug-bounty-specs-docs": "اسناد مشخصات",
"page-upgrades-bug-bounty-submit": "ارسال باگ",
- "page-upgrades-bug-bounty-submit-desc": "برای هر باگ که پیدا کنید، امتیاز دریافت خواهید کرد. امتیازهایی که کسب میکنید به شدت آسیبرسانی باگ بستگی دارد. باگهای Lodestar که در حال حاضر 10% از امتیازهای فهرست شده در زیر را دریافت میکنند، زیرا ممیزیهای اضافی در حال انجام است. بنیاد اتریوم (EF) شدت آسیبرسانی را با استفاده از روش OWASP تعیین میکند.",
- "page-upgrades-bug-bounty-subtitle": "با یافتن اشکالات در پروتکل لایهی اجماع و مشتریان، تا سقف 50,000 دلار آمریکا و همینطور جایگاهی در تابلوی امتیازات کسب کنید.",
+ "page-upgrades-bug-bounty-submit-desc": "برای هر اشکال معتبری که پیدا کنید، جوایزی دریافت خواهید کرد. تعداد جوایز اعطا شده بسته به شدت متفاوت خواهد بود. شدت بر اساس مدل رتبه بندی ریسک OWASP بسته به تأثیر بر شبکه اتریوم و احتمال محاسبه می شود.",
+ "page-upgrades-bug-bounty-subtitle": "با یافتن باگهای پروتکل، کاربر و Solidity که بر شبکه اتریوم تأثیر میگذارند، تا 250،000 دلار و جایگاهی در جدول امتیازات کسب کنید.",
"page-upgrades-bug-bounty-title": "امکان ارسال وجود دارد",
"page-upgrades-bug-bounty-title-1": "زنجیرهی بیکن",
"page-upgrades-bug-bounty-title-2": "انتخاب فورک",
"page-upgrades-bug-bounty-title-3": "قرارداد سپرده Solidity",
- "page-upgrades-bug-bounty-title-4": "شبکهی همتا به همتا",
+ "page-upgrades-bug-bounty-title-4": "شبکه همتا به همتا",
"page-upgrades-bug-bounty-type-1": "باگهای امنیتی/مخل قطعیت",
"page-upgrades-bug-bounty-type-2": "بردارهای ممانعت از سرویس (DOS)",
- "page-upgrades-bug-bounty-type-3": "عدم پیوستگی در تخمینها، مانند وضعیتی که در آن اعتبارسنجهای صادق ممکن است خط زده شوند",
+ "page-upgrades-bug-bounty-type-3": "عدم پیوستگی در فرضیات، مانند وضعیتی که در آن اعتبارسنجهای صادق ممکن است خط زده شوند",
"page-upgrades-bug-bounty-type-4": "عدم پیوستگی در محاسبات یا پارامترها",
"page-upgrades-bug-bounty-types": "انواع باگ",
- "page-upgrades-bug-bounty-validity": "باگهای معتبر",
- "page-upgrades-bug-bounty-validity-desc": "تمرکز این برنامهی پاداش برای باگ، مشخصات زنجیرهی بیکن لایهی اجماع هسته و Lighthouse، Nimbus، Teku، Prysm و پیادهسازیهای کلاینت Lodestar است.",
+ "page-upgrades-bug-bounty-validity": "در محدوده",
+ "page-upgrades-bug-bounty-validity-desc": "برنامه باگبانتی ما سرتاسر را در بر می گیرد: از صحت پروتکل ها (مانند مدل اجماع بلاکچین، پروتکل های سیمی و p2p، اثبات سهام و غیره) و انطباق پروتکل/پیاده سازی با امنیت شبکه و یکپارچگی اجماع. امنیت کلاسیک کاربر و نیز امنیت رمزنگاری های اولیه نیز بخشی از این برنامه است. در صورت وجود هرگونه ابهام، یک ایمیل به bounty@ethereum.org ارسال کنید و از ما سوال بپرسید. همچنین میتوانید افشا/آسیبپذیری را مستقیماً به آدرس bounty@ethereum.org ارسال کنید، در این صورت از شما می خواهیم که پیام را با استفاده از کلید PGP رمزگذاری کنید",
"page-upgrades-bug-bounty-card-critical": "بحرانی",
"page-upgrades-bug-bounty-card-critical-risk": "ارسال باگ با ریسک بحرانی",
"page-upgrades-bug-bounty-card-h2": "متوسط",
"page-upgrades-bug-bounty-card-high": "زیاد",
"page-upgrades-bug-bounty-card-high-risk": "ارسال باگ با ریسک زیاد",
- "page-upgrades-bug-bounty-card-label-1": "تا سقف 1,000 امتیاز",
- "page-upgrades-bug-bounty-card-label-2": "تا سقف 2,000 DAI",
- "page-upgrades-bug-bounty-card-label-3": "تا سقف 5,000 امتیاز",
- "page-upgrades-bug-bounty-card-label-4": "تا سقف 10,000 DAI",
- "page-upgrades-bug-bounty-card-label-5": "تا سقف 10,000 امتیاز",
- "page-upgrades-bug-bounty-card-label-6": "تا سقف 20,000 DAI",
- "page-upgrades-bug-bounty-card-label-7": "تا سقف 25,000 امتیاز",
- "page-upgrades-bug-bounty-card-label-8": "تا سقف 50,000 DAI",
+ "page-upgrades-bug-bounty-card-label-1": "تا سقف 1000 امتیاز",
+ "page-upgrades-bug-bounty-card-label-2": "تا 2000 دلار",
+ "page-upgrades-bug-bounty-card-label-3": "تا سقف 5000 امتیاز",
+ "page-upgrades-bug-bounty-card-label-4": "تا سقف 10000 دلار",
+ "page-upgrades-bug-bounty-card-label-5": "تا سقف 10000 امتیاز",
+ "page-upgrades-bug-bounty-card-label-6": "تا سقف 50000 دلار",
+ "page-upgrades-bug-bounty-card-label-7": "تا سقف 25000 امتیاز",
+ "page-upgrades-bug-bounty-card-label-8": "تا سقف 250000 دلار",
"page-upgrades-bug-bounty-card-li-1": "اثرات کم، احتمال متوسط",
"page-upgrades-bug-bounty-card-li-2": "اثرات متوسط، احتمال کم",
"page-upgrades-bug-bounty-card-li-3": "اثرات زیاد، احتمال کم",
@@ -88,8 +99,40 @@
"page-upgrades-bug-bounty-card-subheader": "شدت",
"page-upgrades-bug-bounty-card-subheader-2": "مثال",
"page-upgrades-bug-bounty-card-text": "مهاجم میتواند یک گره را گاهی در شرایطی قرار دهد که باعث رد کردن یک از هر صد تصدیق انجام شده توسط اعتبارسنج شود",
- "page-upgrades-bug-bounty-card-text-1": "مهاجم میتواند با موفقیت حملات خسوف (eclipse) را روی گرههایی با شناسهی همتای شامل 4 بایت اول صفر به انجام برساند",
- "page-upgrades-bug-bounty-card-text-2": "یک باگ وفاق بین 2 کلاینت وجود دارد، اما برای مهاجم سخت یا در عمل غیرممکن است که رویداد را شروع کند.",
- "page-upgrades-bug-bounty-card-text-3": "یک باگ وفاق بین 2 کلاینت وجود دارد، و شروع رویداد از سوی مهاجم بدیهی است.",
- "page-upgrades-question-title": "پرسشهای متداول"
+ "page-upgrades-bug-bounty-card-text-1": "مهاجم میتواند با موفقیت، حملات خسوف (eclipse) را روی گرههایی با شناسه همتای شامل 4 بایت اول صفر به انجام برساند",
+ "page-upgrades-bug-bounty-card-text-2": "مهاجم میتواند با موفقیت بخشهای بزرگی از شبکه را پارتیشن بندی کند، و تحریک آسیبپذیری برای مهاجم امری بیاهمیت است",
+ "page-upgrades-bug-bounty-card-text-3": "مهاجم میتواند با موفقیت اجرای کد از راه دور را در اکثر کاربرها انجام دهد، و برای یک مهاجم ایجاد آسیبپذیری بیاهمیت است",
+ "page-upgrades-question-title": "پرسشهای متداول",
+ "bug-bounty-faq-q1-title": "یک ثبت آسیب پذیری خوب چگونه باید باشد؟",
+ "bug-bounty-faq-q1-contentPreview": "یک نمونه واقعی از ارسال آسیب پذیری با کیفیت را ببینید.",
+ "bug-bounty-faq-q1-content-1": "شرح: رد خدمات از راه دور با استفاده از بلوک های غیرمعتبر",
+ "bug-bounty-faq-q1-content-2": "سناریوی حمله: یک مهاجم میتواند بلوکهایی را ارسال کند که ممکن است به محاسبات زیادی نیاز داشته باشند (حداکثر مقدار gasLimit) اما اثبات کار ندارند. اگر مهاجم به طور مداوم بلوک ها را ارسال کند، مهاجم ممکن است گره قربانی را مجبور به استفاده 100درصدی از CPU کند.",
+ "bug-bounty-faq-q1-content-3": "تأثیر: یک مهاجم میتواند از استفاده از CPU در گرههای راه دور سوء استفاده کند و احتمالاً باعث DoS کامل شود.",
+ "bug-bounty-faq-q1-content-4": " اجزاء: کاربر Go نسخه v0.6.8",
+ "bug-bounty-faq-q1-content-5": "بازتولید: ارسال یک بلوک به گره Go که حاوی tx های زیادی است اما PoW معتبری ندارد.",
+ "bug-bounty-faq-q1-content-6": "جزئیات: بلوکها در روش فرایند(بلوک، dontReact)
اعتبارسنجی میشوند. این روش کارهای گران قیمت را اجرا میکند که نیاز به CPU دارند، مانند اجرای تراکنش ها (sm.ApplyDiff
) و پس از آن اثبات کار را تأیید می کند (sm.ValidateBlock()
). این کار به مهاجم اجازه میدهد بلوکهایی را بفرستد که ممکن است به محاسبات زیاد نیاز داشته باشند (حداکثر gasLimit
) اما اثبات کار ندارند. اگر مهاجم به طور مداوم بلوکها را بفرستد، مهاجم ممکن است گره قربانی را مجبور به استفاده 100٪ از CPU کند.",
+ "bug-bounty-faq-q1-content-7": "رفع: ترتیب چک ها را معکوس کنید.",
+ "bug-bounty-faq-q2-title": "آیا برنامه پاداش باگ زمان محدودی دارد؟",
+ "bug-bounty-faq-q2-contentPreview": "خیر.",
+ "bug-bounty-faq-q2-content-1": "در حال حاضر تاریخ پایانی تعیین نشده است. برای آخرین اخبار به وبلاگ بنیاد اتریوم مراجعه کنید.",
+ "bug-bounty-faq-q3-title": "پاداشها چگونه پرداخت می شوند؟",
+ "bug-bounty-faq-q3-contentPreview": "پاداشها به صورت ETH یا DAI پرداخت می شوند.",
+ "bug-bounty-faq-q3-content-1": "پاداشها به صورت ETH یا DAI پس از تأیید اعتبار ارسال، معمولاً چند روز بعد، پرداخت میشوند. قوانین محلی ما را ملزم می کند احراز هویت شما را درخواست کنیم. علاوه بر این، به آدرس ETH شما نیاز داریم.",
+ "bug-bounty-faq-q4-title": "آیا می توانم پاداش خود را به خیریه اهدا کنم؟",
+ "bug-bounty-faq-q4-contentPreview": "بله!",
+ "bug-bounty-faq-q4-content-1": "ما میتوانیم پاداش شما را به یک سازمان خیریه تثبیت شده به انتخاب شما اهدا کنیم.",
+ "bug-bounty-faq-q5-title": "من یک مسئله/ آسیب پذیری را گزارش کردم اما پاسخی دریافت نکردم!",
+ "bug-bounty-faq-q5-contentPreview": "لطفا چند روز فرصت دهید تا یک نفر به درخواست شما پاسخ دهد.",
+ "bug-bounty-faq-q5-content-1": "هدف ما پاسخگویی به موارد ارسالی در سریع ترین زمان ممکن است. اگر ظرف یک یا دو روز پاسخی دریافت نکردید، میتوانید به bounty@ethereum.org ایمیل بزنید.",
+ "bug-bounty-faq-q6-title": "من می خواهم ناشناس باشم / نمی خواهم نامم در تابلوی امتیازات باشد.",
+ "bug-bounty-faq-q6-contentPreview": "می توانید این کار را انجام دهید، اما ممکن است واجد شرایط دریافت پاداش نباشید.",
+ "bug-bounty-faq-q6-content-1": "ارسال به صورت ناشناس یا با نام مستعار اشکالی ندارد، اما شما را واجد شرایط دریافت پاداش ETH/DAI نمیکند. برای واجد شرایط بودن برای جوایز ETH/DAI، به نام واقعی و مدرک هویت شما نیاز داریم. اهدای هدایایتان به یک موسسه خیریه، نیازی به هویت شما ندارد.",
+ "bug-bounty-faq-q6-content-2": "لطفاً اگر نمیخواهید نام/لقب شما در تابلوی امتیازات نمایش داده شود، به ما اطلاع دهید.",
+ "bug-bounty-faq-q7-title": "امتیازات در جدول امتیازات چیست؟",
+ "bug-bounty-faq-q7-contentPreview": "به هر آسیبپذیری/مسئله پیدا شده یک امتیاز اختصاص مییابد",
+ "bug-bounty-faq-q7-content-1": "به هر آسیبپذیری/مسئله پیدا شده یک امتیاز اختصاص مییابد. شکارچیان پاداش، بر اساس مجموع امتیازات در تابلوی امتیازات ما رتبهبندی می شوند.",
+ "bug-bounty-faq-q8-title": "یک کلید PGP دارید؟",
+ "bug-bounty-faq-q8-contentPreview": "بله. برای اطلاع از جزئیات باز کنید.",
+ "bug-bounty-faq-q8-content-1": "لطفاً از AE96 ED96 9E47 9B00 84F3 E17F E88D 3334 FA5F 6A0A
استفاده کنید",
+ "bug-bounty-faq-q8-PGP-key": "کلید PGP"
}
diff --git a/src/intl/fa/page-contributing-translation-program-acknowledgements.json b/src/intl/fa/page-contributing-translation-program-acknowledgements.json
new file mode 100644
index 00000000000..2e4d753a7c3
--- /dev/null
+++ b/src/intl/fa/page-contributing-translation-program-acknowledgements.json
@@ -0,0 +1,42 @@
+{
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-title": "قدردانی از مشارکت کنندگان",
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-1": "برنامه ترجمه یک تلاش مشترک است و هزاران مشارکت کننده به صورت داوطلبانه وقت خود را صرف کرده اند تا به ما کمک کنند وب سایت را در زبان های بیشتری در دسترس عموم قرار دهیم.",
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-2": "این صفحه به قدردانی از مترجمان و تلاش های آنها، برجسته کردن برجسته ترین همکاران ما و حمایت از آنها در ماموریتهای حرفه ایشان اختصاص داده شده است.",
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-3": "همه مترجمان فعال پروژه ما در Crowdin در صفحه مشارکت کنندگان ما نشان داده شده اند.",
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-link": "تمام مترجمان ethereum.org را مشاهده کنید",
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-4": "فعال ترین مترجمان، همچنین در یک دوره معین جایگاه خود را در تابلوی امتیازات ترجمه کسب خواهند کرد.",
+ "page-contributing-translation-program-acknowledgements-acknowledgement-page-5": "مترجمان حرفه ای یا آینده، و همچنین دانشجویان ترجمه و کارشناسان زبان که به دنبال افزودن یک زمینه تخصصی جدید هستند، می توانند برای تأیید مشارکت خود در وب سایت، گواهی مترجم درخواست کنند.",
+ "page-contributing-translation-program-acknowledgements-cert-title": "گواهی",
+ "page-contributing-translation-program-acknowledgements-cert-1": "ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. با در نظر گرفتن این موضوع، ما گواهینامه مترجم ethereum.org را طراحی کرده ایم.",
+ "page-contributing-translation-program-acknowledgements-cert-2": "این گواهی برای مترجمان حرفه ای و آینده در نظر گرفته شده است که می خواهند از آن به عنوان مرجع استفاده کنند، تخصص خود را در ترجمه محتوای فنی ثابت کنند یا صرفاً تعهد خود را به اتریوم نشان دهند.",
+ "page-contributing-translation-program-acknowledgements-cert-3": "اگر شما در برنامه ترجمه مشارکت کرده اید و حداقل 5000 کلمه ترجمه شده شما تایید شده است، می توانید با ارسال ایمیل به ما به آدرس translations@ethereum.org گواهی ترجمه خود را درخواست کنید. پیام شما باید شامل لینک به حساب Crowdin شما و نام کامل شما (یا نام مستعار، در صورت تمایل) باشد که به گواهی اضافه خواهیم کرد.",
+ "page-contributing-translation-program-acknowledgements-hero-image-alt": "تصویر شیبای قهرمان برنامه ترجمه",
+ "page-contributing-translation-program-acknowledgements-meta-description": "قدردانی از تمام کارهای بزرگی که مترجمان ما انجام می دهند",
+ "page-contributing-translation-program-acknowledgements-meta-title": "قدردانی از مترجمان",
+ "page-contributing-translation-program-acknowledgements-our-translators-cta": "فهرست کامل مترجمان ما را که زمان و مهارت های خود را برای کمک به در دسترس قرار دادن محتوای اتریوم برای همه اختصاص می دهند، ببینید.",
+ "page-contributing-translation-program-acknowledgements-our-translators-title": "مترجمان ما",
+ "page-contributing-translation-program-acknowledgements-our-translators-view-all": "مشاهده همه مترجمان",
+ "page-contributing-translation-program-acknowledgements-our-translators-1": "جامعه، در قلب برنامه ترجمه ethereum.org قرار دارد. تمامی مترجمان انجمن ما را در زیر ببینید.",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-title": "تابلوی امتیازات ترجمه",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-cta": "به ما در ترجمه ethereum.org کمک کنید و در تابلوی امتیازات مترجم جایگاهی کسب کنید!",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-1": "ما میخواهیم مترجمان برجسته را بر اساس فعالیتهای اخیر معرفی کنیم و همچنین تأثیرگذارترین مشارکتکنندگان در تمام دوران خود را برجسته کنیم. تابلوی امتیازات ما دادههای فعالترین مترجمان را با استفاده از نمای ماهانه، فصلی و تمام دوران دنبال میکند و در ابتدای هر ماه بهروزرسانی میشود. مترجمان بر اساس تعداد کلمات \"برنده\" (تعداد کلمات ترجمه شده که در فرآیند بررسی تایید می شوند) در تابلوی امتیازات قرار می گیرند.",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-all-time-view": "نمای کل دوران",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-month-view": "نمای ماهانه",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-quarter-view": "نمای فصلی",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-show-less": "نمایش کمتر",
+ "page-contributing-translation-program-acknowledgements-translation-leaderboard-show-more": "نمایش بیشتر",
+ "page-contributing-translation-program-acknowledgements-translator": "مترجم",
+ "page-contributing-translation-program-acknowledgements-language": "زبان",
+ "page-contributing-translation-program-acknowledgements-total-words": "کل واژه ها",
+ "page-contributing-translation-program-acknowledgements-oats-title": "OATها",
+ "page-contributing-translation-program-acknowledgements-1": "مشارکت کنندگان در برنامه ترجمه واجد شرایط OAT های مختلف (توکن های موفقیت زنجیرهای) هستند - توکن های غیرقابل تعویض که مشارکت آنها در برنامه ترجمه ethereum.org را ثابت می کند.",
+ "page-contributing-translation-program-acknowledgements-2": "ما بر اساس فعالیت مترجمان، OATهای مختلف برای آنها داریم",
+ "page-contributing-translation-program-acknowledgements-3": "اگر به تلاش گروهی ترجمه در پلتفرم Crowdin کمک کرده اید، یک OAT در انتظار شماست!",
+ "page-contributing-translation-program-acknowledgements-how-to-claim-title": "چگونه درخواست کنید",
+ "page-contributing-translation-program-acknowledgements-how-to-claim-1": "پیوستن به ما",
+ "page-contributing-translation-program-acknowledgements-how-to-claim-1-discord": "سرور دیسکورد",
+ "page-contributing-translation-program-acknowledgements-how-to-claim-2": "لینک به حساب Crowdin خود را در کانال #🥇 | proof-of-contribution درج کنید.",
+ "page-contributing-translation-program-acknowledgements-how-to-claim-3": "منتظر باشید تا یکی از اعضای تیم ما نقش های مورد نیاز برای درخواست OATتان را به شما اختصاص دهد.",
+ "page-contributing-translation-program-acknowledgements-how-to-claim-4": "OATهای خود را درخواست کنید!",
+ "page-contributing-translation-program-acknowledgements-4": "برای درخواست OAT فقط باید از کیفپول های خودسرپرست استفاده کنید. از حسابهای صرافی یا سایر حسابهایی که کلیدهای خصوصی را در اختیار ندارید، استفاده نکنید، زیرا به شما اجازه دسترسی و مدیریت OAT را نمیدهند."
+}
diff --git a/src/intl/fa/page-contributing-translation-program-contributors.json b/src/intl/fa/page-contributing-translation-program-contributors.json
new file mode 100644
index 00000000000..02fc2d4a05f
--- /dev/null
+++ b/src/intl/fa/page-contributing-translation-program-contributors.json
@@ -0,0 +1,10 @@
+{
+ "page-contributing-translation-program-contributors-thank-you": "ما می خواهیم از همه همکاران مان تشکر کنیم!",
+ "page-contributing-translation-program-contributors-title": "مترجمان ما",
+ "page-contributing-translation-program-contributors-our-translators-1": "جامعه، در قلب برنامه ترجمه ethereum.org قرار دارد.",
+ "page-contributing-translation-program-contributors-our-translators-2": "با وجود هزاران نفر از اعضای جامعه که در ترجمه پروژه ما مشارکت دارند، قدردانی از همه افراد دشوار است.",
+ "page-contributing-translation-program-contributors-our-translators-3": "همه مترجمان بر اساس نام انتخابی خود در Crowdin بر اساس حروف الفبا فهرست شده اند. اگر مترجم هستید و می خواهید از نام واقعی، نام مستعار، دامنه ENS و غیره استفاده کنید، می توانید نام کامل خود را در Crowdin تغییر دهید.",
+ "page-contributing-translation-program-contributors-meta-title": "مترجمان ما",
+ "page-contributing-translation-program-contributors-meta-description": "فهرستی از کسانی که در ترجمه ما مشارکت داشته اند.",
+ "page-contributing-translation-program-contributors-number-of-contributors": "تعداد مشارکت کنندگان:"
+}
diff --git a/src/intl/fa/page-dapps.json b/src/intl/fa/page-dapps.json
index 3bfa3f8cc1d..6b445bc0658 100644
--- a/src/intl/fa/page-dapps.json
+++ b/src/intl/fa/page-dapps.json
@@ -41,6 +41,7 @@
"page-dapps-choose-category": "انتخاب دسته",
"page-dapps-category-social": "رسانههای اجتماعی",
"page-dapps-category-content": "محتوا",
+ "page-dapps-category-community": "جامعه",
"page-dapps-category-messaging": "پیامرسانی",
"page-dapps-category-identity": "هویت",
"page-dapps-collectibles-benefits-1-description": "زمانی که یک اثر هنری روی اتریوم به صورت توکن در بیاید، وضعیت مالکیت اثر به صورت همگانی قابل مشاهده خواهد بود. شما میتوانید سیر گردش اثر هنری از زمان خلق تا رسیدن به مالک کنونی را ردگیری کنید. این موضوع جلوی جعل را میگیرد.",
@@ -95,6 +96,7 @@
"page-dapps-dapp-description-loopring": "پلتفرم تجاری همتابههمتا که برای تسریع در امور ساخته شده است.",
"page-dapps-dapp-description-marble-cards": "بر اساس آدرسهای اینترتی، کارتهای دیجیتالی منحصربهفردی را ایجاد کرده و به معامله بگذارید.",
"page-dapps-dapp-description-matcha": "برای کمک به شما در یافتن بهترین قیمتها، مبادلات بسیاری را جستجو میکند.",
+ "page-dapps-dapp-description-meeds": "جامعه Web3 با پاداش عادلانه و شفاف به مشارکتهای مهم، پایگاهیست برای عصر فعالیتهای غیرمتمرکز.",
"page-dapps-dapp-description-mirror": "پلتفرم قدرتمند انتشار موازی، که بر روی وب 3 برای وب 3 ساخته شده است و مرزهای نگارش آنلاین را جابجا میکند",
"page-dapps-dapp-description-multichain": "مسیریاب نهایی برای وب 3. این زیرساخت برای تعاملات تصادفی بین زنجیرهای توسعه یافته است.",
"page-dapps-dapp-description-nifty-gateway": "آثار هنرمندان، ورزشکاران، برندها و سازندگان را از روی زنجیره خریداری کنید.",
@@ -113,6 +115,7 @@
"page-dapps-dapp-description-rotki": "پیگیری پورتفولیو با منبع آزاد، تجزیه و تحلیل، حسابداری و ابزار اظهار مالیاتی که به حریم خصوصی شما احترام میگذارد.",
"page-dapps-dapp-description-krystal": "یک پلتفرم جامع برای دسترسی به تمام خدمات دیفای محبوبتان.",
"page-dapps-dapp-description-rarible": "به ایجاد، خرید و فروش کالاهای توکنشده بپردازید.",
+ "page-dapps-dapp-description-request-finance": "مجموعهای از ابزارهای مالی برای فاکتورهای رمزارزی، فیش حقوقی و هزینهها.",
"page-dapps-dapp-description-rubic": "تجمیع کننده فناوری Cross-Chain برای کاربران و برنامههای غیرمتمرکز (dApp).",
"page-dapps-dapp-description-sablier": "جریانسازی پول در آن واحد.",
"page-dapps-dapp-description-spatial": "آواتار و دنیای سهبعدی دلخواه خود را بسازید",
@@ -217,6 +220,7 @@
"page-dapps-marble-cards-logo-alt": "لوگوی marble.cards",
"page-dapps-async-logo-alt": "لوگوی Async",
"page-dapps-matcha-logo-alt": "لوگوی Matcha",
+ "page-dapps-meeds-logo-alt": "لوگوی Meeds",
"page-dapps-metaverse-benefits-title": "متاورس",
"page-dapps-metaverse-benefits-description": "چه چیزی در مورد اتریوم وجود دارد که به متاورس امکان رشد میدهد؟",
"page-dapps-metaverse-benefits-1-title": "توکنهای معاوضهناپذیر",
@@ -241,6 +245,7 @@
"page-dapps-ready-button": "برو",
"page-dapps-ready-description": "یک دپ را انتخاب کرده و امتحان کنید",
"page-dapps-ready-title": "آمادهاید؟",
+ "page-dapps-request-finance-logo-alt": "لوگوی Request Finance",
"page-dapps-rubic-logo-alt": "لوگوی Rubic",
"page-dapps-sablier-logo-alt": "لوگوی Sablier",
"page-dapps-set-up-a-wallet-button": "کیف پول را پیدا کنید",
@@ -281,5 +286,7 @@
"page-dapps-dapp-description-dodo": "DODO یک ارائهدهنده نقدینگی زنجیرهای است که از الگوریتم بازارساز فعال (PMM) استفاده میکند",
"page-dapps-dodo-image-alt": "لوگوی DODO",
"page-dapps-dapp-description-artblocks": "Art Blocks به جان بخشیدن به آثار قانعکننده از هنر مولد معاصر اختصاص دارد",
- "page-dapps-artblocks-image-alt": "لوگوی Art Blocks"
+ "page-dapps-artblocks-image-alt": "لوگوی Art Blocks",
+ "page-dapps-explore-title": "میخواهید اپلیکیشنهای بیشتری را مرور کنید؟",
+ "page-dapps-explore": "صدها اپلیکیشن غیرمتمرکز (dapps) را بررسی کنید"
}
diff --git a/src/intl/fa/page-developers-docs.json b/src/intl/fa/page-developers-docs.json
index 56bd06e1a47..f1913558b68 100644
--- a/src/intl/fa/page-developers-docs.json
+++ b/src/intl/fa/page-developers-docs.json
@@ -20,6 +20,7 @@
"docs-nav-data-and-analytics": "دادهها و تحلیلها",
"docs-nav-data-and-analytics-description": "چطور دادههای درون زنجیرهی بلوکی در برنامههای غیر متمرکز جمعآوری، سازماندهی و پیادهسازی میشوند",
"docs-nav-data-availability": "دسترسی به دادهها",
+ "docs-nav-data-availability-storage-strategies": "راهکارهای ذخیرهسازی داده در زنجیره بلوکی",
"docs-nav-dart": "دارت",
"docs-nav-delphi": "دلفی",
"docs-nav-deploying-smart-contracts": "بکارگیری قراردادهای هوشمند",
@@ -30,6 +31,7 @@
"docs-nav-development-frameworks-description": "این ابزار توسعهی اتریوم را سادهتر میکند",
"docs-nav-development-networks": "شبکههای توسعه",
"docs-nav-development-networks-description": "فضای محلی زنجیرهی بلوکی برای آزمایش برنامههای غیرمتمرکز قبل از بکارگیری",
+ "docs-nav-dex-design-best-practice": "بهترین شیوههای طراحی صرافی غیرمتمرکز (DEX)",
"docs-nav-dot-net": "داتنت",
"docs-nav-erc-20": "ERC-20: توکنهای قابلتعویض",
"docs-nav-erc-721": "ERC-721: توکنهای غیرقابلتعویض",
@@ -45,6 +47,7 @@
"docs-nav-gas": "گاز",
"docs-nav-gas-description": "قدرت محاسباتی مورد نیاز برای محاسبه تراکنشها یا همان کارمزد تراکنش در اتریوم توسط فرستندهها به صورت اتر پرداخت میشود",
"docs-nav-golang": "گولنگ",
+ "docs-nav-heuristics-for-web3": "اکتشاف برای Web3",
"docs-nav-integrated-development-environments-ides": "محیطهای یکپارچهی توسعه (IDEها)",
"docs-nav-integrated-development-environments-ides-description": "بهترین محیط برای کدنویسی برنامههای غیرمتمرکز",
"docs-nav-intro-to-dapps": "معرفی dappها",
@@ -79,6 +82,7 @@
"docs-nav-oracles-description": "چگونگی ثبت اطلاعات در شبکه زنجیرهی بلوکی اتریوم",
"docs-nav-programming-languages": "زبانهای برنامهنویسی",
"docs-nav-programming-languages-description": "چگونه با زبانهایی که از قبل میشناسیم کار با اتریوم شروع کنیم",
+ "docs-nav-proof-of-authority": "اثبات صلاحیت (PoA)",
"docs-nav-proof-of-stake": "اثبات سهام",
"docs-nav-proof-of-work": "اثبات کار",
"docs-nav-python": "پایتون",
diff --git a/src/intl/fa/page-developers-index.json b/src/intl/fa/page-developers-index.json
index 1c104e1a014..5f954629fa4 100644
--- a/src/intl/fa/page-developers-index.json
+++ b/src/intl/fa/page-developers-index.json
@@ -2,38 +2,38 @@
"page-developer-meta-title": "منابع توسعهدهنده اتریوم",
"page-developers-about": "درباره این منابع توسعهدهنده",
"page-developers-about-desc": "ethereum.org برای کمک به ساختن اتریوم با اسناد در مورد مفاهیم بنیادی و همچنین مجموعه توسعه به شما کمک میکند. همچنین آموزشهایی برای راهاندازی و شروع موجود است.",
- "page-developers-about-desc-2": "با الهام از شبکه توسعه دهندگان مرورگر Mozilla، ما فکر کردیم که اتریوم به مکانی برای نگه داشتن محتوای توسعه دهندگان و منابع نیاز دارد. مانند دوستانمان در Mozilla، تمامی موارد در اینجا منبع باز و آماده برای گسترش و پیشرفت توسط شما است.",
+ "page-developers-about-desc-2": "با الهام از شبکه توسعه دهندگان مرورگر Mozilla، ما فکر کردیم که اتریوم به مکانی برای نگه داشتن محتوای توسعه دهندگان و منابع نیاز دارد. مانند دوستانمان در Mozilla، تمامی موارد در اینجا منبع باز و آماده برای گسترش و بهبود توسط شما است.",
"page-developers-account-desc": "قراردادها یا افراد در شبکه",
- "page-developers-accounts-link": "حسابهای کاربری",
+ "page-developers-accounts-link": "حسابها",
"page-developers-advanced": "پیشرفته",
"page-developers-api-desc": "استفاده از کتابخانهها برای تعامل با قراردادهای هوشمند",
- "page-developers-api-link": "بک اند وب سرویسها",
+ "page-developers-api-link": "وب سرویسهای بکاند",
"page-developers-block-desc": "دستههایی از تراکنشهای اضافه شده به بلاکچین",
"page-developers-block-explorers-desc": "پورتال شما به دادههای اتریوم",
- "page-developers-block-explorers-link": " جستجوگرهای بلوک",
+ "page-developers-block-explorers-link": " جستجوگرهای بلاک",
"page-developers-blocks-link": "بلوکها",
"page-developers-browse-tutorials": "مرور آموزشها",
"page-developers-choose-stack": "انتخاب سهم خود",
"page-developers-contribute": "مشارکت",
"page-developers-dev-env-desc": "IDE هایی که برای توسعه ی dapp ها مناسب هستند",
- "page-developers-dev-env-link": "محیطهای برنامه نویسی",
+ "page-developers-dev-env-link": "محیطهای توسعه",
"page-developers-discord": "به دیسکورد بپیوندید",
"page-developers-docs-introductions": "معرفی",
"page-developers-evm-desc": "رایانهای که تراکنشها را پردازش میکند",
- "page-developers-evm-link": "دستگاه مجازی اتریوم (EVM)",
+ "page-developers-evm-link": "ماشین مجازی اتریوم (EVM)",
"page-developers-explore-documentation": "جستجوی اسناد",
- "page-developers-feedback": "نظرات و پیشنهادات خود را از طریق مطرح کردن یک Issue در GitHub یا از طریق سرور Discord ما با ما مطرح نمایید",
- "page-developers-frameworks-desc": "ابزار برای کمک به تسریع توسعه",
+ "page-developers-feedback": "نظرات و پیشنهادات خود را از طریق مطرح کردن یک Issue در Github یا از طریق سرور دیسکورد ما با ما مطرح نمایید.",
+ "page-developers-frameworks-desc": "ابزارهایی برای کمک به تسریع توسعه",
"page-developers-frameworks-link": "چارچوبهای توسعه",
"page-developers-fundamentals": "اصول بنیادی",
- "page-developers-gas-desc": "برای تقویت تراکنشها، اتر مورد نیاز است",
+ "page-developers-gas-desc": "برای تقویت تراکنشها، اتر لازم است",
"page-developers-gas-link": "گاز",
"page-developers-get-started": "چگونه میخواهید شروع کنید؟",
"page-developers-improve-ethereum": "به ما در بهبود ethereum.org کمک کنید",
"page-developers-improve-ethereum-desc": "مانند ethereum.org، این اسناد تلاشی در سطح جامعه است. در صورت مشاهده اشتباه، فضایی برای بهبود، یا فرصتهای جدید، برای کمک به توسعهدهندگان اتریوم، یک PR ایجاد کنید.",
"page-developers-into-eth-desc": "معرفی بلاکچین و اتریوم",
"page-developers-intro-ether-desc": "مقدمهای بر ارزهای رمزنگاری شده و اتر",
- "page-developers-intro-dapps-desc": "معرفی پخش افزار",
+ "page-developers-intro-dapps-desc": "معرفی برنامههای غیرمتمرکز",
"page-developers-intro-dapps-link": "معرفی دپها",
"page-developers-intro-eth-link": "معرفی اتریوم",
"page-developers-intro-ether-link": "معرفی اتر",
@@ -41,13 +41,13 @@
"page-developers-intro-stack-desc": "معرفی سهام اتریوم",
"page-developers-js-libraries-desc": "استفاده از جاوا اسکریپت برای تعامل با قراردادهای هوشمند",
"page-developers-js-libraries-link": "کتابخانههای جاوا اسکریپت",
- "page-developers-language-desc": "کاربرد اتریوم با زبانهای آشنا",
+ "page-developers-language-desc": "استفاده از اتریوم با زبانهای آشنا",
"page-developers-languages": "زبانهای برنامهریزی",
"page-developers-learn": "آموزش توسعه اتریوم",
- "page-developers-learn-desc": "مفاهیم اصلی و سهام اتریوم را با اسناد ما بخوانید",
+ "page-developers-learn-desc": "مفاهیم اصلی و سهام اتریوم را با اسناد ما بخوانید.",
"page-developers-learn-tutorials": "از طریق برنامه آموزشی یاد بگیرید",
"page-developers-learn-tutorials-cta": "مشاهده برنامههای آموزشی",
- "page-developers-learn-tutorials-desc": "توسعه اتریوم را گام به گام از سازندگانی که قبلاً آنرا انجام داده اند یاد بگیرید.",
+ "page-developers-learn-tutorials-desc": "توسعه اتریوم را گام به گام از سازندگانی که قبلاً آن را انجام داده اند یاد بگیرید.",
"page-developers-meta-desc": "اسناد، برنامههای آموزشی و ابزارهایی برای توسعهدهندگان اتریوم.",
"page-developers-mev-desc": "مقدمهای بر حداکثر مقدار قابلاستخراج (MEV)",
"page-developers-mev-link": "حداکثر مقدار قابلاستخراج (MEV)",
@@ -57,9 +57,9 @@
"page-developers-mining-algorithms-link": "الگوریتمهای استخراج",
"page-developers-networks-desc": "مروری بر شبکه اصلی و شبکههای آزمایشی",
"page-developers-networks-link": "شبکهها",
- "page-developers-node-clients-desc": "بلوکها و تراکنشها چگونه در شبکه بررسی میشوند",
+ "page-developers-node-clients-desc": "بلوکها و تراکنشها چگونه در شبکه تایید میشوند",
"page-developers-node-clients-link": "گرهها و کاربرها",
- "page-developers-oracle-desc": "وارد کردن دادههای زنجیرهای در قراردادهای هوشمند شما",
+ "page-developers-oracle-desc": "وارد کردن دادههای خارج زنجیره در قراردادهای هوشمند شما",
"page-developers-oracles-link": "اوراکلها",
"page-developers-play-code": "بازی با کد",
"page-developers-read-docs": "مطالعه اسناد",
@@ -71,6 +71,8 @@
"page-developers-setup-desc": "با پیکربندی یک محیط توسعه، مجموعه خود را برای ساختن آماده کنید.",
"page-developers-smart-contracts-desc": "منطق پشت دپها – توافقنامههای خوداجرایی",
"page-developers-smart-contracts-link": "قراردادهای هوشمند",
+ "page-developers-speedrunethereum-title": "مهم ترین مفاهیم را با ساختن روی اتریوم، یاد بگیرید",
+ "page-developers-speedrunethereum-link": "SpeedRun Ethereum",
"page-developers-stack": "مجموعه",
"page-developers-start": "شروع به آزمایش",
"page-developers-start-desc": "میخواهید اول آزمایش کنید، بعد سؤال بپرسید؟",
diff --git a/src/intl/fa/page-developers-learning-tools.json b/src/intl/fa/page-developers-learning-tools.json
index b3943319228..b6c91d13fba 100644
--- a/src/intl/fa/page-developers-learning-tools.json
+++ b/src/intl/fa/page-developers-learning-tools.json
@@ -6,6 +6,10 @@
"page-learning-tools-browse-docs": "مرور اسناد",
"page-learning-tools-capture-the-ether-description": "گرفتن اتر بازیای است که در آن شما با هک کردن قراردادهای هوشمند اتریوم، درباره امنیت اطلاعات کسب میکنید.",
"page-learning-tools-capture-the-ether-logo-alt": "لوگوی Capture the Ether",
+ "page-learning-tools-node-guardians-description": "نود گاردینز (Node Guardians) یک پلتفرم آموزشی گیمفای شده است که توسعه دهندگان web3 را در فضایی قرار میدهد که مراحلی را طی کنند تا در برنامه نویسی Solidity و Cairo و Noir و Huff تسلط پیدا کنند.",
+ "page-learning-tools-node-guardians-logo-alt": "لوگوی Node Guardians",
+ "page-learning-tools-chainshot-description": "کارگاه از راه دور و مربی محور توسعهدهندگان اتریوم و دروس تکمیلی.",
+ "page-learning-tools-chainshot-logo-alt": "لوگوی ChainShot",
"page-learning-tools-coding": "آموزش از طریق کدنویسی",
"page-learning-tools-coding-subtitle": "اگر خواهان تجربه یک یادگیری تعاملی با اتریوم هستید، این ابزارها به شما کمک خواهند کرد.",
"page-learning-tools-consensys-academy-description": "کارگاه آنلاین توسعه اتریوم.",
@@ -14,6 +18,8 @@
"page-learning-tools-buildspace-logo-alt": "لوگوی _buildspace",
"page-learning-tools-cryptozombies-description": "بازی زامبی خودتان را طراحی کنید و از این طریق Solidity را یاد بگیرید.",
"page-learning-tools-cryptozombies-logo-alt": "لوگوی CryptoZombies",
+ "page-learning-tools-dapp-world-description": "یک اکوسیستم ارتقای مهارت زنجیبره بلوکی شامل دورهها، آزمونها، تمرین عملی و مسابقات هفتگی.",
+ "page-learning-tools-dapp-world-logo-alt": "نشان جهانی دپ",
"page-learning-tools-documentation": "یادگیری با مستندات",
"page-learning-tools-documentation-desc": "میخواهید بیشتر بدانید؟ با مراجعه به مستندات هر توضیحاتی را که میخواهید پیدا کنید.",
"page-learning-tools-eth-dot-build-description": "یک sandbox آموزشی برای web3، با قابلیت برنامه نویسی کشیدن و انداختن و بلوکهای ساختن متن باز.",
@@ -26,10 +32,12 @@
"page-learning-tools-game-tutorials-desc": "در حین بازی یاد بگیرید. این آموزشها از طریق بازی به شما مقدمات را آموزش خواهند داد.",
"page-learning-tools-meta-desc": "ابزارهای کدنویسی مبتنی بر وب و تجربیات یادگیری تعاملی برای کمک به شما در آزمایش توسعه اتریوم.",
"page-learning-tools-meta-title": "ابزارهای یادگیری توسعهدهنده",
+ "page-learning-tools-atlas-logo-alt": "لوگوی Atlas",
+ "page-learning-tools-atlas-description": "قرارداد های هوشمند را بنویسید، تست کنید و در چند دقیقه با Atlas IDE اجرا کنید.",
"page-learning-tools-questbook-description": "آموزشهای متناسب هر فرد برای یادگیری Web 3.0 از راه ساختن",
"page-learning-tools-questbook-logo-alt": "لوگوی Questbook",
"page-learning-tools-remix-description": "توسعه، استقرار و مدیریت قراردادهای هوشمند برای اتریوم. با افزونه Learneth آموزشها را دنبال کنید.",
- "page-learning-tools-remix-description-2": "Remix، Replit، و ChainIDE فقط جعبههای شنی نیستند – توسعهدهندگان میتوانند قراردادهای هوشمند خود را با استفاده از آنها بنویسند، کامپایل و مستقر کنند.",
+ "page-learning-tools-remix-description-2": "Remix و Replit و ChainIDE و Atlas فقط محیط تست نیستند، توسعه دهندهها میتوانند بنویسند، کامپایل کنند و قرارداد های هوشمند خود را به کمک آنها اجرا کنند.",
"page-learning-tools-replit-description": "یک محیط توسعه قابل تنظیم برای اتریوم با بارگذاری مجدد موارد پرطرفدار، بررسی خطا، و پشتیبانی درجه یک تست شبکه.",
"page-learning-tools-chainIDE-description": "سفر خود به Web3 را با نوشتن قراردادهای هوشمند برای اتریوم با ChainIDE آغاز کنید. از الگوهای داخلی برای یادگیری و صرفه جویی در زمان استفاده کنید.",
"page-learning-tools-chainIDE-logo-alt": "لوگوی ChainIDE",
@@ -46,9 +54,11 @@
"page-learning-tools-vyperfun-logo-alt": "لوگوی Vyper.fun",
"page-learning-tools-nftschool-description": "از لحاظ فنی درباره توکنهای تعویض ناپذیر، یا NFTها کاوش کنید.",
"page-learning-tools-nftschool-logo-alt": "لوگوی NFT school",
+ "page-learning-tools-pointer-description": "مهارتهای توسعهدهندگی Web3 را با آموزشهای تعاملی جذاب یاد بگیرید. در این مسیر پاداشهای رمزارزی به دست آورید",
+ "page-learning-tools-pointer-logo-alt": "لوگوی اشارهگر",
"page-learning-tools-platzi-description": "یاد بگیرید که چگونه dAppها را در Web3 بسازید و بر تمام مهارتهای لازم برای تبدیل شدن به یک توسعهدهنده زنجیرهی بلوکی مسلط شوید.",
"page-learning-tools-platzi-logo-alt": "لوگوی پلاتزی",
"page-learning-tools-alchemy-university-description": "حرفه وب 3 خود را از طریق دوره ها، پروژه ها و کد توسعه دهید.",
"page-learning-tools-alchemy-university-logo-alt": "لوگوی دانشگاه کیمیاگری",
"alt-eth-blocks": "تصویری از بلوکهایی که مانند نماد ETH سازماندهی شده اند"
-}
\ No newline at end of file
+}
diff --git a/src/intl/fa/page-developers-local-environment.json b/src/intl/fa/page-developers-local-environment.json
index a0ce482ffb3..e09065c1e08 100644
--- a/src/intl/fa/page-developers-local-environment.json
+++ b/src/intl/fa/page-developers-local-environment.json
@@ -30,6 +30,8 @@
"page-local-environment-setup-title": "یک محیط توسعه محلی راه اندازی کنید",
"page-local-environment-solidity-template-desc": "یک الگوی GitHub برای راه اندازی از پیش ساخته شده برای قراردادهای هوشمند Solidity شما. شامل یک شبکه محلی Hardhat، Waffle برای آزمایش، Ethers برای اجرای کیف پول و موارد دیگر است.",
"page-local-environment-solidity-template-logo-alt": "لوگوی الگوی Solidity",
+ "page-local-environment-truffle-desc": "Truffle Suite توسعه دهندگان را تا حد امکان راحت از ایده به دپ میرساند.",
+ "page-local-environment-truffle-logo-alt": "لوگوی Truffle",
"page-local-environment-waffle-desc": "پیشرفته ترین کتاب تست قراردادهای هوشمند. به تنهایی یا با Scaffold-eth یا Hardhat استفاده کنید.",
"page-local-environment-waffle-logo-alt": "لوگوی Waffle"
}
diff --git a/src/intl/fa/page-layer-2.json b/src/intl/fa/page-layer-2.json
index 423c24bb42d..382675872c6 100644
--- a/src/intl/fa/page-layer-2.json
+++ b/src/intl/fa/page-layer-2.json
@@ -2,35 +2,37 @@
"layer-2-arbitrum-note": "اثبات تقلب فقط برای کاربران قرار گرفته در فهرست سفید است، فهرست سفید هنوز باز نشده است",
"layer-2-boba-note": "اعتبارسنجی حالت در حال توسعه است",
"layer-2-optimism-note": "اثبات تقلب در حال توسعه است",
+ "layer-2-base-note": "سیستم ضدتقلب در حال توسعه است",
+ "layer-2-metadata-description": "صفحه معرفی لایه 2",
"layer-2-hero-title": "لایه 2",
"layer-2-hero-header": "اتریوم برای همه",
"layer-2-hero-subtitle": "مقیاس پذیری اتریوم برای پدیرش همگانی.",
"layer-2-hero-alt-text": "تصویری از تراکنش هایی که بر روی لایه-2 انباشته میشوند و سپس به شبکه اصلی اتریوم ارسال میشوند",
"layer-2-hero-button-1": "لایه 2 چیست",
- "layer-2-hero-button-2": "استفاده کردن از لایه 2",
+ "layer-2-hero-button-2": "استفاده از لایه 2",
"layer-2-hero-button-3": "رفتن به لایه 2",
- "layer-2-statsbox-1": "TVL قفلشده در لایه 2 (USD)",
+ "layer-2-statsbox-1": "ارزش کل قفلشده در لایه 2 (USD)",
"layer-2-statsbox-2": "میانگین هزینه انتقال اتریوم لایه 2 (دلار آمریکا)",
"layer-2-statsbox-3": "تغییر لایه 2 TVL (30 روز)",
"layer-2-what-is-layer-2-title": "لایه 2 چیست؟",
- "layer-2-what-is-layer-2-1": "لایه 2 (L2) یک اصطلاح جمعی برای توصیف مجموعه خاصی از راه حل های مقیاس پذیری اتریوم است. لایه 2 یک بلاک چین جداگانه است که اتریوم را گسترش می دهد و تضمین های امنیتی اتریوم را به ارث می برد.",
+ "layer-2-what-is-layer-2-1": "لایه 2 یا L2 یک اصطلاح جمعی برای توصیف مجموعه خاصی از راهکارهای مقیاس پذیری اتریوم است.یک لایه 2 یعنی یک بلاکچین مجزا که اتریوم را گسترش میدهد و تضمینهای امنیتی اتریوم را به ارث میبرد.",
"layer-2-what-is-layer-2-2": "اکنون به بررسی بیشتر این موضوع بپردازیم. برای این امر ابتدا باید لایه-1 (L1) را شرح دهیم.",
"layer-2-what-is-layer-1-title": "لایه 1 چیست؟",
"layer-2-what-is-layer-1-1": "لایه 1 بلاکچین پایه می باشد. اتریوم و بیتکوین هر دو بلاکچینهای لایه 1 هستند چون آنها بنیان شبکه های مختلف لایه 2 می باشند که بر روی آنها ساخته می شوند. نمونه هایی از پروژه های لایه 2، شامل \"رول آپ ها\" بر روی بستر اتریوم و شبکه \"لایتنینگ\" یر روی بستر بینکوین می باشد. تمام تراکنش های کاربر بر روی پروژه های لایه 2 در نهایت می توانند به بلاکچین لایه 1 باز گردانده شود.",
- "layer-2-what-is-layer-1-2": "اتریوم همچنین بهعنوان یک لایه دسترسی به دادهها برای لایههای 2 عمل میکند. پروژههای لایه 2 دادههای تراکنش خود را بر روی اتریوم ارسال میکنند و برای در دسترس بودن دادهها به اتریوم متکی هستند. از این دادهها میتوان برای به دست آوردن حالت لایه 2 یا طرح اختلاف با تراکنشهای لایه 2 استفاده کرد.",
+ "layer-2-what-is-layer-1-2": "اتریوم همچنین بهعنوان یک لایه از دسترسیپذیری داده برای لایه 2 عمل میکند. پروژههای لایه 2 داده های تراکنش خود را بر روی اتریوم ارسال میکنند و برای دسترسیپذیری داده به اتریوم متکی هستند. از این داده میتوان برای اطلاع از وضعیت لایه 2 یا برای مخالفت با تراکنشهای لایه 2 استفاده کرد.",
"layer-2-what-is-layer-1-list-title": "اتریوم بهعنوان لایه 1 شامل این موارد است:",
- "layer-2-what-is-layer-1-list-1": "شبکهای از عملگرهای گره برای ایمنسازی و اعتبارسنجی شبکه",
+ "layer-2-what-is-layer-1-list-1": "شبکهای از اپراتورهای گره برای ایمنسازی و تأیید اعتبار شبکه",
"layer-2-what-is-layer-1-list-2": "شبکهای از تولیدکنندگان بلوک",
"layer-2-what-is-layer-1-list-3": "خود زنجیرهی بلوکی و تاریخچه دادههای تراکنش",
- "layer-2-what-is-layer-1-list-4": "مکانیزم اجماع برای شبکه",
+ "layer-2-what-is-layer-1-list-4": "مکانیسم اجماع برای شبکه",
"layer-2-what-is-layer-1-list-link-1": "هنوز در مورد اتریوم سردرگم هستید؟",
"layer-2-what-is-layer-1-list-link-2": "یاد بگیرید که اتریوم چیست.",
"layer-2-why-do-we-need-layer-2-title": "چرا به لایه 2 نیاز داریم؟",
"layer-2-why-do-we-need-layer-2-1": "سه ویژگی مطلوب یک زنجیرهی بلوکی این است که غیرمتمرکز، ایمن و مقیاسپذیر است. سهگانه زنجیرهی بلوکی بیان میکند که یک معماری ساده زنجیرهی بلوکی تنها میتواند به دو مورد از سه مورد دست یابد. زنجیرهی بلوکی امن و غیرمتمرکز میخواهید؟ باید مقیاسپذیری را قربانی کنید.",
- "layer-2-why-do-we-need-layer-2-2": "در حال حاضر اتریوم قادر به پردازشبیش از 1 میلیون تراکنش در روز می باشد. نیاز به استفاده از اتریوم می تواند منجر به افزایش قیمت کارمزد تراکنش شود. اینجاست که شبکه های لایه 2 وارد می شوند.",
+ "layer-2-why-do-we-need-layer-2-2": "در حال حاضر اتریوم قادر به پردازش بیش از 1 میلیون تراکنش در روز می باشد. نیاز به استفاده از اتریوم می تواند منجر به افزایش قیمت کارمزد تراکنش شود. اینجاست که شبکه های لایه 2 وارد می شوند.",
"layer-2-why-do-we-need-layer-2-scalability": "مقیاسپذیری",
"layer-2-why-do-we-need-layer-2-scalability-1": "هدف اصلی لایه 2 افزایش تعداد تراکنش ها (بیشترین تراکنش بر ثانیه) بدون قربانی کردن تمرکززدایی یا امنیت می باشد.",
- "layer-2-why-do-we-need-layer-2-scalability-2": "شبکه اصلی اتریوم (لایه 1) فقط می تواند نزدیک به 15 تراکنش بر ثانیه را پردازش کند. زمانی که تقاضا برای استفاده از اتریوم زیاد است، شبکه شلوغ می شود، که قیمت ها و کارمزد تراکنش ها را برای کاربرانی که توان پرداخت آن هزینه ها را ندارند افزایش می دهد. لایه های 2 راه حل هایی هستند که این هزینه ها را با پردازش تراکنش های خارج از لایه-1 بلاکچین کاهش می دهند.",
+ "layer-2-why-do-we-need-layer-2-scalability-2": "شبکه اصلی اتریوم (لایه 1) تنها قادر به پردازش 15 تراکنش در ثانیه است. زمانی که تقاضا برای استفاده از اتریوم زیاد باشد، شبکه شلوغ میشود، که کارمزد تراکنشها و قیمتها را برای کاربرانی که توانایی پرداخت آن هزینهها را ندارند، افزایش میدهد. لایه 2ها راهکارهایی هستند که این هزینه ها را با پردازش تراکنشها خارج از بلاکچین لایه 1 کم میکنند.",
"layer-2-why-do-we-need-layer-2-scalability-3": "اطلاعات بیشتر دربارهی چشمانداز اتریوم",
"layer-2-benefits-of-layer-2-title": "مزایای لایه 2",
"layer-2-lower-fees-title": "کازمزد کمتر",
@@ -44,7 +46,7 @@
"layer-2-how-does-layer-2-work-2": "چندین نوع متفاوت لایه 2 وجود دارند، هر کدام مبادلات و مدل های امنیتی خودشان را دارند. لایه های 2، بار معاملاتی را از لایه 1 می گیرند و به آن امکان می دهند که کمتر شلوغ شود، و همه چیز بیشتر مقیاس پذیر باشد.",
"layer-2-rollups-title": "رولآپها",
"layer-2-rollups-1": "رول آپ ها (یا \"رول آپ\")، صد ها تراکنش را در یک تراکنش مستقل روی لایه 1 دسته بندی می کند. این کار کارمزد تراکنش های لایه 1 را بین همه افراد در رولآپ توزیع می کند، و آن را برای هر کاربر ارزانتر می کند.",
- "layer-2-rollups-2": "تراکنش های رول آپ، بیرون از لایه 1 اجرا می شوند اما داده های مربوط به تراکنش ها در لایه 1 ثبت می شوند. با ثبت تراکنش داده بر روی لایه 1، رول آپ ها از امنیت اتریوم بهره مند می شوند. این به این خاطر است که زمانی که داده بر روی لایه 1 بارگذاری می شود، بازگشت یک تراکنش رول آپ نیازمند بازگشت اتریوم است. دو روش مختلف برای \"رول آپ ها\" وجود دارد: خوشبینانه و دانش صفر. تفاوت عملکرد آنها بر اساس نحوه ثبت داده تراکنش بر روی لایه 1 می باشد.",
+ "layer-2-rollups-2": "دادههای تراکنش در رولآپ به لایه 1 ارسال میشود، اما اجرا به طور جداگانه توسط رولآپ انجام می شود. با ارسال دادههای تراکنش در لایه 1، رولآپها امنیت اتریوم را به ارث می برند. این امر هم به این دلیل است که وقتی دادهها در لایه 1 آپلود میشوند، بازگرداندن یک تراکنش رولآپ نیاز به برگرداندن زنجیره اتریوم به عقب دارد. دو رویکرد متفاوت برای رولآپها وجود دارند: خوشبینانه و دانش صفر - که عمدتاً در نحوه ارسال این دادههای تراکنش به لایه 1 متفاوت هستند.",
"layer-2-optimistic-rollups-title": "رولآپهای خوشبینانه",
"layer-2-optimistic-rollups-description": "رولآپهای خوشبینانه از این دید «خوشبین» هستند که تراکنشها معتبر فرض میشوند، اما در صورت لزوم میتوانند به چالش کشیده شوند. اگر یک تراکنش نامعتبر درنظر گرفته شود، یک اثبات تقلب جهت بررسی صحت این اتقاق اجرا میشود.",
"layer-2-optimistic-rollups-childSentance": "کسب اطلاعات بیشتر در مورد رولآپهای خوشبینانه",
@@ -53,17 +55,17 @@
"layer-2-zk-rollups-childSentance": "کسب اطلاعات بیشتر در مورد رولآپهای دانش-صفر",
"layer-2-dyor-title": "تحقیق خود را انجام دهید: خطرات لایه 2",
"layer-2-dyor-1": "بسیاری از پروژههای لایه 2 نسبتا نوپا هستند و در حالی که در مسیر غیرمتمرکز شدن قدم برمیدارند کاربران هنوز باید به بعضی اپراتور ها اعتماد کنند که صادقانه رفتار کنند. همواره خودتان تحقیق کنید و سپس تصمیم بگیرید که آیا ریسک های مربوطه برای شما قابل قبول است یا خیر.",
- "layer-2-dyor-2": "برای اطلاعات بیشتر در مورد فناوری، ریسکها و مفروضات اعتماد لایه 2، توصیه میکنیم L2BEAT را بررسی کنید، که چارچوب ارزیابی ریسک جامع هر پروژه را ارائه میکند.",
+ "layer-2-dyor-2": "برای اطلاعات بیشتر در مورد تکنولوژی، ریسکها و فرضهای اعتماد لایه 2، توصیه میکنیم که پلتفرم تحلیل ریسک L2BEAT را بررسی کنید، که یک چارچوب جامع ارزیابی ریسک را برای هر پروژه ارائه میدهد.",
"layer-2-dyor-3": "رفتن به L2BEAT",
"layer-2-use-layer-2-title": "استفاده کردن از لایه 2",
"layer-2-use-layer-2-1": "اکنون که فهمیدید چرا لایه 2 وجود دارد و چگونه کار میکند، بیایید کار را شروع کنیم!",
- "layer-2-contract-accounts": "اگر از کیف پول های مبتنی بر قرارداد هوشمند مثل Safe یا Argent استفاده میکنید، به این آدرس روی لایه 2 دسترسی ندارید تا وقتی که دوباره حساب قرارداد را بر روی آن آدرس در لایه 2 پیادهسازی کنید. حساب های کلاسیک با عبارت بازیابی، به صورت خودکار حساب یکسانی روی تمام شبکههای لایه 2 خواهند داشت.",
+ "layer-2-contract-accounts": "اگر از کیف پول قرارداد هوشمند مانند Safe یا Argent استفاده میکنید، روی این آدرس در لایه 2 کنترلی نخواهید داشت مگر اینکه حساب قرارداد خود را به آن آدرس در لایه 2 منتقل کنید. حساب های کلاسیک همراه با عبارت بازیابی بهطور خودکار مالک همان حساب در همه شبکههای لایه 2 خواهند بود.",
"layer-2-use-layer-2-generalized-title": "لایه 2های تعمیم یافته",
- "layer-2-use-layer-2-generalized-1": "لایه 2های تعمیم یافته دقیقاً مانند اتریوم عمل میکنند - اما ارزانتر. هر کاری که میتوانید در لایه 1 اتریوم انجام دهید، میتوانید در لایه 2 نیز انجام دهید. بسیاری از dappها قبلاً شروع به مهاجرت به این شبکهها کرده اند یا بهطور کلی از شبکه اصلی صرفنظر کردهاند تا مستقیماً روی لایه 2 مستقر شوند.",
+ "layer-2-use-layer-2-generalized-1": "لایه2های تعمیم یافته دقیقاً مانند اتریوم عمل میکنند - اما ارزانتر. هر کاری که میتوانید در لایه 1 اتریوم انجام دهید، میتوانید در لایه 2 نیز انجام دهید. بسیاری از دپها قبلاً شروع به مهاجرت به این شبکهها کردهاند یا به طور کلی شبکه اصلی را نادیده گرفتهاند تا پروژهها را مستقیماً روی لایه 2 بسازند.",
"layer-2-use-layer-2-application-specific-title": "لایه 2های خاص برنامههای کاربردی",
"layer-2-use-layer-2-application-specific-1": "لایه 2های خاص برنامه پروژههایی هستند که در بهینهسازی برای یک فضای برنامه خاص تخصص دارند و عملکرد بهبودیافته را به ارمغان میآورند.",
"layer-2-sidechains-title": "یادداشتی در مورد زنجیرههای جانبی، Validiumها و زنجیرههای بلوکی جایگزین",
- "layer-2-sidechains-1": "زنجیرههای جانبی و Validiumها زنجیرههای بلوکی هستند که به داراییهای اتریوم اجازه میدهند تا روی زنجیرهی بلوکی پل بزنند و از آنها استفاده کنند. زنجیرههای جانبی و Validiumها به موازات اتریوم اجرا میشوند و از طریق پلها با اتریوم در تعامل هستند، اما امنیت یا در دسترس بودن دادههای خود را از اتریوم نمیگیرند.",
+ "layer-2-sidechains-1": "زنجیرههای جانبی و ولیدیومها بلاکچینهایی هستند که به داراییهای اتریوم اجازه میدهند بر روی یک بلاکچین پل زده و از آن استفاده کنند. زنجیرههای جانبی و ولیدیومها بهطور موازی با اتریوم اجرا میشوند و از طریق پلها با اتریوم تعامل دارند، اما امنیت یا دسترسیپذیری دیتای خود را از اتریوم نمیگیرند.",
"layer-2-sidechains-2": "هر دو به طور مشابه به لایه 2 مقیاسپذیری میشوند - آنها کارمزد تراکنش کمتر و توان عملیاتی تراکنش بالاتری را ارائه میدهند - اما مفروضات اعتماد متفاوتی دارند.",
"layer-2-more-on-sidechains": "اطلاعات بیشتر در مورد زنجیرههای جانبی",
"layer-2-more-on-validiums": "اطلاعات بیشتر در مورد Validiumها",
@@ -87,6 +89,8 @@
"layer-2-go-to": "برو به",
"layer-2-tools-title": "ابزارهایی مفید برای لایه 2",
"layer-2-tools-l2beat-description": "L2BEAT یک منبع عالی برای بررسی ارزیابی ریسک فنی پروژههای لایه 2 است. توصیه میکنیم هنگام تحقیق در مورد پروژههای لایه 2 خاص، منابع آنها را بررسی کنید.",
+ "layer-2-tools-growthepie-description": "تحلیلهای منتخب درباره لایه 2های اتریوم",
+ "layer-2-tools-ethereumecosystem-description": "صفحه غیررسمی اکوسیستم اتریوم و لایه2های آن از جمله Base و Optimism و Starknet حاوی صدها دپ و ابزار هستند.",
"layer-2-tools-l2fees-description": "L2 Fees به شما امکان میدهد هزینه جاری (به دلار آمریکا) را برای انجام تراکنش در لایههای مختلف 2 مشاهده کنید.",
"layer-2-tools-chainlist-description": "Chainlist یک منبع عالی برای وارد کردن RPCهای شبکه به کیف پولهای پشتیبانی است. شما RPCها را برای پروژههای لایه 2 در اینجا پیدا خواهید کرد که کمکتان میکنند متصل شوید.",
"layer-2-tools-zapper-description": "کل پورتفولیوی وب 3 خود را از دیفای گرفته تا NFT و هر آنچه که در آینده میآید مدیریت کنید. از یک محیط واحدِ آسان در تازهترین فرصتها سرمایهگذاری کنید.",
@@ -102,7 +106,7 @@
"layer-2-more-info-on-optimistic-rollups": "اطلاعات بیشتر در مورد رولآپ خوشبینانه",
"layer-2-more-info-on-zk-rollups": "کسب اطلاعات بیشتر در مورد رولآپهای دانش-صفر",
"layer-2-faq-question-4-title": "خطرات لایه 2 چیست؟",
- "layer-2-faq-question-4-description-1": "پروژههای لایه 2 در مقایسه با نگهداری وجوه و تراکنش مستقیم روی شبکه اصلی اتریوم دارای خطرات بیشتری هستند. بهعنوان مثال، ترتیبدهندهها ممکن است از کار بیفتند، که باعث میشود برای دسترسی به وجوه منتظر بمانید.",
+ "layer-2-faq-question-4-description-1": "پروژههای لایه2 در مقایسه با نگهداری وجوه و تراکنش مستقیم روی شبکه اصلی اتریوم دارای خطرات بیشتری هستند. برای مثال، مرتبکنندگان ممکن است از کار بیفتند، که باعث میشود برای دسترسی به وجوه منتظر بمانید.",
"layer-2-faq-question-4-description-2": "ما شما را تشویق میکنیم قبل از انتقال وجوه قابل توجه به لایه 2، تحقیق خود را انجام دهید. برای اطلاعات بیشتر در مورد فناوری، خطرات و مفروضات اعتماد لایه 2، توصیه می کنیم L2BEAT را، که یک چارچوب ارزیابی ریسک جامع از هر پروژه ارائه میکند، بررسی کنید.",
"layer-2-faq-question-4-description-3": "پلهای زنجیرهی بلوکی که انتقال داراییها به لایه 2 را تسهیل میکنند، در مراحل اولیه توسعه خود هستند و احتمالاً طراحی پل بهینه هنوز کشف نشده است. اخیراً هکهای پل مشاهده شده است.",
"layer-2-faq-question-5-title": "چرا برخی از پروژههای لایه 2 در اینجا فهرست نشدهاند؟",
@@ -119,13 +123,17 @@
"arbitrum-description": "Arbitrum One رولآپی خوشبینانه است که میخواهد حسی دقیقاً شبیه تعامل با اتریوم را تداعی کند، اما با تراکنشهایی که هزینهشان تنها کسری از هزینه آنها در لایه 1 است.",
"optimism-description": "Optimism یک رولآپ خوشبینانه سریع، ساده و ایمن معادل EVM است. این رولآپ فناوری اتریوم را مقیاسپذیر میکند و در عین حال ارزشهای آن را از طریق تأمین مالی ماسبق برای کالاهای عمومی افزایش میدهد.",
"boba-description": "Boba یک رولآپ خوشبینانه است که در اصل از Optimism جدا شده است و یک راهحل مقیاسپذیر است که هدف آن کاهش هزینههای گاز، بهبود توان عملیاتی تراکنشها و گسترش قابلیتهای قراردادهای هوشمند است.",
+ "base-description": "Base یک لایه 2 اتریوم ایمن، کمهزینه و مناسب برای توسعهدهندگان است که برای آوردن میلیاردها کاربر بعدی به وب3 ساخته شده است. بیس یک لایه 2 اتریوم است که توسط کوینبیس بال و پر گرفته و بر روی OP Stack منبع باز ساخته شده است.",
"loopring-description": "راهحل لایه 2 رولآپ دانش-صفر Loopring به دنبال ارائه کردن ضمانتهای امنیتی مشابه شبکه اصلی اتریوم به همراه بهبود خیرهکننده مقیاسپذیری است: توان عملیاتی 1000 برابر افزایش یافته و هزینه به تنها 0.1% از L1 کاهش مییابد.",
- "zksync-description": "ZKsync یک پلتفرم جمعبندی دانش-صفر کاربر محور ارائهشده توسط Matter Labs است. این پلتفرم، یک راهحل مقیاسپذیر برای اتریوم است که در حال حاضر در شبکه اصلی اتریوم وجود دارد. ZKsync از پرداخت، مبادله توکن و ضرب کردن NFT پشتیبانی میکند.",
+ "zksync-description": "پروژه ZKsync یک مجموعه دانش صفر است که هدف آن مقیاس دادن به اتریوم و ارزشهای آن برای پذیرش سراسری است، بدون تضعیف امنیت یا عدمتمرکز.",
"zkspace-description": "پلتفرم ZKSpace از سه بخش اصلی تشکیل شده است: یک صرافی غیر متمرکز و بازارساز خودکار(AMM DEX) لایه 2 که از فناوری ZK-Rollups به نام ZKSwap استفاده میکند، یک سرویس پرداخت به نام ZKSquare و یک بازار NFT به نام ZKSea.",
"aztec-description": "شبکه آزتک اولین رولآپ دانش-صفر خصوصی در اتریوم است که به برنامههای غیرمتمرکز امکان دسترسی به حریم خصوصی و مقیاسپذیری را میدهد.",
+ "starknet-description": "Starknet یک Validity Rollup Layer 2 است. توان عملیاتی بالا، هزینه گاز پایین را فراهم می کند و سطح امنیت لایه 1 اتریوم را حفظ می کند.",
"layer-2-note": "توجه:",
"layer-2-ecosystem-portal": "پورتال اکوسیستم",
"layer-2-token-lists": "فهرستهای توکن",
"layer-2-explore": "کاوش",
- "page-dapps-ready-button": "برو"
+ "page-dapps-ready-button": "برو",
+ "layer-2-information": "اطلاعات",
+ "layer-2-wallet-managers": "مدیران کیفپول"
}
diff --git a/src/intl/fa/page-learn.json b/src/intl/fa/page-learn.json
index 985df4f622d..42556eead4f 100644
--- a/src/intl/fa/page-learn.json
+++ b/src/intl/fa/page-learn.json
@@ -11,10 +11,10 @@
"hero-subtitle": "راهنمای آموزشی شما برای دنیای اتریوم. یادگیری نحوه کار با اتریوم و چگونگی اتصال به آن. این صفحه شامل مقالات، راهنماها و منابع فنی و غیر فنی است.",
"hero-button-lets-get-started": "بیایید شروع کنیم",
"what-is-crypto-1": "شما شاید درباره رمزارزها، بلاکچینها و بیتکوین شنیده باشید. لینک های زیر به شما کمک می کنند تا یاد بگیرید آنها چه هستند و چگونه به اتریوم مربوط می شوند.",
- "what-is-crypto-2": "رمزارزها، مانند بیکوین، هر کسی را قادر می سازند تا پول را در سطح جهانی انتقال دهند. اتریوم نیز اینکار را انجام می دهد، ولی همچنین می تواند با اجرای کدهایی به افراد امکان دهد تا اپلیکیشن ها و سازمان ها را ایجاد کنند. هم بهبود پذیر و هم انعطافپذیر است: هر برنامه رایانه می تواند روی اتریوم اجرا شود. بیشتر بدانید و نحوه شروع کار را بیاموزید:",
+ "what-is-crypto-2": "رمزارزها، مانند بیکوین، هر کس را قادر می سازند پول را در سطح جهانی انتقال دهند. اتریوم نیز اینکار را انجام می دهد، ولی همچنین می تواند با اجرای کدهایی به افراد امکان دهد تا اپلیکیشن ها و سازمان ها را ایجاد کنند. هم تغییرپذیر و هم انعطافپذیر است: هر برنامه رایانه می تواند روی اتریوم اجرا شود. بیشتر بدانید و نحوه شروع کار را بیاموزید:",
"what-is-ethereum-card-title": "اتریوم چیست؟",
"what-is-ethereum-card-description": "اگر مبتدی هستید، از اینجا شروع کنید تا بدانید چرا اتریوم اهمیت دارد.",
- "what-is-ethereum-card-image-alt": "تصویر فردی حین نظاره یک بازار، تداعی کننده اتریوم.",
+ "what-is-ethereum-card-image-alt": "تصویر فردی در حال نگاه کردن به یک بازار که تداعی کننده اتریوم است.",
"what-is-eth-card-title": "اتر (ETH) چیست؟",
"what-is-eth-description": "اتر (ETH) ارزی است که شبکه و اپلیکیشن های اتریوم را پشتیبانی می کند.",
"what-is-web3-card-title": "Web3 چیست؟",
@@ -26,7 +26,7 @@
"additional-reading-what-is-web3": "Web3 چیست؟",
"additional-reading-ethereum-in-thirty-minutes": "اتریوم در 30 دقیقه با ویتالیک بوترین",
"additional-reading-get-eth": "نحوه دریافت اتر را بیاموزید",
- "how-do-i-use-ethereum-1": "استفاده از اتریوم برای بسیاری از افراد ممکن است معانی متفاوتی داشته باشد. شاید بخواهید وارد یک اپلیکیشن شوید، هویت آنلاین خود را تایید کنید، و یا مقداری اتر انتقال دهید. اولین چیزی که احتیاج خواهید داشت یک حساب است. راحتترین راه برای ایجاد و دسترسی به یک حساب استفاده از نرمافزاری به اسم کیف پول است.",
+ "how-do-i-use-ethereum-1": "استفاده از اتریوم برای بسیاری از افراد ممکن است معانی متفاوت داشته باشد. شاید بخواهید وارد یک اپلیکیشن شوید، هویت آنلاین خود را تایید کنید، و یا مقداری ETH انتقال دهید. اولین چیزی که احتیاج خواهید داشت یک حساب است. راحتترین راه برای ایجاد و دسترسی به یک حساب استفاده از نرمافزاری به اسم کیف پول است.",
"what-is-a-wallet-card-title": "کیف پول چیست؟",
"what-is-a-wallet-card-description": "کیف پولهای دیجیتال همانند کیف پولهای واقعی هستند؛ آنها هر چیزی را که برای اثبات هویت خود نیاز دارید و برای ورود به مکان هایی که برای شما ارزشمند هستند، ذخیره می کنند.",
"what-is-a-wallet-card-alt": "تصویر یک ربات.",
@@ -37,42 +37,42 @@
"crypto-security-basics-card-description": "یادگیری در مورد نحوه شناسایی کلاه برداری ها و چگونه از رایج ترین ترفندها اجتناب کنیم.",
"crypto-security-basics-card-button": "ایمن بمانید",
"things-to-consider-banner-title": "مواردی که هنگام استفاده از اتریوم باید در نظر گرفت",
- "things-to-consider-banner-1": "هر تراکنش اتریوم نیازمند یک کارمزد در قالب اتر می باشد، حتی اگر بخواهید توکن های متفاوت ساخته شده روی اتریوم مانند رمزارزهای پایای USDC یا Dai را جا به جا کنید.",
- "things-to-consider-banner-2": "بسته به تعداد افرادی که سعی بر استفاده از اتریوم را دارند، کارمزدها می تواند بالا باشد، بابراین ما استفاده از",
- "things-to-consider-banner-layer-2": "لایه 2 را توصیه میکنیم",
+ "things-to-consider-banner-1": "هر تراکنش اتریوم نیازمند یک کارمزد در قالب ETH می باشد، حتی اگر بخواهید توکن های متفاوت ساخته شده روی اتریوم مانند رمزارزهای پایای USDC یا Dai را جا به جا کنید.",
+ "things-to-consider-banner-2": "بسته به تعداد افرادی که سعی بر استفاده از اتریوم دارند، کارمزدها می تواند بالا باشد، بنابراین ما استفاده از",
+ "things-to-consider-banner-layer-2": "لایه های 2 را توصیه میکنیم",
"additional-reading-more-on-using-ethereum": "اطلاعات بیشتر درباره استفاده از اتریوم",
"additional-reading-how-to-create-an-ethereum-account": "چگونگی «ساخت» یک حساب اتریوم",
"additional-reading-how-to-use-a-wallet": "چطور می توان از یک کیف پول استفاده کرد",
"additional-reading-layer-2": "لایه 2: کاهش کارمزدهای تراکنش",
- "what-is-ethereum-used-for-1": "اتریوم منجر به تولید محصولات و خدمات جدیدی شده است که می توانند بخش های متفاوتی از زندگی ما را ارتقا دهند. ما هنوز در مراحل ابتدایی هستیم ولی موارد بسیاری برای هیجان زده شدن وجود دارد.",
+ "what-is-ethereum-used-for-1": "اتریوم منجر به تولید محصولات و خدمات جدیدی شده است که می توانند بخش های متفاوتی از زندگی ما را ارتقا دهند. ما هنوز در مراحل ابتدایی هستیم ولی موارد هیجان انگیز بسیاری وجود دارد.",
"defi-card-title": "امور مالی غیرمتمرکز (DeFi)",
- "defi-card-description": "یک سیستم مالی جایگزین را که بدون بانک ها ساخته شده و برای عموم آزاد است، کشف کنید.",
+ "defi-card-description": "یک سیستم مالی جایگزین را کشف کنید که بدون بانک ها ساخته شده و برای عموم آزاد است.",
"defi-card-button": "DeFi چیست؟",
"stablecoins-card-title": "استیبل کوینها",
- "stablecoins-card-description": "رمزارزها، که به ارزش یک ارز، یک کالا یا با یک ابزار مالی دیگر ضرب شدهاند.",
+ "stablecoins-card-description": "رمزارزهایی که به ارزش یک ارز، یک کالا یا با یک ابزار مالی دیگر ضرب شدهاند.",
"stablecoins-card-button": "استیبل کوین ها (رمزارزهای پایا) چه هستند؟",
"nft-card-title": "توکنهای غیرمثلی (NFTها)",
"nft-card-description": "نشان دهنده مالکیت اقلام منحصر به فرد، از آثار هنری گرفته تا اسناد ملکی تا بلیتهای کنسرت.",
"nft-card-button": "NFTها چه هستند؟",
"dao-card-title": "سازمانهای خودمختار غیرمتمرکز (DAOها)",
- "dao-card-description": "فعال کردن راه های جدید برای هماهنگی کار بدون وجود رئیس.",
+ "dao-card-description": "فعال کردن راه های جدید برای هماهنگی کار بدون وجود یک رئیس.",
"dao-card-button": "DAO چیست؟",
- "dapp-card-title": "برنامههای کاربردی غیر متمرکز (dapps)",
+ "dapp-card-title": "برنامههای کاربردی غیر متمرکز (dappها)",
"dapp-card-description": "ایجاد اقتصاد دیجیتالی از سرویس های همتا به همتا.",
"dapp-card-button": "کاوش در صرافیهای غیرمتمرکز",
- "emerging-use-cases-title": "موارد کاربرد در حال ظهور",
- "emerging-use-cases-description": "همچنین صنایع برجسته دیگری نیز با استفاده از اتریوم در حال ساخته شدن یا بهبود هستند:",
- "play-to-earn": "بازی های بازی برای کسب درآمد (P2E)",
+ "emerging-use-cases-title": "کاربردهای در حال ظهور",
+ "emerging-use-cases-description": "همچنین صنایع برجسته دیگر با استفاده از اتریوم در حال ساخته شدن یا بهبود هستند:",
+ "play-to-earn": "بازی هایی برای کسب درآمد (P2E)",
"fundraising-through-quadratic-funding": "جذب سرمایه از طریق تامین سرمایه درجه دو",
"supply-chain-management": "مدیریت زنجیره تامین",
"more-on-ethereum-use-cases": "اطلاعات بیشتر درباره کاربردهای اتریوم",
"more-on-ethereum-use-cases-link": "بلاکچین در کشورهای در حال توسعه",
- "strengthening-the-ethereum-network-description": "شما میتوانید به امنیت اتریوم کمک کنید، و در عین حال با سهام گذاری اترهای خودتان پاداش دریافت کنید. روش های متفاوت برای سهام گذاری در اتریوم وجود دارد که به دانش فنی شما و اینکه چه مقدار اتر دارید بستگی دارد.",
+ "strengthening-the-ethereum-network-description": "شما میتوانید به امنیت اتریوم کمک کنید، و در عین حال با سهام گذاری اترهای خودتان پاداش دریافت کنید. روش های متفاوت برای سهام گذاری در اتریوم وجود دارد که به دانش فنی شما و اینکه چه مقدار اتر دارید بستگی دارد.",
"staking-ethereum-card-title": "سهام گذاری در اتریوم",
- "staking-ethereum-card-description": "یاد بگیرید که چگونه سهام گذاری اتر خود را شروع کنید.",
+ "staking-ethereum-card-description": "یاد بگیرید چگونه سهام گذاری اتر را شروع کنید.",
"staking-ethereum-card-button": "شروع سهامگذاری",
"run-a-node-card-title": "راهاندازی یک گره",
- "run-a-node-card-description": "با اجرا کردن یک کد یک نقش مهم را در شبکه اتریوم بازی کنید.",
+ "run-a-node-card-description": "با اجرا کردن یک کد، نقشی مهم در شبکه اتریوم بازی کنید.",
"learn-about-ethereum-protocol-description": "برای کاربرانی که بیشتر به بخش فنی شبکه اتریوم علاقه دارند.",
"energy-consumption-card-title": "مصرف انرژی",
"energy-consumption-card-description": "اتریوم چه مقدار انرژی استفاده می کند؟",
@@ -81,7 +81,7 @@
"ethereum-upgrades-card-description": "نقشه راه اتریوم آن را مقیاس پذیرتر، ایمن تر و پایدار تر می کند.",
"ethereum-upgrades-card-button": "نقشه راه را کاوش کنید",
"ethereum-whitepaper-card-title": "وایتپیپر اتریوم",
- "ethereum-whitepaper-card-description": "طرح اصلی اتریوم در سال 2014 توسط ویتالیک بوترین نوشته شده است.",
+ "ethereum-whitepaper-card-description": "طرح اصلی اتریوم که در سال 2014 توسط ویتالیک بوترین نوشته شده است.",
"ethereum-whitepaper-card-button": "وایت پیپر را بخوانید",
"more-on-ethereum-protocol-title": "اطلاعات بیشتر در مورد پروتکل اتریوم",
"more-on-ethereum-protocol-ethereum-for-developers": "اتریوم برای توسعه دهندگان",
@@ -90,11 +90,11 @@
"more-on-ethereum-protocol-nodes-and-clients": "گره ها و کاربران اتریوم",
"ethereum-community-description": "موفقیت اتریوم به لطف جامعه فوقالعاده متعهد آن است. هزاران نفر از افراد الهام بخش و کوشا به پیشبرد چشم انداز اتریوم کمک می کنند و در عین حال امنیت شبکه را از طریق سهام گذاری و حاکمیت فراهم می کنند. به ما بپیوندید!",
"community-hub-card-title": "مرکز اجتماع",
- "community-hub-card-description": "جامعه ما متشکل از افرادی با همه پیشینه ها می باشد.",
- "community-hub-card-alt": "تصویر گروهی در حال ساخت و ساز به کمک هم.",
+ "community-hub-card-description": "جامعه ما متشکل از افرادی با همه پیشینه ها است.",
+ "community-hub-card-alt": "تصویر گروهی از سازندهها در حال کار باهم.",
"community-hub-card-button": "بیشتر کشف کنید",
"get-involved-card-title": "چطور میتوانم مشارکت کنم؟",
- "get-involved-card-description": "شما (بله، خود شما!) به مشارکت در جامعه اتریوم خوش آمدید.",
+ "get-involved-card-description": "شما (بله شما!) به مشارکت در جامعه اتریوم خوش آمدید.",
"online-communities-card-title": "جوامع آنلاین",
"online-communities-card-description": "جوامع آنلاین یک فرصت بسیار عالی برای پرسیدن سوالات تخصصی، یا مشارکت را فراهم میکنند.",
"online-communities-card-button": "جوامع را کشف کنید",
@@ -102,9 +102,9 @@
"proof-of-stake-title": "اثبات سهام",
"proof-of-stake-description": "13 سپتامبر 2022- ویتالیک بوترین، ناتان اشنایدر",
"cryptopians-title": "کریپتوپیان ها",
- "cryptopians-description": "22 فوریه، 2022 -لاورا شین",
+ "cryptopians-description": "22 فوریه 2022 -لاورا شین",
"out-of-the-ether-title": "خارج از اتر",
- "out-of-the-ether-description": "29 سپتامبر، 2020 - متیو لیزینگ",
+ "out-of-the-ether-description": "29 سپتامبر 2020 - متیو لیزینگ",
"the-infinite-machine-title": "ماشین بینهایت",
"the-infinite-machine-description": "14 ژوئیه 2020 - کامیلا روسو",
"mastering-ethereum-title": "تسلط بر اتریوم",
@@ -115,9 +115,9 @@
"zeroknowledge-title": "دانش صفر",
"zeroknowledge-description": "مملو از فناوری که وب غیرمتمرکز نوظهور و جامعه سازنده آن را پشتیبانی خواهد کرد",
"green-pill-title": "Green Pill",
- "green-pill-description": "سیستمهای اقتصادی کریپتو محور و تاثیر جانبی مثبت آن بر دنیا را بررسی میکند",
+ "green-pill-description": "سیستمهای اقتصادی رمزارز را که تاثیر جانبی مثبت بر دنیا می گذارند بررسی می کند",
"unchained-title": "بیزنجیر",
- "unchained-description": "کسانی را که در حال ساخت اینترنت غیرمتمرکز هستند، جزئیات فناوری که پایه آینده ما را میسازد، و بعضی از مشکل زا ترین موضوعات کریپتو، مثل قانون گذاری، امنیت و حریم خصوصی را توضیح میدهد",
+ "unchained-description": "کسانی را که در حال ساخت اینترنت غیرمتمرکز هستند، جزئیات این فناوری که می تواند پایه آینده ما را بسازد، و بعضی از مشکل زا ترین موضوعات کریپتو، مثل قانون گذاری، امنیت و حریم خصوصی را به تفصیل توضیح میدهد",
"the-daily-gwei-title": "Gwei روزانه",
- "the-daily-gwei-description": "خلاصه ها، به روزرسانی ها و تجزیه و تحلیل اخبار اتریوم"
+ "the-daily-gwei-description": "خلاصه ها، به روزرسانی ها و تحلیل اخبار اتریوم"
}
diff --git a/src/intl/fa/page-run-a-node.json b/src/intl/fa/page-run-a-node.json
index 5376948d245..3080861e5f7 100644
--- a/src/intl/fa/page-run-a-node.json
+++ b/src/intl/fa/page-run-a-node.json
@@ -60,7 +60,7 @@
"page-run-a-node-getting-started-software-section-1-link": "چرخاندن یک گره اتریوم",
"page-run-a-node-getting-started-software-section-2": "حالا ما DAppNode را داریم که یک نرمافزار متنباز و آزاد است که برای کاربران تجربهای همانند یک برنامهی کاربردی را حین مدیریت گرههای آنها فراهم میکند.",
"page-run-a-node-getting-started-software-section-3a": "فقط با چند کلیک شما میتوانید گره خود را اجرا کنید.",
- "page-run-a-node-getting-started-software-section-3b": "DAppNode کار اجرای یک گره کامل، برنامههای غیررسمی و سایر شبکههای همتا به همتا را بدون نیاز به استفاده از خط فرمان برای کاربران آسان میکند. این کار، مشارکت و ساخت یک شبکهی غیر متمرکز را برای همه سادهتر میکند.",
+ "page-run-a-node-getting-started-software-section-3b": "DAppNode اجرای کامل گرهها، و نیز دپها و سایر شبکههای همتا به همتابدون نیاز به هرگونه دستورنویسی را برای کاربران راحت میکند. این امر، مشارکت و ایجاد یک شبکه غیرمتمرکزتر را برای همه آسانتر میکند.",
"page-run-a-node-getting-started-software-title": "بخش 2: نرمافزار",
"page-run-a-node-glyph-alt-terminal": "عکس ترمینال",
"page-run-a-node-glyph-alt-phone": "عکس لمس کردن گوشی",
@@ -78,7 +78,6 @@
"page-run-a-node-hero-header": "کنترل کامل را به دست آورید.
گره خود را اجرا کنید.",
"page-run-a-node-hero-subtitle": "در عین حال که به امنیت شبکه کمک میکنید، حاکمیت کامل را به دست آورید. اتریوم شوید.",
"page-run-a-node-hero-cta-1": "بیشتر بدانید",
- "page-run-a-node-hero-cta-2": "بیایید شروع کنیم!",
"page-run-a-node-install-manually-title": "بهصورت دستی نصب کنید",
"page-run-a-node-install-manually-1": "اگر شما کاربر فنیتری هستید و به این نتیجه رسیدید که میخواهید دستگاه خودتان را بسازید، DAppNode میتواند بر روی هر کامپیوتری دانلود شود و بر روی درایو حالت جامد (SSD) یا فلش USB نصب شود.",
"page-run-a-node-meta-description": "درآمدی بر اینکه چه چیز را روی یک گره اتریوم اجرا کنیم، چرا اجرا کنیم و چگونه اجرا کنیم.",
@@ -93,8 +92,6 @@
"page-run-a-node-privacy-3": "اگر هم یک گره خرابکار تراکنشی نامعتبر را توزیع کند، گره شما میتواند به راحتی به آن بیتوجهی کند. هر تراکنشی بر روی ماشین شما به صورت محلی تایید میشود، پس نیازی نیست شما به دیگران اعتماد کنید.",
"page-run-a-node-rasp-pi-title": "یادداشتی دربارهی رزبری پای (پردازندهی ARM)",
"page-run-a-node-rasp-pi-description": "رزبری پایها رایانههای سبک و مقرونبهصرفه هستند، اما محدودیتهایی دارند که میتواند بر روی کارایی گره شما تاثیر بگذارد. گرچه در حال حاضر برای سهامگذاری پیشنهاد نمیشوند، اما میتوانند گزینهای عالی و ارزان برای اجرای یک گره برای استفادهی شخصی با ۴ تا ۸ گیگابایت رم باشند.",
- "page-run-a-node-rasp-pi-note-1-link": "DAppNode بر روی ARM",
- "page-run-a-node-rasp-pi-note-1-description": "این ساختارها را مشاهده کنید اگر میخواهید که DAppNode را روی رزبری پای اجرا کنید",
"page-run-a-node-rasp-pi-note-2-link": "اسناد اتریوم بر روی ARM",
"page-run-a-node-rasp-pi-note-2-description": "یاد بگیرید که چگونه یک گره را با خط فرمان بر روی رزبری پای نصب کنید",
"page-run-a-node-rasp-pi-note-3-link": "یک گره با رزبری پای اجرا کنید",
@@ -126,8 +123,8 @@
"page-run-a-node-what-3-subtitle": "زمان آنلاین بودن.",
"page-run-a-node-what-3-text": "اجرای یک گره اتریوم ممکن است در ابتدا پیچیده به نظر برسد، اما در واقع اجرای مداوم نرمافزار کلاینت بر روی یک رایانه در حین اتصال به اینترنت است. در حالت آفلاین، گره شما به سادگی غیرفعال خواهد بود تا زمانی که دوباره آنلاین شود و آخرین تغییرات را دریافت کند.",
"page-run-a-node-who-title": "چه کسی باید یک گره اجرا کند؟",
- "page-run-a-node-who-preview": "هر کس! گره ها فقط برای تایید کننده های اثبات سهام نیستند. هر کسی می تواند یک گره را اجرا کند—شما حتی به ETH نیاز ندارید.",
- "page-run-a-node-who-copy-1": "برای اجرای یک گره نیازی به شرط بندی ETH ندارید. در واقع، این هر گره دیگری در اتریوم است که اعتبار سنجی ها را مسئول میداند.",
+ "page-run-a-node-who-preview": "توجه! گرهها فقط برای اعتبارسنجهای اثبات سهام نیستند. هر کس میتواند یک گره را اجرا کند— حتی بدون نیاز به پرداخت اتر.",
+ "page-run-a-node-who-copy-1": "برای اجرای یک گره نیازی به سهامگذاری اتر ندارید. در واقع، این فقط یک گره دیگر در اتریوم است که اعتبارسنجها را مسئول کار میداند.",
"page-run-a-node-who-copy-2": "ممکن است پاداشهای مالی را که اعتبارسنجیها به دست میآورند، دریافت نکنید، اما بسیاری از مزایای دیگر اجرای یک گره برای هر کاربر اتریوم وجود دارد، از جمله حفظ حریم خصوصی، امنیت، کاهش اتکا به سرورهای شخص ثالث، مقاومت در برابر سانسور و بهبود سلامت و عدم تمرکز شبکه.",
"page-run-a-node-who-copy-3": "داشتن گره اختصاصی به این معنی است که نیازی به اعتماد به اطلاعات مربوط به وضعیت شبکه ارائه شده توسط شخص ثالث ندارید.",
"page-run-a-node-who-copy-bold": "اعتماد نکنید. اعتبارسنجی کنید.",
diff --git a/src/intl/fa/page-stablecoins.json b/src/intl/fa/page-stablecoins.json
index 8d9586c248a..1b53b094f18 100644
--- a/src/intl/fa/page-stablecoins.json
+++ b/src/intl/fa/page-stablecoins.json
@@ -163,5 +163,6 @@
"makerdao-logo": "لوگوی MakerDao",
"matcha-logo": "لوگوی Matcha",
"summerfi-logo": "لوگوی Summer.fi",
- "uniswap-logo": "لوگوی Uniswap"
+ "uniswap-logo": "لوگوی Uniswap",
+ "page-stablecoins-go-to": "برو به"
}
diff --git a/src/intl/fa/page-staking.json b/src/intl/fa/page-staking.json
index f02a3cc2ae1..e2a2b9eec47 100644
--- a/src/intl/fa/page-staking.json
+++ b/src/intl/fa/page-staking.json
@@ -1,52 +1,52 @@
{
"comp-withdrawal-comparison-current-title": "سهامگذاران فعلی",
- "comp-withdrawal-comparison-current-li-1": "ممکن است برخی از کاربران در ابتدای راهاندازی واریز سهامگذاری خود، آدرس برداشت را ارائه کرده باشند - این کاربران، دیگر لازم نیست کاری انجام دهند",
- "comp-withdrawal-comparison-current-li-2": "اکثر سهامگذاران در واریز اولیه، آدرس برداشت ارائه نکردهاند و باید اعتبارنامه برداشت خود را به روز کنند. Staking Launchpad دستورالعملهایی درباره نحوه انجام این کار دارد",
+ "comp-withdrawal-comparison-current-li-1": "برخی از کاربران ممکن است در ابتدای ایجاد سپرده سهامگذاری خود، آدرس برداشت را ارائه کرده باشند - این کاربران، دیگر لازم نیست کاری انجام دهند",
+ "comp-withdrawal-comparison-current-li-2": "اکثر سهامگذاران در سپردهگذاری اولیه، آدرس برداشت ارائه نکردهاند و باید اعتبارنامه برداشت خود را به روز کنند. سکوی پرتاب سهامگذاری دستورالعملهایی درباره نحوه انجام این کار دارد",
"comp-withdrawal-comparison-current-p": "میتوانید شماره شاخص اعتبارسنج خود را در اینجا وارد کنید تا ببینید آیا همچنان نیاز به بهروزرسانی اعتبارنامهتان دارید یا نه (آن را میتوانید در گزارشهای کاربری خود پیدا کنید): ",
- "comp-withdrawal-comparison-new-title": "سهامگذاران جدید (هنوز واریز نشدهاند)",
- "comp-withdrawal-comparison-new-li-1": "بهطور پیشفرض، سهامگذاران جدیدی که بهدنبال فعال کردن خودکار پرداختهای پاداش و عملکرد برداشت هستند، باید یک آدرس برداشت اتریوم را که هنگام تولید کلیدهای اعتبارسنج خود با استفاده از ابزار Staking Deposit CLI کنترل میکنند ارائه کنند",
- "comp-withdrawal-comparison-new-li-2": "این کار در زمان واریز الزامی نیست، اما از نیاز به بروز رسانی این کلیدها در تاریخ بعدی برای آزاد کردن وجوه شما جلوگیری می کند",
- "comp-withdrawal-comparison-new-p": "سکوی پرتاب سهامگذاری، در فرایند همسوسازی سهامگذاری شما را راهنمایی خواهد کرد.",
+ "comp-withdrawal-comparison-new-title": "سهامگذاران جدید (هنوز واریز نکرده اند)",
+ "comp-withdrawal-comparison-new-li-1": "بهطور پیشفرض، سهامگذاران جدیدی که بهدنبال فعال کردن خودکار پرداختهای پاداش و عملکرد برداشت هستند، باید یک آدرس برداشت اتریوم را که هنگام تولید کلیدهای اعتبارسنج خود با استفاده از «ابزار CLI برای سهامگذاری سپرده» کنترل میکنند ارائه کنند",
+ "comp-withdrawal-comparison-new-li-2": "این کار در زمان سپردهگذاری الزامی نیست، اما از نیاز به بروز رسانی این کلیدها در تاریخ بعدی برای آزاد کردن وجوه شما جلوگیری می کند",
+ "comp-withdrawal-comparison-new-p": "سکوی پرتاب سهامگذاری، در فرایند همسوسازی سهامگذاری شما را هدایت خواهد کرد.",
"comp-withdrawal-comparison-new-link": "سکوی پرتاب سهامگذاری را مشاهده کنید",
"comp-withdrawal-credentials-placeholder": "شاخص اعتبارسنج",
"comp-withdrawal-credentials-error": "اوه! شماره شاخص اعتبارسنج را دوباره بررسی و امتحان کنید.",
"comp-withdrawal-credentials-upgraded-1": "شاخص اعتبارسنج {{validatorIndex}} برای شروع دریافت جوایز آماده است!",
- "comp-withdrawal-credentials-upgraded-2": "اعتبارنامه برداشت مرتبط با آدرس اجرا:",
+ "comp-withdrawal-credentials-upgraded-2": "اعتبارنامه های برداشت مرتبط با آدرس اجرا:",
"comp-withdrawal-credentials-not-upgraded-1": "این اعتبار سنج باید ارتقا یابد.",
- "comp-withdrawal-credentials-not-upgraded-1-testnet": "این اعتبارسنج شبکه آزمایشی Holesky باید ارتقا یابد.",
- "comp-withdrawal-credentials-not-upgraded-2": "دستورالعملهای نحوه ارتقا را میتوانید در Staking Launchpad پیدا کنید",
+ "comp-withdrawal-credentials-not-upgraded-1-testnet": "این اعتبار سنج شبکه تست Holesky باید ارتقا یابد.",
+ "comp-withdrawal-credentials-not-upgraded-2": "دستورالعملهای نحوه ارتقا را میتوانید در سکوی پرتاب سهامگذاری پیدا کنید",
"comp-withdrawal-credentials-verify-mainnet": "در شبکه اصلی تأیید کنید",
- "comp-withdrawal-credentials-verify-holesky": "در شبکه Holesky تایید کنید",
+ "comp-withdrawal-credentials-verify-holesky": "در Holesky تایید کنید",
"page-staking-withdrawals-when": "اجرا شد!",
"page-staking-image-alt": "تصویری از نشان کرگدن برای سکوی پرتاب سهامگذاری.",
"page-staking-benefits-1-title": "کسب پاداش",
- "page-staking-benefits-1-description": "برای اقداماتی که به کسب وفاق توسط شبکه کمک میکنند، پاداش داده میشود. شما بابت اجرای نرم افزاری که معاملات در یک بلوک جدید را دستهبندی یا کار سایر اعتبارسنجها زا بررسی \n میکند، پاداش خواهید گرفت زیرا همین امر باعث میٰشود که زنجیره بهطور ایمن کار کند.",
+ "page-staking-benefits-1-description": "برای اقداماتی که به حصول وفاق توسط شبکه کمک میکنند، پاداش داده میشود. شما بابت اجرای نرم افزاری که معاملات در یک بلوک جدید را دستهبندی یا کار سایر اعتبارسنجها را بررسی میکند، پاداش خواهید گرفت زیرا همین امر باعث میٰشود زنجیره بهطور ایمن کار کند.",
"page-staking-benefits-2-title": "امنیت بهتر",
- "page-staking-benefits-2-description": "هر چه اتر بیشتری سهامگذاری شود شبکه در برابر حملات قویتر میشود، زیرا در آن صورت برای کنترل اکثریت شبکه به اتر بیشتری نیاز است. برای تبدیل شدن به یک تهدید، باید اکثر اعتبارسنجها را در اختیار داشته باشید، به این معنی که باید اکثریت اتر را در سیستم کنترل کنید – خیلی زیاد است!",
+ "page-staking-benefits-2-description": "هر چه ETH بیشتری سهامگذاری شود شبکه در برابر حملات قویتر میشود، زیرا در آن صورت برای کنترل اکثریت شبکه به ETH بیشتری نیاز است. برای تبدیل شدن به یک تهدید، باید اکثر اعتبارسنجها را در اختیار داشته باشید، به این معنی که باید اکثریت ETH را در سیستم کنترل کنید – مزیت بالایی است!",
"page-staking-benefits-3-title": "پایدارتر",
"page-staking-benefits-3-description": "سهامگذاران برای مشارکت در ایمن سازی شبکه نیازی به محاسبات اثبات کار با انرژی زیاد ندارند، به این معنی که گره های سهامگذاری می توانند با استفاده از انرژی بسیار کم روی سخت افزار نسبتاً متوسط اجرا شوند.",
"page-staking-benefits-3-link": "اطلاعات بیشتر در مورد مصرف انرژی اتریوم",
- "page-staking-description": "«سهامگذاری» عمل واریز 32 اتر برای فعال کردن نرمافزار اعتبارسنج است. شما بهعنوان یک اعتبارسنج، مسئول ذخیره دادهها، پردازش تراکنشها و افزودن بلوکهای جدید به بلاک چین خواهید بود. با این کار اتریوم برای همه امن خواهد بود و اتر جدیدی را در این کار کسب خواهید کرد.",
- "page-staking-hero-title": "چگونه اتر خود را سهام گذاری کنیم",
+ "page-staking-description": "سهامگذاری عمل واریز 32 اتر (ETH) برای فعال کردن نرمافزار اعتبارسنج است. شما بهعنوان یک اعتبارسنج، مسئول ذخیره کردن دادهها، پردازش تراکنشها و افزودن بلوکهای جدید به بلاک چین خواهید بود. با این کار اتریوم برای همه امن خواهد بود و ETH جدیدی در این کار کسب خواهید کرد.",
+ "page-staking-hero-title": "چگونه ETHتان را سهام گذاری کنید",
"page-staking-hero-header": "ضمن ایمنسازی اتریوم پاداش کسب کنید",
- "page-staking-hero-subtitle": "هر کاربر با هر مقدار اتر می تواند به امنیت شبکه کمک کند و در این فرآیند پاداش کسب کند.",
+ "page-staking-hero-subtitle": "هر کاربر با هر مقدار ETH می تواند به امنیت شبکه کمک کند و در این فرآیند پاداش کسب کند.",
"page-staking-dropdown-home": "صفحه اصلی سهامگذاری",
"page-staking-dropdown-solo": "سهامگذاری انفرادی",
- "page-staking-more-on-solo": "اطلاعات بیشتر درباره سهامگذاری",
+ "page-staking-more-on-solo": "اطلاعات بیشتر درباره سهامگذاری انفرادی",
"page-staking-learn-more-solo": "درباره سهامگذاری انفرادی بیشتر بدانید",
"page-staking-dropdown-saas": "سهامگذاری بهعنوان یک خدمت",
"page-staking-saas-with-abbrev": "سهامگذاری به عنوان یک سرویس (SaaS)",
"page-staking-more-on-saas": "اطلاعات بیشتر در مورد سهامگذاری بهعنوان سرویس",
- "page-staking-learn-more-saas": "بیشتر در مورد سهامگذاری به عنوان سرویس",
+ "page-staking-learn-more-saas": "در مورد سهامگذاری به عنوان سرویس بیشتر بدانید",
"page-staking-dropdown-pools": "سهامگذاری گروهی",
"page-staking-dropdown-withdrawals": "در مورد برداشت ها",
"page-staking-dropdown-dvt": "فناوری اعتبارسنج توزیع شده",
- "page-staking-more-on-pools": "اطلاعات بیشتر درباره سهامگذاری ادغامشده",
+ "page-staking-more-on-pools": "اطلاعات بیشتر درباره سهامگذاری مشترک",
"page-staking-learn-more-pools": "درباره سهامگذاری مشترک بیشتر بدانید",
"page-staking-section-what-title": "سهامگذاری چیست؟",
- "page-staking-section-why-title": "چرا بهتر است اتر خود را سهامگذاری کنید؟",
- "page-staking-section-why-p1": "همهچیز به این بستگی دارد که شما چقدر مایل به سهامگذاری هستید. برای فعال کردن اعتبارسنج خودتان به 32 اتر نیاز دارید، اما امکان سهامگذاری مقدار کمتر هم وجود دارد.",
- "page-staking-section-why-p2": "گزینههای زیر را بررسی کنید و به سراغ گزینهای بروید که برای شما و شبکه بهترین است.",
+ "page-staking-section-why-title": "چرا بهتر است ETH خود را سهامگذاری کنید؟",
+ "page-staking-section-why-p1": "همهچیز به این بستگی دارد که شما چقدر مایل به سهامگذاری هستید. برای فعال کردن اعتبارسنج خودتان به 32 ETH نیاز دارید، اما امکان سهامگذاری مقدار کمتر هم وجود دارد.",
+ "page-staking-section-why-p2": "گزینههای زیر را بررسی کنید و گزینهای را انتخاب کنید که برای شما و شبکه بهترین است.",
"page-staking-guide-title-coincashew-ethereum": "راهنمای اتریوم 2.0 از CoinCashew",
"page-staking-guide-title-somer-esat": "Somer Esat",
"page-staking-guide-title-rocket-pool": "اپراتورهای گره استخر راکت",
@@ -56,105 +56,105 @@
"page-staking-hierarchy-solo-pill-1": "تأثیرگذارترین",
"page-staking-hierarchy-solo-pill-2": "تسلط کامل",
"page-staking-hierarchy-solo-pill-3": "پاداشهای کامل",
- "page-staking-hierarchy-solo-pill-4": "بدون نیاز به اعتماد به شخص ثالث",
- "page-staking-hierarchy-solo-p1": "سهامگذاری انفرادی در اتریوم استاندارد طلایی برای سهامگذاری است. این کار پاداش مشارکت کامل را فراهم میکند، تمرکززدایی شبکه را بهبود میبخشد، و هرگز نیازی به اعتماد به دیگران برای نگه داشتن وجوهتان ندارد.",
- "page-staking-hierarchy-solo-p2": "کسانی که در نظر دارند سهامگذاری انفرادی داشته باشند باید حداقل 32 اتر و یک رایانهی اختصاصی داشته باشند که بهصورت شبانهروزی در تمام ایام هفته به اینترنت متصل باشد. داشتن کمی دانش فنی مفید است، اما در حال حاضر ابزارهایی برای سادهسازی این فرایند وجود دارند که استفاده از آنها آسان است.",
- "page-staking-hierarchy-saas-pill-1": "32 اتر شما",
- "page-staking-hierarchy-saas-pill-2": "کلیدهای اعتبارسنجی شما",
- "page-staking-hierarchy-saas-pill-3": "عملیات گرهی مورد اعتماد",
- "page-staking-hierarchy-saas-p1": "اگر نمیخواهید با سختافزار سروکله بزنید یا این کار برایتان راحت نیست اما در عین حال میخواهید 32 اتر خود را سهامگذاری کنید، گزینههای سهامگذاری بهعنوان سرویس به شما این امکان را میدهند که بخش سخت را در حالی که پاداشهای بلوک بومی دریافت میکنید، به دیگران واگذار کنید.",
- "page-staking-hierarchy-saas-p2": "این گزینهها معمولاً شما را برای ایجاد مجموعهای از اعتبارنامههای اعتبارسنج، بارگذاری کلیدهای امضای خود در آنها و واریز 32 اتر راهنمایی میکنند. این کار به سرویس امکان میدهد تا از طرف شما اعتبارسنجی کند.",
- "page-staking-hierarchy-saas-p3": "این روش سهامگذاری نیاز به سطح معینی از اعتماد به ارائهدهنده دارد. برای محدود کردن ریسک طرف مقابل، کلیدهای برداشت اتر معمولاً در اختیار شما هستند.",
+ "page-staking-hierarchy-solo-pill-4": "بینیاز به اعتماد شخص ثالث",
+ "page-staking-hierarchy-solo-p1": "سهامگذاری انفرادی در اتریوم، استاندارد طلایی برای سهامگذاری است. این کار پاداش مشارکت کامل را ارائه میکند، تمرکززدایی شبکه را بهبود میبخشد، و هرگز نیازی به اعتماد به دیگران برای نگه داشتن وجوهتان ندارد.",
+ "page-staking-hierarchy-solo-p2": "کسانی که در نظر دارند سهامگذاری انفرادی داشته باشند باید حداقل 32 اتر (ETH) و یک کامپیوتر اختصاصی داشته باشند که بهصورت شبانهروزی در تمام ایام هفته به اینترنت متصل باشد. داشتن کمی دانش فنی مفید است، اما در حال حاضر ابزارهایی برای سادهسازی این فرایند وجود دارند که استفاده از آنها آسان است.",
+ "page-staking-hierarchy-saas-pill-1": "32 اتر (ETH) شما",
+ "page-staking-hierarchy-saas-pill-2": "کلیدهای اعتبارسنج شما",
+ "page-staking-hierarchy-saas-pill-3": "عملیات گره واگذار شده",
+ "page-staking-hierarchy-saas-p1": "اگر نمیخواهید با سختافزار سروکله بزنید یا این کار برایتان راحت نیست اما در عین حال میخواهید 32 اتر (ETH) خود را سهامگذاری کنید، گزینههای سهامگذاری بهعنوان سرویس به شما این امکان را میدهند که بخش سخت را در حالی که پاداشهای بلوک بومی دریافت میکنید، به دیگران واگذار کنید.",
+ "page-staking-hierarchy-saas-p2": "این گزینهها معمولاً در ایجاد مجموعهای از اعتبارنامههای اعتبارسنج، بارگذاری کلیدهای امضای خود در آنها و واریز 32 اتر (ETH) شما را راهنمایی میکنند. این کار به سرویس امکان میدهد تا از طرف شما اعتبارسنجی کند.",
+ "page-staking-hierarchy-saas-p3": "این روش سهامگذاری نیاز به سطح معینی از اعتماد به ارائهدهنده دارد. برای محدود کردن ریسک طرف مقابل، کلیدهای برداشت ETH معمولاً در اختیار شما هستند.",
"page-staking-hierarchy-pools-pill-1": "سهامگذاری به هر مقدار",
"page-staking-hierarchy-pools-pill-2": "کسب پاداش",
"page-staking-hierarchy-pools-pill-3": "حفظ سادگی",
"page-staking-hierarchy-pools-pill-4": "محبوب",
- "page-staking-hierarchy-pools-p1": "اکنون چندین راهحل ادغام برای کمک به کاربرانی وجود دارد که 32 اتر ندارند یا با سهامگذاری آن راحت نیستند.",
- "page-staking-hierarchy-pools-p2": "بسیاری از این گزینهها شامل چیزی است که به عنوان «نقدینگی سهامگذاری» شناخته میشود که شامل یک رمز نقدینگی ERC-20 است که اتر سهامگذاریشدهی شما را نشان میدهد.",
- "page-staking-hierarchy-pools-p3": "«لیکوئید استیکینگ»، خروج آسان و در هر زمان را امکانپذیر میسازد و سهامگذاری را بهسادگی تعویض توکن میکند. این گزینه همچنین به کاربران امکان میدهد تا داراییهای خود را در کیف پول اتریوم خود نگه دارند.",
- "page-staking-hierarchy-pools-p4": "سهامگذاری مشترک، بومیِ شبکهی اتریوم نیست. اشخاص ثالث در حال ساخت این راه حلها هستند و ریسکهای خود را نیز به همراه دارند.",
+ "page-staking-hierarchy-pools-p1": "اکنون چندین راهحل ادغام برای کمک به کاربرانی وجود دارد که 32 اتر (ETH) ندارند یا احساس خوبی از سهامگذاری آن ندارند.",
+ "page-staking-hierarchy-pools-p2": "بسیاری از این گزینهها شامل چیزی است که به عنوان «سهامگذاری شناور» شناخته میشود که شامل یک توکن نقدینگی ERC-20 است که اتر (ETH) سهامگذاریشده شما را نشان میدهد.",
+ "page-staking-hierarchy-pools-p3": "«سهامگذاری شناور»، خروج آسان و در هر زمان را امکانپذیر میسازد و سهامگذاری را بهسادگی تعویض توکن میکند. این گزینه همچنین به کاربران امکان میدهد داراییهای خود را در کیف پول اتریوم خود نگه دارند.",
+ "page-staking-hierarchy-pools-p4": "سهامگذاری مشترک، بومیِ شبکهی اتریوم نیست. طرفهای ثالث در حال ساخت این راه حلها هستند و ریسکهای خود را نیز به همراه دارند.",
"page-staking-hierarchy-cex-h2": "صرافیهای متمرکز",
"page-staking-hierarchy-cex-pill-1": "کماثرترین",
- "page-staking-hierarchy-cex-pill-2": "بالاترین مفروضات مربوط به اعتماد",
- "page-staking-hierarchy-cex-p1": "اگر هنوز با نگه داشتن اتر خود در کیف پول خود راحت نیستید، بسیاری از صرافیهای متمرکز خدمات سهامگذاری ارائه میکنند. آنها میتوانند جایگزینی باشند که به شما این امکان را بدهند با کمترین نظارت یا تلاش، مقداری بازده از داراییهای اتر خود کسب کنید.",
- "page-staking-hierarchy-cex-p2": "در اینجا، بدهبستان از این قرار است که ارائهدهندگان متمرکز، استخرهای بزرگی از اتر را برای اجرای تعداد زیادی اعتبارسنج ادغام میکنند. این کار میتواند برای شبکه و کاربران آن خطرناک باشد، زیرا یک هدف متمرکز و نقطهی شکست بزرگ ایجاد می کند و شبکه را در برابر حمله یا اشکالات آسیبپذیرتر میکند.",
- "page-staking-hierarchy-cex-p3": "اگر با نگه داشتن کلیدهای خود راحت نیستید، اشکالی ندارد. این گزینهها برای شما هستند. در ضمن، به صفحه کیف پول ما مراجعه کنید؛ در آنجا میتوانید یاد بگیرید چگونه مالکیت واقعی بر وجوه خود را در دست بگیرید. هنگامی که آماده شدید، برگردید و با امتحان کردن یکی از سرویسهای سهامگذاری مشترک که امکان نگهداری از مدارک شناسایی را در اختیارتان قرار میدهد، دانش سهامگذاری خود را ارتقا دهید.",
- "page-staking-hierarchy-subtext": "همانطور که ممکن است متوجه شده باشید، راههای زیادی برای شرکت در سهامگذاری اتریوم وجود دارد. این مسیرها طیف گستردهای از کاربران را هدف قرار میدهند و در نهایت هر کدام منحصر به فرد هستند و از نظر خطرات، پاداشها و مفروضات اعتماد متفاوت هستند. برخی از آنها غیرمتمرکزتر، بررسیشدهتر و/یا خطرناکتر از دیگران هستند. ما برخی اطلاعات را در مورد پروژههای پرطرفدار در فضا ارائه میکنیم، اما همیشه قبل از ارسال اتر به هر جایی، تحقیق خود را انجام دهید.",
- "page-staking-comparison-solo-saas": "شما توسط ارائهدهندگان SaaS هم همچنان باید 32 اتر را واریز کنید، اما نیازی به اجرای سختافزار ندارید. شما معمولاً دسترسی به کلیدهای اعتبارسنجی خود را حفظ میکنید، اما در عین حال باید کلیدهای امضای خود را به اشتراک بگذارید تا عملگر بتواند از طرف اعتبارسنج شما عمل کند. این کار یک لایهی اعتماد را شکل میدهد که در هنگام اجرای سختافزار شما وجود ندارد، و بر خلاف سهامگذاری انفرادی در خانه، SaaS چندان به توزیع جغرافیایی گرهها کمک نمیکند. اگر با اجرای سختافزار راحت نیستید اما همچنان به دنبال به اشتراک گذاشتن 32 اتر هستید، استفاده از یک ارائهدهندهی SaaS ممکن است گزینهی خوبی برای شما باشد.",
- "page-staking-comparison-solo-pools": "سهام گذاری انفرادی به طور قابل ملاحظه بار کاری بیشتری از سهام گذاری با سرویس مشترک دارد، اما دسترسی کامل به پاداش های اتر و کنترل کامل بر تنظیمات و امنیت اعتبارسنج شما را ارائه می دهد. سهام گذاری مشترک حد ورودی بسیار کمتری دارد. کاربران می توانند مقادیر کمی از اتر را سهام گذاری کنند، نیازی به تولید کردن کلید های اعتبارسنج نیست، و نیاز به سخت افزاری فراتر از اتصال استاندارد به اینترنت ندارند. توکن های نقدینگی امکان خروج از سهام گذاری را قبل از فعال شدن در سطح پروتکل فراهم می کنند. اگر به این ویژگی ها علاقه مند هستید، سهام گذاری مشترک ممکن است مناسب باشد.",
- "page-staking-comparison-saas-solo": "شباهتها شامل داشتن کلیدهای اعتبارسنج خود بدون نیاز به تجمیع وجوه است، اما با SaaS باید به شخص ثالث اعتماد کنید، که ممکن است بهطور بالقوه به طور مخرب عمل کند یا خود هدف حمله نظارت قرار گیرد. اگر این مفروضات مربوط به اعتماد یا خطرات تمرکزگرایی شما را نگران میکند، استاندارد طلایی سهامگذاری مستقل، سهامگذاری انفرادی است.",
- "page-staking-comparison-saas-pools": "اینها از این جهت مشابه هستند که شما معمولاً به شخص دیگری برای اجرای کلاینت اعتبارسنج متکی هستید، اما برخلاف SaaS، سهامگذاری مشترک به شما امکان میدهد با مقادیر کمتری از اتر مشارکت کنید. اگر میخواهید با کمتر از 32 اتر سهامگذاری کنید، این موارد را بررسی کنید.",
- "page-staking-comparison-pools-solo": "سهامگذاری مشترک در مقایسه با سهامگذاری انفرادی، حد ورود بسیار کمتری دارد، اما با واگذاری تمام عملیاتهای گره به شخص ثالث و با هزینه، خطر بیشتری را به همراه دارد. سهامگذاری انفرادی، حاکمیت و کنترل کاملی را برای گزینههایی که جهت انتخاب مجموعهی سهامگذاری در نظر گرفته میشود، ارائه میدهد. سهامگذارها هرگز مجبور نیستند کلیدهای خود را تحویل دهند و بدون هیچ واسطهای پاداش کامل دریافت میکنند.",
- "page-staking-comparison-pools-saas": "شباهت اینها از این جهت است که سهامگذاران خودشان نرمافزار اعتبارسنج را اجرا نمیکنند، اما برخلاف گزینههای تجمیع، SaaS برای فعال کردن اعتبارسنج به یک سپرده 32 اتر کامل نیاز دارد. پاداشها برای سهامگذار جمع میشود و معمولاً شامل هزینهی ماهانه یا سایر انواع سهام برای استفاده از خدمات میشود. اگر ترجیح میدهید کلیدهای اعتبارسنج خود را داشته باشید و میخواهید حداقل 32 اتر سهامگذاری کنید، استفاده از یک ارائهدهندهی SaaS ممکن است گزینهی خوبی برای شما باشد.",
+ "page-staking-hierarchy-cex-pill-2": "مفروضات مربوط به بالاترین اعتماد",
+ "page-staking-hierarchy-cex-p1": "اگر هنوز با نگه داشتن ETH خود در کیف پول تان راحت نیستید، بسیاری از صرافیهای متمرکز خدمات سهامگذاری ارائه میکنند. آنها میتوانند جایگزینی باشند که به شما این امکان را بدهند با کمترین نظارت یا تلاش، سودی از داراییهای ETH خود کسب کنید.",
+ "page-staking-hierarchy-cex-p2": "در اینجا، بدهبستان از این قرار است که ارائهدهندگان متمرکز، استخرهای بزرگی از ETH را برای اجرای تعداد زیادی اعتبارسنج ادغام میکنند. این کار میتواند برای شبکه و کاربران آن خطرناک باشد، زیرا یک هدف متمرکز و نقطه شکست بزرگ ایجاد می کند و شبکه را در برابر حمله یا اشکالات آسیبپذیرتر میکند.",
+ "page-staking-hierarchy-cex-p3": "اگر با نگه داشتن کلیدهای خود راحت نیستید، اشکالی ندارد. این گزینهها برای شما هستند. در ضمن، به صفحه کیفهای پول ما مراجعه کنید؛ در آنجا میتوانید یاد بگیرید چگونه مالکیت واقعی بر وجوه خود را در دست بگیرید. هنگامی که آماده شدید، برگردید و با امتحان کردن یکی از سرویسهای سهامگذاری مشترک که امکان کنترل کامل داراییها را در اختیارتان قرار میدهد، دانش سهامگذاری خود را ارتقا دهید.",
+ "page-staking-hierarchy-subtext": "همانطور که ممکن است متوجه شده باشید، راههای زیادی برای شرکت در سهامگذاری اتریوم وجود دارد. این مسیرها طیف گستردهای از کاربران را هدف قرار میدهند و در نهایت هر کدام منحصر به فرد هستند و از نظر خطرات، پاداشها و مفروضات اعتماد متفاوت هستند. برخی از آنها غیرمتمرکزتر، بررسیشدهتر و/یا پرخطرتر از بقیه هستند. ما برخی اطلاعات را در مورد پروژههای پرطرفدار در این زمینه ارائه میکنیم، اما قبل از ارسال ETH به هر مقصد، همیشه تحقیق خود را انجام دهید.",
+ "page-staking-comparison-solo-saas": "شما توسط ارائهدهندگان SaaS هم همچنان باید 32 اتر (ETH) را واریز کنید، اما نیازی به اجرای سختافزار ندارید. معمولاً دسترسی به کلیدهای اعتبارسنجی خود را حفظ میکنید، اما در عین حال باید کلیدهای امضای خود را به اشتراک بگذارید تا اپراتور بتواند از طرف اعتبارسنج شما عمل کند. این کار یک لایه اعتماد را شکل میدهد که در هنگام اجرای سختافزار شما وجود ندارد، و بر خلاف سهامگذاری انفرادی در خانه، SaaS چندان به توزیع جغرافیایی گرهها کمک نمیکند. اگر با اجرای سختافزار راحت نیستید اما همچنان به دنبال به سهامگذاری 32 اتر (ETH) هستید، استفاده از یک ارائهدهنده SaaS ممکن است گزینه خوبی برای شما باشد.",
+ "page-staking-comparison-solo-pools": "سهام گذاری انفرادی به طور قابل ملاحظه بار کاری بیشتری از سهام گذاری با سرویس مشترک دارد، اما دسترسی کامل به پاداش های ETH و کنترل کامل بر تنظیمات و امنیت اعتبارسنج شما ارائه می کند. سهام گذاری مشترک حد ورودی بسیار کمتری دارد. کاربران می توانند مقادیر کمی از ETH را سهام گذاری کنند، نیازی به تولید کردن کلیدهای اعتبارسنج نیست، و نیاز به سخت افزاری فراتر از اتصال استاندارد به اینترنت ندارند. توکن های نقدینگی امکان خروج از سهام گذاری را قبل از فعال شدن در سطح پروتکل فراهم می کنند. اگر به این ویژگی ها علاقه مند هستید، سهام گذاری مشترک ممکن است مناسب باشد.",
+ "page-staking-comparison-saas-solo": "شباهتها شامل داشتن کلیدهای اعتبارسنج خود بدون نیاز به تجمیع وجوه است، اما با SaaS باید به طرف ثالث اعتماد کنید، که ممکن است بهطور بالقوه مخرب عمل کند یا خود هدف حمله یا نظارت قرار گیرد. اگر این مفروضات مربوط به اعتماد یا خطرات تمرکزگرایی شما را نگران میکند، استاندارد طلایی سهامگذاری مستقل، سهامگذاری انفرادی است.",
+ "page-staking-comparison-saas-pools": "اینها از این جهت مشابه هستند که شما معمولاً به شخص دیگری برای اجرای کاربر اعتبارسنج متکی هستید، اما برخلاف SaaS، سهامگذاری مشترک به شما امکان میدهد با مقادیر کمتری از ETH مشارکت کنید. اگر میخواهید با کمتر از 32 اتر (ETH) سهامگذاری کنید، این موارد را بررسی کنید.",
+ "page-staking-comparison-pools-solo": "سهامگذاری مشترک در مقایسه با سهامگذاری انفرادی، حد ورود بسیار کمتری دارد، اما با واگذاری تمام عملیاتهای گره به شخص ثالث و با هزینه، خطر بیشتری را به همراه دارد. سهامگذاری انفرادی، تسلط و کنترل کامل را برای گزینههایی که جهت انتخاب مجموعه سهامگذاری در نظر گرفته میشود، ارائه میدهد. سهامگذارها هرگز مجبور نیستند کلیدهای خود را تحویل دهند و بدون واسطه پاداش کامل دریافت میکنند.",
+ "page-staking-comparison-pools-saas": "شباهت اینها از این جهت است که سهامگذاران خودشان نرمافزار اعتبارسنج را اجرا نمیکنند، اما برخلاف گزینههای تجمیع، SaaS برای فعال کردن اعتبارسنج به یک سپرده 32 اتر (ETH) کامل نیاز دارد. پاداشها برای سهامگذار جمع میشوند و معمولاً شامل هزینه ماهانه یا سایر انواع سهام برای استفاده از خدمات هستند. اگر ترجیح میدهید کلیدهای اعتبارسنج خود را داشته باشید و میخواهید حداقل 32 اتر (ETH) سهامگذاری کنید، استفاده از یک ارائهدهنده SaaS ممکن است گزینه خوبی برای شما باشد.",
"page-staking-considerations-solo-1-title": "منبعباز",
- "page-staking-considerations-solo-1-description": "کد اساسی 100% منبعباز است و برای فورک و استفاده در دسترس عموم است",
- "page-staking-considerations-solo-1-warning": "منبعبسته",
+ "page-staking-considerations-solo-1-description": "کد اساسی 100% منبع باز است و برای فورک و استفاده در دسترس عموم است",
+ "page-staking-considerations-solo-1-warning": "منبع بسته",
"page-staking-considerations-solo-2-title": "حسابرسیشده",
- "page-staking-considerations-solo-2-description": "کد اساسی مورد حسابرسی رسمی قرار گرفته است و نتایج آن منتشر شده و در دسترس عموم قرار گرفته است",
+ "page-staking-considerations-solo-2-description": "کد اساسی مورد حسابرسی رسمی قرار گرفته، و نتایج آن منتشر شده و در دسترس عموم قرار گرفته است",
"page-staking-considerations-solo-2-warning": "هیچکدام",
- "page-staking-considerations-solo-3-title": "پاداش برای باگ",
- "page-staking-considerations-solo-3-description": "پاداش عمومی برای باگ برای هر کد اساسی اجرا شده است تا برای گزارش دادن آسیبپذیریها بهطور ایمن و/یا درست کردن آنها، به کاربران پاداش داده شود",
+ "page-staking-considerations-solo-3-title": "پاداش باگ",
+ "page-staking-considerations-solo-3-description": "پاداش عمومی باگ برای هر کد اساسی اجرا شده است تا برای گزارش دادن آسیبپذیریها بهطور ایمن و/یا درست کردن آنها، به کاربران پاداش داده شود",
"page-staking-considerations-solo-3-valid": "در حال حاضر فعال",
"page-staking-considerations-solo-3-caution": "تکمیلشده",
- "page-staking-considerations-solo-4-title": "آزمودهشده",
- "page-staking-considerations-solo-4-description": "نرمافزار برای مدت زمان مشخصشده در دسترس عموم بوده و مورد استفاده قرار گرفته است",
- "page-staking-considerations-solo-4-valid": "در دسترس بودن > 1 سال",
- "page-staking-considerations-solo-4-caution": "در دسترس بودن > 6 ماه",
+ "page-staking-considerations-solo-4-title": "تست شده در شرایط سخت",
+ "page-staking-considerations-solo-4-description": "نرمافزار برای مدت زمان مشخصشده، در دسترس عموم بوده و استفاده شده است",
+ "page-staking-considerations-solo-4-valid": "دسترسی > 1 سال",
+ "page-staking-considerations-solo-4-caution": "دسترسی > 6 ماه",
"page-staking-considerations-solo-4-warning": "تازهمنتشرشده",
"page-staking-considerations-solo-5-title": "بدون نیاز به اعتماد به شخص ثالث",
- "page-staking-considerations-solo-5-description": "کلیدهای اعتبارسنج در چرخهی حیات اعتبارسنج هرگز به هیچ انسان دیگری سپرده نمیشود. هرگونه قرارداد هوشمند درگیر، فاقد در پشتی است، بدون اتکا به مجوزهای ممتاز برای اجرا.",
- "page-staking-considerations-solo-5-warning": "نیازمند اعتماد به شخص ثالث",
+ "page-staking-considerations-solo-5-description": "کلیدهای اعتبارسنج در چرخه حیات اعتبارسنج هرگز به هیچ انسان دیگری سپرده نمیشوند. هرگونه قرارداد هوشمند درگیر، فاقد در پشتی است، بدون اتکا به مجوزهای ممتاز برای اجرا.",
+ "page-staking-considerations-solo-5-warning": "مورد اعتماد",
"page-staking-considerations-solo-6-title": "بدون نیاز به مجوز",
"page-staking-considerations-solo-6-description": "کاربران برای اجرای یک اعتبارسنج با استفاده از نرمافزار یا سرویس، به مجوز ویژه نیاز ندارند",
"page-staking-considerations-solo-6-valid": "بدون نیاز به مجوز",
"page-staking-considerations-solo-6-warning": "نیازمند مجوز",
- "page-staking-considerations-solo-7-title": "چندکلاینتی",
- "page-staking-considerations-solo-7-description": "نرم افزار به کاربران امکان می دهد از میان حداقل دو یا چند کاربر اجرایی و دو یا چند کاربر لایه اجماعی را انتخاب کنند و بین آنها جابجا شوند",
- "page-staking-considerations-solo-7-valid": "جابجایی آسان بین کلاینتها",
+ "page-staking-considerations-solo-7-title": "چندکاربر",
+ "page-staking-considerations-solo-7-description": "نرم افزار به کاربران امکان می دهد از میان حداقل دو یا چند کاربر اجرایی، و دو یا چند کاربر لایه اجماعی، انتخاب کنند و بین آنها جابجا شوند",
+ "page-staking-considerations-solo-7-valid": "جابجایی آسان بین کاربرها",
"page-staking-considerations-solo-7-warning": "محدود به کاربر اکثریت",
- "page-staking-considerations-solo-8-title": "نگهداری مدارک شناسایی توسط خود",
- "page-staking-considerations-solo-8-description": "کاربر هر گونه مدارک شناسایی اعتبارسنج، از جمله کلیدهای امضا و برداشت را نزد خود نگه میدارد",
- "page-staking-considerations-solo-8-warning": "نگهداری مدارک شناسایی توسط شخص ثالث",
+ "page-staking-considerations-solo-8-title": "کنترل دارایی توسط خود",
+ "page-staking-considerations-solo-8-description": "کاربر کنترل هرگونه اعتبارنامههای اعتبارسنج، از جمله کلیدهای امضا و برداشت را نزد خود نگه میدارد",
+ "page-staking-considerations-solo-8-warning": "کنترل توسط شخص ثالث",
"page-staking-considerations-solo-9-title": "اقتصادی",
- "page-staking-considerations-solo-9-description": "کاربران میتوانند با سهامگذاری کمتر از 32 اتر، با استفاده از وجوه جمعآوری شده از دیگران، یک اعتبارسنج را اجرا کنند",
- "page-staking-considerations-solo-9-valid": "< 32 اتر",
- "page-staking-considerations-solo-9-warning": "32 اتر",
- "page-staking-considerations-saas-4-description": "خدمات برای مدت زمان مشخصشده در دسترس عموم بوده و مورد استفاده قرار گرفته است",
- "page-staking-considerations-saas-6-description": "کاربران برای شرکت در این سرویس به مجوز خاصی، ثبتنام در حساب کاربری یا احراز هویت مشتری نیاز ندارند",
- "page-staking-considerations-saas-6-valid": "هر کسی میتواند بپیوندد",
+ "page-staking-considerations-solo-9-description": "کاربران میتوانند با سهامگذاری کمتر از 32 اتر (ETH)، با استفاده از وجوه جمعآوری شده از دیگران، یک اعتبارسنج را اجرا کنند",
+ "page-staking-considerations-solo-9-valid": "< 32 اتر (ETH)",
+ "page-staking-considerations-solo-9-warning": "32 اتر (ETH)",
+ "page-staking-considerations-saas-4-description": "خدمات برای مدت زمان مشخصشده، در دسترس عموم بوده و استفاده شده است",
+ "page-staking-considerations-saas-6-description": "کاربران برای شرکت در این سرویس به مجوز خاص، ثبتنام در حساب کاربری یا احراز هویت مشتری نیاز ندارند",
+ "page-staking-considerations-saas-6-valid": "هر کس میتواند بپیوندد",
"page-staking-considerations-saas-6-warning": "نیازمند مجوز است",
"page-staking-considerations-saas-7-title": "تنوع اجرا",
- "page-staking-considerations-saas-7-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای مجموع آن را با کاربر اجرای اکثریت اجرا کند",
+ "page-staking-considerations-saas-7-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای آن را با یک کاربر اجرای اکثریت اجرا کند",
"page-staking-considerations-saas-7-valid": "کمتر از %50",
- "page-staking-considerations-saas-7-caution": "در حال حاضر ناشناخته است",
+ "page-staking-considerations-saas-7-caution": "در حال حاضر نامعلوم",
"page-staking-considerations-saas-7-warning": "بیش از 50%",
"page-staking-considerations-saas-8-title": "تنوع اجماع",
- "page-staking-considerations-saas-8-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای مجموع آن را با کاربر اجرای اکثریت اجرا کند",
+ "page-staking-considerations-saas-8-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای آن را با یک کاربر اجماع اکثریت اجرا کند",
"page-staking-considerations-saas-8-valid": "کمتر از %50",
- "page-staking-considerations-saas-8-caution": "در حال حاضر ناشناخته است",
+ "page-staking-considerations-saas-8-caution": "در حال حاضر نامعلوم",
"page-staking-considerations-saas-8-warning": "بیش از 50%",
- "page-staking-considerations-pools-5-description": "خدمات برای نگهداری از کلیدهای شما یا توزیع جوایز نیازی به اعتماد به هیچ انسانی ندارد",
- "page-staking-considerations-pools-6-title": "گرههای بدون نیاز به مجوز",
- "page-staking-considerations-pools-6-description": "سرویس به هر کسی اجازه میدهد تا بدون نیاز به اجازه به عنوان یک عملگر گره برای استخر ملحق شود",
- "page-staking-considerations-pools-7-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای مجموع آن را با کاربر اجرای اکثریت اجرا کند",
+ "page-staking-considerations-pools-5-description": "سرویس، برای نگهداری از کلیدهای شما یا توزیع جوایز، نیازی به اعتماد به هیچ انسانی ندارد",
+ "page-staking-considerations-pools-6-title": "گرههای بدون مجوز",
+ "page-staking-considerations-pools-6-description": "سرویس به هر کس اجازه میدهد بدون مجوز، به عنوان یک اپراتور گره برای استخر ملحق شود",
+ "page-staking-considerations-pools-7-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای آن را با یک کاربر اجرای اکثریت اجرا کند",
"page-staking-considerations-pools-8-title": "توکنهای نقدینگی",
- "page-staking-considerations-pools-8-description": "توکن نقدینگی قابلمعامله ارائه میدهد که نشاندهنده اتر سهامگذاریشده شما است که در کیف پولتان نگهداری میشود",
+ "page-staking-considerations-pools-8-description": "نقدینگی قابلمعامله ارائه میکند که نشاندهنده ETH سهامگذاریشده شما است که در کیف پولتان نگهداری میشود",
"page-staking-considerations-pools-8-valid": "توکن(های) نقدینگی",
"page-staking-considerations-pools-8-warning": "بدون توکن نقدینگی",
- "page-staking-considerations-pools-9-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای مجموع آن را با کاربر اجرای اکثریت اجرا کند",
+ "page-staking-considerations-pools-9-description": "سرویس نباید بیش از 50 درصد کل اعتبارسنجهای آن را با یک کاربر اجماع اکثریت اجرا کند",
"page-staking-how-solo-works-item-1": "سختافزاری دریافت کنید: برای سهامگذاری باید یک گره را اجرا کنید",
- "page-staking-how-solo-works-item-2": "یک کلاینت لایهی اجرا را همگامسازی کنید",
- "page-staking-how-solo-works-item-3": "یک کلاینت لایهی اجماع را همگامسازی کنید",
- "page-staking-how-solo-works-item-4": "کلیدهای خود را تولید کنید و آنها را در کلاینت اعتبارسنج خود بارگذاری کنید",
- "page-staking-how-solo-works-item-5": "بر گرهی خود نظارت کنید و از آن نگهداری کنید",
+ "page-staking-how-solo-works-item-2": "یک کاربر لایه اجرا را همگامسازی کنید",
+ "page-staking-how-solo-works-item-3": "یک کاربر لایه اجماع را همگامسازی کنید",
+ "page-staking-how-solo-works-item-4": "کلیدهای خود را تولید کنید و آنها را در کاربر اعتبارسنج خود بارگذاری کنید",
+ "page-staking-how-solo-works-item-5": "بر گره خود نظارت کنید و از آن نگهداری کنید",
"page-staking-launchpad-widget-testnet-label": "شبکه تست Holesky",
"page-staking-launchpad-widget-testnet-start": "سهامگذاری در شبکه تست Holesky را شروع کنید",
"page-staking-launchpad-widget-mainnet-label": "شبکهی اصلی",
- "page-staking-launchpad-widget-mainnet-start": "سهامگذاری در شبکهی اصلی را شروع کنید",
+ "page-staking-launchpad-widget-mainnet-start": "سهامگذاری در شبکه اصلی را شروع کنید",
"page-staking-launchpad-widget-span": "انتخاب شبکه",
- "page-staking-launchpad-widget-p1": "انتظار میرود که اعتبارسنج های انفرادی قبل از ریسک کردن وجوه، راهاندازی و مهارتهای عملیاتی خود را در شبکه آزمایشی Holesky آزمایش کنند. به یاد داشته باشید که انتخاب یک کاربر اقلیت مهم است، زیرا امنیت شبکه را بهبود می بخشد و ریسک شما را محدود می کند.",
- "page-staking-launchpad-widget-p2": "اگر با خط فرمان راحت هستید، میتوانید همهی چیزهای لازم را از طریق آن و با استفاده از Staking Launchpad بهتنهایی تنظیم کنید.",
- "page-staking-launchpad-widget-p3": "برای آسانتر کردن امور، برخی از ابزارها و راهنماهای زیر را بررسی کنید که میتوانند در کنار Staking Launchpad به شما کمک کنند کلاینتهای خود را بهراحتی راهاندازی کنید.",
+ "page-staking-launchpad-widget-p1": "انتظار میرود اعتبارسنجهای انفرادی، تنظیمات و مهارتهای عملیاتی خود را در شبکه تست Holesky قبل از ریسک کردن وجوه تست کنند. به یاد داشته باشید که انتخاب یک مشتری اقلیت مهم است زیرا امنیت شبکه را بهبود می بخشد و ریسک شما را محدود می کند.",
+ "page-staking-launchpad-widget-p2": "اگر مشکلی ندارید، میتوانید همه چیزهای لازم را از طریق خط فرمان و با استفاده از سکوی پرتاب سهامگذاری بهتنهایی تنظیم کنید.",
+ "page-staking-launchpad-widget-p3": "برای آسانتر کردن امور، برخی از ابزارها و راهنماهای زیر را بررسی کنید که میتوانند در کنار سکوی پرتاب سهامگذاری به شما کمک کنند کاربرهای خود را بهراحتی راهاندازی کنید.",
"page-staking-launchpad-widget-link": "راهنما و ابزارهای نرمافزاری",
"page-staking-products-get-started": "شروع به کار",
"page-staking-dropdown-staking-options": "گزینههای سهام گذاری",
@@ -162,72 +162,75 @@
"page-staking-stats-box-metric-1": "کل اتر سهامگذاریشده",
"page-staking-stats-box-metric-2": "کل اعتبارسنجها",
"page-staking-stats-box-metric-3": "APR فعلی",
- "page-staking-stats-box-metric-1-tooltip": "مجموع اتر در سهامگذاری در رنجیره بیکون، بدون در نظر گرفتن موجودی بیش از 32 اتر",
- "page-staking-stats-box-metric-2-tooltip": "تعداد حسابهای اعتبارسنج که در حال حاضر در زنجبره بیکون فعال شدهاند",
+ "page-staking-stats-box-metric-1-tooltip": "مجموع اتر در سهامگذاری در رنجیره بیکن، بدون در نظر گرفتن موجودی بیش از 32 اتر",
+ "page-staking-stats-box-metric-2-tooltip": "تعداد حسابهای اعتبارسنج که در حال حاضر در زنجبره بیکن فعال شدهاند",
"page-staking-stats-box-metric-3-tooltip": "میانگین بازده مالی سالانه به ازای هر اعتبارسنج در دوره 24 ساعته گذشته",
"page-staking-section-comparison-subtitle": "هیچ راهحل یکسانی برای سهامگذاری وجود ندارد و همگی آنها منحصربهفرد هستند. در اینجا ما برخی از ریسکها، پاداشها و الزامات روشهای مختلف سهامگذاری را مقایسه میکنیم.",
"page-staking-section-comparison-rewards-title": "پاداشها",
"page-staking-section-comparison-solo-rewards-li1": "حداکثر پاداش - پاداش کامل را بهطور مستقیم از پروتکل دریافت کنید",
"page-staking-section-comparison-solo-rewards-li2": "برای دستهبندی تراکنشها در یک بلوک جدید یا بررسی کار اعتبارسنجهای دیگر جهت حفظ امنیت زنجیره، پاداش دریافت خواهید کرد",
"page-staking-section-comparison-solo-rewards-li3": "همچنین برای بلوکهایی که پیشنهاد میکنید، کارمزد تراکنش نسوخته دریافت خواهید کرد",
- "page-staking-section-comparison-saas-rewards-li1": "معمولاً شامل پاداش کامل پروتکل منهای هزینهی ماهانه عملیاتهای گره است",
- "page-staking-section-comparison-saas-rewards-li2": "داشبوردهایی اغلب برای ردیابی آسان کلاینت اعتبارسنج شما در دسترس هستند",
+ "page-staking-section-comparison-saas-rewards-li1": "معمولاً شامل پاداش کامل پروتکل منهای هزینه ماهانه عملیاتهای گره است",
+ "page-staking-section-comparison-saas-rewards-li2": "داشبوردهایی اغلب برای ردیابی آسان کاربر اعتبارسنج شما در دسترس هستند",
"page-staking-section-comparison-pools-rewards-li1": "سهامگذاران مشترک، بسته به اینکه کدام روش سهامگذاری مشترک را انتخاب کردهاند، پاداشهای متفاوتی دریافت میکنند",
- "page-staking-section-comparison-pools-rewards-li2": "بسیاری از سرویسهای لیکوئید استیکینگ یک یا چند توکن نقدینگی را ارائه میدهند که نشاندهندهی اتر سهامگذاریشدهی شما به اضافهی سهم شما از پاداشهای اعتبارسنج است",
- "page-staking-section-comparison-pools-rewards-li3": "توکنهای نقدیگنی را میتوانید در کیف پول خود نگه دارید، در دیفای از آنها استفاده کنید، و در صورت تصمیم به خروج بفروشید",
+ "page-staking-section-comparison-pools-rewards-li2": "بسیاری از سرویسهای سهامگذاری مشترک، یک یا چند توکن نقدینگی را ارائه میدهند که نشاندهنده اتر سهامگذاریشده شما به اضافه سهم شما از پاداشهای اعتبارسنج است",
+ "page-staking-section-comparison-pools-rewards-li3": "توکنهای نقدیگنی را میتوانید در کیف پول خود نگه دارید، در دیفای از آنها استفاده کنید، و در صورت تصمیم به خروج، بفروشید",
"page-staking-section-comparison-risks-title": "ریسکها",
"page-staking-section-comparison-solo-risks-li1": "اتر شما سهامگذاری میشود",
"page-staking-section-comparison-solo-risks-li2": "برای آفلاین شدن جریمههایی در قالب مبالغ اتر وجود دارد",
- "page-staking-section-comparison-solo-risks-li3": "رفتارهای مخرب میتواند منجر به «کاهش» مقادیر بیشتر اتر و اجبار به رانده شدن از شبکه شود",
- "page-staking-section-comparison-saas-risks-li1": "همان خطرات سهامگذاری انفرادی به اضافهی ریسک ارائهدهندهی سرویس",
+ "page-staking-section-comparison-solo-risks-li3": "رفتارهای مخرب ممکن است منجر به «کاهش» مقادیر بیشتر اتر و اجبار به رانده شدن از شبکه شوند",
+ "page-staking-section-comparison-saas-risks-li1": "همان خطرات سهامگذاری انفرادی به اضافه خطر متقابل ارائهدهنده سرویس",
"page-staking-section-comparison-saas-risks-li2": "استفاده از کلیدهای امضای شما به شخص دیگری واگذار میشود که ممکن است بدخواهانه رفتار کند",
"page-staking-section-comparison-pools-risks-li1": "خطرات بسته به روش مورد استفاده متفاوت است",
- "page-staking-section-comparison-pools-risks-li2": "بهطور کلی، ریسکها ترکیبی از ریسک طرف مقابل، ریسک قرارداد هوشمند و ریسک اجرا هستند",
+ "page-staking-section-comparison-pools-risks-li2": "بهطور کلی، ریسکها ترکیبی از ریسک متقابل، ریسک قرارداد هوشمند و ریسک اجرا هستند",
"page-staking-section-comparison-requirements-title": "الزامات",
"page-staking-section-comparison-solo-requirements-li1": "شما باید 32 اتر واریز کنید",
- "page-staking-section-comparison-solo-requirements-li2": "نگهداری از سختافزاری که هم کلاینت اجرای اتریوم و هم کلاینت اجماع را در حین اتصال به اینترنت اجرا میکند",
- "page-staking-section-comparison-solo-requirements-li3": "پلتفرم سرمایهگذاری شما را در آشنایی با مراحل و نیازمندیهای سختافزاری راهنمایی میکند",
- "page-staking-section-comparison-saas-requirements-li1": "32 اتر را واریز کنید و کلیدهای خود را با راهنمایی تولید کنید",
+ "page-staking-section-comparison-solo-requirements-li2": "نگهداری از سختافزاری که هم کاربر اجرای و هم کاربر اجماع اتریوم را در حین اتصال به اینترنت اجرا میکند",
+ "page-staking-section-comparison-solo-requirements-li3": "پلتفرم سرمایهگذاری شما را در آشنایی با فرایند و نیازمندیهای سختافزاری راهنمایی میکند",
+ "page-staking-section-comparison-saas-requirements-li1": "32 اتر را واریز کنید و با کمک راهنما کلیدهای خود را تولید کنید",
"page-staking-section-comparison-saas-requirements-li2": "کلیدهای خود را بهطور ایمن ذخیره کنید",
- "page-staking-section-comparison-saas-requirements-li3": "برای سایر موارد نیاز به انجام کاری نیست، گرچه سرویسهای خاص متفاوت خواهد بود",
- "page-staking-section-comparison-pools-requirements-li1": "کمترین مقدار اتر مورد نیاز، برخی از پروژهها به مقداری بسیار کم در حد 0.01 اتر نیاز دارند",
- "page-staking-section-comparison-pools-requirements-li2": "مستقیماً از کیف پول خود به پلتفرمهای مختلف سهامگذاری واریز کنید یا به سادگی با یکی از توکنهای سهامگذاری معامله کنید",
- "page-staking-faq-1-question": "اعتباردهنده چیست؟",
- "page-staking-faq-1-answer": "اعتبارسنج یک موجودیت مجازی است که در اتریوم زندگی میکند و در اجماع پروتکل اتریوم شرکت میکند. اعتبارسنجیها با تعادل، کلید عمومی و سایر ویژگیها نشان داده میشوند. کلاینت اعتبارسنج نرمافزاری است که با نگه داشتن و استفاده از کلید خصوصی آن، از طرف اعتبارسنج عمل میکند. یک کلاینت اعتبارسنج منفرد میتواند چندین جفت کلید را در خود نگه دارد و اعتبارسنجهای زیادی را کنترل کند.",
+ "page-staking-section-comparison-saas-requirements-li3": "برای سایر موارد نیاز به انجام کاری نیست، گرچه سرویسهای خاص متفاوت خواهند بود",
+ "page-staking-section-comparison-pools-requirements-li1": "کمترین مقدار اتر مورد نیاز، برخی از پروژهها به مقدار بسیار کم در حد 0.01 اتر نیاز دارند",
+ "page-staking-section-comparison-pools-requirements-li2": "مستقیماً از کیف پول خود به پلتفرمهای مختلف سهامگذاری مشترک واریز کنید یا به سادگی با یکی از توکنهای سهامگذاری معامله کنید",
+ "page-staking-faq-1-question": "اعتبارسنج چیست؟",
+ "page-staking-faq-1-answer": "اعتبارسنج یک موجودیت مجازی است که در اتریوم زندگی میکند و در اجماع پروتکل اتریوم شرکت میکند. اعتبارسنجها با تعادل، کلید عمومی و سایر ویژگیها نشان داده میشوند. کاربر اعتبارسنج نرمافزاری است که با نگه داشتن و استفاده از کلید خصوصی اعتبارسنج، از طرف آن عمل میکند. یک کاربر اعتبارسنج منفرد میتواند چندین جفت کلید را در خود نگه دارد و اعتبارسنجهای زیادی را کنترل کند.",
"page-staking-faq-2-question": "چرا باید مبلغی را سهامگذاری کنم؟",
- "page-staking-faq-2-answer": "یک اعتبار سنجی توانایی پیشنهاد دادن و تصدیق بلوکهای شبکه را دارد. برای جلوگیری از رفتارهای ناصادقانه، کاربران باید سرمایهی خود را سهامگذاری کنند. این به پروتکل اجازه میدهد تا بازیگران مخرب را جریمه کند. سهامگذاری وسیلهای برای صادق نگه داشتن شما است، زیرا اقدامات شما عواقب مالی خواهد داشت.",
- "page-staking-faq-3-question": "آیا میتوانم «Eth2» بخرم؟",
- "page-staking-faq-3-answer-p1": "هیچ توکن «Eth2» بومی در پروتکل وجود ندارد، زیرا اتر توکن بومی (ETH) با تغییر اتریوم به اثبات سهام تغییر نکرد.",
- "page-staking-faq-3-answer-p2": "توکنهای مشتقی وجود دارند که ممکن است نشاندهندهی اتر سهامگذار باشند (یعنی rETH از Rocket Pool، stETH از Lido، ETH2 از Coinbase). دربارهی استخرهای سهامگذاری بیشتر بدانید",
+ "page-staking-faq-2-answer": "یک اعتبارسنج توانایی پیشنهاد دادن و تصدیق بلوکهای شبکه را دارد. برای جلوگیری از رفتارهای ناصادقانه، کاربران باید سرمایه خود را سهامگذاری کنند. این کار به پروتکل اجازه میدهد تا بازیگران مخرب را جریمه کند. سهامگذاری وسیلهای برای صادق نگه داشتن شما است، زیرا اقدامات شما عواقب مالی خواهد داشت.",
+ "page-staking-faq-3-question": "میتوانم «Eth2» بخرم؟",
+ "page-staking-faq-3-answer-p1": "هیچ توکن «Eth2» بومی در پروتکل وجود ندارد، زیرا اتر (ETH)، توکن بومی، با تغییر اتریوم به اثبات سهام تغییر نکرد.",
+ "page-staking-faq-3-answer-p2": "توکنهای مشتقی وجود دارند که ممکن است نشاندهنده اتر سهامگذاری شده (یعنی rETH از Rocket Pool، stETH از Lido، ETH2 از Coinbase) باشند. درباره استخرهای سهامگذاری بیشتر بدانید",
"page-staking-faq-4-question": "آیا سهامگذاری همین حالا هم در حال اجرا است؟",
- "page-staking-faq-4-answer-p1": "سهام گذاری از 1 دسامبر 2020 به صورت زنده شروع شده است",
+ "page-staking-faq-4-answer-p1": "بله. سهام گذاری از 1 دسامبر 2020 شروع شده است",
"page-staking-faq-4-answer-p2": "این بدان معنی است که در حال حاضر سهام گذاری برای کاربران فعال است تا ETH خود را واریز کنند، یک کاربر اعتبارسنج را اجرا کنند و شروع به کسب پاداش کنند.",
- "page-staking-faq-4-answer-p3": "ارتقای شانگهای/کاپلا در 12 آوریل 2023 تکمیل شد و امکان برداشتهای سهامگذاری را فراهم کرد و حلقه روی نقدینگی سهامگذاری را بست.",
- "page-staking-faq-5-question": "چه زمانی میتوانم اتر سهامگذاری شده خود را برداشت کنم؟",
+ "page-staking-faq-4-answer-p3": "ارتقای شانگهای/کاپلا در 12 آوریل 2023 تکمیل شد، امکان برداشتهای سهامگذاری را فراهم کرد و حلقه روی نقدینگی سهامگذاری را بست.",
+ "page-staking-faq-5-question": "چه زمان میتوانم اتر سهامگذاری شده خودم را برداشت کنم؟",
"page-staking-faq-5-answer-p1": "همین الان! سهامگذاران آزادند که در صورت تمایل، جوایز و/یا سپرده اصلی خود را از موجودی اعتبارسنج خود برداشت کنند.",
- "page-staking-faq-5-answer-p2": "سهامگذاران همچنین در هنگام پیشنهاد بلوکها، پاداشهایی در قالب هزینهها و MEV دریافت میکنند که بلافاصله از طریق آدرس گیرنده هزینه تعیینشده در دسترس قرار میگیرند.",
+ "page-staking-faq-5-answer-p2": "سهامگذاران همچنین در هنگام پیشنهاد بلوکها، پاداشهایی در قالب هزینهها و MEV دریافت میکنند که بلافاصله از طریق آدرس تعیینشده گیرنده هزینه در دسترس قرار میگیرند.",
"page-staking-faq-5-answer-link": "اطلاعات بیشتر درباره برداشتهای سهامگذاری",
"page-staking-further-reading-author-vitalik-buterin": "ویتالیک بوترین",
- "page-staking-further-reading-2-link": "منطق طراحی Serenity",
+ "page-staking-further-reading-2-link": "منطق طراحی آرامش",
"page-staking-further-reading-4-link": "اخبار Eth2",
"page-staking-further-reading-4-author": "بِن اِدگینگتون",
"page-staking-further-reading-5-link": "نهاییشده شمارهٔ 33، لایهٔ اجماع اتریوم (ژانویه 2022)",
"page-staking-further-reading-5-author": "دَنی رایان",
- "page-staking-further-reading-6-link": "Attestant Posts",
- "page-staking-further-reading-8-link": "محتوای آموزشی تولیدشده توسط جامعهٔ کاربران Beaconcha.in",
- "page-staking-further-reading-9-link": "پرسشهای پرتکرار دربارهٔ سکوی پرتاب سهامگذاری اتریوم",
+ "page-staking-further-reading-6-link": "پستهای تاییدکننده",
+ "page-staking-further-reading-8-link": "مطالب آموزشی تولیدشده توسط جامعهٔ کاربران Beaconcha.in",
+ "page-staking-further-reading-9-link": "پرسشهای متداول دربارهٔ پلتفرم سهامگذاری اتریوم",
"page-staking-further-reading-10-link": "پایگاه دانش EthStaker",
"page-staking-toc-how-to-stake-your-eth": "نحوهی سهامگذاری کردن اتر خود",
- "page-staking-toc-comparison-of-options": "مقایسهی گزینههای سهامگذاری",
+ "page-staking-toc-comparison-of-options": "مقایسه گزینههای سهامگذاری",
"page-staking-toc-faq": "سؤالات متداول",
"page-staking-toc-further": "بیشتر بخوانید",
"page-staking-dom-info-title": "سهامگذاری در اتریوم",
"page-staking-join-community": "به اجتماع سهامگذاران ملحق شوید",
- "page-staking-join-community-desc": "EthStaker گروهی برای تمام کسانی است که میخواهند درباره سهامگذاری در اتریوم بحث کنند. به هزاران عضو از سراسر جهان برای مشورت، حمایت و صحبت درباره تمام مسائل مربوط به سهامگذاری بپیوندید.",
- "page-staking-meta-description": "نمایی کلی از سهامگذاری اتریوم: خطرات، پاداشها، الزامات و مکان انجام آن.",
+ "page-staking-join-community-desc": "EthStaker اجتماعی برای تمام کسانی است که میخواهند درباره سهامگذاری در اتریوم بحث کنند. به هزاران عضو از سراسر جهان برای مشورت، حمایت و صحبت درباره تمام مسائل مربوط به سهامگذاری بپیوندید.",
+ "page-staking-meta-description": "نمایی کلی از سهامگذاری اتریوم: خطرات، پاداشها، الزامات و محل انجام آن.",
"page-staking-meta-title": "سهامگذاری اتریوم",
"page-staking-withdrawals-important-notices": "اطلاعیه های مهم",
- "page-staking-withdrawals-important-notices-desc": "برداشت هنوز در دسترس نیست. لطفاً سؤالات متداول مربوط به ادغام اتریوم 2 و پس از ادغام را برای اطلاعات بیشتر بخوانید.",
+ "page-staking-withdrawals-important-notices-desc": "برداشت هنوز در دسترس نیست. برای اطلاعات بیشتر لطفاً سؤالات متداول مربوط به ادغام اتریوم 2 و پس از ادغام را بخوانید.",
"page-upgrades-merge-btn": "اطلاعات بیشتر دربارهی ادغام",
- "subscribe-to-ef-blog": "برای دریافت اعلانهای ایمیلی درباره آخرین اطلاعیههای پروتکل در وبلاگ EF مشترک شوید."
+ "subscribe-to-ef-blog": "برای دریافت اعلانهای ایمیلی درباره آخرین اطلاعیههای پروتکل، در وبلاگ EF مشترک شوید.",
+ "page-staking-comparison-with-other-options": "مقایسه با گزینههای دیگر",
+ "page-staking-any-amount": "هر مقدار",
+ "page-staking-testnet": "شبکه تست"
}
diff --git a/src/intl/fa/page-upgrades-index.json b/src/intl/fa/page-upgrades-index.json
index d3d3cf00b5f..60b1a32ac8c 100644
--- a/src/intl/fa/page-upgrades-index.json
+++ b/src/intl/fa/page-upgrades-index.json
@@ -13,7 +13,7 @@
"page-upgrades-answer-4": "از زنجیره بیکن برای توسعه مکانیزم اجماع مبتنی بر اثبات سهام که اتریوم درحال حاضر بکار میبرد استفاده شد. این مکانیزم به طور جداگانه برای شبکه اصلی اتریوم (Mainnet) اجرا شد تا توسعهدهندگان بتوانند مکانیزم اجماع را به صورت مجزا قبل از استفاده از آن برای هماهنگ کردن فعالیت واقعی، مشاهده کنند.",
"page-upgrade-article-author-status": "وضعیت",
"page-upgrade-article-author-ethmerge": "Ethmerge",
- "page-upgrade-article-author-alchemy": "Alchemy",
+ "page-upgrade-article-author-alchemy": "شیمی",
"page-upgrade-article-author-consensys": "Consensys",
"page-upgrade-article-author-delphi-digital": "دلفی دیجیتال",
"page-upgrade-article-author-eip-4844": "ویتالیک بوترین، دانکراد فیست، دیدریک لوراکر، جورج کادیناکیس، مت گارنت، موفی تایوو",
diff --git a/src/intl/fa/page-what-is-ethereum.json b/src/intl/fa/page-what-is-ethereum.json
index 50227dca989..38bae50e020 100644
--- a/src/intl/fa/page-what-is-ethereum.json
+++ b/src/intl/fa/page-what-is-ethereum.json
@@ -1,86 +1,86 @@
{
"page-what-is-ethereum-alt-img-bazaar": "تصویر فردی حین نظاره کردن یک بازار، که منظور از آن اتریوم است",
"page-what-is-ethereum-alt-img-comm": "تصویری از اعضای جامعه اتریوم درحال کار با یکدیگر",
- "page-what-is-ethereum-alt-img-lego": "تصویر دستی در حال ساختن نماد اتر با آجرهای لگو",
+ "page-what-is-ethereum-alt-img-lego": "تصویر دستی در حال ساختن لوگوی ETH با آجرهای لگو",
"page-what-is-ethereum-banking-card": "بانکداری برای همه",
- "page-what-is-ethereum-banking-card-desc": "همه به خدمات مالی دسترسی ندارند. اما تنها چیزی که برای دسترسی به اتریوم و محصولات مربوط به قرض دادن، قرض گرفتن و پسانداز ساخته شده بر روی آن نیاز دارید، اتصال به اینترنت است.",
+ "page-what-is-ethereum-banking-card-desc": "همه به خدمات مالی دسترسی ندارند. اتصال به اینترنت تنها چیزی است که برای دسترسی به اتریوم و محصولات وامدهی، قرض و پسانداز یکپارچه با آن نیاز دارید.",
"page-what-is-ethereum-build": "چیزی با اتریوم بسازید",
- "page-what-is-ethereum-build-desc": "اگر میخواهید با اتریوم چیزی بسازید، مستندات ما را بخوانید، تعدادی از محتواهای آموزشی را امتحان کنید یا ابزارهای لازم برای آغاز به کار را بررسی نمایید.",
+ "page-what-is-ethereum-build-desc": "اگر میخواهید با اتریوم چیزی بسازید، مطالب ما را بخوانید، تعدادی از محتواهای آموزشی را امتحان کنید یا ابزارهای لازم برای آغاز به کار را بررسی نمایید.",
"page-what-is-ethereum-censorless-card": "مقاوم در برابر سانسور",
- "page-what-is-ethereum-censorless-card-desc": "هیچ دولت یا شرکتی کنترلی بر اتریوم ندارد. با غیرمتمرکز بودن، تقریباً غیرممکن است که کسی مانع شما برای دریافت پول یا استفاده از خدمات در اتریوم شود.",
- "page-what-is-ethereum-comm-desc": "جامعه ما شامل افرادی از تمام پیشینههاست، از جمله هنرمندان، آنارشیستهای رمزارز، 500 شرکت برتر و اکنون شما. همین امروز ببینید چگونه میتوانید مشارکت کنید.",
+ "page-what-is-ethereum-censorless-card-desc": "هیچ دولت یا شرکتی کنترلی بر اتریوم ندارد. با غیرمتمرکز بودن، تقریباً غیرممکن است کسی مانع شما برای دریافت پول یا استفاده از خدمات در اتریوم شود.",
+ "page-what-is-ethereum-comm-desc": "جامعه ما شامل افرادی با همه هر نوع پیشینه است، از جمله هنرمندان، آنارشیستهای رمزارز، 500 شرکت برتر و اکنون شما. همین امروز ببینید چگونه میتوانید مشارکت کنید.",
"page-what-is-ethereum-commerce-card": "ضمانتهای بازرگانی",
- "page-what-is-ethereum-commerce-card-desc": "مشتریان، تضمینی امن و داخلی دارند که وجوه تنها در صورتی منتقل میشوند که آنچه توافق شده را ارائه دهید. به همین ترتیب، توسعه دهندگان می توانند مطمئن باشند که قوانین در مورد آنها تغییر نمی کند.",
+ "page-what-is-ethereum-commerce-card-desc": "مشتریان، تضمینی امن و داخلی دارند که وجوه تنها در صورتی منتقل میشوند که آنچه را توافق شده است ارائه کنید. به همین ترتیب، توسعهدهندگان می توانند مطمئن باشند که قوانین در مورد آنها تغییر نمی کند.",
"page-what-is-ethereum-composable-card": "محصولات قابل ترکیب",
- "page-what-is-ethereum-composable-card-desc": "همه برنامه ها بر روی یک بلاک چین با یک وضعیت جهانی مشترک ساخته شده اند، به این معنی که می توانند از یکدیگر (مانند آجرهای لگو) ساخته شوند. این امکان را برای محصولات و تجربیات بهتر فراهم میکند و تضمین میکند که هیچکس نمیتواند ابزارهایی را که برنامهها به آن متکی هستند حذف کند.",
- "page-what-is-ethereum-community": "انجمن اتریوم",
+ "page-what-is-ethereum-composable-card-desc": "همه برنامه ها بر روی یک بلاک چین با یک وضعیت جهانی مشترک ساخته شده اند، به این معنی که می توانند از یکدیگر (مانند آجرهای لگو) ساخته شوند. این امر، امکان محصولات و تجربیات بهتر را فراهم میکند و تضمین میکند که هیچکس نمیتواند ابزارهایی را که برنامهها به آن متکی هستند حذف کند.",
+ "page-what-is-ethereum-community": "جامعه اتریوم",
"page-what-is-ethereum-desc": "بنیان آینده دیجیتال ما",
"page-what-is-ethereum-explore": "اتریوم را کاوش کنید",
"page-what-is-ethereum-internet-card": "اینترنت باز",
- "page-what-is-ethereum-internet-card-desc": "هر کسی می تواند با شبکه اتریوم تعامل داشته باشد یا بر روی آن برنامه بسازد. این به شما امکان می دهد تا دارایی ها و هویت خود را کنترل کنید، به جای اینکه آنها توسط چند شرکت بزرگ کنترل شوند.",
- "page-what-is-ethereum-meet-comm": "با این جامعه آشنا شوید",
- "page-what-is-ethereum-meta-description": "درباره اتریوم یاد بگیرید، چه کاری انجام میدهد و چگونه خودتان امتحان کنید.",
+ "page-what-is-ethereum-internet-card-desc": "هر کس می تواند با شبکه اتریوم تعامل داشته باشد یا روی آن برنامه بسازد. این امر به شما امکان می دهد دارایی ها و هویت خود را کنترل کنید، به جای اینکه آنها توسط چند شرکت بزرگ کنترل شوند.",
+ "page-what-is-ethereum-meet-comm": "با جامعه آشنا شوید",
+ "page-what-is-ethereum-meta-description": "درباره اتریوم یاد بگیرید، چه کار انجام میدهد و چگونه خودتان امتحان کنید.",
"page-what-is-ethereum-meta-title": "اتریوم چیست؟",
"page-what-is-ethereum-p2p-card": "یک شبکه همسان با همسان",
"page-what-is-ethereum-p2p-card-desc": "اتریوم به شما این امکان را می دهد که با افراد دیگر هماهنگ کنید، توافق کنید یا دارایی های دیجیتال را انتقال دهید. نیازی نیست به واسطه ها تکیه کنید.",
"page-what-is-ethereum-start-building-btn": "ساختن را آغاز کنید",
"page-what-is-ethereum-title": "اتریوم چیست؟",
- "page-what-is-ethereum-subtitle": "یک راهنمای کامل مبتدی در مورد نحوه عملکرد اتریوم، مزایایی که به ارمغان می آورد و نحوه استفاده از آن توسط میلیون ها نفر در سراسر جهان.",
+ "page-what-is-ethereum-subtitle": "یک راهنمای کامل افراد مبتدی در مورد نحوه عملکرد اتریوم، مزایایی که به ارمغان می آورد و نحوه استفاده از آن توسط میلیون ها نفر در سراسر جهان.",
"page-what-is-ethereum-button-lets-start": "شروع کنیم",
"page-what-is-ethereum-blockchain-tab-title": "بلاک چین چیست؟",
- "page-what-is-ethereum-blockchain-tab-content": "یک بلاک چین، پایگاه داده ای از تراکنش ها است که در بسیاری از رایانه های یک شبکه به روز شده و به اشتراک گذاشته می شود. هر بار که مجموعه جدیدی از تراکنش ها اضافه می شود، به آن \"بلاک\" می گویند - از این رو به آن بلاک چین (زنجیره بلوکی) می گویند. بلاکچینهای عمومی مانند اتریوم به هر کسی اجازه میدهند داده اضافه کنند، اما نه حذف کنند. اگر کسی بخواهد هر یک از اطلاعات را تغییر دهد یا سیستم را فریب دهد، باید این کار را در اکثر کامپیوترهای موجود در شبکه انجام دهد. این خیلی است! این امر بلاک چین های غیرمتمرکز مانند اتریوم را بسیار ایمن می کند.",
+ "page-what-is-ethereum-blockchain-tab-content": "یک بلاک چین، پایگاه داده های تراکنش ها است که در رایانه های زیادی در یک شبکه، به روز شده و به اشتراک گذاشته می شود. هر بار که مجموعه جدیدی از تراکنش ها اضافه می شود، به آن \"بلاک\" می گویند - از این رو به آن بلاک چین (زنجیره بلوکی) می گویند. بلاکچینهای عمومی مانند اتریوم به هر کس اجازه میدهند داده اضافه کنند، ولی نمیتوانند آنها را حذف کنند. اگر کسی بخواهد هر یک از اطلاعات را تغییر دهد یا سیستم را فریب دهد، باید این کار را در اکثر کامپیوترهای موجود در شبکه انجام دهد. این مزیت بزرگی است! این امر بلاک چین های غیرمتمرکز مانند اتریوم را بسیار ایمن می کند.",
"page-what-is-ethereum-cryptocurrency-tab-title": "ارز رمزنگاریشده چیست؟",
- "page-what-is-ethereum-cryptocurrency-tab-content-1": "کریپتوکارنسی اصطلاحی است که برای توصیف بسیاری از انواع توکن های دیجیتال قابل تعویض که با استفاده از بلاک چین ایمن شده اند به کار میرود. همه چیز با بیت کوین شروع شد. بیت کوین را می توان برای انتقال ارزش بین دو طرف بدون نیاز به اعتماد به یک واسطه استفاده کرد. شما فقط باید به کد بیت کوین اعتماد کنید که همگی باز و رایگان در دسترس است.",
- "page-what-is-ethereum-cryptocurrency-tab-content-2": "دلیل اینکه دارایی هایی مانند بیت کوین و اتر «ارزهای رمزنگاری شده» نامیده می شوند این است که امنیت داده ها و دارایی های شما توسط رمزنگاری تضمین می شود، نه با اعتمادکردن به رفتار صادقانه یک موسسه یا شرکت.",
+ "page-what-is-ethereum-cryptocurrency-tab-content-1": "ارز رمزنگاری شده اصطلاحی است که برای توصیف بسیاری از انواع توکن های دیجیتال قابل تعویض که با استفاده از بلاک چین ایمن شده اند به کار میرود. همه چیز با بیت کوین شروع شد. بیت کوین را می توان برای انتقال ارزش بین دو طرف بدون نیاز به اعتماد به یک واسطه استفاده کرد. فقط باید به کد بیت کوین اعتماد کنید که همیشه باز و رایگان در دسترس است.",
+ "page-what-is-ethereum-cryptocurrency-tab-content-2": "دلیل اینکه دارایی هایی مانند بیت کوین و اتر «ارزهای رمزنگاری شده» نامیده می شوند این است که امنیت داده ها و دارایی های شما توسط رمزنگاری تضمین می شود، نه با اعتمادکردن به صداقت رفتار یک موسسه یا شرکت.",
"page-what-is-ethereum-cryptocurrency-tab-content-3": "اتریوم دارای ارز دیجیتال بومی خود به نام اتر (ETH) است که برای پرداخت هزینه فعالیتهای خاص در شبکه استفاده میشود. می توان آن را به سایر کاربران منتقل کرد یا با توکن های دیگر در اتریوم تعویض کرد. اتر ویژه است زیرا برای پرداخت هزینه محاسبات مورد نیاز برای ساخت و اجرای برنامهها و سازمانها در اتریوم استفاده میشود.",
"page-what-is-ethereum-summary-title": "خلاصه",
- "page-what-is-ethereum-summary-desc-1": "اتریوم شبکه ای از رایانه ها در سراسر جهان است که از مجموعه قوانینی به نام پروتکل اتریوم پیروی می کنند. شبکه اتریوم به عنوان پایه ای برای جوامع، برنامه ها، سازمان ها و دارایی های دیجیتالی عمل می کند که هر کسی می تواند بسازد و استفاده کند.",
- "page-what-is-ethereum-summary-desc-2": "می توانید یک حساب اتریوم از هر کجا و در هر زمان ایجاد کنید و دنیایی از برنامه ها را کاوش کنید یا خودتان بسازید. نوآوری اصلی این است که شما می توانید همه این کارها را بدون اعتماد به یک مقام مرکزی که می تواند قوانین را تغییر دهد یا دسترسی شما را محدود کند، انجام دهید.",
+ "page-what-is-ethereum-summary-desc-1": "اتریوم شبکه ای از رایانه ها در سراسر جهان است که از مجموعه قوانینی به نام پروتکل اتریوم پیروی می کنند. شبکه اتریوم به عنوان پایه ای برای جوامع، برنامه ها، سازمان ها و دارایی های دیجیتالی عمل می کند که هر کس می تواند بسازد و استفاده کند.",
+ "page-what-is-ethereum-summary-desc-2": "در هر کجا و در هر زمان می توانید یک حساب اتریوم ایجاد کنید و دنیایی از برنامه ها را کاوش کنید یا خودتان بسازید. نوآوری اصلی این است که می توانید همه این کارها را بدون اعتماد به یک نهاد مرکزی که می تواند قوانین را تغییر دهد یا دسترسی شما را محدود کند، انجام دهید.",
"page-what-is-ethereum-summary-desc-3": "به خواندن ادامه دهید تا بیشتر بدانید…",
"page-what-is-ethereum-btc-eth-diff-title": "تفاوت بین اتریوم و بیت کوین چیست؟",
"page-what-is-ethereum-btc-eth-diff-1": "راه اندازی شده در سال 2015، اتریوم بر پایه نوآوری بیت کوین ساخته شده است، اما تفاوتهای چشمگیری دارد.",
- "page-what-is-ethereum-btc-eth-diff-2": "هر دو به شما امکان میدهند بدون نیاز به ارائهدهندگان خدمات پرداخت یا بانکها، از پول دیجیتال استفاده کنید. اما اتریوم قابلیت برنامهنویسی دارد، در نتیجه شما میتوانید از آن برای ساخت و استقرار برنامه های غیر متمرکز متفاوت بهره ببرید.",
- "page-what-is-ethereum-btc-eth-diff-3": "بیت کوین ما را قادر می سازد تا پیام های اساسی در مورد آنچه فکر می کنیم ارزشمند است به یکدیگر ارسال کنیم. تعیین ارزش بدون مرجع ذیصلاح، در حال حاضر قدرتمند است. اتریوم این را گسترش میدهد: به جای پیامها، میتوانید هرگونه برنامه یا قرارداد کلی بنویسید. هیچ محدودیتی برای نوع قراردادهایی که می توان ایجاد کرد و روی آنها توافق کرد وجود ندارد، بنابراین نوآوری بزرگی در شبکه اتریوم اتفاق می افتد.",
+ "page-what-is-ethereum-btc-eth-diff-2": "هر دو به شما امکان میدهند بدون نیاز به ارائهدهندگان خدمات پرداخت یا بانکها، از پول دیجیتال استفاده کنید. اما اتریوم قابلیت برنامهنویسی دارد، طوری که میتوانید از آن برای ساخت و استقرار برنامه های غیر متمرکز متفاوت بهره ببرید.",
+ "page-what-is-ethereum-btc-eth-diff-3": "بیت کوین به ما امکان میدهد پیام های اساسی در مورد آنچه فکر می کنیم ارزشمند است به یکدیگر ارسال کنیم. تعیین ارزش بدون مرجع ذیصلاح، در حال حاضر قدرتمند است. اتریوم این را گسترش میدهد: به جای پیامها، میتوانید هرگونه برنامه یا قرارداد کلی بنویسید. هیچ محدودیتی برای نوع قراردادهایی که می توانید ایجاد کنید و درباره آنها توافق کنید وجود ندارد، بنابراین نوآوری بزرگی در شبکه اتریوم اتفاق می افتد.",
"page-what-is-ethereum-btc-eth-diff-4": "در حالی که بیت کوین تنها یک شبکه پرداخت است، اتریوم بیشتر شبیه بازار خدمات مالی، بازی ها، شبکه های اجتماعی و سایر اپلیکیشن ها است.",
- "page-what-is-ethereum-what-can-eth-do-title": "اتریوم چه کاری می تواند انجام دهد؟",
+ "page-what-is-ethereum-what-can-eth-do-title": "اتریوم چه کار می تواند انجام دهد؟",
"page-what-is-ethereum-why-would-i-use-ethereum-title": "چرا از اتریوم استفاده کنم؟",
- "page-what-is-ethereum-why-would-i-use-ethereum-1": "اگر به روشهای انعطافپذیرتر، بازتر و قابل اعتمادتر برای هماهنگی در سطح جهانی، ایجاد سازمانها، ساختن برنامهها و اشتراکگذاری ارزش علاقهمندید، اتریوم برای شما مناسب است. اتریوم داستانی است که توسط همه ما نوشته شده است، پس بیایید و کشف کنید که چه دنیاهای باورنکردنی را می توانیم با آن بسازیم.",
- "page-what-is-ethereum-why-would-i-use-ethereum-2": "اتریوم همچنین برای افرادی که به دلیل نیروهای خارجی خارج از کنترل خود مجبور به کنترل عدم اطمینان در مورد امنیت یا سلامت یا تحرک دارایی های خود شده اند بسیار ارزشمند بوده است.",
+ "page-what-is-ethereum-why-would-i-use-ethereum-1": "اگر به روشهای انعطافپذیرتر، بازتر و قابل اعتمادتر برای هماهنگی در سطح جهانی، ایجاد سازمانها، ساختن برنامهها و اشتراکگذاری ارزش علاقهمندید، اتریوم برای شما مناسب است. اتریوم داستانی است که توسط همه ما نوشته شده است، پس بیایید و کشف کنید که چه دنیاهای باورنکردنی می توانیم با آن بسازیم.",
+ "page-what-is-ethereum-why-would-i-use-ethereum-2": "اتریوم همچنین برای افرادی که به دلیل نیروهای خارجی خارج از کنترل شان، مجبور بوده اند عدم اطمینان در مورد امنیت یا سلامت یا تحرک دارایی های خود را تحمل کنند، بسیار ارزشمند بوده است.",
"page-what-is-ethereum-slide-1-title": "پرداخت های فرامرزی ارزان تر و سریع تر",
- "page-what-is-ethereum-slide-1-desc-1": "استیبل کوین ها نوع جدیدی از ارزهای رمزنگاری شده هستند که مبنای ارزش خود را بر دارایی های باثبات تری متکی کرده اند. بیشتر آنها به دلار ایالات متحده مرتبط هستند و بنابراین ارزش آن ارز را حفظ می کنند. اینها امکان یک سیستم پرداخت جهانی بسیار ارزان و پایدار را فراهم می کند. بسیاری از استیبل کوین های فعلی بر روی شبکه اتریوم ساخته شده اند.",
- "page-what-is-ethereum-slide-1-desc-2": "اتریوم و استیبل کوین ها فرآیند ارسال پول به خارج از کشور را ساده می کنند. اغلب تنها چند دقیقه طول می کشد تا وجوه در سراسر جهان جابجا شود، برخلاف بانک شما که به طور متوسط ممکن است چندین روز کاری یا حتی چند هفته طول بکشد و برای کسری از قیمت. علاوه بر این، هیچ کارمزد اضافی برای انجام یک تراکنش با ارزش بالا وجود ندارد و هیچ محدودیتی در مورد مکان یا دلیل ارسال پول خود وجود ندارد.",
+ "page-what-is-ethereum-slide-1-desc-1": "استیبل کوین ها نوع جدیدی از ارزهای رمزنگاری شده هستند که مبنای ارزش خود را بر دارایی باثبات تری متکی کرده اند. بیشتر آنها به دلار ایالات متحده مرتبط هستند و بنابراین ارزش آن ارز را حفظ می کنند. اینها امکان یک سیستم پرداخت جهانی بسیار ارزان و پایدار را فراهم می کنند. بسیاری از استیبل کوین های فعلی بر روی شبکه اتریوم ساخته شده اند.",
+ "page-what-is-ethereum-slide-1-desc-2": "اتریوم و استیبل کوین ها فرآیند ارسال پول به خارج از کشور را ساده می کنند. اغلب تنها چند دقیقه طول می کشد تا وجوه در سراسر جهان جابجا شوند، برخلاف بانک شما که به طور متوسط ممکن است چندین روز کاری یا حتی چند هفته طول بکشد و در قبال کسری از قیمت. علاوه بر این، هیچ کارمزد اضافی برای انجام یک تراکنش با ارزش بالا وجود ندارد و هیچ محدودیتی در مورد مکان یا دلیل ارسال پولتان وجود ندارد.",
"page-what-is-ethereum-slide-2-title": "سریعترین کمک در مواقع بحران",
- "page-what-is-ethereum-slide-2-desc-1": "اگر به اندازه کافی خوش شانس هستید که چندین گزینه بانکی را از طریق مؤسسات مورد اعتماد محل زندگی خود داشته باشید، ممکن است آزادی مالی، امنیت و ثباتی را که آنها ارائه می دهند بدیهی بگیرید. اما برای بسیاری از افرادی که در سراسر جهان با سرکوب سیاسی یا مشکلات اقتصادی مواجه هستند، موسسات مالی ممکن است حمایت یا خدمات مورد نیاز را ارائه ندهند.",
- "page-what-is-ethereum-slide-2-desc-2": "هنگامی که جنگ، فجایع اقتصادی یا سرکوب آزادیهای مدنی ساکنان ونزوئلا ،کوبا، افغانستان، نیجریه، بلاروس و اوکراینرا درنوردید، ارزهای دیجیتال سریعترین و اغلب تنها گزینه برای حفظ آژانس مالی بودند.1 همانطور که در این مثالها مشاهده میشود، ارزهای رمزپایه مانند اتریوم میتوانند در زمانی که ارتباط مردم از دنیای خارج قطع میشوند دسترسی نامحدود به اقتصاد جهانی را فراهم کنند. علاوه بر این، زمانی که ارزهای محلی به دلیل تورم شدید در حال سقوط هستند، استیبل کوین ها ذخیره با ارزشی را ارائه می دهند.",
+ "page-what-is-ethereum-slide-2-desc-1": "اگر به اندازه کافی خوش شانس هستید که چندین گزینه بانکی را از طریق مؤسسات مورد اعتماد محل زندگی خود داشته باشید، ممکن است آزادی مالی، امنیت و ثباتی را که آنها ارائه می کنند بدیهی تلقی کنید. اما برای بسیاری از افرادی که در سراسر جهان با سرکوب سیاسی یا مشکلات اقتصادی مواجه هستند، موسسات مالی ممکن است حمایت یا خدمات مورد نیاز را ارائه نکنند.",
+ "page-what-is-ethereum-slide-2-desc-2": "هنگامی که جنگ، فجایع اقتصادی یا سرکوب آزادیهای مدنی، ساکنین ونزوئلا و کوبا و افغانستان و نیجریه و بلاروس و اوکراین را درگیر کرد، ارزهای دیجیتال سریعترین و اغلب تنها گزینه برای انتقال پول بودند.1 همانطور که در این مثالها مشاهده میشود، زمانی که ارتباط مردم با دنیای اطرافشان دچار مشکل میشود، ارزهای دیجیتال مانند اتریوم میتوانند دسترسی نامحدود به اقتصاد جهانی را فراهم کنند. علاوه بر این، زمانی که ارزهای محلی به دلیل تورم فوق العاده در حال سقوط هستند، استیبل کوین ها ارزش پول را حفظ می کنند.",
"page-what-is-ethereum-slide-3-title": "توانمندسازی سازندگان",
- "page-what-is-ethereum-slide-3-desc-1": "تنها در سال 2021، هنرمندان، نوازندگان، نویسندگان و دیگر سازندگان از اتریوم برای کسب درآمد مجموع حدودا 3.5 میلیارد دلاری استفاده کردند. این امر باعث می شود اتریوم در کنار Spotify، YouTube و Etsy به یکی از بزرگترین پلتفرم های جهانی برای سازندگان تبدیل شود. بیشتر بیاموزید.",
+ "page-what-is-ethereum-slide-3-desc-1": "تنها در سال 2021، هنرمندان، نوازندگان، نویسندگان و دیگر سازندگان، از اتریوم برای کسب درآمد استفاده کردند که در مجموع حدودا 3.5 میلیارد دلار بود. این امر باعث می شود اتریوم در کنار Spotify و YouTube و Etsy به یکی از بزرگترین پلتفرم های جهانی برای سازندگان تبدیل شود. بیشتر بدانید.",
"page-what-is-ethereum-slide-4-title": "توانمندسازی بازیکن ها",
- "page-what-is-ethereum-slide-4-desc-1": "بازی برای کسب درآمد (جایی که بازیکنان در واقع برای انجام بازی ها پاداش دریافت می کنند) اخیراً ظهور کرده است و در حال متحول کردن صنعت بازی است. به طور سنتی، تجارت یا انتقال دارایی های درون بازی به سایر بازیکنان با پول واقعی ممنوع است. این امر بازیکنان را مجبور به استفاده از وب سایت های بازار سیاه می کند که اغلب یک خطر امنیتی هستند. بازی همراه با بلاک چین اقتصاد درون بازی را در بر می گیرد و چنین رفتاری را به شیوه ای قابل اعتماد ارتقا میدهد.",
+ "page-what-is-ethereum-slide-4-desc-1": "بازی برای کسب درآمد (که در آن بازیکنان در واقع برای انجام بازی پاداش میگیرند) اخیراً ظهور کرده است و در حال متحول کردن صنعت بازی است. به طور سنتی، تجارت یا انتقال دارایی های درون بازی به سایر بازیکنان با پول واقعی ممنوع است. این امر بازیکنان را مجبور به استفاده از وب سایت های بازار سیاه می کند که اغلب یک خطر امنیتی هستند. بازی همراه با بلاک چین اقتصاد درون بازی را در بر می گیرد و چنین رفتاری را به شیوه ای قابل اعتماد ارتقا میدهد.",
"page-what-is-ethereum-slide-4-desc-2": "علاوه بر این، بازیکنان با امکان معامله توکنهای درون بازی با پول واقعی انگیزه پیدا میکنند و بنابراین واقعاً برای زمان بازی خود پاداش دریافت میکنند.",
"page-what-is-ethereum-meet-ether-title": "با اتر، رمزارز اتریوم آشنا شوید",
- "page-what-is-ethereum-meet-ether-desc-1": "بسیاری از اقدامات در شبکه اتریوم نیازمند انجام برخی کارها بر روی رایانه جاسازی شده اتریوم (معروف به ماشین مجازی اتریوم) است. این محاسبه رایگان نیست؛ این مبلغ، برای استفاده از ارز دیجیتال بومی اتریوم به نام اتر (ETH) پرداخت می شود. این بدان معناست که برای استفاده از شبکه به حداقل مقدار کمی اتر نیاز دارید.",
- "page-what-is-ethereum-meet-ether-desc-2": "اتر کاملا دیجیتال است و میتوانید آن را فوراً برای هر کسی در هر کجای دنیا ارسال کنید. عرضه اتر توسط هیچ دولت یا شرکتی کنترل نمی شود - غیرمتمرکز و کاملاً شفاف است. اتر به روشی دقیق طبق پروتکل صادر می شود، فقط برای سهامدارانی که شبکه را ایمن می کنند.",
+ "page-what-is-ethereum-meet-ether-desc-1": "بسیاری از اقدامات در شبکه اتریوم نیازمند انجام برخی کارها بر روی رایانه جاسازی شده اتریوم (معروف به ماشین مجازی اتریوم) است. انجام این کارها رایگان نیست؛ این مبلغ، برای استفاده از ارز دیجیتال بومی اتریوم به نام اتر (ETH) پرداخت می شود. این بدان معناست که برای استفاده از شبکه، حداقل مقدار کمی اتر نیاز دارید.",
+ "page-what-is-ethereum-meet-ether-desc-2": "اتر کاملا دیجیتال است و میتوانید آن را فوراً برای هر کس در هر جای دنیا ارسال کنید. عرضه اتر توسط هیچ دولت یا شرکتی کنترل نمی شود - غیرمتمرکز و کاملاً شفاف است. اتر به روشی دقیق طبق پروتکل، فقط برای سهامگذارانی که شبکه را ایمن می کنند، صادر می شود.",
"page-what-is-ethereum-what-is-ether": "اتر چیست؟",
- "page-what-is-ethereum-get-eth": "دریافت اتر",
+ "page-what-is-ethereum-get-eth": "دریافت ETH",
"page-what-is-ethereum-explore-applications": "برنامه های کاربردی را کاوش کنید",
"page-what-is-ethereum-learn-defi": "با DeFi آشنا شوید",
"page-what-is-ethereum-who-runs-ethereum-title": "چه کسی اتریوم را اجرا می کند؟",
- "page-what-is-ethereum-who-runs-ethereum-desc-1": "اتریوم توسط هیچ نهاد خاصی کنترل نمی شود. اتریوم هر زمان که رایانههای متصلی وجود داشته باشد که نرمافزاری را به دنبال پروتکل اتریوم اجرا میکنند و به بلاک چین اتریوم اضافه میکنند، وجود دارد. هر یک از این کامپیوترها به عنوان یک گره شناخته می شوند. گره ها می توانند توسط هر کسی اداره شوند، هرچند برای مشارکت در ایمن سازی شبکه باید ETH (توکن بومی اتریوم) را سهام گذاری کنید. هر کسی با 32 اتر(ETH) می تواند بدون نیاز به اجازه این کار را انجام دهد.",
- "page-what-is-ethereum-who-runs-ethereum-desc-2": "حتی کد منبع اتریوم توسط یک نهاد واحد تولید نمی شود. هر کسی می تواند تغییراتی را در پروتکل پیشنهاد دهد و در مورد ارتقاها بحث کند. چندین اجرای پروتکل اتریوم وجود دارد که توسط سازمان های مستقل در چندین زبان برنامه نویسی تولید می شوند و معمولاً در فضای باز ساخته می شوند و مشارکت های جامعه را تشویق می کنند.",
+ "page-what-is-ethereum-who-runs-ethereum-desc-1": "اتریوم توسط هیچ نهاد خاصی کنترل نمی شود. اتریوم زمانی وجود دارد که کامپیوترهای متصلی وجود داشته باشند که نرمافزاری را بر اساس پروتکل اتریوم و با افزودن بلاک چین اتریوم اجرا میکنند. هر یک از این کامپیوترها به عنوان یک گره شناخته می شوند. گره ها می توانند توسط هر کس اداره شوند، هرچند برای مشارکت در ایمن سازی شبکه باید ETH (توکن بومی اتریوم) را سهام گذاری کنید. هر کس با 32 اتر (ETH) می تواند بدون نیاز به مجوز این کار را انجام دهد.",
+ "page-what-is-ethereum-who-runs-ethereum-desc-2": "حتی کد منبع اتریوم توسط یک نهاد واحد تولید نمی شود. هر کس می تواند تغییراتی را در پروتکل پیشنهاد دهد و در مورد ارتقاها بحث کند. چندین اجرای پروتکل اتریوم وجود دارد که توسط سازمان های مستقل در چندین زبان برنامه نویسی تولید می شوند و معمولاً در فضای باز ساخته می شوند و مشارکت های جامعه را تشویق می کنند.",
"page-what-is-ethereum-run-a-node": "راهاندازی یک گره",
"page-what-is-ethereum-smart-contract-title": "قراردادهای هوشمند چه هستند؟",
- "page-what-is-ethereum-smart-contract-desc-1": "قراردادهای هوشمند برنامههای رایانهای هستند که در بلاک چین اتریوم زندگی میکنند. آنها زمانی اجرا می شوند که توسط یک تراکنش از سوی کاربر راه اندازی شوند. آنها اتریوم را در کارهایی که می تواند انجام دهد بسیار انعطاف پذیر می کنند. این برنامه ها به عنوان بلوک های سازنده برای برنامه ها و سازمان های غیرمتمرکز عمل می کنند.",
- "page-what-is-ethereum-smart-contract-desc-2": "آیا تا به حال از محصولی استفاده کرده اید که شرایط استفاده از خدماتش را تغییر داده باشد؟ یا یک ویژگی را که شما آن را مفید میدانستید حذف کرده باشد؟ وقتی یک قرارداد هوشمند بر روی اتریوم منتشر می شود، تا زمانی که اتریوم وجود دارد آنلاین و عملیاتی خواهد بود. حتی نویسنده آن هم نمی تواند آن را حذف کند. از آنجایی که قراردادهای هوشمند خودکار هستند، برای هیچ کدام از کاربران تبعیض قائل نمی شوند و همیشه آماده استفاده هستند.",
- "page-what-is-ethereum-smart-contract-desc-3": "نمونه های محبوب قراردادهای هوشمند عبارتند از برنامه های وام دهی، مبادلات تجاری غیرمتمرکز، بیمه، تأمین مالی درجه دوم، شبکه های اجتماعی، هاNFT - و اساساً هر چیزی که فکرش را بکنید.",
+ "page-what-is-ethereum-smart-contract-desc-1": "قراردادهای هوشمند برنامههای کامپیوتری هستند که در بلاک چین اتریوم زندگی میکنند. آنها زمانی اجرا می شوند که توسط یک تراکنش از سوی کاربر راه اندازی شوند. آنها اتریوم را در کارهایی که می تواند انجام دهد بسیار انعطاف پذیر می کنند. این برنامه ها به عنوان بلوک های سازنده برای برنامه ها و سازمان های غیرمتمرکز عمل می کنند.",
+ "page-what-is-ethereum-smart-contract-desc-2": "آیا تا به حال از محصولی استفاده کرده اید که شرایط استفاده از خدماتش را تغییر داده باشد؟ یا یک ویژگی را که شما آن را مفید میدانستید حذف کرده باشد؟ وقتی یک قرارداد هوشمند بر روی اتریوم منتشر می شود، تا زمانی که اتریوم وجود دارد آنلاین و عملیاتی خواهد بود. حتی نویسنده آن هم نمی تواند آن را حذف کند. از آنجا که قراردادهای هوشمند خودکار هستند، برای هیچ کدام از کاربران تبعیض قائل نمی شوند و همیشه آماده استفاده هستند.",
+ "page-what-is-ethereum-smart-contract-desc-3": "نمونه های محبوب قراردادهای هوشمند عبارتند از برنامه های وام دهی، مبادلات تجاری غیرمتمرکز، بیمه، تأمین مالی درجه دو، شبکه های اجتماعی، NFTها - و اساساً هر چیزی که فکرش را بکنید.",
"page-what-is-ethereum-more-on-smart-contracts": "اطلاعات بیشتر در مورد قراردادهای هوشمند",
- "page-what-is-ethereum-explore-dapps": "کاوش در صرافیهای غیرمتمرکز",
+ "page-what-is-ethereum-explore-dapps": "کاوش در برنامههای غیرمتمرکز",
"page-what-is-ethereum-criminal-activity-title": "شنیده ام رمزارز به عنوان ابزاری برای فعالیت های مجرمانه استفاده می شود. آیا این درست است؟",
- "page-what-is-ethereum-criminal-activity-desc-1": "مانند هر فن آوری، گاهی اوقات از آن سوء استفاده می شود. با این حال، از آنجایی که تمام تراکنشهای اتریوم در یک بلاک چین باز انجام میشوند، ردیابی فعالیتهای غیرقانونی اغلب برای مقامات نسبت به سیستم مالی سنتی آسانتر است و به صورت قابل بحث، اتریوم را برای کسانی که ترجیح میدهند شناسایی نشوند، انتخابی کمتر جذاب میکند.",
- "page-what-is-ethereum-criminal-activity-desc-2": "براساس یافته های کلیدی یوروپل، یک آژانس در اتحادیه اروپا برای همکاری اجرای قانون، برای اهداف مجرمانه رمزارزها نسبت به پول های فیات بسیار کمتر استفاه می شوند:",
- "page-what-is-ethereum-criminal-activity-desc-3": "“به نظر می رسد استفاده از رمزارزها برای فعالیت های غیر قانونی تنها بخش کوچکی از کل اقتصاد رمزارزها را شامل می شود و به نظر می رسد در مقایسه با وجوه غیرقانونی در سیستم مالی سنتی، کمتر است.“",
+ "page-what-is-ethereum-criminal-activity-desc-1": "مانند هر فن آوری، بعضا از آن سوء استفاده می شود. با این حال، از آنجا که تمام تراکنشهای اتریوم در یک بلاک چین باز انجام میشوند، ردیابی فعالیتهای غیرقانونی اغلب برای مقامات نسبت به سیستم مالی سنتی آسانتر است و به صورت قابل بحث، اتریوم را برای کسانی که ترجیح میدهند شناسایی نشوند، انتخابی کمتر جذاب میکند.",
+ "page-what-is-ethereum-criminal-activity-desc-2": "براساس یافته های کلیدی یوروپل، سازمان همکاری اجرای قانون در اتحادیه اروپا، برای اهداف مجرمانه رمزارزها نسبت به ارزهای فیات بسیار کمتر استفاه می شوند:",
+ "page-what-is-ethereum-criminal-activity-desc-3": "“به نظر می رسد استفاده از رمزارزها برای فعالیت های غیرقانونی تنها بخش کوچکی از کل اقتصاد رمزارزها را شامل می شود و به نظر می رسد در مقایسه با وجوه غیرقانونی در سیستم مالی سنتی، کمتر است.“",
"page-what-is-ethereum-energy-title": "در مورد مصرف انرژی اتریوم چطور؟",
- "page-what-is-ethereum-energy-desc-1": "در 15 سپتامبر 2022، اتریوم ارتقای Merge را انجام داد که اتریوم را از سند کار به سند سهام تبدیل کرد.",
- "page-what-is-ethereum-energy-desc-2": "Merge بزرگترین ارتقاء اتریوم بود و مصرف انرژی مورد نیاز برای ایمنسازی اتریوم را تا 99.95%کاهش داد و شبکه امن تر را با هزینه کربن کمتر ایجاد کرد. اتریوم اکنون یک بلاکچین کم-کربن است و در این حال امنیت و مقیاس پذیری آن افزایش یافته است.",
+ "page-what-is-ethereum-energy-desc-1": "در 15 سپتامبر 2022، اتریوم ارتقای Merge را انجام داد که اتریوم را از اثبات کار به اثبات سهام تبدیل کرد.",
+ "page-what-is-ethereum-energy-desc-2": "Merge بزرگترین ارتقاء اتریوم بود و مصرف انرژی مورد نیاز برای ایمنسازی اتریوم را تا 99.95%کاهش داد و شبکه ای امن تر را با هزینه کربن کمتر ایجاد کرد. اتریوم اکنون یک بلاکچین کم-کربن است و در این حال امنیت و مقیاس پذیری آن افزایش یافته است.",
"page-what-is-ethereum-more-on-energy-consumption": "اطلاعات بیشتر درباره مصرف انرژی",
"page-what-is-ethereum-energy-consumption-chart-legend": "مصرف سالانه انرژی بر حسب کیلووات ساعت در سال",
"energy-consumption-chart-global-data-centers-label": "مراکز داده جهانی",
@@ -90,23 +90,23 @@
"energy-consumption-chart-eth-pow-label": "ETH PoS",
"energy-consumption-chart-gaming-us-label": "بازی در ایالات متحده",
"energy-consumption-chart-airbnb-label": "AirBnB",
- "energy-consumption-chart-paypal-label": "پی پال",
+ "energy-consumption-chart-paypal-label": "پی پل",
"energy-consumption-chart-eth-pos-label": "ETH PoS",
"page-what-is-ethereum-the-merge-update": "به روز رسانی Merge",
"page-what-is-ethereum-additional-reading": "بیشتر بخوانید",
- "page-what-is-ethereum-week-in-ethereum": "هفته در اخبار اتریوم",
- "page-what-is-ethereum-week-in-ethereum-desc": "- یک خبرنامه هفتگی که تحولات کلیدی در اکوسیتم را پوشش می دهد.",
+ "page-what-is-ethereum-week-in-ethereum": "اخبار اتریوم در هفته",
+ "page-what-is-ethereum-week-in-ethereum-desc": "- یک خبرنامه هفتگی که تحولات کلیدی در اکوسیستم را پوشش می دهد.",
"page-what-is-ethereum-kernel-dreamers": "هسته",
"page-what-is-ethereum-kernel-dreamers-desc": "رویای اتریوم",
"page-what-is-ethereum-atoms-institutions-blockchains": "اتم ها، موسسات، بلاکچین ها",
"page-what-is-ethereum-atoms-institutions-blockchains-desc": "- چرا بلاکچین ها مهم هستند؟",
"page-what-is-ethereum-ethereum-in-numbers-title": "اتریوم به اعداد",
- "page-what-is-ethereum-ethereum-in-numbers-stat-1-desc": "ایجاد پروژه روی اتریوم",
+ "page-what-is-ethereum-ethereum-in-numbers-stat-1-desc": "ایجاد پروژه در اتریوم",
"page-what-is-ethereum-ethereum-in-numbers-stat-2-desc": "حساب (کیف پول) با یک موجودی ETH",
- "page-what-is-ethereum-ethereum-in-numbers-stat-3-desc": "قراردادهای هوشمند روی اتریوم",
- "page-what-is-ethereum-ethereum-in-numbers-stat-4-desc": "ارزش تضمین شده روی اتریوم",
- "page-what-is-ethereum-ethereum-in-numbers-stat-5-desc": "درامد محتواساز روی اتریوم در 2021",
- "page-what-is-ethereum-ethereum-in-numbers-stat-6-desc": "شمار تراکنشهای امروز",
+ "page-what-is-ethereum-ethereum-in-numbers-stat-3-desc": "قراردادهای هوشمند در اتریوم",
+ "page-what-is-ethereum-ethereum-in-numbers-stat-4-desc": "ارزش تضمین شده در اتریوم",
+ "page-what-is-ethereum-ethereum-in-numbers-stat-5-desc": "درآمدهای محتواساز در اتریوم در 2021",
+ "page-what-is-ethereum-ethereum-in-numbers-stat-6-desc": "تعداد تراکنشهای امروز",
"adoption-chart-column-now-label": "اکنون",
"adoption-chart-investors-label": "سرمایه گذاران",
"adoption-chart-developers-label": "توسعهدهندگان",
@@ -116,10 +116,10 @@
"adoption-chart-writers-label": "نویسندگان",
"adoption-chart-gamers-label": "گیمرها",
"adoption-chart-refugees-label": "پناهندگان",
- "page-what-is-ethereum-get-eth-alt": "کمی اتر بگیرید",
- "page-what-is-ethereum-get-eth-description": "اتر رمزارز بومی اتریوم است. شما لازم است مقدار کمی اتر در حساب خود داشته باشید تا بتوانید از برنامههای کاربردی اتریوم استفاده کنید.",
- "page-what-is-ethereum-get-eth-title": "کمی اتر بگیرید",
+ "page-what-is-ethereum-get-eth-alt": "کمی ETH بگیرید",
+ "page-what-is-ethereum-get-eth-description": "ETH رمزارز بومی اتریوم است. باید مقدار کمی ETH در حساب خود داشته باشید تا بتوانید از برنامههای کاربردی اتریوم استفاده کنید.",
+ "page-what-is-ethereum-get-eth-title": "کمی ETH بگیرید",
"page-what-is-ethereum-explore-dapps-alt": "کاوش در برنامههای غیرمتمرکز",
"page-what-is-ethereum-explore-dapps-description": "برنامههای کاربردی غیرمتمرکز (Dapps) برنامههایی هستند که روی اتریوم ساخته شدهاند. برنامههای کاربردی غیرمتمرکز مدلهای کسبوکار فعلی را مختل میکنند و مدلهای جدید ابداع میکنند.",
- "page-what-is-ethereum-explore-dapps-title": "چند دپ امتحان کنید"
+ "page-what-is-ethereum-explore-dapps-title": "چند برنامه کاربردی غیرمتمرکز امتحان کنید"
}
diff --git a/src/intl/fa/template-usecase.json b/src/intl/fa/template-usecase.json
index cde27f84ade..67540c16491 100644
--- a/src/intl/fa/template-usecase.json
+++ b/src/intl/fa/template-usecase.json
@@ -4,7 +4,7 @@
"template-usecase-dropdown-dao": "سازمانهای خودمختار غیرمتمرکز (DAOها)",
"template-usecase-dropdown-social-networks": "شبکه های مجازی غیرمتمرکز",
"template-usecase-dropdown-identity": "هویت غیرمتمرکز",
- "template-usecase-dropdown-desci": "دانش نامتمرکز (دیسای)",
+ "template-usecase-dropdown-desci": "دانش غیرمتمرکز (DeSci)",
"template-usecase-dropdown-refi": "امور مالی بازتولیدکننده (ReFi)",
"template-usecase-dropdown": "موارد استفادهی اتریوم",
"template-usecase-banner": "کاربردهای اتریوم همواره در حال توسعه و تکامل هستند. هرگونه اطلاعاتی را که فکر میکنید مسائل را شفافتر و بهروزتر میکند اضافه کنید.",
From f7adb218b61557ae277aedc7875069c9669014d8 Mon Sep 17 00:00:00 2001
From: Corwin Smith
Date: Wed, 16 Oct 2024 13:27:07 -0600
Subject: [PATCH 2/9] remove wrong imported folders
---
.../fa/04) Exploring/nft/index.md | 114 --
.../fa/05) Use Ethereum Pages/dao/index.md | 168 --
.../fa/06) Use Cases/defi/index.md | 357 ----
.../fa/06) Use Cases/smart-contracts/index.md | 82 -
.../fa/06) Use Cases/web3/index.md | 157 --
.../fa/07) Staking Pages/staking/dvt/index.md | 91 -
.../07) Staking Pages/staking/pools/index.md | 86 -
.../07) Staking Pages/staking/saas/index.md | 94 -
.../07) Staking Pages/staking/solo/index.md | 207 --
.../staking/withdrawals/index.md | 218 --
.../decentralized-identity/index.md | 191 --
.../fa/08) Use cases 2/desci/index.md | 136 --
.../fa/08) Use cases 2/refi/index.md | 81 -
.../08) Use cases 2/social-networks/index.md | 106 -
.../fa/09) Learn Pages/bridges/index.md | 136 --
.../energy-consumption/index.md | 82 -
.../fa/09) Learn Pages/governance/index.md | 182 --
.../fa/09) Learn Pages/security/index.md | 293 ---
.../zero-knowledge-proofs/index.md | 214 --
.../index.md | 73 -
.../guides/how-to-id-scam-tokens/index.md | 97 -
.../how-to-revoke-token-access/index.md | 73 -
.../guides/how-to-swap-tokens/index.md | 67 -
.../guides/how-to-use-a-bridge/index.md | 70 -
.../guides/how-to-use-a-wallet/index.md | 88 -
.../fa/10) Guides and Quizzes/guides/index.md | 27 -
.../translations/fa/11) Roadmap/eips/index.md | 79 -
.../11) Roadmap/roadmap/beacon-chain/index.md | 75 -
.../roadmap/future-proofing/index.md | 38 -
.../fa/11) Roadmap/roadmap/index.md | 119 --
.../fa/11) Roadmap/roadmap/merge/index.md | 227 ---
.../roadmap/merge/issuance/index.md | 131 --
.../fa/11) Roadmap/roadmap/scaling/index.md | 51 -
.../fa/11) Roadmap/roadmap/security/index.md | 48 -
.../roadmap/user-experience/index.md | 36 -
.../roadmap/account-abstraction/index.md | 126 --
.../roadmap/danksharding/index.md | 95 -
.../fa/12) Roadmap 2/roadmap/dencun/index.md | 120 --
.../fa/12) Roadmap 2/roadmap/pbs/index.md | 51 -
.../roadmap/secret-leader-election/index.md | 44 -
.../roadmap/single-slot-finality/index.md | 66 -
.../roadmap/statelessness/index.md | 103 -
.../roadmap/verkle-trees/index.md | 66 -
.../developers/docs/accounts/index.md | 136 --
.../developers/docs/blocks/index.md | 152 --
.../developers/docs/dapps/index.md | 101 -
.../developers/docs/evm/index.md | 78 -
.../developers/docs/evm/opcodes/index.md | 174 --
.../developers/docs/gas/index.md | 139 --
.../developers/docs/index.md | 25 -
.../developers/docs/intro-to-ether/index.md | 78 -
.../docs/intro-to-ethereum/index.md | 116 --
.../developers/docs/networks/index.md | 149 --
.../developers/docs/transactions/index.md | 243 ---
.../developers/docs/web2-vs-web3/index.md | 62 -
.../developers/docs/wrapped-eth/index.md | 65 -
.../community/code-of-conduct/index.md | 77 -
.../community/events/index.md | 24 -
.../community/get-involved/index.md | 135 --
.../community/grants/index.md | 47 -
.../community/language-resources/index.md | 153 --
.../community/online/index.md | 50 -
.../community/research/index.md | 399 ----
.../community/support/index.md | 104 -
.../nodes-and-clients/archive-nodes/index.md" | 89 -
.../nodes-and-clients/bootnodes/index.md" | 31 -
.../client-diversity/index.md" | 109 -
.../docs/nodes-and-clients/index.md" | 307 ---
.../nodes-and-clients/light-clients/index.md" | 61 -
.../node-architecture/index.md" | 57 -
.../nodes-as-a-service/index.md" | 419 ----
.../nodes-and-clients/run-a-node/index.md" | 480 -----
.../docs/consensus-mechanisms/index.md" | 92 -
.../pos/attack-and-defense/index.md" | 163 --
.../pos/attestations/index.md" | 92 -
.../pos/block-proposal/index.md" | 69 -
.../consensus-mechanisms/pos/faqs/index.md" | 172 --
.../consensus-mechanisms/pos/gasper/index.md" | 52 -
.../docs/consensus-mechanisms/pos/index.md" | 99 -
.../consensus-mechanisms/pos/keys/index.md" | 96 -
.../pos/pos-vs-pow/index.md" | 69 -
.../pos/rewards-and-penalties/index.md" | 90 -
.../pos/weak-subjectivity/index.md" | 39 -
.../docs/consensus-mechanisms/poa/index.md" | 79 -
.../docs/consensus-mechanisms/pow/index.md" | 109 -
.../consensus-mechanisms/pow/mining/index.md" | 81 -
.../dagger-hashimoto/index.md" | 334 ----
.../mining/mining-algorithms/ethash/index.md" | 1014 ----------
.../pow/mining/mining-algorithms/index.md" | 37 -
.../developers/docs/apis/backend/index.md" | 207 --
.../developers/docs/apis/javascript/index.md" | 235 ---
.../developers/docs/apis/json-rpc/index.md" | 1770 -----------------
.../block-explorers/index.md" | 257 ---
.../docs/data-and-analytics/index.md" | 55 -
.../docs/development-networks/index.md" | 83 -
.../developers/docs/ethereum-stack/index.md" | 61 -
.../developers/docs/frameworks/index.md" | 147 --
.../developers/docs/ides/index.md" | 71 -
.../docs/programming-languages/dart/index.md" | 30 -
.../programming-languages/delphi/index.md" | 56 -
.../programming-languages/dot-net/index.md" | 86 -
.../programming-languages/golang/index.md" | 85 -
.../docs/programming-languages/index.md" | 29 -
.../docs/programming-languages/java/index.md" | 65 -
.../javascript/index.md" | 73 -
.../programming-languages/python/index.md" | 90 -
.../docs/programming-languages/ruby/index.md" | 61 -
.../docs/programming-languages/rust/index.md" | 64 -
.../developers/docs/storage/index.md" | 217 --
.../fa/19) Learn Pages 2/glossary/index.md | 499 -----
.../fa/19) Learn Pages 2/history/index.md | 738 -------
.../docs/smart-contracts/anatomy/index.md" | 658 ------
.../docs/smart-contracts/compiling/index.md" | 282 ---
.../docs/smart-contracts/deploying/index.md" | 81 -
.../developers/docs/smart-contracts/index.md" | 112 --
.../docs/smart-contracts/languages/index.md" | 326 ---
.../docs/smart-contracts/libraries/index.md" | 117 --
.../docs/smart-contracts/security/index.md" | 580 ------
.../smart-contracts/composability/index.md" | 76 -
.../formal-verification/index.md" | 310 ---
.../docs/smart-contracts/testing/index.md" | 372 ----
.../docs/smart-contracts/upgrading/index.md" | 165 --
.../docs/smart-contracts/verifying/index.md" | 119 --
.../fa/21) Whitepaper/whitepaper/index.md | 610 ------
.../developers/docs/bridges/index.md | 135 --
.../index.md | 118 --
.../docs/data-availability/index.md | 84 -
.../dex-design-best-practice/index.md | 220 --
.../heuristics-for-web3/index.md | 138 --
.../developers/docs/design-and-ux/index.md | 85 -
.../developers/docs/mev/index.md | 221 --
.../developers/docs/oracles/index.md | 433 ----
.../developers/docs/standards/index.md | 59 -
.../docs/standards/tokens/erc-1155/index.md | 146 --
.../docs/standards/tokens/erc-20/index.md | 172 --
.../docs/standards/tokens/erc-223/index.md | 209 --
.../docs/standards/tokens/erc-4626/index.md | 211 --
.../docs/standards/tokens/erc-721/index.md | 244 ---
.../docs/standards/tokens/erc-777/index.md | 77 -
.../developers/docs/standards/tokens/index.md | 39 -
.../developers/docs/scaling/index.md" | 114 --
.../docs/scaling/optimistic-rollups/index.md" | 269 ---
.../developers/docs/scaling/plasma/index.md" | 175 --
.../docs/scaling/sidechains/index.md" | 73 -
.../docs/scaling/state-channels/index.md" | 67 -
.../docs/scaling/validium/index.md" | 165 --
.../docs/scaling/zk-rollups/index.md" | 259 ---
.../data-structures-and-encoding/index.md | 32 -
.../patricia-merkle-trie/index.md | 323 ---
.../data-structures-and-encoding/rlp/index.md | 163 --
.../data-structures-and-encoding/ssz/index.md | 149 --
.../web3-secret-storage-definition/index.md | 189 --
.../developers/docs/networking-layer/index.md | 155 --
.../network-addresses/index.md | 38 -
.../networking-layer/portal-network/index.md | 83 -
.../fa/26) Miscellaneous/about/index.md | 139 --
.../fa/26) Miscellaneous/enterprise/index.md | 199 --
.../enterprise/private-ethereum/index.md | 26 -
.../fa/26) Miscellaneous/foundation/index.md | 40 -
.../contributing/design-principles/index.md | 93 -
.../contributing/design/index.md | 77 -
.../fa/27) Contributing/contributing/index.md | 117 --
.../translation-program/faq/index.md | 119 --
.../how-to-translate/index.md | 89 -
.../contributing/translation-program/index.md | 90 -
.../mission-and-vision/index.md | 25 -
.../translation-program/resources/index.md | 45 -
.../translators-guide/index.md | 293 ---
.../adding-desci-projects/index.md | 44 -
.../adding-developer-tools/index.md | 61 -
.../contributing/adding-exchanges/index.md | 40 -
.../adding-glossary-terms/index.md | 26 -
.../contributing/adding-layer-2s/index.md | 97 -
.../contributing/adding-products/index.md | 100 -
.../adding-staking-products/index.md | 176 --
.../contributing/adding-wallets/index.md | 80 -
.../contributing/content-resources/index.md | 32 -
.../design/adding-design-resources/index.md | 69 -
.../contributing/quizzes/index.md | 62 -
179 files changed, 27483 deletions(-)
delete mode 100644 public/content/translations/fa/04) Exploring/nft/index.md
delete mode 100644 public/content/translations/fa/05) Use Ethereum Pages/dao/index.md
delete mode 100644 public/content/translations/fa/06) Use Cases/defi/index.md
delete mode 100644 public/content/translations/fa/06) Use Cases/smart-contracts/index.md
delete mode 100644 public/content/translations/fa/06) Use Cases/web3/index.md
delete mode 100644 public/content/translations/fa/07) Staking Pages/staking/dvt/index.md
delete mode 100644 public/content/translations/fa/07) Staking Pages/staking/pools/index.md
delete mode 100644 public/content/translations/fa/07) Staking Pages/staking/saas/index.md
delete mode 100644 public/content/translations/fa/07) Staking Pages/staking/solo/index.md
delete mode 100644 public/content/translations/fa/07) Staking Pages/staking/withdrawals/index.md
delete mode 100644 public/content/translations/fa/08) Use cases 2/decentralized-identity/index.md
delete mode 100644 public/content/translations/fa/08) Use cases 2/desci/index.md
delete mode 100644 public/content/translations/fa/08) Use cases 2/refi/index.md
delete mode 100644 public/content/translations/fa/08) Use cases 2/social-networks/index.md
delete mode 100644 public/content/translations/fa/09) Learn Pages/bridges/index.md
delete mode 100644 public/content/translations/fa/09) Learn Pages/energy-consumption/index.md
delete mode 100644 public/content/translations/fa/09) Learn Pages/governance/index.md
delete mode 100644 public/content/translations/fa/09) Learn Pages/security/index.md
delete mode 100644 public/content/translations/fa/09) Learn Pages/zero-knowledge-proofs/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md
delete mode 100644 public/content/translations/fa/10) Guides and Quizzes/guides/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/eips/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/beacon-chain/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/future-proofing/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/merge/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/merge/issuance/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/scaling/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/security/index.md
delete mode 100644 public/content/translations/fa/11) Roadmap/roadmap/user-experience/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/account-abstraction/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/danksharding/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/dencun/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/pbs/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/secret-leader-election/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/single-slot-finality/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/statelessness/index.md
delete mode 100644 public/content/translations/fa/12) Roadmap 2/roadmap/verkle-trees/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/accounts/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/blocks/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/dapps/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/evm/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/evm/opcodes/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ether/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/networks/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/transactions/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
delete mode 100644 public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/events/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/get-involved/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/grants/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/language-resources/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/online/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/research/index.md
delete mode 100644 public/content/translations/fa/14) Community Pages/community/support/index.md
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
delete mode 100644 "public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
delete mode 100644 "public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
delete mode 100644 "public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
delete mode 100644 "public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
delete mode 100644 "public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
delete mode 100644 "public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
delete mode 100644 "public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
delete mode 100644 "public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
delete mode 100644 "public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
delete mode 100644 public/content/translations/fa/19) Learn Pages 2/glossary/index.md
delete mode 100644 public/content/translations/fa/19) Learn Pages 2/history/index.md
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
delete mode 100644 "public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
delete mode 100644 "public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
delete mode 100644 "public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
delete mode 100644 "public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
delete mode 100644 "public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
delete mode 100644 "public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
delete mode 100644 public/content/translations/fa/21) Whitepaper/whitepaper/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md
delete mode 100644 public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md"
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md"
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md"
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md"
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md"
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md"
delete mode 100644 "public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md"
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md
delete mode 100644 public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md
delete mode 100644 public/content/translations/fa/26) Miscellaneous/about/index.md
delete mode 100644 public/content/translations/fa/26) Miscellaneous/enterprise/index.md
delete mode 100644 public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md
delete mode 100644 public/content/translations/fa/26) Miscellaneous/foundation/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/design-principles/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/design/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/translation-program/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md
delete mode 100644 public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md
delete mode 100644 public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md
diff --git a/public/content/translations/fa/04) Exploring/nft/index.md b/public/content/translations/fa/04) Exploring/nft/index.md
deleted file mode 100644
index 8989820ca83..00000000000
--- a/public/content/translations/fa/04) Exploring/nft/index.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: توکنهای معاوضهناپذیر (NFTها)
-description: نگاهی کلی به NFTها در اتریوم
-lang: fa
-template: use-cases
-emoji: ":frame_with_picture:"
-sidebarDepth: 2
-image: /images/infrastructure_transparent.png
-alt: لوگوی اتر که با هولوگرام نمایش داده شده است.
-summaryPoint1: راهی برای نمایش دادن هر چیز بیهمتا بهعنوان یک دارایی مبتنی بر اتریوم.
-summaryPoint2: 'NFTها بیش از هر زمان دیگر به تولیدکنندگان محتوا قدرت میدهند.'
-summaryPoint3: با پشتیبانی قراردادهای هوشمند روی زنجیره بلوکی اتریوم.
----
-
-## NFTها چه هستند؟ {#what-are-nfts}
-
-NFTها توکنهایی هستند که **منحصربهفرد** هستند. هر NFT ویژگی های متفاوت (غیرقابل معاوضه) دارد و به صورت قابل اثبات کمیاب است. این با توکنهایی مانند [ETH](/glossary/#ether) یا سایر توکنهای مبتنی بر اتریوم مانند USDC که در آن هر توکن یکسان است و ویژگیهای یکسان («قابلمعاوضه») دارد متفاوت است. برای شما مهم نیست که کدام اسکناس دلار (یا اتریوم) را در کیف پول خود داشته باشید زیرا همه آنها یکسان هستند و ارزش یکسان دارند. با این حال، شما به نوع NFT تحت مالکیتتان اهمیت _میدهید_، زیرا هر کدام از آنها مشخصات متفاوت دارند که آنها را نسبت به بقیه متمایز میکنند (معاوضهناپذیر).
-
-منحصربهفرد بودن هر NFT امکان توکنیزه کردن چیزهایی مانند آثار هنری، اشیاء کلکسیونی یا حتی املاک و مستغلات را فراهم میکند؛ در این حالت، یک NFT منحصربهفرد نمودی از برخی اقلام خاص در دنیای واقعی یا اقلام دیجیتال است. مالکیت یک دارایی به صورت عمومی در [بلاکچین](/glossary/#blockchain) اتریوم قابل تأیید است.
-
-
-
-## اینترنت دارایی ها {#internet-of-assets}
-
-NFTها و اتریوم برخی از مشکلات موجود در اینترنت امروزی را حل میکنند. هرچه همه چیز دیجیتالیتر میشود، تکثیر ویژگیهای اقلام فیزیکی مانند تعداد محدود، یکتایی و اثبات مالکیت به نحوی که تحت کنترل یک سازمان مرکزی قرار نگیرد، ضرورت پیدا میکند. به عنوان مثال، با NFTها، میتوانید یک فایل mp3 موسیقی را در همه برنامههای مبتنی بر اتریوم داشته باشید و به یک برنامه موسیقی خاص مانند Spotify یا Apple Music وابسته نباشید. میتوانید یک نام کاربری رسانه اجتماعی داشته باشید که میتوانید آن را بفروشید یا معاوضه کنید، ولی ارائهدهنده پلتفرم **نمیتواند خودسرانه آن را از شما بگیرد**.
-
-اینترنت NFTها در مقایسه با اینترنت امروزی که اکثر ما استفاده می کنیم چنین به نظر میرسد...
-
-### یک مقایسه {#nft-comparison}
-
-| یک اینترنت NFT | اینترنت امروزی |
-| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| **مالک داراییهای خود هستید!** فقط شما میتوانید آنها را بفروشید یا معاوضه کنید. | از برخی سازمانها **یک دارایی را اجاره میکنید** که ممکن است از شما پس گرفته شود. |
-| NFTها **یگانگی دیجیتالی** دارند، هیچ کدام از NFT ها مثل دیگری نیست. | **نسخه کپی را گاهی نمیتوان از نسخه اصل تشخیص داد**. |
-| مالکیت یک NFT روی بلاکچین ذخیره شده است تا هر کس بتواند آن را **عموماً تایید کند**. | دسترسی به سوابق مالکیت اقلام دیجیتال **توسط موسسات کنترل میشود** - شما باید حرف آنها را قبول کنید. |
-| NFTها [قراردادهای هوشمند](/glossary/#smart-contract) روی اتریوم هستند. بدین معنا که **استفاده آسان از آنها در دیگر قراردادهای هوشمند** و اپهای روی اتریوم امکانپذیر است! | شرکتهای دارای اقلام دیجیتال معمولاً **به زیرساخت "محدوده بسته" خود نیاز دارند**. |
-| **تولیدکنندگان محتوا میتوانند آثار خود را در هر جا بفروشند** و میتوانند به بازار جهانی دسترسی داشته باشند. | سازندگان به زیرساخت و توزیع پلتفرمهایی که ازشان استفاده میکنند متکی هستند. اینها اغلب مشمول شرایط استفاده و **محدودیتهای جغرافیایی** هستند. |
-| سازندگان NFTها **میتوانند حقوق مالکیت را بر کار خود حفظ کنند** و حق امتیاز را مستقیماً در قرارداد NFT برنامهریزی کنند. | پلتفرمهایی مانند **سرویسهای پخش آنلاین موسیقی، بیشترین سود حاصل از فروش را در اختیار دارند**. |
-
-## NFTها برای چه مواردی مورد استفاده قرار میگیرند؟ {#nft-use-cases}
-
-NFTها کاربرد بسیاری دارند، از جمله:
-
-- اثبات اینکه شما در یک رویداد شرکت کرده اید
-- گواهی میدهد که شما یک دوره را گذرانده اید
-- اقلام قابل مالکیت در بازیها
-- اثر هنری دیجیتال
-- توکنیزه کردن دارایی های جهان واقعی
-- اثبات هویت دیجیتالی شما
-- دریچه دسترسی به محتوا
-- صدور بلیت
-- نام دامنه های اینترنتی غیرمتمرکز
-- وثیقه در [امورمالی غیرمتمرکز](/glossary/#defi)
-
-شاید هنرمندی هستید که میخواهید با استفاده از NFT، و بدون از دست دادن کنترل و سودتان به واسطهها، آثارتان را به اشتراک بگذارید. میتوانید قرارداد هوشمند جدیدی بسازید و تعداد NFTها، مشخصات آنها و لینک ورود به برخی آثار هنری خاص را مشخص کنید. بهعنوان هنرمند، **میتوانید امتیازهایی را در قرارداد هوشمند برنامهریزی کنید** که باید به شما پرداخت شود (مثلاً هر بار که یک NFT معامله میشود 5٪ از قیمت فروش به صاحب قرارداد منتقل شود). همچنین همیشه میتوانید ثابت کنید که شما NFTها را تولید کردهاید، زیرا مالک [کیف پولی](/glossary/#wallet) هستید که قرارداد را منتشر کرده است. خریداران شما بهراحتی میتوانند ثابت کنند که مالک **یک NFT معتبر** متعلق به مجموعه شما هستند زیرا [آدرس](/glossary/#address) کیفپول آنها با توکنی در قرارداد هوشمند شما مرتبط است. آنها میتوانند از آن در سراسر اکوسیستم اتریوم استفاده کنند و ضمناً از بابت اصالت آن خیالشان آسوده باشد.
-
-
- NFT اثر هنری/کالاهای خود را جستجو کنید، بخرید یا بسازید...
-
- کشف آثار هنری NFT
-
-
-
-و یا بلیت یک رویداد ورزشی را در نظر بگیرید. همانطور که **برگزارکننده یک رویداد میتواند تعداد بلیت ها برای فروش را تعیین کند**، سازنده یک NFT میتواند درباره تعداد کپیهای موجود از آن تصمیم بگیرد. گاهی اینها کپیهایی کاملاً شبیه به هم هستند، مانند 5000 بلیت ورودی بدون تعیین جای مشخص. گاهی چندین مورد ضرب میشود که بسیار شبیه به هم هستند، اما هریک با دیگری کمی تفاوت دارد؛ مانند بلیت یک صندلی اختصاصی. بلیت ها را میتوان به شکل متناظر و بدون نیاز به واسطه خرید و فروش کرد و خریدار همیشه میتواند اصالت بلیتها را با چک کردن اعتبار آدرس قرارداد چک کند.
-
-در وبسایت ethereum.org، از **کل NFTها برای نشان دادن اینکه افراد به طور معنادار در مخزن گیتهاب ما** مشارکت کردهاند (وبسایت را برنامهریزی کرده، مقالهای نوشته یا تغییر دادهاند و غیره)، محتوای ما را ترجمه کردهاند، یا در دورهمیهای انجمن ما شرکت کردهاند استفاده میشود، و ما حتی نام دامنه NFT خود را داریم. اگر به ethereum.org کمک کنید، میتوانید یک NFT سبک [POAP](/glossary/#poap) دریافت کنید. بعضی دورهمیهای کریپتویی از PAOPها به عنوان بلیط استفاده کردهاند. [اطلاعات بیشتر در مورد مشارکت](/contributing/#poap).
-
-![ethereum.org POAP](./poap.png)
-
-همچنین این وبسایت یک نام دامنه جایگزین دارد که توسط NFTها پشتیبانی میشود، **ethereum.eth**. آدرس `.org` ما اساساً توسط یک ارائهدهنده «سیستم نام دامنه» (DNS) مدیریت میشود، در حالی که ethereum`.eth` از طریق سرویس نام اتریوم (ENS) در اتریوم ثبت شده است. و تحت مالکیت و مدیریت ما است. [سوابق ENS ما را بررسی کنید](https://app.ens.domains/name/ethereum.eth)
-
-[اطلاعات بیشتر درباره ENS](https://app.ens.domains)
-
-
-
-## NFTها چگونه کار میکنند؟ {#how-nfts-work}
-
-NFTها، مانند هر آیتم دیجیتالی در بلاکچین اتریوم، از طریق یک برنامه کامپیوتری ویژه مبتنی بر اتریوم به نام «قرارداد هوشمند» ایجاد میشوند. این قراردادها از قوانین خاصی پیروی می کنند، مانند استانداردهای [ERC-721](/glossary/#erc-721) یا [ERC-1155](/glossary/#erc-1155)، که تعیین میکنند قرارداد چه کار میتواند انجام دهد.
-
-قرارداد هوشمند NFT میتواند چند کار کلیدی را انجام دهد:
-
-- **ایجاد NFTها:** میتواند NFTهای جدید تولید کند.
-- **تخصیص مالکیت:** با پیوند دادن NFTها به آدرسهای خاص اتریوم، مالکیت هریک از آنها را ردیابی میکند.
-- **اختصاص یک شناسه به هر NFT:** هر NFT شمارهای دارد که آن را منحصربهفرد میکند. علاوه بر این، معمولاً برخی از اطلاعات (متادیتا) به آن پیوست شده است که توضیح میدهد آن NFT نشانگر چیست.
-
-وقتی شخصی یک NFT را «ایجاد» یا «ضرب» میکند، اساساً به قرارداد هوشمند میگوید که مالکیت یک NFT خاص را به او بدهد. این اطلاعات به صورت امن و عمومی در بلاکچین ذخیره میشود.
-
-علاوه بر این، تولیدکننده محتوا میتواند قوانین بیشتری اضافه کند. او ممکن است تعداد تولید یک NFT خاص را محدود کند یا مقرر نماید که با هربار دست به دست شدن NFT، حق امتیاز کوچکی دریافت کند.
-
-### امنیت NFT {#nft-security}
-
-امنیت اتریوم از [اثبات سهام](/glossary/#pos) نشأت میگیرد. این سیستم به گونهای طراحی شده است که از لحاظ اقتصادی از اقدامات خرابکارانه جلوگیری کند و اتریوم را درمقابل دستکاری مقاوم سازد. این چیزی است که وجود NFTها را ممکن میکند. وقتی [بلوک](/glossary/#block) حاوی تراکنش NFT شما [نهایی](/glossary/#finality) میشود، تغییر دادن آن، برای یک مهاجم میلیونها اتر هزینه دارد. هرکس که نرمافزار اتریوم را اجرا میکند، فوراً میتواند متوجه دستکاری خرابکارانه در NFT شود و طرف خرابکار مشمول جریمه مالی و اخراج میشود.
-
-مسائل امنیتی مربوط به NFTها اغلب به کلاهبرداریهای فیشینگ، آسیبپذیریهای قرارداد هوشمند یا خطاهای کاربر (مانند افشای ناخواسته کلیدهای خصوصی) مربوط میشوند، که امنیت خوب برای کیف پول را برای دارندگان NFT حیاتی میکند.
-
-
- اطلاعات بیشتر در مورد امنیت
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [راهنمای NFT برای مبتدیان](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _لیندا ژی (Linda Xie)، ژانویه 2020_
-- [ردیاب EtherscanNFT](https://etherscan.io/nft-top-contracts)
-- [استاندارد توکن ERC-721](/developers/docs/standards/tokens/erc-721/)
-- [استاندارد توکن ERC-1155](/developers/docs/standards/tokens/erc-1155/)
-- [اپها و ابزارهای محبوب NFT](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts)
-
-## منابع دیگر {#other-resources}
-
-- [NFTScan](https://nftscan.com/)
-
-
-
-
diff --git a/public/content/translations/fa/05) Use Ethereum Pages/dao/index.md b/public/content/translations/fa/05) Use Ethereum Pages/dao/index.md
deleted file mode 100644
index fe15b5466ec..00000000000
--- a/public/content/translations/fa/05) Use Ethereum Pages/dao/index.md
+++ /dev/null
@@ -1,168 +0,0 @@
----
-title: سازمانهای خودمختار غیرمتمرکز (DAOها)
-description: نگاهی کلی به DAOهای بر پایه اتریوم
-lang: fa
-template: use-cases
-emoji: ":handshake:"
-sidebarDepth: 2
-image: /images/use-cases/dao-2.png
-alt: تصویری از یک DAO در حال رأی دادن به یک پیشنهاد.
-summaryPoint1: جوامع عضومحور بدون رهبری متمرکز.
-summaryPoint2: راهی ایمن برای برقراری ارتباط با غریبههای اینترنتی.
-summaryPoint3: محلی امن برای اختصاص دادن وجه به یک هدف خاص.
----
-
-## DAO چیست؟ {#what-are-daos}
-
-یک DAO در واقع یک سازمان تحت مالکیت جمعی است که در راستای یک ماموریت مشترک کار میکند.
-
-DAOها به ما این امکان را می دهند که بدون اعتماد به یک رهبر خیرخواه برای مدیریت سرمایه ها یا عملیات، با افراد همفکر در سراسر جهان کار کنیم. هیچ مدیر عاملی وجود ندارد که بتواند بودجه خود را صرف یک هوس کند یا مدیر مالی که بتواند کتاب ها را دستکاری کند. درعوض، قوانین مبتنی بر بلاک چین که در کد گنجانده شده است، نحوه عملکرد سازمان و نحوه خرج کردن بودجه را مشخص می کند.
-
-آنها داراییهای یکپارچهای تحت اختیار دارند که هیچکس بدون تأیید گروه، اجازه دسترسی به آنها را ندارد. تصمیمات از طریق پیشنهادها و رایگیری مدیریت میشوند تا اطمینان حاصل شود که هر کس در سازمان حق اظهارنظر دارد، و همه چیز به صورت شفاف [رویزنجیره](/glossary/#on-chain) رخ میدهد.
-
-## چرا به DAO ها نیاز داریم؟ {#why-dao}
-
-راهاندازی یک سازمان با شخصی دیگر که نیازمند بودجه و پول است، نیاز به اعتماد زیادی به افرادی دارد که با آنها کار میکنید. اما اعتماد کردن به کسی که با او فقط در اینترنت تعامل داشتهاید آسان نیست. با استفاده از DAOها، نیازی به اعتماد به دیگر افراد گروه نیست؛ فقط کافی است از کد DAO مطمئن شوید که 100% شفاف است و توسط هر کسی قابل تأیید است.
-
-این موضوع فرصتهای جدیدی را برای همکاری و هماهنگی در سطح جهانی ایجاد میکند.
-
-### یک مقایسه: {#dao-comparison}
-
-| DAO | یک سازمان سنتی |
-| ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
-| معمولاً همهی افراد آن در یک سطح هستند و کاملاً دموکراتیک است. | معمولاً دارای ساختار سلسلهمراتبی است. |
-| رأیگیری از اعضا برای اعمال هرگونه تغییر لازم است. | با توجه به ساختار سازمان، تغییرات را باید از مقامات ردهبالا درخواست کرد یا ممکن است دراینباره رایگیری شود. |
-| رأیها شمرده میشود و نتیجه بهطور خودکار بدون نیاز به واسطهی مورد اعتماد اعلام میشود. | اگر رأیگیری انجام شود، رأیها بهصورت داخلی شمرده میشود و نتیجهی رأیگیری باید بهصورت دستی اعلام شود. |
-| خدمات ارائهشده بهطور خودکار و بهصورت غیرمتمرکز انجام میشوند (بهعنوان مثال، توزیع کمکهای بشردوستانه). | نیازمند دخالت انسان یا اتوماسیونِ دارای کنترل مرکزی است، که مستعد دستکاری است. |
-| تمام فعالیتها شفاف و کاملاً عمومی است. | فعالیتها معمولاً خصوصی است و دسترسی عمومی به آنها محدود است. |
-
-### نمونههای DAO {#dao-examples}
-
-برای درک بیشتر این موضوع، در اینجا چند مثال از موارد استفاده از DAO آورده شده است:
-
-- **یک خیریه** - میتوانید از هر کس در دنیا اعانه دریافت کنید و انتخاب کنید برای چه کار خیری کمک کنید.
-- **مالکیت جمعی** - میتوانید داراییهای دیجیتال یا فیزیکی را بخرید و اعضا میتوانند به روش استفاده آنها رای بدهند.
-- **ونچرها و اعتبارات** - میتوانید یک ونچر ایجاد کنید که حجم سرمایهگذاری را جمعآوری کرده و به سرمایهگذاریها رای دهد. پول بازپرداختشده میتواند بعداً بین اعضای DAO توزیع شود.
-
-
-
-## DAOها چگونه کار میکنند؟ {#how-daos-work}
-
-شالوده یک DAO عبارت است از [قرارداد هوشمند](/glossary/#smart-contract) آن، که قوانین سازمان را تعیین و خزانه گروه را نگهداری میکند. هنگامی که قرارداد در اتریوم فعال میشود، هیچکس نمیتواند قوانین را تغییر دهد مگر با رأی دادن. اگر کسی سعی کند کاری انجام دهد که توسط قوانین و منطق موجود در کد پوشش داده نشده باشد، با شکست مواجه خواهد شد. و از آنجا که خزانهداری نیز توسط قرارداد هوشمند تعریف میشود، به این معنی است که هیچکس نمیتواند پول را بدون تأیید گروه خرج کند. این بدان معناست که DAOها نیازی به یک مرجع مرکزی ندارند. در عوض، گروه به صورت جمعی تصمیم میگیرد و پرداختها به صورتخودکار با تصویب آرا مجاز میشوند.
-
-این امر به این دلیل امکانپذیر است که قراردادهای هوشمند به محض فعال شدن روی اتریوم، ضد دستکاری هستند. شما نمیتوانید کد (قوانین DAOها) را بدون اینکه مردم متوجه شوند ویرایش کنید، زیرا همهچیز عمومی است.
-
-## اتریوم و DAOها {#ethereum-and-daos}
-
-اتریوم بنا به دلایلی، زیربنایی عالی برای DAOها است:
-
-- اجماع خود اتریوم به حد کافی غیرمتمرکز و تثبیت شده است که سازمانها می توانند به شبکه اعتماد کنند.
-- کد قرارداد هوشمند، حتی توسط صاحبان آن نمیتواند پس از فعال شدن تغییر داده شود. این موضوع به DAO اجازه میدهد تا بر اساس قوانینی که با آن برنامهریزی شده است اجرا شود.
-- قراردادهای هوشمند میتوانند وجوه را ارسال یا دریافت کنند. بدون آن، شما برای مدیریت وجوه گروه به یک واسطه قابلاعتماد نیاز دارید.
-- جامعه اتریوم ثابت کرده است که بیشتر مشارکتی است تا رقابتی، و اجازه میدهد که بهترین شیوهها و سیستمهای پشتیبانی بهسرعت ظهور کنند.
-
-## حاکمیت DAO {#dao-governance}
-
-در زمان مدیریت یک DAO، موارد بسیاری باید در نظر گرفته شوند، از جمله نحوه رای دادن و پیشنهادها.
-
-### نمایندگی {#governance-delegation}
-
-اصطلاح نمایندگی (Delegation) نسخه DAO از دموکراسی نمایندگی است. دارندگان توکن، نمایندگی رای خود را به کاربرانی میدهند که خودشان را نامزد میکنند و پروتکل مورد نظر را مدیریت میکنند و همیشه در جریان امور هستند.
-
-#### یک مثال آشنا {#governance-example}
-
-[ENS](https://claim.ens.domains/delegate-ranking) - دارندگان ENS میتوانند نمایندگی رایهای خود را به اعضا مشارکتکننده جامعه بسپارند تا نماینده آنان شوند.
-
-### حاکمیت خودکار تراکنش {#governance-example}
-
-در بسیاری از DAOها، تراکنش ها در صورت کسب حدنصاب آرای اعضا، به صورت خودکار اجرا خواهند شد.
-
-#### یک نمونهٔ معروف {#governance-example}
-
-[Nouns](https://nouns.wtf) - در Nouns DAO، در صورتی که حد نصاب آرا و اکثریت آراء مثبت باشد، تا زمانی که توسط بنیانگذاران وتو نشده باشد، یک معامله بهطور خودکار انجام میشود.
-
-### حاکمیت چند امضایی {#governance-example}
-
-در حالی که DAOها ممکن است هزاران عضو رأیدهنده داشته باشند، وجوه میتوانند در [کیف پول](/glossary/#wallet) به اشتراک گذاشته شده توسط 5 تا 20 عضو فعال انجمن که مورد اعتماد و معمولاً داکس هستند (هویت های عمومی شناخته شده برای جامعه) باقی بمانند. پس از رأیگیری، امضاکنندگان [چندامضایی](/glossary/#multisig) تصمیم جامعه را اجرا میکنند.
-
-## قوانین DAOها {#dao-laws}
-
-در سال ۱۹۷۷، وایومینگ LLC را اختراع کرد که از کارآفرینان محافظت کرده و مسئولیت آنها را محدود میکند. اخیراً، آنها پیشگام قانون DAO بودند که وضعیت قانونی را برای DAOها ایجاد می کند. در حال حاضر وایومینگ، ورمونت و جزایر ویرجین قوانین DAO را به نوعی دارند.
-
-### یک مثال آشنا {#law-example}
-
-[CityDAO](https://citydao.io) – CityDAO از قانون DAO وایومینگ برای خرید 40 هکتار زمین در نزدیکی پارک ملی یلوستون استفاده کرد.
-
-## عضویت در DAO {#dao-membership}
-
-روشهای مختلف برای عضویت در DAO وجود دارد. اعضا میتوانند نحوه رأیگیری و سایر بخشهای کلیدی DAO را تعیین کنند.
-
-### عضویت مبتنی بر توکن {#token-based-membership}
-
-بسته به توکن مورد استفاده، معمولاً کاملاً [بینیاز از مجوز](/glossary/#permissionless) هستند. غالب این توکنهای حاکمیتی را میتوان بدونمجوز در یک [صرافی غیرمتمرکز](/glossary/#dex) معامله کرد. توکنهای دیگری نیز هستند که باید از طریق ارائه نقدینگی یا «اثبات کار» به نوع دیگر به دست آیند. در هر صورت، صرفا نگه داشتن این توکنها امکان شرکت در رأیگیریها را فراهم میکند.
-
-_این روش معمولاً برای کنترل پروتکلهای نامتمرکز گسترده و/یا خود توکنها استفاده میشود._
-
-#### یک مثال آشنا {#token-example}
-
-[MakerDAO](https://makerdao.com) – توکن MakerDAO به نام MKR به طور گسترده در صرافی های نامتمرکز در دسترس بوده و هر کس می تواند با خرید آن قدرت رأی دادن در خصوص آینده پروتکل Maker را به دست آورد.
-
-### عضویت مبتنی بر سهم {#share-based-membership}
-
-DAOهای مبتنی بر سهم مجوزهای بیشتری دارند، اما هنوز کاملاً باز هستند. هر عضو احتمالی میتواند پیشنهادی برای پیوستن به DAO ارائه کند، که معمولاً ادای احترامی با ارزش به شکل توکن یا کار ارائه میکند. سهام نشاندهنده قدرت مستقیم رأی دادن و مالکیت است. اعضا می توانند در هر زمان با سهم متناسب خود از خزانه، خارج شوند.
-
-_معمولاً برای سازمانهای یکپارچهتر و انسانمحور مانند مؤسسات خیریه، تعاونیهای کارگری و باشگاههای سرمایهگذاری، استفاده میشود. همچنین میتواند پروتکلها و توکنها را نیز کنترل کند._
-
-#### یک مثال آشنا {#share-example}
-
-[MolochDAO](http://molochdao.com/) - تمرکز MolochDAO بر تأمین بودجه پروژههای اتریوم است. آنها به پیشنهاد عضویت نیاز دارند تا گروه بتواند ارزیابی کند که آیا شما تخصص و سرمایه لازم برای انجام قضاوتهای آگاهانه در مورد دریافتکنندگان بالقوه احتمالی را دارید یا خیر. شما نمیتوانید دسترسی به DAO را از به سادگی از بازار آزاد خریداری کنید.
-
-### عضویت مبتنی بر شهرت {#reputation-based-membership}
-
-شهرت در DAO نشاندهنده اثبات مشارکت است و قدرت رأی را اعطا میکند. برخلاف عضویت مبتنی بر توکن یا سهم، DAOهای مبتنی بر شهرت، مالکیت را به مشارکتکنندگان منتقل نمیکنند. شهرت را نمیتوان خرید، منتقل یا تفویض کرد. اعضای DAO باید از طریق مشارکت شهرت کسب کنند. رأیگیری روی زنجیره غیرمجاز است و اعضای بالقوه میتوانند آزادانه برای پیوستن به DAO پیشنهاد ارسال کنند و درخواست کنند که بهعنوان پاداشِ مشارکتهای خود، شهرت و توکن دریافت کنند.
-
-_معمولاً برای توسعه و حاکمیت غیرمتمرکز پروتکلها و [دپها](/glossary/#dapp) استفاده میشود، اما برای مجموعههای متنوعی از سازمانها مانند موسسات خیریه، گروههای کارگری، باشگاههای سرمایهگذاری و غیره نیز مناسب است._
-
-#### یک مثال آشنا {#reputation-example}
-
-[DXdao](https://DXdao.eth.limo) - پروژه DXdao یک سازه جمعی مستقل جهانی بود که از سال 2019 بر پروتکل ها و برنامههای غیرمتمرکز حاکم بود. از حکمرانی مبتنی بر شهرت و [اجماع هولوگرافیک](/glossary/#holographic-consensus) برای هماهنگی و مدیریت وجوه استفاده کرد، به این معنی که هیچکس نمیتواند تأثیرگذاری بر آینده یا حاکمیت آن را بخرد.
-
-## پیوستن به / ایجاد یک DAO {#join-start-a-dao}
-
-### پیوستن به DAO {#join-a-dao}
-
-- [DAOهای جامعه اتریوم](/community/get-involved/#decentralized-autonomous-organizations-daos)
-- [فهرست DAOها از DAOHaus](https://app.daohaus.club/explore)
-- [لیست Tally.xyz از DAO](https://www.tally.xyz)
-
-### یک DAO راهاندازی کنید {#start-a-dao}
-
-- [یک DAO را از DAOHaus فراخوانی کنید](https://app.daohaus.club/summon)
-- [یک Governor DAO با Tally راه اندازی کنید](https://www.tally.xyz/add-a-dao)
-- [یک DAO تحت پشتیبانی Aragon ایجاد کنید](https://aragon.org/product)
-- [یک گروه تشکیل دهید](https://colony.io/)
-- [با اجماع هولوگرافیک DAOstack یک DAO ایجاد کنید](https://alchemy.daostack.io/daos/create)
-
-## بیشتر بخوانید {#further-reading}
-
-### مقالات مرتبط با DAO {#dao-articles}
-
-- [DAO چیست؟](https://aragon.org/dao) – [Aragon](https://aragon.org/)
-- [مجموعه DAOها](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
-- [DAO چیست و به چه دردی میخورد؟](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
-- [چگونه انجمن دیجیتالی تحت پشتیبانی DAO ایجاد کنیم؟](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
-- [DAO چیست؟](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
-- [اجماع هولوگرافیک چیست؟](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
-- [DAOها شرکت نیستند: جایی که تمرکززدایی در سازمان های خودمختار از سوی Vitalik اهمیت دارد](https://vitalik.eth.limo/general/2022/09/20/daos.html)
-- [DAO، DAC، DA و موارد دیگر: راهنمای اصطلاحات ناقص](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [بلاگ اتریوم](https://blog.ethereum.org)
-
-### ویدیوها {#videos}
-
-- [DAO در دنیای رمزارزها چیست؟](https://youtu.be/KHm0uUPqmVE)
-- [آیا یک DAO میتواند یک شهر بسازد؟](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city)
-
-
-
-
-
-
diff --git a/public/content/translations/fa/06) Use Cases/defi/index.md b/public/content/translations/fa/06) Use Cases/defi/index.md
deleted file mode 100644
index d3e480e6b52..00000000000
--- a/public/content/translations/fa/06) Use Cases/defi/index.md
+++ /dev/null
@@ -1,357 +0,0 @@
----
-title: امور مالی غیرمتمرکز (DeFi)
-description: نگاهی کلی بر امور مالی غیرمتمرکز بر پایهی اتریوم
-lang: fa
-template: use-cases
-emoji: ":money_with_wings:"
-image: /images/use-cases/defi.png
-alt: لوگوی اتر ساختهشده از آجرهای لگو.
-sidebarDepth: 2
-summaryPoint1: یک جایگزین جهانی و آِزاد برای سیستم مالی فعلی.
-summaryPoint2: محصولاتی برای استقراض، پسانداز، سرمایهگذاری، معامله و سایر موارد.
-summaryPoint3: بر پایهی فناوری متنباز که هر کسی میتواند برای آن برنامهنویسی کند.
----
-
-امور مالی غیرمتمرکز (DeFi) یک سیستم مالی جهانی و آزاد است که برای عصر اینترنت ساخته شده است؛ جایگزینی برای سیستمی غیرشفاف که شدیداً تحت کنترل است و دهها سال است به این شیوه اداره میشود. این سیستم کنترل و شفافیت در رابطه با پولتان را فراهم میکند. این سیستم همچنین بازارهای جهانی را در دسترس شما قرار میدهد و جایگزینی برای پول محلی یا گزینههای بانکی محلی شما ارائه میدهد. محصولات DeFi خدمات مالی را به روی هر شخصی که به اینترنت دسترسی دارد باز میکنند و بهطور کلی متعلق به کاربران هستند و توسط آنها اداره میشوند. تابهحال دهها میلیارد دلار ارز رمزنگاریشده به سمت برنامههای کاربری DeFi روانشدهاند و این رقم روز به روز افزایش مییابد.
-
-## DeFi چیست؟ {#what-is-defi}
-
-DeFi یک واژهی کلی برای محصولات و خدمات مالی در دسترس هر کسی است که میتواند از اتریوم استفاده کند – یعنی هرکسی که به اینترنت دسترسی دارد. با DeFi بازارها همواره باز هستند و هیچ قدرت متمرکزی نمیتواند پرداختها را مسدود کند یا دسترسی شما را محدود کند. خدماتی که پیشتر کند و در ریسک خطای انسانی بودند حالا خودکار و ایمنتر هستند و توسط برنامههایی انجام میشوند که هر کسی میتواند آنها را بررسی کرده و ایمنیشان را بسنجد.
-
-اقتصاد ارزهای رمزنگاریشده بسیار روبهرشد است و در آن میتوانید قرض بدهید، قرض بگیرید، خرید و فروش استقراضی انجام دهید، سود کسب کنید و کارهای دیگر انجام دهید. آرژانتینیهای علاقهمند به ارزهای رمزنگاریشده از DeFi برای فرار از تورم فلجکننده استفاده کردهاند. شرکتها پرداخت دستمزد کارکنانشان بهصورت آنلاین و در لحظه را شروع کردهاند. برخی افراد حتی میلیونها دلار را بدون احراز هویت قرض گرفتهاند و پس دادهاند.
-
-
-
-## DeFi در مقابل امور مالی سنتی {#defi-vs-tradfi}
-
-یکی از بهترین راههای فهمیدن پتانسیلهای DeFi، فهمیدن مشکلات امروزه است.
-
-- برخی مردم دسترسی به ساخت حساب بانکی یا استفاده از خدمات مالی ندارند.
-- دسترسی پایین به خدمات مالی میتواند باعث شود مردم نتوانند مشغول به کار شوند.
-- خدمات مالی میتوانند مانع از پرداخت حقوق شما شوند.
-- یکی از هزینههای پنهان خدمات مالی، اطلاعات شخصی شماست.
-- دولتها و نهادهای متمرکز میتوانند هر زمان خواستند بازارها را ببندند.
-- ساعات خرید و فروش اغلب محدود به ساعات اداری ویژه یک منطقه زمانی است.
-- به دلیل رویههای انسانی، تراکنشهای مالی ممکن است روزها طول بکشند.
-- خدمات مالی کارمزد دارند چرا که نهادهای میانجی میخواهند سهم خود را دریافت کنند.
-
-### یک مقایسه: {#defi-comparison}
-
-| DeFi | امور مالی سنتی |
-| ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| شما مالک پول خود هستید. | پول شما توسط شرکتها نگهداری میشود. |
-| شما کنترل میکنید که پولتان کجا برود و چگونه خرج شود. | شما باید به شرکتها اعتماد کنید که پولتان را به شکل اشتباه مدیریت نکنند، مثلاً آن را به افراد پرریسک قرض ندهند. |
-| جابجایی پول در چند دقیقه انجام میشود. | پرداختها ممکن است به دلیل فرایندهای دستی تا چند روز طول بکشد. |
-| فعالیت تراکنش با نام مستعار انجام میشود. | فعالیت مالی کاملاً وابسته به هویت شخص است. |
-| DeFi برای همه آزاد است. | شما باید برای استفاده از خدمات مالی درخواست بدهید. |
-| بازارها همواره باز هستند. | بازارها بسته میشوند چرا که کارمندان نیاز به استراحت دارند. |
-| بر پایهی شفافیت ساختهشدهاست – هر کس میتواند اطلاعات محصول را نگاه کند و نحوهی کار سیستم را بررسی کند. | نهادهای مالی همانند کتابهای بسته هستند: نمیتوانید از آنها درخواست کنید که تاریخچهی وامها، تاریخچهی داراییهای مدیریتشدهی آنها و غیره را ببینید. |
-
-
- مشاهدهی برنامههای DeFi
-
-
-## همه چیز با بیتکوین شروع شد... {#bitcoin}
-
-از خیلی جهات بیتکوین اولین برنامهی DeFi محسوب میشود. بیتکوین به شما اجازه میدهد که ارزش را واقعاً در اختیار داشته باشید و کنترل کنید و برای هر کسی در هر کجای جهان بفرستید. بیتکوین این کار را با فراهم کردن راهی برای توافق بر یک دفترکل حاوی حسابهای کاربری بدون نیاز به اعتماد به یک میانجی سوم برای تعداد زیادی آدم که به یکدیگر اعتماد ندارند انجام میدهد. بیتکوین برای همه آزاد است و هیچکس نمیتواند برای آن قانون وضع کند. قوانین بیتکوین، مثل کمیابی و باز بودنش، در فناوری آن نهادینه شدهاند. مانند امور مالی سنتی نیست که دولتها بتوانند پول چاپ کنند که ارزش پساندازهای شما کم شود و شرکتها بتوانند بازارها را ببندند.
-
-اتریوم بر همین اساس ساخته شدهاست. همانند بیتکوین، قوانین برای شما و هر کسی که به آن دسترسی دارد تغییر نمیکند. ولی همچنین این پول دیجیتال را با استفاده از [قراردادهای هوشمند](/glossary/#smart-contract) قابلبرنامهنویسی نیز می کند تا بتوانید کارهایی فراتر از نگهداری و انتقال ارزش انجام دهید.
-
-
-
-## پول قابلبرنامهریزی {#programmable-money}
-
-عجیب به نظر میرسد... «چرا باید بخواهم پولم را برنامهنویسی کنم؟» با این حال، این کار چیزی فراتر از ویژگیهای پیشفرض توکنها در اتریوم است. هر شخصی میتواند منطق را بر روی پرداختها برنامهنویسی کند. پس میتوانید کنترل و ایمنی بیتکوین را در کنار خدمات ارائهشده توسط نهادهای مالی داشته باشید. با این ویژگی شما میتوانید کارهایی با ارزهای رمزنگاریشده بکنید که با بیتکوین نمیتوانستید انجام دهید؛ مثل قرض دادن و قرض گرفتن، برنامهریزی کردن پرداختها، سرمایهگذاری در صندوقهای سرمایهگذاری مبتنی بر شاخص و غیره.
-
-
- اگر تازه پا به جهان اتریوم گذاشتهاید، نگاهی به پیشنهادهای ما برای برنامههای DeFi جهت استفاده بیاندازید.
-
- مشاهدهی برنامههای DeFi
-
-
-
-## با DeFi چه کارهایی میتوان کرد؟ {#defi-use-cases}
-
-برای بیشتر خدمات مالی یک جایگزین غیرمتمرکز وجود دارد. اما اتریوم فرصت خلق محصولات مالی کاملاً جدید را هم فراهم میسازد. فهرست این خدمات همواره در حال گسترش است.
-
-- [ارسال پول به اقصی نقاط جهان](#send-money)
-- [به جریان انداختن پول در اقصی نقاط جهان](#stream-money)
-- [دسترسی به پایدارزها](#stablecoins)
-- [قرض گرفتن وجه با وثیقه](#lending)
-- [قرض گرفتن بدون وثیقه](#flash-loans)
-- [شروع پسانداز با ارزهای رمزنگاریشده](#saving)
-- [معاملهی توکنها](#swaps)
-- [بزرگ کردن سبد سرمایه](#investing)
-- [جذب سرمایه برای ایدهها](#crowdfunding)
-- [خرید بیمه](#insurance)
-- [مدیریت سبد سرمایه](#aggregators)
-
-
-
-### ارسال سریع پول به اقصی نقاط جهان {#send-money}
-
-اتریوم به عنوان یک زنجیرهی بلوکی، برای ارسال تراکنشها به شکلی ایمن و در تمام جهان ساخته شده است. همانند بیتکوین، فرستادن پول به تمام نقاط جهان از طریق اتریوم بهسادگی فرستادن یک ایمیل انجام میشود. تنها کافی است که [نام ENS متعلق](/glossary/#ens) به دریافتکننده (مثل bob.eth) یا آدرس حساب او را در کیفپول خود وارد کنید و پول شما ظرف چند دقیقه (بهطور معمول) به دست او خواهد رسید. برای دریافت و پرداخت پول شما نیاز به یک [کیف پول](/wallets/) دارید.
-
-
- مشاهدهی برنامههای غیرمتمرکز پرداخت
-
-
-#### به جریان انداختن پول در اقصی نقاط جهان... {#stream-money}
-
-شما همچنین میتوانید پول را در اتریوم به جریان بیاندازید. با این ویژگی میتوانید حقوق ماهانهی هر فرد را در لحظه واریز کنید تا هر زمان که لازمش داشتند به پولشان دسترسی داشته باشند. یا چیزی مثل قفسهی نگهداری وسایل یا اسکوتر برقی را در لحظه اجاره کنید.
-
-و اگر نمیخواهید [اتر](/glossary/#ether) را ارسال یا استریم کنید چون ارزش آن ممکن است تغییر کند، ارزهای جایگزینی نیز در اتریوم وجود دارند: [استیبلکوینها](/glossary/#stablecoin).
-
-
-
-### دسترسی به پایدارزها {#stablecoins}
-
-نوسانات ارزهای رمزنگاریشده برای بسیاری از محصولات مالی و هزینهکردهای عمومی یک مشکل محسوب میشود. جامعهی DeFi این مشکل را با پایدرز حل کرده است. ارزش آنها به یک دارایی دیگر متصل است؛ عموماً به یک ارز مشهور مثل دلار.
-
-ارزهایی همچون Dai یا USDC ارزشی حدود یک دلار دارند. این موضوع باعث میشود برای کسب درآمد یا خرید عالی باشند. بسیاری از مردم در آمریکای لاتین از پایدارز به عنوان روشی برای حفاظت از پسانداز خود در دوران عدماطمینان بسیار زیاد به ارزهایی که دولت خودشان ساخته است، استفاده کردهاند.
-
-
- اطلاعات بیشتر دربارهی پایدارز
-
-
-
-
-### قرض گرفتن {#lending}
-
-قرض گرفتن پول از فراهمکنندگان غیرمتمرکز به دو شکل است.
-
-- همتا به همتا، به این معنی که قرضگیرنده بهطور مستقیم از یک قرضدهندهی مشخص قرض میگیرد.
-- بر پایهی استخر که در آن قرضدهندگان وجوه (نقدینگی) را به یک استخر ارائه میدهند و قرضگیرندگان میتوانند از آن قرض بگیرند.
-
-
- مشاهدهی برنامههای غیرمتمرکز برای قرض گرفتن
-
-
-مزایای بسیاری برای استفاده از یک قرضدهندهی غیرمتمرکز وجود دارد...
-
-#### قرض گرفتن ضمن حفظ حریم خصوصی {#borrowing-privacy}
-
-امروزه قرض گرفتن و قرض دادن پول بهکلی به افراد دخیل در آن مربوط است. بانکها پیش از وام دادن به شما مطمئن میشوند که آیا وام را بازپرداخت میکنید یا خیر.
-
-قرض دادن غیرمتمرکز به احراز هویت هیچیک از طرفین نیاز ندارد. در عوض، قرضگیرنده باید وثیقهای بگذارد که قرضدهنده در صورت عدم بازپرداخت بهصورت خودکار دریافتش خواهد کرد. برخی قرضدهندگان حتی [NFTها](/glossary/#nft) را به عنوان وثیقه میپذیرند. NFT سندی برای یک دارایی یکتا است؛ مثلاً یک نقاشی. [اطلاعات بیشتر دربارهی NFT](/nft/)
-
-این ویژگی به شما امکان میدهد که بدون چک اعتباری یا دادن اطلاعات خصوصی، پول قرض بگیرید.
-
-#### دسترسی به سرمایههای جهانی {#access-global-funds}
-
-با استفاده از یک قرضدهندهی غیرمتمرکز به سرمایههایی از سراسر جهان دسترسی دارید، نه صرفاً سرمایههایی که در اختیار بانک یا نهاد منتخبتان هستند. این موضوع باعث میشود که وامها در دسترستر بوده و نرخ بهره بهتر باشد.
-
-#### کارآیی مالیاتی {#tax-efficiencies}
-
-قرض گرفتن میتواند به شما اجازه دهد که از سرمایههایی که نیاز دارید بدون فروختن اتر خود (که مالیات دارد) استفاده کنید. در عوض میتوانید از ETH خود بهعنوان وثیقه برای دریافت وام استیبل کوین استفاده کنید. با این کار جریان نقدینگی لازم را خواهید داشت و میتوانید اتر خود را نگهداری کنید. پایدارزها توکنهایی هستند که هنگام نیاز به وجه نقد بسیار بهتر هستند، چون برخلاف اتر نوسانات ارزشی ندارند. [اطلاعات بیشتر دربارهی پایدارزها](#stablecoins)
-
-#### وام لحظهای {#flash-loans}
-
-وامهای لحظهای یک شکل تجربیتر از قرض دادن غیرمتمرکز هستند که به شما اجازه میدهند بدون وثیقه گذاشتن یا در اختیار قرار دادن اطلاعات شخصی قرض بگیرید.
-
-این نوع از وام در حال حاضر بهطور گسترده برای افراد غیرفنی در دسترس نیست، اما اشارهای است برای این که در آینده چه اتفاقاتی میتواند برای همه ممکن باشد.
-
-این وامها به این صورت کار میکنند که قرض دادن و پس دادن قرض در یک تراکنش انجام میشود. اگر امکان بازپرداخت وام در لحظه نباشد، تراکنش برمیگردد، به گونهای که گویی هرگز اتفاق نیافتاده است.
-
-پولهایی که اغلب استفاده میشوند در استخرهای نقدینگی (استخرهای بزرگی از پول که برای قرض دادن استفاده میشوند) نگهداری میشوند. اگر این پولها در لحظهای مشخص در حال استفاده نباشند، یک فرصت برای شخصی دیگر ایجاد میشود که این پولها را قرض بگیرد، با آن کسبوکاری برای خود بسازد و سپس همهی پول را دقیقاً در زمانی که قرض گرفته بازپسدهد.
-
-این به این معناست که منطق بسیار زیادی را باید درون یک تراکنش مشخص گنجاند. یک مثال ساده میتواند این باشد که یک فرد، میزان زیادی از یک دارایی را با وام لحظهای قرض بگیرد تا در صرافی دیگری با قیمتی بالاتر بفروشد.
-
-بنابراین در یک تراکنش، اتفاقات زیر رخ میدهند:
-
-- مقدار X $asset را به قیمت $1.00 از صرافی A قرض میگیرید
-- X $asset را در صرافی B به قیمت $1.00 تومان به فروش میرسانید
-- قرض خود را به صرافی A برمیگردانید
-- سود خود منهای کارمزد تراکنش را نگه میدارید
-
-اگر عرضهی صرافی B ناگهان افت کند و این کاربر نتواند به میزان کافی برای پوشش دادن قرضش از این صرافی خرید کند، تراکنش انجام نمیشود.
-
-برای این که بتوانید مثال پیشگفته را در نظام مالی سنتی دنیا انجام دهید، به مقدار بسیار زیادی پول نیاز دارید. این راهبردهای پولسازی تنها در دسترس افرادی هستند که سرمایهی بسیار زیادی دارند. وامهای لحظهای نمونهای از آیندهای هستند که داشتن پول از ملزومات پول درآوردن نخواهد بود.
-
-
- اطلاعات بیشتر دربارهی وامهای لحظهای
-
-
-
-
-### شروع پسانداز با ارزهای رمزنگاریشده {#saving}
-
-#### قرض دادن {#lending}
-
-شما میتوانید از قرض دادن ارزهای رمزنگاریشدهی خود به دیگران بهره کسب کنید و رشد سرمایهتان را به چشم ببینید. در حال حاضر نرخ بهره بسیار بیشتر از آن چیزی است که احتمالاً در بانکهای محلیتان دریافت میکنید (البته اگر به حد کافی خوششانس باشید که چنین بانکی نزدیکتان باشد). این مثال را ببینید:
-
-- شما 100 Dai، یک [پایدارز](/stablecoins/)، را به یک محصول مثل Aave قرض میدهید.
-- شما 100 Aave Dai (aDai) میگیرید. این توکن نمایشدهندهی Dai قرضدادهشدهی شما است.
-- aDai شما بر اساس نرخ بهره زیاد میشود و میتوانید شاهد افزایش میزان موجودی خود در کیف پولتان باشید. بسته به [نرخ درصدی سالیانه](/glossary/#apr)، موجودی کیفپول شما پس از چند روز یا حتی چند ساعت چیزی شبیه به 100.1234 خواهد بود!
-- شما میتوانید بهاندازهی aDaiهای موجودی خود در هر زمانی از حساب خود Dai برداشت کنید.
-
-
- مشاهدهی برنامههای غیرمتمرکز قرضدهی
-
-
-#### بختآزماییهای بدون باخت {#no-loss-lotteries}
-
-بختآزماییهای بدون باخت مثل PoolTogether روشی جدید، خلاقانه و لذتبخش برای سود کردن با پول هستند.
-
-- شما 100 بلیط با 100 توکن Dai میخرید.
-- 100 عدد plDai که نمایشدهندهی 100 بلیطتان است دریافت میکنید.
-- اگر یکی از بلیطهای شما به عنوان بلیط برنده انتخاب شود، موجودی plDai شما به اندازهی جایزهی استخر افزایش مییابد.
-- اگر برنده نشوید، 100 plDai شما به قرعهکشی هفتهی بعد منتقل میشود.
-- میتوانید بهاندازهی plDaiهایی که موجود دارید در هر زمانی از حساب خود Dai برداشت کنید.
-
-جایزهی استخر از بهرهای که با قرضدهی سپردهی بلیطها همچو مثال قرضدهی بالا به دست میآید، تولید میشود.
-
-
- PoolTogether را امتحان کنید
-
-
-
-
-### مبادلهی توکنها {#swaps}
-
-هزاران توکن روی اتریوم وجود دارند. صرافیهای غیرمتمرکز (DEXها) به شما اجازه میدهند هر زمان که خواستید توکنهای مختلف را مبادله کنید. شما هیچ وقت کنترل دارایی خود را از دست نمیدهید. این کار مثل مراجعه به صرافی در سفر به کشوری دیگر است. تفاوت در این است که صرافیهای DeFi هرگز بسته نمیشوند. بازارها بهصورت شبانهروزی در تمام 365 روز سال باز هستند و فناوری تضمین میکند همواره شخصی وجود داشته باشد که معامله را بپذیرد.
-
-برای مثال، اگر بخواهید از بختآزمایی بدون باخت PoolTogether استفاده کنید (بالاتر توضیح دادهایم)، به توکنی مثل Dai یا USDC نیاز خواهید داشت. این صرافیهای غیرمتمرکز به شما اجازه میدهند که اتر (ETH) خود را به این توکنها تبدیل کنید و وقتی کارتان تمام شد به حالت اول تبدیل کنید.
-
-
- مشاهدهی صرافیهای توکنها
-
-
-
-
-### معاملهی پیشرفته {#trading}
-
-برای معاملهگرانی که میخواهند کمی کنترل بیشتری داشته باشند، گزینههای پیشرفتهتر در دسترس است. سفارش محدود، معاملات دائمی (perpetuals)، معاملات حاشیهای (margin trading) و موارد دیگر امکانپذیر است. با مبادلهی غیرمتمرکز به نقدینگی جهانی متصل خواهید شد، بازار هرگز بسته نخواهد شد و همواره کنترل داراییتان را در دست خواهید داشت.
-
-وقتی از صرافیهای متمرکز استفاده میکنید مجبور هستید که داراییتان را پیش از معامله به آنها منتقل کنید و برای نگهداری داراییتان به آنها اعتماد کنید. داراییهای شما وقتی به صرافیهای متمرکز منتقل شدهاند در خطر هستند، چون صرافیهای متمرکز اهداف جذابی برای هکرها هستند.
-
-
- مشاهدهی برنامههای غیرمتمرکز معامله
-
-
-
-
-### سبد خود را بزرگ کنید {#investing}
-
-محصولات مدیریت سرمایهای روی اتریوم وجود دارد که سعی میکنند سبد سرمایهای شما را بر اساس راهبرد انتخابیتان بزرگ کنند. این کار بهصورت خودکار انجام میشود، برای همه آزاد است و نیازی به مدیریت انسانی ندارد که بخشی از سود را از آن خود کند.
-
-یک مثال خوب برای این موضوع [صندوق مبتنی بر شاخص DeFi Pulse (DPI)](https://defipulse.com/blog/defi-pulse-index/) است. این صندوق بهطور خودکار در موجودی خود تغییر ایجاد میکند تا مطمئن شود که سبد داراییهای شما همواره شامل بهترین توکنهای DeFi از نظر ارزش بازار است. شما هیچ گاه نیاز به مدیریت هیچ یک از جزییات ندارید و هر زمان بخواهید میتوانید سرمایهی خود را خارج کنید.
-
-
- مشاهدهی برنامههای غیرمتمرکز سرمایهگذاری
-
-
-
-
-### جذب سرمایه برای ایدهها {#crowdfunding}
-
-اتریوم یک پلتفرم ایدهآل برای تأمین مالی جمعی است:
-
-- سرمایهگذاران بالقوه میتوانند از هر جایی باشند – اتریوم و توکنهایش به روی هر کسی در هر جای جهان باز هستند.
-- برای همه شفاف است و در نتیجه سرمایهگذاران میتوانند اثبات کنند که چه قدر سرمایه افزودهاند. حتی میتوانید بررسی کنید که این سرمایهها چگونه و در چه جهتی استفاده میشوند.
-- سرمایهگذاران میتوانند بازگشت سرمایهی خودکار تعیین کنند؛ مثلاً برای زمانی که تا یک مهلت زمانی مشخص، حداقل مبلغ به دست نیامده است.
-
-
- مشاهدهی برنامههای غیرمتمرکز تأمین مالی جمعی
-
-
-#### تأمین مالی درجه دوم {#quadratic-funding}
-
-اتریوم نرمافزاری متنباز است و بخش زیادی از کارهای انجامشده برای آن تاکنون توسط جامعهی آن تأمین مالی شده است. این موضوع باعث رشد مدل جدید و جالبی از جذب سرمایه شد: تأمین مالی درجه دوم. این مدل از پتانسیل بهبود روش تأمین مالی هر نوع عامالمنفعه در آینده برخوردار است.
-
-تأمین مالی درجه دوم اطمینان حاصل میکند پروژههایی که بیشترین سرمایه را جذب میکنند آنهایی باشند که دارای بیشترین تقاضای منحصربهفرد هستند. به عبارت دیگر، پروژههایی که برای بهبود زندگی اکثریت مردم بنا شدهاند. این مدل بهصورت زیر کار میکند:
-
-1. یک استخر تطابقی از سرمایههای اهدایی وجود دارد.
-2. یک دورهی جذب سرمایهی عمومی شروع میشود.
-3. مردم میتوانند تقاضای خود برای یک پروژه را با اهدای مقداری پول مشخص کنند.
-4. زمانی که این دور به پایان رسید، استخر تطابقی بین پروژهها توزیع میشود. پروژههایی که بیشترین تقاضای منحصربهفرد را دارند بیشترین میزان سرمایه را از استخر تطابقی دریافت میکنند.
-
-این بدین معنا است که پروژهی A با 100 اهدای 1 دلاری میتواند سرمایهی بیشتری از پروژهی B با یک اهدای 10,000 دلاری جذب کند (بسته به این که ابعاد استخر تطابقی چه قدر باشد).
-
-
- اطلاعات بیشتر دربارهی تأمین مالی درجه دوم
-
-
-
-
-### بیمه {#insurance}
-
-هدف بیمهی غیرمتمرکز ارزانتر ساختن، سریعتر شدن فرایند پرداخت و شفافیت بیشتر صنعت بیمه است. با خودکارسازی بیشتر، پوشش مالی به صرفهتر و پرداختها بسیار سریعتر خواهند بود. اطلاعاتی که برای تصمیمگیری دربارهی ادعای دریافت خسارت شما استفاده میشوند کاملاً شفاف هستند.
-
-محصولات اتریوم، همچون هر نرمافزار دیگر، ممکن است دچار باگ یا مشکل شوند. بنابراین اکنون محصول بیمهای بسیار زیادی در این فضا روی محافظت از کاربرانشان در برابر از دست دادن سرمایه تمرکز دارند. با این حال، پروژههایی وجود دارند که برای پوشش تمام خطرات مربوط به زندگی اجرا میشوند. یک مثال خوب، پوشش Etherisc's Crop است که هدفش [ محافظت از مالکان مزارع کوچک در کنیا در مقابل خشکی و سیل](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc) است. بیمهی غیرمتمرکز میتواند بهنسبت بیمهی سنتی، پوشش ارزانتری به کشاورزان ارائه دهد.
-
-
- مشاهدهی برنامههای غیرمتمرکز بیمهای
-
-
-
-
-### تجمیعکنندگان و سبدگردانان {#aggregators}
-
-با در نظر گرفتن همهی این مسائل، شما به راهی نیاز دارید که بتوانید بر همهی سرمایهگذاریهایتان، وامهایتان و معاملاتتان نظارت داشته باشید. محصولاتی وجود دارند که به شما امکان میدهند بتوانید از یکجا بر همهی فعالیتهای DeFiتان نظارت کنید. این زیبایی مهندسی باز DeFi است. تیمها میتوانند رابطهای کاربریای بسازند که نهتنها بتوانید موجودی حسابهایتان را از طریق آنها ببینید، بلکه بتوانید از ویژگیهای آنها نیز بهره ببرید. شاید وقتی در دنیای DeFi بیشتر کاوش کردید، این ویژگی را کارگشا بیابید.
-
-
- مشاهدهی برنامههای غیرمتمرکز سبدگردانی
-
-
-
-
-## DeFi چگونه کار میکند؟ {#how-defi-works}
-
-DeFi از ارزهای رمزنگاری شده و قرارداد هوشمند استفاده میکند تا خدماتی را بدون حضور میانجی ارائه دهد. در دنیای مالی امروز، نهادهای مالی به عنوان تضمینکننده های تراکنش ها ایفای نقش میکنند. این موضوع به این نهادها قدرت بسیار زیادی میدهد، چرا که پول شما از دل آنها میگذرد. بهعلاوه، میلیاردها انسان در سراسر جهان حتی نمیتوانند حساب بانکی داشته باشند.
-
-در DeFi یک قرارداد هوشمند جایگزین نهادهای مالی در تراکنشها میشود. قرارداد هوشمند نوعی حساب اتریوم است که میتواند سرمایه را در خود نگهداری کند و آن را در شرایط خاصی به شخصی بفرستد یا مسترد کند. هیچکس نمیتواند وقتی قرارداد هوشمند در حال کار است آن را تغییر دهد – این قرارداد همواره به شکلی که برنامهنویسی شده کار خواهد کرد.
-
-یک قرارداد که برای واریز مقرری یا پول توجیبی طراحی شده است، میتواند به گونهای برنامهنویسی شود که هر جمعه از حساب A به حساب B پول واریز کند. و این کار را تا زمانی انجام خواهد داد که حساب A پول کافی داشته باشد. هیچکس نمیتواند قرارداد را تغییر دهد و حساب C را بهعنوان گیرنده اضافه کند تا پول بدزدد.
-
-بهعلاوه، قراردادها برای همه عمومی هستند تا هر کسی بتوانند آنها را بررسی و امنیتسنجی کند. این بدین معنا است که قراردادهای بد اغلب خیلی زود مورد بررسی موشکافانهی جامعه قرار میگیرند.
-
-این به این معنا است که در حال حاضر باید به افرادی که در جامعهی اتریوم فنیتر هستند و میتوانند کدها را بخوانند، بیشتر اعتماد کنیم. جامعهی مبتنی بر متنباز کمک میکند که توسعهدهندگان تحتنظر باقی بمانند، اما وقتی قراردادهای هوشمند راحتتر قابلخواندن شوند و راههای دیگری برای سنجش اعتبار لازم کدها توسعه دادهشوند، این نیاز از بین خواهد رفت.
-
-## اتریوم و DeFi {#ethereum-and-defi}
-
-به چند دلیل، اتریوم زیربنایی عالی برای DeFi است:
-
-- هیچکس مالک اتریوم یا قراردادهای هوشمند روی آن نیست – این موضوع، فرصت استفاده از DeFi را در اختیار همه قرار میدهد. این موضوع همچنین به این معنا است که کسی نمیتواند قوانین را برای شخص شما عوض کند.
-- محصولات DeFi همگی یک زبان مشترک در پشتصحنه دارند: اتریوم. این بدان معناست که بسیاری از محصولات در کنار هم و با هم کار میکنند. شما می توانید توکنها را در یک پلتفرم قرض دهید و توکنهای سودتان را در یک بازار متفاوت در یک برنامهی کاملاً متفاوت مبادله کنید. چیزی شبیه نقد کردن امتیازات باشگاه مشتریان در بانک محلیتان.
-- توکنها و ارزهای رمزنگاریشده درون اتریوم که یک دفتر کل اشتراکی است قرار گرفتهاند – نگهداری از تراکنشها و تملکها کار اتریوم است.
-- اتریوم آزادی کامل مالی را در اختیار شما قرار میدهد – بیشتر محصولات هرگز کنترل سرمایهی شما را به دست نمیگیرند و کنترل آن بهطور کامل در اختیار شما خواهد بود.
-
-میتوانید DeFi را در قالب چند لایه در نظر بگیرید:
-
-1. زنجیرهی بلوکی – اتریوم شامل تاریخچهی تراکنشها و وضعیت حسابها است.
-2. داراییها – [اتر (ETH)](/eth/) و دیگر توکنها (ارزها).
-3. پروتکلها – [قراردادهای هوشمندی](/glossary/#smart-contract) که عملکرد را امکانپذیر میکنند؛ مثلاً خدمتی که امکان قرض دادن داراییها را به صورت غیرمتمرکز فراهم میکند.
-4. [برنامههای کاربردی](/dapps/) – محصولاتی که برای مدیریت و دسترسی به پروتکلها استفاده میکنیم.
-
-توجه: بیشتر دیفای از [استاندارد ERC-20](/glossary/#erc-20) استفاده میکنند. اپلیکیشنها در دیفای از یک ارز همسان برای اتر به نام رپد اتر (WETH) استفاده میکنند. [درباره رپد اتر بیشتر بدانید](/wrapped-eth).
-
-## DeFi را بسازید {#build-defi}
-
-DeFi یک جنبش متنباز است. پروتکلها و برنامههای کاربردی DeFi همگی به روی شما باز هستند تا آنها را بررسی کنید، فورک کنید، و روی آنها خلاقیت به خرج دهید. به دلیل این ساختار لایهای (که همگی از زنجیرهی بلوکی و داراییهای پایه یکسان استفاده میکنند)، پروتکلها میتوانند با یکدیگر ترکیب شده و تطبیق دادهشوند تا فرصتهای ترکیبی منحصربهفردی را ایجاد کنند.
-
-
- اطلاعات بیشتر دربارهی ساختن برنامههای غیرمتمرکز
-
-
-## بیشتر بخوانید {#further-reading}
-
-### دادههای DeFi {#defi-data}
-
-- [DeFi Prime](https://defiprime.com/)
-- [DeFi Llama](https://defillama.com/)
-
-### مقالههای DeFi {#defi-articles}
-
-- [راهنمای امور مالی غیرمتمرکز (DeFi) برای مبتدیان](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu، تاریخ 6 ژانویه 2020_
-
-### ویدیوها {#videos}
-
-- [Finematics - decentralized finance education](https://finematics.com/) – _ویدیوهایی دربارهی DeFi_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _مقدمات DeFi: هر آنچه لازم است برای شروع در این فضای کمابیش گیجکننده بدانید._
-- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _DeFi چیست؟_
-
-### جوامع {#communities}
-
-- [سرور دیسکورد DeFi Llama](https://discord.defillama.com/)
-- [سرور دیسکورد DeFi Pulse](https://discord.gg/Gx4TCTk)
diff --git a/public/content/translations/fa/06) Use Cases/smart-contracts/index.md b/public/content/translations/fa/06) Use Cases/smart-contracts/index.md
deleted file mode 100644
index f1914381563..00000000000
--- a/public/content/translations/fa/06) Use Cases/smart-contracts/index.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: قراردادهای هوشمند
-description: یک مقدمهی غیرفنی بر قراردادهای هوشمند
-lang: fa
----
-
-# مقدمهای بر قراردادهای هوشمند {#introduction-to-smart-contracts}
-
-قرارداد های هوشمند بنیادیترین اجزای سازنده لایه اپلیکیشن اتریوم هستند. آن ها برنامه های کامپیوتری دخیره شده بر روی بستر [بلاکچین](/glossary/#blockchain) هستند که از منطق "اگر این بنابراین آن" پیروی می کنند و تضمین می شود که بر اساس قوانین تعریف شده از سوی کد آن اجرا شوند و زمانی که ایجاد شدند دیگر قابل تغییر نخواهند بود.
-
-نیک سابو برای اولین بار آنها را «قرارداد هوشمند» نامید. او در سال 1994 اینگونه نوشت [مقدمه ای بر مفهوم قرارداد های هوشمند](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html)، و در 1996 نوشت [کاوشی بر آنچه قرارداد های هوشمند می توانند انجام دهند](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html).
-
-سابو یک بازار دیجیتال را متصور بود که در آن فرایندهای [رمزنگارانه ایمن](/glossary/#cryptography) و خودکار امکان انجام معاملات و عملکردهای تجاری را بدون نیاز به واسطههای مورد اعتماد فراهم میکنند. قراردادهای هوشمند در اتریوم به این تجسم جامه عمل میپوشانند.
-
-Watch Finematics قراردادهای هوشمند را توضیح میدهد:
-
-
-
-## اعتماد در قراردادهای متعارف {#trust-and-contracts}
-
-یکی از بزرگترین مشکلات قراردادهای سنتی، نیاز به افراد مورد اعتماد برای پیگیری نتایج قرارداد است.
-
-بهعنوان مثال:
-
-آلیس و باب مسابقه دوچرخهسواری دارند. فرض کنید آلیس با باب 10 دلار شرط میبندد که در مسابقه برنده خواهد شد. باب مطمئن است که برنده خواهد بود و با شرط بندی موافقت می کند. در پایان، آلیس مسابقه را خیلی جلوتر از باب به پایان میرساند و مشخصاً برنده میشود. اما باب از پرداخت مبلغ شرطبندی امتناع میکند و ادعا میکند که آلیس حتماً تقلب کرده است.
-
-این مثال احمقانه، مشکل هر نوع توافق غیرهوشمند را نشان میدهد. حتی اگر شرایط توافق برآورده شود (یعنی شما برنده مسابقه شده باشید)، همچنان باید به شخص دیگری برای اجرای توافق اعتماد کنید (یعنی پرداخت مبلغ شرطبندی).
-
-## یک دستگاه فروش دیجیتال {#vending-machine}
-
-یک مثال ساده برای قرارداد هوشمند، دستگاه فروش خودکار است که تا حدودی شبیه به قرارداد هوشمند عمل میکند - ورودیهای خاص خروجیهای از پیش تعیین شده را تضمین میکنند.
-
-- شما یک محصول را انتخاب میکنید
-- دستگاه فروش خودکار قیمت را نشان می دهد
-- شما بهای آن را پرداخت می کنید
-- دستگاه فروش خودکار تایید می کند که شما مبلغ درستی را پرداخت کرده اید
-- وندینگ ماشین جنس را به شما می دهد
-
-دستگاه فروش خودکار فقط پس از برآورده شدن تمام الزامات، محصول مورد نظر را به شما میدهد. اگر محصولی را انتخاب نکنید یا پول کافی پرداخت نکنید، دستگاه فروش خودکار محصول را به شما تحویل نمیدهد.
-
-## اجرای خودکار {#automation}
-
-مزیت اصلی قراردادهوشمند این است که زمانی که شرایط مشخص موجود باشد، کد دستوری واضح و غیر مبهم را به طور قطعی اجرا می کند. نیازی نیست منتظر ماند تا انسان نتیجه را تفسیر یا راجع به آن مذاکره کند. این امر، نیاز به واسطه قابل اعتماد را از بین میبرد.
-
-بهعنوان مثال، میتوانید یک قرارداد هوشمند بنویسید که مبلغی را برای یک کودک نزد شخص ثالث نگه دارد و به او اجازه دهد پس از یک تاریخ خاص مبلغ را برداشت کند. اگر سعی کند وجه را قبل از تاریخ مشخص شده برداشت کند، قرارداد هوشمند اجرا نمیشود. یا میتوانید قراردادی بنویسید که نسخهی دیجیتالی سند خودرو را هنگام پرداخت قیمت معامله به فروشنده بهطور خودکار به شما بدهد.
-
-## نتایج قابل پیشبینی {#predictability}
-
-قراردادهای سنتی مبهم هستند زیرا تفسیر و اجرای آنها به عهده انسان است. برای مثال، دو قاضی ممکن است تفسیر متفاوتی از یک قرارداد یکسان داشته باشند،که میتواند منجر به تصمیمات ناسازگار و نتیجه نهایی نابرابر شود. قراردادهای هوشمند این احتمال را از بین میبرند. در عوض، قراردادهای هوشمند دقیقاً بر اساس شرایط نوشته شده در کد قرارداد اجرا میشوند. این دقت به این معنی است که در شرایط یکسان، قرارداد هوشمند نتیجه یکسان را به همراه خواهد داشت.
-
-## سابقه عمومی {#public-record}
-
-قراردادهای هوشمند برای حسابرسی و ردیابی مفید هستند. از آنجایی که قراردادهای هوشمند اتریوم بر روی یک بلاکچین عمومی قرار دارند، هر کس میتواند فوراً انتقال داراییها و سایر اطلاعات مرتبط را ردیابی کند. برای مثال، شما میتوانید چک کنید که آیا کسی به آدرس شما پول فرستاده است یا نه.
-
-## حفاظت از حریم خصوصی {#privacy-protection}
-
-قراردادهای هوشمند همچنین میتوانند از حریم خصوصی شما محافظت کنند. از آنجا که اتریوم یک شبکه مستعار است (تراکنشهای شما بهصورت عمومی به یک آدرس رمزنگاری منحصربهفرد مرتبط هستند، نه هویت شما)، میتوانید از حریم خصوصی خود در برابر ناظران محافظت کنید.
-
-## قوانین مشخص {#visible-terms}
-
-در نهایت، مانند قراردادهای سنتی، شما قبل از امضای قرارداد هوشمند (یا هر نوع تعامل دیگر با آن) میتوانید محتوای آن را بررسی نمایید. بخاطر شفافیت قراردادهای هوشمند میتوان آنها را موشکافانه بررسی کرد.
-
-## کاربردهای قراردادهای هوشمند {#use-cases}
-
-قراردادهای هوشمند اصولاً قادرند هر کاری را که توسط نرمافزارهای رایانهای قابل انجام است انجام دهند.
-
-آنها میتوانند محاسبات، ایجاد ارز، ذخیره کردن داده، ضرب کردن [NFTها](/glossary/#nft)، ایجاد ارتباط و حتی تولید گرافیک را انجام دهند. در ادامه چند مثال معمول از دنیای واقعی آورده شده است:
-
-- [پایدارزها](/stablecoins/)
-- [ایجاد و توزیع داراییهای یکتای دیجیتال](/nft/)
-- [یک صرافی خودکار و باز یکاهای پولی](/get-eth/#dex)
-- [بازی کردن غیرمتمرکز](/dapps/?category=gaming#explore)
-- [یک بیمهنامه که بهصورت خودکار پرداخت میکند.](https://etherisc.com/)
-- [استانداردی که به افراد امکان میدهد ارزهای سفارشیشده و قابل تعامل ایجاد کنند](/developers/docs/standards/tokens/)
-
-## بیشتر بخوانید {#further-reading}
-
-- [چگونه قراردادهای هوشمند دنیا را تغییر خواهند داد](https://www.youtube.com/watch?v=pA6CGuXEKtQ)
-- [قردادهای هوشمند: فناوری زنجیرهی بلوکی که جایگزین وکلا خواهد شد](https://blockgeeks.com/guides/smart-contracts/)
-- [قراردادهای هوشمند برای توسعهدهندگان](/developers/docs/smart-contracts/)
-- [نحوهی نوشتن قراردادهای هوشمند را بیاموزید](/developers/learning-tools/)
-- [تبحر در اتریوم: یک قرارداد هوشمند چیست؟](https://github.com/ethereumbook/ethereumbook/blob/develop/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract)
diff --git a/public/content/translations/fa/06) Use Cases/web3/index.md b/public/content/translations/fa/06) Use Cases/web3/index.md
deleted file mode 100644
index 5da8790eb68..00000000000
--- a/public/content/translations/fa/06) Use Cases/web3/index.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-title: وب 3 چیست و چرا اهمیت دارد?
-description: مقدمهای بر Web3- تکامل بعدی اینترنت - و چرایی اهمیت آن.
-lang: fa
----
-
-# مقدمه ای بر وب 3 {#introduction}
-
-متمرکزسازی به فراهمسازی امکان حضور میلیاردها نفر در اینترنت کمک کرده است و زیرساخت پایدار و مستحکمی را ایجاد کرده است که بر بستر آن بنا شده است. در عین حال، تعداد انگشتشماری از نهادهای متمرکز کنترل بخشهای وسیعی از اینترنت را در دست دارند و به طور یکجانبه تصمیم میگیرند که چه چیزی باید مجاز باشد و چه چیزی نباید مجاز باشد.
-
-وب 3 پاسخی به این معضل است. به جای شبکهای که در انحصار شرکتهای بزرگ فناوری است، Web3 از تمرکززدایی استقبال میکند و توسط کاربرانش ساخته میشود، گردانده میشود و تحت مالکیت آنها است. وب 3 قدرت را بهجای شرکتها در دست افراد قرار میدهد. قبل از اینکه در مورد وب 3 صحبت کنیم، بیایید ببینیم که چطور به اینجا رسیدیم.
-
-
-
-## وب اولیه {#early-internet}
-
-بیشتر مردم اینترنت را چیزی تصور میکنند که همیشه همراه زندگی مدرن بوده است – اینترنت اختراع شد و از آن زمان تاکنون وجود داشته است. با این حال، اینترنتی که امروزه میشناسیم کاملاً متفاوت از تصور اولیه است. برای درک بهتر این موضوع، خوب است که تاریخچه کوتاه اینترنت را به دورههای کوچکتر تقسیم کنیم - وب 1.0 و وب 2.0.
-
-### وب 1.0: صرفاً خواندنی (2004-1990) {#web1}
-
-در سال 1989، در سرن، ژنو، تیم برنرز-لی مشغول توسعه پروتکلهایی بود که به اینترنت تبدیل شدند. ایدهی او چه بود؟ برای ایجاد پروتکلهای باز و غیرمتمرکز که امکان اشتراکگذاری اطلاعات را از هر نقطه روی زمین فراهم میکند.
-
-پیدایش اولیه اینترنت که اکنون با نام «وب 1.0» شناخته میشود، تقریباً بین سالهای 1990 تا 2004 رخ داد. وب 1.0 عمدتاً وبسایتهای ثابت متعلق به شرکتها بود و تقریباً هیچ تعاملی بین کاربران - افرادی که به ندرت محتوا تولید میکردند- وجود نداشت، که باعث شد بهعنوان وبِ صرفاً خواندنی شناخته شود.
-
-![معماری سرویسگیرنده-سرور، نشاندهندهی وب 1.0](./web1.png)
-
-### وب 2.0: خواندنی-نوشتنی (از 2004 تاکنون) {#web2}
-
-دورهی وب 2.0 در سال 2004 با ظهور پلتفرمهای رسانههای اجتماعی آغاز شد. برخلاف صرفاً خواندنی بودن، وب به شکل خواندنی-نوشتنی تکامل یافت. شرکتها در کنار ارائهی محتوا به کاربران، شروع به ارائهی پلتفرمهایی برای اشتراکگذاری محتوای تولید شده توسط کاربران و تعامل کاربر با کاربر کردند. با ورود افراد بیشتری به اینترنت، تعداد انگشتشماری از شرکتهای برتر شروع به کنترل مقدار بسیار زیادی از ترافیک و ارزش تولید شده در وب کردند. وب 2.0 همچنین مدل درآمد مبتنی بر تبلیغات را ایجاد کرد. کاربران میتوانستند محتوا ایجاد کنند، اما مالک آن نبودند یا از درآمدزایی آن سود نمیبردند.
-
-![معماری سرویسگیرنده-سرور، نشاندهندهی وب 2.0](./web2.png)
-
-
-
-## وب 3.0: خواندنی-نوشتنی-داشتنی {#web3}
-
-مفهوم «وب 3.0» توسط گاوین وود، یکی از بنیانگذاران [اتریوم](/what-is-ethereum/) اندکی پس از راهاندازی اتریوم در سال 2014 ابداع شد. گاوین راهحلی را برای مشکلی که بسیاری از پذیرندگان اولیه رمزارزها احساس میکردند به زبان آورد: وب بیش از حد به اعتماد کردن نیاز داشت. به عبارت دیگر، بیشتر فضای اینترنتی که امروزه مردم میشناسند و از آن استفاده میکنند، متکی به اعتماد به تعداد انگشتشماری از شرکتهای خصوصی است تا در راستای منافع عمومی عمل کنند.
-
-![معماری گرهی غیرمتمرکز، نشاندهندهی وب 3](./web3.png)
-
-### وب 3 چیست؟ {#what-is-web3}
-
-وب 3 بدل به یک اصطلاح کلی برای چشمانداز اینترنت جدید و بهتر شده است. وب 3 در هستهی خود از زنجیرهی بلوکی، ارزهای دیجیتال و توکنهای غیرقابل معاوضه برای بازگرداندن قدرت به کاربران در قالب مالکیت استفاده میکند. [مطلبی که یک کاربر در سال 2020 در توییتر نوشته شده بود](https://twitter.com/j1mmyeth/status/1459003044067258370) به بهترین نحو این موضوع را بیان میکند: وب 1 فقط خواندنی بود، وب 2 خواندنی/نوشتنی؛ وب 3 خواندنی/ نوشتنی/داشتنی خواهد بود.
-
-#### ایدههای اصلی وب 3 {#core-ideas}
-
-اگرچه ارائه یک تعریف دقیق از چیستی وب 3 چالش برانگیز است، اما چند اصل بنیادین در ساخت آن ایفای نقش میکنند.
-
-- **وب 3 غیرمتمرکز است:** بهجای اینکه بخشهای وسیعی از اینترنت تحت کنترل و مالکیت نهادهای متمرکز باشد، مالکیت بین سازندگان و کاربران آن توزیع میشود.
-- **وب 3 بدون مجوز است:** همه دسترسی یکسانی برای شرکت در وب 3 دارند و هیچکس مستثنی نمیشود.
-- **وب 3 پرداختهای بومی دارد:** از ارز دیجیتال برای خرج کردن و ارسال پول آنلاین بهجای تکیه بر زیرساختهای قدیمی بانکها و پردازشگرهای پرداخت استفاده میکند.
-- **وب 3 بینیاز از اعتماد کردن است:** وب 3 از مشوقها و سازوکارهای اقتصادی به جای تکیه بر اشخاص ثالث قابل اعتماد استفاده میکند.
-
-### چرا وب 3 مهم است؟ {#why-is-web3-important}
-
-اگرچه ویژگیهای برتر وب 3 مجزا نیستند و در دستهبندیهای منظمی قرار نمیگیرند، برای سادگی، سعی کردهایم آنها را از هم جدا کنیم تا درک آنها آسانتر شود.
-
-#### مالکیت {#ownership}
-
-وب 3 مالکیت داراییهای دیجیتال خود را به روشی بیسابقه به شما میدهد. بهعنوان مثال، فرض کنیم که در حال انجام یک بازی وب 2 هستید. اگر یک آیتم درون بازی خریداری کنید، مستقیماً به حساب شما مرتبط خواهد بود. اگر سازندگان بازی حساب کاربری شما را حذف کنند، این موارد را از دست خواهید داد. یا اگر بازی را متوقف کنید، ارزشی را که روی آیتمهای درون بازی خود سرمایهگذاری کردهاید از دست میدهید.
-
-Web3 امکان مالکیت مستقیم را از طریق [توکنهای غیرقابل معاوضه (NFTها)](/glossary/#nft) فراهم می کند. هیچکس، حتی سازندگان بازی، قدرت سلب مالکیت شما را ندارند. و اگر بازی را متوقف کنید، میتوانید آیتمهای درون بازی خود را در بازارهای آزاد بفروشید یا معامله کنید و ارزش آنها را بازپس بگیرید.
-
-
- دربارهی NFTها بیشتر بدانید
-
- اطلاعات بیشتر درباره NTFها
-
-
-
-#### مقاومت در برابر سانسور {#censorship-resistance}
-
-سازوکار قدرت بین پلتفرمها و سازندگان محتوا به شدت نامتعادل است.
-
-OnlyFans یک سایت محتوای ویژهی بزرگسالان است که توسط کاربران تولید میشود و بیش از 1 میلیون سازنده محتوا دارد که بسیاری از آنها از این پلتفرم بهعنوان منبع درآمد اصلی خود استفاده میکنند. در آگوست 2021، OnlyFans برنامههایی را برای ممنوعیت محتوای جنسی آشکار اعلام کرد. این اعلامیه خشم سازندگان روی پلتفرم را برانگیخت، زیرا احساس کردند درآمدشان از پلتفرمی که به ایجاد آن کمک کردهاند از دست میرود. پس از واکنش شدید، این تصمیم به سرعت پس گرفته شد. علیرغم اینکه سازندگان در این نبرد پیروز شدند، مشکلی را برای سازندگان وب 2.0 برجسته میکند: اگر پلتفرمی را ترک کنید، شهرت و دنبالکنندگان را از دست میدهید.
-
-در وب 3، داده های شما روی زنجیرهی بلوکی قرار دارند. هنگامی که تصمیم به ترک یک پلتفرم میگیرید، میتوانید شهرت خود را همراه خود ببرید و آن را به رابط دیگری متصل کنید که با ارزشهای شما همسوتر است.
-
-وب 2.0 از سازندگان محتوا میخواهد که به پلتفرمها اعتماد کنند تا قوانین را تغییر ندهند، اما مقاومت در برابر سانسور ویژگی اصلی یک پلتفرم وب 3 است.
-
-#### سازمانهای خودمختار غیرمتمرکز (DAOها) {#daos}
-
-علاوه بر مالکیت دادههای خود در Web3، میتوانید با استفاده از توکنهایی که مانند سهام یک شرکت عمل میکنند، پلتفرم را به عنوان یک گروه در اختیار داشته باشید. DAO به شما امکان می دهد مالکیت غیرمتمرکز یک پلتفرم را هماهنگ کنید و در مورد آینده آن تصمیم بگیرید.
-
-DAOها از نظر فنی با عنوان [قراردادهای هوشمند](/glossary/#smart-contract) توافق شده تعریف میشوند که تصمیمگیری غیرمتمرکز را بر روی مجموعهای از منابع (توکنها)، خودکار میکنند. کاربران دارای توکن در مورد نحوه مصرف منابع رای می دهند و کد به طور خودکار نتیجه رایگیری را اجرا میکند.
-
-با این حال، مردم، بسیاری از جوامع Web3 را به عنوان DAO تعریف می کنند. همه این جوامع، سطوح مختلفی از تمرکززدایی و اتوماسیون با کد دارند. در حال حاضر، ما در حال بررسی این هستیم که DAO چیست و چگونه ممکن است در آینده تکامل یابد.
-
-
- درباره DAO ها بیشتر بیاموزید
-
- اطلاعات بیشتر درباره DAO ها
-
-
-
-### هویت {#identity}
-
-بهطور سنتی، شما در هر پلتفرمی که استفاده میکنید یک حساب کاربری میسازید. برای مثال، ممکن است یک حساب توییتر، یک حساب یوتیوب و یک حساب ردیت داشته باشید. میخواهید نام نمایشدادهشده یا تصویر نمایه خود را تغییر دهید؟ باید این کار را برای هر حساب انجام دهید. در برخی موارد میتوانید از حسابهای خود در شبکههای اجتماعی برای ورود استفاده کنید، اما این موضوع یک مشکل آشنا را به همراه دارد - سانسور. با یک کلیک، این پلتفرمها میتوانند شما را از کل زندگی آنلاینتان محروم کنند. حتی بدتر از آن، بسیاری از پلتفرمها از شما میخواهند که برای ایجاد یک حساب کاربری به آنها اعتماد کنید و اطلاعات هویتی خود را در اختیارشان قرار دهید.
-
-Web3 با اجازه دادن به شما برای کنترل هویت دیجیتال خود از طریق یک آدرس اتریوم و پروفایل [Ethereum Name Service (ENS)](/glossary/#ens) این مشکلات را حل میکند. استفاده از یک آدرس اتریوم، یک حساب کاربری واحد برای ورود را در سراسر پلتفرم ها فراهم میکند که امن، مقاوم در برابر سانسور و ناشناس است.
-
-### پرداختهای بومی {#native-payments}
-
-زیرساخت پرداخت Web2 به بانکها و پردازشگرهای پرداخت متکی است، به استثنای افرادی که حساب بانکی ندارند یا کسانی که درون مرزهای کشور اشتباهی زندگی میکنند. Web3 از توکنهایی مانند [اتر](/glossary/#ether) برای ارسال مستقیم پول در مرورگر استفاده میکند و به طرف ثالث قابلاعتماد نیاز ندارد.
-
-
- اطلاعات بیشتر دربارهی اتر
-
-
-## محدودیتهای وب 3 {#web3-limitations}
-
-علیرغم مزایای بیشمار Web3 در شکل فعلیاش، هنوز محدودیتهای زیادی وجود دارد که اکوسیستم باید آنها را برطرف کند تا شکوفا شود.
-
-### قابلیت دسترسی {#accessibility}
-
-ویژگیهای مهم Web3، مانند ورود به سیستم با اتریوم، در حال حاضر برای همه بدون هزینه در دسترس است. اما، هزینه نسبی تراکنشها هنوز برای بسیاری گران است. به دلیل کارمزدهای بالای تراکنش، احتمال کمتری وجود دارد که Web3 در کشورهای کمتر ثروتمند و در حال توسعه مورد استفاده قرار گیرد. در اتریوم، این چالشها از طریق پیادهسازی [نقشه راه](/roadmap/) و [راهحلهای مقیاسپذیری لایه 2](/glossary/#layer-2) حل میشوند. این فناوری آماده است، اما ما به سطوح بالاتری از پذیرش در لایه 2 نیاز داریم تا Web3 را برای همه در دسترس قرار دهیم.
-
-### تجربهی کاربری {#user-experience}
-
-موانع فنی برای ورود به استفاده از Web3 در حال حاضر بسیار زیاد است. کاربران باید نگرانیهای امنیتی را درک کنند، اسناد فنی پیچیده را درک کنند و با رابطهای کاربری غیرمعمول کار کنند. [ارائهدهندگان کیف پول](/wallets/find-wallet/)، بهویژه، برای حل این مشکل تلاش میکنند، اما قبل از پذیرش انبوه Web3 به پیشرفت بیشتری نیاز است.
-
-### آموزشی {#education}
-
-Web3 پارادایمهای جدیدی را معرفی میکند که نیازمند یادگیری مدلهای ذهنی متفاوتی نسبت به مدلهای استفاده شده در Web2.0 هستند. هنگامی که Web1.0 در اواخر دهه 1990 رفتهرفته محبوبیت پیدا کرد، نیاز به یادگیری به شکلی مشابه به وجود آمد. طرفداران شبکه جهانی وب از تعداد زیادی تکنیک آموزشی برای آموزش مردم استفاده کردند؛ از استعارههای ساده (بزرگراه اطلاعات، مرورگرها، گشت و گذار در وب) گرفته تا [برنامههای تلویزیونی](https://www.youtube.com/watch?v=SzQLI7BxfYI). Web3 سخت نیست، اما متفاوت است. ابتکارات آموزشی که کاربران Web2 را از این پارادایمهای Web3 آگاه میکند برای موفقیت آن حیاتی هستند.
-
-Ethereum.org از طریق [برنامه ترجمه](/contributing/translation-program/) ما با هدف ترجمه محتوای مهم اتریوم به زبانهای هر چه بیشتر، به آموزش Web3 کمک میکند.
-
-### زیرساخت متمرکز {#centralized-infrastructure}
-
-اکوسیستم Web3 جوان است و به سرعت در حال تکامل است. در نتیجه، در حال حاضر عمدتاً به زیرساختهای متمرکز (گیتهاب، توییتر، دیسکورد و غیره) متکی است. بسیاری از شرکتهای Web3 به سرعت در حال تلاش برای پر کردن این شکافها هستند، اما ایجاد زیرساختهای باکیفیت و قابل اعتماد زمان میبرد.
-
-## آیندهای غیرمتمرکز {#decentralized-future}
-
-Web3 یک اکوسیستم جوان و در حال تکامل است. گاوین وود این اصطلاح را در سال 2014 ابداع کرد، اما بسیاری از این ایدهها به تازگی به واقعیت تبدیل شدهاند. تنها در سال گذشته، افزایش قابلتوجهی در علاقه به ارزهای دیجیتال، بهبود راهحلهای مقیاسپذیری لایه 2، آزمایشهای عظیم با اشکال جدید حاکمیت و انقلابهایی در هویت دیجیتال وجود داشته است.
-
-ما تنها در ابتدای ایجاد وب بهتر با Web3 هستیم، اما با ادامه بهبود زیرساختهایی که از آن پشتیبانی میکند، آینده اینترنت روشن به نظر میرسد.
-
-## چطور میتوانم مشارکت کنم {#get-involved}
-
-- [یک کیف پول بگیرید](/wallets/)
-- [افزودن جامعه](/community/)
-- [برنامههای وب 3 را کاوش کنید](/dapps/)
-- [پیوستن به یک DAO](/dao/)
-- [ساختن در وب 3](/developers/)
-
-## بیشتر بخوانید {#further-reading}
-
-Web3 تعریف سفت و محکمی ندارد. شرکتکنندگان مختلف جامعه، دیدگاههای متفاوتی در مورد آن دارند. چند نمونه از آنها در ادامه ذکر شده است:
-
-- [وب 3 چیست؟ توضیح تعامل غیرمتمرکز آینده](https://www.freecodecamp.org/news/what-is-web3/) – _نادر دبیت_
-- [درک وب 3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _ جاش استارک_
-- [چرا وب 3 مهم است](https://future.a16z.com/why-web3-matters/) – _کریس دیکسون_
-- [چرا تمرکززدایی مهم است](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) - _کریس دیکسون_
-- [فضای وب 3](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_
-- [بحث وب ۳](https://www.notboring.co/p/the-web3-debate?s=r) - _پکی مککورمیک_
-
-
diff --git a/public/content/translations/fa/07) Staking Pages/staking/dvt/index.md b/public/content/translations/fa/07) Staking Pages/staking/dvt/index.md
deleted file mode 100644
index 80b81f13a7c..00000000000
--- a/public/content/translations/fa/07) Staking Pages/staking/dvt/index.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: فناوری اعتبارسنج توزیعشده
-description: فناوری اعتبارسنج توزیع شده عملیات توزیع شده یک اعتبارسنج اتریوم را توسط چندین شخص فعال می کند.
-lang: fa
----
-
-# فناوری اعتبارسنج توزیعشده {#distributed-validator-technology}
-
-فناوری اعتبارسنج توزیعشده (DVT) یک روش امنیتبخشی به اعتبارسنج است که وظایف مدیریت کلیدها و امضای دیجیتال را در میان طرفهای چندگانه پخش میکند تا از نقاط شکست واحد بکاهد و انعطاف اعتبارسنج را افزایش دهد.
-
-این کار را با **تقسیم کلید خصوصی** مورد استفاده برای امنیت اعتبارسنج **بین تعداد زیادی کامپیوتر** که در یک «خوشه» سازماندهی شدهاند، انجام میدهد. مزیت این فناوری در این است که دستیابی به کلید را برای هکرها بسیار دشوار میکند زیرا کلید به شکل کامل روی یک دستگاه واحد ذخیره نمیشود. همچنین اجازه میدهد که برخی از گرهها آفلاین باشند به این علت که امضاهای لازم میتوانند توسط زیرمجموعهای از گرهها در هر خوشه انجام شوند. این امر، نقاط شکست واحد در شبکه را کاهش میدهد و کل مجموعۀ اعتبارسنج را مستحکمتر میسازد.
-
-![نمودار نشان میدهد چگونه یک کلید اعتبارسنج به تکهکلیدها تقسیم میشود و به چندین گره با اجزای گوناگون توزیع میشود.](./dvt-cluster.png)
-
-## چرا به فناوری اعتبارسنج توزیعشده نیاز داریم؟ {#why-do-we-need-dvt}
-
-### ایمنی {#security}
-
-اعتبارسنجها دو جفت کلید عمومی- خصوصی میسازند: کلیدهای اعتبارسنجی برای مشارکت در اجماع و کلیدهای برداشت برای دسترسی به وجوه. در حالی که اعتبارسنجها میتوانند با ذخیرهسازی سرد از امنیت کلیدهای برداشت اطمینان حاصل کنند، کلیدهای اعتبارسنجی باید به صورت 24/7 آنلاین باشند. در صورتی که یک کلید اعتبارسنج معیوب باشد، مهاجم میتواند کنترل گره اعتبارسنج را به دست گیرد و احتمال اسلشینگ یا از دست رفتن اتر سهامگذار افزایش مییابد. فناوری اعتبارسنج توزیعشده به حذف این ریسک کمک میکند. به این شکل:
-
-با استفاده از فناوری اعتبارسنج توزیعشده، سهامگذار ان میتوانند همزمان با نگهداری کلید خصوصی اعتبارسنج در ذخیرهسازی سرد، در فرایند سهامگذاری مشارکت کنند. این امکان با رمزگذاری کلید اعتبارسنج اصلی و کامل و سپس تقسیم آن به چندین تکه کلید میسر میشود. تکهکلیدها همیشه آنلاین هستند و بین چندین نود که عملیات توزیع شده را برای اعتبارسنج فعال میکنند توزیع میشوند. این امر امکان پذیر است زیرا اعتبارسنجهای اتریوم از امضاهای BLS که افزودنی هستند استفاده میکنند، بدین معنا که کلید کامل را میتوان بوسیله جمع کردن اجزای آنها بازسازی کرد. همین موضوع به سهامگذاران اجازه میدهد تا کلید اعتبارسنج کامل و اصلی را به شکلی امن به صورت آفلاین نگهداری کنند.
-
-### عدم وجود نقطه شکست واحد {#no-single-point-of-failure}
-
-وقتی یک اعتبارسنج بین چندین اپراتور و چندین دستگاه تقسیم میشود میتواند اختلالات نرمافزاری و سختافزاری را بدون این که وقفهای در فعالیت آن ایجاد شود، تحمل کند. همچنین ریسک اختلالات با استفاده از تنظیمات نرمافزاری و سختافزاری متنوع در سطح گرههای موجود در یک خوشه کم شود. این انعطاف در تنظیمات اعتبارسنج تکگرهای موجود نیست و با لایه فناوری اعتبارسنج توزیعشده امکانپذیر است.
-
-اگر یکی از عناصر یک دستگاه در یک خوشه به هر دلیل متوقف شود (برای مثال اگر چهار اپراتور در یک اعتبارسنج باشند و یکی از آنها از کاربری استفاده کند که دچار مشکل است)، سایر اعضای خوشه تضمین خواهند کرد که اعتبارسنجی بدون مشکل ادامه یابد.
-
-### غیرمتمرکزسازی {#decentralization}
-
-سناریوی ایدهآل برای شبکۀ اتریوم داشتن بیشترین تعداد گره اعتبارسنج مستقل است. به هر حال، تعداد محدودی از سهامگذاران بسیار محبوب شدهاند و بخش قابل توجهی از کل توکنهای اتر سهامگذاری شده در شبکه را شامل میشوند. DVT میتواند به این اپراتورها اجازه دهد همزمان با غیرمتمرکز بودنِ سهامگذاری، به قوت خود باقی بمانند. به این دلیل میتوان گفت که کلیدها برای هر اعتبارسنج در سطح دستگاههای متعدد توزیع میشوند و تبانی بیشتری میطلبد تا یک اعتبارسنج به یک عامل زیانآور تبدیل شود.
-
-بدون DVT، برای سهامگذاران آسانتر است که تنها از یک یا دو پیکربندی برای تمام اعتبارسنجهای خود استفاده کنند، همین موضوع اثر اشکالات کاربر را تشدید میکند. DVT میتواند به کار گرفته شود تا ریسک را در سطح تعداد زیادی پیکربندی کاربر و سختافزار مختلف پخش کند و از طریق تنوعبخشی به ارتقای انعطاف کمک کند.
-
-**DVT این مزایا را به شبکه اتریوم عرضه میکند:**
-
-1. **غیر متمرکز کردن** اجماع اثبات سهام اتریوم
-2. اطمینان از **سرزندگی** شبکه
-3. ایجاد **تحمل نقص** برای اعتبارسنج
-4. عملیات اعتبارسنج با **حداقل اعتماد**
-5. **حداقل شدن اسلشینگ** و ریسکهای اختلال
-6. **تنوع را بهبود میدهد** (کاربر، مرکز داده، موقعیت، قوانین، غیره)
-7. **ارتقای امنیت** مدیریت کلید اعتبارسنج
-
-## DVT چگونه کار میکند؟ {#how-does-dvt-work}
-
-یک راهحل DVT از این عناصر تشکیل شده است:
-
-- **[اشتراکگذاری رمزی شامیر](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - اعتبارسنجها از [کلیدهای BLS](https://en.wikipedia.org/wiki/BLS_digital_signature) استفاده میکنند. «تکههای کلید» BLS («تکههای کلید») میتوانند در یک کلید واحد (امضا) ترکیب شوند. در DVT، کلید خصوصی اعتبارسنج، متشکل از امضای ترکیبی BLS هر اپراتور در خوشه است.
-- **[طرح امضای آستانه](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** - تعداد تکههای کلید مجزای مورد نیاز برای امضای وظایف را مشخص میکند، برای مثال، 3 از 4.
-- **[تولید کلید توزیع شده (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** - فرایند رمزنگاری که تکهکلیدها را تولید میکند و از آن برای توزیع تکههای یک کلید اعتبارسنج جدید یا موجود به گرههای درون یک خوشه استفاده میشود.
-- **[محاسبه چندجانبه (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** - نسخه کامل کلید اعتبارسنج به صورت مخفیانه با استفاده از محاسبه چندجانبه تولید میشود. هیچکدام از اپراتورها هرگز نسخه کامل کلید را نخواهند دانست - آنها فقط بخشی از آن ("تکه" خودشان) را میدانند.
-- **پروتکل اجماع** - پروتکل اجماع یک گره را انتخاب میکند تا پیشنهاد دهندۀ بلاک باشد. آنها بلوک را با دیگر گرههای درون خوشه که تکهکلیدهایشان را به امضای تجمیعی اضافه میکنند به اشتراک میگذارند. وقتی که تکهکلید به تعداد کافی جمعآوری شد، بلوک به اتریوم پیشنهاد داده میشود.
-
-اعتبارسنجهای توزیع شده تحمل خطای داخلی دارند و میتوانند حتی اگر تعدادی از گرهها آفلاین شوند به کار خود ادامه دهند. این یعنی خوشه منعطف است حتی در حالی که برخی از گرههای داخل آن، مخرب یا تنبل باشند.
-
-## موارد استفاده DVT {#dvt-use-cases}
-
-DVT دستاوردهای برجستهای برای صنعت سهامگذاری گستردهتر دارد:
-
-### سهامگذاران انفرادی {#solo-stakers}
-
-DVT با سهامگذاری غیرحضانتی به شما امکان میدهد کلید اعتبارسنج خود را در سراسر گرههای دورکار توزیع کنید و در عین حال کلید کامل را کاملاً آفلاین نگه دارید. این بدان معناست که سهامگذاران خانگی لزوماً نیازی به هزینه سختافزاری ندارند، درحالیکه توزیع تکهکلیدها میتواند به تقویت آنها در برابر هکهای احتمالی کمک کند.
-
-### سهام گذاری به عنوان یک سرویس (SaaS) {#saas}
-
-اپراتورهایی (مانند استخرهای سهامگذاری و سهامگذاران سازمانی) که اعتبارسنجهای زیادی را مدیریت میکنند میتوانند از DVT برای کاهش ریسک خود استفاده کنند. آنها بوسیله توزیع زیرساخت خود میتوانند تزائد را به عملیاتهایشان اضافه کنند و انواع سختافزاری که استفاده میکنند را تنوع ببخشند.
-
-DVT مسئولیت مدیریت کلید را در بین چندین گره تقسیم میکند، یعنی برخی هزینههای عملیاتی را نیز میتوان تقسیم کرد. DVT همچنین میتواند خطر عملیاتی و هزینههای بیمه را برای ارائهدهندگان سهامگذاری کاهش دهد.
-
-### استخرهای سهامگذاری {#staking-pools}
-
-با توجه به تنظیمات استاندارد اعتبارسنج، استخرهای سهامگذاری و ارائهدهندگان سهامگذاری نقدینگی مجبورند سطوح مختلفی از اعتماد به یک اپراتور را داشته باشند زیرا سود و زیان در سراسر استخر به همه میرسد. آنها همچنین به اپراتورها از جهت محافظت از کلیدهای امضا متکی هستند، زیرا تاکنون هیچ گزینه دیگری برای آنها وجود نداشته است.
-
-حتی اگر به شکل سنتی تلاشهایی برای پخش خطر بهوسیله توزیع سهام بین اپراتورهای متعدد انجام میشود، هر اپراتور هنوز یک سهم قابل توجه را بهطور مستقل مدیریت میکند. اتکا بر یک اپراتور درصورتی که عملکرد ناکافی، مواجهه با خرابی، هک شدن، یا عملکرد مخرب داشته باشند خطرات زیادی را به همراه دارد.
-
-با استفاده از DVT، اعتماد موردنیاز به اپراتورها به حد قابل توجهی کاهش مییابد. **استخرها میتوانند اپراتورها را قادر به نگهداری سهام بدون نیاز به حضانت کلیدهای اعتبارسنج سازند** (زیرا فقط از تکهکلیدها استفاده میشود). همچنین این امکان را میدهد تا سهام مدیریت شده بین اپراتورهای بیشتری توزیع شود (بهعنوان مثال، به جای داشتن یک اپراتور تنها که 1000 اعتبارسنج را مدیریت میکند، DVT این اعتبارسنجها را بهطور جمعی توسط اپراتورهای متعدد اجرا میکند). پیکربندیهای متنوع اپراتور تضمین میکند که اگر یکی از اپراتورها از کار بیفتد، سایرین همچنان قادر به امضا کردن هستند. این به تزائد و تنوع میانجامد که عملکرد و انعطاف را افزایش میدهد در حالی که پاداشها حداکثر میشوند.
-
-یک مزیت دیگر برای کمینه کردن اعتماد به اپراتور واحد این است که استخرهای سهامگذاری میتوانند از مشارکت آزاد و بدون مجوزِ اپراتورها پشتیبانی کنند. با انجام این کار، خدمات ریسکشان را کاهش میدهند و با استفاده از مجموعههای بدون مجوز و نگهبانیشده اپراتورها، برای مثال با جفت کردن سهامگذاران خرد با سهامگذاران بزرگتر، از غیر متمرکز بودنِ شبکۀ اتریوم پشتیبانی میکند.
-
-## ایرادات بالقوه استفاده از DVT {#potential-drawbacks-of-using-dvt}
-
-- **اجزای اضافی** - معرفی یک گرۀ DVT یک بخش دیگر اضافه میکند که احتمال دارد دچار نقص شود یا آسیبپذیر باشد. یک راه برای حذف این اثر، تلاش برای چندین پیادهسازی از یک گرۀ DVT است که به معنای چندین مشتری DVT است (مشابه با حالتی که چندین اپراتور برای لایههای اجماع و اجرا وجود دارد).
-- **هزینههای عملیاتی**- از آنجا که DVT اعتبارسنج را بین چندین طرف توزیع میکند، به جای یک گره تنها، گرههای بیشتری برای انجام عملیات مورد نیاز هستند، که قاعدتاً هزینه عملیاتی بالاتری را به همراه دارد.
-- **افزایش بالقوه تاخیر** - از آنجا که DVT از یک پروتکل اجماع برای حصول اجماع بین چندین گره که یک اعتبارسنج را عملیاتی میکنند استفاده میکند، این امر میتواند افزایش تاخیر بالقوهای را به همراه داشته باشد.
-
-## اطلاعات بیشتر {#further-reading}
-
-- [مشخصات اعتبارسنج توزیعشده اتریوم (سطح بالا)](https://github.com/ethereum/distributed-validator-specs)
-- [مشخصات فنی اعتبارسنج توزیعشده اتریوم](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec)
-- [اپلیکیشن آزمایشی تقسیم راز شامیر](https://iancoleman.io/shamir/)
diff --git a/public/content/translations/fa/07) Staking Pages/staking/pools/index.md b/public/content/translations/fa/07) Staking Pages/staking/pools/index.md
deleted file mode 100644
index 7436b3f3c8d..00000000000
--- a/public/content/translations/fa/07) Staking Pages/staking/pools/index.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: سهامگذاری مشترک
-description: مروری بر شروع سهامگذاری مشترک اتر
-lang: fa
-template: staking
-emoji: ":money_with_wings:"
-image: /images/staking/leslie-pool.png
-alt: لسلی اسب آبی در حال شنا در استخر.
-sidebarDepth: 2
-summaryPoints:
- - از طریق تجمیع قوا با دیگران، هر چقدر اتر که میخواهید سهامگذاری کنید و پاداش کسب کنید
- - بخش سخت را رها کنید و عملیات اعتبارسنجی را به شخص ثالث بسپارید
- - توکنهای سهامگذاری را در کیفپول خودتان نگه دارید
----
-
-## استخر سهامگذاری چیست؟ {#what-are-staking-pools}
-
-استخر سهامگذاری یک رویکرد مبتنی بر همکاری است که به افراد بسیاری که مقادیر اتر کمتری دارند امکان میدهد 32 اتر لازم برای فعال کردن مجموعهای از کلیدهای اعتبارسنجی را به دست آورند. عملکرد ادغام بهطور بومی در پروتکل پشتیبانی نمیشود، بنابراین راه حلهایی بهطور جداگانه برای رفع این نیاز ساخته شدند.
-
-برخی از استخرها با استفاده از قراردادهای هوشمند کار میکنند، که در آن میتوان وجوه را به یک قرارداد واریز کرد، که بدون نیاز به اعتماد سهام شما را مدیریت و ردیابی میکند، و توکنی را برای شما صادر میکند که نشاندهنده این ارزش است. سایر استخرها ممکن است شامل قراردادهای هوشمند نباشند و در عوض به صورت خارج زنجیره واسطه شوند.
-
-## چرا بهتر است با استخر سهامگذاری کنیم؟ {#why-stake-with-a-pool}
-
-علاوه بر مزایایی که در [معرفی سهامگذاری](/staking/) بیان کردیم، سهامگذاری با استخر دارای چندین مزیت متمایز است.
-
-
-
-
-
-
-
-
-
-## آنچه باید در نظر گرفته شود {#what-to-consider}
-
-سهامگذاری مشترک یا تفویضی بهطور بومی توسط پروتکل اتریوم پشتیبانی نمیشود، اما با توجه به تقاضای کاربران برای سهامگذاری کمتر از 32 اتر، راهحلهای فزایندهای برای پاسخگویی به این تقاضا ساخته شده است.
-
-هر استخر و ابزار یا قراردادهای هوشمند مورد استفاده آنها توسط تیم های مختلف ساخته شدهاند و هر کدام همراه با منافع و خطراتی هستند. استخرها کاربران را قادر میسازند تا اترهای خود را با توکنی که نمایانگر اتر سهامگذاری شده است تعویض کنند. این توکن مفید است زیرا به کاربران اجازه می دهد تا هر مقدار اتر دلخواه را با مقدار معادل یک توکن سودده مبادله کنند که سودی را از طریق پاداشهای سهامگذاری اجرا شده بر روی اتر سهامگذاری شده اساسی (و بالعکس) در صرافیهای غیرمتمرکز تولید میکند، حتی اگر اتر واقعی روی لایه اجماع ثابت بماند. این بدان معناست که مبادله مکرر بین محصول سودده اتر سهامگذاری شده و "اتر خام" نه تنها در ضریب 32 اتر در دسترس است بلکه فرایندی سریع و آسان است.
-
-با اینحال، این توکنهای اتر سهامگذاری شده تمایل به ایجاد رفتارهای کارتلمانندی دارند که در آنجا مقدار زیادی از اتر سهامگذاری شده به جای اینکه در بین بسیاری از افراد مستقل پخش شود، تحت کنترل چند سازمان متمرکز قرار میگیرد. این اتفاق شرایطی را برای سانسور یا استخراج ارزش ایجاد میکند. استاندارد طلا برای سهامگذاری همیشه باید اشخاصی باشند که در هر زمان ممکن اعتبارسنجها را بر روی سختافزار خودشان اجرا کنند.
-
-[اطلاعات بیشتر درباره خطرات سهامگذاری توکنها](https://notes.ethereum.org/@djrtwo/risks-of-lsd).
-
-شاخصهای ویژگی در زیر برای نشان دادن نقاط قوت یا ضعف قابل توجهی که ممکن است یک استخر فهرست شده داشته باشد استفاده میشود. از این بخش بهعنوان مرجعی برای نحوه تعریف این ویژگیها هنگام انتخاب استخری برای پیوستن استفاده کنید.
-
-
-
-## استخرهای سهامگذاری را کاوش کنید {#explore-staking-pools}
-
-گزینههای مختلفی برای کمک به شما در راهاندازی وجود دارد. از شاخصهای بالا برای راهنمایی به خود در مورد ابزارهای زیر استفاده کنید.
-
-
-
-
-
-لطفاً از اهمیت انتخاب سرویسی که [تنوع کاربر](/developers/docs/nodes-and-clients/client-diversity/) را جدی بگیرد غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. سرویسهایی که شواهدی از محدود کردن استفاده اکثریت کاربران دارند با عنوان "تنوع کاربر اجرایی" و "تنوع کاربر اجماعی" نشان داده میشوند
-
-ابزار سهامگذاری میشناسید که نگنجاندهایم؟ [سیاست فهرستبندی محصول](/contributing/adding-staking-products/) ما را برای اطمینان از مناسب بودن آن و ثبت آن جهت بررسی مشاهده کنید.
-
-## پرسشهای متداول {#faq}
-
-
-معمولاً توکنهای سهامگذاری شده ERC-20 برای سهامگذاران صادر میشوند و ارزش اتر به اضافه پاداشهای سهامگذاری شده آنها را نشان میدهند. در نظر داشته باشید که استخرهای مختلف با روشهای کمی متفاوت، پاداشهای سهامگذاری را بین کاربرانشان توزیع خواهند کرد، که البته امری رایج است.
-
-
-
-همین حالا! ارتقاءهای شانگهای/کاپلا در آوریل سال 2023 رخ دادند، و برداشتهای سهامگذاری را به همراه داشتند. حسابهای اعتبارسنج که استخرهای سهامگذاری را پشتیبانی میکنند، اکنون قادرند که خارج شوند و اتر را به آدرس برداشت تعیین شده خود برداشت کنند. این امر امکان پس گرفتن سهم خودتان از سهمگذاری مربوط به اتر مربوطه را فراهم میسازد. با ارائهدهندهتان بررسی کنید که چگونه این عملکرد را پیشتیبانی میکنند.
-
-از طرفی، استخرهایی که از توکن سهامگذاری ERC-20 استفاده میکنند به کاربرانشان امکان معامله این توکن در بازار آزاد معامله را میدهند، و به شما اجازه میدهند که موقعیت سهامگذاری خود را بفروشید، عملاً یعنی "برداشت کردن" بدون حذف اتر از قرارداد سهامگذاری.
-
-اطلاعات بیشتر درباره برداشتهای سهامگذاری
-
-
-
-شباهتهای زیادی بین این گزینههای سهامگذاری مشترک و صرافیهای متمرکز وجود دارد؛ مانند توانایی سهامگذاری مقادیر کم اتر و ترکیب کردن آنها با یکدیگر برای فعالسازی اعتبارسنجها.
-
-برخلاف صرافیهای متمرکز، بسیاری دیگر از گزینههای سهامگذاری مشترک از قراردادهای هوشمند و/یا توکنهای سهامگذاری استفاده میکنند که معمولاً توکنهای ERC-20 هستند که میتوانید آنها را در کیفپول خود نگه دارید، و درست همانند هر توکن دیگری آنها را بخرید یا بفروشید. این کار با اعطای کنترل توکنهایتان به شما لایهای از حاکمیت و امنیت را ارائه میدهد، اما درعینحال به شما کنترل مستقیمی بر کلاینت اعتبارسنج که از طرف شما در پسزمینه اقدام به امضا کردن میکند ارائه نمیدهد.
-
-برخی از گزینههای مشترکسازی از لحاظ نودهایی که آنها را پشتیبانی میکنند غیرمتمرکزتر از سایرین هستند. برای ارتقای سلامت و عدمتمرکز شبکه، همواره به سهامگذاران توصیه میشود که یک سرویس مشترکسازی را انتخاب کنند که یک مجموعه غیرمتمرکز بدون مجوز از اپراتورهای نود را فعال میکند.
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [فهرست سهامگذاری اتریوم](https://www.staking.directory/) - _Eridian و Spacesider_
-- [ سهامگذاری با Rocket Pool - بررسی کلی سهامگذاری](https://docs.rocketpool.net/guides/staking/overview.html) _مستندات RocketPool _
-- [ سهامگذاری اتریوم با لیدو](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) _مستندات کمکی لیدو_
diff --git a/public/content/translations/fa/07) Staking Pages/staking/saas/index.md b/public/content/translations/fa/07) Staking Pages/staking/saas/index.md
deleted file mode 100644
index 304a56433f1..00000000000
--- a/public/content/translations/fa/07) Staking Pages/staking/saas/index.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: سهامگذاری بهعنوان یک خدمت
-description: مروری بر نحوه شروع سهامگذاری مشترک اتر
-lang: fa
-template: staking
-emoji: ":money_with_wings:"
-image: /images/staking/leslie-saas.png
-alt: لسلی اسب آبی شناور در میان ابرها.
-sidebarDepth: 2
-summaryPoints:
- - عملگرهای گره شخص ثالث، عملیات کلاینت اعتبارسنج شما را مدیریت میکنند
- - گزینهای عالی برای هر کسی با 32 اتر که برای کار با پیچیدگی فنی اجرای گره احساس راحتی نمیکند
- - نیاز به اعتماد را کاهش دهید و از کلیدهای برداشت خود محافظت کنید
----
-
-## سهامگذاری بهعنوان سرویس چیست؟ {#what-is-staking-as-a-service}
-
-سهامگذاری بهعنوان سرویس («SaaS») نشاندهنده دستهای از خدمات سهامگذاری است که در آن شما 32 اتر خود را برای یک اعتبارسنج سپردهگذاری میکنید، اما عملیات گره را به یک عملگر شخص ثالث تفویض میکنید. این فرایند معمولاً شامل راهنمایی شدن از طریق راهاندازی اولیه، از جمله تولید و واریز کلید، و سپس بارگذاری کلیدهای امضای خود برای عملگر است. این کار به سرویس امکان میدهد تا اعتبارسنجتان را از طرف شما، و معمولاً در ازای هزینهای ماهانه، مدیریت کند.
-
-## چرا بهتر است از طریق یک سرویس سهامگذاری کنیم؟ {#why-stake-with-a-service}
-
-پروتکل اتریوم بهطور بومی از تفویض سهام پشتیبانی نمیکند، بنابراین این سرویسها برای برطرف کردن این تقاضا ساخته شدهاند. اگر 32 اتر برای سهامگذاری در اختیار دارید، اما در مواجهه با سختافزار احساس راحتی نمیکنید، سرویسهای SaaS به شما امکان میدهند تا زمانی که پاداشهای بلوک بومی را دریافت میکنید، بخش سخت را تفویض کنید.
-
-
-
-
-
-
-
-
-
-## آنچه باید در نظر گرفته شود {#what-to-consider}
-
-تعداد فزایندهای از ارائهدهندگان SaaS وجود دارند که در سهامگذاری اتر به شما کمک میکنند اما هرکدام از آنها مزایا و خطرات خاص خود را دارند. تمام گزینههای SaaS نیازمند فرضیههای اعتماد بیشتر در مقایسه با سهامگذاری خانگی هستند. گزینههای SaaS ممکن است کد اضافهای داشته باشند که کاربرهای اتریوم را به طوری شکل میدهند که یا باز نیست یا قابل ممیزی نیست. همچنین SaaS تاثیر مخربی بر تمرکززدایی شبکه دارد. بسته به تنظیمات، ممکن است اعتبارسنج خود را کنترل نکنید - اپراتور با عدم صداقت میتواند از اتر شما استفاده کند.
-
-شاخصهای ویژگی در زیر برای نشان دادن نقاط قوت یا ضعف قابلتوجهی که ممکن است ارائهدهنده فهرستشده SaaS داشته باشد، استفاده میشود. از این بخش به عنوان مرجعی برای نحوه تعریف این ویژگیها هنگام انتخاب سرویس برای کمک به خود در مسیر سهامگذاری استفاده کنید.
-
-
-
-## ارائهدهندگان خدمات سهامگذاری را مشاهده و بررسی کنید {#saas-providers}
-
-در زیر برخی از ارائهدهندگان موجود SaaS قید شدهاند. از شاخصهای بالا برای راهنمایی درباره این خدمات استفاده کنید
-
-
-
-### ارائهدهندگان SaaS
-
-
-
-لطفاً از اهمیت انتخاب سرویسی که [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) را جدی بگیرد غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. سرویسهایی که شواهدی از محدود کردن استفاده اکثریت کاربران دارند با عنوان "تنوع کاربر اجرایی" و "تنوع کاربر اجماعی" نشان داده میشوند
-
-### تولیدکنندگان کلید
-
-
-
-یک ارائهدهنده سهامگذاری بهعنوان خدمت را پیشنهاد میدهید که نگنجاندهایم؟ [سیاست فهرستبندی محصول](/contributing/adding-staking-products/) ما را برای اطمینان از مناسب بودن آن و ثبت آن جهت بررسی مشاهده کنید.
-
-## پرسشهای متداول {#faq}
-
-
-ترتیب امور بین ارائهدهندگان مختلف، متفاوت است، اما معمولاً راهنمایی میشوید که کلیدهای امضای مورد نیاز خود (یکی بهازای هر 32 اتر) را راهاندازی کنید، و آنها را برای تأیید اعتبار از طرف خودتان، در ارائهدهندهای بارگذاری کنید. کلیدهای امضا به تنهایی امکان برداشت، انتقال یا خرج کردن وجوه شما را ندارند. با این حال، آنها توانایی رأی دادن برای حصول اجماع را فراهم میکنند، که اگر به درستی انجام نشود، میتواند منجر به جریمه آفلاین یا تقطیع شود.
-
-
-
-بله. هر حساب هم از کلیدهای امضای BLS و هم از کلیدهای برداشت BLS تشکیل شده است. برای اینکه اعتبارسنج وضعیت زنجیره را تأیید کند، در کمیتههای همگامسازی شرکت کند و بلوکها را پیشنهاد کند، کلیدهای امضا باید به آسانی توسط کلاینت اعتبارسنج قابل دسترسی باشند. اینها باید به شکلی به اینترنت متصل شوند، و بنابراین ذاتاً کلیدهای «داغ» در نظر گرفته میشوند. این یک الزام برای اعتبارسنج شماست تا بتواند تصدیق کند، و در نتیجه کلیدهای مورد استفاده برای انتقال یا برداشت وجه به دلایل امنیتی از هم جدا میشوند.
-
-کلیدهای برداشت BLS برای امضای پیام یک بار مصرفی که اعلام میکند پاداشهای سهامگذاری و سرمایه خارج شده حساب باید به کدام لایه اجرایی بروند استفاده میشوند. به محض مخابره این پیام، کلیدهای برداشت BLS دیگر مورد نیاز نیستند. در عوض کنترل وجوه برداشت شده، به صورت دائمی به آدرسی که شما ارائه داده اید منتقل و تفویض میشوند. با این کار میتوانید آدرس برداشت را تنظیم کنید که متعلق به کیفپول سرد شما است تا خطر مربوط به وجوه اعتبارسنج خود را به حداقل برسانید حتی اگر شخص دیگری کلیدهای امضای اعتبارسنج شما را داشته باشد.
-
-بروزرسانی اطلاعات رمز برداشت، یک اقدام لازم برای فعالسازی امکان برداشت است. این فرایند شامل تولید کلیدهای برداشت با استفاده از عبارت بازیابی شما است.
-
-مطمئن شوید که پشتیبان امنی از این عبارت بازیابی دارید یا در هر زمان ممکن نخواهید توانست کلیدهای برداشت خود را تولید کنید.
-/*سهامگذارانی که آدرس برداشت را با واریز اولیه تدارک دیدهاند نیازی به تنظیم این مورد ندارند. با ارائه دهنده سرویس SaaS خود برای راهنمایی در مورد نحوه راه اندازی اعتبار سنج خود تماس بگیرید.
-
-
-
-برداشتهای سهامگذاری در ارتقاء شانگهای/کاپلا در آوریل 2023 پیادهسازی شدند. سهامگذاران باید یک آدرس برداشت ارائه کنند (البته اگر هنگام واریز اولیه ارائه نکردهاند)، و پرداخت پاداشها به صورت خودکار طی دوره زمانی هر چند روز یک بار توزیع خواهند شد.
-
-اعتبارسنجها همچنین میتوانند به صورت کامل از نقش اعتبارسنج خارج شوند، که منجر به باز شدن موجودی اتر باقیمانده آنها برای برداشت خواهد شد. حسابهایی که یک آدرس برداشت اجرایی را ارائه کردهاند و فرایند خروج را تکمیل کردهاند تمام موجودی خود را در نوبت اعتبارسنج بعدی در آدرس برداشتی که ارائه کردهاند دریافت خواهند نمود.
-
-اطلاعات بیشتر درباره برداشتهای سهامگذاری
-
-
-
-شما با استفاده از یک ارائهدهنده SaaS عملیات نود خود را به شخص دیگری تفویض میکنید. این کار، خطر عملکرد ضعیف گره را به همراه دارد، که در کنترل شما نیست. در صورتی که اعتبارسنج شما مشمول تقطیع شود، موجودی اعتبارسنج شما جریمه میشود و قاطعانه از استخر اعتبارسنج حذف میشود.
-
-پس از تکمیل فرایند اسلشینگ/خروج، این وجوه به آدرس برداشت اختصاص یافته به اعتبارسنج منتقل خواهند شد. این امر نیاز به ارائه یک آدرس برداشت برای فعالسازی دارد. آدرس برداشت ممکن است در واریز اولیه ارائه شده باشد. اگر آدرس برداشت ارائه نشده بود، لازم است از کلیدهای برداشت اعتبارسنج برای امضای پیام مشخص کننده آدرس برداشت استقاده شود. اگر آدرس برداشت ارائه نشده باشد، وجوه تا زمان ارائه آدرس، غیر قبل برداشت خواهند بود.
-
-برای جزئیات بیشتر در مورد ضمانت نامه ها یا بیمه و دستورالعملهایی درباره نحوه ارائه آدرس برداشت، با ارائهدهنده سرویس SaaS تماس بگیرید. اگر ترجیح میدهید راهاندازی اعتبارسنج خود را کاملاً تحت کنترل داشته باشید، درباره نحوه به اشتراک گذاشتن اتر خود بهصورت انفرادی بیشتر بدانید.
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [فهرست سهامگذاری اتریوم](https://www.staking.directory/) - _Eridian و Spacesider_
-- [ارزیابی سرویسهای سهامگذاری](https://www.attestant.io/posts/evaluating-staking-services/) - _جیم مکدونالد 2020_
diff --git a/public/content/translations/fa/07) Staking Pages/staking/solo/index.md b/public/content/translations/fa/07) Staking Pages/staking/solo/index.md
deleted file mode 100644
index fb58f459331..00000000000
--- a/public/content/translations/fa/07) Staking Pages/staking/solo/index.md
+++ /dev/null
@@ -1,207 +0,0 @@
----
-title: اتر خود را بهصورت انفرادی سهامگذاری کنید
-description: مروری بر نحوهی آغاز سهامگذاری بهصورت انفرادی
-lang: fa
-template: staking
-emoji: ":money_with_wings:"
-image: /images/staking/leslie-solo.png
-alt: لسلی اسب آبی روی تراشه رایانهای خودش.
-sidebarDepth: 2
-summaryPoints:
- - حداکثر پاداش را مستقیماً از پروتکل دریافت کنید تا اعتبارسنج خود را کارا و آنلاین نگه دارید
- - سختافزار خانگی را اجرا کنید و شخصاً امنیت و تمرکززدایی شبکه اتریوم را بیشتر کنید
- - نیاز به اعتماد را حذف کنید و همیشه کلیدهای سرمایه خود را تحت کنترل داشته باشید
----
-
-## سهامگذاری انفرادی چیست؟ {#what-is-solo-staking}
-
-سهامگذاری انفرادی به عمل [اجرای یک گره اتریوم](/run-a-node/) متصل به اینترنت و واریز 32 اتر برای فعال کردن یک [اعتبارسنج](#faq) گفته میشود، که به شما امکان میدهد بهطور مستقیم در اجماع شبکه شرکت کنید.
-
-**سهامگذاری انفرادی، تمرکززدایی شبکه اتریوم را افزایش میدهد،** که منجر میشود اتریوم در برابر سانسور مقاومتر و در مقابل مهاجمین مستحکمتر باشد. دیگر روشهای سهامگذاری ممکن است به همین روش به شبکه کمک نکنند. سهامگذاری انفرادی بهترین گزینه سهامگذاری برای ایمنسازی اتریوم است.
-
-یک گرهی اتریوم از یک کلاینت لایه اجرا (EL) و یک کلاینت لایه اجماع (CL) تشکیل شده است. این کلاینتها نرمافزارهایی هستند که همراه با مجموعهای از کلیدهای امضاکننده معتبر، برای تأیید تراکنشها و بلوکها، تصدیق کردن سر درست زنجیره، جمعآوری تأییدیهها و پیشنهاد بلوکها با هم کار میکنند.
-
-سهامگذارهای انفرادی مسئول کار با سختافزار مورد نیاز برای اجرای این کلاینتها هستند. قویاً توصیه میشود از یک دستگاه اختصاصی که در خانه به کار گرفته شود برای این کار استفاده کنید - این کار برای سلامت شبکه بسیار مفید است.
-
-یک سهامگذار انفرادی در ازای اینکه اعتبارسنج خود را کارآمد و آنلاین نگه دارد، مستقیماً از پروتکل پاداش دریافت میکند.
-
-## چرا بهصورت انفرادی سهامگذاری کنیم؟ {#why-stake-solo}
-
-سهامگذاری انفرادی مسئولیت به همراه دارد اما حداکثر کنترل بر وجوه و تنظیمات سهامگذاری را به شما ارائه میدهد.
-
-
-
-
-
-
-
-## ملاحظات لازم قبل از سهامگذاری انفرادی {#considerations-before-staking-solo}
-
-درست است که ما آرزو میکنیم سهامگذاری انفرادی برای همه در دسترس و بدون ریسک باشد، اما واقعیت چنین نیست. چند موضوع عملی و جدی وجود دارد که باید قبل از انتخاب سهامگذاری انفرادی اتر خود در نظر داشته باشید.
-
-
-
-هنگام راهاندازی گرهی خود، باید مدتی را صرف یادگیری نحوه استفاده از نرمافزار انتخابی خود کنید. این کار شامل مطالعهی مستندات مرتبط و هماهنگی با کانالهای ارتباطی آن تیمهای توسعهدهنده است.
-
-هرچه بیشتر در مورد نرمافزاری که در حال اجرا هستید و نحوهی کار اثبات سهام اطلاعات بیشتری کسب کنید، ریسک آن بهعنوان یک سهامگذار برایتان کمتر خواهد بود و رفع هرگونه مشکلی که ممکن است در طول مسیر به عنوان عملگر گره ایجاد شود آسانتر خواهد بود.
-
-
-
-راهاندازی گره به تسلط کافی در کار با رایانه نیاز دارد، گرچه ابزارهای جدید به مرور زمان این کار را آسانتر میکنند. درک رابط خط فرمان مفید است، اما دیگر بهشدت موردنیاز نیست.
-
-تنظیمات سختافزاری بسیار ابتدایی و درک حداقل مشخصات توصیهشده نیز لازم است.
-
-
-
-همانطور که کلیدهای خصوصی آدرس اتریوم شما را ایمن میکنند، باید کلیدهایی را بهویژه برای اعتبارسنج خود ایجاد کنید. باید بدانید که چگونه هر عبارت بازیابی یا کلید خصوصی را ایمن نگه دارید.{' '}
-
-امنیت اتریوم و پیشگیری از کلاهبرداری
-
-
-
-سختافزار گهگاه خراب میشود، اتصالات شبکه بعضاً دچار مشکل میشوند و نرمافزار کلاینت هر از گاهی نیازمند ارتقا است. نگهداری از گره ناگزیر است و هر چند وقت یکبار نیازمند توجه شما خواهد بود. شما باید مطمئن باشید که از هرگونه ارتقای شبکه پیشبینیشده یا سایر ارتقاهای حیاتی مشتری آگاه هستید.
-
-
-
-پاداشهای شما متناسب با زمانی است که اعتبارسنج شما آنلاین است و بهدرستی تصدیق میکند. زمان خاموشی متناسب با تعداد اعتبارسنجهای دیگر که همزمان آفلاین هستند مشمول جریمه میشود، اما به برخورد شدید منجر نمیشود. پهنای باند نیز مهم است، زیرا پاداش برای تصدیقهایی که به موقع دریافت نمیشوند کاهش مییابد. الزامات متفاوت خواهد بود، اما حداقل سرعت 10 مگابیت بر ثانیه برای بارگذاری و بارگیری توصیه میشود.
-
-
-
-برخورد شدید که متفاوت از مجازاتهای عدم فعالیت برای آفلاین بودن است، مجازات بسیار جدیتری است که برای جرایم مخرب در نظر گرفته شده است. با اجرای یک کلاینت اقلیت با کلیدهایتان تنها روی یک دستگاه بارشده در آن واحد، ریسک برخورد شدید با شما به حداقل میرسد. همانطور که گفته شد، همه سهامگذاران باید از ریسکهای برخورد شدید آگاه باشند.
-
-اطلاعات بیشتر درباره جریمه و چرخه حیات اعتبارسنج
-
-
-
-
-
-## نحوهی عملکرد {#how-it-works}
-
-
-
-زمانی که فعال باشد شما پاداش اتر دریافت خواهید کرد، که به صورت دورهای به آدرس برداشت شما واریز میگردد.
-
-در صورت تمایل، میتوانید دیگر اعتبارسنج نباشید؛ بدین ترتیب، نیاز به آنلاین بودن از بین میرود و دریافت هرگونه پاداش بیشتر متوقف میشود. موجودی باقیمانده شما نیز سپس به آدرس برداشتی که در زمان تنظیمات اختصاص داده بودید واریز خواهد شد.
-
-[اطلاعات بیشتر درباره برداشتهای سهامگذاری](/staking/withdrawals/)
-
-## با Staking Launchpad کار را شروع کنید {#get-started-on-the-staking-launchpad}
-
-Staking Launchpad یک برنامه منبعباز است که به شما کمک میکند سهامگذار شوید. این شما را از طریق انتخاب کلاینتهای خود، تولید کلیدهای خود و واریز اتر خود به قرارداد واریز سهامگذاری راهنمایی میکند. چکلیستی ارائه شده است تا مطمئن شوید همه چیز را برای راهاندازی اعتبارسنج خود بهطور ایمن در نظر گرفتهاید.
-
-
-
-## ملاحظات مربوط به ابزارهای راهاندازی گره و کلاینت {#node-tool-considerations}
-
-تعداد فزایندهای از ابزارها و خدمات وجود دارد که به شما کمک میکند اتر خود را بهصورت انفرادی به اشتراک بگذارید، اما هر کدام خطرات و مزایای متفاوتی دارند.
-
-شاخصهای ویژگی در زیر برای نشان دادن نقاط قوت یا ضعف قابل توجهی که ممکن است یک استخر فهرستشده داشته باشد استفاده میشود. از این بخش به عنوان مرجعی برای نحوه تعریف این ویژگیها هنگام انتخاب ابزارها برای کمک به خود در مسیر سهامگذاری استفاده کنید.
-
-
-
-## مشاهده و بررسی ابزارهای راهاندازی گره و کلاینت {#node-and-client-tools}
-
-گزینه های مختلفی برای کمک کردن به شما در راهاندازی وجود دارد. از شاخصهای بالا برای راهنمایی درباره ابزارهای زیر استفاده کنید.
-
-
-
-### ابزارهای گره
-
-
-
-لطفاً از اهمیت انتخاب [کلاینت اقلیت](/developers/docs/nodes-and-clients/client-diversity/) غافل نشوید، زیرا امنیت شبکه را بهبود میبخشد و ریسک شما را محدود میکند. ابزارهایی که به شما امکان میدهند کاربر اقلیت را راهاندازی کنید با عنوان «چندکاربری» نشان داده میشوند.
-
-### تولیدکنندگان کلید
-
-این ابزارها میتوانند بهعنوان جایگزینی برای [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) برای کمک به تولید کلید استفاده شوند.
-
-
-
-ابزار سهامگذاری میشناسید که نگنجاندهایم؟ [سیاست فهرستبندی محصول](/contributing/adding-staking-products/) ما را برای اطمینان از مناسب بودن آن و ثبت آن جهت بررسی مشاهده کنید.
-
-## مشاهدهی راهنماهای سهامگذاری انفرادی {#staking-guides}
-
-
-
-## پرسشهای متداول {#faq}
-
-اینها چند مورد از متداولترین سؤالات مربوط به سهامگذاری هستند که ارزش دانستن دارند.
-
-
-
-یک اعتبارسنج یک موجود مجازی است که بر روی اتریوم زندگی میکند و در اجماع پروتکل اتریوم مشارکت میکند. اعتبارسنجها با موجودی، کلید عمومی و سایر مشخصات نشان داده میشوند. کلاینت اعتبارسنج نرمافزاری است که با نگه داشتن و استفاده از کلید خصوصی آن، از طرف اعتبارسنج عمل میکند. یک کلاینت اعتبارسنج منفرد میتواند چندین جفت کلید را در خود نگه دارد و اعتبارسنجهای زیادی را کنترل کند.
-
-
-
-
-هر جفت کلید مرتبط با یک اعتبارسنج دقیقاً به 32 اتر نیاز دارد تا فعال شود. واریز کردن اتر بیشتر به یک مجموعه کلید، پتانسیل پاداش را افزایش نمیدهد، زیرا هر اعتبارسنج محدود به موجودی مؤثر 32 اتر است. این بدان معنی است که سهامگذاری با افزایشهای 32 اتری انجام میشود که هر کدام مجموعهای از کلیدها و موجودی خاص خود را دارند.
-
-بیش از 32 اتر برای یک اعتبارسنج واریز نکنید. این کار پاداشهای شما را زیادتر نمیکند. اگر یک آدرس برداشت برای اعتبارسنج تنظیم شده باشد، وجوه بیشتر از 32 اتر به صورت خودکار به این آدرس در طی نوبت اعتبارسنج بعدی واریز خواهد شد.
-
-اگر سهامگذاری انفرادی برای شما بسیار سخت به نظر میرسد، از یک ارائهدهندهی سهامگذاری بهعنوان سرویس استفاده کنید، یا اگر با کمتر از 32 اتر کار میکنید، استخرهای سهامگذاری را بررسی کنید.
-
-
-
-آفلاین شدن هنگامی که شبکه به درستی در حال نهاییسازی است، منجر به برخورد شدید نمیشود. اگر اعتبارسنج شما برای یک دوره معین (هر دوره 6.4 دقیقه) برای تصدیق کردن در دسترس نباشد، جریمههای عدم فعالیت کوچک اعمال میشود، اما این موضوع با برخورد شدید بسیار متفاوت است. این جریمهها اندکی کمتر از پاداشی است که در صورت در دسترس بودن اعتبارسنج کسب میکردید، و ضررها را میتوان با آنلاین بودن به مدت زمان تقریباً برابر دوباره به دست آورد.
-
-توجه داشته باشید که جریمه عدم فعالیت متناسب با تعداد اعتبارسنجهایی است که در آن واحد آفلاین هستند. در مواردی که بخش بزرگی از شبکه بهطور همزمان آفلاین باشد، جریمه هر یک از این اعتبارسنجها بیشتر از زمانی خواهد بود که یک اعتبارسنج منفرد در دسترس نباشد.
-
-در موارد شدید، اگر شبکه به دلیل آفلاین بودن بیش از یک سوم اعتبارسنجها، نهایی کردن را متوقف کند، این کاربران دچار نشت عدم فعالیت درجه دوم شناخته میشود که تخلیه نمایی اتر از حسابهای اعتبارسنجهای آفلاین است. این کار، به شبکه امکان میدهد تا نهایتاً با سوزاندن اتریوم اعتبارسنجهای غیرفعال خود را ترمیم کند تا زمانی که موجودی آنها به 16 اتر برسد، که در آن نقطه، آنها بهطور خودکار از استخر اعتبارسنج رانده میشوند. اعتبارسنجهای آنلاین باقیمانده در نهایت بیش از 2/3 شبکه را دوباره تشکیل میدهند و اکثریت قابلتوجه موردنیاز را برای نهایی کردن مجدد زنجیره برآورده میکنند.
-
-
-
-بهطور خلاصه، این موضوع را هرگز نمیتوان بهطور کامل تضمین کرد، اما اگر با حسن نیت عمل کنید، یک کلاینت اقلیت را اجرا کنید و کلیدهای امضای خود را هر بار فقط در یک دستگاه نگه دارید، خطر برخورد شدید تقریباً صفر است.
-
-تنها چند راه خاص وجود دارد که میتواند منجر به برخورد شدید و رانده شدن از شبکه شود. در زمان نگارش این مقاله، برخوردهای شدیدی که رخ دادهاند صرفاً حاصل تنظیمات سختافزاری اضافی بوده است که در آن کلیدهای امضا در دو دستگاه جداگانه ذخیره میشوند. این کار میتواند بهطور ناخواسته منجر به رأی مضاعف از سمت کلیدهای شما شود، که یک تخلف مشمول برخورد شدید است.
-
-اجرای یک کلاینت با اکثریت قابلتوجه (هر کلاینتی که بیش از 2/3 شبکه استفاده میکند) همچنین ریسک برخورد شدید بالقوه را در صورتی که کلاینت دارای اشکالی باشد که منجر به فورک زنجیره شود، در خود نهفته است. این موضوع میتواند منجر به فورک معیوب شود که نهایی میشود. برای تصحیح بازگشت به زنجیره موردنظر به ارسال رای فراگیر با تلاش برای لغو یک بلوک نهاییشده نیاز است. این موضوع هم یک تخلف مشمول برخورد شدید است و میتوان به سادگی با اجرای یک کلاینت اقلیت بهجای آن، از آن جلوگیری کرد.
-
-اشکالات برابر در کلاینت اقلیت هرگز نهایی نمیشوند و بنابراین هرگز منجر به رأی فراگیر نمیشوند و صرفاً منجر به جریمههای عدم فعالیت و نه برخورد شدید میشوند.
-
-
-
-
-
-کلاینتهای فردی ممکن است از نظر عملکرد و رابط کاربری کمی متفاوت باشند، زیرا هر کدام توسط تیمهای مختلف و با استفاده از زبانهای برنامهنویسی مختلف توسعه یافتهاند. همانطور که گفته شد، هیچیک از آنها «بهترین» نیستند. همه کلاینتهای تولید نرمافزارهایی عالی هستند که همگی عملکردهای اصلی یکسانی را برای همگامسازی و تعامل با زنجیرهی بلوکی انجام میدهند.
-
-از آنجایی که همهی کلاینتهای تولید عملکردهای اولیه یکسانی را ارائه میدهند، در واقع بسیار مهم است که یک کلاینت اقلیت را انتخاب کنید، یعنی کلاینتی که در حال حاضر توسط اکثر اعتبارسنجها در شبکه استفاده نمیشود. این کار ممکن است غیرمنطقی به نظر برسد، اما اجرای یک کلاینت اکثریت یا کلاینت اکثریت قابلتوجه، شما را در معرض خطر برخورد شدید در صورت بروز اشکال در آن کلاینت قرار میدهد. اجرای یک کلاینت اقلیت، بهشدت این خطرات را محدود میکند.
-
-دربارهی اینکه چرا تنوع کلاینت حیاتی است بیشتر بدانید
-
-
-
-گرچه یک سرور خصوصی مجازی (VPS) میتواند به عنوان جایگزینی برای سختافزار خانگی استفاده شود، دسترسی فیزیکی و مکان کلاینت اعتبارسنجتان مهم است. راهحلهای ابری متمرکز مانند Amazon Web Services یا Digital Ocean، به قیمت متمرکز کردن شبکه، راحتیِ بینیازی از تهیه و اجرای سختافزار را به همراه میآورند.
-
-هر چه کلاینتهای اعتبارسنجی بیشتری روی یک راهحل ذخیرهسازی ابری متمرکز واحد کار کنند، برای این کاربران خطرناکتر میشود. هر رویدادی که این ارائهدهندگان را آفلاین کند، خواه از طریق حمله، درخواستهای نظارتی، یا صرفاً قطع برق/اینترنت، منجر به آفلاین شدن هر کلاینت اعتبارسنجی میشود که به این سرور متکی است و همزمان آفلاین میشود.
-
-جریمههای آفلاین بودن متناسب با تعداد کلاینتهای دیگری است که همزمان آفلاین هستند. استفاده از VPS ریسک شدیدتر شدن جریمههای آفلاین بودن را تا حد زیادی افزایش میدهد و در صورتی که قطعی به اندازه کافی بزرگ باشد، خطر نشت درجه دوم یا کاهش را افزایش میدهد. برای به حداقل رساندن خطر خود و شبکه، به کاربران قویاً توصیه میشود که سختافزار خود را تهیه کنند و اجرا کنند.
-
-
-
-
-هر نوع برداشت از زنجیره بیکن نیازمند آن است که جزئیات رمز برداشت تنظیم شوند.
-
-سهامگذاران جدید این را در زمان تولید کلید و واریز تنظیم میکنند. سهامگذاران کنونی که قبلا این قسمت را تنظیم نکردهاند میتوانند کلیدهایشان را برای پشتیبانی از این عملکرد ارتقا دهند.
-
-به محض تنظیم کردن اطالاعات رمز برداشت، پرداختهای پاداش (اتر جمع شده و بدست آمده از 32 اتر اولیه) به صورت دوره ای و به صورت خودکار به آدرس برداشت توزیع خواهد شد.
-
-برای باز کردن و بازپسگیری کل موجودی تان باید فرایند خروج از اعتبارسنج خود را نیز تکمیل کنید.
-
-اطلاعات بیشتر درباره برداشتهای سهامگذاری
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [فهرست سهامگذاری اتریوم](https://www.staking.directory/) - _Eridian و Spacesider_
-- [مشکل تنوع کلاینت اتریوم](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
-- [کمک به تنوع کلاینتها](https://www.attestant.io/posts/helping-client-diversity/) - _جیم مکدونالد 2022_
-- [ تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_
-- نحوهی خرید سختافزار اعتبارسنج اتریوم - _EthStaker 2022_
-
- - [گامبهگام: نحوهی پیوستن به شبکهی آزمایشی اتریوم 2.0](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) - _ بوتا_
-- [نکات پیشگیری از برخورد شدید Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _راول جردن 2020 _
-
-
diff --git a/public/content/translations/fa/07) Staking Pages/staking/withdrawals/index.md b/public/content/translations/fa/07) Staking Pages/staking/withdrawals/index.md
deleted file mode 100644
index b07c027121f..00000000000
--- a/public/content/translations/fa/07) Staking Pages/staking/withdrawals/index.md
+++ /dev/null
@@ -1,218 +0,0 @@
----
-title: برداشتها از سهامگذاری
-description: این صفحه به طور خلاصه بیان میکند که برداشتهای سهامگذاری خودکار چه هستند، چطور کار میکنند، و سهامگذاران برای دریافت پاداشهایشان به چه کار باید انجام بدهند
-lang: fa
-template: staking
-image: /images/staking/leslie-withdrawal.png
-alt: لزلی (Leslie) کرگدن، با پاداش سهام گذاریاش
-sidebarDepth: 2
-summaryPoints:
- - ارتقاء شانگهای/کاپلا برداشتهای سهامگذاری را روی اتریوم فعال کرد
- - اپراتورهای اعتبارسنج باید یک آدرس برداشت را برای فعالسازی فراهم کنند
- - پاداش ها هر چند روز یک بار به صورت خودکار توزیع میشوند
- - اعتبارسنجهایی که از سهامگذاری کاملاً خارج میشوند موجودی باقیمانده خود را دریافت خواهند نمود
----
-
-
-برداشتهای سهامگذاری همراه با ارتقاء شانگهای/کاپلا که در 12 آوریل 2023 رخ داد فعال شدند. اطلاعات بیشتر درباره شانگهای/کاپلا
-
-
-**برداشتهای سهامگذاری** اشاره به انتقالهای اتر از یک حساب اعتبارسنج روی لایه اجماعی اتریوم (زنجیره بیکن) به لایه اجرایی که میتواند در آنجا معامله شود دارند.
-
-**پرداخت پاداش موجودی اضافه** بیشتر از 32 اتر به صورت خودکار و مرتب به آدرس برداشت متصل به هر اعتبارسنج، که قبلاً یک بار توسط کاربر فراهم شده است ارسال خواهد شد. کاربران همچنین میتوانند **کاملاً از سهامگذاری خارج شوند**، که کل موجودی اعتبارسنج آنها را باز خواهد کرد.
-
-## پاداشهای سهامگذاری {#staking-rewards}
-
-پرداخت پاداشها به صورت خودکار برای حسابهای اعتبارسنج فعال همراه با حداکثر موجودی مؤثر 32 اتری پردازش میشوند.
-
-هرگونه موجودی بالاتر از 32 اتر که از طریق پاداشها به دست میآید، در واقع به اصل کار کمک نمیکند یا وزن این اعتبارسنج را در شبکه افزایش نمیدهد، و بنابراین بهطور خودکار هر چند روز یکبار بهعنوان پرداخت پاداش برداشت میشود. جدا از ارائه یک باره آدرس برداشت، این پاداشها نیازی به هیچ اقدامی از سوی اپراتور اعتبارسنج ندارند. همه اینها در لایه اجماع فعال میشوند، بنابراین هیچ گسی (کارمزد معامله) در هیچ مرحلهای مورد نیاز نیست.
-
-### چطور به اینجا رسیدیم؟ {#how-did-we-get-here}
-
-اتریوم طی چند سال گذشته تحت چندین ارتقاء شبکه قرار گرفته است و به جای ماینینگ انرژیبر که در گذشته وجود داشت، به شبکهای که توسط خود اتریوم ایمنسازی شده تبدیل شده است. مشارکت در اجماع روی اتریوم اکنون تحت عنوان "سهامگذاری" شناخته می شود، زیرا شرکتکنندگان بهطور داوطلبانه اتر را قفل کردهاند، و آن را برای امکان مشارکت در شبکه "در وضعیت سهامگذاری" قرار دادهاند. کاربرانی که از قوانین تبعیت میکنند پاداش میگیرند، و هر تلاشی برای تقلب میتواند جریمه شود.
-
-از زمان راهاندازی قرارداد سپردهگذاری سهام در نوامبر 2020، برخی از پیشگامان شجاع اتریوم بهطور داوطلبانه وجوهی را برای فعالسازی «اعتبارسنجها» قفل کردهاند، یعنی حسابهای ویژهای که بر اساس قوانین شبکه،حق تصدیق رسمی و پیشنهاد بلوکها را دارند.
-
-قبل از ارتقاء شانگهای/کاپلا، نمیتوانید به اتر سهامگذاری شده خود دسترسی داشته باشید یا از آن استفاده کنید. اما الان، میتوانید انتخاب کنید که پاداشهای خود را به صورت خودکار در یک حساب منتخب دریافت کنید، و نیز میتوانید اتر سهامگذاری شده خود را هر زمان که بخواهید برداشت کنید.
-
-### چگونه آماده شوم؟ {#how-do-i-prepare}
-
-
-
-### اطلاعیه های مهم {#important-notices}
-
-ارائه یک آدرس برداشت، یک قدم ضروری برای هر حساب اعتبارسنج قبل از واجد شرایط بودن آن برای برداشت اتر از موجودی آن است.
-
-
- هر حساب اعتبارسنج میتواند فقط یک بار تنها به یک آدرس برداشت اختصاص یابد. پس از انتخاب یک آدرس و ارسال آن به لایه اجماع، نمیتوان آن را لغو کرد یا دوباره تغییر داد. مالکیت و صحت آدرس ارائه شده را قبل از ثبت دوباره بررسی کنید.
-
-
-در این میان هیچ تهدیدی برای وجوه شما به دلیل ارائه نکردن این مورد وجود ندارد، با این فرض که عبارت بازیابی شما در محیطی آفلاین نگهداری میشود و به هیچ وجه به خطر نیفتاده است. عدم افزودن اطلاعات رمز برداشت صرفاً اتر را تا زمانی که آدرس برداشت ارائه شود در حساب اعتبارسنج قفل میکند.
-
-## خروج کامل از سهامگذاری {#exiting-staking-entirely}
-
-فراهم کردن آدرس برداشت قبل از اینکه _هر_ انتقال وجهی بتواند به خارج از موجودی حساب اعتبارسنج منتقل شود الزامی است.
-
-کاربرانی که قصد خروج کامل از سهامگذاری و برداشت کامل موجودی خود را دارند، باید پیام "خروج داوطلبانه" را که روند خروج از سهامگذاری را آغاز خواهد کرد با کلیدهای اعتبارسنج امضا و مخابره کنند. این امر با کاربر اعتبارسنج شما انجام میشود و در گره اجماع شما ثبت میشود، و نیازی به پرداخت گس ندارد.
-
-فرآیند خروج یک اعتبارسنج از سهامگذاری، بسته به تعداد دیگری که همزمان خارج میشوند، زمان متغیری را میطلبد. پس از تکمیل، این حساب دیگر مسئول انجام وظایف اعتبارسنج در شبکه نخواهد بود، و دیگر واجد شرایط دریافت پاداشها نیست، و اتر آن دیگر "در وضعیت سهامگذاری" نیست. در این زمان حساب، نشان کاملاً "قابل برداشت" را دریافت خواهد کرد.
-
-هنگامی که یک حساب نشان "قابل برداشت" را دریافت کند، و اطلاعات رمز برداشت ارائه شدند، کاربر به غیر از انتظار کشیدن کار دیگری لازم نیست انجام بدهد. حسابها بهطور خودکار و بهطور مداوم توسط پیشنهادکنندگان بلوک برای وجوه خارج شده واجد شرایط جابجا میشوند، و موجودی حساب شما بهطور کامل (که به عنوان "برداشت کامل" نیز شناخته میشود) در جابجایی بعدی منتقل میشود.
-
-## برداشتهای سهامگذاری چه موقع فعال میشوند؟ {#when}
-
-برداشتهای سهامگذاری فعال هستند! عملکرد برداشت به عنوان بخشی از ارتقاء شانگهای/کاپلا که در تاریخ 12 آوریل 2023 روی داد فعال شد.
-
-ارتقاء شانگهای/کاپلا این امکان را فراهم کرد که اتر سهامگذاری شده در درون حسابهای معمول اتریوم بازپس گرفته شود. این امر حلقه نقدینگی سهامگذاری را بست و اتریوم را یک قدم به مسیر ساختن یک اکوسیستم غیرمتمرکز پایدار، مقیاسپذیر و امن نزدیکتر کرد.
-
-- [اطلاعات بیشتر درباره تاریخچه اتریوم](/history/)
-- [اطلاعات بیشتر درباره نقشهراه اتریوم](/roadmap/)
-
-## پرداخت برداشتها چگونه انجام میشوند؟ {#how-do-withdrawals-work}
-
-اینکه آیا یک اعتبارسنج مشخص واجد شرایط برداشت است یا نه، توسط وضعیت خود حساب اعتبارسنج تعیین میشود. هیچ اطلاعاتی از سوی کاربر در هر زمان معین برای تعیین اینکه آیا یک حساب باید شروع به برداشت کند یا نه لازم نیست - کل فرآیند به طور خودکار توسط لایه اجماع در یک حلقه پیوسته انجام میشود.
-
-### با توضیحات تصویری راحتترید؟ {#visual-learner}
-
-این توضیحات برداشتهای سهامگذاری اتریوم ارائه شده از سوی Finematics را مرور کنید:
-
-
-
-### «انتقال» بین اعتبارسنجها {#validator-sweeping}
-
-زمانی که یک اعتبارسنج قرار است بلوک بعدی را پیشنهاد کند، باید یک صف برداشت ایجاد کند، نهایتاً تا 16 برداشت واجد شرایط. این کار با شروع با شاخص اعتبارسنج 0 انجام میشود، یعنی تعیین اینکه آیا برداشت واجد شرایطی برای این حساب طبق قوانین پروتکل وجود دارد یا نه، و در صورت وجود آن را به صف اضافه کند. کار اعتبارسنج تنظیم شده برای پیشنهاد بلوک بعدی از جایی که آخرین بلوک متوقف شده است ادامه مییابد و این روند بهترتیب به طور نامحدود پیش میرود.
-
-
-به یک ساعت آنالوگ فکر کنید. عقربه روی آن به ساعت اشاره میکند، در یک جهت پیش میرود، از روی هیچ ساعتی نمیپرد و در نهایت پس از رسیدن به آخرین عدد، دوباره از ابتدا شروع به چرخیدن میکند.
-اکنون به جای اعداد 1 تا 12، تصور کنید ساعت دارای اعداد 0 تا N داشته باشد ( تا ژانویه 2023 تعداد کل حساب های اعتبارسنج که تا کنون در لایه اجماع ثبت شده اند، بیش از 500،000 بوده است).
-عقربه روی ساعت به اعتبارسنج بعدی اشاره میکند که باید برای برداشتهای واجد شرایط بررسی شود. این روند از عدد 0 شروع میشود، و بدون پریدن و رد شدن از هر حساب تا آخر پیش میرود. وقتی که به آخرین اعتبارسنج دست یافت، چرخه پیوسته به آغاز مسیر باز میگردد.
-
-
-#### بررسی یک حساب برای برداشت {#checking-an-account-for-withdrawals}
-
-در حالی که یک پیشنهاددهنده در حال جابجایی بین اعتبارسنجها برای برداشتهای احتمالی است، هر اعتبارسنج که بررسی میشود با یک سری سوالات کوتاه ارزیابی میشود تا مشخص شود که آیا برداشت باید آغاز شود یا نه، و اگر چنین است، چه مقدار اتر باید برداشت شود.
-
-1. **آیا یک آدرس برداشت ارائه شده است؟** اگر هیچ آدرس برداشتی ارائه نشده است، از حساب عبور میکند و هیچ برداشتی انجام نمیشود.
-2. ** آیا اعتبارسنج خارج شده و قابل برداشت است؟** اگر اعتبارسنج به طور کامل خارج شده باشد، و ما به ایپوکی رسیده باشیم که حساب آن "قابل برداشت" در نظر گرفته شود، برداشت کامل انجام میشود. با این کار کل موجودی باقیمانده به آدرس برداشت منتقل میشود.
-3. **آیا موجودی مؤثر حداکثر 32 اتر است؟** اگر حساب دارای اطلاعات رمز برداشت باشد، به طور کامل از آن خارج نشده باشد، و دارای پاداش های در حال انتظار بالاتر از 32 باشد، یک برداشت جزئی پردازش خواهد شد که فقط پاداشهای بالای 32 را به آدرس برداشت کاربر منتقل میکند.
-
-تنها دو اقدام وجود دارد که توسط اپراتورهای اعتبارسنج در طول چرخه عمر اعتبارسنج انجام میشود که مستقیماً بر این جریان تأثیر میگذارد:
-
-- ارائه اطلاعات رمز برداشت برای فعالسازی هر شکلی از برداشت
-- خروج از شبکه، که منجر به برداشت کامل خواهد شد
-
-### بدون گس {#gas-free}
-
-این رویکرد برای برداشتهای سهامگذاری از الزام سهامگذاران به ثبت دستی تراکنشی که درخواست برداشت مقدار خاصی از اتر را دارند، اجتناب میکند. این بدان معناست که **نیازی به گس (کارمزد تراکنش) نیست**، و برداشتها نیز برای فضای بلوک لایه اجرایی موجود رقابت نمیکنند.
-
-### هر چند وقت یکبار پاداشهای سهامگذاری را دریافت خواهم کرد؟ {#how-soon}
-
-حداکثر 16 برداشت را میتوان در یک بلوک پردازش کرد. با این نرخ، میتوان 115200 برداشت اعتبارسنج را در روز پردازش کرد (با فرض تلف نشدن هرگونه اسلات). همانطور که در بالا ذکر شد، اعتبارسنجهای بدون حق برداشت نادیده گرفته میشوند، و زمان پایان جابجایی را کاهش میدهند.
-
-با گسترش این محاسبه، میتوانیم زمان پردازش تعداد معینی از برداشتها را تخمین بزنیم:
-
-
-
-| شمار برداشت ها | زمان تکمیل |
-| :-------------------: | :--------------: |
-| 400,000 | 3.5 روز |
-| 500,000 | 4.3 روز |
-| 600,000 | 5.2 روز |
-| 700,000 | 6.1 روز |
-| 800,000 | 7.0 روز |
-
-
-
-میبینید که اعتبارسنجهای بیشتر در شبکه سرعت آن را کاهش میدهند. افزایش در تعداد اسلاتهای از دست رفته میتواند سرعت را به نسبت کاهش دهد، اما این به طور کلی نشاندهنده سمت کندتر خروجیهای احتمالی است.
-
-## پرسشهای متداول {#faq}
-
-
-نه، فرآیند ارائه اطلاعات رمز برداشت یک فرایند یکباره است و پس از ثبت دیگر قابل تغییر نیست.
-
-
-
-با تعیین یک آدرس برداشت لایه اجرا، اطلاعات رمز برداشت آن اعتبارسنج برای همیشه تغییر کرده است. این بدان معناست که اطلاعات رمز قدیمی دیگر عمل نمیکنند و اطلاعات رمز جدید به یک حساب لایه اجرا هدایت میشود.
-
-آدرسهای برداشت میتوانند یک قرارداد هوشمند (که توسط کد آن کنترل میشود)، یا یک حساب دارای مالکیت خارجی (EOA، که توسط کلید خصوصی آن کنترل میشود) باشند. در حال حاضر این حسابها هیچ راهی برای انتقال یک پیام به لایه اجماع که نشاندهنده تغییر اطلاعات رمز اعتبارسنج باشد ندارند، و افزودن این قابلیت پیچیدگی زائدی را به پروتکل اضافه خواهد کرد.
-
-بهعنوان یک راهکار جایگزین تغییر آدرس برداشت برای یک اعتبارسنج خاص، کاربران ممکن است یک قرارداد هوشمند را بهعنوان آدرس برداشت خود تعیین کنند که میتواند چرخش کلید را انجام دهد، مثلاً یک گاوصندوق. کاربرانی که وجوه خود را روی EOA خود تنظیم میکنند، میتوانند یک خروج کامل برای برداشت همه وجوه سهامگذاری شده خود انجام دهند، و سپس با استفاده از اطلاعات رمز جدید مجدداً سهامگذاری کنند.
-
-
-
-
-اگر بخشی از یک استخر سهامگذاری هستید یا توکنهای سهامگذاری را نگه میدارید، باید با ارائهدهنده خود درباره جزئیات بیشتر مربوط به نحوه انجام برداشتهای سهامگذاری مشورت کنید، چون هر سرویس رویکرد متفاوتی دارد.
-
-در کل، کاربران باید آزاد باشند اتر سهامگذاری شده خود را پس بگیرند، یا اینکه ارائهدهنده مورد استفاده خود را تغییر دهند. اگر یک استخر خاص بیش از حد بزرگ شود، وجوه را میتوان خارج کرد، بازخرید کرد، و دوباره با یک ارائهدهنده کوچکتر سهامگذاری کرد. یا، اگر اتر کافی جمعآوری کردهاید میتوانید بروید سراغ سهامگذاری در خانه.
-
-
-
-
-بله، تا زمانی که اعتبارسنج شما یک آدرس برداشت ارائه کرده باشد. این باید یک بار ارائه شود تا در ابتدا هر شکلی از برداشت را فعال کند، سپس پرداختهای پاداش به طور خودکار هر چند روز یکبار با هر جابجایی اعتبارسنج فعال میشوتد.
-
-
-
-
-نه، اگر اعتبارسنج شما همچنان در شبکه فعال باشد، برداشت کامل به صورت خودکار انجام نخواهد شد. این امر مستلزم آغاز دستی یک خروج داوطلبانه است.
-
-به محض اینکه اعتبارسنج فرایند خروج را تکمیل کرد و با فرض اینکه حساب دارای اطلاعات رمز برداشت است، باقیمانده موجودی سپس در طی انتقال اعتبارسنج بعدی برداشت خواهد شد.
-
-
-
-
-برداشتها به گونهای طراحی شدهاند که بهطور خودکار انجام می شوند و هر اتر را که به طور فعال در سهامگذاری مشارکت ندارد منتقل میکنند. این امر شامل تمام موجودی حسابهایی است که فرایند خروج را تکمیل کردهاند.
-
-امکان درخواست دستی مقادیر خاصی از اتر برای برداشت وجود ندارد.
-
-
-
-
-به اپراتورهای اعتبارسنج توصیه میشود که صفحه برداشتهای پلتفرم سهامگذاری را مشاهده کنند، که در آن جزئیات بیشتری در مورد نحوه آمادهسازی اعتبارسنج خود برای برداشت، زمان رویدادها، و جزئیات بیشتر در مورد نحوه عملکرد برداشت ها پیدا خواهند کرد.
-
-برای اینکه ابتدا تنظیمات خود را در یک شبکه تست امتحان کنید، برای شروع به پلتفرم سهامگذاری شبکه تستHolesky مراجعه کنید.
-
-
-
-
-خیر. به محض اینکه یک اعتبارسنج خارج شود و موجودی کامل آن برداشت شود، هرگونه وجوه اضافی که به آن اعتبارسنج سپرده میشود، بهطور خودکار به آدرس برداشت منتقل خواهد شد. برای سهامگذاری مجدد اتر، یک اعتبارسنج جدید باید فعال شود.
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [برداشتهای سکوی پرتاب سهامگذاری](https://launchpad.ethereum.org/withdrawals)
-- [پروتکل EIP-4895: برداشتهای زنجیره بیکن بهعنوان عملیاتها](https://eips.ethereum.org/EIPS/eip-4895)
-- [تیم ویراستاران اتریوم - شانگهای](https://www.ethereumcatherders.com/shanghai_upgrade/index.html)
-- [PEEPanEIP شماره 94: برداشت اتر سهامگذاری شده (آزمایشی) با Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE)
-- [PEEPanEIP شماره 68: پیشنهاد شماره 4895: زنجیره بیکن برداشتها را بهعنوان عملیات با Alex Stokes مخابره میکند](https://www.youtube.com/watch?v=CcL9RJBljUs)
-- [آشنایی با موجودی مؤثر اعتبارسنج](https://www.attestant.io/posts/understanding-validator-effective-balance/)
diff --git a/public/content/translations/fa/08) Use cases 2/decentralized-identity/index.md b/public/content/translations/fa/08) Use cases 2/decentralized-identity/index.md
deleted file mode 100644
index 5c9214d1e3d..00000000000
--- a/public/content/translations/fa/08) Use cases 2/decentralized-identity/index.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: هویت نامتمرکز
-description: هویت نامتمرکز چیست و چرا اهمیت دارد؟
-lang: fa
-template: use-cases
-emoji: ":id:"
-sidebarDepth: 2
-image: /images/eth-gif-cat.png
-summaryPoint1: سیستم های هویت صنعتی صدور، نگهداری و کنترل شناسه های شما را متمرکز کرده اند.
-summaryPoint2: هویت نامتمرکز اتکا، اشخاص ثالث متمرکز را از بین می برد.
-summaryPoint3: به لطف رمزنگاری، کاربران اکنون ابزارهایی برای صدور، نگهداری و کنترل مجدد شناسه ها و گواهی های خود دارند.
----
-
-هویت امروزه تقریباً زیربنای همه جنبه های زندگی شماست. استفاده از خدمات آنلاین، افتتاح حساب بانکی، رای دادن در انتخابات، خرید ملک، تضمین شغل - همه این موارد مستلزم اثبات هویت شماست.
-
-با این حال، سیستمهای مدیریت هویت سنتی مدتها به واسطههای متمرکز که شناسهها و [تأییدات](/glossary/#attestation) شما را صادر، نگهداری و کنترل میکنند، متکی بودهاند. این بدان معنی است که شما نمی توانید اطلاعات مربوط به هویت خود را کنترل کنید یا تصمیم بگیرید که چه کسی به اطلاعات هویتی شخصی (PII) و میزان دسترسی این افراد دسترسی دارد.
-
-برای حل این مشکلات، سیستمهای هویت غیرمتمرکز ساخته شده بر روی بلاک چینهای عمومی مانند اتریوم را داریم. هویت غیرمتمرکز به افراد اجازه می دهد تا اطلاعات مربوط به هویت خود را مدیریت کنند. با راهحلهای هویت غیرمتمرکز، _شما_ میتوانید شناسه ایجاد کنید و بدون تکیه بر مقامات مرکزی، مانند ارائهدهندگان خدمات یا دولتها، گواهینامههای خود را ادعا و نگهداری کنید.
-
-## هویت چیست? {#what-is-identity}
-
-هویت به معنای احساس یک فرد از خود است که با ویژگی های منحصر به فرد تعریف می شود. هویت به _فرد_ بودن اشاره دارد، یعنی یک موجود انسانی متمایز. هویت همچنین می تواند به سایر نهادهای غیرانسانی مانند یک سازمان یا مقام اشاره کند.
-
-
-
-## شناسه ها چیست? {#what-are-identifiers}
-
-شناسه قطعه ای اطلاعات است که به عنوان نشانگر هویت یا هویت های خاص عمل می کند. شناسه های رایج عبارتند از:
-
-- نام
-- شماره تامین اجتماعی/شماره شناسه مالیاتی
-- شماره تلفن همراه
-- تاریخ و محل تولد
-- مدارک شناسایی دیجیتال، به عنوان مثال، آدرس های ایمیل، نام های کاربری، آواتارها
-
-این نمونه های سنتی شناسه ها توسط نهادهای مرکزی صادر، نگهداری و کنترل می شوند. برای تغییر نام تان، به اجازه دولت یا اجازه یک پلتفرم رسانه اجتماعی برای تغییر نام کاربری تان نیاز دارید.
-
-## مزایای هویت غیرمتمرکز {#benefits-of-decentralized-identity}
-
-1. هویت غیرمتمرکز کنترل فردی اطلاعات شناسایی را افزایش می دهد. شناسه ها و تصدیق های غیرمتمرکز را می توان بدون اتکا به مقامات متمرکز و خدمات شخص ثالث تأیید کرد.
-
-2. راهحلهای هویت غیرمتمرکز، روشی بدون نیاز به اعتماد، بدون درز و حفاظت از حریم خصوصی را برای تأیید و مدیریت هویت کاربر تسهیل میکند.
-
-3. هویت غیرمتمرکز از فناوری بلاک چین استفاده میکند که اعتماد بین طرفهای مختلف ایجاد میکند و تضمینهای رمزنگاری را برای اثبات اعتبار تصدیقها ارائه میکند.
-
-4. هویت غیرمتمرکز داده های هویت را قابل حمل می کند. کاربران گواهیها و شناسهها را در کیف پول موبایل ذخیره میکنند و میتوانند با هر طرفی که انتخاب میکنند به اشتراک بگذارند. شناسه ها و تصدیقهای غیرمتمرکز در پایگاه داده سازمان صادر کننده قفل نمی شوند.
-
-5. هویت غیرمتمرکز باید با فناوریهای نوظهور [دانش صفر](/glossary/#zk-proof) به خوبی کار کند که افراد را قادر خواهند ساخت ثابت کنند مالک یک چیز هستند یا یک کار را انجام داده اند، بدون افشای ماهیت آن. این می تواند راهی قدرتمند برای ترکیب اعتماد و حریم خصوصی برای برنامه هایی مانند رای دادن باشد.
-
-6. هویت غیرمتمرکز مکانیزمهای [ضد سیبیل](/glossary/#anti-sybil) را قادر میسازد زمانی که یک نفر، برای بازی کردن یا ارسال هرزنامه به یک سیستم، تظاهر میکند چند نفر است، تشخیص دهد.
-
-## موارد استفاده هویت غیرمتمرکز {#decentralized-identity-use-cases}
-
-هویت غیرمتمرکز موارد استفاده بالقوه زیادی دارد:
-
-### 1. لاگین های همگانی {#universal-dapp-logins}
-
-هویت غیرمتمرکز میتواند به جایگزینی ورودهای مبتنی بر رمز عبور با احراز هویت غیرمتمرکز کمک کند. ارائه دهندگان خدمات می توانند تصدیق هایی را برای کاربران صادر کنند که می توانند در کیف پول اتریوم ذخیره شوند. یک تایید نمونه، می تواند یک [NFT](/glossary/#nft) باشد که به دارنده اجازه دسترسی به یک انجمن آنلاین را می دهد.
-
-سپس یک تابع [Sign-In with Ethereum](https://login.xyz/) سرورها را قادر میسازد تا حساب اتریوم کاربر را تأیید کنند و گواهی لازم را از آدرس حساب خود دریافت کنند. این بدان معناست که کاربران می توانند بدون نیاز به حفظ رمزهای عبور طولانی به پلتفرم ها و وب سایت ها دسترسی داشته باشند و این تجربه آنلاین را برای کاربران بهبود می بخشد.
-
-### 2. احراز هویت KYC {#kyc-authentication}
-
-استفاده از بسیاری از خدمات آنلاین، افراد را ملزم به ارائه تصدیق ها و اعتبارنامه هایی مانند گواهینامه رانندگی یا پاسپورت ملی می کند. اما این رویکرد مشکل ساز است زیرا اطلاعات خصوصی کاربر می تواند به خطر بیفتد و ارائه دهندگان خدمات نمی توانند صحت تصدیق را تأیید کنند.
-
-هویت غیرمتمرکز به شرکتها این امکان را میدهد که از فرآیندهای معمول [Know-Your-Customer (KYC)](https://en.wikipedia.org/wiki/Know_your_customer) صرفنظر کنند و هویت کاربر را از طریق اعتبارنامههای قابل تأیید احراز هویت کنند. این امر هزینه مدیریت هویت را کاهش می دهد و از استفاده از اسناد جعلی جلوگیری می کند.
-
-### 3. رای گیری و کامیونیتیهای آنلاین {#voting-and-online-communities}
-
-رای گیری آنلاین و سوشال مدیا دو کاربرد جدید برای هویت غیرمتمرکز هستند. طرحهای رایگیری آنلاین مستعد دستکاری هستند، بهویژه اگر بازیگران بدخواه برای رای دادن هویتهای جعلی ایجاد کنند. درخواست از افراد برای ارائه تصدیق های آنچین می تواند یکپارچگی فرآیندهای رای گیری آنلاین را بهبود بخشد.
-
-هویت غیرمتمرکز می تواند به ایجاد کامیونیتیهای آنلاینی که عاری از حساب های جعلی هستند کمک کند. به عنوان مثال، هر کاربر ممکن است مجبور باشد هویت خود را با استفاده از یک سیستم هویت آنچین، مانند سرویس نام اتریوم، احراز هویت کند، که احتمال وجود ربات ها را کاهش می دهد.
-
-### 4. محافظت ضد سیبیل {#sybil-protection}
-
-برنامههای اعطای کمک هزینه که از [رایگیری درجه دوم](/glossary/#quadratic-voting) استفاده میکنند در برابر [حملات سیبیل](/glossary/#sybil-attack) آسیبپذیر هستند، زیرا ارزش کمک هزینه زمانی افزایش مییابد که افراد بیشتری به آن رأی میدهند و کاربران را تشویق میکند تا مشارکتهای خود را در بسیاری از هویتها تقسیم کنند. هویتهای غیرمتمرکز با بالا بردن بار روی دوش هر شرکتکننده برای اثبات اینکه واقعاً انسان هستند، به جلوگیری از این امر کمک میکند، هرچند اغلب بدون نیاز به افشای اطلاعات خصوصی خاص.
-
-## گواهینامه ها چیست? {#what-are-attestations}
-
-تصدیق ادعایی است که توسط یک نهاد در مورد موجودیت دیگر مطرح می شود. اگر در ایالات متحده زندگی می کنید، گواهینامه رانندگی که توسط وزارت وسایل نقلیه موتوری (یک نهاد) برای شما صادر می شود، گواهی می دهد که شما (یک نهاد دیگر) به طور قانونی مجاز به رانندگی یک ماشین هستید.
-
-گواهی ها با شناسه ها متفاوت است. یک گواهی _شامل_ شناسه هایی برای ارجاع به یک هویت خاص است و ادعایی در مورد ویژگی مربوط به این هویت دارد. بنابراین، گواهینامه رانندگی شما دارای شناسه (نام، تاریخ تولد، آدرس) است، اما همچنین گواهی حق قانونی شما برای رانندگی است.
-
-### شناسه های غیرمتمرکز چیست? {#what-are-decentralized-identifiers}
-
-شناسههای سنتی مانند نام قانونی یا آدرس ایمیل شما متکی به اشخاص ثالث - دولتها و ارائهدهندگان ایمیل هستند. شناسه های غیرمتمرکز (DID) متفاوت هستند - آنها توسط هیچ نهاد مرکزی صادر، مدیریت یا کنترل نمی شوند.
-
-شناسه های غیرمتمرکز توسط افراد صادر، نگهداری و کنترل می شوند. یک [حساب اتریوم](/glossary/#account) نمونهای از یک شناسه غیرمتمرکز است. شما می توانید هر تعداد حساب که می خواهید بدون اجازه کسی و بدون نیاز به ذخیره آنها در یک رجیستری مرکزی ایجاد کنید.
-
-شناسههای غیرمتمرکز در دفاتر کل توزیع شده ([بلاکچینها](/glossary/#blockchain)) یا [شبکههای همتا به همتا](/glossary/#peer-to-peer-network) ذخیره میشوند. این باعث میشود DIDها [در سطح جهانی منحصربهفرد، قابل حل با در دسترس بودن بالا، و از نظر رمزنگاری قابل تأیید](https://w3c-ccg.github.io/did-primer/) باشند. یک شناسه غیرمتمرکز میتواند با نهادهای مختلف، از جمله افراد، سازمانها یا مؤسسات دولتی مرتبط باشد.
-
-## چه چیزی شناسه های غیرمتمرکز را ممکن می کند? {#what-makes-decentralized-identifiers-possible}
-
-### 1. رمزنگاری کلید عمومی {#public-key-cryptography}
-
-رمزنگاری کلید عمومی یک اقدام امنیتی اطلاعاتی است که یک [کلید عمومی](/glossary/#public-key) و [کلید خصوصی](/glossary/#private-key) را برای یک نهاد ایجاد میکند. [رمزنگاری](/glossary/#cryptography) کلید عمومی در شبکههای بلاکچین برای احراز هویت کاربران و اثبات مالکیت داراییهای دیجیتال استفاده میشود.
-
-برخی از شناسه های غیرمتمرکز، مانند حساب اتریوم، دارای کلیدهای عمومی و خصوصی هستند. کلید عمومی کنترل کننده حساب را شناسایی می کند، در حالی که کلیدهای خصوصی می توانند پیام های این حساب را امضا و رمزگشایی کنند. رمزنگاری کلید عمومی با استفاده از [امضای رمزنگاری](https://andersbrownworth.com/blockchain/public-private-keys/) برای تأیید همه مطالبات، شواهد مورد نیاز برای احراز هویت، جلوگیری از جعل هویت، و استفاده از هویتهای جعلی را فراهم میسازد.
-
-### 2. داده های غیرمتمرکز {#decentralized-datastores}
-
-یک بلاک چین به عنوان یک رجیستری داده قابل تأیید عمل می کند: یک مخزن اطلاعات باز، غیرقابل اعتماد و غیرمتمرکز. وجود بلاک چین های عمومی نیاز به ذخیره شناسه ها در رجیستری های متمرکز را از بین می برد.
-
-اگر کسی نیاز به تایید اعتبار یک شناسه غیرمتمرکز داشته باشد، میتواند کلید عمومی مرتبط را در بلاک چین جستجو کند. این با شناسههای سنتی که برای احراز هویت به اشخاص ثالث نیاز دارند متفاوت است.
-
-## چگونه شناسهها و گواهیهای غیرمتمرکز هویت غیرمتمرکز را ممکن میسازند؟ {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
-
-هویت غیرمتمرکز این ایده است که اطلاعات مربوط به هویت باید خودکنترل، خصوصی و قابل حمل باشد و شناسه ها و گواهی های غیرمتمرکز بلوک های سازنده اولیه باشند.
-
-در زمینه هویت غیرمتمرکز، گواهیها (همچنین به عنوان [مدارک تأیید اعتبار](https://www.w3.org/TR/vc-data-model/) شناخته میشوند) ادعاهایی غیرقابل دستکاری و قابل تأیید رمزنگاری توسط صادرکننده هستند. هر تصدیق یا اعتبارنامه قابل تأیید یک ماهیت(به عنوان مثال، یک سازمان) با DID آنها مرتبط است.
-
-از آنجایی که DID ها در بلاک چین ذخیره می شوند، هر کسی می تواند اعتبار یک تصدیق را با بازبینی DID صادرکننده در اتریوم تأیید کند. اساساً، بلاک چین اتریوم مانند یک فهرست جهانی عمل می کند که تأیید DID های مرتبط با موجودیت های خاص را امکانپذیر می کند.
-
-شناسه های غیرمتمرکز دلیلی هستند که تصدیق ها خودکنترلی و قابل تأیید هستند. حتی اگر صادرکننده دیگر وجود نداشته باشد، هولدر همیشه مدرکی دال بر منشأ و اعتبار تصدیق دارد.
-
-شناسه های غیرمتمرکز نیز برای محافظت از حریم خصوصی اطلاعات شخصی از طریق هویت غیرمتمرکز بسیار مهم هستند. برای مثال، اگر فردی مدرکی مبنی بر تصدیق (گواهینامه رانندگی) ارائه دهد، طرف تأییدکننده نیازی به بررسی اعتبار اطلاعات موجود در مدرک ندارد. درعوض، تأییدکننده فقط به ضمانتهای رمزنگاری درباره اصالت تصدیق و هویت سازمان صادرکننده نیاز دارد تا تشخیص دهد که آیا مدرک معتبر است یا خیر.
-
-## انواع تصدیق در هویت غیرمتمرکز {#types-of-attestations-in-decentralized-identity}
-
-نحوه ذخیره و بازیابی اطلاعات تصدیق در اکوسیستم هویت مبتنی بر اتریوم با مدیریت هویت سنتی متفاوت است. در اینجا مروری بر رویکردهای مختلف برای صدور، ذخیره و تأیید تصدیق در سیستمهای هویت غیرمتمرکز است:
-
-### تصدیق های خارج از زنجیره {#off-chain-attestations}
-
-یکی از نگرانیهای مربوط به ذخیره تصدیق ها بهصورت آنچین این است که ممکن است حاوی اطلاعاتی باشند که افراد بخواهند خصوصی نگه دارند. ماهیت عمومی بلاک چین اتریوم، ذخیره چنین تصدیقهایی را جذاب نمیکند.
-
-راه حل، صدور گواهی است که توسط کاربران خارج از زنجیره در کیف پول های دیجیتال نگهداری می شود، اما با DID صادرکننده که بهصورت آنچین ذخیره می شود، امضا شده است. این تصدیقها بهعنوان [JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token) کدگذاری میشوند و حاوی امضای دیجیتال صادرکننده هستند—که امکان تأیید آسان ادعاهای خارج از زنجیره را فراهم میکند.
-
-در اینجا یک سناریوی فرضی برای توضیح تصدیقهای خارج از زنجیره وجود دارد:
-
-1. یک دانشگاه (صادرکننده) یک تصدیق (گواهی علمی دیجیتالی) تولید می کند، کلیدهای آن را امضا می کند و آن را برای باب (صاحب هویت) صادر می کند.
-
-2. باب برای کار درخواست میکند و میخواهد مدارک تحصیلی خود را به یک کارفرما ثابت کند، بنابراین تصدیق را از کیف پول تلفن همراه خود به اشتراک میگذارد. سپس شرکت (تأیید کننده) میتواند اعتبار تصدیق را با بررسی DID صادرکننده (یعنی کلید عمومی آن در اتریوم) تأیید کند.
-
-### تصدیق های خارج از زنجیره با دسترسی مداوم {#offchain-attestations-with-persistent-access}
-
-به این ترتیب، تصدیقها به فایلهای JSON تبدیل میشوند و خارج از زنجیره ذخیره میشوند (به طور ایدهآل در یک پلتفرم [ذخیرهسازی غیرمتمرکز ابر](/developers/docs/storage/)، مانند IPFS یا Swarm). با این حال، یک [هش](/glossary/#hash) از فایل JSON در زنجیره ذخیره میشود و از طریق یک رجیستری در زنجیره به یک DID مرتبط میشود. DID مرتبط میتواند صادرکننده تصدیق یا گیرنده باشد.
-
-این رویکرد تصدیقها را قادر میسازد تا پایداری مبتنی بر بلاک چین را به دست آورند، در حالی که اطلاعات ادعاها را رمزگذاری شده و قابل تأیید نگه میدارد. همچنین امکان افشای انتخابی را فراهم می کند زیرا دارنده کلید خصوصی می تواند اطلاعات را رمزگشایی کند.
-
-### تصدیقهای آنچین {#onchain-attestations}
-
-تصدیقهای روی زنجیره در [قراردادهای هوشمند](/glossary/#smart-contract) در بلاکچین اتریوم نگهداری میشوند. قرارداد هوشمند (که به عنوان یک رجیستری عمل می کند) یک تصدیق را به یک شناسه غیرمتمرکز آنچین مربوطه (یک کلید عمومی) متصل می کند.
-
-در اینجا یک مثال برای نشان دادن نحوه عملکرد تصدیقهای آنچین در عمل آورده شده است:
-
-1. یک شرکت (XYZ Corp) قصد دارد سهام مالکیت خود را با استفاده از یک قرارداد هوشمند بفروشد اما فقط خریدارانی را می خواهد که بررسی پیشینه را تکمیل کرده باشند.
-
-2. XYZ Corp میتواند شرکت را وادار کند که بررسیهای پیشینه را برای صدور تصدیقهای آنچین در اتریوم انجام دهد. این گواهی تأیید می کند که یک فرد بدون افشای هیچ گونه اطلاعات شخصی، بررسی پیشینه را گذرانده است.
-
-3. قرارداد هوشمند فروش سهام می تواند قرارداد ثبت را برای هویت خریداران غربال شده بررسی کند و این امکان را برای قرارداد هوشمند تعیین کند که چه کسی مجاز به خرید سهام است یا خیر.
-
-### توکنهای Soulbound و هویت {#soulbound}
-
-[توکنهای انحصاری](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([NFTهای غیرقابل انتقال](/glossary/#nft)) میتوانند برای جمعآوری اطلاعاتِ انحصاری یک کیفپول خاص استفاده شوند. این به طور مؤثر یک هویت آنچین منحصر به فرد ایجاد می کند که به یک آدرس اتریوم خاص متصل می شود که می تواند شامل توکن هایی باشد که دستاوردها را نشان می دهد (به عنوان مثال اتمام یک دوره آنلاین خاص یا گذراندن یک امتیاز آستانه در یک بازی) یا مشارکت کامیونیتی.
-
-## از هویت غیرمتمرکز استفاده کنید {#use-decentralized-identity}
-
-پروژه های جاه طلبانه زیادی وجود دارد که از اتریوم به عنوان پایه ای برای راه حل های هویت غیرمتمرکز استفاده می کنند:
-
-- **[Ethereum Name Service (ENS)](https://ens.domains/)** - _یک سیستم نامگذاری غیرمتمرکز برای شناسههای روی زنجیره، قابل خواندن توسط ماشین، مانند آدرسهای کیف پول اتریوم، هش محتوا و ابرداده._
-- **[SpruceID](https://www.spruceid.com/)** - _یک پروژه هویت غیرمتمرکز که به کاربران امکان می دهد به جای تکیه بر خدمات شخص ثالث هویت دیجیتال را با حساب های اتریوم و پروفایل های ENS کنترل کنند._
-- **[خدمات گواهی اتریوم (EAS)](https://attest.sh/)** - _یک دفتر کل/پروتکل غیرمتمرکز برای ایجاد گواهیهای زنجیرهای یا خارج از زنجیره درباره هر چیزی._
-- **[Proof of Humanity](https://www.proofofhumanity.id)** - _Proof of Humanity (یا PoH) یک سیستم تأیید هویت اجتماعی است که بر روی اتریوم ساخته شده است._
-- **[BrightID](https://www.brightid.org/)** - _یک شبکه هویت اجتماعی غیرمتمرکز و منبع باز که به دنبال اصلاح تأیید هویت از طریق ایجاد و تجزیه و تحلیل یک نمودار اجتماعی است._
-- **[walt.id](https://walt.id)** — _هویت و زیرساخت کیفپول غیرمتمرکز منبع باز که به توسعهدهندگان و سازمانها این امکان را میدهد تا از هویت مستقل و NFT/SBT استفاده کنند._
-- **[Veramo](https://veramo.io/)** - _یک چارچوب جاوا اسکریپت است که استفاده از داده های قابل تأیید از لحاظ رمزنگاری را در برنامههای خود برای هر کس آسان میسازد._
-
-## بیشتر بخوانید {#further-reading}
-
-### مقالات {#articles}
-
-- [موارد استفاده از بلاک چین: بلاک چین در هویت دیجیتال](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_
-- [اتریوم ERC725 چیست؟ مدیریت هویت خودمختار در بلاک چین](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _سام تاون_
-- [چگونه بلاک چین می تواند مشکل هویت دیجیتال را حل کند](https://time.com/6142810/proof-of-humanity/) — _اندرو آر. چاو_
-- [هویت غیرمتمرکز چیست و چرا باید به آن اهمیت دهید؟](https://web3.hashnode.com/what-is-decentralized-identity) _آووسیکا_
-- [مقدمهای بر هویت غیرمتمرکز](https://walt.id/white-paper/digital-identity) - به قلم _دومینیک برون_
-
-### ویدیوها {#videos}
-
-- [هویت غیرمتمرکز (جلسه پخش زنده جایزه)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) - _یک ویدیوی توضیح دهنده عالی در مورد هویت غیرمتمرکز توسط آندریاس آنتونوپولوس_
-- [ورود با اتریوم و هویت غیرمتمرکز با Ceramic، IDX، React و 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _آموزش YouTube در مورد ایجاد یک سیستم مدیریت هویت برای ایجاد، خواندن و به روز رسانی نمایه کاربر با استفاده از کیف پول اتریوم توسط نادر دبیت_
-- [BrightID - هویت غیرمتمرکز در اتریوم](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _قسمت پادکست بدون بانک در مورد BrightID، یک راه حل هویت غیرمتمرکز برای اتریوم_
-- [اینترنت خارج از زنجیره: هویت غیرمتمرکز & اعتبار قابل تأیید](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — ارائه EthDenver 2022 توسط Evin McMullen
-- [تشریح اعتبارنامه های قابلاحراز](https://www.youtube.com/watch?v=ce1IdSr-Kig) - ویدیو توضیحی یوتیوب همراه با نسخه آزمایشی از تامینو باومن
-
-### جوامع {#communities}
-
-- [اتحاد ERC-725 در GitHub](https://github.com/erc725alliance) — _حامی استاندارد ERC725 برای مدیریت هویت در بلاک چین اتریوم_
-- [سرور SpruceID Discord](https://discord.com/invite/Sf9tSFzrnt) — _انجمن برای علاقه مندان و توسعه دهندگانی که روی ورود به سیستم با اتریوم_کار می کنند
-- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _جامعه ای از توسعه دهندگان که در ساخت چارچوبی برای داده های قابل تأیید برای برنامه ها مشارکت دارند_
-- [walt.id](https://discord.com/invite/AW8AgqJthZ) — _جامعهای از توسعهدهندگان و سازندگان که بر روی موارد استفاده از هویت غیرمتمرکز در صنایع مختلف کار میکنند_
diff --git a/public/content/translations/fa/08) Use cases 2/desci/index.md b/public/content/translations/fa/08) Use cases 2/desci/index.md
deleted file mode 100644
index 9e0160ec762..00000000000
--- a/public/content/translations/fa/08) Use cases 2/desci/index.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: دانش غیرمتمرکز (DeSci)
-description: مروری بر علم غیرمتمرکز در اتریوم
-lang: fa
-template: use-cases
-emoji: ":microscope:"
-sidebarDepth: 2
-image: /images/future_transparent.png
-alt: ""
-summaryPoint1: یک جایگزین جهانی و باز برای سیستم علمی فعلی.
-summaryPoint2: فناوری که دانشمندان را قادر میسازد بودجه جمعآوری کنند، آزمایشها را انجام دهند، دادهها را به اشتراک بگذارند، بینشها را توزیع کنند و موارد دیگر.
-summaryPoint3: بر اساس جنبش علم باز است.
----
-
-## علم غیرمتمرکز (DeSci) چیست؟ {#what-is-desci}
-
-دانش غیرمتمرکز (DeSci) جنبشی است که هدف آن ایجاد زیرساخت عمومی برای تأمین مالی، ایجاد، بررسی، اعتباردهی، ذخیره و انتشار دانش علمی به طور عادلانه و مساوی با استفاده از پشته [Web3](/glossary/#web3) است.
-
-هدف DeSci ایجاد اکوسیستمی است که در آن دانشمندان تشویق می شوند تا تحقیقات خود را آشکارا به اشتراک بگذارند و اعتبار کار خود را دریافت کنند و در عین حال به هر کسی اجازه دهد به راحتی به تحقیق دسترسی داشته باشد و در آن مشارکت کند. DeSci از این ایده استفاده می کند که دانش علمی باید در دسترس همه باشد و روند تحقیقات علمی باید شفاف باشد. DeSci در حال ایجاد یک مدل تحقیقات علمی غیرمتمرکز و توزیعشدهتر است و آن را در برابر سانسور و کنترل مقامات مرکزی مقاومتر میکند. DeSci امیدوار است با غیرمتمرکز کردن دسترسی به بودجه، ابزارهای علمی و کانال های ارتباطی، محیطی ایجاد کند که در آن ایده های جدید و غیر متعارف شکوفا شوند.
-
-علم غیرمتمرکز، امکان منابع مالی متنوعتر (از [DAO](/glossary/#dao), [اعانه های درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) تا تأمین مالی جمعی و غیره)، دادهها و روشهای قابل دسترس تر، و همراه با ارائه انگیزههایی برای تکثیرپذیری را فراهم می سازد.
-
-### خوان بنت - جنبش DeSci
-
-
-
-## چگونه DeSci علم را بهبود می بخشد {#desci-improves-science}
-
-فهرست ناقصی از مشکلات کلیدی در علم و اینکه چگونه علم غیرمتمرکز می تواند به رفع این مسائل کمک کند
-
-| **علم غیرمتمرکز** | **علم سنتی** |
-| ---------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| توزیع وجوه **توسط عموم** و با استفاده از مکانیسم هایی مانند اعانه های درجه دوم یا DAO ها تعیین می شود. | گروه های کوچک، بسته و **متمرکز** توزیع وجوه را کنترل می کنند. |
-| شما با همتایانی از **سراسر جهان** در تیمهای پویا همکاری میکنید. | سازمانهای تأمین مالی و مؤسسات خانگی همکاریهای شما را **محدود میکنند**. |
-| تصمیمات تامین مالی به صورت آنلاین و **شفاف** اتخاذ میشوند. مکانیسم های تامین مالی جدید بررسی شده است. | تصمیمات تامین مالی با مدت زمان طولانی و **شفافیت محدود** اتخاذ میشوند. مکانیسم های مالی کمی وجود دارد. |
-| اشتراکگذاری خدمات آزمایشگاهی با استفاده از فناوری [Web3](/glossary/#web3) آسانتر و شفافتر شده است. | اشتراکگذاری منابع آزمایشگاهی اغلب **کُند و مبهم** است. |
-| **مدلهای جدیدی برای انتشار** میتوانند ایجاد شوند که از اصول اولیه Web3 برای اعتماد، شفافیت و دسترسی جهانی استفاده میکنند. | شما از طریق مسیرهای مشخصی که اغلب به عنوان **ناکارآمد، مغرضانه و استثمارگر** شناخته می شوند منتشر میکنید. |
-| میتوانید برای کار **بررسی همتایان، توکن و شهرت کسب کنید**. | **کار بررسی همتایان بدون دستمزد**، و به نفع ناشران انتفاعی است. |
-| **شما دارای مالکیت معنوی (IP) هستید** که بر اساس شرایط شفاف، تولید و توزیع میکنید. | **موسسه خانگی شما مالک IP است** که ایجاد میکنید. دسترسی به IP شفاف نیست. |
-| **اشتراکگذاری همه تحقیقات**، از جمله دیتای حاصل از تلاشهای ناموفق، با انجام تمام مراحل روی زنجیره. | **سوگیری انتشار** به این معنی است که محققان غالباً آزمایشهایی را به اشتراک میگذارند که نتایج موفقیتآمیزی داشتهاند. |
-
-## اتریوم و DeSci {#ethereum-and-desci}
-
-یک سیستم علمی غیرمتمرکز به امنیت قوی، حداقل هزینه های پولی و معاملاتی و یک اکوسیستم غنی برای توسعه برنامه نیاز دارد. اتریوم همه چیز مورد نیاز برای ساخت یک فناوری دانش غیرمتمرکز را فراهم میکند.
-
-## موارد استفاده DeSci {#use-cases}
-
-DeSci در حال ساخت مجموعه ابزارهای علمی برای ورود آکادمی های سنتی به دنیای دیجیتال است. در زیر نمونهای از موارد استفاده است که Web3 میتواند به جامعه علمی ارائه دهد.
-
-### انتشار {#publishing}
-
-انتشار علم بسیار مشکل ساز است زیرا توسط مؤسسات انتشاراتی مدیریت می شود که برای تولید مقالات به نیروی کار رایگان دانشمندان، داوران و ویراستاران متکی هستند اما پس از آن هزینه های گزافی برای انتشار دریافت می کنند. عموم مردم که معمولاً به طور غیرمستقیم برای اثر و هزینه های انتشار از طریق مالیات پرداخت کرده اند، اغلب نمی توانند بدون پرداخت مجدد به ناشر به همان اثر دسترسی داشته باشند. مجموع هزینههای انتشار مقالات علمی منفرد اغلب پنج رقمی است ($USD) که کل مفهوم دانش علمی بهعنوان [کالای عمومی](/glossary/#public-goods) را تضعیف میکند، در عین حال سود زیادی را برای گروه کوچکی از ناشران ایجاد میکند.
-
-پلتفرمهای رایگان و دسترسی آزاد به شکل سرورهای پیش چاپ، [مانند ArXiv](https://arxiv.org/)وجود دارند. با این حال، این پلتفرمها فاقد کنترل کیفیت، [مکانیسمهای ضد سیبیل](/glossary/#anti-sybil)هستند و معمولاً معیارهای سطح مقاله را ردیابی نمیکنند، به این معنی که معمولاً فقط برای تبلیغ کار قبل از ارسال به یک ناشر سنتی استفاده میشوند. SciHub همچنین دسترسی به مقالات منتشر شده را رایگان می کند، اما نه به صورت قانونی، و تنها پس از اینکه ناشران قبلاً پرداخت خود را دریافت کرده و اثر را در قوانین سخت گیرانه حق چاپ قرار داده باشند. این یک شکاف مهم برای مقالات و داده های علمی قابل دسترس با مکانیزم مشروعیت تعبیه شده و مدل انگیزشی باقی می گذارد. ابزار ساخت چنین سیستمی در Web3 وجود دارد.
-
-### تکرارپذیری و تکرارپذیری {#reproducibility-and-replicability}
-
-تکرارپذیری و تکرارپذیری پایه های اکتشاف علمی با کیفیت هستند.
-
-- نتایج قابل تکرار را می توان چندین بار متوالی توسط یک تیم با استفاده از روش یکسان به دست آورد.
-- نتایج قابل تکرار را می توان توسط گروهی متفاوت با استفاده از تنظیمات آزمایشی یکسان به دست آورد.
-
-ابزارهای جدید وب 3 می توانند اطمینان حاصل کنند که تکرارپذیری و تکرارپذیری اساس کشف هستند. ما میتوانیم علم با کیفیت را در تار و پود فناوری دانشگاه ببافیم. Web3 توانایی ایجاد [تاییدها](/glossary/#attestation) برای هر جزئی از تجزیه و تحلیل را ارائه میکند: داده خام، موتور محاسباتی، و نتیجه برنامه. زیبایی سیستمهای اجماع در این است که وقتی یک شبکه قابل اعتماد برای حفظ این اجزا ایجاد میشود، هر یک از شرکتکنندگان شبکه میتوانند مسئول بازتولید محاسبات و اعتبارسنجی هر نتیجه باشند.
-
-### منابع مالی {#funding}
-
-مدل استاندارد فعلی برای تأمین مالی علم این است که افراد یا گروههایی از دانشمندان درخواستهای کتبی برای یک آژانس تأمین مالی میکنند. گروه کوچکی از افراد مورد اعتماد درخواست ها را نمره گذاری می کنند و سپس با نامزدها قبل از اعطای بودجه به بخش کوچکی از متقاضیان مصاحبه می کنند. گذشته از ایجاد تنگناهایی که گاهی اوقات منجر به **سالها انتظار** بین درخواست و دریافت کمک هزینه میشود، این مدل به شدت در برابر **سوگیریها، منافع شخصی و سیاستهای** هیئت بررسی آسیبپذیر است.
-
-مطالعات نشان داده اند که پانل های بررسی کمک هزینه در انتخاب پیشنهادهای با کیفیت بالا کار ضعیفی انجام می دهند، زیرا همان پیشنهادات ارائه شده به پانل های مختلف نتایج بسیار متفاوتی دارند. از آنجایی که بودجه کمیابتر شده است، این بودجه در مجموعه کوچکتری از محققان ارشد با پروژههای محافظهکارانهتر متمرکز شده است. این اثر یک چشم انداز سرمایه گذاری بیش از حد رقابتی ایجاد کرده است، انگیزه های انحرافی را تقویت می کند و نوآوری را خفه می کند.
-
-Web3 این پتانسیل را دارد که با آزمایش مدلهای انگیزشی مختلف که توسط DAOs و Web3 به طور گسترده ایجاد شدهاند، این مدل بودجه شکسته را مختل کند. [تأمین مالی ماسبق برای کالاهای عمومی](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) و [تأمین مالی درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) و [حاکمیت DAO](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) و [ساختارهای تشویقی توکنیزه شده](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) ساختارهای تشویقی توکنیزه شده، برخی از ابزارهای Web3 هستند که می توانند تأمین مالی علمی را متحول کنند.
-
-### مالکیت و توسعه IP {#ip-ownership}
-
-مالکیت فکری (IP) یک مشکل بزرگ در علم سنتی است: از گیر افتادن در دانشگاه ها یا استفاده نشدن در بیوتکنولوژی گرفته تا ارزش گذاری بسیار سخت. با این حال، مالکیت داراییهای دیجیتال (مانند دادههای علمی یا مقالات) چیزی است که Web3 با استفاده از [توکنهای غیرقابل معاوضه (NFT)](/glossary/#nft) به خوبی انجام میدهد.
-
-همانطور که NFTها می توانند درآمد معاملات آتی را به سازنده اصلی بازگردانند، شما می توانید زنجیره های انتساب ارزش شفاف را برای پاداش دادن به محققان، نهادهای حاکم (مانند DAO) یا حتی افرادی که داده های آنها جمع آوری شده است ایجاد کنید.
-
-[IP-NFT](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) همچنین می تواند به عنوان کلیدی برای مخزن داده های غیرمتمرکز آزمایش های تحقیقاتی در حال انجام عمل کند و به NFT و [DeFi](/glossary/#defi) مالی (از تقسیم بندی تا استخرهای وام دهی و ارزشیابی) متصل شود. همچنین به نهادهای داخلی زنجیره ای مانند DAO مانند [VitaDAO](https://www.vitadao.com/) اجازه می دهد تا تحقیقات را مستقیماً روی زنجیره انجام دهند. ظهور [توکنهای «انحصاری»](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) غیرقابل انتقال نیز ممکن است نقش مهمی در DeSci ایفا کند و به افراد اجازه میدهد تا تجربه و اعتبار خود مرتبط با آدرس اتریوم خود را ثابت کنند.
-
-### ذخیره سازی داده ها، دسترسی و معماری {#data-storage}
-
-داده های علمی را می توان با استفاده از الگوهای Web3 بسیار در دسترس تر کرد و ذخیره سازی توزیع شده تحقیقات را قادر می سازد تا از رویدادهای فاجعه بار جان سالم به در ببرد.
-
-نقطه شروع باید سیستمی باشد که توسط هر هویت غیرمتمرکزی که دارای اعتبارنامه های قابل تایید مناسب است، قابل دسترسی باشد. این اجازه میدهد تا دادههای حساس بهطور ایمن توسط طرفهای مورد اعتماد تکثیر شوند و مقاومت در برابر افزونگی و سانسور، بازتولید نتایج، و حتی امکان همکاری چندین طرف و افزودن دادههای جدید به مجموعه داده را ممکن میسازد. روشهای محاسباتی محرمانه مانند [محاسبه به داده](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol) مکانیسمهای دسترسی جایگزین را برای تکرار دادههای خام فراهم میکنند و محیطهای تحقیقاتی مورد اعتماد را برای حساسترین دادهها ایجاد میکنند. محیطهای تحقیقاتی مورد اعتماد توسط NHS [بهعنوان راهحلی آیندهنگر برای حفظ حریم خصوصی دادهها و همکاری با ایجاد یک اکوسیستم که در](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) محققان میتوانند به طور ایمن با دادهها در محل با استفاده از محیطهای استاندارد شده برای اشتراکگذاری کد و شیوهها کار کنند، ذکر شده است.
-
-راهحلهای داده انعطافپذیر Web3 از سناریوهای بالا پشتیبانی میکنند و پایهای را برای علوم باز واقعاً فراهم میکنند، جایی که محققان میتوانند کالاهای عمومی را بدون مجوز دسترسی یا هزینه ایجاد کنند. راه حل های داده عمومی Web3 مانند IPFS، Arweave و Filecoin برای تمرکززدایی بهینه شده اند. به عنوان مثال، dClimate دسترسی جهانی به داده های آب و هوا و آب و هوا، از جمله ایستگاه های هواشناسی و مدل های پیش بینی آب و هوا را فراهم می کند.
-
-## مشارکت کنید {#get-involved}
-
-پروژه ها را کاوش کنید و به جامعه DeSci بپیوندید.
-
-- [DeSci.Global: رویدادهای جهانی و تقویم ملاقات](https://desci.global)
-- [بلاک چین برای علم تلگرام](https://t.me/BlockchainForScience)
-- [Molecule: برای پروژه های تحقیقاتی خود بودجه و بودجه دریافت کنید](https://www.molecule.xyz/)
-- [VitaDAO: دریافت بودجه از طریق توافقنامه های تحقیقاتی حمایت شده برای تحقیقات طول عمر](https://www.vitadao.com/)
-- [ResearchHub: یک نتیجه علمی را ارسال کنید و با همتایان خود گفتگو کنید](https://www.researchhub.com/)
-- [LabDAO: یک پروتئین را در سیلیکو تا کنید](https://alphafodl.vercel.app/)
-- [dClimate API: دادههای آب و هوایی را که توسط یک جامعه غیرمتمرکز جمعآوری شده است، جستجو کنید](https://api.dclimate.net/)
-- [DeSci Foundation: سازنده ابزار انتشارات DeSci](https://descifoundation.org/)
-- [DeSci.World: فروشگاه تک مرحله ای برای مشاهده کاربران، درگیر شدن با علم غیرمتمرکز](https://desci.world)
-- [OceanDAO: DAO بر تأمین مالی علوم مرتبط با داده نظارت می کرد](https://oceanprotocol.com/)
-- [Opscientia: باز کردن گردش کار علمی غیرمتمرکز](https://opsci.io/research/)
-- [Bio.xyz: برای پروژه بیوتکنولوژی DAO یا desci خود بودجه دریافت کنید](https://www.bio.xyz/)
-- [پروتکل فلمینگ: اقتصاد داده منبع باز که به کشف مشترک زیست پزشکی کمک می کند](http://flemingprotocol.io/)
-- [موسسه استنتاج فعال](https://www.activeinference.org/)
-- [IdeaMarkets: امکان اعتبار علمی غیرمتمرکز](https://ideamarket.io/)
-- [DeSci Labs](https://www.desci.com/)
-- [ValleyDAO : یک اجتماع جهانی و باز که سرمایه گذاری و حمایت های انتقالی (قابل انتقال) برای تحقیقات زیستی (بیولوژی) ترکیبی ارئه می دهد](https://www.valleydao.bio)
-- [Cerebrum DAO : منبع یابی و راه حل های مفید برای سلامت مغز پیشرفته و جلوگیری از عصب تباهی (تخریب نورونی)](https://www.cerebrumdao.com/)
-- [CryoDAO: سرمایه گذاری پروژه های بلندپروازانه در حوزه ارز های دیجیتال](https://www.cryodao.org)
-
-ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط مشی فهرست [](/contributing/adding-desci-projects/) ما نگاه کنید!
-
-## بیشتر بخوانید {#further-reading}
-
-- [DeSci Wiki توسط Jocelynn Pearl and Ultrarare](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
-- [راهنمای بیوتکنولوژی غیرمتمرکز توسط Jocelynn Pearl برای آینده a16z](https://future.a16z.com/a-guide-to-decentralized-biotech/)
-- [مورد برای DeSci](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
-- [راهنمای DeSci](https://future.com/what-is-decentralized-science-aka-desci/)
-- [منابع علمی غیرمتمرکز](https://www.vincentweisser.com/decentralized-science)
-- [Molecule's Biopharma IP-NFTs - توضیحات فنی](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
-- [ساختن سیستم های بی اعتماد علم توسط جان استار](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [Paul Kohlhaas - DeSci: The Future of Science Decentralized (پادکست)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
-- [هستیشناسی استنتاج فعال برای علم غیرمتمرکز: از حسسازی موقعیتیافته تا عوام معرفتی](https://zenodo.org/record/6320575)
-- [DeSci: The Future of Research اثر ساموئل آکینوشو](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
-- [تامین مالی علم (پایان: DeSci و رمزارزهای اولیه) توسط نادیا](https://nadia.xyz/science-funding)
-- [عدم تمرکز توسعه دارو را مختل می کند](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
-
-### ویدیوها {#videos}
-
-- [علم غیرمتمرکز چیست؟](https://www.youtube.com/watch?v=-DeMklVWNdA)
-- [گفتگوی ویتالیک بوترین و دانشمند اوبری دو گری در مورد تلاقی تحقیقات طول عمر و رمزنگاری](https://www.youtube.com/watch?v=x9TSJK1widA)
-- [انتشارات علمی خراب است. آیا Web3 می تواند آن را برطرف کند؟](https://www.youtube.com/watch?v=WkvzYgCvWj8)
-- [Juan Benet - DeSci، آزمایشگاههای مستقل، & علم داده در مقیاس بزرگ](https://www.youtube.com/watch?v=zkXM9H90g_E)
-- [Sebastian Brunemeier - چگونه DeSci می تواند تحقیقات زیست پزشکی را تغییر دهد & سرمایه خطرپذیر](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
diff --git a/public/content/translations/fa/08) Use cases 2/refi/index.md b/public/content/translations/fa/08) Use cases 2/refi/index.md
deleted file mode 100644
index 0c3fa8385fe..00000000000
--- a/public/content/translations/fa/08) Use cases 2/refi/index.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: امور مالی بازتولیدکننده (ReFi)
-description: مروری بر ReFi و موارد استفاده فعلی آن.
-lang: fa
-template: use-cases
-emoji: ":recycle:"
-sidebarDepth: 2
-image: /images/future_transparent.png
-alt: ""
-summaryPoint1: یک سیستم اقتصادی جایگزین ساخته شده بر پایه اصول بازتولیدکننده
-summaryPoint2: تلاشی برای استفاده از اتریوم برای حل چالش های هماهنگی در سراسر جهان مثل تغییرات آب و هوایی
-summaryPoint3: ابزاری برای مقیاسپذیری قابل توجه دارایی های سودمند زیست محیطی مانند اعتبارات کربن تایید شده
----
-
-## Refi چیست؟ {#what-is-refi}
-
-**سیستمهای مالی احیایی (ReFi)** مجموعهای از ابزارها و ایدههایی است که بر روی [بلاکچینها](/glossary/#blockchain) ساخته شدهاند و هدف آن ایجاد اقتصادهایی است که به جای استخراج یا بهرهکشی، احیاکننده هستند. در نهایت، سیستم های استخراجی منابع موجود را استفاده کرده و از بین می برند که بدون هیچگونه ساز و کار بازتولیدکننده، فاقد قدرت خواهند بود. عملکرد ReFi بر این پنداشت است که ایجاد ارزش پولی باید از استخراج ناپایدار منابع از سیاره و از جوامع ما جدا شود.
-
-در عوض، هدف ReFi حل مشکلات محیط زیستی، همگانی، یا اجتماعی به وسیله ایجاد چرخه های بازتولیدکننده می باشد. این سیستم ها در حالی که برای شرکت کنندگان ارزش تولید می کنند، به طور همزمان به اکوسیستم ها و جوامع هم سود می رسانند.
-
-یکی از پایه های ReFi مفهوم اقتصاد بازتولیدکننده است که توسط جان فولرتون از موسسه Capital مطرح شد. او [هشت اصل به هم پیوسته](https://capitalinstitute.org/8-principles-regenerative-economy/) را پیشنهاد کرد که زیربنای سلامت سیستمیک هستند:
-
-![هشت اصل به هم پیوسته](refi-regenerative-economy-diagram.png)
-
-پروژه های Refi این اصول را هنگام استفاده از [قرارداد های هوشمند](/glossary/#smart-contract) و اپلیکیشنهای [سیستم های مالی غیر متمرکز (DeFi)](/glossary/#defi) به عنوان محرکی برای رفتارهای بازتولیدکننده به کار می گیرند. به عنوان مثال احیا اکوسیستم های تنزل یافته و تقویت همکاری ها در مقیاس بزرگ برای مسائل جهانی مانند تغییرات آب و هوا و تقلیل تنوع زیستی جانوری.
-
-ReFi همچنین با جنبش [دانش غیرمتمرکز (DeSci)](/desci/) همپوشانی دارد، که از اتریوم به عنوان پلتفرمی برای فراهم کردن سرمایه، تولید کردن، بررسی کردن، اعتبار دادن، ذخیره کردن، و منتشر کردن دانش علمی استفاده می کند. ابزارهای DeSci می توانند برای توسعه استاندارد ها و شیوه های تحقیق پذیر برای اجرا کردن و نظارت کردن بر فعالیت های بازتولیدکننده مانند کاشتن درختان، جمعآوری پلاستیک از اقیانوس، یا احیای یک اکوسیستم تخریب شده مفید باشند.
-
-
-
-## توکنیزه کردن اعتبارات کربنی {#tokenization-of-carbon-credits}
-
-**[بازار داوطلبانه کربن (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** مکانیزمی است برای تامین مالی پروژه هائی که تاثیر مثبت تایید شده بر انتشار کربن دارند؛ یا انتشار مداوم را کاهش می دهند، یا گاز های گل خانه ای را که قبلا در جو منتشر شده اند حذف میکنند. پس از تایید این پروژه ها، آن ها یک دارائی به نام "اعتبارات کربن" دریافت می کنند، که می توانند آن ها را به افراد و سازمان هایی که میخواهند از اقدامات آب و هوایی حمایت کنند بفروشند.
-
-علاوه بر VCM، چندین بازار کربن دستوری از طرف دولت («بازارهای سازگاری) وجود دارد که هدف آن ها تعیین قیمت کربن از طریق قوانین و مقررات در یک حوزه قضایی بخصوص (مثلا در یک کشور یا منطقه)، جهت کنترل صدور مجوزهایی است که باید توزیع شوند. بازارهای سازگاری، در حوزه حقوقی خود، آلایندگان را جهت کاهش انتشار گاز های گلخانه ای تشویق می کنند، اما قادر به پاک کردن گاز های گلخانه ای از قبل منتشر شده نیستند.
-
-علی رقم توسعه آن در دهه های اخیر، VCM هنوز با چالش های متعدد مواجه است:
-
-1. پراکندگی زیاد نقدینگی
-2. مکانیزم های غیر شفاف تراکنش
-3. هزینه های بالا
-4. سرعت بسیار پایین معاملات
-5. عدم مقیاس پذیری
-
-انتقال VCM به **بازار جدید کربن دیجیتال (DCM)** مبتنی بر بلاکچین، ممکن است فرصتی برای ارتقا دادن تکنولوژی موجود برای معتبر ساختن، معامله کردن و مصرف اعتبارات کربن باشد. بلاکچینها به داده های قابل تایید عمومی اجازه دسترسی برای طیف گسترده ای از کاربرها، و نقدینگی بیشتر را می دهند.
-
-پروژه های Refi با به کارگیری تکنولوژی بلاکچین تعداد زیادی از مشکلات بازار های سنتی را تسهیل می کنند:
-
-- ** نقدینگی در تعداد محدودی از استخر های نقدینگی متمرکز شده است** که هر شخص می تواند آزادانه آن را مبادله کند. تشکیلات بزرگ همانند اشخاص می توانند از این استخر های نقدینگی بدون جستجوی دستی فروشندگان و خریداران، پرداخت هزینه های مشارکت یا هزینه ثبت نام، استفاده کنند.
-- **تمامی تراکنش ها به روی بلاکچینهای عمومی ثبت می شوند**. مسیری که هر یک از اعتبارات کربن جهت فعالیت مبادله طی می کند، به محض در دسترس بودن در DCM برای همیشه قابل ردیابی خواهد بود.
-- **سرعت تراکنش تقریبا آنی می باشد**. تامین مقادیر زیاد اعتبارات کربن از طریق بازارهای ارثی می تواند چندین روز یا هفته به طول بینجامد، در حالی که از طریق DCM در عرض چند ثانیه میسر خواهد بود.
-- **فعالیت مبادله تجاری بدون هرگونه واسطه انجام می گیرد**، که کارمزد بالایی را درخواست می کنند. اعتبارات کربن دیجیتال نشان دهنده کاهش قابل توجه هزینه در مقایسه با اعتبارات سنتی است.
-- **DCM مقیاس پذیز است** و میتواند هم نیاز اشخاص و هم سازمان های بین المللی را بر طرف کند.
-
-### اجزای کلیدی DCM {#key-components-dcm}
-
-چشم انداز فعلی DCM شامل چهار جزء اصلی است:
-
-1. سازمان ها یا سیستم هایی مانند [Verra](https://verra.org/project/vcs-program/registry-system/) و [ Gold Standard](https://www.goldstandard.org/) از قابل اعتماد بودن پروژه هایی که اعتبارات کربن تولید می کنند اطمینان حاصل می کنند. آنها همچنین پایگاه های اطلاعاتی را مدیریت می کنند که اطلاعات کربن دیجیتال از آن ها منشأ می گیرد و می تواند منتقل یا مصرف شود (بازنشسته).
-
-موج جدیدی از پروژه های نوآورانه در حال ساخت بر روی بلاکچینها وجود دارد که در حال تلاش برای ایجاد اختلال برای متصدیان در این بخش هستند.
-
-2. پل های کربنی، با نام مستعار مبدل توکن های دیجیتال، یک فناوری برای نمایش دادن یا انتقال اعتبارات کربن از سازمان های قدیمی به DCM را فراهم می کنند. مثال های قابل توجه شامل [Toucan Protocol](https://toucan.earth/)، [C3](https://c3.app/)، و [Moss.Earth](https://moss.earth/) می شوند.
-3. خدمات یکپارچه، اجتناب کربن و/یا حذف اعتبارات را به کاربران نهایی ارائه می کند بنابراین آن ها می توانند اعتبار مزایای زیست محیطی را مطالبه کنند و حمایت خود را از اقدامات آب و هوایی را با دنیا به اشتراک بگذارند.
-
-بعضی شرکت ها مثل [کلیما اینفینیتی (Klima Infinity)](https://www.klimadao.finance/infinity) و [سنکن (Senken)](https://senken.io/) طیف گسترده ای از پروژه های توسعه یافته توسط طرف های ثالت و اعتبار کربن صادر شده زیر نظر استاندارد هایی مثل Verra را ارائه میدهند؛ دیگران مثل [نوری (Nori)](https://nori.com/) تنها پروژه های خاص را ارائه می کنند که زیر نظر استاندارد اعتبار کربن خودشان توسعه یافته اند، آنها را صادر میکنند و برای هر کدام بازارچه مخصوص به خود را دارند.
-
-4. چارچوب و زیرساخت اساسی که امکان مقیاسپذیری اثربخشی و بازده کل زنجیره تامین را در بازار کربن فراهم می کند. [KlimaDAO](http://klimadao.finance/) نقدینگی را به عنوان کالای عمومی تامین میکند (امکان خرید یا فروش اعتبار کربن با قیمتی شفاف را برای هر کس فراهم میکند)، مشوق برای افزایش فعالیت در بازارهای کربن و بازنشستگی اعتبارات را از طریق پاداشها، و ابزارهای ساده و همتراز برای دسترسی به اطلاعات و همچنین بهدست آوردن و بازنشستگی طیف گستردهای از اعتبارات کربن توکنسازیشده فراهم میکند.
-
-## Refi فراتر از بازارهای کربن {#refi-beyond}
-
-با اینکه هم اکنون تاکید زیادی روی بازارهای کربن به طور کلی، و به خصوص انتقال VCM به DCM در این حوزه وجود دارد، Refi به کربن محدود نمیشود. دیگر داراییهای زیستمحیطی فراتر از اعتبارات کربن هم میتوانند توسعه و توکنیزه شوند، که امکان گنجاندن سایر اثرات جانبی نامطلوب را در سطوح پایه ای سیستمهای اقتصادی آینده فراهم میکند. علاوه بر این، جنبه بازتولیدکنندگی این مدل اقتصادی را میتوان برای سایر بخش ها نیز به کار برد، مثل تامین سرمایه کالاهای عمومی از طریق پلتفرم های تامین مالی درجه دوم مثل [گیتکوین](https://gitcoin.co/). سازمان هایی که بنیاد آنها بر اساس ایده مشارکت آزاد و توزیع منصفانه منابع نهادینه شده است همه را قادر میسازند سرمایه ها را به سمت پروژه های نرم افزاری منبع-باز، و نیز پروژههای آموزشی، محیط زیستی و پروژههای جامعه محور سرازیر کنند.
-
-با تغییر مسیر جریان سرمایه از فعالیتهای استخراجی به سوی جریان بازتولیدکننده، پروژهها و شرکتهایی که مزایای اجتماعی، زیست محیطی یا محلی ارائه میکنند - و ممکن است در سیستم سنتی تامین سرمایه ناموفق باشند - میتوانند از جا بلند شوند و تأثیرات مثبت جانبی را برای جامعه به شکل سریعتر و آسانتر ایجاد کنند. انتقال به این نوع تأمین سرمایه، همچنین فرصتی برای ایجاد سیستمهای اقتصادی فراگیر ایجاد میکند که در آنها افراد همه بافتهای جمعیتی میتوانند به صورت فعال مشارکت کنند، به جای اینکه فقط به طور غیرفعال ناظر باشند. ReFi چشم اندازی از اتریوم را ارائه میکند که از آن به عنوان مکانیسمی برای هماهنگی مقابله با چالشهای پیش روی ما و حیات روی سیارهمان استفاده میشود- به عنوان لایه پایه یک پارادایم اقتصادی جدید، این مکانیسم یک آینده فراگیرتر و پایدارتر برای قرون آینده را ممکن میسازد.
-
-## مطالعه بیشتر درباره ReFi
-
-- [نگاه کلی به ارز های کربن و جایگاه آنها در اقتصاد](https://www.klimadao.finance/blog/the-vision-of-a-carbon-currency)
-- [وزارت آینده، رمانی که نقش ارزهای دارای پشتوانه کربن در مقابله با تغییرات اقلیمی را شرح میدهد](https://en.wikipedia.org/wiki/The_Ministry_for_the_Future)
-- [یک گزارش مفصل از سوی Taskforce for Scaling Voluntary Carbon Markets](https://www.iif.com/Portals/1/Files/TSVCM_Report.pdf)
-- [توضیح واژه نامه CoinMarketCap از Kevin Owocki و Evan Miyazono درباره ReFi](https://coinmarketcap.com/alexandria/glossary/regenerative-finance-refi)
diff --git a/public/content/translations/fa/08) Use cases 2/social-networks/index.md b/public/content/translations/fa/08) Use cases 2/social-networks/index.md
deleted file mode 100644
index e3352a79d85..00000000000
--- a/public/content/translations/fa/08) Use cases 2/social-networks/index.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: شبکه های اجتماعی غیر متمرکز
-description: بررسی اجمالی شبکه های اجتماعی غیرمتمرکز روی اتریوم
-lang: fa
-template: use-cases
-emoji: ":mega:"
-sidebarDepth: 2
-image: /images/ethereum-learn.png
-summaryPoint1: پلتفرم های مبتنی بر بلاک چین، برای تعامل اجتماعی و ایجاد و توزیع محتوا.
-summaryPoint2: شبکه های رسانه اجتماعی غیرمتمرکز، از حریم خصوصی کاربران محافظت می کنند و امنیت داده ها را افزایش می دهند.
-summaryPoint3: توکن ها و نیفتی ها راه های جدیدی برای کسب درآمد از محتوا ایجاد می کنند.
----
-
-شبکه های اجتماعی نقش گسترده ای در ارتباطات و تعاملات روزانه ما دارند. اگرچه، کنترل متمرکز این پلتفرمها مشکلات زیادی ایجاد کرده است که: نقض دادهها، قطع شدن سرورها، پلتفرمزدایی، سانسور و نقض حریم خصوصی برخی از مبادلاتی هستند که رسانههای اجتماعی اغلب انجام میدهند. برای مبارزه با این مشکلات، توسعه دهندگان در حال ساخت شبکه های اجتماعی بر روی اتریوم هستند. شبکه های اجتماعی غیرمتمرکز می توانند بسیاری از مشکلات پلتفرم های شبکه های اجتماعی سنتی را برطرف کنند و تجربه کلی کاربران را بهبود بخشند.
-
-## شبکه های اجتماعی غیرمتمرکز چی هستند؟ {#what-are-decentralized-social-networks}
-
-شبکههای اجتماعی غیرمتمرکز پلتفرمهایی [مبتنی بر بلاک چین](/glossary/#blockchain) هستند که به کاربران امکان تبادل اطلاعات و نیز انتشار و توزیع محتوا برای مخاطبان را میدهند. از آنجایی که این برنامهها بر روی بلاک چین اجرا میشوند، میتوانند غیرمتمرکز باشند و در برابر سانسور و کنترل بیرویه مقاوم باشند.
-
-بسیاری از شبکههای اجتماعی غیرمتمرکز بهعنوان جایگزینی برای سرویسهای رسانههای اجتماعی موجود تاسیس شده اند. مانند فیسبوک، لینکدین، توییتر و مدیوم . اما شبکه های اجتماعی مبتنی بر بلاک چین دارای تعدادی ویژگی هستند که آنها را از پلتفرم های اجتماعی سنتی برتری می دهد.
-
-
-
-### شبکه های اجتماعی غیرمتمرکز چگونه کار می کنند؟ {#decentralized-social-networks-overview}
-
-شبکههای اجتماعی غیرمتمرکز دستهای از [ برنامههای کاربردی غیرمتمرکز (dapps) ](/dapps/) هستند که توسط [ قراردادهای هوشمند ](/glossary/#smart-contract) مستقر در بلاک چین پشتیبانی می شوند. کد قرارداد به عنوان پشتیبان این برنامه ها عمل می کند و منطق تجاری آنها را تعریف می کند.
-
-پلتفرمهای رسانههای اجتماعی سنتی برای ذخیره اطلاعات کاربر، کد برنامه و سایر اشکال داده به پایگاههای داده متکی هستند. ولی این باعث ایجاد نقاط شکست واحد می شود و خطر قابل توجهی را ایجاد می کند. به عنوان مثال، سرورهای فیس بوک در اکتبر 2021 به طرز بدنامی [ برای ساعت ها آفلاین شدند ](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) و کاربران را از پلتفرم قطع کردند.
-
-شبکه های اجتماعی غیرمتمرکز در یک [شبکه همتا به همتا (peer-to-peer)](/glossary/#peer-to-peer-network) وجود دارند که شامل هزاران گره (nodes) در سراسر جهان است حتی اگر برخی از گره ها از کار بیفتند، شبکه بدون وقفه اجرا می شود و برنامه ها را در برابر خرابی ها و قطعی ها مقاوم می کند.
-
-با استفاده از سیستمهای ذخیرهسازی غیرمتمرکز مانند [ سیستم فایل بین سیارهای (IPFS به معنای فایل سیستم بین سیاره ای است که در واقع یک سیستم توزیع فایل همتا به همتا و غیر متمرکز است)](https://ipfs.io/)، شبکههای اجتماعی ساخته شده بر روی اتریوم میتوانند از اطلاعات کاربر در برابر سوء استفاده و استفاده مخرب محافظت کنند. هیچ کس اطلاعات شخصی شما را به تبلیغ کنندگان نمی فروشد و هکرها نیز نمی توانند اطلاعات محرمانه شما را بدزدند.
-
-بسیاری از پلتفرمهای اجتماعی مبتنی بر بلاک چین دارای توکنهای بومی هستند که در غیاب درآمد تبلیغاتی به کسب درآمد کمک میکنند. کاربران میتوانند این توکنها را برای دسترسی به برخی ویژگیها، تکمیل خریدهای درونبرنامهای یا انعام دادن به سازندگان محتوای مورد علاقه خود خریداری کنند.
-
-## مزایای شبکه های اجتماعی غیر متمرکز؟ {#benefits}
-
-1. شبکه های اجتماعی غیرمتمرکز در برابر سانسور مقاوم هستند و به روی همه باز هستند. یعنی کاربران را **نمی توان خودسرانه ممنوع کرد**، پلتفرم آنها را تغییر داد، یا محدود کرد.
-
-2. شبکه های اجتماعی غیرمتمرکز بر اساس **ایده آل های منبع باز ساخته شده اند** و کد منبع برنامه ها را برای بازرسی عمومی در دسترس قرار می دهند. با حذف اجرای الگوریتمهای غیرشفاف رایج در رسانههای اجتماعی سنتی، شبکههای اجتماعی مبتنی بر بلاک چین میتوانند علایق کاربران و سازندگان پلتفرم را همسو کنند.
-
-3. شبکه های اجتماعی غیرمتمرکز «مرد میانی» (middle-man) را حذف می کنند. **سازندگان محتوا مالکیت مستقیم بر محتوای خود دارند** و مستقیماً با دنبالکنندگان، طرفداران، خریداران و سایر طرفها درگیر میشوند و چیزی جز یک قرارداد هوشمند در این بین وجود ندارد.
-
-4. مثل برنامههای غیرمتمرکز اجرا شده در شبکه اتریوم که توسط یک شبکه جهانی و همتا به همتا از گرهها پشتیبانی میشود، **شبکههای اجتماعی غیرمتمرکز کمتر در معرض خرابی** و قطعی سرور هستند.
-
-5. پلتفرمهای اجتماعی غیرمتمرکز یک چارچوب **بهبودیافته درآمدزایی** را برای سازندگان محتوا از طریق [توکنهای غیرقابل تعویض (NFT)](/glossary/#nft)، پرداختهای رمزارزی درون برنامه و موارد دیگر ارائه میکنند.
-
-6. شبکه های اجتماعی غیرمتمرکز **سطح بالایی از حریم خصوصی و ناشناس بودن** را برای کاربران فراهم می کند. مثلا یک فرد میتواند با استفاده از نمایه یا [کیف پول](/glossary/#wallet) [ENS](/glossary/#ens) به یک شبکه اجتماعی مبتنی بر اتریوم وارد شود - بدون اینکه نیازی به اشتراکگذاری اطلاعات شناسایی شخصی (PII) مانند نام، آدرس ایمیل و غیره باشد.
-
-7. شبکههای اجتماعی غیرمتمرکز به ذخیرهسازی غیرمتمرکز متکی هستند، نه پایگاههای داده متمرکز، که برای حفاظت از دادههای کاربر بسیار بهتر هستند.
-
-## شبکه های اجتماعی غیرمتمرکز در اتریوم {#ethereum-social-networks}
-
-شبکه اتریوم به دلیل محبوبیت توکنهای آن (ERC) و پایگاه کاربر عظیم آن، به ابزاری مطلوب برای توسعهدهندگانی تبدیل شده است که رسانههای اجتماعی غیرمتمرکز ایجاد میکنند. در اینجا چند نمونه از شبکه های اجتماعی مبتنی بر اتریوم آورده شده است:
-
-### Mirror {#mirror}
-
-[ Mirror](https://mirror.xyz/) یک پلتفرم نوشتاری دارای web3 فعال است که هدف آن غیرمتمرکز بودن و مالکیت کاربر است. کاربران می توانند با اتصال کیف پول خود به صورت رایگان در Mirror بخوانند و بنویسند. کاربران همچنین می توانند نوشته ها را درخواست کرده و همچنین نویسندگان مورد علاقه خود را دنبال کنند.
-
-پستهای منتشر شده در Mirror بهطور دائم در Arweave، یک پلتفرم ذخیرهسازی غیرمتمرکز، ذخیره میشوند و میتوانند بهعنوان [ توکنهای غیرقابل تعویض قابل جمعآوری (NFT) ](/nft/) به نام Writing NFT ذخیره شوند. نوشتن NFT برای نویسندگان کاملاً رایگان است و جمعآوری آن در [لایه 2](/glossary/#layer-2) اتریوم انجام میشود - که باعث میشود تراکنشها ارزان، سریع و سازگار با محیطزیست باشند.
-
-### MINDS {#minds}
-
-[MINDS](https://www.minds.com/) یکی از پرکاربردترین شبکه های اجتماعی غیرمتمرکز است. مانند فیس بوک کار می کند و تاکنون میلیون ها کاربر را جذب کرده است.
-
-کاربران جهت انجام پرداخت برای آیتمها، از توکن بومی و مبتنی بر [ERC-20](/glossary/#erc-20) پلتفرم به نام $MIND استفاده میکنند. کاربران همچنین می توانند با انتشار محتوای محبوب، کمک به اکوسیستم و ارجاع دیگران به پلتفرم، توکن های $MIND کسب کنند.
-
-## از شبکه های اجتماعی غیرمتمرکز استفاده کنید {#use-decentralized-social-networks}
-
-- **[Status.im](https://status.im/)** - _ یک برنامه پیام رسانی امن است که از یک پروتکل منبع باز، همتا به همتا و رمزگذاری سرتاسر برای محافظت از پیام های شما در برابر اشخاص ثالث استفاده می کند_.
-- **[Mirror.xyz](https://mirror.xyz/)** - _ یک پلتفرم انتشار غیرمتمرکز و متعلق به کاربر است که بر پایه اتریوم ساخته شده است تا کاربران بتوانند بر روی ایدههای خود سرمایهگذاری کنند، از محتوا کسب درآمد کنند و جوامع با ارزش بالا بسازند _.
-- **[Lens Protocol](https://lens.xyz/)** - _ پروتکل لنز یک نمودار اجتماعی قابل ترکیب و غیرمتمرکز است که به سازندگان کمک میکند تا هر کجا که در باغ دیجیتال اینترنت غیرمتمرکز میروند، مالکیت محتوای خود را در دست بگیرند_.
-- **[Farcaster](https://farcaster.xyz/)** - _Farcaster یک شبکه اجتماعی به اندازه کافی غیر متمرکز است. این یک پروتکل باز است که می تواند بسیاری از مشتریان را پشتیبانی کند، درست مانند ایمیل._
-
-## شبکه های اجتماعی Web2 در اتریوم {#web2-social-networks-and-ethereum}
-
-پلتفرمهای اجتماعی بومی [ Web3](/glossary/#web3) تنها پلتفرمهایی نیستند که تلاش میکنند فناوری بلاک چین را در رسانههای اجتماعی بگنجانند. بسیاری از پلتفرم های متمرکز نیز در حال برنامه ریزی برای ادغام اتریوم در زیرساخت خود هستند:
-
-### Reddit {#reddit}
-
-ردیت دارای[امتیازهای تبلیغشده در انجمن](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) است که توکنهای ERC-20 هستند که کاربران میتوانند آنها را با ارسال محتوای با کیفیت و مشارکت در انجمنهای آنلاین (سابردیتها) کسب کنند. برای دریافت امتیازات و امتیازات انحصاری، میتوانید این توکنها را در یک سابردیت بازخرید کنید. برای این پروژه، ردیت با آربیتروم کار میکند، که یک شبکه [لایه 2](/glossary/#layer-2) است که برای مقیاسبندی تراکنشهای اتریوم طراحی شده است.
-
-این برنامه در حال حاضر فعال است و زیر ردیت r/CryptoCurrency نسخه Community Points خود را به نام [ "Moons" ](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki) اجرا می کند. طبق توضیحات رسمی، Moons "به پوسترها، نظر دهندگان و ناظران برای مشارکت آنها در subreddit پاداش می دهد." زیرا این توکن ها هستند از آنجایی که این توکن ها روی بلاک چین قرار دارند (کاربران آنها را در کیف پول دریافت می کنند)، مستقل از Reddit هستند و نمی توان آنها را برداشت.
-
-علاوه بر استفاده از امتیازات انجمن برای باز کردن قفل ویژگیهای خاص، کاربران میتوانند آنها را با فیات در صرافیها مبادله کنند. همچنین، امتیازات انجمن که یک کاربر در اختیار دارد، تأثیر او را بر فرآیند تصمیمگیری در جامعه تعیین میکند.
-
-## بیشتر بخوانید {#further-reading}
-
-### مقالات {#articles}
-
-- [تمرکززدایی رسانه های اجتماعی: راهنمایی برای پشته اجتماعی web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_
-- [شبکه های اجتماعی فرصت بزرگ بعدی برای عدم تمرکز هستند](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Ben Goertzel_
-- [Web3 نوید شبکه های اجتماعی غیرمتمرکز و مبتنی بر جامعه را دارد](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_
-- [مروری بر چشم انداز رسانه های اجتماعی بلاک چین](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_
-- [چگونه بلاک چین می تواند حریم خصوصی رسانه های اجتماعی را حل کند](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_
-- [عدم تمرکز کافی برای شبکه های اجتماعی](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_
-
-### ویدیوها {#videos}
-
-- [توضیح رسانه های اجتماعی غیرمتمرکز](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_
-- [بلاک چین DeSo می خواهد رسانه های اجتماعی را غیرمتمرکز کند](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_
-- [آینده رسانه های اجتماعی غیرمتمرکز با بالاجی سرینیواسان، ویتالیک بوترین، خوان بنت](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_
-
-### جوامع {#communities}
-
-- [ساب ردیت r/CryptoCurrency subreddit](https://www.reddit.com/r/CryptoCurrency/)
diff --git a/public/content/translations/fa/09) Learn Pages/bridges/index.md b/public/content/translations/fa/09) Learn Pages/bridges/index.md
deleted file mode 100644
index 11b0c468bba..00000000000
--- a/public/content/translations/fa/09) Learn Pages/bridges/index.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: مقدمهای بر پلهای بلاکچین
-description: پلها به كاربران اجازه مي دهند دارايي هايشان را بين بلاك چينهاي مختلف انتقال دهند
-lang: fa
----
-
-# پلهای زنجیرهی بلوکی {#prerequisites}
-
-_Web3 به راهحلهای مقیاسپذیری اكوسيستم لايه 1 و اكوسيستم لايه 2 تبدیل شدند که هركدام از اين لايه ها داراي تواناییها و قوانين منحصربهفرد هستند. با افزایش تعداد پروتکلهای بلاکچین، تقاضا برای جابجایی داراییها در زنجیرهها نیز افزایش مییابد. براي پاسخ به اين نياز ما به پلها نياز داريم._
-
-
-
-## پل ها چه هستند؟ {#what-are-bridges}
-
-پلهاي بلاك چين دقيقا مثل پلهاي واقعی در دنياي فيزيكي هستند. همانطور كه يك پل فيريكي دو محل فيزيكي را به هم مرتبط مي كند يك پل بلاك چين نيز دو اکوسیستم بلاكچين را به هم متصل مي كند. **پلها ارتباط بین بلاکچین ها را از طریق انتقال اطلاعات و داراییها تسهیل میکنند**.
-
-با يك مثال مسئله را توضيح مي دهيم:
-
-شما اهل آمريكا هستيد و می خواهيد به اروپا سفر كنيد. شما دلار داريد ولي به يورو نياز داريد. براي تبديل دلار به يورو از يك صرافي با كارمزد كم كمك مي گيريد.
-
-اما، اگر بخواهید یک صرافی مشابه برای استفاده از یک [بلاکچین](/glossary/#blockchain) متفاوت ایجاد کنید، چه میکنید؟ فرض کنید میخواهید [اتر](/glossary/#ether) در شبکه اصلی اتریوم را با اتر در [آربیتروم](https://arbitrum.io/) مبادله کنید. مثل تبديل پولي كه براي يورو انجام داديم، به يك مكانيزم نياز داريم تا بتوانيم اتر بلاك چين اصلي را به اتر بلاك چين آربیتروم تبديل كنيم. پل ها چنين انتقالي را امكان پذير مي كنند. در اين مثال [ آربیتروم داراي يك پل اصلي است ](https://bridge.arbitrum.io/) كه مي تواند اتر را از شبکه اصلی به آربیتروم انتقال دهد.
-
-## چرا به پلها نياز داريم؟ {#why-do-we-need-bridges}
-
-تمام بلاك چين ها محدوديت هاي خود را دارند. اتریوم برای مقیاسپذیر بودن و نگهداری سطح تقاضا به [رولآپها](/glossary/#rollups) نیاز دارد. جايگزينهايي مثل Solana و Avalanche به صورت متفاوت طراحي شده اند تا دادههای ورودی بیشتر را ممکن سازند اما با قربانی کردن تمركززدایی.
-
-بااینحال، همه بلاکچینها در محیطهای ایزوله توسعه مییابند و قوانین و مکانیزمهای [اجماع](/glossary/#consensus) متفاوت دارند. یعنی نمي توانند به صورت طبيعي با هم ارتباط پيدا كنند و توكنها آزادنه نمي توانند بين بلاک چینها حركت كنند.
-
-پلها براي اتصال بلاكچينها هستند و اجازه انتقال اطلاعات و توكنها را بين آنها مي دهند.
-
-**قابلیتهای پلها**:
-
-- انتقال بینزنجیرهای دارایی ها و اطلاعات.
-- تامین [دپها](/glossary/#dapp) برای دسترسی به نقاط قوت بلاکچینهای مختلف – بنابراین قابلیتهای آنها را افزایش میدهند (زیرا پروتکلها هماکنون فضای طراحی بیشتری برای نوآوری دارند).
-- کاربران میتوانند به پلتفرمهاي جديد دسترسی پیدا کنند و از مزایای زنجيره هاي مختلف استفاده کنند.
-- توسعه دهندگان اکوسیستمهای مختلف بلاك چين میتوانند همکاری کنند و پلتفرمهاي جديدي را براي كاربرها بسازند.
-
-[چگونه توکن ها را به لایه دوم ارتباط دهیم](/guides/how-to-use-a-bridge/)
-
-
-
-## موارد استفاده پلها {#bridge-use-cases}
-
-سناريوهاي مختلفي كه مي توان از پلها استفاده كرد در زير ارائه شده است:
-
-### هزينه انتقال پايين تر {#transaction-fees}
-
-فرض كنيد كه شما اتر را در شبکه اصلی بلاكچين اتريوم داريد ولي مي خواهيد قیمت تراکنش كمتري را براي کاوش اپليكيشنهاي غیرمتمرکز مختلف پرداخت كنيد. با پل زدن اترتان از شبکه اصلی بلاكچين به رولآپ لايه 2 میتوانید از قیمتهای تراکنش پایینتر بهرهمند شوید.
-
-### اپليكيشنهای غير متمركز روي بلاكچينهای دیگر {#dapps-other-chains}
-
-فرض كنيد شما از Aave در شبکه اصلی اتریوم استفاده کردهاید تا USDT قرض بدهید ولي نرخ بهره قرض دادن USDT با استفاده از Aave در Polygon بالاتر است.
-
-### کاوش اكوسيستمهای بلاكچين {#explore-ecosystems}
-
-اگر شما اتر در شبکه اصلی اتریوم داريد و مي خواهيد یک لایه 1 جایگزین را برای امتحان کردن اپلیکیشنهای غیرمتمرکز اصلی آنها کاوش کنید. با استفاده از يك پل مي توانيد اتر خود را از شبکه اصلی اتریوم به لایه 1 جایگزین منتقل کنید.
-
-### دارايیهای رمز ارز اصلی خود {#own-native}
-
-فرض كنيد مي خواهيد بيتكوين (BTC) خودتان را داشته باشيد ولي فقط در شبكه اصلي اتريوم پول داريد. براي بدست آوردن بيتكوين در اتريوم مي توانيد بيتكوين تبدیل یافته (WBTC) خريداري كنيد. بااینحال، WBTC یک توکن [ERC-20](/glossary/#erc-20) بومی شبکه اتریوم است، به این معنی که نسخه اتریوم بیتکوین است و نه دارایی اصلی در بلاکچین بیتکوین. براي داشتن بيتكوين اصلي بايد به كمك پل دارايیهای خود را از اتريوم به بيتكوين انتقال دهيد. با اين كار WBTC خود را به بيتكوين اصلي پل میزنید و تغيير مي دهيد. از طرف دیگر، ممکن است صاحب بیتکوین باشید و بخواهید از آن در پروتکلهای [دیفای](/glossary/#defi) اتریوم استفاده کنید. اين امر نيازمند آن است كه يك پل در جهت مخالف از بيتكوين به رپد بيتكوين استفاده شود که میتوان از آن به عنوان دارایی در اتریوم استفاده کرد.
-
-
- البته مي توانيد تمام كارهاي فوق را توسط صرافي متمركز انجام دهيد. با این حال، در این صورت با انجام چند مرحله می توانید بهتر از پل مورد نظر استفاده کنید، مگر آن که پولهایتان از قبل در صرافی باشد.
-
-
-
-
-## انواع پل {#types-of-bridge}
-
-پلها انواع مختلفی از نظر طرح و پیچیدگی دارند. به طور کلی پلها به دو گروه تقسیم می شوند: بدون نیاز به اعتماد و نیازمند به اعتماد.
-
-| پلهای با نیاز به اعتماد | پل های بدون نیاز به اعتماد |
-| --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
-| پلهای نیازمند به اعتماد به یک سیستم یا نهاد مرکزی برای استفاده از آنها وابسته هستند. | پلهای بدون اعتماد، با استفاده از قراردادهای هوشمند و الگوریتمها کار میکنند. |
-| آنها فرض اعتماد پذیر بودن را در رابطه با سرپرستی دارایی و امنیت پل دارا می باشند. کابران بیشتر به شهرت اپراتور پل اعتماد میکنند. | آنها بدون نیاز به اعتماد هستند این به این معنی است که امنیت پل مشابه امنیت بلاک چین مورد نظر است. |
-| کاربران باید کنترل دارایی های خود را واگذار کنند. | از طریق [قراردادهای هوشمند](/glossary/#smart-contract)، پلهای بیواسطه کاربران را قادر میسازند تا کنترل سرمایه خود را حفظ کنند. |
-
-به طور مشخص می توان گفت که در پلهایی که نیاز به اعتماد می باشد شما به پلتفرم مورد نظر اعتماد می کنید در حالی که در پلهای بدون اعتماد با حداقل اعتماد کردن و صرفا با فرض درست بودن دامنه های زیر ساخت کار انجام می شود. این اصطلاحات در زیر توضیح داده شده است:
-
-- بدون اعتماد**: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط آرجون بوپتانی در این مقاله
- توضیح داده شده است
-
- - در مدل دارای اعتماد:** با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
-
- برای این که تفاوت های اساسی بین دو روش بهتر جا بیفتد یک مثال ارائه می شود:
-
- فرض کنید شما داخل گیت امنیتی فرودگاه هستید. دو روش برای گیت کنترل وجود دارد:
-
- 1. روش دستی - که تمام جزئیات بلیت و کارت شناسایی توسط افسران مربوطه قبل از دادن کارت پرواز انجام می شود.
-2. کنترل توسط خودتان - با دستگاه انجام می شود که در آن اطلاعات پروازتان را وارد میکنید و اگر همه چیز درست باشد، کارت پرواز را دریافت میکنید.
-
-یک پست بازرسی دستی، شبیه یک مدل مورد اعتماد است زیرا برای عملیات خود به شخص ثالث یعنی مقامات رسمی وابسته است. به عنوان کاربر به مراکز معتبر اعتماد می کنید تا تصمیم درست را بگیرند و از اطلاعات خصوصی شما به درستی استفاده کنند.
-
-مدلی که توسط خود کاربر چک می شود مشابه مدل بدون نیاز به اعتماد می باشد، چون نقش اپراتور حذف می شود و با کمک تکنولوژی امور مربوطه را انجام می دهد. کاربر همیشه کنترل اطلاعات شخصی خود را بدون اعتماد به شخص ثالث در اختیار دارد.
-
-بسیاری از پلها مدلهای مابین این دو حالت معرفی می کنند و دارای درجه ای از عدم نیاز به اعتماد هستند.
-
-
-
-
-
-## خطر استفاده از پلها {#bridge-risk}
-
-پلها در مرحله ابتدایی توسعه می باشند. به عبارتی طراحی بهینه پلها هنوز به صورت کامل کشف نشده است. استفاده از هر کدام از پلها خطر مربوط به خود را دارد:
-
-- خطر قرارداد هوشمند —** وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
-
- - خطر تکنولوژی—** خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
-
- با این حال پلهای نیازمند به اعتماد از آنجا که تصورهای اعتماد را افزایش میدهند، می توانند خطرات مضاعفی را به همراه داشته باشند، مثل:
-
- - خطر سانسور—** کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
-
- - خطر سرپرستی—** کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند
-
- دارایی های کابرها در خطر هستند اگر:
-
- - یک باگ در قرارداد هوشمند باشد
-- کاربر مرتکب خطا شود
-- بلاکچین مورد استفاده هک شود
-- اپارتورهای پل در پلهای نیاز به اعتماد صادق نباشند
-- پل هک شود
-
-یکی از آخرین هکهای اتفاق افتاده مربوط به پل، [Wormhole از Solana می باشد که در آن 120000 رپد اتر معادل 325 میلیون دلار دزدیده شد](https://rekt.news/wormhole-rekt/). بسیاری از [هکهای بزرگ در بلاک چین از طریق پلها اتفاق می افتد](https://rekt.news/leaderboard/).
-
-پلها برای کسانی که می خواهند به اتریوم لایه 2 بروند و همچنین برای کسانی که می خواهند اکوسیستمهای دیگر را کشف کنند دارای نقش حیاتی هستند. با این حال با توجه به خطرات مرتبط با پلها، کاربران باید مبادلاتی را که پلها انجام میدهند بفهمند. برخی از [استراتژی های امنیت کراسچین](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946).
-
-
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [EIP-5164: اجرای کراسچین](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658)_تاریخ 18 ژوئن 2022 - برندان اسلتاین_
-- [چارچوب ریسک L2Bridge](https://gov.l2beat.com/t/l2bridge-risk-framework/31)_تاریخ 5 ژوئیه 2022 - بارتک کیپوسوسکی_
-- [«چرا در آینده به سمت چند زنجیرهای پیش می رویم نه کراس چین.»](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/)_تاریخ 8 ژانویه 2022 - ویتالیک بوترین_
diff --git a/public/content/translations/fa/09) Learn Pages/energy-consumption/index.md b/public/content/translations/fa/09) Learn Pages/energy-consumption/index.md
deleted file mode 100644
index 01ba4a77081..00000000000
--- a/public/content/translations/fa/09) Learn Pages/energy-consumption/index.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: مصرف انرژی اتریوم
-description: اطلاعات پایه که برای درک مصرف انرژی اتریوم نیاز دارید.
-lang: fa
----
-
-# هزینه انرژی اتریوم {#proof-of-stake-energy}
-
-اتریوم یک بلاک چین سبز است. [سیستم اثبات گواه سهام](/developers/docs/consensus-mechanisms/pos) اتریم از مکانیسم اجماع به جای [انرژی برای امنیت شبکه](/developers/docs/consensus-mechanisms/pow) استفاده میکند. مصرف انرژی اتریوم تقریبا [~0.0026 ترا وات ساعت در سال](https://carbon-ratings.com/eth-report-2022)در کل شبکه جهانی می باشد.
-
-تخمین مصرف انرژی اتریوم بر اساس اطلاعات بدست آمده از [CCRI ( موسسه نرخ کربن ارز دیجیتال)](https://carbon-ratings.com) تخمین زده شده است. آنها حداقل و حداکثر برآوردهای مصرف برق و ردپای کربن شبکه اتریوم را تولید کردند ([گزارش را ببینید](https://carbon-ratings.com/eth-report-2022)). آنها مصرف برق گرههای مختلف را با سخت افزار ها و پیکربندیهای متفاوت نرمافزار کاربران اندازه گرفته اند. مقدار تخمینی **2601 مگاوات ساعت** (0.0026 تراوات ساعت) برای مصرف سالیانه برق شبکه منجر به کاهش مقدار دی اکسید کربن تولیدی به مقدار **870 تن** می باشد، که در آن از فاکتورهای منطقهای شدت کربن استفاده میشود. این مقدار با ورود و خروج گرهها به شبکه تغییر می کند، می توانید یک مقدار میانگین برای 7 روز را که توسط[شاخص پایداری شبکه بلاکچین کمبریج](https://ccaf.io/cbnsi/ethereum) تخمین زده شده، مورد بررسی قرار دهید (آنها از یک روش متفاوت برای تخمین استفاده کرده اند که جزئیات مطالعه آنها در سایتشان موجود است).
-
-برای درک بهتر از میزان مصرف انرژی شبکه اتریوم، میتوانیم آن را با سرانه تخمینی سالانه مصرف انرژی برخی محصولات و صنایع دیگر مقایسه کنیم. این به ما کمک می کند که بهنر درک کنیم که آیا تخمین اتریوم زیاد است یا کم.
-
-
-
-نمودار زیر، تخمینی از میران مصرف انرژی شبکه اتریوم بر اساس ترا وات ساعت در سال را در مقایسه با تعدادی صنایع و محصولات دیگر نمایش میدهد. آمار فراهم شده بر اساس اطلاعات عمومی موجود در ژوئیه 2023 بوده و لینک منابع آنها نیز در جدول زیر قابل مشاهده است.
-
-| | مصرف انرژی سالانه (ترا وات ساعت در سال) | مقایسه با اتریوم گواه سهام | منبع |
-|:------------------------ |:---------------------------------------:|:--------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
-| مراکز داده جهانی | 190 | 73,000x | [منبع](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) |
-| بیت کوین | 149 | 53,000x | [منبع](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| استخراج طلا | 131 | 50,000x | [منبع](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| بازی در ایالات متحده\* | 34 | 13,000x | [منبع](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) |
-| اتریوم PoW | 21 | 8,100x | [منبع](https://ccaf.io/cbnsi/ethereum/1) |
-| گوگل | 19 | 7,300x | [منبع](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) |
-| نتفلیکس | 0.457 | 176x | [منبع](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
-| پی پال | 0.26 | 100x | [منبع](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-(1).pdf) |
-| AirBnB | 0.02 | 8x | [منبع](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-(Final).pdf) |
-| **اتریوم PoS** | **0.0026** | **1x** | [منبع](https://carbon-ratings.com/eth-report-2022) |
-
-\*شامل دستگاههای کاربران نهایی مانند رایانههای شخصی، لپتاپ، و کنسولهای بازی است.
-
-دستیابی به تخمینهای دقیق درباره مصرف انرژی امری پیچیده است، به خصوص زمانی که آنچه که اندازهگیری میشود دارای زنجیره تامین پیچیده یا جزئیات پیادهسازی است که بر کارایی آن تأثیر میگذارد. برای مثال، تخمین مصرف انرژی شرکتهای نتفلیکس و گوگل بسته به اینکه فقط انرژی مصرف شده برای نگهداری سیستمهایشان و ارائه محتوا به کاربران (_هزینه مستقیم_) را شامل میشوند یا اینکه شامل هزینههای لازم برای تولید محتوا، اداره دفاتر شرکت، تبلیغات و غیره (_هزینه غیرمستقیم_) میشوند متفاوت است. هزینههای غیرمستقیم همچنین میتوانند شامل انرژی مورد نیاز برای مصرف محتوا در دستگاههای کاربر نهایی مانند تلویزیون، کامپیوتر و موبایل باشند.
-
-تخمینهای فوقالذکر مقایسه کاملی نیستند. مقدار مخارج غیرمستقیم محاسبه شده، بر اساس منبع متفاوت است و به ندرت شامل انرژی دستگاههای کاربر نهایی میشوند. هر منبع زیربنایی، شامل جزئیات بیشتر در مورد آنچه اندازهگیری میشود است.
-
-جدول و نمودار بالا فوق همچنین شامل مقایسه های بیت کوین و اتریوم اثبات کار است. توجه به این نکته ضروری است که مصرف انرژی شبکههای اثبات کار ثابت نیست و روز به روز تغییر میکند. تخمینها نیز ممکن است بین منابع بهطور گسترده متفاوت باشند. این موضوع نه تنها در مورد میزان انرژی مصرفشده، بلکه در مورد منابع آن انرژی و اصول اخلاقی مرتبط با آن، [مباحثات](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) ظریف را به خود جلب میکند. مصرف انرژی لزوماً دقیقاً به ردپای محیطزیستی مربوط نمیشود زیرا پروژههای مختلف ممکن است از منابع انرژی متفاوت استفاده کنند، از جمله انرژیهای تجدیدپذیر با نسبت کمتر یا بیشتر. برای مثال، [شاخص مصرف برق بیتکوین دانشگاه کمبریج](https://ccaf.io/cbnsi/cbeci/comparisons) یعنی شاخص Cbeci نشان میدهد که تقاضای شبکه بیتکوین از نظر تئوری میتواند با سوخت گاز یا برق تامین شود که در غیر این صورت در انتقال و توزیع از بین میرود. راه حل اتریوم در مسیر پایداری، جایگزینی بخش نیازمندِ انرژیِ شبکه با یک گزینه سبز بود.
-
-مصرف انرژی و انتشار کربن برای صنایع مختلف را می توانید در [سایت شاخص پایداری شبکه بلاک چین کمبریج ](https://ccaf.io/cbnsi/ethereum) ببینید.
-
-## تخمینهای قبل از تراکنش {#per-transaction-estimates}
-
-بسیاری از مقالهها، مصرف انرژی «قبل از تراکنش» را برای بلاک چینها تخمین می زنند. این روش ممکن است گمراهکننده باشد، چون انرژی لازم برای پیشنهاد و تایید کردن یک بلوک، به تعداد تراکنشهای داخل آن ربط ندارد. یک واحد از هزینه انرژی در هر تراکنش به این معنی است که تراکنشهای کمتر منجر به هزینه کمتر انرژی می شود و بالعکس، که اینطور نیست. همچنین تخمین انرژی به ازا تراکنش، بسیار به این ربط دارد که تعداد دادههای ورودی یک تراکنش بلاکچین چگونه تعریف می شود، و با بازی کردن با این تعریف می توان مقدار انرژی را بزرگ تر یا کوچکتر جلوه داد.
-
-بهعنوان مثال، در اتریوم تعداد دادههای ورودی تراکنش فقط مربوط به لایه پایه نیست - بلکه مجموع دادههای ورودی تراکنش در تمام رولآپهای "[لایه 2](/layer-2/)" آن است. لایه 2ها به صورت کلی در محاسبات لحاظ نمی شوند، اما در نظر گرفتن انرژی اضافی مصرف شده از سوی ترتیب سنجها ( کوچک) و تعداد تراکنشهای مورد پردازش آنها (بزرگ)، احتمالا تخمینهای پیش از تراکنش را به صورت قابل ملاحظه کاهش می دهند. این فقط یکی از دلایلی است که چرا مقایسه مصرف انرژی در هر تراکنش بین پلتفرمها میتواند گمراهکننده باشد.
-
-## بدهی کربن مربوط به اتریوم {#carbon-debt}
-
-مصرف انرژی اتریوم خیلی پایین است، اما این همیشه مورد مهم نیست. اتریوم اصلی بر پایه اثبات کار بود که هزینه زیستمحیط خیلی بیشتری نسبت به مکانیسم فعلی اثبات سهام داشت.
-
-اتریوم از همان آغاز برنامه داشت مکانیزم اجماع مبتنی بر اثبات سهام را پیاده سازی کند ولی انجام این امر بدون قربانی کردن امنیت و غیر متمرکز نگه داشتن شبکه، نیاز به سالها تحقیق و توسعه داشت. بنابراین از مکانیسم اثبات کار برای راهاندازی شبکه استفاده شد. اثبات کار استخراجگرها را ملزم میکند از سختافزار محاسباتیشان برای محاسبه یک مقدار استفاده کنند و این فرایند نیازمند انرژی است.
-
-![مقایسه مصرف انرژی اتریوم قبل و بعد از ادغام با استفاده از برج ایفل (با 330 متر ارتفاع) در سمت چپ برای سمبولیزه کردن مصرف بالای انرژی پیش از ادغام، و یک شکل لگوی کوچک 4 سانتیمتری در سمت راست به نشانه کاهش شدید مصرف انرژی پس از ادغام](energy_consumption_pre_post_merge.png)
-
-موسسه CCRI تخمین میزند که ادغام، مصرف سالانه برق اتریوم را بیش از **99.988٪** کاهش داده است. به طور مشابه، مقدار تولید کربن نیز در حدود **99.992 %** کاهش پیدا کرده است (از 11016000 تن به 870 تن دی اکسید کربن). برای مشابه سازی کاهش در آلودگی تولید شده، شبیه به رفتن از برج ایفل به یک اسباب بازی کوچک پلاستیکی است، همانطور که در شکل بالا نشان داده شده است. به عنوان نتیجه، هزینه زیست محیطی تامین امنیت شبکه به صورت قابل توجه کاهش پیدا کرده است. همزمان، اعتقاد بر این است که امنیت شبکه نیز ارتقا پیدا کرده است.
-
-## یک لایه سبز اپلیکیشن {#green-applications}
-
-در حالی که مصرف انرژی اتریوم بسیار اندک است، یک مجموعه قابل توجه، در حال رشد و بسیار فعال[**احیاکننده مالی (ReFi)**](/refi/) در بستر اتریوم وجود دارد. برنامههای ReFi از اجزای DeFi برای ساخت برنامههای مالی استفاده میکنند که اثرات خارجی مثبتی برای محیط زیست دارند. RiFi بخشی از یک جنبش گسترده تر به نام ["solarpunk"](https://en.wikipedia.org/wiki/Solarpunk) است که با هماهنگی نزدیک با اتریوم حرکت می کند و هدف آن رشد تکنولوژیکی و نظارت محیط زیستی است. ویژگی هایی مثل غیر متمرکز بودن، عدم نیاز به اجازه و قابلیت ترکیب اتریوم، باعث شده است لایه پایه ایدهآل برای گروه های RiFi و solarpunk باشد.
-
-پلتفرمهای بومی Web3 برای تامین هزینه کالاهای عمومی مثل [Gitcoin](https://gitcoin.co) میزگردهای مربوط به اقلیم را برای تحریک ساخت سازگار با محیط زیست در لایه اپلیکیشن اتریوم، اجرا میکنند. به خاطر این ابتکارها (و موارد دیگر مثل [DeSci](/desci/)) اتریوم از جنبه محیط زیستی و اجتماعی در حال تبدیل شدن به یک تکنولوژی کاملا مثبت است.
-
-
- اگر فکر میکنید این صفحه میتواند دقیقتر شود، لطفاً آن را در قالب یک مشکل یا درخواست مطرح کنید. آمار این صفحه بر اساس داده های عمومی می باشد. آنها نشاندهنده اعلام رسمی یا قول تیم ethereum.org یا بنیاد اتریوم نیستند.
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [شاخص پایداری شبکه بلاکچین کمبریج](https://ccaf.io/cbnsi/ethereum)
-- [گزارش کاخ سفید درباره اثبات کار بلاکچینها](https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
-- [انتشارات اتریوم: یک برآورد پایین به بالا](https://kylemcdonald.github.io/ethereum-emissions/) - _ کیلی مک دونالد_
-- [شاخص مصرف انرژی اتریوم](https://digiconomist.net/ethereum-energy-consumption/) – _Digiconomist_
-- [ETHMerge.com](https://ethmerge.com/) — _[@InsideTheSim](https://twitter.com/InsideTheSim)_
-- [ادغام - مفاهیم مصرف برق و میزان انتشار کربن در شبکه اتریوم](https://carbon-ratings.com/eth-report-2022) - _CCRI_
-- [مصرف انرژی اتریوم](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8)
-
-## موضوعات مرتبط {#related-topics}
-
-- [چشمانداز اتریوم](/roadmap/vision/)
-- [زنجیره بیکن](/roadmap/beacon-chain)
-- [ادغام](/roadmap/merge/)
diff --git a/public/content/translations/fa/09) Learn Pages/governance/index.md b/public/content/translations/fa/09) Learn Pages/governance/index.md
deleted file mode 100644
index 4234ad9c017..00000000000
--- a/public/content/translations/fa/09) Learn Pages/governance/index.md
+++ /dev/null
@@ -1,182 +0,0 @@
----
-title: حاکمیت اتریوم
-description: مقدمهای بر چگونگی تصمیمگیری برای اتریوم.
-lang: fa
----
-
-# مقدمهای بر حاکمیت اتریوم {#introduction}
-
-_اگر هیچکس مالک اتریوم نیست، تصمیمات دربارهی گذشته و آیندهی اتریوم چگونه گرفته میشوند؟ حاکمیت اتریوم به فرایندی اطلاق میشود که امکان اتخاذ چنین تصمیماتی را فراهم میسازد._
-
-
-
-## حاکمیت چیست؟ {#what-is-governance}
-
-حاکمیت یعنی نظامهایی که اجازه میدهند تصمیمات گرفته شوند. در یک ساختار سازمانی معمولی، تیم اجرایی یا هیئت مدیره ممکن است حرف آخر را در تصمیمگیری بزند. یا شاید سهامداران برای تصویب تغییر، دربارهی پیشنهادها رأیگیری کنند. در یک نظام سیاسی، مقامات منتخب ممکن است قوانینی را وضع کنند که تلاش میکند خواستههای رأیهندگان آنها را نمایندگی کند.
-
-## حاکمیت غیرمتمرکز {#decentralized-governance}
-
-هیچ فردی مالک پروتکل اتریوم نیست و آن را کنترل نمیکند، اما برای اعمال تغییرات لازم جهت حصول اطمینان از دیرپایی و عملکرد مناسب شبکه، همچنان نیاز است که تصمیماتی گرفته شود. این عدم وجود مالک باعث میشود که حاکمیت سازمانی سنتی، راهحلی ناکارآمد باشد.
-
-## حاکمیت اتریوم {#ethereum-governance}
-
-حاکمیت اتریوم فرایندی است که تغییرات پروتکل از طریق آن انجام میشود. لازم به ذکر است که این فرایند، ارتباطی به افراد و برنامههایی که از پروتکل استفاده میکنند ندارد - اتریوم پروتکلی بدون نیاز به مجوز است. هر کسی در هر جای جهان میتواند در فعالیتهای درونزنجیرهای (on-chain) مشارکت کند. هیچ قانونی برای افراد گذاشته نشده که چهکسی میتواند و چه کسی نمیتواند یک برنامه بسازد یا تراکنشی بفرستد. با این حال، فرآیندی برای پیشنهاد تغییرات در پروتکل اصلی وجود دارد، که برنامه های غیرمتمرکز روی آن کار می کنند. از آن جایی که مردم به پایداری اتریوم وابسته هستند، آستانهی هماهنگی بسیار زیادی برای تغییرات هستهای، از جمله فرایندهای فنی و اجتماعی، وجود دارد تا اطمینان حاصل شود که تغییرات اتریوم ایمن هستند و بهطور گسترده توسط جامعه حمایت میشوند.
-
-### حاکمیت درونزنجیرهای و برونزنجیرهای {#on-chain-vs-off-chain}
-
-تکنولوژی زنجیرهی بلوکی امکان تواناییهای حاکمیتی جدید، که به نام حاکمیت درونزنجیرهای شناخته میشوند، را فراهم میسازد. حاکمیت درونزنجیرهای یعنی تصمیمگیری در خصوص تغییرات پیشنهادی پروتکل با رأی سهامداران، که معمولاً دارندگان توکن حاکمیت هستند، انجام میشود، و رأیگیری روی زنجیره بلوکی اتفاق میافتد. در بعضی شکلهای حاکمیت درونزنجیرهای، تغییرات پیشنهادی پروتکل قبلا به شکل کد نوشته شده و اگر سهامداران تغییرات را از طریق تایید تراکنش بپذیرند بهطور خودکار به اجرا گذاشته میشود.
-
-رویکرد مقابل، یعنی حاکمیت برونزنجیرهای، یعنی هر تصمیمی برای تغییر پروتکل از طریق یک فرایند غیررسمی مباحثههای اجتماعی گرفته میشود، که اگر پذیرفته شود، در کد اعمال خواهد شد.
-
-با مشارکت سهامداران بسیار متنوع در این فرایند، **حاکمیت اتریوم به شکل برونزنجیرهای اتفاق میافتد**.
-
-_گرچه در لایهی پروتکل حاکمیت اتریوم برونزنجیرهای است، بسیاری از پروتکلهایی که روی اتریوم ساخته شدهاند، مثل DAOها، از حاکمیت درونزنجیرهای استفاده میکنند._
-
-
- اطلاعات بیشتر درباره DAOها
-
-
-
-
-## چه افرادی دخیل هستند؟ {#who-is-involved}
-
-سهامداران متنوعی در [جامعهی اتریوم](/community/) وجود دارند که هرکدام در فرایند حاکمیت نقشی ایفا میکنند. اگر از سهامدارانی که بیشترین فاصله را از پروتکل دارند شروع کنیم و رفتهرفته به آن نزدیکتر شویم، فهرست ما از این قرار خواهد بود:
-
-- **دارندگان اتر**: این افراد میزان دلخواهی اتر را نگهداری میکنند. [درباره اتر بیشتر بدانید](/eth/).
-- **کاربران برنامههای کاربردی**: این افراد با برنامههای موجود در زنجیرهی بلوکی اتریوم تعامل دارند.
-- **توسعهدهندگان برنامهها/ابزارها**: این افراد برنامههایی را مینویسند که روی زنجیره بلوکی اتریوم اجرا میشوند (مثل DeFi، NFTها و غیره) یا ابزارهایی میسازند که با اتریوم تعامل دارند (مثل کیف پولها، بستههای آزمایش (test suites) و غیره). [درباره برنامههای غیرمتمرکز بیشتر بدانید](/dapps/).
-- **اپراتورهای گره**: این افراد گرههایی را اجرا میکنند که بلوکها و تراکنشها را پخش میکنند و هر تراکنش یا بلوک نامعتبری که ظاهر میشود را رد میکنند. [درباره گرهها بیشتر بدانید](/developers/docs/nodes-and-clients/).
-- **نویسندگان EIP**: این افراد پیشنهادهایی را برای تغییر پروتکل اتریوم در قالب پیشنهادهای بهبود اتریوم (EIPها) ارائه میدهند. [درباره EIP بیشتر بدانید](/eips/).
-- **اعتبارسنج ها**: این افراد گره هایی را اجرا می کنند که می توانند بلوک های جدید را به زنجیره بلوکی اتریوم اضافه کنند.
-- **توسعهدهندگان پروتکل** (همان "توسعه دهندگان اصلی"): این افراد توسعه اجراهای مختلف اتریوم را در دست دارند (به عنوان مثال go-ethereum و Nethermind و Besu و Erigon و Reth در لایه اجرا یا Prysm و Lighthouse و Nimbus و Teku و Lodestar در لایه اجماع). [درباره کلاینتهای اتریوم بیشتر بدانید](/developers/docs/nodes-and-clients/).
-
-_یادداشت: هر فردی میتواند عضوی از چند گروه مختلف باشد (مثلا یک توسعهدهندهی پروتکل میتواند EIP را نگهداری کند، و یک اعتبارسنج زنجیرهی بیکن را اجرا کند و از یک برنامهی DeFi استفاده کند). برای شفافیت مفهومی، بهتر است که آنها را از هم جدا کنیم._
-
-
-
-## EIP چیست؟ {#what-is-an-eip}
-
-یکی فرایند مهم که در حاکمیت اتریوم استفاده میشود، ارائهی **پیشنهادهای بهبود اتریوم (EIPها)** است. EIPها استانداردهایی هستند که ویژگیها یا فرایندهای جدید را برای اتریوم مشخص میکنند. هرکسی در جامعهی اتریوم میتواند EIP بسازد. اگر علاقه مند به نوشتن EIP یا شرکت کردن در بررسی از سوی همتا و/یا حاکمیت هستید، نگاه کنید به:
-
-
- اطلاعات بیشتر درباره EIPها
-
-
-
-
-## فرایند رسمی {#formal-process}
-
-فرایند رسمی معرفی تغییرات برای پروتکل اتریوم به شرح زیر است:
-
-1. **یک EIP هستهای پیشنهاد دهید**: همانطور که در [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips) توضیح دادهشده، اولین گام برای پیشنهاد رسمی یک تغییر در اتریوم این است که آن را با جزئیات در یک EIP هستهای شرح دهید. این توضیحات بهعنوان مشخصات رسمی برای EIP در نظر گرفته میشوند که در صورت پذیرش، توسط توسعهدهندگان پروتکل پیادهسازی خواهند شد.
-
-2. **EIP خود را به توسعهدهندگان پروتکل ارائه دهید**: زمانی که یک EIP هستهای دارید که دیدگاه جامعه را دربارهی آن جمعآوری کردهاید، باید آن را به توسعهدهندگان پروتکل ارائه دهید. می توانید این کار را با پیشنهاد بحث کردن دربارهی آن در یک [تماس AllCoreDevs](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status) انجام دهید. ممکن است برخی بحثها بهصورت غیرهمزمان در [انجمن جادوگران اتریوم](https://ethereum-magicians.org/) یا روی [دیسکورد R&D اتریوم](https://discord.gg/mncqtgVSVw) مطرح شدهباشند.
-
-> خروجیهای احتمالی این مرحله به شرح زیرند:
-
-> - EIP بهعنوان یک ارتقای شبکهای آتی در نظر گرفته خواهد شد
-> - تغییرات فنی برای آن درخواست خواهد شد
-> - ممکن است در صورت اولویت نداشتن یا بهبود اندک بهنسبت توان لازم برای توسعه با آن مخالفت شود
-
-3. **برای رسیدن به پیشنهاد نهایی آن را بازگو کنید:** پس از دریافت بازخورد از همهی سهامداران مرتبط، احتمالاً لازم است برای بهبود امنیت آن یا برای رسیدن به نیازهای مختلف کاربران، تغییراتی را در پیشنهاد اولیهی خود اعمال کنید. زمانی که EIP شما همهی تغییرات مد نظرتان را در خود داشت، باید آن را دوباره به توسعهدهندگان پروتکل ارائه دهید. پس از این، یا به مرحلهی بعدی فرایند میروید یا مشکلات جدیدی پیش میآیند که یکبار بازگویی دیگر برای پیشنهادتان برای آنها لازم خواهد بود.
-
-4. **EIP در ارتقای شبکه گنجانده میشود**: با فرض اینکه EIP پذیرفته شده، تست شده و پیادهسازی شدهاست، برای اجرایی شدن بهعنوان ارتقای شبکه زمانبندی میشود. با توجه به هزینهی بسیار زیاد ارتقاهای شبکه (همه باید بهصورت همزمان ارتقا دهند)، EIPها معمولاً به صورت دستهای در ارتقاها قرار میگیرند.
-
-5. **ارتقای شبکه فعال میشود**: وقتی ارتقای شبکه فعال شد، EIP روی شبکهی اتریوم خواهد بود. _یادداشت: ارتقاهای شبکه معمولاً ابتدا رو شبکهی تست فعال میشوند و سپس روی شبکهی اصلی اتریوم فعال میشوند._
-
-این جریان، گرچه تا حد زیادی سادهسازی شدهاست، یک نمای کلی از گامهای خاصی که برای فعالی شدن یک تغییر پروتکل روی اتریوم طی میشود، به ما نشان میدهد. حال اجازه بدهید به عوامل غیررسمی دخیل در این فرایند بپردازیم.
-
-## فرایند غیررسمی {#informal-process}
-
-### درک کارهای قبلی {#prior-work}
-
-مدافعان EIP باید پیش از اقدام به ساخت یک EIP، که ممکن است روی شبکهی اصلی اتریوم اجرا شود، با کارها و پیشنهادهای قبلی کاملاً آشنا باشند. در این صورت، EIP احتمالاً چیز جدیدی برای ارائه خواهد داشت که قبلاً رد نشده است. سه مکان اصلی برای تحقیق درباره این موضوع عبارتند از [مخزن EIP](https://github.com/ethereum/EIPs)، [جادوگران اتریوم](https://ethereum-magicians.org/) و [ethresear.ch](https://ethresear.ch/).
-
-### کارگروهها {#working-groups}
-
-اولین نسخهی یک EIP احتمالاً بدون بازبینی و تغییر روی شبکهی اصلی اتریوم پیادهسازی نخواهد شد. عموماً مدافعان EIP برای مشخص کردن، پیادهسازی، تست، بازگویی و نهاییسازی پیشنهاد خود با زیرمجموعهای از توسعهدهندگان پروتکل کار میکنند. از گذشته تاکنون، این کارگروهها به چند ماه (و گاهی چند سال!) کار نیاز داشتهاند. بهطور مشابه، دارندگان EIP برای چنین تغییراتی باید توسعهدهندگان برنامههای کاربردی/ابزارسازی را در اولین مراحل وارد کار خود کنند تا از کاربر نهایی بازخورد دریافت کنند و هرگونه ریسک استقرار را کاهش دهند.
-
-### وفاق جامعه {#community-consensus}
-
-در حالی که برخی از EIP ها پیشرفت های فنی ساده با حداقل تفاوت های جزئی هستند، برخی پیچیدهتر هستند و دارای معاوضه هایی هستند که به طرق مختلف بر سهامداران مختلف تأثیر می گذارد. این بدان معناست که برخی EIPها در جامعه از برخی دیگر مناقشهبرانگیزتر هستند.
-
-هیچ دستورالعمل مشخصی برای برخورد با پیشنهادهای مناقشهبرانگیز وجود ندارد. این نتیجه طراحی غیرمتمرکز اتریوم است که به موجب آن هیچ گروه سهام داری نمی تواند دیگری را از طریق نیروی بی رحمانه ناگزیر کند: توسعهدهندگان پروتکل می توانند انتخاب کنند که تغییرات کد را اجرا نکنند؛ اپراتورهای گره می توانند انتخاب کنند که آخرین اتریوم کاربر را اجرا نکنند؛ تیم ها و کاربران اپلیکیشن می توانند انتخاب کنند که بر روی زنجیره تراکنش انجام ندهند. از آن جا که توسعهدهندگانِ پروتکل هیچ راهی برای اجبار مردم به اعمال ارتقاهای شبکه ندارند، آنها معمولاً از EIPهایی که مناقشه برانگیزبودنشان بر نفعشان برای اکثریت جامعه میچربد، دوری میکنند.
-
-از مدافعان EIP انتظار میرود که از تمام سهامداران مرتبط بازخورد بگیرند. اگر مدافع یک EIP مناقشهبرانگیز هستید، باید سعی کنید مخالفتهایی که با EIP میشود را برطرف کنید تا دربارهی EIP خود وفاق ایجاد کنید. با توجه به بزرگی و تنوع جامعهی اتریوم، یک متر مشخص (مثل رأیگیری با کوین) وجود ندارد که بتوان برای رسیدن به وفاق اجتماعی از آن استفاده کرد، و از مدافعان EIP انتظار میرود که با شرایط پیشنهادهای خود سازگار شوند.
-
-فراتر از امنیت شبکهی اتریوم، از گذشته تاکنون توسعهدهندگان پروتکل برای آنچه که توسعهدهندگان برنامههای کاربردی/ابزارسازی و کاربران برنامههای کاربردی ارزشمند میدانستهاند وزن قابلتوجهی قائل بودهاند، چون استفاده و توسعهی آنها در اتریوم است که اکوسیستم را برای سایر ذینفعان جذاب میسازد. بهعلاوه، EIPها باید برای همهی پیادهسازیهای کلاینت که توسط تیمهای مجزا مدیریت میشوند، پیادهسازی شوند. بخشی از این فراند معمولاً به معنای این است که باید چند تیم مختلف از توسعهدهندگانِ پروتکل را قانع کنیم یک تغییر خاص ارزشمند است، به کاربر نهایی کمک میکند یا یک مشکل امنیتی را حل میکند.
-
-
-
-## برخورد کردن با مخالفتها {#disagreements}
-
-داشتن ذینفعان متعدد با انگیزهها و اعتقادات متفاوت به این معنی است که عدمتوافق غیرمعمولی نیست.
-
-عموماً، عدمتوافق با برگزاری مباحثههای طولانی در انجمنها برای فهمیدن ریشهی مشکل و مشارکت همگانی حل میشود. معمولاً یک گروه بحث را واگذار میکند یا یه حد وسط راضیکننده حاصل میشود. اگر یک گروه به حد کافی قدرتمند باشد و تغییری را برای بقیه اجبار کند، میتواند به جدا شدن زنجیرهها منجر شود. جدا شدن زنجیرهها یعنی تعدادی از ذینفعان در مقابل پیادهسازی تغییر پروتکل به شدت مقاومت میکنند و در نتیجه با این اختلاف دو زنجیره بلوکی متفاوت با ورژنهای مختلف پروتکل در حال اجرا پدید میآیند.
-
-### فورک DAO {#dao-fork}
-
-فورکها برای زمانی هستند که لازم است ارتقاهای فنی عمده یا تغییراتی روی شبکه اعمال شوند و این تغییرات به تغییر «قوانین» پروتکل میانجامند. [کلاینتهای اتریوم](/developers/docs/nodes-and-clients/) باید نرمافزارشان را بهروزرسانی کنند تا قوانین فورک جدید را پیادهسازی کنند.
-
-فورک DAO در واکنش به [حملهی DAO در سال 2016](https://www.coindesk.com/understanding-dao-hack-journalists) رخ داد که در آن در یک هک، یک قرارداد [DAO](/glossary/#dao) ناامن از بیش از 3.6 میلیون اتر تخلیه شد. این فورک سرمایهها را از قرارداد مشکلدار به یک قرارداد جدید منتقل کرد و به همهی کسانی که در هک سرمایه از دست داده بودند اجازه داد که آن را بازگردانند.
-
-این کار توسط جامعهی اتریوم رأیگیری شد. هر دارندهی اتر میتوانست از طریق یک تراکنش در یک [سکوی رأیگیری](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/) رأی بدهد. تصمیم انجام فورک بیشتر از 85% از آرا را به خود اختصاص داد.
-
-لازم به ذکر است با اینکه پروتکل فورک کرد تا هک را برگرداند، تعداد آرا برای تصمیمگیری دربارهی فورک کردن به چند دلیل قابل بحث است:
-
-- مشارکت در رأیگیری به شکلی قابلتوجه کم بود
-- بیشتر مردم نمیدانستند که این رأیگیری در حال انجام است
-- رأیگیری فقط برای دارندگان اتر بود و نه افراد دیگری که در این سیستم مشارکت داشتند
-
-زیرمجموعهای از جامعه مخالف فورک بودند، بیشتر به این دلیل که رخداد DAO اثری روی پروتکل نداشت. آنها با هم دیگر [اتریوم کلاسیک](https://ethereumclassic.org/) را ساختند.
-
-امروزه، جامعهی اتریوم سیاست عدمدخالت را در موارد وجود باگ در قراردادها یا از دست رفتن سرمایه اتخاذ کردهاست تا بیطرفی معتبر سیستم را حفظ کند.
-
-دربارهی هک DAO بیشتر تماشا کنید:
-
-
-
-
-
-### کاربرد فورک کردن {#forking-utility}
-
-فورک اتریوم/اتریوم کلاسیک مثالی عالی از یک فورک سالم است. ما دو گروه داشتیم که دربارهی ارزشهای اساسی با یکدیگر اختلاف نظر شدید داشتند؛ در حدی که به این نتیجه رسیدند که این موضوع ارزش ریسکهای اقدامهای متفاوتشان را دارد.
-
-وجود توانایی فورک کردن در مواجهه با اختلافات سیاستی، فلسفی یا اقتصادی نقشی بزرگ در موفقیت حاکمیت اتریوم ایفا میکند. اگر توانایی فورک کردن نبود، راه جایگزین ادامهی بحث و دعوا، مشارکت اجباری افرادی که نهایتا اتریوم کلاسیک را شکل دادند، و چشماندازی بسیار متفاوت از موفقیت برای اتریوم بود.
-
-
-
-## حاکمیت زنجیره بیکن {#beacon-chain}
-
-فرایند حاکمیت اتریوم اغلب سرعت و کارایی را با آزاد بودن و فراگیر بودن طاق میزند. برای توسعهی زنجیرهی بیکن، این زنجیره بهطور جداگانه از شبکهی اثبات کار اتریوم اجرا شد و رویههای حاکمیت شخصی خودش را اتخاذ کرد.
-
-با وجود اینکه مشخصات و اجراهای توسعه همواره متن کاملا باز بوده است، فرایندهای رسمی که برای پیشنهاد بهروزرسانی در بالا توضیح داده شد در آن استفاده نشدهاند. این کار اجازه داد تغییرات سریعتر توسط محققین و پیادهکنندگان مشخص شده و پذیرفته شوند.
-
-با ادغام زنجیره بیکن با لایه اجرایی اتریوم در 15 سپتامبر 2022 رویداد ادغام (The Merge) به عنوان بخشی از [ارتقا شبکه پاریس](/history/#paris) کامل شد. پیشنهاد [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) از حالت 'Last Call' به 'Final'، با کامل شدن گذر به مکانیزم اثبات سهام تغییر کرد.
-
-
- اطلاعات بیشتر دربارهی ادغام
-
-
-
-
-## چطور میتوانم مشارکت کنم؟ {#get-involved}
-
-- [پیشنهاد یک EIP](/eips/#participate)
-- [بررسی پیشنهاد فعلی](https://ethereum-magicians.org/)
-- [مشارکت در مباحثهی R&D](https://ethresear.ch/)
-- [پیوستن به دیسکورد R&D اتریوم](https://discord.gg/mncqtgVSVw)
-- [راهاندازی یک گره](/developers/docs/nodes-and-clients/run-a-node/)
-- [کمک به توسعهی کلاینت](/developers/docs/nodes-and-clients/#execution-clients)
-- [برنامهی کارآموزی توسعهدهندهی هستهای](https://blog.ethereum.org/2021/09/06/core-dev-apprenticeship-second-cohort/)
-
-## بیشتر بخوانید {#further-reading}
-
-حاکمیت در اتریوم تعریف دشواری ندارد. مشارکتکنندگانِ جوامع مختلف دیدگاههای مختلفی دربارهی آن دارند. چند نمونه از آنها در ادامه ذکر شده است:
-
-- [یادداشتهایی درباره حاکمیت بلاکچین](https://vitalik.eth.limo/general/2017/12/17/voting.html) - _ویتالیک بوترین_
-- [حاکمیت اتریوم چگونه کار میکند؟](https://cryptotesters.com/blog/ethereum-governance) - _Cryptotesters_
-- [چگونگی کارکرد حاکمیت اتریوم](https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a) - _میکا زولتو_
-- [توسعهدهنده اصلی اتریوم چیست؟](https://hudsonjameson.com/2020-06-22-what-is-an-ethereum-core-developer/) - _هادسون جیمز_
-- [حاکمیت، قسمت دوم: پلوتوکراسی همچنان بد است](https://vitalik.eth.limo/general/2018/03/28/plutocracy.html) - _ویتالیک بوترین_
-- [حرکت ورای حاکمیت رأیگیری با کوین](https://vitalik.eth.limo/general/2021/08/16/voting3.html) - _ویتالیک بوترین_
diff --git a/public/content/translations/fa/09) Learn Pages/security/index.md b/public/content/translations/fa/09) Learn Pages/security/index.md
deleted file mode 100644
index 88cf61e40e5..00000000000
--- a/public/content/translations/fa/09) Learn Pages/security/index.md
+++ /dev/null
@@ -1,293 +0,0 @@
----
-title: امنیت اتریوم و جلوگیری از کلاهبرداری
-description: ایمن ماندن در اتریوم
-lang: fa
----
-
-# امنیت اتریوم و جلوگیری از کلاهبرداری {#introduction}
-
-افزایش علاقه به رمزارز ریسک فزایندهای را از سوی کلاهبرداران و هکرها به همراه دارد. این مقاله برخی از بهترین شیوهها برای کاهش این خطرات را ارائه میدهد.
-
-
-
-## امنیت رمزارزها 101 {#crypto-security}
-
-### دانش خود را ارتقا دهید {#level-up-your-knowledge}
-
-سوءتفاهمها در مورد نحوه عملکرد رمزارز میتواند منجر به اشتباهات پرهزینه شود. به عنوان مثال، اگر شخصی وانمود کند که یک نماینده خدمات مشتری است که میتواند در ازای کلیدهای خصوصی شما اتر از دست رفته را برگرداند، افرادی را که نمیدانند اتریوم یک شبکه غیرمتمرکز و فاقد این نوع عملکرد است، شکار میکند. بالا بردن دانشتان در مورد نحوه کار اتریوم یک سرمایهگذاری ارزشمند است.
-
-
- اتریوم چیست؟
-
-
-
- اتر چیست؟
-
-
-
-## امنیت کیف پول {#wallet-security}
-
-### کلید خصوصیتان را اعلام نکنید {#protect-private-keys}
-
-**هیچگاه به هیچ دلیلی کلید خصوصیتان را بهاشتراک نگذارید!**
-
-کلید خصوصی کیفپول شما، رمزعبور کیفپول اتریوم شما است. این تنها چیزی است که نمیگذارد افرادی که آدرس کیف پول شما را میدانند تمام داراییهای حسابتان را خالی کنند!
-
-
- کیف پول اتریوم چیست؟
-
-
-#### از کلید خصوصی/عبارت بذر خود اسکرینشات نگیرید {#screenshot-private-keys}
-
-اسکرینشات گرفتن از عبارات بذر یا کلیدهای خصوصی شما ممکن است آنها را با یک ارائه دهنده خدمات دیتای ابری همگام کند، که ممکن است آنها را در معرض دسترسی هکرها قرار دهد. دستیابی به کلید خصوصی از فضای ابری یک مسیر متداول حمله برای هکرها است.
-
-### از کیف پول سختافزاری استفاده کنید {#use-hardware-wallet}
-
-کیف پول سختافزاری یک حافظه آفلاین برای کلید خصوصی است. آنها امن ترین روش برای نگهداری امن کلید خصوصی کیف پول شما به حساب می آیند: کلید خصوصی شما هرگز به اینترنت متصل نمیشود و کاملا در دستگاه محلی شما میماند.
-
-نگهداری کلیدهای خصوصی بهصورت آفلاین به شدت ریسک هک شدن را پایین میآورد، حتی اگر هکر بتواند کنترل کامپیوتر شما را به دست آورد.
-
-#### یک کیف پول سختافزاری را امتحان کنید: {#try-hardware-wallet}
-
-- [دفتر کل](https://www.ledger.com/)
-- [Trezor](https://trezor.io/)
-
-### پیش از ارسال تراکنش، صحت آن را دوباره بررسی کنید {#double-check-transactions}
-
-فرستادن ارز رمزنگاریشده به آدرس کیف پول نادرست، اشتباهی رایج است. **تراکنش ارسال شده در اتریوم برگشتناپذیر است.** مگر اینکه مالک آدرس را بشناسید و بتوانید او را متقاعد کنید که وجوه شما را پس بدهد، وگرنه نمیتوانید وجوهتان را باز گردانید.
-
-همیشه مطمئن شوید آدرسی که میخواهید به آن وجه ارسال کنید، با آدرسی که در حال ارسال وجه به آن هستید دقیقاً تطابق داشته باشد. هنگام تعامل با یک قرارداد هوشمند، خواندن پیام تراکنش قبل از امضا، روش خوبی است.
-
-### برای قرارداد هوشمند محدودیت خرج کردن وضع کنید {#spend-limits}
-
-وقتی با قراردادهای هوشمند تعامل میکنید، اجازهی خرج کردن نامحدود را به آنها ندهید. خرج کردن نامحدود میتواند به قرارداد هوشمند امکان دهد تمام کیف پول شما را خالی کند. در عوض، بهاندازهای که برای تراکنش نیاز است، حد خرج کردن مشخص کنید.
-
-بسیاری از کیف پولهای اتریوم برای حفاظت کردن از حسابها در مقابل خالی شدن، محافظت با وضع محدودیت را پیشنهاد میدهند.
-
-[چطور دست رسی یک قرارداد هوشمند را به دارایی های خود ممنوع کنیم](/guides/how-to-revoke-token-access/)
-
-
-
-## کلاهبرداریهای رایج {#common-scams}
-
-جلوگیری کامل از کلاهبرداران غیرممکن است، ولی میتوانیم با آگاهی از تکنیکهای مورد استفاده کلاهبرداران، اثربخشی آنها را کاهش دهیم. روشهای زیادی برای کلاهبرداری وجود دارد، اما آنها بهطور کلی الگوهای سطح بالای مشابهی را دنبال میکنند. در هر صورت، به یاد داشته باشید:
-
-- همیشه محتاط باشید
-- هیچکس نمیخواهد به شما اتریوم رایگان یا با تخفیف بدهد
-- هیچکس به کلید خصوصی و اطلاعات شخصی شما نیاز ندارد
-
-### توییتر و فیشینگ {#ad-phishing}
-
-![فیشینگ لینک توییتر](./twitterPhishingScam.png)
-
-روشی برای جعل کردن ویژگی پیشنمایش (باز کردن) لینک توییتر (همان X) وجود دارد تا کاربران را به طور بالقوه فریب دهد فکر کنند در حال بازدید از یک وبسایت قانونی هستند. این تکنیک، از مکانیزم توییتر برای ایجاد پیشنمایش آدرسهای اینترنتی به اشتراک گذاشته شده در توییتها سوءاستفاده میکند و برای مثال عبارت _از ethereum.org_ (نشان داده شده در بالا) را نشان میدهد، در حالی که در واقع به یک سایت مخرب هدایت میشوند.
-
-همیشه مطمئن شوید که به یک دامنه درست هدایت شدهاید، به خصوص پس از کلیک کردن روی یک لینک.
-
-[اطلاعات بیشتر در اینجا](https://harrydenley.com/faking-twitter-unfurling).
-
-### کلاهبرداری ارسال هدیه {#giveaway}
-
-یکی از شایعترین انواع کلاهبرداری مربوط به ارزهای رمزنگاریشده، کلاهبرداری ارسال هدیه است. کلاهبرداری با وعده واریز پاداش، میتواند اشکال مختلف داشته باشد، اما ایده کلی این است که اگر اتر را به آدرس کیفپول ارائه شده ارسال کنید، دو برابر اتر ارسالی خود را دریافت خواهید کرد. *به همین دلیل، به کلاهبرداری 2 به 1 نیز معروف است.*
-
-برای ایجاد احساس کاذب فوریت، این کلاهبرداریها معمولاً فرصت محدودی را برای درخواست واریز مبلغ تعیین میکنند.
-
-### هکهای رسانههای اجتماعی {#social-media-hacks}
-
-یک مورد معروف این نوع کلاهبرداری در ژوئیه 2020 اتفاق افتاد که حساب توییتر افراد مشهور و سازمانها هک شدند. هکر بهطور همزمان یک هدیه بیتکوینی را در شبکههای هکشده ارسال کرد. علیرغم کشف سریع و حذف توییتهای فریبنده، هکرها توانستند 11 بیت کوین (معادل 500،000 دلار در سپتامبر 2021) را به جیب بزنند.
-
-![یک کلاهبرداری در توییتر](./appleTwitterScam.png)
-
-### هدیه افراد مشهور {#celebrity-giveaway}
-
-کلاهبرداری در قالب هدیه افراد مشهور یکی دیگر از انواع رایج کلاهبرداری هدیه است. کلاهبرداران یک مصاحبه ویدیویی ضبطشده یا سخنرانی در همایش با حضور یک فرد مشهور را در یوتوب بهصورت زنده پخش میکنند - جوری که به نظر برسد آن فرد مشهور یک مصاحبه ویدیویی زنده دارد که در آن هدیهای در قالب ارز رمزنگاریشده را تأیید میکند.
-
-ویتالیک بوترین بیشتر اوقات در این کلاهبرداری مورد استفاده قرار میگیرد، اما بسیاری از افراد مطرح دیگر در حوزه ارزهای رمزنگاریشده نیز استفاده میشوند (مثال ایلان ماسک و چارلز هاسکینسون). دخیل کردن یک فرد بسیار مشهور میتواند به پخش زنده ویدیویی کلاهبرداران نوعی حس مشروعیت ببخشد (به نظر بودار میآید، اما پای ویتالیک هم وسط است، پس نباید مشکلی باشد!).
-
-**هدیهها همیشه کلاهبرداری هستند. اگر پولتان را به این حسابها بفرستید، آن را برای همیشه از دست خواهید داد.**
-
-![یک کلاهبرداری در یوتیوب](./youtubeScam.png)
-
-### کلاهبرداریهای پشتیبانی {#support-scams}
-
-ارز رمزنگاری شده یک فناوری نسبتاً نوپا است که خیلی وقتها درست فهمیده نمیشود. یکی از کلاهبرداریهای رایج که از این موضوع سوء استفاده میکند کلاهبرداری پشتیبانی است که در آن، کلاهبرداران خود را بهعنوان عامل پشتیبانی کیف پولها، صرافیها یا بلاکچینهای شناختهشده جا میزنند.
-
-اکثر بحث و گفتگوها درباره اتریوم روی Discord انجام میشود. کلاهبرداران پشتیبانی معمولاً افراد هدف خود را با جستجوی کسانی که در کانالهای عمومی Discord سؤالات مربوط به پشتیبانی مطرح میکنند پیدا میکنند، و سپس جهت ارائه پشتیبانی به آنها پیام خصوصی میفرستند. کلاهبرداران پشتیبانی با اعتمادسازی سعی میکنند شما را فریب دهند تا کلید خصوصیتان را افشا کنید یا پولتان را به کیف پول آنها بفرستید.
-
-![یک کلاهبرداری پشتیبانی در Discord](./discordScam.png)
-
-بهعنوان یک قانون کلی، کارکنان هرگز ار راههای خصوصی و غیررسمی با شما ارتباط برقرار نمیکنند. چند نکته ساده که در برخورد با کلاهبرداری پشتیبانی باید در ذهن داشت از این قرار است:
-
-- هیچگاه کلید خصوصی، عبارت seed یا گذرواژه خود را به اشتراک نگذارید
-- به هیچکس اجازه دسترسی از راه دور به کامپیوترتان را ندهید
-- هیچگاه خارج از کانالهای اختصاصی یک سازمان با آن ارتباط برقرار نکنید
-
-
-
- آگاه باشید: درست است که کلاهبرداریهای پشتیبانی عموماً در Discord رخ میدهند، اما امکان رخ دادن آنها در هر برنامه پیامرسان که در آن بحث و گفتگو با محوریت ارزهای رمزنگاریشده انجام میشود نیز وجود دارد؛ از جمله ایمیل.
-
-
-
-### کلاهبرداری توکن 'Eth2' {#eth2-token-scam}
-
-در آستانه [ادغام](/roadmap/merge/)، کلاهبرداران از سردرگمی در مورد عبارت "Eth2" استفاده کردند و سعی کردند کاربران را وادار کنند ETH خود را در قبال "ETH2" بازخرید کنند. «ETH2» وجود ندارد، و هیچ توکن قانونی دیگری با ادغام معرفی نشد. ETH که قبل از ادغام مالک آن بودید، اکنون همان ETH است. **نیازی به انجام هیچ گونه اقدام در رابطه با اتریوم شما برای محاسبه تغییر از اثبات کار به اثبات سهام وجود ندارد**.
-
-کلاهبرداران ممکن است به عنوان "پشتیبانی" ظاهر شوند و به شما بگویند اگر ETH خود را واریز کنید، "ETH2" پس خواهید گرفت. [پشتیبانی رسمی اتریوم](/community/support/) وجود خارجی ندارد و هیچ توکن جدیدی در کار نیست. هرگز عبارت بذر کیف پول خود را با کسی به اشتراک نگذارید.
-
-_توجه: توکنها/تیکرهای مشتقی وجود دارند که ممکن است نشاندهنده اتر سهام گذاریشده (یعنی rETH از استخر Rocket و stETH از Lido و ETH2 از Coinbase) باشند، اما اینها چیزی نیستند که شما نیاز به «مهاجرت به آن» داشته باشید._
-
-### کلاهبرداری فیشینگ {#phishing-scams}
-
-کلاهبرداریهای فیشینگ روش در حال رواج دیگری بین کلاهبرداران است که سعی میکنند از طریق آن موجودی کیف پول شما را بدزدند.
-
-برخی ایمیلهای فیشینگ از کاربران میخواهند روی لینکهایی کلیک کنند که آنها را به سایتهایی میبرند که از آنها میخواهند عبارت بذر را وارد کنند، گذرواژهشان را بازیابی کنند یا اتر بفرستند. برخی دیگر ممکن است از شما بخواهند ناآگاهانه بدافزاری را نصب کنید تا کامپیوترتان را آلوده کند و دسترسی به فایلهایتان را در اختیار کلاهبرداران قرار بدهد.
-
-اگر ایمیلی از فرستندهای ناشناس دریافت کردید، به یاد داشته باشید:
-
-- هیچگاه لینک یا پیوست ارسالی از آدرسهای ایمیل ناشناس را باز نکنید
-- هیچگاه رمزها یا اطلاعات شخصیتان را برای کسی فاش نکنید
-- ایمیلهای افراد ناشناس را پاک کنید
-
-[اطلاعات بیشتر درباره پرهیز از کلاهبرداری فیشینگ](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico)
-
-### کلاهبرداری کارگزاری معامله ارزهای رمزنگاریشده {#broker-scams}
-
-کارگزارهای جعلی معامله رمزارز ادعا می کنند کارگزارهای تخصصی رمزارز هستند و پیشنهاد می کنند پول شما را بگیرند تا از طرف شما سرمایهگذاری کنند. پس از آن که کلاهبردار سرمایه شما را گرفت، ممکن است رفتار شما را هدایت کند و از شما بخواهد سرمایه بیشتری به او بدهید تا از دریافت سود بیشتر جا نمانید، یا اینکه ممکن است به کلی ناپدید شود.
-
-این کلاهبرداران اغلب با استفاده از حسابهای جعلی در یوتیوب طعمههایی را پیدا میکنند تا مکالمات به ظاهر طبیعی درباره «کارگزاری» را شروع کنند. این صحبتها عموما به شدت رای مثبت دریافت میکنند تا وجهه آنها بهتر نشان داده شود اما این رأیهای مثبت از طرف حسابهای روباتی هستند.
-
-**به غریبههای اینترنتی برای سرمایهگذاری بهجای شما اعتماد نکنید. رمزارز خود را از دست خواهید داد.**
-
-![یک کلاهبرداری کارگزاری معاملاتی در یوتیوب](./brokerScam.png)
-
-### کلاهبرداریهای استخر استخراج رمزارز {#mining-pool-scams}
-
-از سپتامبر 2022، استخراج در اتریوم دیگر امکان پذیر نیست. با این حال، کلاهبرداری استخر استخراج هنوز وجود دارد. کلاهبرداری استخر استخراج از افرادی سر میزند که به طور ناخواسته با شما تماس می گیرند و ادعا می کنند که می توانید با پیوستن به یک استخر استخراج اتریوم، بازدهی زیادی داشته باشید. کلاهبردار ادعاهایی را مطرح میکند و تا وقتی لازم باشد با شما در ارتباط باقی میماند. در اصل، کلاهبردار سعی میکند شما را متقاعد کند وقتی به یک استخر استخراج اتریوم میپیوندید، از رمزارز شما برای تولید اتر استفاده میشود و سود سهامگذاری اتر به شما پرداخت میشود. سپس خواهید دید که رمزارز شما بازدهی کمی دارد. هدف صرفاً ترغیب شما به سرمایهگذاری بیشتر است. در نهایت، تمام وجوه شما به یک آدرس نامعلوم ارسال میشود و کلاهبردار یا ناپدید میشود یا در برخی موارد مانند موردی که اخیرا رخ داده، در تماس باقی میماند.
-
-موضوع اساسی: مراقب افرادی باشید که در رسانههای اجتماعی با شما ارتباط میگیرند و از شما میخواهند عضوی از یک استخر استخراج باشید. وقتی رمزارزتان را از دست بدهید، دیگر نمیتوانید آن را برگردانید.
-
-چند نکته برای بهخاطرسپاری:
-
-- در مقابل کسانی که به شما درباره پول درآوردن از رمزارزتان پیام میدهند هشیار باشید
-- در مورد سهامگذاری، استخرهای نقدینگی یا هر روش دیگر سرمایهگذاری با رمزارزهایتان تحقیق کنید
-- اگر نخواهیم بگوییم هرگز، چنین طرحهایی بهندرت موجه هستند. اگر موجه بودند، احتمالاً بهشدت رایج بودند و شما درباره آنها میشنیدید.
-
-[مردی 200 هزار دلار را در یک کلاهبرداری استخر استخراج از دست داد](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/)
-
-### کلاهبرداریهای ایردراپ {#airdrop-scams}
-
-کلاهبرداریهای ایردراپ پروژههای جعلی هستند که یک دارایی (NFT، توکن) را به کیف پول شما ایردراپ میکنند و شما را به یک وبسایت کلاهبرداری هدایت میکنند تا دارایی ایردراپشده را دریافت کنید. از شما خواسته میشود با کیف پول اتریومتان وارد وبسایت شوید و با یک تراکنش برای پذیرش آن دارایی «موافقت کنید». این تراکنش با فرستادن کلیدهای خصوصی و عمومی شما به کلاهبردار، حسابتان را فاش میکند. شکل دیگر این کلاهبرداری اینگونه است که شما تراکنشی را تأیید کنید که مبلغی را به حساب کلاهبردار واریز میکند.
-
-[اطلاعات بیشتر درباره کلاهبرداری ایردراپ](https://www.youtube.com/watch?v=LLL_nQp1lGk)
-
-
-
-## امنیت شبکه 101 {#web-security}
-
-### از رمزهای قوی استفاده کنید {#use-strong-passwords}
-
-[بیش از 80% هک شدن حسابهای کاربری ناشی از رمزهای ضعیف یا بهسرقترفته است](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). ترکیب طولانی کاراکترها، اعداد و نمادها به حفظ امنیت حسابهای شما کمک میکند.
-
-یک اشتباه رایج استفاده از ترکیب چند کلمه رایج و مرتبط است. رمزهای شبیه این ناامن هستند زیرا مستعد یک تکنیک هک به نام حمله دیکشنری هستند.
-
-```md
-نمونه یک رمز ضعیف: CuteFluffyKittens!
-
-نمونه یک رمز قوی: ymv\*azu.EAC8eyp8umf
-```
-
-یکی دیگر از اشتباهات رایج استفاده از رمزهایی است که بهراحتی میتوان آنها را از طریق [مهندسی اجتماعی](https://wikipedia.org/wiki/Social_engineering_(security)) حدس زد یا کشف کرد. گنجاندن نام مادر، نام فرزندان یا حیوانات خانگی یا تاریخ تولد در رمز عبور، خطر هک شدن را افزایش میدهد.
-
-#### ویژگیهای رمز خوب: {#good-password-practices}
-
-- تا جایی که برنامه رمزساز شما یا فرمی که مشغول پُر کردن آن هستید اجازه میدهد، رمزتان را طولانی بنویسید
-- از ترکیب حروف بزرگ، کوچک، اعداد و علامت ها استفاده کنید
-- از اطلاعات شخصی، مانند نام خانوادگی، در رمز خود استفاده نکنید
-- از کلمات رایج بپرهیزید
-
-[اطلاعات بیشتر درباره ساخت رمز قدرتمند](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/)
-
-### برای همهچیز، از گذرواژههای منحصربهفرد استفاده کنید {#use-unique-passwords}
-
-رمز قوی که در لو رفتن اطلاعات فاش شده باشد، دیگر یک رمز قوی نیست. از طریق وبسایت [Have I Been Pwned](https://haveibeenpwned.com) میتوانید بررسی کنید که آیا حسابهای شما در هر گونه نشت دادههای عمومی لو رفتهاند یا نه. اگر لو رفتهاند، **آن رمزها را فوراً تغییر دهید**. استفاده از رمزهای منحصر به فرد برای هر حساب، خطر دسترسی هکرها به تمام حسابهای شما را در صورت به خطر افتادن یکی از رمزهایتان، کاهش میدهد.
-
-### از یک برنامه مدیریت رمز استفاده کنید {#use-password-manager}
-
-
-
- استفاده از برنامههای مدیریت رمز میتواند خیال شما را از حیث ساخت رمزهای قوی و منحصربهفرد و بهخاطرسپاری آنها راحت کند! ما قویاً توصیه میکنیم از یک برنامه مدیریت رمز استفاده کنید. بیشتر این برنامهها رایگان هستند!
-
-
-
-بهخاطرسپاری رمزهای قوی و منحصربهفرد برای هر حساب راهکار ایدهآلی نیست. یک برنامه مدیریت رمز، محلی امن و رمزنگاریشده برای تمام رمزها در اختیارتان قرار میدهد که میتوانید از طریق یک رمز مادر به آن دسترسی داشته باشید. بهعلاوه، این برنامهها هنگام ثبتنام در یک سرویس جدید به شما رمزهای قوی پیشنهاد میدهند تا لازم نباشد خودتان رمز بسازید. بسیاری از برنامههای مدیریت رمز همچنین به شما خواهند گفت که اطلاعاتتان در نشت داده ها درز کرده است یا خیر. در این صورت میتوانید پیش از هرگونه حمله خرابکارانه رمزهایتان را عوض کنید.
-
-![مثالی برای استفاده از برنامه مدیریت رمز](./passwordManager.png)
-
-#### یک برنامه مدیریت رمز را امتحان کنید: {#try-password-manager}
-
-- [Bitwarden](https://bitwarden.com/)
-- [KeePass](https://keepass.info/)
-- [1Password](https://1password.com/)
-- و یا دیگر [نرم افزارهای مدیریت رمز توصیه شده](https://www.privacytools.io/secure-password-manager) را بررسی کنید
-
-### از احراز هویت دو عاملی استفاده کنید {#two-factor-authentication}
-
-گاهی اوقات ممکن است از شما خواسته شود هویتتان را از طریق مدارک انحصاری تأیید کنید. به اینها میگوییم **عوامل**. سه عامل مهم شامل این مواردند:
-
-- چیزی که میدانید (مانند یک رمز یا سؤال امنیتی)
-- چیزی که هستید (مانند اثر انگشت یا اسکنر قرنیه/صورت)
-- چیزی که دارید (مانند یک کلید امنیتی یا برنامههای احراز هویت روی تلفن همراه)
-
-استفاده از **احراز هویت دوعاملی (2FA)** یک *عامل امنیتی* اضافی را برای حسابهای آنلاین شما فراهم میکند. احراز هویت دوعاملی تضمین میکند که صرف داشتن رمز برای دسترسی به یک حساب کاربری کافی نیست. عامل دوم معمولاً یک کد 6 رقمی تصادفی است که به آن **رمز یکبارمصرف زماندار (TOTP)** میگویند و با یک برنامه احراز هویت مثل Google Authenticator یا Authy میتوانید به آن دسترسی داشته باشید. اینها بهعنوان عامل «چیزی که دارید» عمل میکنند، چون هستهای که کد زماندار را میسازد روی دستگاه شما نگهداری میشود.
-
-
-
- توجه: استفاده از 2FA پیامکی، در معرض استراق سمع سیم کارت است و ایمن نیست. برای بهترین امنیت، از سرویسی مانند Google Authenticator یا Authy استفاده کنید.
-
-
-
-#### کلید امنیتی {#security-keys}
-
-کلید امنیتی نوع پیشرفته و ایمن 2FA است. کلیدهای امنیتی نوعی دستگاههای احراز هویت با سختافزار فیزیکی هستند که مانند برنامههای احراز هویت کار میکنند. استفاده از کلید امنیتی امنترین روش برای احراز هویت دو عاملی است. بسیاری از این کلیدها از استاندارد عامل دوم جهانی (U2F) FIDO استفاده میکنند. [اطلاعات بیشتر دربارهی FIDO U2F](https://www.yubico.com/authentication-standards/fido-u2f/).
-
-بیشتر درباره 2FA ببینید:
-
-
-
-### افزونههای مرورگر را پاک کنید {#uninstall-browser-extensions}
-
-افزونههای مرورگر، مانند افزونههای کروم یا افزونههای فایرفاکس، میتوانند عملکرد مرورگر را بهبود بخشند، اما خطراتی نیز دارند. بهطور پیشفرض، اکثر افزونههای مرورگرها برای «خواندن و تغییر دادههای سایت» دسترسی میخواهند که به آنها اجازه میدهد با دادههایتان تقریباً هر کاری بکنند. افزونههای Chrome معمولاً بهطور خودکار بهروزرسانی میشوند. در نتیجه، افزونهای که اکنون امن است، ممکن است پس از بهروزرسانی به یک افزونهی خرابکار تبدیل شود. اکثر افزونههای مرورگر قصد ندارند دادههای شما را بدزدند، اما باید بدانید که میتوانند این کار را بکنند.
-
-#### با این کارها ایمن بمانید: {#browser-extension-safety}
-
-- افزونههای مرورگر را تنها از منابع مطمئن نصب کنید
-- افزونههای مرورگر بیاستفاده را پاک کنید
-- افزونههای Chrome را بهصورت محلی نصب کنید تا از بهروزرسانی خودکار جلوگیری کنید (پیشرفته)
-
-[اطلاعات بیشتر دربارهی ریسکهای افزونههای مرورگر](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/)
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-### امنیت وب {#reading-web-security}
-
-- [نزدیک به 3 میلیون دستگاه به بدافزاری روی افزونههای Chrome و Edge آلوده شدند](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) - _دن گودین_
-- [چگونه رمزی قوی بسازیم که فراموش نکنیم](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) - _AVG_
-- [کلید امنیتی چیست؟](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) - _Coinbase_
-
-### امنیت ارزهای رمزنگاریشده {#reading-crypto-security}
-
-- [حفاظت از خود و سرمایهی خود](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) - _MyCrypto_
-- [مشکلات امنیتی رایج در نرم افزار معمول ارتباطی رمزنگاری](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) - _Salus_
-- [راهنمای امنیت برای تازهواردها و همچنین باهوشها](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) - _MyCrypto_
-- [امنیت ارزهای رمزنگاریشده: گذرواژهها و احراز هویت](https://www.youtube.com/watch?v=m8jlnZuV1i4) - _آندرس ام. آنتوپولوس_
-
-### آموزش علیه کلاهبرداری {#reading-scam-education}
-
-- [راهنما: تشخیص توکن های کلاهبرداری](/guides/how-to-id-scam-tokens/)
-- [ایمن ماندن: کلاهبرداریهای رایج](https://support.mycrypto.com/staying-safe/common-scams) - _MyCrypto_
-- [جلوگیری از کلاهبرداری](https://bitcoin.org/en/scams) - _Bitcoin.org_
-- [رشته توییتر در ایمیلها و پیامهای رایج فیشینگ رمزنگاری](https://twitter.com/tayvano_/status/1516225457640787969) - _تیلور موناهان_
-
-
diff --git a/public/content/translations/fa/09) Learn Pages/zero-knowledge-proofs/index.md b/public/content/translations/fa/09) Learn Pages/zero-knowledge-proofs/index.md
deleted file mode 100644
index cb47fa9a1c9..00000000000
--- a/public/content/translations/fa/09) Learn Pages/zero-knowledge-proofs/index.md
+++ /dev/null
@@ -1,214 +0,0 @@
----
-title: اثباتهای دانش-صفر
-description: یک مقدمه غیرتخصصی درباره اثبات دانش صفر، برای مبتدی ها.
-lang: fa
----
-
-# اثبات های دانش صفر چیست؟ {#what-are-zk-proofs}
-
-اثبات دانش صفر، روشی برای اثبات اعتبار یک گزاره بدون افشای خود گزاره است. «ثابت کننده» طرفی است که تلاش می کند ادعایی را ثابت کند، در حالی که «تایید کننده» مسئولیت تایید آن ادعا را دارد.
-
-اثبات دانش صفر اولین بار در سال 1985 در مقالهای با عنوان [«پیچیدگی دانش سیستمهای اثبات تعاملی»](http://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf) مطرح شد که تعریفی از اثبات دانش صفر ارائه میدهد که امروز به طور گسترده مورد ارجاع قرار میگیرد:
-
-> پروتکل دانش صفر روشی است که توسط آن یک طرف (اثبات کننده) **میتواند به طرف دیگر (تأیید کننده)** ثابت کند **که یک چیزی درست است، بدون افشای هیچ اطلاعاتی**، جدا از این واقعیت که این بیانیه خاص درست است یا خیر.
-
-اثباتهای دانش صفر در طول سالیان بهبود یافتهاند و اکنون در چندین اپلیکیشن در دنیای واقعی مورد استفاده قرار میگیرند.
-
-
-
-## چرا به اثبات دانش صفر نیاز داریم؟ {#why-zero-knowledge-proofs-are-important}
-
-اثبات دانش صفر نشاندهندۀ یک پیشرفت چشمگیر در رمزنگاری کاربردی بود، زیرا وعدۀ بهبود امنیت اطلاعات برای افراد را میداد. در نظر بگیرید که چگونه میتوانید ادعای خود (مثلاً «من شهروند کشور X هستم») را به یک طرف دیگر (مثلاً یک ارائهدهندۀ خدمات) اثبات کنید. برای اثبات ادعای خود باید «شواهدی» مانند پاسپورت ملی یا گواهینامۀ رانندگی ارائه دهید.
-
-اما این شیوه مشکلاتی دارد، بیش از همه، فقدان حریم خصوصی. زیرا اطلاعات شناسایی شخصی (PII) اشتراکگذاریشده با سرویسهای طرف ثالث، در پایگاههای دادۀ مرکزی ذخیره میشود که در برابر هک آسیبپذیرند. همزمان با اهمیت یافتن سرقت هویت، درخواستها برای ابزارهایی با قابلیت حفاظت بیشتر از حریم خصوصی به هنگام اشتراکگذاری اطلاعات حساس افزایش یافته است.
-
-اثباتهای دانش صفر این مشکل را با **حذف نیاز به افشای اطلاعات برای اثبات اعتبار ادعاها** حل میکنند. پروتکل دانش صفر، از گزاره (که «شاهد» نامیده میشود) به عنوان ورودی استفاده میکند تا یک اثبات موجز برای اعتبار آن ایجاد کند. این اثبات، تضمینهای محکمی برای صحت یک گزاره بدون افشای اطلاعات مورد استفاده در ایجاد آن ارائه میدهد.
-
-با رجوع به مثال قبلی، تنها مدرکی که برای اثبات ادعای شهروندی خود نیاز دارید، اثبات دانش صفر است. تاییدکننده تنها باید بررسی کند که آیا برخی از ویژگیهای اثبات درست است یا نه تا متقاعد شود که گزارۀ اصلی نیز درست است.
-
-## موارد استفادۀ اثبات دانش صفر {#use-cases-for-zero-knowledge-proofs}
-
-### پرداختهای ناشناس {#anonymous-payments}
-
-پرداختهای کارت اعتباری اغلب برای چندین طرف، از جمله ارائهدهندۀ خدمات پرداخت، بانکها و سایر اشخاص ذینفع (مانند مقامات دولتی) قابل مشاهده است. هرچند نظارت مالی برای شناسایی فعالیتهای غیرقانونی مزیتهایی دارد، اما حریم خصوصی شهروندان عادی را نیز تضعیف میکند.
-
-رمزارزها به عنوان ابزاری در خدمت کاربران، برای انجام معاملات محرمانه و همتا به همتا در نظر گرفته شده بودند. اما بیشتر تراکنشهای ارزهای دیجیتال در بلاکچینهای عمومی به طور آشکار قابل مشاهدهاند. هویت کاربران اغلب مستعار است یا به طور عمدی به هویت دنیای واقعی آنها مرتبط میشود (مثلاً با قرار دادن آدرسهای ETH در پروفایلهای توییتر یا گیتهاب)، یا ممکن است با استفاده از تجزیه و تحلیل دادههای اولیه و آفچین، با هویت دنیای واقعی آنها مرتبط شود.
-
-«سکههای حریم خصوصی» خاصی وجود دارد که برای تراکنشهای کاملاً ناشناس طراحی شدهاند. بلاکچینهای متمرکز بر حریم خصوصی، مانند Zcash و Monero، از جزئیات تراکنش، از جمله آدرسهای فرستنده/گیرنده، نوع دارایی، مقدار، و جدول زمانی تراکنش محافظت میکنند.
-
-با استفاده از فناوری دانش صفر در پروتکل، شبکههای [بلاکچین](/glossary/#blockchain) متمرکز بر حریم خصوصی به [گرهها](/glossary/#node) اجازه میدهند تراکنشها را بدون نیاز به دسترسی به دادههای تراکنش تأیید کنند.
-
-**شواهد دانش صفر نیز برای ناشناس کردن تراکنشها در بلاکچینهای عمومی اعمال میشوند**. به عنوان مثال، Tornado Cash یک سرویس غیرمتمرکز و غیرسرپرستی است که به کاربران اجازه میدهد تا تراکنشهای محرمانه را در اتریوم انجام دهند. Tornado Cash از اثبات دانش صفر برای مخفی کردن جزئیات تراکنش و تضمین حریم خصوصی مالی استفاده میکند. متأسفانه، به این دلیل که ابزارهای حفظ حریم خصوصی «انتخابی» هستند، با فعالیتهای غیرقانونی همراهند. برای غلبه بر این امر، حریم خصوصی در نهایت باید به پیشفرض در بلاکچینهای عمومی تبدیل شود.
-
-### حفاظت از هویت {#identity-protection}
-
-سیستمهای کنونی مدیریت هویت، اطلاعات شخصی را در معرض خطر قرار میدهند. اثبات دانش صفر به افراد کمک میکند تا هویت خود را تایید، و در عین حال از اطلاعات حساس محافظت کنند.
-
-اثبات دانش صفر بهویژه در زمینۀ [هویت غیرمتمرکز](/decentralized-identity/) مفید است. هویت غیرمتمرکز (که «هویت خودمختار» نیز نامیده میشود) توانایی کنترل دسترسی به شناسههای شخصی را به فرد میدهد. اثبات شهروندی بدون فاش کردن جزئیات شناسۀ مالیاتی یا اطلاعات گذرنامه، نمونۀ خوبی است که نشان میدهد چگونه فناوری دانش صفر هویت غیرمتمرکز را امکانپذیر میکند.
-
-### احراز هویت {#authentication}
-
-استفاده از خدمات آنلاین پلتفرمها مستلزم اثبات هویت و حق دسترسی شما به آن پلتفرمها است. این امر اغلب مستلزم ارائۀ اطلاعات شخصی مانند نام، آدرس ایمیل، تاریخ تولد و غیره است. همچنین ممکن است لازم باشد رمزهای عبور طولانی را به خاطر بسپارید یا در خطر از دست دادن دسترسی باشید.
-
-با این حال، اثبات دانش صفر میتواند احراز هویت را هم برای پلتفرمها و هم برای کاربران ساده کند. هنگامی که یک ZK-proof با استفاده از ورودیهای عمومی (مانند دادههایی که عضویت کاربر در پلتفرم را تایید میکند) و ورودیهای خصوصی (مانند جزئیات کاربر) تولید شد، کاربر میتواند بهسادگی آن را برای احراز هویت خود در زمانی که نیاز به دسترسی دارد ارائه کند. این امر تجربۀ کاربران را بهبود میبخشد و سازمانها را از نیاز به ذخیرۀ حجم عظیمی از اطلاعات کاربران معاف میکند.
-
-### محاسبه قابل تایید {#verifiable-computation}
-
-محاسبات قابل تایید یکی دیگر از کاربردهای فناوری اثبات دانش صفر برای بهبود طرحهای بلاکچین است. محاسبه قابل تایید به ما امکان میدهد ضمن حفظ نتایج قابل تایید، محاسبات را به نهاد دیگری برونسپاری کنیم. آن نهاد نتیجه را همراه با اثباتی که تایید میکند برنامه بهدرستی اجرا شده است، ارسال میکند.
-
-محاسبه قابل تأیید **برای بهبود سرعت پردازش در بلاکچینها** بدون کاهش امنیت بسیار مهم است. درک این موضوع مستلزم دانستن تفاوتهای راهحلهای پیشنهادی برای مقیاسپذیری اتریوم است.
-
-[راهحلهای مقیاسپذیری آنچین](/developers/docs/scaling/#on-chain-scaling)، مانند شاردینگ، نیاز به اصلاح گستردۀ لایۀ پایۀ بلاکچین دارند. با این حال، این رویکرد بسیار پیچیده است و اشتباهات در پیادهسازی میتواند مدل امنیتی اتریوم را تضعیف کند.
-
-[راهحلهای مقیاسپذیری آفچین](/developers/docs/scaling/#off-chain-scaling) نیازی به طراحی مجدد پروتکل هستۀ اتریوم ندارند. در عوض، برای بهبود توان عملیاتی در لایۀ پایۀ اتریوم به یک مدل محاسباتی برونسپاری شده تکیه میکنند.
-
-در عمل اینگونه کار میکنند:
-
-- اتریوم به جای پردازش هر تراکنش، اجرا را در یک زنجیرۀ جداگانه بارگذاری میکند.
-
-- پس از پردازش تراکنشها، زنجیرۀ دیگر، نتایج را برای اعمال به حالت اتریوم برمیگرداند.
-
-در اینجا، مزیت این است که اتریوم نیازی به اجرا ندارد و فقط باید نتایج حاصل از محاسبات برونسپاریشده را در حالت خود اعمال کند. این امر ازدحام شبکه را کاهش میدهد و در عین حال سرعت تراکنش را بهبود میبخشد (پروتکلهای آفچین برای اجرای سریعتر بهینه میشوند).
-
-زنجیره نیاز به روشی دارد تا معاملات آفچین را بدون اجرای مجدد آنها اعتبارسنجی کند، در غیر این صورت ارزش اجرای آفچین از بین میرود.
-
-اینجا همان جایی است که محاسبه قابل تایید وارد عمل میشود. هنگامی که یک گره، تراکنشی را خارج از اتریوم اجرا میکند، برای اثبات صحت اجرای آفچین، اثبات دانش صفر را ارائه میدهد. این اثبات (که [اثبات اعتبار](/glossary/#validity-proof) نامیده میشود) معتبر بودن یک تراکنش را تضمین میکند و به اتریوم اجازه میدهد تا نتیجه را در حالت خود اعمال کند، بدون اینکه انتظار داشته باشد کسی آن را مورد تردید قرار دهد.
-
-[رول آپهای دانش صفر](/developers/docs/scaling/zk-rollups) و [ولیدیومها](/developers/docs/scaling/validium/) دو راهحل مقیاسپذیری آفچین هستند که از اثبات اعتبار برای ارائۀ مقیاسپذیری ایمن استفاده میکنند. این پروتکلها هزاران تراکنش را به صورت آفچین اجرا میکنند و اثباتهایی را برای تایید در شبکۀ اتریوم ارائه میکنند. این نتایج را میتوان بلافاصله پس از تایید اثبات اعمال کرد که به اتریوم اجازه میدهد تراکنشهای بیشتری را بدون افزایش محاسبه در لایۀ پایه پردازش کند.
-
-### کاهش رشوه و تبانی در رایگیری آنچین {#secure-blockchain-voting}
-
-طرحهای رایگیری بلاکچین ویژگیهای مناسب زیادی دارند: آنها کاملاً قابل ممیزی، ایمن در برابر حملات، مقاوم در برابر سانسور و عاری از محدودیتهای جغرافیایی هستند. اما حتی طرحهای رایگیری آنچین نیز از مشکل **تبانی** مصون نیستند.
-
-تبانی که به عنوان «هماهنگی برای محدود کردن رقابت آزاد از طریق فریب دادن، گول زدن و گمراه کردن دیگران» تعریف میشود، ممکن است از طریق یک طرف بدخواه که با ارائۀ رشوه بر رایگیری تاثیر میگذارد، عملی شود. به عنوان مثال، آلیس ممکن است از باب رشوه بگیرد تا به `گزینۀ B` رأی دهد، حتی اگر ترجیح خودش `گزینۀ A` باشد.
-
-رشوه و تبانی، اثربخشی هر فرایندی را که از رای دادن به عنوان مکانیسم سیگنالدهی استفاده میکند کاهش میدهد (بهویژه در جایی که کاربران میتوانند نحوۀ رای دادن خود را ثابت کنند). این امر میتواند عواقب قابل توجهی داشته باشد، بهویژه در مواردی که آرا تعیینکنندۀ تخصیص منابع کمیاب هستند.
-
-برای مثال، [مکانیسمهای تامین مالی ثانویه](https://www.radicalxchange.org/concepts/plural-funding/) برای سنجش و اولویتبندی گزینههای خاص از میان پروژههای مختلف نفع عمومی، بر اعانهها تکیه میکنند. هر اعانه به عنوان یک «رای» برای یک پروژۀ خاص محسوب میشود و هر پروژهای که رای بیشتری بیاورد وجوه بیشتری از استخر مربوطه دریافت میکند.
-
-استفاده از رایگیری آنچین، تامین مالی ثانویه را مستعد تبانی میکند: تراکنشهای بلاکچین عمومی هستند، بنابراین رشوهدهندگان میتوانند فعالیت آنچین رشوهگیران را بررسی کنند تا ببینند چگونه «رای دادهاند». به این ترتیب، بودجۀ ثانویه دیگر ابزاری موثر برای تخصیص بودجه بر اساس ترجیحات جمعی جامعه نخواهد بود.
-
-خوشبختانه، راهحلهای جدیدتر مانند MACI که مخفف Minimum Anti-Collusion Infrastructure (زیرساخت ضد تبانی حداقل) است، از اثبات دانش صفر استفاده میکنند تا رایگیری آنچین (مانند مکانیسمهای تامین مالی ثانویه) را در برابر رشوه و تبانی مقاوم کنند. MACI مجموعهای از قراردادهای هوشمند و اسکریپتها است که به یک مدیر مرکزی (که «هماهنگکننده» نامیده میشود) اجازه میدهند تا رایها را _بدون_ افشای جزئیات نحوۀ رای دادن افراد جمعآوری و شمارش کند. با این حال، هنوز هم میتوان شمارش صحیح آرا یا مشارکت یک فرد خاص در رایگیری را تایید کرد.
-
-#### MACI چگونه با اثبات دانش صفر کار میکند؟ {#how-maci-works-with-zk-proofs}
-
-در ابتدا، هماهنگکننده قرارداد MACI را بر روی شبکۀ اتریوم قرار میدهد، پس از آن کاربران میتوانند برای رای دادن (با ثبت کلید عمومی خود در قرارداد هوشمند) ثبتنام کنند. کاربران با ارسال پیامهای رمزگذاریشده از طریق کلید عمومی خود در قرارداد هوشمند رای میدهند (از جمله معیارهای دیگر این است که یک رای معتبر باید با جدیدترین کلید عمومی مرتبط با هویت کاربر امضا شود). سپس، هماهنگکننده پس از پایان دورۀ رایگیری، همۀ پیامها را پردازش میکند، آرا را جمعآوری و نتایج را در زنجیره تایید میکند.
-
-در MACI، از اثباتهای دانش صفر برای اطمینان از صحت محاسبه استفاده میشود، زیرا هماهنگکننده نمیتواند به طور نادرست آرا را پردازش و نتایج را محاسبه کند. این امر با درخواست از هماهنگکننده برای ایجاد اثباتهای ZK-SNARK به دست میآید که تایید میکند الف) همۀ پیامها بهدرستی پردازش شدهاند؛ ب) نتیجۀ نهایی با مجموع آرای _معتبر_ مطابقت دارد.
-
-بنابراین، حتی بدون به اشتراک گذاشتن آرای تکتک کاربران (که معمولاً اتفاق میافتد)، MACI صحت و سلامت نتایج محاسبهشده در فرایند شمارش آرا را تضمین میکند. این ویژگی در کاهش اثربخشی طرحهای تبانی اساسی مفید است. در ادامه، این احتمال را با استفاده از مثال قبلی رشوه دادن باب به آلیس برای رای دادن به گزینۀ مد نظرش، بررسی میکنیم:
-
-- آلیس با ارسال کلید عمومی خود به یک قرارداد هوشمند، برای رای دادن ثبتنام میکند.
-- آلیس در ازای دریافت رشوه از باب، با او توافق میکند که به `گزینۀ B` رای دهد.
-- آلیس به `گزینۀ B` رای میدهد.
-- آلیس به طور محرمانه یک تراکنش رمزگذاریشده برای تغییر کلید عمومی مرتبط با هویت خود ارسال میکند.
-- آلیس با استفاده از کلید عمومی جدید، پیام دیگری (رمزگذاریشده) مبنی بر رای دادن به `گزینۀ A` به قرارداد هوشمند میفرستد.
-- آلیس تراکنشی را به باب نشان میدهد تا بگوید او به `گزینۀ B` رای داده است (که نامعتبر است، زیرا کلید عمومی دیگر با هویت آلیس در سیستم مرتبط نیست)
-- در حین پردازش پیامها، هماهنگکننده رای آلیس برای `گزینۀ B` را نادیده میگیرد و تنها رای `گزینۀ A` را میشمارد. از این رو، تلاش باب برای تبانی با آلیس و دستکاری در رایگیری آنچین با شکست مواجه میشود.
-
-استفاده از MACI نیازمند اعتماد به هماهنگکننده مبنی بر تبانی نکردن با رشوهدهندگان یا تلاش برای رشوه دادن رایدهندگان از سوی او است. هماهنگکننده میتواند پیامهای کاربران را رمزگشایی کند (برای ایجاد اثبات لازم است)، بنابراین آنها میتوانند نحوۀ رای دادن هر فرد را به طور دقیق تایید کنند.
-
-اما در مواردی که هماهنگکننده صادق است، MACI ابزاری قدرتمند برای تضمین سلامت رایگیری آنچین است. این امر بیانکنندۀ دلیل محبوبیت آن در میان برنامههای تامین مالی ثانویه (مانند [↗clr.fund](https://clr.fund/#/about/maci)) است که بهشدت بر صحت آرای تکتک افراد متکی است.
-
-[درباره MACI بیشتر بدانید](https://privacy-scaling-explorations.github.io/maci/).
-
-## اثبات دانش صفر چگونه کار میکند؟ {#how-do-zero-knowledge-proofs-work}
-
-اثبات دانش صفر به شما امکان میدهد که صحت یک گزاره را اثبات کنید، بدون اینکه محتوای آن گزاره را به اشتراک بگذارید یا چگونگی کشف حقیقت را فاش کنید. برای ممکن ساختن این امر، پروتکلهای دانش صفر بر الگوریتمهایی تکیه میکنند که برخی دادهها را به عنوان ورودی میگیرند و «درست» یا «نادرست» را به عنوان خروجی برمیگردانند.
-
-یک پروتکل دانش صفر باید معیارهای زیر را برآورده کند:
-
-1. **کامل بودن**: اگر ورودی معتبر باشد، پروتکل دانش صفر همیشه پاسخ «درست» را برمیگرداند. از این رو، اگر گزارۀ اصلی درست باشد و اثباتکننده و تاییدکننده صادقانه عمل کنند، اثبات را میتوان پذیرفت.
-
-2. **صحت:** اگر ورودی نامعتبر باشد، از نظر تئوری غیرممکن است که پروتکل دانش صفر فریب بخورد تا پاسخ «درست» را بازگرداند. از این رو، یک اثباتکنندۀ دروغگو نمیتواند یک تاییدکنندۀ صادق را فریب دهد تا یک گزارۀ نامعتبر را معتبر بداند (مگر با یک احتمال ناچیز).
-
-3. **دانش صفر**: تاییدکننده، چیزی دربارۀ یک گزاره فراتر از اعتبار یا نادرستی آن یاد نمیگیرد (آنها از گزاره، «دانش صفر» دارند). این الزام همچنین مانع میشود که تاییدکننده از طریق اثبات، به ورودی اصلی (محتوای گزاره) دست یابد.
-
-در شکل اولیه، یک اثبات دانش صفر از سه عنصر تشکیل شده است: **شاهد**،**چالش**، و **پاسخ**.
-
-- **شاهد**: با استفاده از اثبات دانش صفر، اثباتکننده میخواهد آگاهی خود از برخی اطلاعات محرمانه را اثبات کند. اطلاعات محرمانه، «شاهد» اثبات است، و آگاهی مفروض اثباتکننده درباره شاهد، مجموعهای از پرسشها را تعیین میکند که تنها از سوی یک طرف مطلع میتواند پاسخ داده شود. بنابراین، اثباتکننده فرایند اثبات را با انتخاب تصادفی یک پرسش، برآورد پاسخ و ارسال آن برای تاییدکننده آغاز میکند.
-
-- **چالش**: تاییدکننده به طور تصادفی پرسش دیگری را از مجموعه انتخاب میکند و از اثباتکننده میخواهد که به آن پاسخ دهد.
-
-- **پاسخ**: اثباتکننده پرسش را میپذیرد، پاسخ را برآورد میکند و به تاییدکننده بازمیگرداند. پاسخ اثباتکننده، به تاییدکننده اجازه میدهد که بررسی کند آیا اولی واقعاً به شاهد دسترسی دارد یا خیر. برای اطمینان از اینکه اثباتکننده حدسهای کورکورانه نمیزند و پاسخهای صحیحش از سر تصادف و شانس نیست، تاییدکننده سؤالهای بیشتری میپرسد. با تکرار چندبارۀ این تعامل تا زمانی که رضایت تاییدکننده جلب شود، احتمال جعل شدن دانش شاهد از سوی اثبات کننده به میزان قابل توجهی کاهش مییابد.
-
-موارد بالا، ساختار یک «اثبات دانش صفر تعاملی» را شرح میدهد. پروتکلهای اولیۀ دانش صفر از اثبات تعاملی استفاده میکردند، طبق این پروتکلها، تایید اعتبار یک گزاره نیازمند ارتباط رفت و برگشتی میان اثباتکنندهها و تاییدکنندهها بود.
-
-یک مثال خوب که نحوۀ کار اثباتهای تعاملی را روشن میکند، داستان معروف [غار علی بابا](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave) از ژان ژاک کویسکوتر است. در این داستان، پگی (اثباتکننده) میخواهد بدون فاش کردن عبارت رمز، به ویکتور (تاییدکننده) ثابت کند که آن عبارت را میداند تا دری جادویی را باز کند.
-
-### اثبات دانش صفر غیرتعاملی {#non-interactive-zero-knowledge-proofs}
-
-هرچند اثبات تعاملی یک انقلاب محسوب میشد، اما کارایی چندانی نداشت، زیرا مستلزم این بود که دو طرف در دسترس باشند و به طور مکرر با هم تعامل داشته باشند. حتی اگر یک تاییدکننده به صداقت یک اثباتکننده اعتقاد داشته باشد، اثبات برای تایید مستقل در دسترس نخواهد بود (محاسبۀ یک اثبات جدید نیازمند مجموعۀ جدیدی از پیامها بین اثباتکننده و تاییدکننده است).
-
-برای حل این مشکل، مانوئل بلوم، پل فلدمن و سیلویو میکالی اولین [اثباتهای دانش صفر غیرتعاملی](https://dl.acm.org/doi/10.1145/62212.62222) را پیشنهاد کردند که در آن اثباتکننده و تاییدکننده یک کلید مشترک دارند. این کلید اجازه میدهد که اثباتکننده دانش خود از برخی اطلاعات (به عنوان مثال شاهد) را بدون ارائۀ خود اطلاعات اثبات کند.
-
-برخلاف اثباتهای تعاملی، اثباتهای غیرتعاملی فقط به یک دور ارتباط بین شرکتکنندگان (اثباتکننده و تاییدکننده) نیاز دارند. اثباتکننده، برای محاسبۀ اثبات دانش صفر، اطلاعات محرمانه را به یک الگوریتم ویژه میفرستد. این اثبات برای تاییدکننده ارسال میشود، و تاییدکننده با استفاده از الگوریتم دیگری بررسی میکند که آیا اثباتکننده اطلاعات محرمانه را میداند یا خیر.
-
-اثبات غیرتعاملی، ارتباط بین اثباتکننده و تاییدکننده را کاهش میدهد و اثباتکنندههای دانش صفر را کارآمدتر میکند. علاوه بر آن، بهمحض تولید هر اثبات، برای تایید اشخاص دیگر (به شرط داشتن کلید مشترک و الگوریتم تایید) در دسترس است.
-
-اثبات غیرتعاملی پیشرفتی برای فناوری دانش صفر محسوب میشد و باعث توسعۀ سیستمهای اثبات مورد استفادۀ امروزی شد. در زیر به معرفی انواع آن میپردازیم:
-
-### انواع اثبات دانش صفر {#types-of-zero-knowledge-proofs}
-
-#### اسنارکهای دانش-صفر {#zk-snarks}
-
-ZK-SNARK مخفف عبارت **Zero-Knowledge Succinct Non-Interactive Argument of Knowledge** است. پروتکل ZK-SNARK دارای ویژگیهای زیر است:
-
-- **دانش صفر**: یک تاییدکننده میتواند یکپارچگی یک گزاره را بدون دانستن چیز دیگری در مورد آن گزاره تایید کند. تنها دانش تاییدکننده از گزاره، درست یا نادرست بودن آن است.
-
-- **موجز**: اثبات دانش صفر کوچکتر از شاهد، و بهسرعت قابل تایید است.
-
-- **غیرتعاملی**: اثبات «غیرتعاملی» است، زیرا اثباتکننده و تاییدکننده فقط یک دور باهم تعامل دارند، برخلاف اثباتهای تعاملی که به چندین دور ارتباط نیاز دارند.
-
-- **استدلال**: اثبات، شرط «صحت» را برآورده میکند، بنابراین تقلب بسیار بعید است.
-
-- **(از) دانش**: اثبات دانش صفر بدون دسترسی به اطلاعات محرمانه (شاهد) قابل ساخت نیست. برای اثباتکنندهای که شاهد ندارد، اگر نگوییم غیرممکن، اما دشوار است که یک اثبات دانش صفر معتبر را محاسبه کند.
-
-«کلید مشترک» که قبلاً به آن اشاره کردیم، به پارامترهای عمومی اشاره دارد که اثباتکننده و تاییدکننده توافق میکنند از آنها در تولید و تایید شواهد استفاده کنند. تولید پارامترهای عمومی (که در مجموع، به عنوان رشتۀ مرجع مشترک یا بهاختصار CRS شناخته میشود) به دلیل اهمیت آن در امنیت پروتکل، یک عملیات حساس است. اگر آنتروپی (تصادفی بودن) مورد استفاده در تولید CRS به دست یک اثباتکنندۀ نااهل بیفتد، ممکن است اثباتهای تقلبی را محاسبه کنند.
-
-[محاسبات چندجانبه که بهاختصار MPC گفته میشود](https://en.wikipedia.org/wiki/Secure_multi-party_computation)، راهی برای کاهش ریسک در تولید پارامترهای عمومی است. در این نوع محاسبات، چندین طرف در یک [مراسم راهاندازی مورد اعتماد](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) شرکت میکنند، که در آن هر فرد مقادیری تصادفی برای تولید CRS ارائه میکند. تا زمانی که یک طرف صادق بخشی از آنتروپی خود را از بین ببرد، پروتکل ZK-SNARK سلامت محاسباتی را حفظ میکند.
-
-راهاندازیهای مورد اعتماد، کاربران را ملزم میکنند در تولید پارامتر به شرکتکنندگان اعتماد کنند. با این حال، توسعۀ ZK-STARKs پروتکلهای اثباتی را فعال کرده است که با یک راهاندازی غیرمعتمد کار میکنند.
-
-#### استارکهای دانش-صفر {#zk-starks}
-
-ZK-STARK مخفف عبارت **Zero-Knowledge Scalable Transparent Argument of Knowledge** است. ZK-STARKها مشابه ZK-SNARKها هستند، با این تفاوت که ویژگیهای زیر را دارند:
-
-- **مقیاسپذیر**: در مواقعی که اندازۀ شاهد بزرگتر است، ZK-STARK در ایجاد و تایید مدارک، سریعتر از ZK-SNARK عمل میکند. با بزرگتر شدن شاهد، زمان مورد نیاز برای اثبات و تایید توسط اثباتهای STARK تنها اندکی افزایش پیدا میکند (زمانهای اثباتکننده و تاییدکنندۀ SNARK با افزایش اندازۀ شاهد به صورت خطی افزایش مییابند).
-
-- **شفاف**: برای ایجاد پارامترهای عمومی به منظور اثبات و تایید، ZK-STARK به جای اینکه به راهاندازی مورد اعتماد متکی باشد، به تصادف قابل تایید عمومی متکی است. بنابراین، در مقایسه با ZK-SNARK شفافتر هستند.
-
-ZK-STARKها، نسبت به ZK-SNARKها اثباتهای بزرگتری تولید میکنند، به این معنی که معمولاً منابع/هزینۀ بیشتری برای تایید نیاز دارند. با این حال، ممکن است در برخی موارد (مانند اثبات مجموعه دادههای بزرگ)، ZK-STARK نسبت به ZK-SNARK مقرونبهصرفهتر باشد.
-
-## معایب استفاده از اثبات دانش صفر {#drawbacks-of-using-zero-knowledge-proofs}
-
-### هزینههای سختافزاری {#hardware-costs}
-
-تولید اثباتهای دانش صفر شامل محاسبات بسیار پیچیدهای است که تنها در ماشینهای تخصصی به بهترین وجه انجام میشود. از آنجا که این ماشینها گرانقیمتاند، اغلب در دسترس افراد عادی نیستند. بهعلاوه، برنامههایی که میخواهند از فناوری دانش صفر استفاده کنند، میبایست هزینههای سختافزاری را لحاظ کنند، که احتمال دارد باعث افزایش هزینهها برای کاربران نهایی شود.
-
-### هزینههای تایید اثبات {#proof-verification-costs}
-
-تایید اثباتها همچنین نیازمند محاسبه پیچیده است و هزینههای پیادهسازی فناوری دانش صفر در برنامهها را افزایش میدهد. این هزینه بهویژه در زمینۀ اثبات محاسبه متناسب است. به عنوان مثال، رولآپهای ZK برای تایید یک اثبات ZK-SNARK در اتریوم حدود 500000 گس هزینه برمیدارد و هزینههای ZK-STARKها از این رقم هم بالاتر است.
-
-### مفروضات اعتماد {#trust-assumptions}
-
-در ZK-SNARK، رشته مرجع مشترک (Common Reference String) یا همان پارامترهای عمومی، یک بار تولید میشود و از آن پس، برای استفادۀ طرفهایی که مایل به شرکت در پروتکل دانش صفر هستند در دسترس خواهد بود. پارامترهای عمومی از طریق یک مراسم راهاندازی مورد اعتماد ایجاد میشوند، که در آن شرکتکنندگان مورد اعتمادند.
-
-اما در واقع، هیچ راهی برای کاربران وجود ندارد تا صداقت شرکا را ارزیابی کنند و آنها ناگزیدند به قول توسعهدهندگان اطمینان کنند. اما ZK-STARKها نیازی به مفروضات اعتماد ندارند زیرا تصادفی بودن استفاده شده در تولید رشته به طور عمومی قابل تایید است. در همین حال، محققان در حال کار بر روی راهاندازی بدون اعتماد برای ZK-SNARKها هستند تا امنیت مکانیسمهای اثبات را افزایش دهند.
-
-### تهدیدات محاسبات کوانتومی {#quantum-computing-threats}
-
-ZK-SNARK از رمزنگاری منحنی بیضوی برای رمزگذاری استفاده میکند. در حالی که فرض میشود مشکل لگاریتم گسسته منحنی بیضوی در حال حاضر غیرقابل حل است، توسعه رایانههای کوانتومی میتواند این مدل امنیتی را در آینده شکست دهد.
-
-ZK-STARK در مقابل تهدید محاسبات کوانتومی مصون در نظر گرفته میشود، زیرا برای امنیت خود فقط به توابع هش ضدتصادم متکی است. برخلاف جفت کلیدهای عمومی-خصوصی که در رمزنگاری منحنی بیضوی استفاده میشوند، شکستن هش مقاوم در برابر تصادم، برای الگوریتمهای محاسبات کوانتومی دشوارتر است.
-
-## بیشتر بخوانید {#further-reading}
-
-- [بررسی اجمالی موارد استفاده برای اثبات دانش صفر](https://pse.dev/projects) - _تیم کاوشهای حریم خصوصی و مقیاسپذیری_
-- [SNARKها در مقایسه با STARKها و SNARKهای بازگشتی](https://www.alchemy.com/overviews/snarks-vs-starks) — _خلاصههای کیمیاگری_
-- [اثبات دانش صفر: بهبود حریم خصوصی در یک بلاکچین](https://www.altoros.com/blog/zero-knowledge-proof-improving-privacy-for-a-blockchain/) - _دیمیتری لاورنوف_
-- [zk-SNARKها - یک مثال واقعی از دانش صفر و بررسی جامع آن](https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c) - _آدام لوسیانو_
-- [ZK-STARKها - ایجاد اعتماد قابل تایید، حتی نسبت به رایانههای کوانتومی](https://medium.com/coinmonks/zk-starks-create-verifiable-trust-even-against-quantum-computers-dd9c6a2bb13d) - _آدام لوسیانو_
-- [مقدمهای تقریبی دربارۀ ممکن بودن zk-SNARKها](https://vitalik.eth.limo/general/2021/01/26/snarks.html) - _ویتالیک بوترین_
-- [چرا اثباتهای دانش صفر (ZKPs) یک عامل مهم برای هویت خودمختار هستند؟](https://frankiefab.hashnode.dev/why-zero-knowledge-proofs-zkps-is-a-game-changer-for-self-sovereign-identity) — _فرانکلین اوهاگبولام_
-
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md
deleted file mode 100644
index 4b23e889a86..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: چگونگی «ساخت» یک حساب اتریوم
-description: راهنمای گام به گام درباره ساخت حساب اتریوم با استفاده از کیف پول.
-lang: fa
----
-
-# چگونگی «ساخت» یک حساب اتریوم
-
-**هر کس میتواند یک حساب اتریوم به صورت رایگان ایجاد کند.** فقط باید یک برنامه کیفپول رمزارزی نصب کنید. کیفپولها حساب اتریوم شما را ایجاد و مدیریت میکنند. آنها میتوانند تراکنشها را ارسال کنند، موجودیهای شما را بررسی کنند، و شما را به سایر برنامههای ساخته شده بر روی اتریوم متصل کنند.
-
-با یک کیفپول میتوانید فوراً وارد هر صرافی، بازی، و بازار [NFT](/glossary/#nft) شوید. نیازی به ثبتنام جداگانه نیست، یک حساب برای همه برنامههای ساخته شده بر روی اتریوم به اشتراک گذاشته میشود.
-
-## قدم اول: یک کیف پول انتخاب کنید
-
-کیف پول اپلیکیشنی است که به شما کمک می کند حساب اتریوم خود را مدیریت کنید. دهها کیفپول مختلف برای انتخاب وجود دارد: موبایل، دسکتاپ یا حتی افزونههای مرورگر.
-
-
-
- لیست کیف پول ها
-
-
-اگر تازهکار هستید، میتوانید فیلتر «New to crypto» را در صفحه «یافتن کیف پول» انتخاب کنید تا کیفهایی را که باید شامل همه ویژگیهای لازم برای مبتدیان باشند، شناسایی کنید.
-
-![انتخاب فیلتر در صفحه «یافتن کیفپول»](./wallet-box.png)
-
-همچنین سایر فیلترهای پروفایل برای رفع نیازهای شما وجود دارد. اینها نمونه هایی از کیف پولهای رایج هستند - قبل از اعتماد به هر نرمافزار باید تحقیق خود را انجام دهید.
-
-## قدم دوم: بارگذاری و نصب اپلیکیشن کیف پول
-
-هنگامی که تصمیم گرفتید یک کیف پول خاص را انتخاب کنید، به وب سایت رسمی آن یا app store مراجعه کنید، آن را دانلود و نصب کنید. همه آنها باید رایگان باشند.
-
-## مرحله سوم: برنامه را باز کنید و حساب اتریوم خود را بسازید
-
-اولین باری که کیف پول جدید خود را باز میکنید ممکن است از شما خواسته شود بین ایجاد یک حساب جدید یا وارد کردن یک حساب موجود یکی را انتخاب کنید. روی ساخت حساب جدید کلیک کنید. **این مرحلهای است که طی آن نرمافزار کیفپول حساب اتریوم شما را تولید میکند.**
-
-## مرحله 4: عبارت بازیابی خود را ذخیره کنید
-
-برخی از برنامهها از شما درخواست میکنند که یک "عبارت بازیابی" مخفی را ذخیره کنید (که گاهی اوقات "عبارت بذر" یا "مانمونیک" نامیده میشوند). ایمن نگه داشتن این عبارت بسیار مهم است! از آن بذر برای ایجاد حساب اتریوم شما استفاده میشود و می توان از آن برای ارسال تراکنش ها استفاده کرد.
-
-**هر فرد که از این عبارات آگاه است میتواند کنترل همه سرمایهها را در دست بگیرد.** هرگز آن را با کسی به اشتراک نگذارید. این عبارت باید شامل 12 تا 24 کلمه باشد که بهطور تصادفی تولید شده باشند (ترتیب کلمات مهم است).
-
-
-
- کیفپول نصب شد؟
نحوه استفاده اینجاست.
-
- چگونگی استفاده از کیفپول
-
-
-
-
-به راهنماهای دیگر علاقهمندید؟ [راهنماهای گامبهگام](/guides/) ما را بررسی کنید
-
-## پرسشهای متداول
-
-### آیا کیف پول و حساب اتریوم من یکی هستند؟
-
-خیر. کیف پول یک ابزار مدیریت است که به شما کمک می کند حسابهای خود را مدیریت کنید. یک کیفپول ممکن است به چندین حساب دسترسی داشته باشد و یک حسابِ تنها، توسط چندین کیفپول قابل دسترسی است. عبارت بازیابی برای ایجاد حسابها استفاده میشود و به یک برنامه کیفپول اجازه میدهد تا داراییها را مدیریت کند.
-
-### آیا میتوانم بیتکوین به یک آدرس اتریوم و یا اتر به یک آدرس بیتکوین ارسال کنیم؟
-
-خیر، نمیتوانید. بیتکوین و اتر در دو شبکه مجزا (یعنی بلاکچین های مختلف) وجود دارند که هر کدام دارای فرمتهای حسابداری و آدرس مختص خود هستند. تلاشهای مختلف برای ایجاد پل ارتباطی بین دو شبکه مختلف صورت گرفته است که فعالترین آنها در حال حاضر[ رپد بیتکوین یا WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/) است. این به معنی تایید WBTC نیست، چون توکن WBTC از طریق یک راهکار سرپرستی است (به این معنی که یک گروه از افراد کنترل توابع حیاتی خاص را دارند) و اینجا تنها برای اطلاعرسانی از آن یاد شده است.
-
-### اگر من صاحب یک آدرس اتریوم باشم، صاحب همان آدرس روی سایر بلاکچینها نیز هستم؟
-
-میتوانید از یک [آدرس](/glossary/#address) در همه بلاکچینهایی که از نرمافزار زیربنایی مشابه اتریوم (معروف به «سازگار با EVM») استفاده میکنند، استفاده کنید. این [لیست](https://chainlist.org/) بلاکچینهایی را که در آن میتوانید از آدرس یکسان استفاده کنید نمایش میدهد. بعضی بلاکچینها، مثل بیتکوین، قوانین شبکه کاملا متفاوتی اجرا میکنند و برای استفاده از آن شبکه به آدرس متفاوت با فرمت متفاوت احتیاج است. اگر یک کیف پول قرارداد هوشمند دارید، باید وب سایت محصول آن را برای اطلاعات بیشتر در مورد اینکه کدام بلاکچین ها پشتیبانی میشوند بررسی کنید، زیرا معمولاً آن ها دامنه محدود اما ایمنتری دارند.
-
-### آیا نگهداری دارایی دیجیتال در کیف پول شخصی، ایمنتر از نگهداری آن در صرافی است؟
-
-استفاده از کیف پول شخصی به معنی قبول مسئولیت امنیت داراییهایتان است. متأسفانه مثالهای زیادی از اتفاقات ناگوار در صرافیها وجود دارند که باعث از دست رفتن سرمایه مشتریان آنها شدهاند. داشتن یک کیفپول (با عبارت بازیابی) خطر مربوط به اعتماد به برخی نهادها برای نگهداری داراییهای شما را از بین میبرد. بااینحال، خودتان باید آن را ایمن کنید و از کلاهبرداریهای فیشینگ، تایید تصادفی تراکنشها یا افشای عبارت بازیابی، تعامل با وبسایت های جعلی، و سایر خطرات مربوط به حضانت دارایی خودداری کنید. ریسک ها و فواید متفاوتند.
-
-### اگر گوشی تلفن همراه/کیف پول سختافزاری خودم را گم کنم، لازم است از همان اپلیکیشن کیف پول دیجیتال قبلی برای بازیابی حساب از دست رفته استفاده کنم؟
-
-خیر، میتوانید از کیف پول دیگری هم استفاده کنید. مادامی که عبارت بذر خود را داشته باشید میتوانید با وارد کردن آن در اکثر کیف پول های دیجیتال حساب خود را بازیابی کنید. اگر زمانی خواستید این کار را انجام دهید مراقب باشید: بهتر است مطمئن شوید هنگام بازیابی کیف پول به اینترنت متصل نباشید تا از نشت اتفاقی عبارت بذر در اینترنت جلوگیری کنید. غالباً بازیابی وجوه از دست رفته بدون داشتن عبارات بازیابی غیرممکن است.
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md
deleted file mode 100644
index 8d3a715c950..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: چگونگی تشخیص توکن های کلاهبرداری
-description: فهمیدن توکن های کلاهبرداری، آنها چگونه خود را قانونی جلوه می دهند و چگونه باید از آن ها اجتناب کرد.
-lang: fa
----
-
-# چگونگی تشخیص توکن های کلاهبرداری {#identify-scam-tokens}
-
-یکی از رایجترین استفادههای اتریوم، ایجاد یک توکن قابل معامله توسط یک گروه است، که به نوعی واحد پول خودشان است. این توکن ها معمولا یک استاندارد [ERC-20](/developers/docs/standards/tokens/erc-20/) را دنبال میکنند. با این حال، هر جا که موارد استفاده قانونی وجود داشته باشد که ارزشی به همراه دارند، مجرمانی نیز وجود دارند که سعی بر دزدیدن آن ارزش برای خود دارند.
-
-دو روش وجود دارد که در آنها ممکن است شما را فریب دهند:
-
-- **فروش یک توکن کلاهبرداری به شما**، که ممکن است شبیه یک توکن قانونی باشد که قصد خرید آن را دارید، اما توسط کلاهبردارها صادر شده اند و ارزشی ندارند.
-- **اغفال شما برای امضا کردن نراکتش های بد**، معمولا با هدایت شما به رابط کاربری خودشان. آنها ممکن است شما را وادار کنند تا به قراردادهایشان یک اجازه دسترسی بر روی توکن های ERC-20 خود بدهید که باعث افشای اظلاعات حساس و دسترسی آنها به دارایی شما می گردد، و سایر موارد. این رابطهای کاربری ممکن است به بهترین نحو کپی از سایت های قابل اعتماد باشند، ولی با حقههای مخفی.
-
-برای نشان دادن اینکه توکن های کلاهبرداری چه هستند و نحوه شناسایی آنها، قصد داریم یک مثال را بررسی کنیم:[`wARB`](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82). این توکن تلاش دارد تا شبیه توکن قانونی [`ARB`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) باشد.
-
-
-
-آربیتروم سازمانی است که رول آپ های خوشبینانه را توسعه داده و مدیریت می کند. در ابتدا، آربیتروم به عنوان یک شرکت انتفاعی تشکیل شد اما سپس اقداماتی را در جهت غیر متمرکز شدن انجام داد. به عنوان بخشی از آن فرایند، آنها یک توکن حاکمیت قابل مبادله را صادر کردند.
-
-
-
-
-
-قراردادی در اتریوم وجود دارد که زمانیکه یک دارایی سازگار با ERC-20 نیست ما یک نسخه "رپد" از آن را ایجاد می کنیم که نام آن با "w" شروع می شود. بنابراین، به عنوان مثال، ما wBTC را برای بیتکوین و wETH را برای اتر داریم.
-
-ایجاد ورژن "رپد" از یک توکن ERC-20 که از قبل در اتریوم موجود است بی معنی خواهد بود، در حالی که کلاهبرداران تنها به ظاهر مشروع آن اتکا می کنند، نه به ماهیت زیربنایی آن.
-
-
-
-## توکن های کلاهبرداری چگونه کار می کنند؟ {#how-do-scam-tokens-work}
-
-تمام هدف اتریوم تمرکز زدایی است. این بدان معنی است که هیچ قدرت مرکزی وجود ندارد که بتواند دارایی های شما را ضبط کند یا مانع بکارگیری قرارداد هوشمند شما شود. اما این همچنین به این معناست که کلاهبرداران میتوانند هر قرارداد هوشمندی که می خواهند را بکار بگیرند.
-
-
-
-قراردادهای هوشمند برنامههایی هستند که بر روی بلاکچین اتریوم اجرا میشوند. هر توکن ERC-20، برای مثال، به عنوان یک قرارداد هوشمند اجرا می شود.
-
-
-
-به طور خاص، آربیتروم قراردادی را به کار گرفت که از نماد `ARB` استفاده می کند. اما این امر، افراد دیگر را از بکارگیری قراردادی که از نماد دقیقا یکسان، یا یک نماد مشابه استفاده می کند، بازنمیدارد. هرکس که قرارداد را می نویسد تعیین می کند که قرارداد چه کاری انجام می دهد.
-
-## مشروع جلوه دادن {#appearing-legitimate}
-
-چندین ترفند وجود دارد که سازندگان توکن تقلبی انجام می دهند تا مشروع جلوه کنند.
-
-- **نام و علامت قانونی**. همانطور که قبلا ذکر شد، قراردادهای ERC-20 ممکن است نام و علامت مشابه قراردادهای ERC-20 دیگر را داشته باشند. برای امنیت، نمی توانید روی آن فیلدها حساب کنید.
-
-- **صاحبان قانونی**. توکن های تقلبی اغلب موجودی قابل توجهی را به آدرس هایی که انتظار میرود دارندگان قانونی توکن واقعی باشند ایردراپ می کنند.
-
- برای مثال، بیایید دوباره به `wARB` نگاه کنیم. [حدود 16% از توکن ها](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82?a=0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f) در آدرسی نگهداری می شوند که برچسب عمومی آن [بنیاد آربیتروم: توسعهدهنده](https://etherscan.io/address/0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f) است. این یک آدرس جعلی _نیست_، بلکه آدرسی است که [قرارداد واقعی ARB را روی شبکه اصلی اتریوم به کار گرفته است](https://etherscan.io/tx/0x242b50ab4fe9896cb0439cfe6e2321d23feede7eeceb31aa2dbb46fc06ed2670).
-
- از آنجا که موجودی ERC-20 یک آدرس، بخشی از حافظه ERC-20 قرارداد است، قرارداد میتواند آن را به عنوان هر چیزی که توسعهدهنده قرارداد دوست دارد تعیین کند. همچنین قرارداد میتواند انتقالها را ممنوع کند، طوری که کاربران معتبر از شر آن توکنهای تقلبی خلاص نخواهند شد.
-
-- ** انتقال های قانونی**. _صاحبان قانونی برای انتقال یک توکن جعلی به دیگران هزینه نمیکنند، بنابراین اگر انتقال هایی وجود داشته باشد، باید قانونی باشند، درست است؟_ **خیر،اشتباهه**. رویداد های `انتقال توکن` توسط قرارداد ERC-20 ساخته میشوند. یک کلاه بردار به آسانی می تواند یک قرارداد هوشمند بنویسد، طوری که آن اقدامات را ایجاد کند.
-
-## وبسایت های کلاه برداری {#websites}
-
-کلاه برداران همچنین می توانند وبسایت های بسیار قانع کننده ای ایجاد کنند، بعضی مواقع حتی کپی کردن دقیق سایت های معتبر با رابط های کاربری یکسان، ولی با ترفندهای ماهرانه. مثالها میتوانند لینک های خارجی باشند که قانونی به نظر می رسند و در واقع کاربر را به یک سایت کلاهبردار بیرونی میفرستند، یا دستورالعمل های نادرستی که کاربر را به سمت افشای کلیدهایشان یا ارسال وجوه به یک آدرس طرف مهاجم راهنمایی می کنند.
-
-بهترین روش برای جلوگیری از این، چک کردن دقیق URL سایت هایی است که بازدید می کنید، و آدرس سایت های معتبر شناخته شده را در نشانک های خود ذخیره کنید. سپس، می توانید از طریق نشانک ها به سایت های حقیقی دسترسی پیدا کنید، بدون اینکه تصادفا اشتباهات املایی داشته باشید یا به لینک های خارجی اتکا کنید.
-
-## چگونه از خود محافظت کنید؟ {#protect-yourself}
-
-1. **آدرس قرارداد را چک کنید**. توکن های قانونی توسط سازمان های قانونی تولید میشوند، و شما میتوانید آدرسهای قرارداد را در وبسایت این سازمان ها ببینید. برای مثال، در [برای`ARB` میتوانید آدرسهای قانونی را در اینجا ببینید](https://docs.arbitrum.foundation/deployment-addresses#token).
-
-2. **توکن های واقعی نقدینگی دارند**. گزینه دیگر، بررسی سایز استخر نقدینگی در [Uniswap](https://uniswap.org/) است که یکی از معمولترین پروتکل های تبادل توکن است. این پروتکل، از استخرهای نقدینگی استفاده میکند، و سرمایه گذاران توکن های خود را به امید کسب درآمد از کارمزد معاملات، در این پلتفرم سپردهگذاری میکنند.
-
-توکن های جعلی، معمولا استخرهای نقدینگی کوچکی دارند، اگر داشته باشند، چون کلاهبردارن نمی خواهند با دارایی واقعی خود ریسک کنند. برای مثال، استخر `ARB`/`ETH` در پروتکل Uniswap حدود یک میلیون دلار دارد ([برای مقدار بهروز شده، اینجا را ببینید](https://info.uniswap.org/#/pools/0x755e5a186f0469583bd2e80d1216e02ab88ec6ca)) و خرید و فروش مقدار کم باعث تغییر قیمت نمیشود:
-
-![خرید یک توکن قانونی](./uniswap-real.png)
-
-اما زمانی که بخواهید توکن جعلی `wARB` را حتی به اندازه بسیار کم بخرید، قیمت بیشتر از 90 درصد تغییر میکند:
-
-![خرید یک توکن جعلی](./uniswap-scam.png)
-
-این گواه دیگری است که به ما نشان میدهد `wARB` احتمالا توکن قانونی نیست.
-
-3. ** Etherscan را چک کنید**. بسیاری از توکن های جعلی توسط اعضای جامعه تشخیص داده شده و گزارش شده اند. این نوع توکن ها در [Etherscan نشانه گذاری شده اند](https://info.etherscan.com/etherscan-token-reputation/). در حالی که Etherscan یک منبع معتبر حقیقت نیست (این به طبیعت شبکههای غیرمتمرکز برمیگردد که در آن یک نهاد قدرت برای مشروعسازی وجود ندارد)، توکن هایی که توسط Etherscan به عنوان جعلی شناسایی شده اند احتمالا جعلی هستند.
-
- ![توکن جعلی در Etherscan](./etherscan-scam.png)
-
-## نتيجه گيری {#conclusion}
-
-تا زمانی که چیز ارزشمندی در دنیا وجود داشته باشد، کلاهبرداری وجود خواهند داشت که آن را از یکدیگر بدزدند، و در یک دنیای غیرمتمرکز هیچ کس برای حفاظت از شما غیر از خودتان وجود ندارد. امیدوارم این نکات را برای تشخیص توکنهای قانونی از جعلی همیشه به یاد داشته باشید:
-
-- توکن های کلاهبرداری توکن های قانونی را جعل میکنند، آنها ممکن است از اسم و علامت یکسانی استفاده کنند.
-- توکن های جعلی _نمیتوانند_ از آدرس قرارداد یکسان استفاده کنند.
-- بهترین منبع برای آدرس یک توکن قانونی، سازمان سازنده آن توکن است.
-- اگر آن در دسترس نبود، میتوانید از اپلیکیشنهای پرطرفدار و مورد اطمینان مثل [Uniswap](https://app.uniswap.org/#/swap) و [Etherscan](https://etherscan.io/) استفاده کنید.
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md
deleted file mode 100644
index 26ba41546a4..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: چطور دست رسی یک قرارداد هوشمند را به دارایی های خود ممنوع کنیم
-description: راهنمای لغو دسترسی غیرمجاز به توکن قرارداد هوشمند
-lang: fa
----
-
-# چطور دست رسی یک قرارداد هوشمند را به دارایی های خود ممنوع کنیم
-
-این راهنما به شما نشان میدهد که چگونه فهرستی از همه [قراردادهای هوشمند](/glossary/#smart-contract) را که اجازه دسترسی به وجوه تان را به آنها دادهاید و نحوه لغو آنها را مشاهده کنید.
-
-بعضی وقتها توسعهدهندگان خرابکار، درهای پشتی را برای ورود به قراردادهای هوشمند ایجاد میکنند که امکان دسترسی به منابع مالی کاربران ناآگاه قراردادهای هوشمند را فراهم میکنند. آنچه اغلب اتفاق میافتد این است که چنین پلتفرمهایی از کاربر اجازه میخواهند تا **تعداد نامحدودی از توکنها** را برای صرفهجویی در مقدار کمی [گس](/glossary/#gas) در آینده خرج کند، اما این امر با افزایش خطر همراه است.
-
-هنگامی که یک پلتفرم دارای حقوق دسترسی نامحدود به یک توکن درون [کیفپول](/glossary/#wallet) شما باشد، میتواند تمام آن توکنها را خرج کند، حتی اگر وجوه تان را از پلتفرم آنها در کیفپول خود برداشت کرده باشید. عوامل خرابکار همچنان میتوانند با دسترسی به وجوه شما، آنها را به کیف پول خود منتقل کنند بدون اینکه هیچگونه حق بازیابی برای شما باقی بگذارند.
-
-تنها راه محافظت این است که از پروژههای جدید آزمایشنشده استفاده نکنید، فقط موارد مورد نیاز را تأیید کنید یا بهطور منظم دسترسیها را لغو کنید. اما، چگونه این کار را انجام دهید؟
-
-## مرحلۀ 1: از ابزارهای لغو دسترسی استفاده کنید
-
-چندین وبسایت به شما این امکان را میدهند که قراردادهای هوشمند متصل به آدرس خود را مشاهده و لغو کنید. به وبسایت رجوع کنید و کیف پول خود را متصل کنید:
-
-- [Ethallowance](https://ethallowance.com/) (اتریوم)
-- [Etherscan](https://etherscan.io/tokenapprovalchecker) (اتریوم)
-- [Cointool](https://cointool.app/approve/eth) (شبکه های گوناگون)
-- [Revoke](https://revoke.cash/) (شبکه های گوناگون)
-- [Unrekt](https://app.unrekt.net/) (شبکه های گوناگون)
-- [EverRevoke](https://everrise.com/everrevoke/) (شبکه های گوناگون)
-
-## مرحلۀ 2: کیف پول خود را متصل کنید
-
-پس از ورود به وبسایت، روی «Connect wallet» کلیک کنید. وبسایت باید از شما بخواهد که کیف پول خود را متصل کنید.
-
-اطمینان حاصل کنید که از یک شبکه یکسان در کیف پول و وبسایت خود استفاده میکنید. تنها قراردادهای هوشمند مربوط به شکبه انتخاب شده را خواهید دید. به عنوان نمونه، اگر به شبکۀ اصلی اتریوم متصل شوید، فقط قراردادهای اتریوم را خواهید دید، نه قراردادهای زنجیرههای دیگر مانند پالیگان (Polygon).
-
-## مرحلۀ 3: قرارداد هوشمندی را که میخواهید لغو کنید انتخاب کنید
-
-باید تمام قراردادهایی را که اجازۀ دسترسی به توکنهای شما را دارند، و حد مجاز خرج کردن آنها را بینید. موردی را که قصد دارید لغو کنید پیدا کنید.
-
-اگر نمیدانید کدام قرارداد را باید انتخاب کنید، میتوانید همۀ قراردادها را لغو کنید. هیچ مشکلی برای شما ایجاد نخواهد کرد، فقط دفعۀ بعد که خواستید از هر یک از این قراردادها استفاده کنید، ناگزیرید دوباره مجموعۀ جدیدی از مجوزها را اعطا کنید.
-
-## مرحله 4: دسترسی به پولهای خود را لغو کنید
-
-پس از کلیک روی دکمۀ لغو، انتظار میرود که یک پیشنهاد تراکنش جدید را در کیف پول خود مشاهده کنید. این مسئله قابل انتظار است. برای لغو موفقیتآمیز میبایست هزینهای بپردازید. بسته به شبکه، ممکن است پردازش آن از یک تا چند دقیقه طول بکشد.
-
-توصیه میکنیم پس از چند دقیقه، ابزار لغو را بازآوری کنید و کیف پول خود را دوباره متصل کنید تا مجدداً بررسی شود که آیا قرارداد لغوشده از فهرست حذف شده است یا خیر.
-
-توصیه میکنیم هرگز به هیچ پروژهای اجازۀ دسترسی نامحدود به توکنهای خود را ندهید و همۀ دسترسیهای مجاز توکن را بهطور منظم لغو کنید. لغو دسترسی توکن هرگز نباید منجر به از دست دادن پولها شود، بهخصوص اگر از ابزارهای مذکور در بالا استفاده میکنید.
-
-
-
-
- میخواهید بیشتر بدانید؟
-
- راهنماهای دیگر ما را ببینید
-
-
-
-## پرسشهای متداول
-
-### آیا لغو دسترسی به توکن، سهامگذاری، ادغام، وام دادن و غیره را نیز متوقف میکند؟
-
-نه، هیچ یک از استراتژیهای [دیفای](/glossary/#defi) شما را تحت تأثیر قرار نخواهد داد. شما در موقعیتهای قبلی خود باقی خواهید ماند و به دریافت پاداش و غیره ادامه میدهید.
-
-### آیا قطع اتصال کیف پول از یک پروژه، با حذف مجوز استفاده از وجوه من همراه است؟
-
-خیر، اگر اتصال کیف پول خود را از پروژه قطع کنید، اما مجوزهای دسترسی به توکن را اعطا کرده باشید، آنها همچنان میتوانند از آن توکنها استفاده کنند. باید آن دسترسی را لغو کنید.
-
-### مجوز قرارداد چه زمانی منقضی میشود؟
-
-مجوزهای قرارداد هیچ تاریخ انقضای مشخصی ندارند. اگر مجوزهای قرارداد را اعطا کنید، حتی سالها بعد از اعطا هم قابل استفادهاند.
-
-### چرا پروژهها مجوز دسترسی نامحدود به توکن تعیین میکنند؟
-
-پروژهها اغلب این کار را برای به حداقل رساندن تعداد درخواستهای مورد نیاز انجام میدهند، به این معنی که عمل تایید و پرداخت هزینۀ تراکنش تنها یک بار از سوی کاربر انجام میشود. اگرچه دسترسی نامحدود کارها را راحت میکند، اما بیاحتیاطی در عمل «تایید» در سایتهایی که با گذشت زمان ثابت نشده یا ممیزی نشدهاند، میتواند برای کاربران خطرناک باشد. برخی از کیف پولها برای کم کردن ریسک، به شما این امکان را میدهند که مقدار توکنهای تاییدشده را به صورت دستی محدود کنید. برای کسب اطلاعات بیشتر با خدماتدهندۀ کیف پول خود تماس بگیرید.
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md
deleted file mode 100644
index a3b591d9f05..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: چطور می توان توکن ها را مبادله کرد
-description: راهنمای تبادل توکن در اتریوم.
-lang: fa
----
-
-# چطور می توان توکن ها را مبادله کرد
-
-آیا از جستجوی یک صرافی که تمام توکنهای محبوب شما را در لیست خود دارد، خسته شدهاید؟ شما میتوانید بیشتر توکنها را با استفاده از [صرافیهای غیرمتمرکز](/glossary/#dex) مبادله کنید.
-
-مبادله توکن شامل مبادله دو دارایی متفاوت است که در شبکه اتریوم وجود دارد، به عنوان مثال مبادله ETH با DAI (که یک توکن [ERC-20](/glossary/#erc-20)است). این فرآیند ارزان و سریع است. لازم است یک کیف پول رمزارز داشته باشید تا تبادل توکن را انجام دهید.
-
-**پیششرط:**
-
-- اگر یک [کیفپول رمزارزی](/glossary/#wallet) داشته باشید، میتوانید این آموزش را دنبال کنید: [نحوه: "ثبتنام" یک حساب اتریوم](/guides/how-to-create-an-ethereum-account/)
-- وجوهی به کیف پول خود واریز کنید
-
-## 1. کیف پول خود را به صرافی غیرمتمرکز دلخواه خود متصل کنید
-
-برخی از صرافیهای محبوب:
-
-- [Uniswap](https://app.uniswap.org/#/swap)
-- [Sushiswap](https://www.sushi.com/swap)
-- [1Inch](https://app.1inch.io/#/1/unified/swap/ETH/DAI)
-- [Curve](https://curve.fi/#/ethereum/swap)
-
-جالب است؟ درباره [امور مالی غیرمتمرکز (دیفای)](/defi/) و نحوه عملکرد این نوع مبادلات جدید بیشتر بدانید.
-
-## 2. جفت توکن مورد نظر خود برای تبادل را انتخاب کنید
-
-برای مثال، اتر و DAI را انتخاب کنید. مطمئن شوید که از یکی از این دو رمزارز در کیف پول خود موجودی کافی داشته باشید. ![رابط مشترک برای تعویض](./swap1.png)
-
-## 3. مقدار توکنهایی را که قصد مبادله آنها را دارید، مشخص کنید
-
-صرافی به صورت خودکار محاسبه خواهد کرد که چه تعداد توکن خواهید گرفت.
-
-![رابط مشترک برای تعویض](./swap2.png)
-
-## 4. تراکنش را تایید کنید
-
-جزئیات تراکنش را بازبینی کنید. نرخ تعویض و هر گونه کارمزد دیگر را کنترل کنید تا از هر پیشامد نامطلوب پیشگیری کنید.
-
-![رابط مشترک برای بررسی تراکنش](./swap3.png)
-
-## 5. صبر کنید تا فرایند تراکنش انجام شود
-
-میتوانید پیشرفت فرایند تراکنش را در هر مرورگر بلاک چین مشاهده کنید. این فرایند معمولا نباید بیش از 10 دقیقه طول بکشد.
-
-به محض تکمیل پردازش تراکنش، به صورت خودکار توکنهای تعویض شده را در کیف پول خود دریافت خواهید کرد.
-
-
-
- میخواهید بیشتر بدانید؟
-
- راهنماهای دیگر ما را ببینید
-
-
-
-## پرسشهای متداول
-
-### آیا میتوانم از کیف پول خود اتر را با بیت کوین تعویض کنم؟
-
-خیر، تنها میتوانید توکنهای بومی شبکۀ اتریوم مثل اتر، توکنهای استاندارد ERC-20 یا توکنهای NFT اتریوم را تعویض کنید. تنها میتوانید به تعویض انواع «رپد» بیتکوین که در شبکۀ اتریوم هستند، اقدام کنید.
-
-### افت چیست؟
-
-به تفاوت میان نرخ تعویض مورد انتظار شما و نرخ حقیقی اشاره دارد.
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md
deleted file mode 100644
index b2099fee281..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-title: چگونه توکن ها را به لایه دوم ارتباط دهیم
-description: راهنمای نحوه انتقال توکنها از اتریوم به لایه 2 با استفاده از یک پل.
-lang: fa
----
-
-# چگونه توکن ها را به لایه دوم ارتباط دهیم
-
-هرگاه ترافیک شبکۀ اتریوم زیاد شود، ممکن است گرانتر شود. یکی از راهحلها در مواجهه با این مشکل ایجاد «لایههای» جدید است: یعنی شبکههای مختلفی که به روشهای مشابه با خود شبکۀ اتریوم کار میکنند. شبکههای معروف به لایه 2، با پردازش تعداد زیادی از تراکنشها با کارمزد پایین به کاهش تراکم و هزینه در شبکۀ اتریوم کمک میکنند و تنها هر چند وقت یک بار نتایج پردازشها را بر روی اتریوم ذخیره میکنند. به این ترتیب، لایههای 2 ما را قادر میسازند تا با سرعت بیشتر و هزینۀ کمتر تراکنشهای خود را انجام دهیم. بسیاری از پروژههای رمزارزیِ محبوب، در حال انتقال به لایههای 2 به دلیل مزایای زیاد آنها هستند. آسانترین راه برای انتقال توکنها از شبکۀ اتریوم به لایۀ 2 استفاده از پل است.
-
-**پیششرط:**
-
-- برای نصب یک کیف پول رمزارز میتوانید از این راهنمای آموزشی استفاده کنید:[چگونه یک حساب اتریوم «ثبت کنیم»](/guides/how-to-create-an-ethereum-account/)
-- وجوهی به کیف پول خود واریز کنید
-
-## 1. تصمیم بگیرید که از کدام شبکۀ لایه 2 میخواهید استفاده کنید
-
-میتوانید در مورد پروژههای مختلف و لینکهای مهم در [صفحۀ لایه 2](/layer-2/) ما اطلاعات بیشتری کسب کنید.
-
-## 2. به پل انتخاب شده بروید
-
-تعدادی از محبوبترین لایههای 2:
-
-- [پل Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
-- [پل Optimism](https://app.optimism.io/bridge/deposit)
-- [پل شبکه Boba](https://gateway.boba.network/)
-
-## 3. با کیفپول خود به پل متصل شوید
-
-مطمئن شوید که کیفپولتان به شبکۀ اصلی اتریوم متصل است. اگر متصل نباشد، وبسایت به صورت خودکار از شما میخواهد که شبکۀ خود را تغییر دهید.
-
-![رابط مشترک برای پل زدن توکنها](./bridge1.png)
-
-## 4. مبلغ مدنظرتان را مشخص کرده و آن را انتقال دهید
-
-برای جلوگیری از اتفاقات ناخوشایند، آنچه را که در ازای این انتقال در شبکه لایه 2 دریافت خواهید کرد و نیز کارمزدها را بررسی کنید.
-
-![رابط مشترک برای پل زدن توکنها](./bridge2.png)
-
-## 5. تراکنش را در کیفپولتان تایید کنید
-
-باید با ETH هزینه انجام تراکنش را پرداخت کنید.
-
-![رابط مشترک برای پل زدن توکنها](./bridge3.png)
-
-## 6. صبر کنید تا پولتان انتقال یابد
-
-این فرآیند نباید بیشتر از 10 دقیقه طول بکشد.
-
-## 7. شبکه لایه 2 انتخابیتان را به کیفپولتان اضافه کنید (اختیاری)
-
-میتوانید از [chainlist.org](http://chainlist.org) برای پیداکردن جزئیات RPC شبکه استفاده کنید. به محض اینکه شبکه اضافه شود و تراکنش پایان یابد، باید توکنها را در کیفپولتان مشاهده کنید.
-
-
-
- میخواهید بیشتر بدانید؟
-
- راهنماهای دیگر ما را ببینید
-
-
-
-## پرسشهای متداول
-
-### اگر پولهایم در یک صرافی باشد چطور؟
-
-ممکن است بتوانید سرمایۀ خود را مستقیماً از یک صرافی برداشت و به چند شبکۀ لایه 2 انتقال دهید. برای اطلاعات بیشتر، بخش «انتقال به لایه 2» را در [صفحه لایه 2](/layer-2/) ما بررسی کنید.
-
-### بعد از بریج و انتقال توکنهایم به لایه 2 میتوانم دوباره به شبکۀ اصلی اتریوم برگردم؟
-
-بله، شما همیشه میتوانید داراییتان را با استفاده از همان پل مجدداً به شبکۀ اصلی برگردانید.
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md
deleted file mode 100644
index 2abb5e8304b..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: چطور می توان از یک کیف پول استفاده کرد
-description: راهنمای ارسال و دریافت توکن ها و اتصال به پروژه های web3.
-lang: fa
----
-
-# چطور می توان از یک کیف پول استفاده کرد
-
-یاد بگیرید چگونه تمام عملکردهای اساسی یک کیف پول را اجرا کنید. اگر هنوز کیفپول ندارید، مبحث [نحوه ایجاد یک حساب اتریوم](/guides/how-to-create-an-ethereum-account/) را بررسی کنید.
-
-## کیف پول خود را باز کنید
-
-باید پنل کاربری را ببینید که احتمالا موجودی شما را نشان می دهد و شامل دکمه هایی برای ارسال و دریافت توکن ها است.
-
-## دریافت رمز ارز
-
-آیا می خواهید کریپتو در کیف پول خود دریافت کنید؟
-
-هر حساب اتریوم آدرس دریافتکننده خود را دارد که یک توالی منحصر به فرد از اعداد و حروف است. آدرس مانند شماره حساب بانکی عمل می کند. آدرس های اتریوم همواره با "0x" شروع می شوند. می توانید این آدرس را با هر کس به اشتراک بگذارید: انجام این کار بی خطر است.
-
-آدرس شما مانند آدرس منرل شماست: باید آن را به افراد بگویید تا آنها بتوانند شما را پیدا کنند. انجام این کار بی خطر است، چون شما همچنان می توانید در ورودی خود را با کلید دیگری که فقط شما دارید قفل کنید تا هیچ کس نتواند وارد شود، حتی اگر بدانند کجا زندگی می کنید.
-
-باید آدرس عمومی خود را به هر کسی که می خواهد برای شما پول ارسال کند بدهید. بسیاری از اپلیکیشنهای کیف پول به شما اجازه کپی کردن آدرستان را می دهند یا یک کد QR برای استفاده آسانتر نشان می دهند. از تایپ دستی هرگونه آدرس اتریوم خودداری کنید. این کار به راحتی می تواند به اشتباهات اداری و از دادن پول منجر شود.
-
-اپلیکیشنهای مختلف ممکن است متفاوت باشند یا از زبان های مختلف استفاده کنند، اما اگر بخواهید پولی منتقل کنید، آنها باید شما را از یک فرآیند مشابه عبور دهند.
-
-1. اپلیکیشن کیف پول خود را باز کنید.
-2. روی "دریافت" (یا گزینه معادل آن) کلیک کنید.
-3. آدرس اتریوم خود را در کلیپ بورد کپی کنید.
-4. آدرس اتریوم دریافت کننده خود را به فرستنده بدهید.
-
-## فرستادن کریپتو
-
-آیا می خواهید ETH را به کیف پول دیگری ارسال کنید؟
-
-1. اپلیکیشن کیف پول خود را باز کنید.
-2. آدرس دریافت کننده را بگیرید و مطمئن شوید که به شبکه گیرنده یکسان متصل هستید.
-3. آدرس دریافت را وارد کنید یا کد QR را با دوربین خود اسکن کنید، طوری که مجبور نیستید آدرس را به صورت دستی بنویسید.
-4. در کیف پول خود بر روی "ارسال" کلیک کنید (یا گزینه مشابه دیگر).
-
-![فیلد آدرس کریپتو را بفرستید](./send.png)
-
-
-5. بسیاری از دارایی ها، مانند Dai یا USDC، روی چندین شبکه وجود دارند. هنگام انتقال توکن های کریپتو، مطمئن شوید که گیرنده از همان شبکه شما استفاده می کند، زیرا آنها قابل معاوضه نیستند.
-6. مطمئن شوید که کیف پول شما ETH کافی برای پوشش دادن کارمزد تراکنش، که بسته به شرایط شبکه متفاوت است، دارد. اکثر کیف پول ها به صورت خودکار کارمزد پیشنهادی را به تراکنش اضافه می کنند که سپس می توانید آن را تایید کنید.
-7. هنگامی که تراکنش شما پردازش شد، مقدار کریپتو مربوطه در حساب گیرنده نشان داده می شود. بسته به مقدار استفاده شده از شبکه در آن لحظه، این عمل ممکن است از چند ثانیه تا چند دقیقه طول بکشد.
-
-## وصل شدن به پروژه ها
-
-آدرس شما در تمام پروژه های اتریوم یکسان خواهد بود. شما نیاز به ثبت نام جداگانه در هیچ پروژه ای ندارید. هنگامی که کیف پول دارید، بدون هیچ اطلاعات اضافی می توانید به هر پروژه اتریوم متصل شوید. هیچ ایمیل یا اطلاعات شخصی دیگری نیاز نیست.
-
-1. از وبسایت هر پروژه بازدید کنید.
-2. اگر صفحه آعازین وبسایت یک پروژه فقط یک توصیف ثابت از پروژه است، باید بتوانید در منو روی دکمه "بازکردن اپلیکیشن" کلیک کنید، که شما را به اپلیکیشن وب واقعی هدایت می کند.
-3. وارد برنامه که شدید روی "Connect" کلیک کنید.
-
-![دکمه ای که به کاربر اجازه می دهد با یک کیف پول به وبسایت متصل شود](./connect1.png)
-
-4. کیف پول خود را از بین لیست گزینه های ارائه شده انتخاب کنید. اگر نمی توانید کیف پول خود را ببینید، ممکن است در زیر گزینه "WalletConnect" پنهان شده باشد.
-
-![انتخاب از لیست کیف پول ها برای اتصال](./connect2.png)
-
-5. برای برقرار کردن اتصال، درخواست امضا را در کیف پول خود تایید کنید. **برای امضای این پیام، نباید به پرداخت هیچ ETH نیاز باشد**.
-6. همین! استفاده از اپلیکیشن را شروع کنید. در [صفحه برنامه های غیرمتمرکز](/dapps/#explore) می توانید پروژه های جالبی را پیدا کنید.
-
-
- میخواهید بیشتر بدانید؟
-
- راهنماهای دیگر ما را ببینید
-
-
-
-## پرسشهای متداول
-
-### اگر من صاحب یک آدرس اتریوم باشم، صاحب همان آدرس روی سایر بلاکچینها نیز هستم؟
-
-می توانید از یک آدرس یکسان در تمام بلاکچینهای سازگار با EVM استفاده کنید (اگر کیف پول با عبارت بازیابی دارید). این [لیست](https://chainlist.org/) بلاکچینهایی را که در آن میتوانید از آدرس یکسان استفاده کنید نمایش میدهد. بعضی بلاکچینها، مثل بیتکوین، قوانین شبکه کاملا متفاوتی اجرا میکنند و برای استفاده از آن شبکه به آدرس متفاوت با فرمت متفاوت احتیاج است. اگر از یک کیف پول مبتنی بر قرارداد هوشند استفاده میکنید، باید وبسایت ارائه دهنده خدمات را برای کسب اطلاعات درباره بلاکچینهای مورد پشتیبانی بررسی کنید.
-
-### آیا می توانم از یک آدرس یکسان در چند دستگاه استفاده کنم؟
-
-بله، می توانید از یک آدرس یکسان در چند دستگاه استفاده کنید. کیف پول ها از نظر فنی فقط یک رابط برای نشان دادن موجودیتان به شما و انجام تراکنش ها هستند، و حساب شما در بلاکچین ذخیره می شود نه در کیف پول.
-
-### رمزارز را دریافت نکردم، از کجا می توانم وضعیت تراکنش را بررسی کنم؟
-
-برای دیدن وضعیت هر تراکنش در زمان واقعی، می توانید از [جستجوگرهای بلاک](/developers/docs/data-and-analytics/block-explorers/) استفاده کنید. تنها کاری که باید انجام دهید این است که آدرس کیف پول خود یا ID تراکنش را جستجو کنید.
-
-### آیا می توانم تراکنش ها را لغو کنم یا باز گردانم؟
-
-خیر، پس ار تایید تراکنش، نمی توانید تراکنش را لغو کنید.
diff --git a/public/content/translations/fa/10) Guides and Quizzes/guides/index.md b/public/content/translations/fa/10) Guides and Quizzes/guides/index.md
deleted file mode 100644
index 01da530b086..00000000000
--- a/public/content/translations/fa/10) Guides and Quizzes/guides/index.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: راهنماهای اتریوم
-description: مجموعه راهنمایی های کاربردی که مبانی اتریوم را به مبتدی ها آموزش میدهند.
-lang: fa
----
-
-# راهنماهای اتریوم
-
-در آستانه ورود به دنیای اتریوم هستید؟ راهنماهای عملی و گام به گام ما، آغاز و حرکت در مسیر دنیای این فناوری جدید را برای شما هموار میکنند.
-
-## شروع به کار
-
-1. [روش «ایجاد» حساب اتریوم](/guides/how-to-create-an-ethereum-account/) - همه افراد میتوانند بهصورت رایگان یک کیفپول ایجاد کنند. این راهنما نقطه آغاز مسیر را به شما نشان میدهد.
-
-2. [نحوه استفاده از کیف پول](/guides/how-to-use-a-wallet/) - مقدمهای درباره آشنایی با مشخصات ابتدایی هر کیف پول و نحوه استفاده از آنها.
-
-## اصول اولیه امنیتی
-
-1. [چطور میتوانید دسترسی قراردادهای هوشمند به رمزارزهای خودتان را لغو کنید؟](/guides/how-to-revoke-token-access/)-این راهنما به شما کمک میکند تراکنشهایی را که خودتان آن را آغاز نکردهاید، لغو کنید، و جلوی تکرار آن را بگیرید.
-
-2. [نحوه شناسایی توکنهای کلاهبرداری](/guides/how-to-id-scam-tokens/)- توکنهای کلاهبرداری چه توکنهایی هستند، چطور خود را قانونی جلوه میدهند، با چه نشانههایی میتوان آنها را شناخت و از کلاهبرداریها جلوگیری کرد.
-
-## استفاده از اتریوم
-
-1. [چطور میتوان توکنها را به لایه 2 پل زد](/guides/how-to-use-a-bridge/)-به نظرتان تراکنشها در شبکه اتریوم بیش از حد گراناند؟ از راهحلهای مقیاسپذیر کردن اتریوم که به آن شبکههای لایه 2 میگویند استفاده کنید.
-
-2. [چطور توکنها را تعویض کنیم](/guides/how-to-swap-tokens/)-آیا تصمیم دارید توکنهای فعلیتان را به توکنهای دیگری تبدیل کنید؟ این راهنمای ساده نشان خواهد داد که چگونه این کار را انجام دهید.
diff --git a/public/content/translations/fa/11) Roadmap/eips/index.md b/public/content/translations/fa/11) Roadmap/eips/index.md
deleted file mode 100644
index 837e2604bfb..00000000000
--- a/public/content/translations/fa/11) Roadmap/eips/index.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: پیشنهادهای بهبود اتریوم (EIP)
-description: اطلاعات اولیه که برای درک EIPها نیاز دارید
-lang: fa
----
-
-# معرفی پیشنهادهای بهبود اتریوم (EIP) {#introduction-to-ethereum-improvement-proposals}
-
-## پیشنهادهای بهبود اتریوم (EIPها) چیست؟ {#what-are-eips}
-
-[پیشنهادهای بهبود اتریوم (EIPها)](https://eips.ethereum.org/) استاندارهایی هستند که ویژگیهای جدید بالقوه برای فرایندهای اتریوم را شناسایی و مشخص میکنند. EIPها حاوی مشخصات فنی برای تغیرات پیشنهادی بوده و بهعنوان «منبع حقیقت» برای جامعه اتریوم عمل میکنند. بهروزرسانیهای شبکه و استانداردهای اپلیکیشن برای اتریوم از طریق فرایند EIP مورد بحث قرار گرفته و توسعه داده میشوند.
-
-هرکسی در جامعه اتریوم میتواند یک EIP بسازد. دستورالعملهای نگارش EIPها در [EIP-1](https://eips.ethereum.org/EIPS/eip-1) گنجانده شده است. یک EIP در درجه اول باید یک مشخصات فنی مختصر با مقدار کمی انگیزه ارائه دهد. نویسنده EIP مسئول دستیابی به اجماع در جامعه و مستندسازی نظرات جایگزین است. از نظر تاریخی، با توجه به موانع فنی بالا برای ارسال یک EIP خوشفرم، اکثر نویسندگان EIP معمولاً توسعهدهندگان برنامه یا پروتکل هستند.
-
-## چرا EIPها مهم هستند؟ {#why-do-eips-matter}
-
-EIPها نقش مهمی در نحوه ایجاد تغییرات دارند و در اتریوم بهصورت مستند ثبت میشوند. EIPها روشی برای پیشنهاد، بحث و ایجاد تغییر توسط مردم هستند. البته [انواع مختلفی از EIP](https://eips.ethereum.org/EIPS/eip-1#eip-types) وجود دارد، شامل EIPهای هستهای برای تغییرات سطح پایین پروتکل که بر روی اجماع تأثیر میگذارند و نیازمند یک ارتقا در شبکه، مثل [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)، و ERCهایی برای استانداردهای برنامه، مانند [EIP-20](https://eips.ethereum.org/EIPS/eip-20) و [EIP-721](https://eips.ethereum.org/EIPS/eip-721)، هستند.
-
-هر ارتقا در شبکه شامل مجموعهای از EIPها است که باید توسط هر [کلاینت اتریوم](/learn/#clients-and-nodes)در شبکه پیادهسازی شوند. این یعنی توسعهدهندگان کلاینت برای اینکه اجماعشان را با کلاینتهای دیگر در شبکه اصلی اتریوم حفظ کنند، باید مطمئن شوند که همه EIPهای لازم را پیادهسازی کرده باشند.
-
-EIPها در کنار ارائه مشخصات فنی برای تغییرات، واحدی هستند که حاکمیت در اتریوم پیرامون آنها رخ میدهد: هرکس آزاد است یک EIP پیشنهاد دهد و سپس ذینفعان مختلف در اجتماع بر سر اجرای آن بهعنوان یک استاندارد یا گنجاندن آن در ارتقای شبکه بحث میکنند. از آنجایی که EIPهای غیرهستهای (non-core EIPs) نیازی به اجرا شدن توسط همه برنامههای کاربردی ندارند (مثلاً میتوان یک توکن قابل معاوضه ساخت که EIP-20 را اجرا نمیکند)، اما EIPهای هستهای باید مورد استفاده گسترده قرار بگیرند (چون همه گرهها باید برای باقی ماندن بهعنوان بخشی از همان شبکه بهروز بمانند)، EIPهای هستهای در مقایسه با نوع غیرهستهای مستلزم اجماع گستردهتر در جامعه اتریوم هستند.
-
-## تاریخچه EIPها {#history-of-eips}
-
-انبار گیتهاب [پیشنهادهای بهبود اتریوم (EIP)](https://github.com/ethereum/EIPs)در اکتبر 2015 ساخته شد. فرایند EIP بر فرایند [پیشنهادهای بهبود بیت کوین(EIBها)](https://github.com/bitcoin/bips) مبتنی است که خود بر [پیشنهادهای بهبود پایتون (PEPها)](https://www.python.org/dev/peps/) مبتنی است.
-
-ویراستارهای EIP وظیفه انجام فرایند بازبینی EIPها را برای تأیید صحت فنی، قالببندی، دستور زبان و املای صحیح و سبک کدنویسی برعهده دارند. مارتین بز، ویتالیک بوترین، گوین وود و چند نفر دیگر ویراستاران اصلی EIP از سال 2015 تا 2016 بودند.
-
-ویراستاران فعلی EIP
-
-- Alex Beregszaszi (@axic)
-- Gavin John (@Pandapip1)
-- Greg Colvin (@gcolvin)
-- Matt Garnett (@lightclient)
-- Sam Wilson (@SamWilsn)
-
-ویراستاران بازنشسته EIP
-
-- Casey Detrio (@cdetrio)
-- Hudson Jameson (@Souptacular)
-- Martin Becze (@wanderer)
-- Micah Zoltu (@MicahZoltu)
-- Nick Johnson (@arachnid)
-- Nick Savers (@nicksavers)
-- Vitalik Buterin (@vbuterin)
-
-اگر علاقهمند به فعالیت به عنوان ویراستار EIP هستید، لطفاً [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069) را چک کنید.
-
-ویراستاران EIP هستند که تصمیم میگیرند چه زمانی یک پیشنهاد آماده است تبدیل به یک EIP شود، و همچنین به نویسندگان EIPها کمک میکند پیشنهادهایشان را به مراحل بعدی پیش ببرند. [Ethereum Cat Herders](https://www.ethereumcatherders.com/) به برنامهریزی جلسات بین ویراستاران و جامعه اتریوم کمک میکنند (نگاهی به [EIPIP](https://github.com/ethereum-cat-herders/EIPIP) بیاندازید).
-
-فرایند کامل استانداردسازی در کنار نمودار آن در [EIP-1](https://eips.ethereum.org/EIPS/eip-1) شرح داده شده است.
-
-## بیشتر بدانید {#learn-more}
-
-اگر علاقهمند به مطالعه بیشتر راجع به EIPها هستید، به [وبسایت EIPها](https://eips.ethereum.org/)و[EIP-1](https://eips.ethereum.org/EIPS/eip-1) سر بزنید. تعدادی مرجع مفید برای مطالعه بیشتر:
-
-- [فهرستی از هر پیشنهاد بهبود اتریوم](https://eips.ethereum.org/all)
-- [توضیح تمام انواع EIPها](https://eips.ethereum.org/EIPS/eip-1#eip-types)
-- [توضیح وضعیت تمام EIPها](https://eips.ethereum.org/EIPS/eip-1#eip-process)
-
-### پروژه های آموزش جامعه {#community-projects}
-
-- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — پروژه *PEEPanEIP یک مجموعه ویدیویی آموزشی است که در مورد پیشنهاد بهبود اتریوم (EIP) و ویژگیهای کلیدی ارتقاهای آینده بحث میکند.*
-- [EIPs For Nerds](https://ethereum2077.substack.com/t/eip-research) — پروژه *EIPs For Nerds مروری جامع و به سبک ELI5 از پیشنهادهای مختلف بهبود اتریوم (EIPها)، از جمله EIP های اصلی و EIP های لایه کاربردی/زیرساختی (ERC) برای آموزش خوانندگان و ایجاد اجماع در مورد تغییرات پیشنهادی در پروتکل اتریوم، ارائه میکند.*
-- [EIPs.wtf](https://www.eips.wtf/) — پروژه *EIPs.wtf اطلاعات اضافی برای پیشنهادهای بهبود اتریوم (EIPها)، از جمله وضعیت، جزئیات پیادهسازی، درخواستهای ادغام مرتبط، و بازخورد جامعه ارائه میدهد.*
-- [EIP.Fun](https://eipfun.substack.com/) — پروژه *EIP.Fun آخرین اخبار در مورد پیشنهادهای بهبود اتریوم (EIP)، بهروزرسانیهای جلسات EIP و موارد دیگر را ارائه میدهد.*
-- [EIPs Insight](https://eipsinsight.com/) — پروژه *EIPs Insight نمایشی از وضعیت فرآیند پیشنهادهای بهبود اتریوم (EIPs) و & آمار بر اساس اطلاعات جمع آوری شده از منابع مختلف است.*
-
-## مشارکت کنید {#participate}
-
-هر کسی میتواند یک EIP تهیه کند. پیش از ثبت یک پیشنهاد، باید[EIP-1](https://eips.ethereum.org/EIPS/eip-1) را مطالعه کنید که روند و نحوه نوشتن یک EIP را تشریح میکند، و درخواست بازخورد در [Ethereum Magicians](https://ethereum-magicians.org/) کنید، جایی که پیش از ارسل پیشنویس، پیشنهادها ابتدا با جامعه در میان گذاشته میشوند.
-
-## منابع {#references}
-
-
-
-بخشی از محتوای صفحه از [حاکمیت توسعهی پروتکل اتریوم و هماهنگی ارتقای شبکه](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) نوشتهی هادسون جیمسون تهیه شدهاست
-
-
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/beacon-chain/index.md b/public/content/translations/fa/11) Roadmap/roadmap/beacon-chain/index.md
deleted file mode 100644
index e57d23f3644..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/beacon-chain/index.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: زنجیره بیکن
-description: در مورد زنجیرهی بیکن یاد بگیرید - ارتقایی که اثبات سهام را برای اتریوم به ارمغان آورد.
-lang: fa
-template: upgrade
-image: /images/upgrades/core.png
-alt:
-summaryPoint1: زنجیره بیکن اثبات سهام را برای اولین بار به اکوسیستم اتریوم وارد کرد.
-summaryPoint2: این زنجیره در ماه سپتامبر 2022 با زنجیرۀ اصلی اثبات کار اتریوم ادغام شد.
-summaryPoint3: زنجیره بیکن منطق اجماع و پروتکل شایعه (گاسیپ) را برای اولین بار ارائه کرد که اکنون امنیت اتریوم را تأمین میکند.
----
-
-
- زنجیره بیکن در تاریخ 1 دسامبر 2020 عرضه شد و با ارتقای The Merge در تاریخ 15 سپتامبر 2022، اثبات سهام را به عنوان مکانیزم اجماع اتریوم رسمیت داد.
-
-
-## زنجیره بیکن چیست؟ {#what-is-the-beacon-chain}
-
-زنجیره بیکن نام زنجیره بلوکی اصلی اثبات سهام است که در سال 2020 شروع به کار کرد. هدف از ایجاد آن اطمینان از صحت منطق اجماع اثبات سهام پیش از فعال سازی بر روی «شبکه اصلی اتریوم» بود. بنابراین، به صورت موازی با نسخه اصلی اثبات سهام اتریوم اجرا گردید. زنجیره بیکن زنجیرهای از بلوکهای خالی بود، اما غیرفعال کردن اثبات کار و سوییچ کردن روی اثبات سهام در اتریوم، نیازمند دستور دادن به زنجیره بیکن برای پذیرش دادههای تراکنش از کلاینتهای اجرا، دستهبندی آنها در بلوکها و سپس سازماندهی آنها در یک زنجیره بلوکی با استفاده از مکانیزم اجماعِ مبتنی بر اثبات سهام بود. به طور همزمان، کلاینتهای اصلی اتریوم، از فعالیت استخراج، انتشار بلوک و منطق اجماع خود دست کشیدند و همۀ آن فعالیتها را به زنجیره بیکن سپردند. این رویداد به [The Merge](/roadmap/merge/) معروف بود. زمانی که The Merge اتفاق افتاد، دیگر دو زنجیره بلوکی وجود نداشت. بلکه، تنها یک اثبات سهام اتریوم وجود داشت که حالا به دو کلاینت مختلف در هر گره نیاز دارد. زنجیره بیکن درحال حاضر لایۀ اجماع اتریوم است، یک شبکۀ همتا به همتا از کلاینتهای اجماع که گاسیپهای بلوک و منطق اجماع را مدیریت میکند، درحالی که کلاینتهای اصلی لایۀ اجرا را تشکیل میدهند که وظیفۀ گاسیپ کردن و اجرای تراکنشها و مدیریت وضعیت اتریوم را بر عهده دارد. این دو لایه میتوانند با استفاده از Engine API با یکدیگر ارتباط برقرار کنند.
-
-## زنجیره بیکن چه کاری انجام میدهد؟ {#what-does-the-beacon-chain-do}
-
-زنجیره بیکن به یک دفترکل حاوی مجموعهای از حسابها گفته میشود که قبل از اینکه سهامگذاران شروع به اعتبارسنجی بلوکهای واقعی اتریوم کنند، شبکۀ [سهامگذاران](/staking/) اتریوم را هدایت و هماهنگ میکرد. این زنجیره نه پردازش تراکنشها را انجام میدهد و نه تعاملات قرارداد هوشمند را مدیریت میکند زیرا این کارها در لایۀ اجرا انجام میشوند. زنجیره بیکن مسئولیت مواردی مانند مدیریت بلوک و تصدیق، اجرای الگوریتم انتخاب فورک و مدیریت پاداشها و جریمهها را بر عهده دارد. در صفحۀ [معماری گره](/developers/docs/nodes-and-clients/node-architecture/#node-comparison) ما، در این باره بیشتر بخوانید.
-
-## تأثیر زنجیره چین {#beacon-chain-features}
-
-### معرفی استیکینگ {#introducing-staking}
-
-زنجیره بیکن [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) را برای اولین بار به اتریوم وارد کرد. این زنجیره شبکۀ اتریوم را امن نگه میدارد و در این فرایند، اعتبار اتریوم بیشتری را به اعتبارسنجها میرساند. در عمل، سهامگذاری شامل سهامگذاری روی اتریوم به منظور فعال کردن نرمافزار اعتبارسنج است. شما به عنوان یک سهامگذار، نرمافزاری را اجرا میکنید که بلوکهای جدیدی را در زنجیره ایجاد و تأیید میکند.
-
-سهامگذاری، هدفی مشابه با [استخراج (ماینینگ)](/developers/docs/consensus-mechanisms/pow/mining/) دارد، اما از بسیاری جهات متفاوت است. استخراج نیاز به سرمایۀ اولیۀ زیادی در قالب سختافزار قدرتمند و مصرف انرژی داشت که منجر به صرفه به مقیاس (مزیت مقیاس) و افزایش متمرکزسازی میشد. ضمناً، استخراج هیچ الزامی برای قفل کردن داراییها به عنوان وثیقه نداشت و همین، توانایی پروتکل را برای مجازات نقشآفرینان بدکار پس از حمله محدود میکرد.
-
-جایگزینی اثبات سهام به جای اثبات کار، اتریوم را به طور قابل توجهی امنتر و غیرمتمرکزتر کرد. هرچه افراد بیشتری در شبکه شرکت کنند، غیرمتمرکزتر و در برابر حملات امنتر میشود.
-
-و استفاده از اثبات سهام به عنوان مکانیزم اجماع، یک مؤلفۀ اساسی برای [ اتریوم امن، سازگار با محیط زیست و مقیاسپذیر است که اکنون داریم](/roadmap/vision/).
-
-
- اگر علاقهمندید به یک اعتبارسنج تبدیل شوید و به ایمنسازی اتریوم کمک کنید، دربارۀ سهامگذاری بیشتر بدانید.
-
-
-### راهاندازی برای شاردینگ (زنجیرهایسازی) {#setting-up-for-sharding}
-
-از زمانی که زنجیره بیکن با نسخه اورجینال «شبکه اصلی اتریوم» ادغام شد، جامعۀ اتریوم شروع به برنامهریزی برای مقیاسبندی شبکه کرد.
-
-اثبات سهام یک مزیت دارد: داشتن یک رجیستری از همۀ تولیدکنندگان تأییدشده بلوک در هر زمان معین، که هر کدام با اتریوم در سهامگذاری است. این رجیستری زمینه را برای توانایی تقسیم و تسخیر مطمئن مسئولیتهای خاص شبکه فراهم میکند.
-
-این مسئولیتپذیری برخلاف اثبات کار است، جایی که استخراجگران هیچ تعهدی در قبال شبکه ندارند و میتوانند بدون هیچ عواقبی، در یک لحظه فرایند استخراج را متوقف و نرمافزار گره خود را به طور دائم خاموش کنند. همچنین هیچ رجیستری از پیشنهاددهندگان شناختهشدۀ بلوک و هیچ راه مطمئنی برای تقسیم مسئولیتهای شبکه به طور ایمن وجود ندارد.
-
-[اطلاعات بیشتر درباره شاردینگ](/roadmap/danksharding/)
-
-## رابطۀ بین ارتقاها {#relationship-between-upgrades}
-
-همۀ ارتقاهای اتریوم تا حدودی به هم مرتبط هستند. پس بیایید مرور کنیم که زنجیره بیکن چگونه بر سایر ارتقاها تأثیر میگذارد.
-
-### زنجیره بیکن و The Merge {#merge-and-beacon-chain}
-
-در ابتدا، زنجیره بیکن جدای از شبکه اصلی اتریوم بود، اما این دو در سال 2022 با هم ادغام شدند.
-
-
- The Merge (ادغام)
-
-
-### شاردها و زنجیره بیکن {#shards-and-beacon-chain}
-
-شاردینگ تنها با وجود مکانیزم اجماع اثبات سهام میتواند به طور ایمن وارد اکوسیستم اتریوم شود. زنجیره بیکن سهامگذاری را برای اولین بار معرفی کرد که با شبکه اصلی «ادغام» شد و راه را برای شاردینگ هموار کرد تا به مقیاسبندی بیشتر اتریوم کمک کند.
-
-
- زنجیرههای شارد (خردهزنجیرهها)
-
-
-## اطلاعات بیشتر
-
-- [اطلاعات بیشتر دربارۀ ارتقاهای آتی اتریوم](/roadmap/vision)
-- [اطلاعات بیشتر دربارۀ معماری گره](/developers/docs/nodes-and-clients/node-architecture)
-- [اطلاعات بیشتر دربارۀ اثبات سهام](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/future-proofing/index.md b/public/content/translations/fa/11) Roadmap/roadmap/future-proofing/index.md
deleted file mode 100644
index 05ac6598f41..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/future-proofing/index.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: آیندهنگری در اتریوم
-description: این ارتقاها اتریوم را به عنوان لایه پایه مقاوم و غیرمتمرکز برای هرآنچه در آینده پیش آید تقویت میکند.
-lang: fa
-image: /images/roadmap/roadmap-future.png
-alt: "نقشه راه اتریوم"
-template: roadmap
----
-
-برای مقیاسپذیری یا ایمنسازی اتریوم در کوتاهمدت، به برخی از بخشهای نقشۀ راه الزاماً نیازی نیست، ولی این بخشها میتوانند ثبات و قابلیت اطمینان را در اتریوم برای آینده تقویت کنند.
-
-## مقاومت کوانتومی {#quantum-resistance}
-
-زمانی که محاسبات کوانتومی به واقعیت تبدیل شود، برخی از [رمزنگاریهای](/glossary/#cryptography) کنونی که اتریوم را ایمن ساختهاند به خطر میافتند. اگرچه احتمالاً دهها سال طول بکشد تا کامپیوترهای کوانتومی تهدیدی واقعی برای رمزنگاری مدرن بهشمار آیند، اتریوم در طول این مدت به گونهای ساخته میشود که برای قرنهای آتی ایمن باشد. این بدین معنی است که [مقاومت کوانتومی اتریوم](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) به زودی محتمل خواهد بود.
-
-چالش پیش روی توسعه دهندگان اتریوم این است که پروتکل [اثبات سهام](/glossary/#pos) کنونی بر یک طرح امضای بسیار کارآمد به نام BLS برای گردآوری آرا در [بلوک](/glossary/#block) معتبر متکی است. این مدل امضا در برابر کامپیوترهای کوانتومی شکننده است، اما جایگزینهای مقاوم در برابر کوانتوم نیز آنچنان کارآمد نیستند.
-
-[مدلهای تعهدی KZG](/roadmap/danksharding/#what-is-kzg) که در چندین جا در سرتاسر شبکۀ اتریوم برای تولید رازهای رمزنگاریشده استفاده میشوند از جمله مدلهایی هستند که آسیبپذیریشان در برابر کوانتوم شناختهشده است. درحال حاضر، این مسئله با استفاده از «تنظیمات قابل اعتماد» دور زده میشود، یعنی جایی که در آن بسیاری از کاربران قابلیت انتخاب تصادفی را ایجاد میکنند و انجام مهندسی معکوس روی این قابلیت توسط کامپیوترهای کوانتومی امکانپذیر نیست. با این حال، راهحل ایدهآل این است که خیلی ساده به جای این روشها از رمزنگاری ایمن کوانتومی استفاده شود. دو رویکرد پیشرو در این زمینه وجود دارند که میتوانند جایگزینهای کارآمدی برای مدل BLS باشند: مدلهای امضا به نامهای [STARK-based](https://hackmd.io/@vbuterin/stark_aggregation) و [lattice-based](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **اینها هنوز در مرحله تحقیق و نمونه سازی هستند**.
-
- درباره KZG و تنظیمات مورد اعتماد بخوانید
-
-## شبکۀ اتریومِ سادهتر و کارآمدتر {#simpler-more-efficient-ethereum}
-
-پیچیدگیِ یک شبکه فرصتهای زیادی برای انواع باگها یا آسیبپذیریها ایجاد میکند که میتواند سبب سوءاستفاده مهاجمان شود. بنابراین، بخشی از نقشۀ راه را سادهسازیِ شبکۀ اتریوم و حذف کدهایی تشکیل میدهد که از طریق بهروزرسانیهای مختلف گریبانگیر شبکه شدهاند ولی دیگر نه مورد نیاز هستند و نه میتوان آنها را بهبود بخشید. نگهداری و استدلال یک پایگاه کد کوچکتر و سادهتر برای توسعهدهندگان آسانتر است.
-
-چندین بهروزرسانی در راه است تا روی [ماشین مجازی اتریوم (EVM)](/developers/docs/evm) اعمال شود و آن را سادهتر و کارآمدتر کند. یکی از این بهروزرسانیها [حذف کد عملیاتی SELFDESTRUCT](https://hackmd.io/@vbuterin/selfdestruct) است – دستوری که به ندرت مورد استفاده قرار میگیرد و دیگر مورد نیاز نیست و حتی در برخی از شرایط استفاده از آن میتواند خطرناک هم باشد، مخصوصاً زمانی که با سایر ارتقاهای مدلهای ذخیرهسازی اتریوم در آینده ترکیب شود. [کاربرهای اتریوم](/glossary/#consensus-client) همچنین از برخی از انواع تراکنشهای قدیمی پشتیبانی میکنند که اکنون میتوانند به طور کامل حذف شوند. نحوه محاسبه [گس](/glossary/#gas) نیز می تواند بهبود یابد و روش های کارآمدتری برای محاسبات زیربنای برخی عملیات رمزنگاری ارائه شود.
-
-به همین ترتیب، بهروزرسانیهایی وجود دارند که میتوانند برای بخشهای دیگری از کلاینتهای امروزی اتریوم اعمال شوند. یک مثال در رابطه با این موضوع این است که در حال حاضر کلاینتهای اجرا و اجماع از نوع متفاوتی از فشردهسازی دادهها استفاده میکنند. هنگامی که یکپارچهسازیِ طرح فشردهسازی در کل شبکه انجام بگیرد، اشتراکگذاریِ دادهها بین کلاینتها بسیار سادهتر و شهودیتر خواهد شد.
-
-## پیشرفت فعلی {#current-progress}
-
-بسیاری از ارتقاهای مورد نیاز برای اتریومِ مقاوم در آینده **هنوز در مرحله تحقیقاتی هستند و ممکن است چندین سال تا اجرای آن فاصله داشته باشد**. بهروزرسانیهایی مانند حذف SELFDESTRUCT و هماهنگ کردن طرح فشردهسازی مورد استفاده در کاربرهای لایههای اجرا و اجماع احتمالاً زودتر از رمزنگاری مقاوم در برابر کوانتوم انجام میشوند.
-
-**بیشتر بخوانید**
-
-- [گاز](/developers/docs/gas)
-- [ماشین مجازی اتریوم (EVM)](/developers/docs/evm)
-- [ساختارهای داده](/developers/docs/data-structures-and-encoding)
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/index.md b/public/content/translations/fa/11) Roadmap/roadmap/index.md
deleted file mode 100644
index 6b73bbeb746..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/index.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: نقشه راه اتریوم
-description: مسیری به سمت مقیاسپذیری، امنیت و پایداری بیشتر اتریوم.
-lang: fa
-template: roadmap
-image: /images/heroes/roadmap-hub-hero.jpg
-alt: "نقشه راه اتریوم"
-summaryPoints:
-buttons:
- -
- label: ارتقاهای پیش رو
- toId: چه تغییراتی ایجاد خواهد شد
- -
- label: ارتقاهای پیشین
- href: /history/
- variant: طرح کلی
----
-
-اتریوم همین الان هم یکی از قدرتمندترین پلتفورمهای تعاملات جهانی محسوب میشود، اما تکامل آن همچنان ادامه دارد. مجموعه بهبودهای بلندپروازانۀ شبکه اتریوم در نهایت این پلتفوم را از وضعیت فعلی به پلتفورمی با مقیاسپذیری کامل و انعطاف حداکثری ارتقا خواهد داد. تمام این ارتقاها در نقشه راه اتریوم آمده است.
-
-**برای آگاهی از ارتقاهای پیشین اتریوم، لطفاً صفحه ما درباره [تاریخچه](/history/) اتریوم را مطالعه کنید**
-
-## اتریوم در افق آتی خود چه تغییراتی خواهد داشت؟ {#what-changes-are-coming}
-
-در نقشه راه اتریوم، کلیتی از بهبودهای خاص مطرح شده است که در آینده، به پروتکل شبکه اتریوم اعمال خواهد شد. به طور کلی، مزیتهای اصلی نقشه راه اتریوم برای کاربران خود به شرح زیر است:
-
-
-
-
-
-
-
-
-## چرا اتریوم به نقشه راه نیاز دارد؟ {#why-does-ethereum-need-a-roadmap}
-
-اتریوم با دریافت ارتقاهای منظم، از بهبودی در مقیاسپذیری، امنیت یا پایداری شبکه بهرهمند میشود. یکی از نقاط قوت اتریوم، پذیرش و تطبیقپذیری با ایدههای جدیدی است که از جریان تحقیق و توسعه حاصل میشود. قابلیت تطبیقپذیری این امکان را به شبکه اتریوم داده است که در مواجهه با چالشهای نوظهور بسیار منعطف عمل کرده و مجموعه اتریوم را در بالاترین سطح فناوری حفظ کند.
-
-
-
-عمدۀ این نقشۀ راه حاصل سالها تلاش پژوهشگران و توسعهدهندگان است، زیرا این پروتکل بسیار تخصصی است. با این حال، هر فرد باانگیزهای میتواند در این مسیر سهیم باشد. ایدهها معمولاً با بحث در انجمنی مانند [ethresear.ch](https://ethresear.ch/)، انجمن [Ethereum Magicians] (https://ethereum-magicians.org/) یا سرور دیسکورد Eth R&D شروع میشوند. آنها ممکن است پاسخی به آسیبپذیریهای جدیدی باشند که کشف میشوند، پیشنهادات سازمانهایی باشند که در لایه برنامه کار میکنند (مانند [دپ ها](/glossary/#dapp) و صرافی ها) یا از اصطکاکهای شناخته شده برای کاربران نهایی (مانند هزینهها یا سرعتهای تراکنش) باشند. زمانی که این ایدهها تکامل یافتند، میتوانند در قالب [پیشنهاد بهبود اتریوم] مطرح شوند (https://eips.ethereum.org/). تمام این فرآیند به شکل عمومی صورت میگیرد تا هر فردی از این جامعه بتواند هر زمانی در آن نقش داشته باشد.
-
-[مطالب بیشتر درباره حاکمیت اتریوم](/governance/)
-
-
-
-
- ETH2 چه بود؟
-
- اصطلاح "Eth2" معمولا برای توصیف آینده اتریوم قبل از تغییر به اثبات سهام استفاده میشد، اما در راستای اصطلاحات دقیقتر حذف شد. در ابتدا برای متمایز کردن شبکه اتریوم قبل از تغییر به اثبات سهام و شبکه بعد از آن استفاده می شد، یا گاهی اوقات برای اشاره به کاربرهای مختلف اتریوم (کلاینتهای اجرا) به نام کاربرهای ETH1 شناخته میشدند و کاربرهای اجماع گاهی اوقات به عنوان کاربرهای ETH2 شناخته می شدند.
-
-
-
-## آیا نقشه راه اتریوم به مرور زمان تغییر خواهد کرد؟ {#will-ethereums-roadmap-change-over-time}
-
-**بله—تقریباً قطعاً**. نقشه راه اتریوم درواقع همان طرح کنونی برای ارتقای اتریوم است که هم طرحهای میانمدت را شامل میشود و هم طرحهای بلندمدت را. با در دسترس شدن اطلاعات و فناری جدید انتظار داریم که تغییراتی در نقشه راه ایجاد شود.
-
-به نقشه راه اتریوم به عنوان مجموعه ای از اهداف برای بهبود اتریوم فکر کنید. این بهترین فرضیه اصلی محققان و توسعهدهندگان در مورد بهینه ترین مسیر پیشروی اتریوم است.
-
-## نقشه راه کی به پایان میرسد؟ {#when-will-the-roadmap-be-finished}
-
-برخی از ارتقاء ها اولویت پایینتری دارند و احتمالاً تا 5 تا 10 سال آینده اجرا نخواهند شد (مثلاً مقاومت در برابر محاسبات کوانتومی). **ارائه زمان دقیق برای هر ارتقا پیشبینی را پیچیده میکند** زیرا بسیاری از موارد نقشه راه به صورت موازی کار میشوند و با سرعتهای مختلف توسعه مییابند. از طرفی، اولویت پیادهسازی یک ارتقا نیز ممکن است با توجه به عوامل خارجی تغییر کند (به عنوان نمونه، جهش ناگهانی در عملکرد و دسترسیپذیری به کامپیوترهای کوانتومی میتواند رمزنگاری با مقاومت کوانتومی را در اولویت بالاتری قرار دهد).
-
-یکی از راههای ادراک فرآیند توسعه اتریوم مقایسه آن با تکامل زیستی است. شبکهای که در مواجهه با چالشهای جدید، قدرت سازگاری و تطبیقپذیری بالاتری دارد شانس موفقیت بیشتری نسبت به شبکهای دارد که در مقابل تغییرات مقاومت میکند، البته هرچه شبکه قدرت بیشتری در عملکرد پیدا کند، تغییرات کمتری برای مقیاسپذیری و تأمین امنیت روی پروتکل لازم خواهد بود.
-
-## آیا لازم است در مواجهه با ارتقای شبکه کاری صورت دهم؟ {#do-i-have-to-do-anything-when-there-is-an-upgrade}
-
-ارتقاهای شبکه معمولاً تأثیر مستقیمی بر کاربران نهایی شبکه ندارد، جز اینکه کاربران نهایی میتوانند تجربه کاربری بهتر، پرتوکلی امنتر یا شاید امکانات بیشتری برای تعامل با شبکه اتریوم را تجربه کنند. **کاربران عادی نیازی به مشارکت فعال در ارتقاء ندارند و از آنها نیز خواسته نمیشود کاری انجام دهند** که داراییهای خود را حفظ کنند. اپراتورهای [گره](/glossary/#node) باید کاربرهای خود را بهروز کنند تا برای ارتقا آماده شوند. برخی از ارتقاها ممکن است موجب تغییراتی در روند کار توسعهدهندگان برنامههای کاربردی شود. به عنوان نمونه، ارتقاهای مربوط به دوره اتمام تاریخچه ممکن است توسعهدهندگان را به سمت کسب دادههای پیشینهای از منابع جدید سوق دهد.
-
-## ارتقاهای Verge و Splurge و غیره، چه نقشی در بهبود شبکه ایفا میکنند؟ {#what-about-the-verge-splurge-etc}
-
-[«ویتالیک بوترین» چشماندازی را برای نقشه راه اتریوم پیشنهاد داد.](https://twitter.com/VitalikButerin/status/1741190491578810445) این چشمانداز شامل طبقهبندیهای مختلف بود که از لحاظ اثراتشان روی ساختار شبکه اتریوم به هم متصل بودند. این چشمانداز شامل موارد زیر میشد:
-
-- **ادغام**: ارتقاهای مربوط به تغییر از [اثبات کار](/glossary/#pow) به [اثبات سهام](/glossary/#pos)
-- **موج بلند**: ارتقاهای مربوط به مقیاس پذیری توسط [رولآپها](/glossary/#rollups) و شاردینگ داده
-- **شلاق**: ارتقاهای مربوط به مقاومت در برابر سانسور، عدم تمرکز و خطرات پروتکل از سمت [MEV](/glossary/#mev)
-- **نزدیکی**: ارتقاهای مربوط به تأیید آسانتر [بلوکها](/glossary/#block)
-- **پالایش**: ارتقاهای مربوط به کاهش هزینههای محاسباتی گرههای در حال اجرا و سادهسازی پروتکل
-- **ریخت و پاش**: ارتقاءهای دیگر که به خوبی در دسته های قبلی قرار نمی گیرند.
-
-ما تصمیم گرفتیم از این اصطلاحات استفاده نکنیم چراکه میخواستیم از یک مدل سادهتر و کاربرپسندتر استفاده کنیم. اگرچه از زبانی با محوریت کاربران استفاده میکنیم، اما اصل چشمانداز همان است که «ویتالیک» پیشنهاد داد.
-
-## درباره شاردینگ چه میدانید؟ {#what-about-sharding}
-
-شاردینگ یعنی تقسیم بلاکچین اتریوم طوری که زیرمجموعههای [اعتبارسنجها](/glossary/#validator) تنها مسئول کسری از کل داده هستند. قصد این مکانیزم در ابتدا این بود که راهی برای افزایش مقیاسپذیری اتریوم باشد. با این حال، رولآپهای [لایه 2](/glossary/#layer-2) بسیار سریعتر از آنچه انتظار میرفت توسعه یافتهاند و در حال حاضر مقیاسگذاری زیادی را ارائه کردهاند، و پس از اجرای پروتو-دنکشاردینگ بسیار بیشتر خواهند بود. به عبارتی، «خردهزنجیرهها» دیگر به کار نخواهد آمد و از نقشه راه اتریوم حذف شدهاند.
-
-## به دنبال ارتقاهای فنی خاصی میگردید؟ {#looking-for-specific-technical-upgrades}
-
-- [Danksharrding](/roadmap/danksharding): این ارتقا با اضافه کردن «تودههای» دادهها به بلوکهای اتریوم، مکانیزم رولآپهای در لایه دوم را برای کاربران بسیار ارزانتر میکند.
-- [برداشت یا خروج سهام (Staking Withdrawal)](/staking/withdrawals): ارتقای شانگهای/کاپلا امکان خروج سهام از شبکه اتریوم را میسر کرد تا کاربران بتوانند اتریومهای سپردهگذاریشده خود را از حالت مسدود خارج کنند.
-- [قطعیت اسلات منفرد (Single slot finality)](/roadmap/single-slot-finality): به جای انتظار 15 دقیقهای، بلوکها میتوانند در همان اسلات پیشنهاد شوند و قطعی شوند. این امکان برای برنامهها سهولت بیشتری فراهم میکند و حمله به شبکه را دشوارتر میکند.
-- [تفکیک پیشنهاددهنده از سازنده](/roadmap/pbs): تقسیم مسئولیت ایجاد بلوک و پیشنهاد بلوک بین اعتبارسنجهای مختلف وضعیت منصفانهتری فراهم میکند، شبکه را در مقابل سانسور اطلاعات مقاومتر میکند و مسیر بهتری را برای شکلگیری اجماع اتریوم فراهم میکند.
-- [انتخاب رهبر مخفی](/roadmap/secret-leader-election): رمزنگاری هوشمندانه میتواند در راستای اطمینان یافتن از عدم افشای هویت پیشنهاددهندۀ بلوک مورد استفاده قرار گیرد، و بدین ترتیب آنها را از بعضی حملات در امان نگه دارد.
-- [انتزاع حساب](/roadmap/account-abstraction): انتزاع حساب یکی از دستههای ارتقاها است که به جای استفاده از میانافزار پیچیده، پشتیبانی بومی را برای کیف پولهای قرارداد هوشمند روی شبکه اتریوم فراهم میکند.
-- [درختان ورکل](/roadmap/verkle-trees): درختان ورکل نوعی ساختار دادهها است که از آن میتوان برای فعال کردن کلاینتهای بیحالت بر روی شبکه اتریوم استفاده کرد. این کلاینتهای «بیحالت» به فضای ذخیرهسازی ناچیزی احتیاج دارند و درعین حال همچنان میتوانند بلوکهای جدید را تأیید کنند.
-- [بیحالتی](/roadmap/statelessness): کلاینتهای بیحالت قادر خواهند بود تأیید بلوکهای جدید را بدون اینکه لازم به ذخیره کردنمقادیر عظیمی از دادهها باشد انجام دهند. این روش، ضمن اینکه کلیه مزیتهای اجرای یک گره را فراهم میکند، تنها کسری کوچک از هزینههای کنونی را خواهد داشت.
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/merge/index.md b/public/content/translations/fa/11) Roadmap/roadmap/merge/index.md
deleted file mode 100644
index 1e87ad09518..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/merge/index.md
+++ /dev/null
@@ -1,227 +0,0 @@
----
-title: ادغام
-description: توضیحاتی درباره ادغام (The Merge) - وقتی شبکه اصلی اتریوم مکانیزم اثبات سهام را اتخاذ کرد.
-lang: fa
-template: upgrade
-image: /images/upgrades/merge.png
-alt:
-summaryPoint1: '«شبکه اصلی اتریوم» از مکانیزم اثبات سهام استفاده میکند، اما همیشه اینگونه نبوده است.'
-summaryPoint2: به ارتقایی که مکانیزم اصلی اثبات کار را به اثبات سهام تغییر داد ادغام گفته میشود.
-summaryPoint3: رویداد «ادغام» به ادغام شدن شبکه اصلی اتریوم و یک زنجیره بلوکی جداگانه اثبات سهام به اسم زنجیره بیکن (Beacon Chain) اشاره دارد که اکنون به صورت یک زنجیره واحد وجود دارند.
-summaryPoint4: میزان مصرف انرژی اتریوم بعد از ادغام درحدود 99/95% کاهش پیدا کرد.
----
-
-
- ادغام در تاریخ 15 سپتامبر 2022 اجرایی شد. این ارتقا فرایند گذار اتریوم به مکانیزم اجماع اثبات سهام را کامل کرد و باعث شد مصرف انرژی تا 99/95% کاهش یابد.
-
-
-## رویداد ادغام چه بود؟ {#what-is-the-merge}
-
-به اتصال لایۀ اجرای اصلی اتریوم (شبکه اصلی که از بدو [پیدایش](/history/#frontier) اتریوم وجود داشته است) با لایۀ اجماع جدید اثبات سهام آن (زنجیره بیکن) بود. این رویداد نیاز به استخراج انرژیبر را از بین بُرد و در عوض شبکه را قادر ساخت تا با استفاده از اتریوم سهامگذاریشده، امن شود. این رویداد یک گام واقعاً هیجانانگیز در تحقق چشمانداز اتریوم —یعنی مقیاسپذیری، امنیت و پایداری بیشتر — بود.
-
-
-
-در ابتدا، [زنجیره بیکن](/roadmap/beacon-chain/) به طور مجزا از [شبکه اصلی](/glossary/#mainnet) عرضه شد. شبکه اصلی اتریوم - با تمام حسابها، موجودیها، قراردادهای هوشمند و حالت زنجیره بلوکی - همچنان با [اثبات کار](/developers/docs/consensus-mechanisms/pow/) ایمن میشد، با اینکه حتی زنجیره بیکن با استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) به طور موازی اجرا میشد. «ادغام» مربوط به زمانی است که این دو سیستم در نهایت با هم یکی شدند و اثبات کار برای همیشه جای خود را به اثبات سهام داد.
-
-تصور کنید اتریوم یک سفینۀ فضایی است که قبل از آمادگی کامل برای یک سفر بین ستارهای، به فضا پرتاب شده است. با زنجیره بیکن، جامعۀ اتریوم یک موتور جدید و یک بدنۀ سخت ساخت. پس از انجام آزمایشهای سنگین، در اواسط پرواز زمان تعویض موتور جدید با موتور قدیمی فرا رسید. این کار موتور جدید و کارآمدتر را در سفینۀ موجود جای داد و آن را قادر ساخت چند سال نوری مهم را طی کند و جهان را تحت کنترل خود درآورد.
-
-## ادغام با شبکه اصلی {#merging-with-mainnet}
-
-با اثبات کار، امنیت شبکه اصلی اتریوم از زمان پیدایش تا زمان ادغام تأمین شد. این به زنجیره بلوکی اتریوم که همۀ ما به آن عادت کردهایم اجازه داد تا در ماه ژوئیه 2015 با تمام ویژگیهای آشنای آن مانند تراکنشها، قراردادهای هوشمند، حسابها و غیره به وجود بیاید.
-
-در طول تاریخ اتریوم، توسعهدهندگان خود را برای انتقال نهایی از اثبات کار به اثبات سهام آماده میکردند. روز 1 دسامبر 2020، زنجیره بیکن به عنوان یک زنجیره بلوکی جداگانه برای شبکه اصلی ایجاد شد، که به صورت موازی درحال اجرا بود.
-
-زنجیره بیکن در ابتدا تراکنشهای شبکه اصلی را پردازش نمیکرد. در عوض، با توافق بر روی اعتبارسنجهای فعال و موجودی حسابهای آنها، دربارۀ حالت خود داشت اجماع حاصل میکرد. پس از آزمایشهای گسترده، زمان آن فرا رسید که زنجیره بیکن در مورد دادههای دنیای واقعی به اجماع برسد. بعد از رویداد ادغام، زنجیره بیکن به موتور اجماع همۀ دادههای شبکه، ازجمله تراکنشهای لایۀ اجرا و موجودی حساب، تبدیل شد.
-
-ادغام منعکسکنندۀ تغیرر رسمی به استفاده از زنجیره بیکن به عنوان موتور تولید بلوک بود. استخراج دیگر وسیلهای برای تولید بلوکهای معتبر نیست. در عوض، اعتبارسنجهای اثبات سهام این نقش را پذیرفتهاند و اکنون مسئولیت پردازش اعتبار همۀ تراکنشها و پیشنهاد بلوکها را بر عهده دارند.
-
-هیچ سابقهای در «ادغام» گم نشد. همچنانکه شبکه اصلی با زنجیره بیکن ادغام شد، کل سابقۀ معاملات اتریوم را نیز ادغام کرد.
-
-
-با گذار به اثبات سهام، نحوۀ صدور اتر تغییر یافت. درباره نحوه صدور اتر قبل و بعد از ادغام بیشتر بدانید.
-
-
-### کاربران و دارندگان {#users-holders}
-
-**«ادغام» چیزی را برای دارندگان/کاربران اتریوم تغییر نداد.**
-
-_پس این موضوع را تکرار میکنیم_: شما به عنوان کاربر یا دارنده اتریوم یا هر دارایی دیجیتال دیگری در شبکۀ اتریوم، و همچنین سهامگذاران غیرفعال گره، **نیازی نیست هیچ کاری با وجوه یا کیف پول خود درپی رویداد «ادغام» انجام دهید.**اتر همان اتر است. چیزی به نام «اتر قدیمی»/«اتر جدید» یا «اتر1»/«اتر2» وجود ندارد و کیف پولها نیز پس از ظهور «ادغام» دقیقاً مانند قبل کار میکنند— افرادی که چیزی جز این به شما میگویند احتمالاً کلاهبردارند.
-
-با وجود کنار گذاشتن اثبات کار و جایگزینی آن با اثبات سهام، کل سابقۀ اتریوم از زمان پیدایش، دستنخورده باقی ماند و تغییری نکرد. همۀ وجوهی که قبل از «ادغام» در کیف پول شما نگهداری میشد، پس از «ادغام» نیز همچنان قابل دسترسی است. **از سمت شما، هیچ اقدامی به منظور ارتقا لازم نیست.**
-
-[دربارۀ امنیت اتریوم بیشتر بدانید](/security/#eth2-token-scam)
-
-### اپراتورهای گره و توسعهدهندگان Dapp {#node-operators-dapp-developers}
-
-
-
-موارد کلیدی اقدام عبارتند از:
-1. اجرای هردو کلاینت اجرا و کلاینت اجماع؛ از زمان وقوع ادغام، اندپوینتهای شخص ثالث برای به دست آوردن دادههای اجرا دیگر کار نمیکنند.
-2. تأیید اعتبار هر دو کلاینت اجرا و اجماع با یک رمز مشترک JWT تا بتوانند ارتباط امن برقرار کنند.
-3. تنظیم یک آدرس «گیرندۀ کارمزد» برای دریافت نکات/MEV کارمزد تراکنش کسبشده.
-
-تکمیل نکردن دو مورد اول باعث میشود تا زمانی که هر دو لایه همگامسازی و احراز هویت شوند، گره شما «آفلاین» دیده شود.
-
-تنظیم نکردن «گیرندۀ کارمزد» همچنان به اعتبارسنج شما اجازه میدهد تا طبق معمول رفتار کند، اما نکات مربوط به کارمزد تراکنش نسوخته و هرگونه MEV (حداکثر ارزش قابل استخراج) را از دست خواهید داد، درحالی که میتوانستید در بلوکهایی که اعتبارسنج شما پیشنهاد میکند به دست آورید.
-
-
-
-
-تا قبل از ادغام، یک کلاینت اجرا (مانند Geth، Erigon، Besu یا Nethermind) برای دریافت، اعتبارسنجی صحیح و انتشار بلوکهایی که توسط شبکه شایعه میشوند کافی بود. پس از ادغام، اعتبار تراکنشهای موجود در پیلود اجرا اکنون به اعتبار «بلوک اجماع» موجود در داخل آن نیز بستگی دارد.
-
-در نتیجه، یک گره کامل اتریوم اکنون هم به کلاینت اجرا و هم کلاینت اجماع نیاز دارد. این دو کلاینت با استفاده از Engine API جدید با هم کار میکنند. Engine API نیازمند احراز هویت با استفاده از یک رمز JWT است که برای هر دو کلاینت ارائه میشود و امکان برقراری ارتباط امن را فراهم میکند.
-
-موارد کلیدی اقدام عبارتند از:
-- نصب یک کلاینت اجماع علاوه بر یک کلاینت اجرا
-- تأیید اعتبار کلاینتهای اجرا و اجماع با یک رمز مشترک JWT تا بتوانند ارتباط امنی با یکدیگر برقرار کنند.
-
-تکمیل نکردن موارد بالا باعث میشود که گره شما «آفلاین» به نظر برسد تا زمانی که هر دو لایه همگامسازی و احراز هویت شوند.
-
-
-
-
-
-رویداد «ادغام» با تغییراتی در اجماع همراه شد، که همچنین شامل تغییرات مرتبط با موارد زیر میشود:<
-
-
- - ساختار بلوک
- - زمانبندی اسلات/بلوک
- - تغییرات کد عملیاتی
- - انتخاب تصادفی منابع روی زنجیره
- - مفهوم Safe Head و بلوکهای نهاییشده
-
-
-برای اطلاعات بیشتر، این پست وبلاگی از Tim Beiko را در مورد چگونگی تأثیر «ادغام» بر لایۀ برنامۀ اتریوم بررسی کنید.
-
-
-
-## ادغام و مصرف انرژی {#merge-and-energy}
-
-ادغام پایان اثبات کار برای اتریوم بود و عصر اتریوم پایدارتر و سازگارتر با محیط زیست را آغاز کرد. مصرف انرژی اتریوم 99/95 درصد کاهش یافت و اتریوم را به یک زنجیره بلوکی سبز تبدیل کرد. دربارۀ [مصرف انرژی اتریوم](/energy-consumption/) بیشتر بدانید.
-
-## «ادغام» و مقیاسپذیری {#merge-and-scaling}
-
-«ادغام» زمینه را برای ارائه ارتقاهای بیشتر در زمینه مقیاسپذیری فراهم کرد که در مکانیزم اثبات کار امکانپذیر نبود. بدین ترتیب، شبکۀ اتریوم را یک گام به دستیابی به مقیاس کامل، امنیت و پایداری که در [چشمانداز اتریوم](/roadmap/vision/) ذکر شده است نزدیکتر کرد.
-
-## باورهای غلط دربارۀ «ادغام» {#misconceptions}
-
-
-
-دو نوع گره اتریوم وجود دارد: گرههایی که میتوانند بلوکها را پیشنهاد کنند و گرههایی که نمیتوانند این کار را انجام دهند.
-
-تنها تعداد معدودی از کل گرههای اتریوم میتوانند بلوکها را پیشنهاد کنند. این دسته شامل گرههای استخراج تحت اثبات کار (PoW) و گرههای اعتبارسنج تحت اثبات سهام (PoS) میشود. این دسته نیازمند تخصیص منابع اقتصادی (مانند قدرت هش GPU در اثبات کار یا اتر سهامگذاریشده در اثبات سهام) در ازای توانایی پیشنهاد مقطعی بلوک بعدی و دریافت پاداشهای پروتکل است.
-
-سایر گرههای شبکه (یعنی اکثریت آنها) جز یک کامپیوتر خانگی با 1-2 ترابایت فضای ذخیرهسازی و اتصال به اینترنت، به هیچ منبع اقتصادی دیگری نیاز ندارند. این گرهها پیشنهاد بلوک نمیدهند، اما همچنان با پاسخگو نگهداشتن همۀ پیشنهاددهندگان بلوک با شنود کردن بلوکهای جدید و تأیید اعتبار آنها در بدو ورود بر طبق قوانین اجماع شبکه، نقش مهمی در امنیت شبکه ایفا میکنند. اگر بلوک معتبر باشد، گره به انتشار آن از طریق شبکه ادامه میدهد. اگر بلوک به هر دلیلی نامعتبر باشد، نرمافزار گره آن را به عنوان بلوک نامعتبر نادیده میگیرد و انتشارش را متوقف میکند.
-
-اجرای یک گره تولیدکننده غیربلوکی تحت هر دو مکانیزم اجماع (اثبات کار یا اثبات سهام) برای هر کسی امکانپذیر است و انجام آن برای همۀ کاربران در صورت داشتن امکانات لازم، اکیداً توصیه میشود. اجرای هر گره برای اتریوم بسیار ارزشمند است و به هر فردی که در حال اجرای گره باشد مزایای افزودهای اختصاص میدهد، ازجمله بهبود امنیت، حفظ حریم خصوصی و مقاومت در برابر سانسور.
-
-توانایی تکتک افراد برای اجرای گرههای خود، به منظور حفظ غیرمتمرکزسازی شبکۀ اتریوم کاملاً ضروری است.
-
-مطالب بیشتر در مورد اجرای گره
-
-
-
-
-
-هزینههای گس محصول تقاضای شبکه نسبت به ظرفیت شبکه است. «ادغام» استفاده از مکانیزم اثبات کار را منسوخ کرد و برای اجماع به مکانیزم اثبات سهام روی آورد، اما در هیچ پارامتری که به طور مستقیم بر ظرفیت یا تعداد دادههای ورودی شبکه تأثیرگذار است، تغییر قابل توجهی ایجاد نکرد.
-
-با یک نقشۀ راه رولآپ محور تلاشها بر مقیاسپذیری فعالیت کاربر در لایه 2 متمرکز شده است، ضمن اینکه شبکه اصلی لایه 1 را به عنوان یک لایۀ استقرار غیرمتمرکز امن که برای ذخیرهسازی دادههای رولآپ بهینه شده است فعال میکند تا به ارزانتر کردن تراکنشهای رولآپ به صورت تصاعدی کمک کند. انتقال به اثبات سهام یک پیشزمینۀ حیاتی برای تحقق این امر است. اطلاعات بیشتر در مورد گس و کارمزدها.
-
-
-
-
-«سرعت» تراکنش را میتوان به چند روش اندازهگیری کرد، از جمله زمان گنجانده شدن در یک بلوک و زمان نهایی شدن. هر دوی اینها تغییراتی درحد کم داشتهاند، اما نه به گونهای که برای کاربران محسوس باشد.
-
-از آغاز، در اثبات کار، هدف این بود که تقریباً هر 13/3 ثانیه یک بلوک جدید داشته باشیم. تحت اثبات سهام، اسلاتها دقیقا هر 12 ثانیه اتفاق میافتند، که هر کدام فرصتی برای انتشار یک بلوک برای اعتبارسنج است. اکثر اسلاتها بلوک دارند، اما نه لزوماً همۀ آنها (یعنی اعتبارسنج آفلاین است). در اثبات سهام، تقریباً 10٪ بیشتر از اثبات کار بلوک تولید میشود. این تغییر نسبتاً ناچیز بود و بعید است کاربران متوجه آن شوند.
-
-اثبات سهام مفهوم قطعیت در تراکنش را معرفی کرد که پیش از آن وجود نداشت. در اثبات کار، امکان معکوس کردن یک بلوک با عبور هر بلوک استخراجشده در بالای تراکنش، به طور تصاعدی دشوارتر میشود، اما هرگز به صفر نمیرسد. بر اساس اثبات سهام، بلوکها در ایپوکهایی دستهبندی میشوند (بازههای زمانی 6/4 دقیقهای شامل 32 شانس برای بلوک) که اعتبارسنجها به آن رأی میدهند. هنگامی که یک ایپوک به پایان میرسد، اعتبارسنجها رأی میدهند که آیا آن ایپوک را «موجه» (justified) درنظر بگیرند یا خیر. اگر اعتبارسنجها با موجه دانستن ایپوک موافقت کنند، در ایپوک بعدی نهایی میشود. لغو تراکنشهای نهایی از نظر اقتصادی مقرونبهصرفه نیست، زیرا مستلزم دریافت و سوزاندن بیش از یکسوم کل اتریوم سهامگذاریشده است.
-
-
-
-
-
-در ابتدا پس از وقوع «ادغام»، سهامگذاران فقط میتوانستند به نکات هزینه و MEV که در نتیجۀ پیشنهادهای بلوک بهدست میآمدند، دسترسی داشته باشند. این پاداشها به یک حسابِ غیرسهامی که توسط اعتبارسنج (معروف به گیرندۀ کارمزد) کنترل میشود واریز میگردد و بلافاصله در دسترس است. این پاداشها جدا از پاداشهای پروتکل است که درقبال انجام وظایف اعتبارسنج داده میشود.
-
-از زمان ارتقای شبکۀ شانگهای/کاپلا، سهامگذاران میتوانند یک آدرس برداشت برای شروع دریافت پرداختهای خودکار هرگونه اضافه موجودی سهامگذاری (بیش از 32 واحد اتریوم از پاداشهای پروتکل) تعیین کنند. این ارتقا همچنین به اعتبارسنج امکان میدهد تا پس از خروج از شبکه، کل موجودی خود را رمزگشایی و بازیابی کند.
-
-اطلاعات بیشتر دربارۀ برداشتها در سهامگذاری
-
-
-
-
-از آنجایی که ارتقای شانگهای/کاپلا امکان برداشت را فراهم کرد، اعتبارسنجها تشویق میشوند تا موجودی اضافی سهامگذاری بالای 32 واحد اتریوم را برداشت کنند، زیرا این وجوه به بازدهی نمیافزایند و اگر این کار را نکنند، قفل میشوند. بسته به APR (که براساس کل اتریوم سهامگذاریشده تعیین میشود)، ممکن است به آنها انگیزه داده شود که از اعتبارسنج(های) خود خارج شوند تا کل موجودیشان را پس بگیرند یا برای کسب بازدهی بیشتر، با استفاده از پاداشهای خود، حتی بیش از این سهامگذاری کنند.
-
-یک نکتۀ مهم در اینجا این است که سرعت خروجیهای اعتبارسنج کامل توسط پروتکل محدود میشود و فقط آن تعداد محدودی اعتبارسنج ممکن است در هر ایپوک (هر 6/4 دقیقه) خارج شوند. این حد بسته به تعداد اعتبارسنجهای فعال در نوسان است، اما تقریباً 0/33٪ از کل اتریومهای سهامگذاریشده را میتوان در یک روز از شبکه خارج کرد.
-
-این امر از خروج حجم عظیمی از وجوه سهامگذاریشده جلوگیری میکند. به علاوه، مانع از آن میشود که یک مهاجم بالقوه با دسترسی به بخش بزرگی از کل اتریوم سهامگذاریشده، مرتکب تخلفی شود که مستحق اخراج باشد و قبل از آنکه پروتکل بتواند مجازات اخراج را اعمال کند، تمام موجودی اعتبارسنجهای متخلف در همان ایپوک را خارج/برداشت کند.
-
-APR همچنین به طور هدفمندی پویا است و به بازار سهامگذاران اجازه میدهد تا در میزان مبلغی که مایل به پرداخت آن برای کمک به امنیت شبکه هستند تعادل ایجاد کنند. اگر نرخ خیلی پایین باشد، آنگاه اعتبارسنجها با نرخی که با پروتکل محدود شده است خارج میشوند. این امر به تدریج APR را برای همۀ افراد باقیمانده افزایش خواهد داد، ضمن اینکه دوباره سهامگذاران جدید یا بازگشتی را جذب میکند.
-
-
-## چه بر سر «Eth2» آمد؟ {#eth2}
-
-اصطلاح «Eth2» منسوخ شده است. پس از ادغام «Eth1» و «Eth2» در یک زنجیرۀ واحد، دیگر نیازی به متمایز کردن این دو شبکۀ اتریوم نیست؛ زیرا فقط یک شبکه وجود دارد و آن هم اتریوم است.
-
-برای جلوگیری از گیج شدن، جامعه این واژهها را بهروز کرده است:
-
-- «Eth1» الان «لایهی اجرا» است که به تراکنشها و اجراها رسیدگی میکند.
-- «Eth2» الان «لایهی اجماع» است، که به وفاق اثبات کار رسیدگی میکند.
-
-این بهروزرسانی در نامگذاری تنها در مورد عوض شدن نامهاست؛ این به اهداف یا نقشهی راه اتریوم هیچ خدشهای وارد نمیکند.
-
-[دربارهی تغییر نام «Eth2» بیشتر بدانید](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/)
-
-## رابطهی بین ارتقاها {#relationship-between-upgrades}
-
-تمام ارتقاهای اتریوم تا حدودی با یکدیگر مرتبط هستند. پس بیایید نحوۀ ارتباط «ادغام» با سایر ارتقاها را مرور کنیم.
-
-### «ادغام» و زنجیره بیکن {#merge-and-beacon-chain}
-
-«ادغام» نشاندهندۀ اتخاذ رسمی زنجیره بیکن به عنوان لایۀ اجماع جدید برای لایۀ اجرای ابتدایی شبکه اصلی است. از زمان وقوع «ادغام»، وظیفۀ تأمین امنیت شبکه اصلی اتریوم به اعتبارسنجها واگذار شده است و استخراج با استفاده از [الگوریتم اثبات کار](/developers/docs/consensus-mechanisms/pow/) دیگر ابزاری معتبر برای تولید بلوک نیست.
-
-در عوض، بلوکها با گرههای اعتبارسنجی که در ازای حق مشارکت در اجماع اقدام به سهامگذاری اتریوم کردهاند پیشنهاد میشوند. این ارتقا زمینه را برای سایر ارتقاهای مقیاسپذیری آتی، ازجمله شاردینگ (زنجیرهایسازی)، فراهم کرد.
-
-
- زنجیره بیکن
-
-
-### «ادغام» و ارتقای شانگهای {#merge-and-shanghai}
-
-به منظور سادهسازی و به حداکثر رساندن تمرکز روی یک انتقال موفق به اثبات سهام، جریان ارتقا طی رویداد «ادغام» یک سری ویژگیهای معین پیشبینیشده، همچون توانایی برداشت اتر سهامگذاریشده، را دربر نداشت. این عملکرد به صورت جداگانه با ارتقای شانگهای /کاپلا فعال شد.
-
-افراد کنجکاو میتوانند مقالۀ [چه اتفاقی پس از ادغام میافتد](https://youtu.be/7ggwLccuN5s?t=101) را مطالعه کنند، مطلبی که توسط Vitalik در رویداد جهانی اتر در آوریل 2021 ارائه شد.
-
-### «ادغام» و شاردینگ {#merge-and-data-sharding}
-
-در اصل، برنامه این بود که قبل از «ادغام» روی شاردینگ کار شود تا موضوع مقیاسپذیری مورد توجه قرار گیرد. اما، با رونق [راهحلهای مقیاسپذیری لایه 2](/layer-2/) اولویت به تغییر از مکانیزم اثبات کار به اثبات سهام داده شد.
-
-طرحهای شاردینگ بهسرعت در حال تکاملاند، اما با توجه به ظهور و موفقیت فناوریهای لایه 2 برای مقیاسپذیری اجرای تراکنشها، طرحهای شاردینگ به سمتِ یافتن بهینهترین راه برای توزیع بار ذخیرهسازی کالدیتای فشرده از قراردادهای رولآپ سوق یافتهاند که امکان رشد تصاعدی در ظرفیت شبکه را فراهم میکند. این امر بدون گذار به اثبات سهام نمیتوانست ممکن باشد.
-
-
- خرد کردن
-
-
-## بیشتر بخوانید {#further-reading}
-
-
-
-
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/merge/issuance/index.md b/public/content/translations/fa/11) Roadmap/roadmap/merge/issuance/index.md
deleted file mode 100644
index 78cd52bb001..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/merge/issuance/index.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: چگونگی تأثیر رویداد ادغام (The Merge) بر عرضه اتر
-description: جزئیات تأثیر رویداد ادغام بر عرضه اتر
-lang: fa
----
-
-# چگونگی تأثیر رویداد ادغام (The Merge) بر عرضه اتر {#how-the-merge-impacts-ETH-supply}
-
-فرآیند «ادغام» که در سپتامبر سال 2022 انجام گرفت، سبب گردید که شبکۀ اتریوم از مکانیزم اثبات کار به اثبات سهام تغییر کند. نحوۀ صدور رمزارز اتریوم نیز در مقطع وقوع آن گذار دستخوش تغییراتی در شبکه شد. پیش از این، اتر جدید توسط دو منبع صادر میشد: لایۀ اجرا (یعنی شبکۀ اصلی) و لایۀ اجماع (یعنی زنجیره بیکن). از زمان وقوع «ادغام»، صدور اتر توسط لایۀ اجرا به صفر رسیده است. بیایید به جزئیات این موضوع بپردازیم.
-
-## اجزای صدور رمزارز اتر {#components-of-eth-issuance}
-
-عرضۀ اتر در شبکه توسط دو فرآیند اصلی انجام میپذیرد: صدور و سوزاندن.
-
-**صدور** اتر فرآیند ایجاد رمزارزهای اتریومی است که قبلاً در شبکه وجود نداشتهاند. پروسه **سوزاندن** اترها نیز زمانی اتفاق میافتد که رمزارزهای اتریوم موجود معدوم میشوند و از گردش در شبکه حذف میگردند. نرخ صدور و سوزاندن توسط چندین پارامتر محاسبه میشود، و تعادل بین آنها تعیینکننده نرخ تورم /کاهش تورم اتر است که درپی آن حاصل میشود.
-
-
-
--قبل از انتقال به مکانیسم اثبات سهام، استخراجگرها تقریباً 13,000 رمزارز اتر را در روز ایجاد میکردند
--تقریباً 1,700 اتر در روز برای سهامگذاران ایجاد و صادر میشود که براساس حدود 14 میلیون از کل رمزارزهای اتر سهامگذاریشده در شبکه انجام میگیرد
--مقدار دقیق اترهای صادرشده با مکانیسم اثبات سهام، بر مبنای مقدار کل اترهای سهامگذاریشده در شبکه در نوسان است
-- **از زمان وقوع «ادغام»، تنها 1,700 اتر در روز در شبکه باقی میماند، یعنی مقدار کل صدور اتر جدید 88 درصد کاهش یافته است**
--سوزاندن: میزان سوزانده شدن رمزارزهای اتر بسته به تقاضا در شبکه در نوسان است. _اگر_ قیمت متوسط گس در شبکه حداقل 16 gwei در یک روز معین باشد، این قضیه به طور مؤثری 1,700 اتریومی را که برای اعتبارسنجها صادر میشود، جبران نموده و تورم خالص اتر را در همان روز به صفر یا کمتر میرساند.
-
-
-
-## قبل از ادغام (تاریخی) {#pre-merge}
-
-### صدور در لایۀ اجرا {#el-issuance-pre-merge}
-
-در مکانیزم اثبات کار، استخراجگرها تنها با لایۀ اجرا در تعامل بودند و در صورتی که به عنوان اولین استخراجگر میتوانستند بلوک بعدی را حل کنند، پاداش بلوک به آنها تعلق میگرفت. از زمان [ارتقای Constantinople ](/history/#constantinople)در سال 2019، این پاداش 2 اتر به ازای هر بلوک بود. استخراجگرها حتی برای انتشار بلوکهای[Ommer](/glossary/#ommer) پاداش دریافت میکردند. آنها بلوکهای معتبری بودند که نمیتوانستند به زنجیرۀ طولانیتر/متعارف بلوکهای شبکه بپیوندند. این پاداشها به حداکثر 1/75 اتر به ازای هر بلوک ommer میرسید، و این پاداشها _علاوه بر_ پاداشی بود که بابت بلوکهای متعارف در شبکه دریافت میشد. فرآیند استخراج یک فعالیت فشرده اقتصادی بود که به طور تاریخی برای ثبات خود نیاز به سطوح بالایی از صدور اتر داشت.
-
-### صدور در لایۀ اجماع {#cl-issuance-pre-merge}
-
-[زنجیره بیکن](/history/#beacon-chain-genesis) در سال ۲۰۲۰ راهاندازی شد. امنیت این زنجیره به جای استخراجگرها، توسط اعتبارسنجهایی که از مکانیزم اثبات سهام استفاده میکنند، تأمین میشود. زنجیرۀ بیکن توسط کاربران شبکۀ اتریوم بوت استرپ یا خودگردانسازی شد که طی آن، کاربران رمزارز اتر را به صورت یکطرفه به قرارداد هوشمندی که روی شبکۀ اصلی (لایۀ اجرا) بود واریز میکردند تا درنتیجۀ آن، زنجیرۀ بیکن بهاندازه همان مقدار اتریوم روی زنجیره جدید به کاربر اعتبار دهد. بعد از این که رویداد «ادغام» انجام گرفت، اعتبارسنجهای زنجیرۀ بیکن دیگر تراکنشها را پردازش نکردند و نسبت به وضعیت استخر اعتبارسنج اساساً داشتند به اجماع میرسیدند.
-
-اعتبارسنجها روی زنجیرۀ بیکن بابت تأیید وضعیت زنجیره و پیشنهاد دادن بلوکها، اتر پاداش میگیرند. پاداشها ( یا جریمهها) در هر ایپوک (هر 6/4 دقیقه) براساس عملکرد اعتبارسنج محاسبه و توزیع میشوند. پاداشهای اعتبارسنجی **به طور قابل توجهی**کمتر از پاداشهای استخراج است که قبلاً در مکانیزم اثبات کار (در هر 13/5 ثانیه 2 اتر) صادر میشد، چون اجرای یک گره اعتبارسنجی از نظر اقتصادی چندان مشکل نیست، بنابراین نیازی به پاداش بالا یا ضمانت زیادی در این زمینه ندارد.
-
-### تفکیک صدور اتر قبل از ادغام {#pre-merge-issuance-breakdown}
-
-عرضۀ کل اتر:**معادل 120,520,000 اتر**(در زمان وقوع ادغام در ماه سپتامبر 2022)
-
-**صدور در لایۀ اجرا:**
-
-- در هر 13/3 ثانیه 2/08 اتر تخمین زده شده است/*:**صدور حدود 4,930,000** اتر در یک سال
-- منجر به نرخ تورم تقریبی **حدوداً 4/09% درصد**شده است (4/93 میلیون اتر در سال / جمعاً 120/5 میلیون اتر)
-- /*این شامل پاداشی برابر 2 اتر برای هر بلوک متعارف، به علاوۀ میانگین 0/08 اتر برای بلوکهای ommer در طول زمان میشود. همچنین از 13.3 ثانیه استفاده میکند، یعنی تارگت زمانی در بلوک پایه بدون هیچگونه اثری از [بمب سختی](/glossary/#difficulty-bomb). ([مشاهده منبع](https://bitinfocharts.com/ethereum/))
-
-**صدور در لایۀ اجماع:**
-
-- با استفاده از تمامی 14/000/000 اتر سهامگذاریشده، نرخ صدور حدوداً معادل 1700 اتر در روز است ([مشاهده منبع](https://ultrasound.money/))
-- در نتیجه **حدود 620,500** اتریوم در سال صادر شده است
-- منجر به تورم سالانه **حدود 0/52 درصد** شد (620/5 هزار اتر در سال / جمعاً 119/3 میلیون)
-
-
-نرخ صدور کل سالانه (قبل ادغام): حدود 4/61 درصد(4/09 درصد + 0/52 درصد)
حدود 88/7 درصد از صدوری که در لایۀ اجرا به استخراجگرها تعلق میگرفت (4/09 / 4/61 * 100)
میزان 11/3 درصد برای سهامگذاران در لایۀ اجماع صادر میشد ( 0/52 / 4/61 * 100)
-
-
-## بعد از ادغام (مقطع کنونی) {#post-merge}
-
-### صدور در لایۀ اجرا {#el-issuance-post-merge}
-
-صدور در لایۀ اجرا از زمان وقوع «ادغام» به صفر رسیده است. مکانیزم اثبات کار دیگر مسیر معتبری برای تولید بلوک تحت قوانین ارتقایافته در اجماعِ شبکه نیست. تمامی فعالیتهای لایۀ اجرا در «بلوکهای بیکن» بستهبندی شده، و توسط اعتبارسنجهای اثبات سهام منتشر و تأیید میشوند. پاداشها برای تأیید و انتشار بلوکهای بیکن به طور جداگانه در لایۀ اجماع محاسبه میگردند.
-
-### صدور در لایۀ اجماع {#cl-issuance-post-merge}
-
-صدور در لایۀ اجماع امروز نیز همانند قبل از رویداد «ادغام» با درنظر گرفتن پاداشهای کوچک برای اعتبارسنجهایی که بلوکها را تأیید میکنند و پیشنهاد میدهند، ادامه دارد. پاداشهای اعتبارسنجی همچنان به _اعتبارسنجهایی_ که در لایۀ اجماع مدیریت میشوند تعلق میگیرد. برخلاف حسابهای جاری (حسابهای «اجرا»)، که میتوانند در شبکۀ اصلی معامله انجام دهند، اینها حسابهای جداگانۀ اتریومی هستند که نمیتوانند آزادانه با سایر حسابهای اتریومی معامله یا تراکنشی داشته باشند. برداشت داراییهای موجود در این نوع حسابها را فقط میتوان با انتقال به یک آدرس اجرایی واحد و مشخصشده انجام داد.
-
-از زمان بهروزرسانیهای شانگهای/کاپلا که در آوریل سال 2023 به وقوع پیوستند، این برداشتها برای سهامگذاران شبکه فعال شده است. سهامگذاران تشویق میشوند که _عایدیها/پاداشهای خود را (موجودی بیش از 32 اتر)_ حذف کنند به این دلیل که این داراییها درحالت غیر هیچ نقشی در وزن سهامگذاریشان ندارد (که با رسیدن به 32 واحد به حداکثر میرسد).
-
-سهامگذاران حتی ممکن است بخواهند از شبکه خارج شده و تمامی موجودی اعتبارسنجشان را برداشت کنند. برای اطمینان از ثبات شبکۀ اتریوم، تعدادِ اعتبارسنجهایی که میتوانند همزمان شبکه را ترک کنند، محدود شده است.
-
-تقریباً 0/33 درصد از کل تعداد اعتبارسنجها میتوانند در یک روز مشخص از شبکه خارج شوند. به طور پیشفرض، چهار (4) اعتبارسنج میتوانند در هر ایپوک (هر 6.4 دقیقه، یا 900 اعتبارسنج در روز) از شبکه خارج شوند. به ازای هر 65,536 (162) اعتبارسنج وقتی تعدادشان از 262,144 (182) بیشتر باشد، تنها یک (1) اعتبارسنج مجاز به خروج است. برای مثال، با وجود بیش از 327,680 اعتبارسنج در شبکه، پنج (5) اعتبارسنج میتوانند در هر ایپوک (1,125 در روز) از شبکه خارج شوند. شش (6) اعتبارسنج تنها زمانی میتوانند از شبکه خارج شوند که تعداد کل اعتبارسنجهای فعال در شبکه بیش از 393,216 باشد و این قضیه به همین ترتیب ادامه دارد.
-
-با برداشت موجودی ازسوی تعدادی بیشتری اعتبارسنج، بیشترین تعداد اعتبارسنجی که میتواند از شبکه خارج شود به تدریج به حداقل چهار نفر کاهش مییابد تا عمداً از برداشت همزمان مقادیر زیادی اتر سهامگذاریشده، که موجب بیثباتی در شبکه میگردد، جلوگیری گردد.
-
-### تفکیک میزان تورم بعد از «ادغام» {#post-merge-inflation-breakdown}
-
-- عرضۀ کل اتر:**معادل 120,520,000 اتر**(در زمان وقوع ادغام در ماه سپتامبر 2022)
-- صدور در لایۀ اجرا: **0**
-- صدور در لایۀ اجماع: همانطور که در بالا اشاره شد،**تقریباً 0/52درصد**نرخ صدور سالانه (با 14 میلیون از کل اتر سهامگذاریشده)
-
-
-نرخ صدور سالانۀ کل:حدود 0/52درصد
کاهش خالص در صدور سالانه:حدود88/7 درصد((4/61% - 0/52%) / 4/61% * 100)
-
-
-## سوزاندن {#the-burn}
-
-نیروی مخالف صدور اتر، نرخ سوزانده شدنش است. برای اجرایی شدن یک تراکنش بر روی شبکۀ اتریوم، حداقل کارمزد شبکه (که با نام «کارمزد پایه» شناخته میشود) باید پرداخت گردد، که مقدارش به طور پیوسته (بلوک به بلوک) بسته به فعالیت شبکه در نوسان و تغییر است. کارمزد به واحد اتر پرداخت میشود و برای معتبر تلقی شدن تراکنشها _نیاز_است. این کارمزد در فرآیند انجام یک تراکنش _میسوزد_، و از چرخه حذف میشود.
-
-
-سوختن کارمزد در اوت 2021 و با اجرای ارتقای لندنمحقق گردید و از زمان وقوع «ادغام» هم تغییری نکرده است.
-
-
-علاوه بر سوزاندن کارمزد تراکنشها که طی ارتقای لندن اجرایی شد، اعتبارسنجها میتوانند جریمههایی را نیز از بابت آفلاین بودنشان یا بدتر از آن متحمل شوند؛ آنها ممکن است با زیر پا گذاشتن قوانین خاصی که امنیت شبکه را تهدید میکند، از شبکه بیرون انداخته شوند. این جریمهها باعث کاهش در موجودی اتر اعتبارسنجها میگردد؛ جریمۀ برداشتشده مستقیماً به حسابهای دیگر به عنوان پاداش داده نمیشود، بلکه به طور اثربخش سوزانده/از گردش در شبکه حذف خواهد شد.
-
-### محاسبۀ میانگین قیمت گس برای کاهش تورم {#calculating-average-gas-price-for-deflation}
-
-همانطور که در بالا صحبت کردیم، مقدار اتر صادرشده در یک روز مشخص به تعداد کل اترهای سهامگذاریشده بستگی دارد. در زمان نوشتن این مقاله، این مقدار تقریباً برابر 1700 اتر در روز است.
-
-برای تعیین قیمت میانگین گس مورد نیاز به منظور جبران فرآیند صدور در شبکه و تعادل با آن در یک دورۀ معین 24 ساعته، با محاسبۀ تعداد کل بلوکها در یک روز، و دادن زمان 12 ثانیه به هر بلوک شروع میکنیم:
-
-- `(یک بلوک /12 ثانیه)*(60 ثانیه/1 دقیقه)= 5 بلوک/دقیقه`
-- `(5 بلوک/دقیقه)*(60 دقیقه/1 ساعت)=300 بلوک/ساعت`
-- `(300بلوک/ساعت)*(24 ساعت/1 روز)=7200 بلوک/روز`
-
-هر بلوک اتریوم حداکثر`15x10^6 واحد گس/بلوک` مصرف میکند ([مطالب بیشتر درباره گس](/developers/docs/gas/)). با استفاده از این فرمول، میتوانیم قیمت متوسط گس را (در واحد gwei/gas) به منظور ایجاد تعادل با صدور در شبکه، با درنظر گرفتن صدور روزانه 1700 اتر حل کنیم:
-
-- `7200 بلوک/روز * 15x10^6 واحد گس/بلوک *`**`Y gwei/gas`**`* 1 اتر/10^9 gwei = 1700 اتر/روز`
-
-حل متغیر `Y`:
-
-- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (با گرد کردن به تنها دو رقم معنادار)
-
-روش دیگر برای بهتر شدن فرمول در مرحلۀ آخر محاسبات، جایگذاری متغیر `X` به جای عدد `1700` است که برابر است با میزان صدور روزانه اتر، و ادامه محاسبات به شکل زیر ساده میشود:
-
-- `Y = (X(10^3)/(7200 * 15)) = X/108`
-
-میتوانیم این فرمول را به صورت تابعی از `X` نیز به شرح زیر ساده کنیم:
-
-- تابع `f(X) = X/108` که در آن `X` نرخ صدور روزانه اتر است و تابع`f(X)` نشانگر gwei/گس مورد نیاز برای جبران کلیه اترهایی است که جدیداً در شبکه صادر شدهاند.
-
-بنابراین، به عنوان مثال اگر`X` (صدور روزانه اتر) به 1800 اتر در روز برسد که تابعی از اترهای سهمگذاریشده است،`(x) f` (یعنی gwei لازم برای جبران تمام صدور) حدود `17 gwei`خواهد بود (با استفاده از 2 رقم معنادار)
-
-## بیشتر بخوانید {#further-reading}
-
-- [ادغام](/roadmap/merge/)
-- [Ultrasound.money](https://ultrasound.money/) - _ داشبوردی برای تصویرسازی لحظهای صدور و سوزاندن اتر _
-- [نمودار صدور اتر](https://www.attestant.io/posts/charting-ethereum-issuance/) - _Jim McDonald 2020_
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/scaling/index.md b/public/content/translations/fa/11) Roadmap/roadmap/scaling/index.md
deleted file mode 100644
index 9d34b178fbd..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/scaling/index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: مقیاسپذیری اتریوم
-description: رولآپها تراکنشها را خارج از زنجیره گردآوری میکنند و هزینه را برای کاربر کاهش میدهند. با این حال، روشی که در حال حاضر رولآپها از داده استفاده میکنند، بسیار گران است و میزان ارزان بودن تراکنشها را محدود میکند. Proto-Danksharding مشکل را برطرف خواهد کرد.
-lang: fa
-image: /images/roadmap/roadmap-transactions.png
-alt: "نقشه راه اتریوم"
-template: roadmap
----
-
-اتریوم با استفاده از [لایه 2](/layer-2/#rollups) (به اسم رولآپ نیز شناخته میشود) به مقیاسپذیری دست مییابد، که تراکنشها را با هم ترکیب میکند و خروجی را به اتریوم ارسال میکند. با اینکه رولآپها تا هشت برابر ارزانتر از شبکه اصلی اتریوم هستند، امکان بهینهسازی بیشتر رولآپها در جهت کاهش هزینههای کاربران نهایی وجود دارد. علاوه بر این، رولآپها به برخی مؤلفههای متمرکز متکی هستند که توسعهدهندگان میتوانند با بلوغ رولآپها، آن را حذف کنند.
-
-
-
- - رولآپهای امروزی حدود 5 تا 20 برابر ارزانتر از لایه 1 اتریوم هستند
- - رولآپهای ZK به زودی کارمزدها را 40 تا 100 برابر ارزانتر خواهد کرد
- - تغییرات آتی اتریوم مقیاسپذیری را تقریباً بین 100 تا 1000 برابر افزایش خواهد داد
- - کاربران باید از تراکنشهایی با هزینه کمتر از 0.001 دلار بهرهمند شوند
-
-
-
-## ارزانتر کردن دادهها {#making-data-cheaper}
-
-رولآپها تعداد زیادی از تراکنشها را جمعآوری میکنند، اجرا میکنند و نتایج را به اتریوم ارسال میکنند. این کار اطلاعات زیادی تولید میکند که باید آشکارا در دسترس باشند تا هر کسی بتواند تراکنشها را برای خود انجام دهد و تأیید کند که اپراتور رولآپ صادق بوده است. اگر کسی عدم شفافیتی مشاهده کرد، میتواند یک چالش مطرح کند.
-
-### Proto-Danksharding {#proto-danksharding}
-
-داده رولآپ در گذشته بهطور دائم در اتریوم ذخیره شده است که البته گران است. بیش از 90 درصد از هزینه تراکنشهایی که کاربران در رولآپها پرداخت میکنند به دلیل ذخیرهسازی این دادهها پرداخت میشود. برای کاهش هزینههای تراکنش، میتوانیم اطلاعات را به یک حافظه موقت جدید از نوع «تودهای» انتقال دهیم. تودهها ارزانتر هستند چراکه دائمی نیستند؛ زمانی که دیگر مورد نیاز نباشند از اتریوم حذف میشوند. ذخیرهسازی داده رولآپ در درازمدت به عهده افرادی است که به آن نیاز دارند، مانند اپراتورهای رولآپ، صرافی ها، خدمات ایندکسینگ و غیره. افزودن تراکنشهای تودهای به اتریوم بخشی از ارتقای شناختهشده تحت عنوان «Proto-Danksharding» است.
-
-با پروتو-دنکشاردینگ، میتوان تعداد زیادی Blob به بلوکهای اتریوم اضافه کرد. این امر، یک افزایش قابل توجه (>100برابری) دیگر در مقیاسدهی به اتریوم و کاهش هزینههای تراکنش را ممکن می کند.
-
-### دانکشاردینگ {#danksharding}
-
-مرحله دوم گسترش داده blob پیچیده است زیرا به روشهای جدیدی برای بررسی وجود داده رولآپ در شبکه نیاز دارد و به [اعتبارسنجها](/glossary/#validator) متکی است که مسئولیتهای ساخت بلوک و مسئولیتهای پیشنهاد [بلوک](/glossary/#block) آن را از هم جدا میکنند. همچنین نیاز به روشی دارد که بهصورت رمزنگاری ثابت کند اعتبارسنجها زیرمجموعههای کوچکی از دادههای تودهای را تأیید کردهاند.
-
-این مرحلۀ دوم به عنوان [Danksharding](/roadmap/danksharding/) شناخته میشود. **احتمالاً چندین سال** تا اجرای کامل آن فاصله وجود دارد. Danksharding به پیشرفتهای دیگری مانند [تفکیک مسئولیت بلوکسازی و پیشنهاد بلوک](/roadmap/pbs) و طرحهای جدید شبکه متکی است که شبکه را قادر میسازد تا با نمونهبرداری تصادفی چند کیلوبایتی در لحظه، به طور مؤثر تأیید کند که دادهها در دسترس هستند. این روند تحت عنوان [نمونهگیری دسترسیپذیری به دادهها (DAS)](/developers/docs/data-availability) شناخته میشود.
-
-اطلاعات بیشتر در مورد Danksharding
-
-## غیرمتمرکزسازی رولآپها {#decentralizing-rollups}
-
-[رولآپها](/layer-2) اکنون نیز در حال افزایش مقیاسپذیری اتریوم هستند. یک [اکوسیستم غنی از پروژههای رولآپ](https://l2beat.com/scaling/tvl) به کاربران امکان میدهد تا تراکنشها را با سرعت بیشتر و هزینه ارزانتر، با طیف وسیعی از ضمانتهای امنیتی انجام دهند. با این حال، رولآپها با استفاده از توالیگرهای متمرکز (رایانههایی که تمام پردازش تراکنشها و گردآوری را قبل از ارسال به اتریوم انجام میدهند) بوت استرپ شدهاند. این امر در برابر سانسور آسیبپذیر است، زیرا اپراتورهای توالیگر میتوانند تحریم شوند، رشوه بگیرند یا بهشکل دیگری در معرض خطر قرار گیرند. همزمان، [رولآپها عملکرد متفاوتی](https://l2beat.com) در روش معتبر ساختن دادههای ورودی دارند. بهترین راه این است که "اثبات کننده ها" [اثبات تقلب](/glossary/#fraud-proof) یا اثبات اعتبار ارائه کنند، اما هنوز همه رولآپها وجود ندارد. حتی آن دسته از رولآپهایی که از اثبات اعتبار/تقلب استفاده میکنند، از مجموعه کوچکی از اثباتکنندههای شناختهشده استفاده میکنند. بنابراین، گام مهم بعدی در مقیاسپذیری اتریوم این است که مسئولیت اجرای توالیگرها و اثباتکنندهها بین افراد بیشتری توزیع شود.
-
-اطلاعات بیشتر درباره رولآپها
-
-## پیشرفت فعلی {#current-progress}
-
-پروتو-دنکشاردینگ اولین مورد از این موارد نقشه راه است که به عنوان بخشی از ارتقاء شبکه Cancun-Deneb ("Dencun") در مارس 2024 اجرا میشود. **دنکشاردینگ کامل احتمالاً چندین سال دیگر رخ میدهد**، زیرا متکی بر چندین مورد دیگر نقشه راه است که ابتدا باید تکمیل شوند. غیرمتمرکزسازی زیرساخت رولآپ احتمالاً یک فرآیند تدریجی است - رولآپهای متفاوت زیادی وجود دارند که در حال ساختن سیستمهایی با تفاوت جزئی هستند و به طور کامل با نرخهای متفاوت غیرمتمرکز میشوند.
-
-[اطلاعات بیشتر درباره ارتقا Dencun](/roadmap/dencun/)
-
-
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/security/index.md b/public/content/translations/fa/11) Roadmap/roadmap/security/index.md
deleted file mode 100644
index d1c808caedf..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/security/index.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: یک اتریوم ایمنتر
-description: اتریوم ایمنترین و غیرمتمرکزترین پلتفورم قرارداد هوشمند موجود است. با این حال، همچنان میتوان آن را بهبود بخشید تا اتریوم بتواند در آینده در برابر هر سطحی از حملات مقاوم باشد.
-lang: fa
-image: /images/roadmap/roadmap-security.png
-alt: "نقشه راه اتریوم"
-template: roadmap
----
-
-**اتریوم در حال حاضر یک پلت فرم بسیار امن** و غیرمتمرکز [قرارداد هوشمند](/glossary/#smart-contract) است. با این حال، همچنان میتوان آن را بهبود بخشید تا اتریوم بتواند در آینده در مقابل همه انواع حملات مقاوم باشد. اینها شامل تغییرات ظریف در نحوه برخورد [کاربرهای اتریوم](/glossary/#consensus-client) با [بلوکهای رقیب](/glossary/#block) و همچنین افزایش سرعتی است که شبکه بلوکها را ["نهایی"](/developers/docs/consensus-mechanisms/pos/#finality) میداند. (به این معنی که آنها را نمی توان بدون خسارات اقتصادی شدید به یک مهاجم تغییر داد).
-
-علاوه بر این بهبودهایی وجود دارد که سانسور کردن تراکنشها را با نابینا کردن ارائهدهندگان بلوک نسبت به محتوای واقعی بلوکهایشان و راههای جدید شناسایی در مواقعی که یک کلاینت سانسور اعمال میکند، سخت میکند. این پیشرفتها باهم، پروتکل [اثبات سهام](/glossary/#pos) را ارتقا میدهند تا کاربران - از افراد گرفته تا شرکتها - به برنامهها، دادهها و داراییهای خود در اتریوم اعتماد فوری داشته باشند.
-
-## برداشتها از سهامگذاری {#staking-withdrawals}
-
-ارتقاء از الگوریتم [اثبات کار](/glossary/#pow) به اثبات سهام با پیشگامان اتریوم شروع شد که اتر خود را در یک قرارداد سهام گذاری کردند. آن ETH برای محافظت از شبکه استفاده میشود. دومین بهروز رسانی در 12 آوریل 2023 انجام شده تا امکان برداشت اتر سهامگذاری شده را فراهم کند. از آن زمان اعتبارسنجها میتوانند آزادانه اتر را سهامگذاری یا برداشت کنند.
-
-خواندن در مورد برداشتها
-
-## دفاع در برابر حملات {#defending-against-attacks}
-
-پیشرفتهایی وجود دارد که میتوان در پروتکل اثبات سهام اتریوم ایجاد کرد. یکی به عنوان [مشاهده-ادغام](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) شناخته می شود که یک الگوریتم انتخاب [فورک](/glossary/#fork) ایمن تر است که انواع خاصی از حملات پیچیده را دشوارتر می کند.
-
-کاهش مدت زمانی که اتریوم برای [نهایی کردن](/glossary/#finality) بلوکها صرف میکند، تجربه کاربری بهتری را فراهم میکند و از حملات پیچیده "reorg" جلوگیری می کند، که در آن مهاجمان سعی می کنند بلوکهای اخیر را تغییر دهند تا سود استخراج کنند یا تراکنش های خاص را سانسور کنند. [**قطعیت شکاف منفرد (SSF)**](/roadmap/single-slot-finality/) **روشی برای به حداقل رساندن تاخیر در نهایی سازی** است. در حال حاضر بلوکهای 15 دقیقهای وجود دارد که مهاجم میتواند از نظر تئوری، اعتبارسنجهای دیگر را متقاعد کند که دوباره پیکربندی کنند. با SSF احتمال این کار به صفر میرسد. کاربران، از افراد عادی گرفته تا برنامهها و صرافیها، از تضمین سریع و عدم بازگشت تراکنشهایشان منتفع میشوند و از طرف دیگر شبکه با از بین بردن یک دسته کامل از حملات سود میبرد.
-
-خواندن در مورد قطعیت اسلات منفرد
-
-## دفاع در برابر سانسور {#defending-against-censorship}
-
-تمرکززدایی، از مافیابازی افراد یا گروههای کوچک [اعتبارسنج](/glossary/#validator) جلوگیری میکند. فناوریهای جدید سهامگذاری میتوانند به تضمین اعتبارسنجهای اتریوم کمک کنند که تا حد امکان غیرمتمرکز بماند و در عین حال از آنها در برابر اختلالات سختافزار، نرمافزار و شبکه دفاع کنند. این شامل نرمافزاری میشود که مسئولیتهای اعتبارسنج را در چندین [گره](/glossary/#node) به اشتراک میگذارد. این مفهوم با عنوان **تکنولوژی اعتبارسنجی توزیعشده (DVT)** شناخته میشود. [استخرهای سهامگذاری](/glossary/#staking-pool) برای استفاده از DVT تشویق میشوند زیرا به چندین رایانه اجازه میدهند به طور جمعی در اعتبارسنجی شرکت کنند که تزائد و تحمل خطا را اضافه میکند. همچنین به جای اینکه اپراتورهای منفرد چند اعتبارسنج را اجرا کنند، کلیدهای اعتبارسنجی را در چندین سیستم تقسیم میکند. این امر هماهنگی حملات به اتریوم را برای اپراتورهای متقلب دشوارتر میکند. به طور کلی، ایده این است که با اجرای اعتبارسنجی به صورت _جمعی_ به جای فردی، از مزایای امنیتی بهرهمند شویم.
-
-خواندن در مورد تکنولوژی اعتبارسنجی توزیعشده
-
-پیادهسازی **«جداسازی پیشنهاددهنده-سازنده» (PBS)** به شدت دفاعهای داخلی اتریوم را در برابر سانسور بهبود میبخشد. الگوریتم PBS به یک اعتبارسنج اجازه میدهد یک بلوک را ایجاد کند و به یک اعتبارسنج دیگر اجازه میدهد تا بلوک ایجادشده را در شبکه اتریوم منتشر کند. این تضمین میکند که عایدیهای حاصل از الگوریتمهای حرفهای بلوکساز با سود حداکثری به طور عادلانهتری در سراسر شبکه به اشتراک گذاشته شوند تا **مانع از متمرکز شدن بلندمدت سهامگذاری** توسط آن دسته از سهامگذاران سازمانی شود که بهترین عملکرد را دارند. پیشنهاددهنده بلوک میتواند سودآورترین بلوک را که توسط بازار سازندگان بلوک به آنها ارائه میشود، انتخاب کند. برای سانسور، یک پیشنهاددهنده بلوک اغلب باید بلوک کمسودتری را انتخاب کند، که از نظر **اقتصادی غیرمنطقی و همچنین برای بقیه اعتبارسنجها** روی شبکه، آشکار خواهد بود.
-
-افزونههای بالقوهای برای PBS، مانند تراکنشهای رمزگذاریشده و فهرستهای بایگانی، وجود دارد که میتواند مقاومت اتریوم در برابر سانسور را بیشتر بهبود بخشد. این روشها تراکنشهای واقعی موجود در بلوکها را از سازنده و پیشنهاددهنده بلوک پنهان میکند.
-
-خواندن در مورد جداسازی پیشنهاددهنده-سازنده
-
-## محافظت از اعتبارسنجها {#protecting-validators}
-
-این امکان وجود دارد که یک مهاجم پیشرفته بتواند اعتبار سنجهای آینده را شناسایی کند و آنها را اسپم کند تا آنها را از پیشنهاد دادن بلوکها جلوگیری کند؛ این به عنوان **حمله حذف خدمات (DoS)** شناخته میشود. پیادهسازی [**«انتخاب مخفیانه رهبر» (SLE)**](/roadmap/secret-leader-election) با جلوگیری از شناسایی زودهنگام پیشنهاددهندههای بلوک، از شبکه در برابر این نوع حمله محافظت خواهد کرد. این کار با بهم ریختن مداوم مجموعهای از تعهدات رمزنگاریشده که نشاندهنده پیشنهاددهندگان بلوک نامزد است و از ترتیبشان استفاده میکند تا اعتبارسنج انتخابشده را تعیین کند، به گونهای که فقط خود اعتبارسنجها از قبل ترتیبشان را بدانند.
-
-خواندن در مورد انتخاب مخفیانه رهبر
-
-## پیشرفت فعلی {#current-progress}
-
-**ارتقاهای امنیتی در نقشه راه در مراحل پیشرفتهای از تحقیقات است**، اما تا مدتی انتظار نمی رود اجرا شوند. مراحل بعدی برای view-merge، PBS، SSF و SLE نهایی کردن ویژگیها و شروع ساخت نمونههای اولیه آنها است.
diff --git a/public/content/translations/fa/11) Roadmap/roadmap/user-experience/index.md b/public/content/translations/fa/11) Roadmap/roadmap/user-experience/index.md
deleted file mode 100644
index 24880bdf3cc..00000000000
--- a/public/content/translations/fa/11) Roadmap/roadmap/user-experience/index.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: ارتقای تجربه کاربری
-description: همچنان استفاده از اتریوم برای اکثر افراد بیش از حد پیچیده است. اتریوم باید برای تشویق پذیرش انبوه، موانع ورودش را به شدت کاهش دهد - کاربران باید از مزایای دسترسی غیرمتمرکز، بدون نیاز به مجوز و مقاوم در برابر سانسور به اتریوم بهرهمند شوند اما باید به اندازه استفاده از یک برنامه سنتی web2 بدون اصطکاک باشد.
-lang: fa
-image: /images/roadmap/roadmap-ux.png
-alt: "نقشه راه اتریوم"
-template: roadmap
----
-
-**استفاده از اتریوم باید ساده شود**؛ از مدیریت [کلیدها](/glossary/#key) و [کیف پول](/glossary/#wallet) تا شروع تراکنش ها. برای تسهیل پذیرش عمومی، اتریوم باید سهولت استفاده را به شدت افزایش دهد و به کاربران اجازه دهد با استفاده از برنامههای [Web2](/glossary/#web2) دسترسی بینیاز به مجوز طرف ثالث و مقاوم در برابر سانسور به اتریوم را تجربه کنند.
-
-## فراتر از کلمات بازیابی {#no-more-seed-phrases}
-
-حسابهای اتریوم توسط یک جفت کلید برای تایید اصالت حسابها (کلید عمومی) و امضا زدن روی پیامها (کلید خصوصی)، محافظت میشوند. کلید خصوصی مثل شاهکلید است. این کلید به شما اجازه میدهد به یک حساب اتریوم دسترسی کامل داشته باشید. این یک روش مجزا است برای کسانی که بیشتر با بانکها و برنامههای Web2 که حسابها را از طرف یک کاربر مدیریت میکنند آشنا هستند. برای اینکه اتریوم بدون نیاز به اشخاص ثالث متمرکز به پذیرش انبوه برسد، باید راهی ساده و بدون اصطکاک برای کاربر وجود داشته باشد تا بتواند از داراییهای خود نگهداری کند و کنترل دادههایشان را بدون نیاز به آشنایی با رمزنگاری کلید خصوصی-عمومی و مکانیزم مدیریت کلید، در دست داشته باشد.
-
-راهکار این امر، استفاده از کیف پول های [قرارداد هوشمند](/glossary/#smart-contract) برای تعامل با اتریوم است. کیف پولهای قرارداد هوشمند راههایی برای محافظت از حسابها در صورت گم یا دزدیده شدن ایجاد میکند، بستر مناسب را برای تشخیص و دفاع بهتر در مقابل کلاهبرداری فراهم میکند و به کیف پولها این امکان را میدهد تا عملکرد جدیدی داشته باشند. اگرچه در حال حاضر کیف پولهای قرارداد هوشمند وجود دارند، اما ساخت آنها دشوار است. چراکه پروتکل اتریوم باید پشتیانی بهتری برای آن فراهم کند. این پشتیبانی تکمیلی تحت عنوان انتزاع حساب شناخته میشود.
-
-اطلاعات بیشتر در مورد انتزاع حساب
-
-## گرهها برای همه
-
-کاربرانی که [گرهها](/glossary/#node) را اجرا میکنند لازم نیست به طرفهای ثالث برای ارائه دادهها به آنها اعتماد کنند و میتوانند سریع، خصوصی و بدون مجوز با [بلاکچین](/glossary/#blockchain) اتریوم تعامل داشته باشند. با این وجود، در حال حاضر اجرای یک گره به دانش فنی و فضای دیسک چشمگیر نیاز دارد، به عبارتی بسیاری از افراد مجبورند در عوض به واسطهها اعتماد کنند.
-
-ارتقاهایی وجود دارد که اجرای گرهها را بسیار سادهتر و میزان منابع لازم را به شدت کمتر خواهد کرد. شیوه ذخیرهسازی دادهها در جهت استفاده یک ساختار بهینهتر از فضا تغییر میکند که به عنوان **درخت ورکل** شناخته میشود. علاوه بر این، با [بیحالتی](/roadmap/statelessness) یا [انقضای دادهها](/roadmap/statelessness/#data-expiry)، گرههای اتریوم دیگر نیازی به ذخیرهسازی یک کپی از کل دادههای حالت اتریوم نخواهند داشت که نیاز به فضای هارد دیسک را به شدت کاهش میدهد. [گرههای سبک](/developers/docs/nodes-and-clients/light-clients/) مزایای زیادی از اجرای یک گره کامل ارائه میدهند اما میتوانند به آسانی روی موبایلها یا داخل برنامههای مرورگر ساده اجرا شوند.
-
-خواندن درباره درختان ورکل
-
-با ابن بروزرسانیها موانع راهاندازی یک گره به صفر میرسد. کاربران بدون نیاز به فضای دیسک بالا یا پردازندههای قدرتمند، روی کامپیوتر یا تلفن همراه خود از دسترسی ایمن و بدون مجوز به اتریوم بهرهمند خواهند شد و مجبور نیستند هنگام استفاده از برنامهها برای دسترسی به دادهها یا شبکه به اشخاص ثالث تکیه کنند.
-
-## پیشرفت فعلی {#current-progress}
-
-کیف پولهای قرارداد هوشمند درحال حاضر در دسترس هستند، ولی ارتقا و بهروزرسانیهای بیشتری لازم است تا آنها را تا حد ممکن غیرمتمرکز و بینیاز به مجوز کند. EIP-4337 یک پیشنهاد کامل است که نیاز به هیچ تغییری در پروتکل اتریوم ندارد. قرارداد هوشمند اصلی مورد نیاز برای پیشنهاد EIP-4337 **در مارس 2023 پیادهسازی شد**.
-
-**بی حالتی کامل هنوز در مرحله تحقیق است** و احتمالا چندین سال تا اجرای آن فاصله دارد. چندین نقطهعطف از جمله انقضای دادهها، در مسیر تحقق بیحالتی کامل وجود دارد که ممکن است زودتر پیادهسازی شود. بخشهای دیگر نقشه راه مثل [درختان ورکل](/roadmap/verkle-trees/) و [جداسازی پیشنهاددهندگان-ایجادکنندگان](/roadmap/pbs/) باید ابتدا تکمیل شوند.
-
-در حال حاضر شبکههای تست درخت ورکل راجرا شدهاند و مرحله بعدی اجرای کلاینتهای مبتنی بر درخت ورکل در شبکههای آزمایشی خصوصی و پس از آن در شبکههای تست عمومی است. میتوانید با بهکارگیری قراردادها در شبکههای تست یا اجرای کلاینتهای شبکه تست، پیشرفت آن را سرعت دهید.
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/account-abstraction/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/account-abstraction/index.md
deleted file mode 100644
index 58570d277d3..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/account-abstraction/index.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: انتزاع حساب
-description: مروری بر برنامههای اتریوم برای سادهتر و ایمنتر کردن حسابهای کاربری
-lang: fa
-summaryPoints:
- - انتزاع حساب باعث میشود ساخت کیف پول قراردادهای هوشمند بسیار سادهتر گردد
- - کیف پولهای قرارداد هوشمند مدیریت دسترسی به حسابهای اتریوم را بسیار آسانتر میکند
- - کلیدهای گمشده و لورفته را میتوان با استفاده از چندین نسخه پشتیبان بازیابی کرد
----
-
-# انتزاع حساب {#account-abstraction}
-
-کاربرانی که در تعامل با شبکۀ اتریوم هستند از **[حسابهای تحت مالکیت خارجی (EOA)](/glossary/#eoa)** استفاده میکنند. این تنها راه شروع یک تراکنش یا اجرای یک قرارداد هوشمند است. البته این امر نحوۀ تعامل کاربران با شبکۀ اتریوم را محدود میکند. برای مثال، انجام چندین تراکنش در یک آن توسط حسابهای EOA برای کاربران دشوار بوده و نیازمند آن است که کاربر همیشه به منظور تأمین گس یا همان کارمزد شبکه، موجودی ETH کافی در حسابش داشته باشد.
-
-انتزاع حساب یک راهحل برای این دست از مشکلات بوده که به کاربران اجازه میدهد امنیت بیشتر و تجربۀ کاربری بهتری را به طور منعطف برای حسابهایشان برنامهریزی و وارد آن کنند. این هدف میتواند با [ارتقای EOAها](https://eips.ethereum.org/EIPS/eip-3074) تحقق یابد تا قابلیت کنترل توسط قراردادهای هوشمند را داشته باشند، یا با [ارتقای قراردادهای هوشمند](https://eips.ethereum.org/EIPS/eip-2938) تا بتوانند تراکنشها را انجام دهند. تحقق هر دو مورد ذکرشده در بالا نیازمند تغییراتی در پروتکل اتریوم است. همچنین مسیر سومی نیز وجود دارد که شامل اضافه نمودن یک [سیستم تراکنشی جداگانه ثانویه](https://eips.ethereum.org/EIPS/eip-4337) میشود که بهصورت موازی با پروتکل موجود اجرا میگردد. صرفنظر از مسیر انتخابی، در کل نتیجۀ این عمل دسترسی به شبکۀ اتریوم از طریق کیف پولهای قرارداد هوشمند است که یا به صورت بومی به عنوان بخشی از پروتکل موجود پشتیبانی میشوند یا از طریق اضافه نمودن یک شبکۀ تراکنشی جدید.
-
-کیفپولهای قرارداد هوشمند مزایای بسیاری را برای کاربر فراهم میکنند، ازجمله:
-
-- تعریف کردن قوانین امنیتی منعطف مختص خود
-- بازیابی حسابتان در صورت گم کردن کلیدها
-- اشتراکگذاری امنیت حسابتان با دستگاهها یا افراد قابل اعتماد
-- پرداخت هزینۀ گس برای شخصی دیگر، یا درخواست از شخصی دیگر برای پرداخت هزینۀ گس شما
-- انجام دستهجمعی چندین تراکنش به صورت همزمان (مثلاً تأیید و اجرای یک مبادله یا سواپ به صورت یکجا)
-- ایجاد فرصتهای بیشتر برای توسعهدهندگان کیف پول یا برنامههای dapp به منظور ایجاد نوآوری در تجربههای کاربری
-
-امروزه این مزایا به صورت بومی پشتیبانی نمیشوند به این دلیل که تنها حسابهای تحت مالکیت خارجی ([EOAها](/glossary/#eoa)) میتوانند آغازگر تراکنشها باشند. EOAها به بیان ساده همان جفت کلیدهای عمومی-خصوصی هستند. عملکرد آنها به شرح زیر است:
-
-- اگر کلید خصوصی دارید میتوانید _هر کاری_ را در چارچوب قوانین ماشین مجازی اتریوم (EVM) انجام دهید
-- اگر کلید خصوصی ندارید _هیچ کاری_ نمیتوانید انجام دهید.
-
-اگر کلیدهای خود را گم کنید قابل بازیابی نیستند و کلیدهای دزدیدهشده به سارقان امکان دسترسی آنی به کلیه وجوه داخل حساب را میدهند.
-
-کیف پولهای قرارداد هوشمند راهحل مناسبی برای این قبیل مشکلات هستند، ولی امروزه برنامهنویسی آنها دشوار است چون در نهایت هر منطقی که پیادهسازی میکنند باید به مجموعهای از تراکنشهای EOA ترجمه شود تا بتواند توسط شبکه اتریوم پردازش شود. با انتزاع حساب، قراردادهای هوشمند میتوانند خودشان شروعکنندۀ تراکنشها باشند و در نتیجه هر منطقی که کاربران خواهان پیادهسازی آن هستند، میتواند در خود کیف پول قرارداد هوشمند کدگذاری شده و بر روی شبکۀ اتریوم اجرا گردد.
-
-به طورکلی، انتزاع حساب پشتیبانی از کیف پولهای قرارداد هوشمند را ارتقا میبخشد و ساخت آنها را آسانتر و کاربریشان را ایمنتر میکند. در نهایت، با وجود انتزاع حساب، کاربران میتوانند بدون آگاهی از فناوری بهکاررفته در زیرساختهای شبکه یا توجه به آن، از تمامی مزایای موجود در شبکۀ اتریوم بهره ببرند.
-
-## فراتر از کلمات بازیابی {#beyond-seed-phrases}
-
-امنیت حسابهای امروزی با استفاده از کلیدهای خصوصی که از محاسبۀ کلمات بازیابی بدست میآیند تأمین میشود. هر فردی که به کلمات بازیابی دسترسی داشته باشد میتواند به آسانی کلید خصوصیِ محافظ حساب کاربری را بدست آورده و به تمامی داراییِ موجود در حساب دسترسی پیدا کند. اگر کلید خصوصی و کلمات بازیابی گم شوند، هرگز قابل بازیابی نخواهند بود و سرمایۀ تحت کنترل اینها برای همیشه فریز میشود. محافظت از این کلمات بازیابی برای هر فردی، حتی کاربران باتجربه، ناخوشایند و آزاردهنده است، و حملات فیشینگ به این کلمات جزء معمولترین روشهای کلاهبرداری از کاربران است.
-
-انتزاع حساب این مشکل را با استفاده از قراردادهای هوشمند برای نگهداری از داراییها و اعطای مجوز تراکنشها حل خواهد کرد. سپس، این قراردادهای هوشمند را میتوان توسط یک منطق سفارشی با هدف ایمنسازی و مناسبسازی با نیاز کاربران از نو آراسته نمود. به طور کلی، شما همچنان برای کنترلِ دسترسی به حسابتان از کلیدهای خصوصی استفاده میکنید، اما با این تفاوت که این کار توسط نوعی شبکههای ایمنی که استفاده و مدیریت آنها را آسانتر و ایمنتر میکند انجام میگیرد.
-
-برای مثال، کلیدهای پشتیبان میتوانند به کیفپول اضافه شوند در نتیجه اگر شما کلیدهای اصلی خود را گم کردید یا به طور اتفاقی در معرض دید سایرین قرار دادید، یک کلید جدید و ایمن میتواند با مجوز و تأیید کلیدهای پشتیبان جایگزین آن شود. شما ممکن است ایمنسازی هرکدام از کلیدها را به روشی دیگر انجام دهید یا آنها را بین چندین محافظ قابل اعتماد تقسیم کنید. این کار باعث میشود کنترل کامل وجوهتان برای سارق سختتر شود. به همین ترتیب، شما میتوانید قوانینی را به کیف پولتان اضافه کنید تا در صورت به خطر افتادن کلید اصلی، تأثیرات منفی ناشی از آن را کاهش دهد، برای مثال ممکن است اجازه دهید تراکنشهای کمارزش با تنها یک امضا تأیید شوند در حالی که تراکنشهایی با ارزش بالاتر نیاز به تأیید چندین امضاکننده داشته باشند. راههای دیگری نیز وجود دارد که کیف پولهای هوشمند میتوانند به شما در خنثی کردن سرقتها کمک کنند، برای مثال ایجاد یک لیست سفید میتواند برای مسدود نمودن هر تراکنش استفاده شود مگر اینکه آدرس تراکنش قابل اعتماد بوده و یا توسط چندین کلید از پیش تأییدشده، اعتبار آن ثابت گردد.
-
-### مثالهایی از منطق امنیت که میتواند بر روی کیف پول قرارداد هوشمند ساخته شود:
-
-- **مجوز چند امضایی**: شما میتوانید اطلاعات امنیتی مجوز خود را بین چندین فرد یا دستگاه مورد اعتماد به اشتراک بگذارید. قراردادها را میتوان به گونهای پیکربندی کرد که برای تراکنشهایی با ارزشی بیشتر از حد تعیینشده، نیاز به تأیید نسبت معینی (مثلاً ۳ نفر از ۵ نفر) از طرفهای مورد اعتماد باشد. برای مثال، بسیاری از تراکنشهای دارای ارزش بالا ممکن است نیاز به تأیید از روی دستگاه موبایل و کیفپول سختافزاری یا حتی امضاهایی از حسابهای توزیعشده بین اعضای معتمد خانواده داشته باشند.
-- **حسابهای فریزشده**: اگر دستگاه گم شد یا در معرض خطر قرار گرفت حساب موردنظر را میتوان از روی دستگاه تأییدشدۀ دیگری قفل کرد و بدین ترتیب از داراییهای کاربر محافظت نمود.
-- **بازیابی حساب**: دستگاه را گم کرده یا گذرواژه را فراموش کردهاید؟ در پارادایم فعلی، این موضوع بدین معناست که دارایی شما برای همیشه میتواند فریز شود. با استفاده از کیف پول قرارداد هوشمند شما میتوانید لیست سفید حسابهایی را ایجاد کنید که این حسابها میتوانند دستگاههای جدیدی را تأیید و دسترسی به آنها را برایتان بازنشانی کنند.
-- **تعیین محدودیت تراکنش**: آستانههای روزانهای برای مقدار ارزشی که میتواند در روز/هفته/ماه از حساب انتقال یابد مشخص کنید. به عبارتی، اگر یک مهاجم به نحوی به حساب شما دسترسی پیدا کرد، نمیتواند به یکباره تمامی دارایی شما را بیرون بکشد و شما این فرصت را داشته باشید تا دسترسی به حسابتان را فریز و آن را مجدداً بازنشانی کنید.
-- **ایجاد لیست سفید**: با این کار، انجام تراکنشها را فقط به آدرسهای خاصی که میدانید امن است مجاز کنید. به عبارتی، _حتی اگر_ کلید خصوصی دزدیده شود، مهاجم نتواند وجوهتان را به حسابهای مقصدی که خارج از لیست سفید هستند ارسال کند. این لیستهای سفید نیاز به چندین امضا برای ایجاد هرگونه تغییر دارند برای همین مهاجم یا هکر نمیتواند آدرسهای خودش را به این لیست اضافه کند مگر اینکه به چندین کلید پشتیبان شما دسترسی داشته باشد.
-
-## تجربه کاربری بهتر {#better-user-experience}
-
-انتزاع حساب **به طور کلی تجربۀ کاربری بهتر** و همچنین **بهبود در امنیت شبکه** را برای کاربرانش فراهم میکند زیرا پشتیبانی لازم را برای کیف پولهای قرارداد هوشمند در سطح پروتکل میافزاید. مهمترین دلیل برای ایجاد چنین پشتیبانی کاملی در سرتاسر شبکه این است که این ویژگی به توسعهدهندگان قراردادهای هوشمند، کیف پولها و برنامههای کاربردی، آزادی عمل بیشتری برای نوآوری در زمینه تجربه کاربری به روشهای جدید و خلاقانه ارائه میدهد. بعضی از پیشرفتهای مشهودی که همراه با انتزاع حساب بدست میآیند دستهبندی معاملات و تراکنشها برای حصول سرعت و کارایی است. برای مثال، یک مبادلۀ ساده فرآیندی است که باید با یک کلیک انجام گیرد، ولی امروزه قبل از اینکه مبادله اجرا شود، به منظور تأیید پرداخت و مصرف توکنها در این مبادله، به امضای چندین تراکنش نیاز است. انتزاع حساب این اصطکاک را با دستهبندی تراکنشها در یک مجموعه برطرف میکند. علاوهبراین، تراکنش دستهبندیشده میتواند به طور دقیق ارزش واقعی و درستی از توکنهایی را که برای هر معامله نیاز هست تأیید کرده و پس از تکمیل شدن معامله برای امنیت بیشتر، تمامی تأییدیهها را لغو کند.
-
-مدیریت گس نیز با انتزاع حساب بهشدت بهبود مییابد. در واقع تنها برنامهها نیستند که میتوانند هزینۀ کارمزد گس کاربرانشان را بپردازند، بلکه کارمزد گس میتواند توسط به واحد توکنهایی غیر از اتریوم نیز پرداخت شود؛ این کار سبب میگردد که کاربران برای تأمین تراکنشها، لازم نباشد همیشه میزان معینی از موجودی اتریوم در حسابهایشان داشته باشند. این عمل از طریق مبادلۀ توکنهای کاربران با اتریوم در داخل یک قرارداد هوشمند و سپس استفاده از همان اتریوم برای پرداخت گس شبکه انجام میپذیرد.
-
-
-
-مدیریت گاز یکی از اصطکاکهای اصلی برای کاربران اتریوم است، عمدتاً به این دلیل که اتریوم تنها دارایی است که میتوان برای پرداخت تراکنشها از آن استفاده کرد. تصور کنید یک کیف پول با موجودی USDC دارید، اما بدون اتریوم. شما نمیتوانید آن توکنهای USDC را مبادله کنید زیرا نمیتوانید گس بپردازید. شما USDC را با اتریوم نیز نمیتوانید مبادله کنید، زیرا خود این کار هزینه گس دارد. برای حل مشکل باید اتریوم بیشتری را از یک صرافی یا آدرس دیگری به حساب خود ارسال کنید. با کیف پولهای قرارداد هوشمند، میتوانید بهجای آن، گس را به واحد USDC پرداخت کنید و حساب خود را آزاد کنید. دیگر لازم نیست موجودی اتریوم را در همه حسابهای خود نگه دارید.
-
-انتزاع حساب همچنین به توسعهدهندگان dapp اجازه میدهد تا در مدیریت گس خلاق باشند. به عنوان مثال، ممکن است بتوانید هر ماه یک کارمزد ثابت به DEX مورد علاقه خود برای تراکنشهای نامحدود پرداخت کنید. Dappها ممکن است به عنوان پاداشی برای استفاده از پلتفورم خود یا به عنوان پیشنهاد ورود به سیستم، پیشنهاد دهند که تمام هزینههای گس را بهجای شما پرداخت کنند. زمانی که کیف پولهای قرارداد هوشمند در سطح پروتکل پشتیبانی میشوند، نوآوری در مورد گس برای توسعهدهندگان بسیار آسانتر خواهد بود.
-
-
-
-تعامل یا تبادلهای اطلاعاتی قابل اعتماد میتوانند به طور بالقوهای در ایجاد تحول در رابطه با تجربههای کاربری مؤثر باشند، علیالخصوص برای برنامههایی مانند بازیها که تعداد زیادی از تراکنشهای کوچک ممکن است لازم باشد در یک بازه زمانی کوتاه تأیید شوند. تأیید هر تراکنش به صورت تکی میتواند تجربۀ بازی را از بین ببرد ولی تأیید آن به صورت دائمی هم ایمن نیست. کیف پول قرارداد هوشمند میتواند تراکنشهای مشخصی را برای یک مدتزمان ثابت، تا یک مقدار مشخص یا فقط برای آدرسی خاص تأیید کند.
-
-همچنین جالب است بدانید که چگونه خریدها با کمک انتزاع حساب میتوانند تغییر کنند. امروزه هر تراکنش باید از طریق کیف پولی که از قبل با مقدار کافی و صحیح از توکن لازم تأمین شده است، تأیید و اجرا شود. با انتزاع حساب، این تجربه میتواند بیشتر شبیه به خریدهای آنلاین گردد به گونهای که کاربر میتواند سبد خرید را با آیتمهای مختلفی پر کرده و تنها با یکبار کلیک، تمامی آیتمها را یکجا با کل منطق لازم که توسط قرارداد، و نه کاربر، مدیریت میشود خریداری کند.
-
-اینها فقط چند نمونه از چگونگی ارتقای تجربۀ کاربری توسط انتزاع حساب است، اما قطعاً کاربردهای انتزاع حساب بسیار بیشتر از حد تصور ماست. انتزاع حساب توسعهدهندگان را از محدودیتهای EOAهای امروزی رهایی میبخشد، و به آنها اجازه میدهد تا ویژگیها و جنبههای خوب و مفید Web2 را بدون قربانی کردن حضانت شخصی به Web3 بیاورند و به طور خلاقانهای تجربیات کاربری جدید و نوآورانهای را ابداع کنند.
-
-## انتزاع حساب چگونه اجرا خواهد شد؟ {#how-will-aa-be-implemented}
-
-کیف پولهای قرارداد هوشمند امروزه وجود دارند، اما اجرای آنها چالشبرانگیز است زیرا EVM از آنها پشتیبانی نمیکند. در عوض، آنها بر بستهبندی کدهای نسبتاً پیچیده حول تراکنشهای استاندارد اتریوم متکی هستند. اتریوم میتواند با دادن اجازۀ شروع تراکنشها به قراردادهای هوشمند، این امر را تغییر دهد و منطق لازم را در قراردادهای هوشمند اتریوم به جای خارج از زنجیره انجام دهد. قرار دادن منطق در قراردادهای هوشمند غیرمتمرکزسازی اتریوم را نیز افزایش میدهد، زیرا نیاز به «راهانداز»هایی را که توسط توسعهدهندگان کیف پول برای ترجمه پیامهای امضاشده توسط کاربر به تراکنشهای معمولی اتریوم اجرا میشوند از بین میبرد.
-
-
-
-EIP-2771 مفهوم تراکنشهای متا را معرفی میکند که به اشخاص ثالث اجازه میدهد تا هزینههای گس کاربر را بدون ایجاد تغییراتی در پروتکل اتریوم بپردازند. ایده پشت این قضیه این است که تراکنشهای امضاشده توسط یک کاربر به یک قرارداد «حامل» (فورواردر) ارسال میشود. حامل یک نهاد قابل اعتماد است که قبل از ارسال آنها به رله گس، اعتبار معاملات را تأیید میکند. این کار خارج از زنجیره انجام میشود و نیازی به پرداخت گس نیست. رله گس تراکنش را به یک قرارداد «گیرنده» منتقل میکند و گس لازم را برای اجرای تراکنش در اتریوم میپردازد. تراکنش در صورتی انجام میشود که «حامل» را «گیرنده» بشناسد و مورد اعتماد او باشد. این مدل اجرای تراکنشهای بدون گس را برای توسعهدهندگان آسان میکند.
-
-
-
-
-
-EIP-4337 اولین گام به سمت پشتیبانی بومی کیف پول قرارداد هوشمند به روشی غیرمتمرکز بدون نیاز به تغییر در پروتکل اتریوم است. به جای اصلاح لایه اجماع برای پشتیبانی از کیف پول قراردادهای هوشمند، یک سیستم جدید به طور جداگانه به پروتکل شایعه تراکنش عادی اضافه میشود. این سیستم سطح بالاتر حول یک شیء جدید به نام UserOperation
ساخته شده است که اقدامات یک کاربر را همراه با امضاهای مربوطه بستهبندی میکند. این اشیاء UserOperation
سپس در یک «استخر حافظه» اختصاصی پخش میشوند و در آنجا، اعتبارسنجها میتوانند آنها را در یک «تراکنش بسته» جمعآوری کنند. تراکنش باندل نشاندهنده دنبالهای از بسیاری از عملیات UserOperations
است و میتواند مانند یک تراکنش عادی در بلوکهای اتریوم گنجانده شود و توسط اعتبارسنجها با استفاده از یک مدل مشابه برای انتخاب حداکثرسازی هزینه انتخاب میشود.
-
-نحوه کار کیف پولها نیز تحت EIP-4337 تغییر میکند. به جای اینکه هر کیف پولی منطق ایمنی رایج اما پیچیده را مجدداً پیادهسازی کند، این عملکردها به یک قرارداد کیف پول جهانی بهنام "نقطه ورود" برونسپاری میشوند. این کار عملیاتی مانند پرداخت هزینه و اجرای کد EVM را انجام میدهد تا توسعهدهندگان کیف پول بتوانند بر ارائه تجربیات عالی برای کاربر تمرکز کنند.
-
-توجه داشته باشید که قرارداد نقطه ورودی EIP 4337 در تاریخ 1 مارس 2023 در «شبکه اصلی اتریوم» بکار گرفته شد. میتوانید قرارداد را در Etherscan مشاهده کنید.
-
-
-
-
-
-هدف EIP-2938 بهروزرسانی پروتکل اتریوم با معرفی یک نوع تراکنش جدید بهنام AA_TX_TYPE
است که شامل سه فیلد روبرو میشود: nonce
، هدف
و دادهها
، که در آن nonce
یک شمارنده تراکنش است، هدف
آدرس قرارداد نقطه ورودی و دادهها
بایتکد EVM است. برای اجرای این تراکنشها، دو دستورالعمل جدید (معروف به کدهای عملیاتی) باید به EVM اضافه شوند: NONCE
و PAYGAS
. کد عملیاتی NONCE
دنباله تراکنش را دنبال میکند و PAYGAS
گس مورد نیاز برای اجرای تراکنش را از موجودی قرارداد محاسبه و برداشت میکند. این ویژگیهای جدید به اتریوم اجازه میدهد تا از کیف پولهای قرارداد هوشمند بهصورت بومی پشتیبانی کند، زیرا زیرساختهای لازم در پروتکل اتریوم تعبیه شده است.
-
-توجه داشته باشید که EIP-2938 درحال حاضر فعال نیست. جامعه درحال حاضر از EIP-4337 استقبال میکند زیرا نیازی به تغییر در پروتکل ندارد.
-
-
-
-
-
-هدف EIP-3074 بهروزرسانی حسابهای تحت مالکیت خارجی اتریوم است بدینصورت که به آنها اجازه میدهد کنترل را به یک قرارداد هوشمند واگذار کنند. این بدان معناست که منطق قرارداد هوشمند میتواند تراکنشهایی با منشاء یک EOA را تأیید کند. این امکان ویژگیهایی مانند تراکنشهای حامی گس و دستهای را فراهم میکند. برای اینکه این کار عمل کند، باید دو کد عملیاتی جدید به EVM اضافه شود: AUTH
و AUTHCALL
. با EIP-3074، مزایای کیف پول قرارداد هوشمند بدون نیاز به قرارداد در دسترس قرار میگیرد - در عوض، یک نوع خاص از قراردادِ بدون حالت، غیرقابل اعتماد و غیرقابل ارتقا، معروف به «Invoker»، تراکنشها را مدیریت میکند.
-
-توجه داشته باشید که EIP-3074 درحال حاضر فعال نیست. جامعه درحال حاضر از EIP-4337 استقبال میکند زیرا نیازی به تغییر در پروتکل ندارد.
-
-
-
-## پیشرفت فعلی {#current-progress}
-
-کیف پولهای قرارداد هوشمند درحال حاضر در دسترس هستند، ولی ارتقا و بهروزرسانیهای بیشتری لازم است تا آنها را تا حد ممکن غیرمتمرکز و بینیاز به مجوز کند. EIP-4337 یک پروپوزال کامل است که نیاز به اعمال هیچگونه تغییری بر روی پروتکل اتریوم نیست، بنابراین این امکان هست که این پروپوزال سریعتر اجرا گردد. با این حال، ارتقاهایی که پروتکل اتریوم را تغییر میدهند در حال حاضر در روند توسعۀ فعال نیستند، بنابراین اعمال تغییرات بر روی آنها ممکن است بسیار بیشتر طول بکشد. همچنین این امکان وجود دارد که انتزاع حسابی مناسب و کافی توسط EIP-4337 بدست آید و دیگر نیازی به اعمال تغییرات بر روی پروتکل نباشد.
-
-## بیشتر بخوانید {#further-reading}
-
-- [erc4337.io](https://www.erc4337.io/)
-- [گفتگو پانل انتزاع حساب از Devcon Bogota](https://www.youtube.com/watch?app=desktop&v=WsZBymiyT-8)
-- [«چرا انتزاع حساب یک تغییردهنده بازی برای dappها است» از Devcon Bogota](https://www.youtube.com/watch?v=OwppworJGzs)
-- [«انتزاع حساب ELI5» از Devcon Bogota](https://www.youtube.com/watch?v=QuYZWJj65AY)
-- [یادداشتهای «راهی به انتزاع حساب» از ویتالیک](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists)
-- [پست وبلاگ Vitalik با موضوع کیف پولهای بازیابی اجتماعی](https://vitalik.eth.limo/general/2021/01/11/recovery.html)
-- [یادداشتهای EIP-2938](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938)
-- [اسناد EIP-2938](https://eips.ethereum.org/EIPS/eip-2938)
-- [یادداشتهای EIP-4337](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a)
-- [اسناد EIP-4337](https://eips.ethereum.org/EIPS/eip-4337)
-- [اسناد EIP-2771](https://eips.ethereum.org/EIPS/eip-2771)
-- [«مبانی انتزاع حساب» -- قسمت اول انتزاع حساب چیست](https://www.alchemy.com/blog/account-abstraction)
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/danksharding/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/danksharding/index.md
deleted file mode 100644
index 63d136e8027..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/danksharding/index.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: دانکشاردینگ
-description: با دو ارتقای متوالی برای مقیاسبندی اتریوم تحت عنوان Proto-Danksharding و Danksharding آشنا شوید.
-lang: fa
-summaryPoints:
- - Danksharding یک ارتقای چندمرحلهای برای بهبود مقیاسپذیری و ظرفیت اتریوم است.
- - مرحله اول، Proto-Danksharding، تودههای داده را به بلوکها اضافه میکند
- - تودههای داده راه ارزانتری را برای جمعآوری دادهها جهت ارسال آنها به اتریوم ارائه میکنند و این هزینهها میتواند در قالب مبلغی کمتر بابت کارمزد تراکنشها به کاربران منتقل شود.
- - بعدتر، Danksharding بهطور کامل مسئولیت تأیید تودههای داده را در زیرمجموعههای گرهها گسترش میدهد و اتریوم را به بیش از 100,000 تراکنش در ثانیه افزایش میدهد.
----
-
-# دانکشاردینگ {#danksharding}
-
-**Danksharding** شبکه اتریوم را به یک زنجیره بلوکی کاملاً مقیاسپذیر تبدیل میکند، اما برای رسیدن به آن، لازم است چندین بهروزرسانی در پروتکل اتریوم اجرا شود. **Proto-Danksharding** یکی از مراحل میانی رسیدن به این هدف است. هردو هدفشان این است که تراکنشها را در شبکههای لایه دوم تا حد ممکن ارزانتر کنند و سرعت پردازش تراکنشها در شبکه اتریوم را به بیش از 100,000> تراکنش در ثانیه تغییر دهد.
-
-## Proto-Danksharding چیست؟ {#what-is-protodanksharding}
-
-بروتو-دنکشاردینگ با نام [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) هم شناخته میشود و راهی است برای [رولآپها](/layer-2/#rollups) تا دادههای ارزانتری به بلوکها افزوده شوند. این اسم از نام دو محقق (Protolambda و Dankrad Feist) که این ایده را مطرح کردند گرفته شده است. از لحاظ تاریخی، رولآپها به دلیل اینکه تراکنشهای خود را در `CALLDATA` پست میکنند، از نظر ارزان بودن تراکنشهای کاربر محدود بوده اند.
-
-این فرایند پرهزینه است چون تمام گرههای اتریوم باید آن را پردازش کنند و باید همیشه در زنجیره فعال باشند، گرچه رولآپها فقط برای مدت کوتاهی به دادهها نیاز دارند. پروتو-دنکشاردینگ تودههایی از دادهها را ارائه میکند که قابل ارسال و الصاق به بلوکها هستند. داده موجود در این تودهها برای EVM قابل دسترسی نیستند و پس از یک دوره زمانی ثابت (که بر روی 4096 ایپوک در زمان نوشتن یا حدود 18 روز تنظیم شده است) بهطور خودکار حذف میشوند. بهعبارتی، رولآپها اطلاعات را با هزینه کمتری ارسال میکنند و مقدار صرفهجوییشده را در قالب تراکنشهای ارزانتر به کاربران نهایی منتقل میکنند.
-
-
-
-رولآپها روشی برای مقیاسبندی اتریوم با دستهبندی تراکنشهای خارج از زنجیره و سپس ارسال نتایج به اتریوم است. یک رولآپ اساساً از دو بخش تشکیل شده است: دادهها و بررسی اجرا. دادهها دنباله کامل تراکنشهایی هستند که توسط یک رولآپ پردازش میشوند تا تغییر حالت در حال ارسال به اتریوم ایجاد شود. بررسی اجرا عبارت است از اجرای مجدد آن تراکنشها توسط یک بازیگر درستکار (یک «اثباتکننده») تا اطمینان حاصل شود که تغییر حالت پیشنهادی درست است. برای انجام بررسی اجرا، داده تراکنش باید به اندازه کافی در دسترس باشد تا هر کس بتواند آن را دانلود و بررسی کند. این بدان معناست که هر رفتار فریبکارانه توسط توالیسنج رولآپ میتواند توسط اثباتکننده شناسایی و به چالش کشیده شود. با این حال، لازم نیست برای همیشه در دسترس باشد.
-
-
-
-
-
-رولآپها تعهدات مربوط به دادههای تراکنش خود را روی زنجیره ارسال میکنند و همچنین دادههای واقعی را در تودههای داده در دسترس قرار میدهند. این بدان معناست که اثباتکنندگان میتوانند معتبر بودن تعهدات را بررسی کنند یا دادههایی را که فکر میکنند اشتباه هستند به چالش بکشند. در سطح گره، تودههای داده در کلاینت اجماع نگهداری میشوند. کلاینتهای اجماع تأیید میکنند که آنها دادهها را دیدهاند و در سراسر شبکه منتشر شده است. اگر دادهها برای همیشه حفظ میشد، این کلاینتها حجیم میشدند و منجر به نیازهای سختافزاری بزرگ برای اجرای گرهها میشدند. در عوض، داده به طور خودکار هر 18 روز از گره هرس می شود. گواهیهای کلاینت اجماع نشان میدهد که فرصت کافی برای تأیید دادهها ازسوی اثباتکنندهها وجود دارد. دادههای واقعی را میتوان در خارج از زنجیره توسط اپراتورهای رولآپ، کاربران یا دیگران ذخیره کرد.
-
-
-
-### نحوه تأیید توده اطلاعات چگونه است؟ {#how-are-blobs-verified}
-
-رولآپها تراکنشهایی را که اجرا میکنند در قالب تودههای دادهها منتشر میکنند. همچنین «تعهدی» را نسبت به دادهها منتشر میکنند. آنها این کار را با نصب یک تابع چند جملهای به دادهها انجام میدهند. سپس این تابع را میتوان در نقاط مختلف ارزیابی کرد. به عنوان مثال، تابع بسیار ساده `f(x) = 2x-1` را درنظر بگیرید. سپس، این تابع را میتوانیم برای متغیرهای `x = 1` ،`x = 2` ،`x = 3` ارزیابی کنیم، که نتایج `1, 3, 5` را به ما میدهد. هر تأییدکننده همین تابع را برای دادهها اعمال و آن را در همان نقاط ارزیابی میکند. هربار که دادههای اصلی تغییر کنند، تابع هم یکسان نخواهد بود، و بنابراین مقادیری که در هر نقطه ارزیابی شدهاند نیز متفاوت خواهند بود. در واقعیت، پروسه تعهد و تأیید پیچیدهتر است چون در بطن توابع رمزنگاریشده قرار گرفتهاند.
-
-### KZG چیست؟ {#what-is-kzg}
-
-KZG مخفف نام سه [نویسنده اصلی](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) Kate-Zaverucha-Goldberg طرحی است که تودهای از دادهها را در یک [تعهدنامه رمزنگاریشده](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) کوچک خلاصه میکند. برای اطمینان از این که رولآپها رفتار درست دارند، توده دادههای ارسالشده از طرف رولآپها باید تأیید شوند. در این فرایند، یک اثباتکننده تراکنشهای موجود در توده دادهها را مجدداً اجرا میکند تا معتبر بودن تعهد بررسی شود. از نظر مفهومی، این روش شبیه همان کاری است که کاربرهای اجرا، با استفاده از اثباتهای Merkle، برای بررسی اعتبار تراکنشهای اتریوم در لایه 1 انجام میدهند. KZG روشی جایگزین برای اثبات است که یک معادله چند جملهای را به دادهها الصاق میکند. تعهد مذکور صحت این معادله را در برخی مخفی نقاط داده ارزیابی میکند. یک اثباتکننده، همان معادله چندجملهای را روی داده الصاق میکند و با همان مقادیر ارزیابی میکند تا یکسان بودن نتایج را بررسی کند. این فرایند روشی برای تأیید دادههایی سازگار با تکنیکهای دانش صفر است که بعضی از رولآپها و متعاقباً بخشهایی از پروتکل اتریوم بکار میبرند.
-
-### مراسم KZG چه بود؟ {#what-is-a-kzg-ceremony}
-
-مراسم KZG راهی برای بسیاری از افراد از سراسر جامعه اتریوم بود تا به طور جمعی یک رشته تصادفی مخفی از اعداد را تولید کنند که میتواند برای تأیید برخی از دادهها استفاده شود. نکته بسیار مهم این است که این رشته از اعداد ناشناختهاند و کسی نمیتواند دوباره آنها را تولید کند. برای اطمینان از این امر، هر فردی که در مراسم شرکت کرد، یک رشته از شرکت کننده قبلی دریافت کرد. سپس مقادیر تصادفی جدیدی ایجاد کردند (مثلاً با اجازه دادن به مرورگر خود برای اندازه گیری حرکت ماوس) و آن را با مقدار قبلی ترکیب کردند. سپس عدد را برای شرکتکننده بعدی ارسال کردند و آن را از دستگاه محلی خود حذف کردند. تا زمانی که یک نفر در مراسم این کار را صادقانه انجام دهد، عدد نهایی برای مهاجم غیرقابل تشخیص خواهد بود.
-
-پمراسم EIP-4844 KZG برای عموم آزاد بود و ده ها هزار نفر برای اضافه کردن آنتروپی (انتخاب تصادفی) خود شرکت کردند. در مجموع بیش از 140،000 مشارکت کننده وجود داشت که آن مراسم را به بزرگترین مراسم از نوع خود در جهان تبدیل کردند. وقتی اعتبار تشریفات زیر سؤال میرود که 100 درصد شرکتکنندگان فعالیت خود را بهطور فعالانه از روی فریبکاری انجام دهند. از نقطهنظر شرکتکنندگان، اگر بدانند که کارشان را صادقانه انجام دادهاند، نیازی نیست به شخص دیگری اعتماد کنند زیرا میدانند که امنیت تشریفات را تأمین کردهاند (شرط یک شرکتکننده درستکار از میان N شرکتکننده را که لازمه صحت روند است شخصاً تضمین کردهاند).
-
-
-
-هنگامی که یک رولآپ داده را در یک توده پست می کند، آنها یک "تعهد" را ارائه می دهند که روی زنجیره پست می کنند. این تعهد نتیجه ارزیابی یک معادله چندجملهای است که در نقاطی مشخص به دادهها الصاق شدهاند. این نقاط با اعداد تصادفی تولیدشده در تشریفات KZG تعریف میشوند. سپس اثباتکنندگان میتوانند معادله چندجملهای را در همان نقاط ارزیابی کنند تا دادهها را تأیید کنند - اگر به همان مقادیر برسند، دادهها درست است.
-
-
-
-
-
-اگر کسی مکانهای تصادفی مورد استفاده برای تعهد را بداند، به راحتی میتواند یک چندجملهای جدید ایجاد کند که در آن نقاط خاص قرار بگیرد (یعنی نوعی «برخورد»). این بدان معنی است که آنها میتوانند دادهها را به توده اضافه یا از آن حذف کنند و همچنان یک مدرک معتبر ارائه دهند. برای جلوگیری از این امر، به جای دادن مکانهای مخفی واقعی به اثباتکنندگان، آنها در واقع مکانهایی را دریافت میکنند که در یک «جعبه سیاه» رمزنگاری، با استفاده از منحنیهای بیضوی پیچیده شدهاند. اینها به طور مؤثر مقادیر را به گونهای درهم میزنند که امکان مهندسی معکوس روی مقادیر اصلی وجود ندارد، اما با برخی از اثباتکنندهها و تأییدکنندگان باهوش در حیطه جبر، همچنان میتوانند چندجملهایها را در نقاطی که نشان میدهند ارزیابی کنند.
-
-
-
-
- نه دنکشاردینگ و نه پروتو-دنکشاردینگ از مدل سنتی "شاردینگ" پیروی نمیکنند که هدف آن تقسیم بلاکچین به چندین بخش است. زنجیرههای شارد (خردهزنجیرهها) دیگر بخشی از نقشه راه نیستند. در عوض، Danksharding از نمونهگیری دادههای توزیعشده در تودهها برای مقیاسبندی اتریوم استفاده میکند. اجرای این بسیار سادهتر است. گاهی اوقات، از این مدل تحت عنوان «شاردینگ دادهها» یاد میشود.
-
-
-## Danksharding چیست؟ {#what-is-danksharding}
-
-Danksharding تحقق کامل مقیاسبندی رولآپی است که با Proto-Danksharding آغاز شده بود. Danksharding در اتریوم فضای عظیمی را برای رولآپها فراهم میکند تا دادههای تراکنشهای فشردهشده را از شبکه بیرون کند. این بدان معناست که اتریوم میتواند با پشتیبانی آسان از صدها رولآپ جداگانه، رؤیای پردازش میلیونها تراکنش در ثانیه را به واقعیت تبدیل کند.
-
-روش کار این است که تودههای متصل به بلوک ها را از شش (6) در پروتو-دنکشاردینگ به 64 در دنکشاردینگ کامل گسترش می دهد. بقیه تغییرات مورد نیاز همگی بهروزرسانیهایی در نحوه عملکرد کلاینت اجماع است تا بتواند به تودههای اطلاعاتی جدید و بزرگ رسیدگی کند. تعدادی از این تغییراتی که هماکنون در نقشه راه وجود دارد برای اهداف دیگری مستقل از Danksharding عمل میکنند. به عنوان مثال، برای Danksharding لازم است تفکیک پیشنهاددهنده و سازنده اجرا شده باشد. این ارتقا وظایف ساخت بلوک و پیشنهاد بلوک را بین اعتبارسنجهای مختلف از هم تفکیک میکند. همچنین، در Danksharding نمونهگیری در دسترس بودن دادهها ضروری است، همانطور که برای توسعه تینکلاینتهایی که دادههای تاریخی زیادی ذخیره نمیکنند لازم است (کلاینتهای بدون حالت).
-
-
-
-جداسازی پیشنهاددهنده-سازنده برای اینکه تأییدکنندههای منفرد نیازی به ایجاد تعهدات و اثباتهای گرانقیمت برای توده دادهای با حجم 32 مگابایت نداشته باشند ضروری است. این امر فشار زیادی را بر سهامگذاران خانگی وارد میکند و آنها را ملزم به سرمایهگذاری روی سختافزار قدرتمندتر میکند که به غیرمتمرکزسازی آسیب میزند. در عوض، متخصصان بلاکسازی مسئولیت این کار محاسباتی گرانقیمت را بر عهده میگیرند. سپس، بلوکهای خود را برای پیشنهادکنندگان بلوک جهت پخش در دسترس قرار میدهند. پیشنهاددهنده بلوک به سادگی بلوکی را انتخاب میکند که بیشترین سود را دارد. هرکسی میتواند تودهها را ارزان و سریع تأیید کند، به این معنی که کلیه اعتبارسنجهای عادی میتوانند بررسی کنند که بلوکسازان رفتاری صادقانه داشته باشند. بدین ترتیب، تودههای بزرگ بدون به خطر انداختن فرایند غیرمتمرکزسازی میتوانند پردازش شوند. بلوکسازانی که رفتار نامناسب دارند را میتوان به سادگی از شبکه خارج و بیرون انداخت - دیگران به جای آنها وارد کار خواهند شد زیرا بلوکسازی یک فعالیت سودآور است.
-
-
-
-
-
-نمونهگیری از در دسترس بودن دادهها برای اعتبارسنجها لازم است تا روند تأیید دادههای تودهها را سریع و کارآمد انجام دهند. با استفاده از نمونهگیری در دسترس بودن دادهها، اعتبارسنجها میتوانند بسیار مطمئن باشند که دادههای تودهها در دسترس بوده و به درستی انجام شده باشد. هریک از اعتبارسنجها میتوانند به طور تصادفی از چند نقطه داده نمونهبرداری کنند و یک اثبات ایجاد کند، به این معنی که اعتبارسنج مجبور نیست کل توده را بررسی کند. اگر دادهای از دست رفته باشد، به سرعت شناسایی میشود و توده رد میشود.
-
-
-
-### پیشرفت فعلی {#current-progress}
-
-هنوز چند سالی با اجرای کامل Danksharding فاصله داریم. در این بین، مراسم KZG با بیش از 140،000 مشارکت کننده به پایان رسید و [EIP](https://eips.ethereum.org/EIPS/eip-4844) مربوط به پروتو-دنکشاردینگ به بلوغ رسید. این پیشنهاد به طور کامل در همه شبکههای آزمایشی پیادهسازی شده و با ارتقای شبکه Cancun-Deneb ("Dencun") در مارس 2024 در شبکه اصلی پخش شد.
-
-### بیشتر بخوانید {#further-reading}
-
-- [یادداشتهای Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_
-- [یادداشتهای Dankrad در مورد Danksharding](https://notes.ethereum.org/@dankrad/new_sharding)
-- [گفتگوی Dankrad و Proto و Vitalik درباره Danksharding](https://www.youtube.com/watch?v=N5p0TB77flM)
-- [تشریفات KZG](https://ceremony.ethereum.org/)
-- [بحث دِوکان Carl Beekhuizen در مورد تنظیمات قابل اعتماد](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube)
-- [اطلاعات بیشتر در مورد نمونهگیری در دسترس بودن داده برای تودهها](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
-- [سخنان Dankrad Feist در مورد تعهدات و اثباتهای KZG](https://youtu.be/8L2C6RDMV9Q)
-- [تعهدات چندجملهای KZG](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html)
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/dencun/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/dencun/index.md
deleted file mode 100644
index eaa3d7d4664..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/dencun/index.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: سوالات متداول Cancun-Deneb (Dencun)
-description: سوالات متداول در مورد ارتقاء شبکه Cancun-Deneb (Dencun)
-lang: fa
----
-
-# Cancun-Deneb (Dencun) {#dencun}
-
-Cancun-Deneb (Dencun) یک ارتقاء شبکه اتریوم است که **پروتو-دنکشاردینگ (پیشنهاد EIP-4844)** را فعال میکند و داده های موقت **تودهها** را برای ذخیرهسازی ارزانتر رولآپ [لایه 2 (L2)](/glossary/#layer-2) معرفی می کند.
-
-یک نوع تراکنش جدید که به ارائهدهندگان رولآپ امکان میدهد داده را به صورت مقرونبهصرفهتر در آنچه به عنوان "تودهها" شناخته میشوند، ذخیره کنند. تودهها به مدت حدود 18 روز نگهداری میشوند (به طور دقیقتر در طی 4096 [ایپوک](/glossary/#epoch). پس از این دوره زمانی، تودهها از شبکه حذف میشوند، اما برنامه ها همچنان می توانند اعتبار داده های خود را با استفاده از شواهد تأیید کنند.
-
-این امر به طور قابل توجه هزینه رولآپها را کاهش میدهد، رشد زنجیره را محدود میکند و به پشتیبانی از کاربران بیشتر در عین حفظ امنیت و مجموعه غیرمتمرکز اپراتورهای گره کمک میکند.
-
-## چه زمان انتظار داریم رولآپها منعکس کننده کارمزدهای کمتر به دلیل پروتو-دنکشاردینگ باشند؟ {#when}
-
-- این ارتقا در ایپوک شماره 269568، در **13-مارس-2024 ساعت 13:55 بعد از ظهر (UTC)** فعال شد
-- همه ارائه دهندگان اصلی رولآپ، مانند آربیتروم و آپتیمیزم، نشان داده اند که تودهها بلافاصله پس از ارتقا پشتیبانی می شوند
-- جدول زمانی پشتیبانی رولآپ انفرادی ممکن است متفاوت باشد، زیرا هر ارائهدهنده باید سیستمهای خود را بهروزرسانی کند تا از فضای توده جدید استفاده کند
-
-## چگونه می توان اتر را بعد از هارد فورک تبدیل کرد؟ {#scam-alert}
-
-- **برای اتر خود هیچ حرکتی لازم نیست بزنید**: پس از ارتقاء اتریوم Dencun، نیازی به تبدیل یا ارتقاء اترهای خود ندارید. موجودی حساب شما ثابت می ماند و اتری که در حال حاضر دارید پس از هارد فورک به شکل موجود خود قابل دسترسی خواهد بود.
-- **مراقب کلاهبرداری ها باشید!** **هرکس که به شما دستور "ارتقای" اترهایتان را بدهد، سعی دارد از شما کلاهبرداری کند.** هیچ کاری نیاز نیست در رابطه با این ارتقاء انجام بدهید. به طور کامل هیچ تاثیری روی دارایی های شما ندارد. به یاد داشته باشید، آگاه ماندن بهترین دفاع در برابر کلاهبرداری است.
-
-[اطلاعات بیشتر در مورد شناخت و جلوگیری از کلاهبرداری](/security/)
-
-## ارتقای شبکه Dencun چه مشکلی را حل می کند؟ {#network-impact}
-
-دنکان در درجه اول **مقیاسپذیری** (مدیریت کاربران بیشتر و تراکنشهای بیشتر) را با **کارمزدهای مقرون به صرفه** مورد توجه قرار میدهد، در حالی که به **حفظ عدمتمرکز** در شبکه میپردازد.
-
-جامعه اتریوم برای رشد خود یک رویکرد "رولآپ-محوری" را در پیش گرفته است، که رولآپهای لایه 2 را به عنوان ابزار اصلی برای پشتیبانی ایمن از کاربرانِ بیشتر، قرار میدهد.
-
-شبکههای رولآپ پردازش _processing_ (یا "اجرای") تراکنشها را جدا از شبکه اصلی انجام میدهند و سپس یک مدرک رمزنگارشده و/یا داده تراکنش فشرده از نتایج را برای نگهداری سوابق در شبکه اصلی منتشر میکنند. ذخیرهسازی این مدارک هزینهای را به همراه دارد (در قالب [گس]](/glossary/#gas))، که قبل از پروتو-دنکشاردینگ، باید به طور دائم توسط تمام اپراتورهای گره شبکه ذخیره می شد و این کار را به یک کار گران تبدیل می کرد.
-
-معرفی پروتو-دنکشاردینگ در ارتقای Dencun، ذخیرهسازی ارزانتر دادهها را برای این اثباتها اضافه میکند، زیرا تنها اپراتورهای گره را ملزم میکند تا این دادهها را برای حدود 18 روز ذخیره کنند، پس از آن میتوان دادهها را با خیال راحت حذف کرد تا از گسترش نیازمندیهای سختافزاری جلوگیری شود. از آنجا که رولآپها معمولاً یک دوره برداشت 7 روزه دارند، مدل امنیتی آنها تا زمانی که حبابها در لایه 1 برای این مدت در دسترس باشند، تغییر نمیکنند. فرصت هرس 18 روزه یک بافر قابل توجه برای این دوره فراهم می کند.
-
-[اطلاعات بیشتر در مورد مقیاسدهی اتریوم](/نقشه راه/مقیاسپذیری/)
-
-## چگونه دسترسی به داده های قدیمی توده پیدا می شود؟ {#historical-access}
-
-در حالی که گرههای معمولی اتریوم همیشه وضعیت فعلی شبکه را حفظ میکنند، دادههای تاریخی توده تقریباً 18 روز پس از معرفی آن حذف میشوند. قبل از دور انداختن این دادهها، اتریوم اطمینان حاصل میکند که در دسترس همه شرکتکنندگان شبکه قرار گرفته است، و همچنین جهت:
-
-- علاقه مندان برای دانلود و ذخیره داده ها.
-- تکمیل تمام دوره های چالش رولآپ.
-- نهاییسازی تراکنشهای رولآپ.
-
-داده های _Historical_ blob ممکن است به دلایل مختلف مورد نظر باشند و با استفاده از چندین پروتکل غیرمتمرکز قابل ذخیره و دسترسی باشند:
-
-- **پروتکلهای ایندکسینگ طرف ثالث**، مانند The Graph، این دادهها را از طریق یک شبکه غیرمتمرکز از اپراتورهای گره ذخیره میکنند که با مکانیزمهای ارزی-اقتصادی تشویق میشوند.
-- **بیتتورنت** یک پروتکل غیرمتمرکز است که در آن داوطلبان می توانند این داده ها را در اختیار دیگران قرار دهند.
-- هدف **[شبکه پورتال اتریوم](/developers/docs/networking-layer/portal-network/)** ارائه دسترسی به تمام داده های اتریوم از طریق شبکه غیرمتمرکز اپراتورهای گره با توزیع داده ها بین شرکتکنندگان مشابه بیت تورنت است.
-- **کاربران فردی** همیشه آزادند نسخه های خود را از هر داده ای که می خواهند برای مراجعه به سابقه ذخیره کنند.
-- **ارائهدهندگان رولآپ** تشویق میشوند این دادهها را ذخیره کنند تا تجربه کاربری از رولآپ خود را افزایش دهند.
-- **کاوشگرهای بلوک** معمولاً گرههای آرشیوی را اجرا میکنند که همه این اطلاعات را برای ارجاع آسان به تاریخچه، فهرستبندی و ذخیره میکنند و برای کاربران از طریق رابط وب در دسترس هستند.
-
-توجه به این نکته مهم است که بازیابی وضعیت سابقه، بر اساس مدل اعتماد **1-از-N** عمل می کند. این به این معنی است که برای تأیید صحت آن با استفاده از وضعیت فعلی شبکه، فقط به دادههایی از یک منبع قابل اعتماد نیاز دارید.
-
-## چگونه این ارتقا به نقشه راه گستردهتر اتریوم کمک میکند؟ {#roadmap-impact}
-
-پروتو-دنکشاردینگ زمینه را برای اجرای کامل [دنکشاردینگ](/نقشه راه/دنکشاردینگ/) فراهم می کند. دنکشاردینگ برای توزیع ذخیرهسازی داده های رولآپ در میان اپراتورهای گره طراحی شده است، بنابراین هر اپراتور فقط باید بخش کوچکی از کل داده ها را مدیریت کند. این توزیع تعداد تودههای داده در هر بلوک را افزایش میدهد، که برای مقیاسپذیری اتریوم برای مدیریت کاربران و تراکنشهای بیشتر ضروری است.
-
-این مقیاسپذیری برای [پشتیبانی از میلیاردها کاربر در اتریوم] (/نقشه راه/مقیاسپذیری/) با هزینههای مقرون به صرفه و برنامههای پیشرفتهتر، و در عین حال حفظ یک شبکه غیرمتمرکز، بسیار مهم است. بدون این تغییرات، تقاضاهای سخت افزاری برای اپراتورهای گره افزایش می یابد و منجر به نیاز به تجهیزات گرانقیمت فزاینده می شود. این میتواند اپراتورهای کوچکتر را قیمتگذاری کند و منجر به تمرکز کنترل شبکه در میان چند اپراتور بزرگ شود که در تضاد با اصل عدم تمرکز است.
-
-## آیا این ارتقا بر کل اجماع اتریوم و کاربرهای اعتبارسنج تأثیر میگذارد؟ {#client-impact}
-
-بله، پروتو-دنکشاردینگ (یعنی EIP-4844) به بهروزرسانیهایی برای کاربرهای اجرا و کاربرهای اجماع نیاز دارد. همه کاربرهای اصلی اتریوم نسخههایی را منتشر کردهاند که از این ارتقا پشتیبانی میکنند. برای حفظ همگام سازی با شبکه اتریوم پس از ارتقا، اپراتورهای گره باید اطمینان حاصل کنند که نسخه کاربر پشتیبانی شده را اجرا می کنند. توجه داشته باشید که اطلاعات مربوط به نسخه های کاربر به زمان حساس است و کاربران باید برای آخرین جزئیات به آخرین بهروزرسانیها مراجعه کنند. [به جزئیات نسخههای کاربر پشتیبانیشده مراجعه کنید](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases).
-
-کاربرهای اجماع نرمافزار _Validator_ را مدیریت می کنند، که همگی برای سازگاری با ارتقاء به روز شدهاند.
-
-## Cancun-Deneb (Dencun) چگونه بر گوئرلی (Goerli) یا سایر شبکه های آزمایشی اتریوم تأثیر می گذارد؟ {#testnet-impact}
-
-- Devnets و Goerli و Sepolia و Holesky همگی تحت ارتقای Dencun قرار گرفتهاند که نتیجتاً پروتو-دنکشاردینگ عملکرد کاملی دارد
-- توسعه دهندگان رولآپ می توانند از این شبکه ها برای آزمایش EIP-4844 استفاده کنند
-- اکثر کاربران، تحت تأثیر این تغییر در هر شبکه آزمایشی قرار نخواهند گرفت
-
-## آیا همه تراکنشهای لایه 2 اکنون از فضای توده موقت استفاده میکنند یا میتوانید حق انتخاب داشته باشید؟ {#calldata-vs-blobs}
-
-تراکنشهای رولآپ در لایه 2 (L2) اتریوم امکان استفاده از دو نوع ذخیرهسازی داده را دارند: فضای توده موقت یا calldata دائمی قرارداد هوشمند. فضای توده یک انتخاب اقتصادی است که ذخیرهسازی موقت را با هزینه کمتر فراهم می کند. در دسترس بودن داده ها را برای تمام دوره های چالشی ضروری تضمین می کند. از سوی دیگر، calldata قرارداد هوشمند ذخیرهسازی دائمی را ارائه می دهد اما گرانتر است.
-
-تصمیم بین استفاده از فضای توده یا calldata در درجه اول توسط ارائه دهندگان رولآپ اتخاذ میشود. آنها این تصمیم را بر اساس تقاضای فعلی برای فضای توده میگیرند. اگر فضای توده تقاضای زیادی داشته باشد، رولآپها ممکن است برای اطمینان از ارسال به موقع دادهها، calldata را انتخاب کنند.
-
-در حالی که از نظر تئوری این امکان برای کاربران وجود دارد که نوع ذخیرهسازی مورد نظر خود را انتخاب کنند، ارائه دهندگان رولآپ معمولاً این انتخاب را مدیریت می کنند. ارائه این گزینه به کاربران پیچیدگی را به خصوص در تراکنشهای بستهبندی مقرونبهصرفه میافزاید. برای جزئیات خاص در مورد این انتخاب، کاربران باید به اسناد ارائه شده توسط ارائهدهندگان فردی رولآپ مراجعه کنند.
-
-## آیا پیشنهاد 4844 گس لایه 1 را کاهش خواهد داد؟ {#l1-fee-impact}
-
-نه زیاد. یک بازار گس جدید به طور انحصاری برای فضای توده، برای استفاده توسط ارائه دهندگان رولآپ معرفی شده است. _اگرچه ممکن است کارمزدهای لایه 1 با بارگیری دادههای رولآپ به تودهها کاهش یابد، این ارتقا در درجه اول بر کاهش کارمزدهای لایه 2 تمرکز دارد. کاهش کارمزدها در لایه 1 (شبکه اصلی) ممکن است به عنوان یک اثر مرتبه دوم به میزان کمتر رخ دهد._
-
-- کاهش گس لایه 1 متناسب با پذیرش/استفاده از داده های توده توسط ارائه دهندگان رولآپ خواهد بود
-- گس لایه 1 احتمالاً از فعالیتهای غیر-رولآپی، رقابتی باقی میماند
-- رولآپهایی که از فضای توده استفاده میکنند، گس لایه 1 کمتری نیاز دارند و به کاهش کارمزدهای گس لایه 1 در کوتاهمدت کمک میکنند
-- فضای توده هنوز محدود است، بنابراین اگر تودههای داخل یک بلوک اشباع/پر باشند، ممکن است نیاز باشد که دادههای خود را بهعنوان دادههای دائمی پست کنند، که باعث افزایش قیمت گس لایه 1 و لایه 2 میشود
-
-## آیا این امر کارمزد سایر بلاکچینهای لایه 1 EVM را کاهش میدهد؟ {#alt-l1-fee-impact}
-
-خیر. مزایای پروتو-دنکشاردینگ، مخصوص رولآپهای لایه 2 اتریوم است که اثباتهای خود را در لایه 1 (شبکه اصلی) ذخیره میکنند.
-
-صرفاً سازگاری با ماشین مجازی اتریوم (EVM) به این معنی نیست که یک شبکه هرگونه سودی از این ارتقاء خواهد دید. شبکههایی که مستقل از اتریوم کار میکنند (خواه سازگار با EVM باشند یا نباشند) دادههای خود را در اتریوم ذخیره نمیکنند و هیچ سودی از این ارتقا نخواهند دید.
-
-[اطلاعات بیشتر در مورد رولآپهای لایه 2](/layer-2/)
-
-## با توضیحات تصویری راحتترید؟ {#visual-learner}
-
-
-
-_فعالسازی مقیاسپذیری اتریوم، EIP-4844 — فینماتیکس_
-
-
-
-_آموزش فضای توده با دوموتی — توسط Bankless_
-
-## ادامه مطلب {#further-reading}
-
-- [وبسایت EIP4844.com](https://www.eip4844.com/)
-- [پیشنهاد EIP-4844: تراکنشهای توده شارد (پروتو-دنکشاردینگ)] (https://eips.ethereum.org/EIPS/eip-4844)
-- [اعلامیه شبکه اصلی دنکان](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _وبلاگ بنیاد اتریوم_
-- [راهنمای سفر به اتریوم: پروتو-دنکشاردینگ](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _توسط Jon Charbonneau_
-- [سؤالات متداول پروتو-دنکشاردینگ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _توسط ویتالیک بوترین_
-- [شرح عمیق پیشنهاد EIP-4844: هسته ارتقاء کنکان](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core- of-the-cancun-upgrade-de7b13761d2c) - _توسط Ebunker_
-- [گزارش تمام توسعههای ریشهای شماره 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _توسط تیم بیکو_
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/pbs/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/pbs/index.md
deleted file mode 100644
index 3e50e33d583..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/pbs/index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: جداسازی سازنده-پیشنهاددهنده
-description: درباره چگونگی و علت جداسازی مسئولیت ساخت و پخش بلوک توسط اعتبارسنجهای اتریوم بیاموزید.
-lang: fa
----
-
-# جداسازی سازنده-پیشنهاددهنده {#proposer-builder-separation}
-
-اعتبارسنجهای کنونی اتریوم بلوکهای مجزا ایجاد _و_ پخش میکنند. آنها تراکنشهایی را که از طریق شبکه شایعه (گاسیپ) شنیدهاند با هم ترکیب میکنند و آنها را در بلوکی بستهبندی میکنند که برای همتایان حاضر در شبکه اتریوم ارسال میشود. **جداسازی پیشنهاد دهنده-سازنده (PBS)** این وظایف را بین چند اعتبارسنج تقسیم میکند. سازندگان بلوک مسئول ایجاد بلوکها و ارائه آنها به پیشنهاددهنده بلوک در هر اسلات هستند. پیشنهاددهنده بلوک نمیتواند محتویات بلوک را ببیند؛ او صرفاً سودآورترین را انتخاب میکند و قبل از ارسال بلوک به همتایان خود، کارمزدی را به سازنده بلوک میپردازد.
-
-این ارتقا به چند دلیل مهم است. اول اینکه فرصتهایی برای جلوگیری از سانسور تراکنشها در سطح پروتکل ایجاد میکند. دوم اینکه، مانع از عقب افتادن اعتبارسنجهای تفریحی از بازیگران سازمانی میشود که میتوانند سودآوری سازندگان بلوک خود را بهینهتر کنند. ثانیاً، با فعال کردن ارتقاهای Danksharding به مقیاسپذیری اتریوم کمک میکند.
-
-## PBS و مقامت در برابر سانسور {#pbs-and-censorship-resistance}
-
-جداسازی سازندههای بلوک و پیشنهاددهندگان بلوک باعث میشود سانسور تراکنشها برای سازندگان بلوک بسیار سختتر گردد. چراکه میتوان معیارهای نسبتاً پیچیدهای را برای شمول اضافه کرد تا اطمینان حاصل شود که قبل از پیشنهاد بلوک، هیچ سانسوری صورت نگرفته باشد. از آنجایی که پیشنهاددهنده بلوک از سازنده بلوک مجزا است، میتواند نقش محافظ در برابر سانسور سازندگان بلوک را بر عهده بگیرد.
-
-به عنوان مثال، میتوان فهرستهای شمول را معرفی کرد تا وقتی اعتبارسنجها از تراکنشها اطلاع دارند اما آنها را در بلوکها نمیبینند، بتوانند آنها را به عنوان موارد ضروری در بلوک بعدی اعمال کنند. این فهرست شمول از استخر حافظه محلی پیشنهادکنندگان بلوک (لیست تراکنشهایی که از آن آگاه است) تولید میشود و درست قبل از پیشنهاد بلوک برای همتایان آنها ارسال میشود. اگر هریک از تراکنشها در فهرست شمول از قلم افتاده باشد، پیشنهاددهنده میتواند بلوک را رد کند، یا تراکنشهای گمشده را قبل از پیشنهاد آن اضافه کند، یا آن را پیشنهاد کند و اجازه دهد وقتی اعتبارسنجهای دیگر آن را دریافت کردند، رد شود. همچنین یک نسخه بالقوه کارآمدتر از این ایده وجود دارد که میگوید سازندگان باید بهطور کامل از فضای بلوک موجود استفاده کنند و در صورت عدم استفاده، تراکنشها از فهرست مشمول پیشنهاددهنده اضافه میشوند. این هنوز یک حوزه تحقیقات فعال است و پیکربندی بهینه برای فهرستهای شمول هنوز مشخص نشده است.
-
-[استخرهای حافظه رمزگذاریشده](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) همچنین میتوانند این امکان را از سازندگان و پیشنهاددهندگان سلب کنند که تا قبل از اینکه بلوکی پخش شود، بفهمند کدام تراکنشها در یک بلوک قرار میگیرند.
-
-
-
-سازمانهای قدرتمند میتوانند اعتبارسنجها را تحت فشار قرار دهند که تراکنشها را از آدرسهایی مشخص یا به آدرسهایی مشخص سانسور کنند. اعتبارسنجها با شناسایی آدرسهای لیست سیاه در مخزن تراکنشها و حذف آنها از بلوکهایی که پیشنهاد میکنند، با این فشار سازگار میشوند. پس از PBS این دیگر امکانپذیر نخواهد بود، چراکه پیشنهاددهندگان بلوک نمیدانند کدام تراکنشها را در بلوکهای خود پخش میکنند. ممکن است برای افراد یا برنامههای خاصی رعایت قوانین سانسور مهم باشد، برای مثال زمانی که این قانون در منطقه آنها اجرایی شده است. در این موارد، پیروی از قوانین در سطح برنامه اتفاق میافتد، در حالی که پروتکل بدون مجوز و بدون سانسور باقی میماند.
-
-
-
-## PBS و MEV {#pbs-and-mev}
-
-**حداکثر ارزش قابل استخراج (MEV)** به اعتبارسنجهایی اشاره دارد که سودآوری خود را با سفارش تراکنشهای مورد نظرشان به حداکثر میرسانند. نمونههای رایج عبارتند از آربیتراژ مبادلهها در صرافیهای غیرمتمرکز (مثلاً فرانترانینگ برای خرید یا فروش بزرگ) یا شناسایی فرصتها برای انحلال موقعیتهای دیفای. به حداکثر رساندن MEV نیازمند دانش فنی پیچیده و نرمافزار سفارشی است که به اعتبارسنجهای معمولی اضافه میشود، و این احتمال را بسیار بیشتر میکند که اپراتورهای سازمانی در استخراج MEV از افراد و اعتبارسنجهای تفریحی بهتر عمل کنند. بهعبارتی، بازده سهامگذاری احتمالاً با اپراتورهای متمرکز بالاتر خواهد بود و نیروی متمرکزکنندهای ایجاد میکند که باعث بیانگیزگی برای سهامگذاری خانگی میشود.
-
-PBS این مشکل را با پیکربندی مجدد جنبۀ اقتصادی MEV حل میکند. به جای اینکه پیشنهاددهندۀ بلوک جستجوی MEV خود را انجام دهد، او به سادگی یک بلوک را از بسیاری از میان بلوکهایی که سازندههای بلوک به آنها پیشنهاد کردهاند، انتخاب میکند. سازندگان بلوک ممکن است برای استخراج MEV مسیر پیچیدهای را طی کرده باشند، اما پاداش آن به پیشنهاددهنده بلوک میرسد. این بدان معناست که حتی اگر استخر کوچکی از سازندگان بلوکهای تخصصی بر استخراج MEV مسلط باشند، پاداش آن میتواند به هر اعتبارسنجی در شبکه، ازجمله سهام گذاران منفرد خانگی، تعلق گیرد.
-
-
-
-به دلیل پیشنهاد پاداشهای افزایشیافتهای که توسط راهبردهای پیچیده MEV ارائه میشود، میتوان افراد را بهجای سهامگذاری انفرادی، تشویق به سهامگذاری در استخرها کرد. جداسازی ساخت بلوک از پیشنهاد بلوک به این معنی است که MEV استخراجشده به جای متمرکز شدن با مؤثرترین جستجوگر MEV، بین اعتبارسنجهای بیشتری توزیع میشود. همزمان، دادن اجازه حضور سازندگان تخصصی بلوک، بار بلوکسازی را از دوش افراد برمیدارد، و همچنین از سرقت MEV جلوگیری میکند، در حالی که تعداد اعتبارسنجهای مستقلی را که میتوانند بلوکها را صادقانه بررسی کنند به حداکثر میرساند. مفهوم مهم عبارت است از «عدم تقارن اثباتکننده- تأییدکننده» و اشاره به این ایده دارد که تولید متمرکز بلوک ایرادی ندارد بهشرطی که یک شبکه قوی و فوقالعاده غیرمتمرکز از اعتبارسنجها باشد که بتوانند صحت و درستی بلوکها را ثابت کنند. غیرمتمرکزسازی یک وسیله است، نه هدف نهایی - آنچه ما میخواهیم بلوکهای درست و قابل اطمینان است.
-
-
-## PBS و Danksharding {#pbs-and-danksharding}
-
-Danksharding راهی است که اتریوم با آن میتواند به مقیاسپذیری >100,000 تراکنش در ثانیه برسد و هزینهها را برای کاربران رولآپ به حداقل برساند. اجرای این ارتقا به PBS متکی است زیرا به حجم کار سازندگان بلوک میافزاید، که باید در کمتر از 1 ثانیه، اثباتها را برای حداکثر 64 مگابایت از دادههای رولآپ محاسبه کنند. این احتمالاً به سازندگان تخصصی نیاز دارد که میتوانند سختافزار نسبتاً قدرتمندی را به این کار اختصاص دهند. با این حال، در شرایط فعلی، به دلیل استخراج MEV، ساخت بلوک میتواند به طور فزایندهای در اطراف اپراتورهای پیچیدهتر و قدرتمندتر متمرکز شود. جداسازی پیشنهاددهنده از سازنده راهی برای پذیرش این واقعیت و جلوگیری از اعمال نیروی متمرکز بر اعتبارسنجی بلوک (بخش مهم) یا توزیع پاداشهای سهامگذاری است. یک مزیت جانبی بزرگ این است که سازندگان بلوک تخصصی نیز مایل و قادر به محاسبه اثبات اطلاعات لازم برای Danksharding هستند.
-
-## پیشرفت فعلی {#current-progress}
-
-PBS در مراحل تحقیقات پیشرفته قرار دارد، اما هنوز چند سؤال مهم در حوزه طراحی وجود دارد که باید قبل از نمونهسازی اولیه آن در کلاینتهای اتریوم، حل شود. هنوز هیچ مشخصاتی نهایی نشده است. این بدان معناست که احتمالاً با PBS حداقل یک سال فاصله داریم. آخرین [مراحل تحقیق](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) را بررسی کنید.
-
-## اطلاعات بیشتر {#further-reading}
-
-- [وضعیت فعلی تحقیق: مقاومت در برابر سانسور تحت PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
-- [طراحی بازارهایی با کارمزد مناسب PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
-- [PBS و مقامت در برابر سانسور](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions)
-- [فهرستهای شمول](https://notes.ethereum.org/@fradamt/H1ZqdtrBF)
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/secret-leader-election/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/secret-leader-election/index.md
deleted file mode 100644
index c9467f5a2bd..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/secret-leader-election/index.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: انتخاب پنهانی رهبر
-description: توضیح اینکه چگونه انتخاب رهبر مخفی میتواند به محافظت از اعتبارسنجها در برابر حملات کمک کند
-lang: fa
-summaryPoints:
- - آدرس IP پیشنهاددهندگان بلوک را میتوان پیشاپیش متوجه شد، و همین آنها را در برابر حملات آسیبپذیر میکند
- - انتخاب رهبر مخفی هویت اعتبارسنجها را پنهان میکند تا پیشاپیش قابل شناسایی نباشند
- - حالت بسطیافتهای از این ایده عبارت است از اینکه انتخاب اعتبارسنج برای هر اسلات به صورت تصادفی انجام شود.
----
-
-# انتخاب پنهانی رهبر {#single-secret-leader-election}
-
-امروزه در مکانیسم اجماع مبتنی بر [اثبات سهام](/developers/docs/consensus-mechanisms/pos)، فهرست پیشنهاددهندگان بلوک برای عموم در دسترس است و امکان بدست آوردن آدرس IP آنها وجود دارد. این بدان معناست که مهاجمان میتوانند تشخیص دهند کدام اعتبارسنجها قرار است یک بلوک را پیشنهاد کنند و آنها را با یک حملۀ «رد خدمات» (DOS) هدف قرار دهند، که باعث میشود نتوانند بلوک خود را به موقع پیشنهاد کنند.
-
-این میتواند فرصتهای سودآوری برای مهاجم ایجاد کند. به عنوان مثال، یک پیشنهاددهنده بلوک که برای اسلات `n+1` انتخاب شده است، میتواند پیشنهاددهنده را در اسلات `n` مورد حمله DOS قرار دهد تا فرصت خود را برای پیشنهاد کردن یک بلوک از دست بدهد. این به پیشنهاددهنده بلوک مهاجم اجازه میدهد تا MEV هر دو اسلات را استخراج کند، یا تمام تراکنشهایی را که باید بین دو بلوک تقسیم میشد، بگیرد و در عوض، همه آنها را در یک بلوک قرار دهد و تمام کارمزدهای مرتبط را به دریافت کند. این احتمالاً بر اعتبارسنجهای خانگی بیشتر از اعتبارسنجهای سازمانی و پیچیده تأثیر میگذارد چراکه آنها میتوانند از روشهای پیشرفتهتری برای محافظت از خود در برابر حملات DOS استفاده کنند و بنابراین میتوانند یک نیروی متمرکزکننده باشند.
-
-چندین راه حل برای رفع این مسئله وجود دارد. یکی از آنها [فناوری اعتبارسنجی توزیعشده](https://github.com/ethereum/distributed-validator-specs) است که هدفش توزیع وظایف مختلف مربوط به اجرای یک اعتبارسنجی در چندین ماشین، با تزائد است، به طوری که جلوگیری از پیشنهاد یک بلوک در یک اسلات خاص برای یک مهاجم بسیار دشوارتر شود. با این حال، موثرترین راه حل **انتخاب رهبر مخفی منفرد (SSLE)** است.
-
-## انتخابات تکرهبر پنهان {#secret-leader-election}
-
-در SSLE، از رمزنگاری هوشمندانهای استفاده میشود تا اطمینان حاصل شود که فقط اعتبارسنج انتخابشده از انتخاب شدنش اطلاع داشته باشد. این کار به این صورت انجام میشود که هر اعتبارسنج تعهدی را به عبارت محرمانهای که همگی به طور مشترک دارند، ارائه کند. تعهدات به شکل تصادفی تغییر میکنند و مجدداً پیکربندی میشوند تا هیچکس نتواند تعهدات را به اعتبارسنجیها مرتبط کند، اما هریک از اعتبارسنجها میدانند که کدام تعهد متعلق به آنهاست. پس از آن، یک تعهد به شکل تصادفی انتخاب میشود. اگر اعتبارسنج تشخیص دهد که تعهد او انتخاب شده است، متوجه میشود که نوبت اوست که یک بلوک را پیشنهاد کند.
-
-پیادهسازی اصلی این ایده [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763) نام دارد. و به شرح زیر عمل میکند:
-
-1. اعتبارسنجها به یک عبارت محرمانه مشترک متعهد میشوند. طرح تعهد به گونهای طراحی شده است که میتوان آن را به یک اعتبارسنج مشخص پیوند داد و تصادفیسازی کرد، به طوری که هیچ شخص ثالثی نتواند پیوند مذکور را مهندسی معکوس کند و یک تعهد خاص را به یک اعتبارسنج خاص مرتبط کند.
-2. در شروع یک ایپوک، با استفاده از RANDAO یک مجموعه تصادفی از اعتبارسنجها برای نمونهبرداری از تعهدات از مجموع 16,384 اعتبارسنج انتخاب میشود.
-3. برای 8182 اسلات بعدی (1 روز)، پیشنهاددهندگان بلوک زیرمجموعهای از تعهدات را با استفاده از الگوی بیمنظمی خصوصی خود به هم ریخته و تصادفی میکنند.
-4. پس از اینکه فرآیند درهم آمیختن انجام شد، از RANDAO برای ایجاد یک لیست منظم از تعهدات استفاده میشود. این لیست بر روی اسلاتهای اتریوم ثبت شده است.
-5. اعتبارسنجها میبینند که تعهد آنها به یک اسلات خاص متصل است و هنگامی که آن اسلات در دسترس قرار میگیرد، یک بلوک را پیشنهاد میکنند.
-6. این مراحل را تکرار کنید تا تخصیص تعهدات به اسلاتها همیشه جلوتر از اسلات فعلی باشد.
-
-این امر مانع از این میشود که مهاجمان از قبل بدانند کدام اعتبارسنج بلوک بعدی را پیشنهاد میکند، بنابراین از ایجاد فرصت برای حملات DOS جلوگیری میشود.
-
-## انتخاب رهبر مخفی غیرمنفرد (SnSLE) {#secret-non-single-leader-election}
-
-همچنین، یک پیشنهاد جداگانه وجود دارد که هدف آن ایجاد سناریویی است که در آن اعتبارسنجیها شانسی تصادفی برای پیشنهاد یک بلوک در هر اسلات دارند، مشابه نحوه تصمیمگیری درباره پیشنهاد بلوک برمبنای اثبات کار، که با عنوان **انتخاب رهبر مخفی غیرمنفرد (SnSLE)** شناخته میشود. یک راه ساده برای انجام این کار استفاده از تابع RANDAO است که برای انتخاب تصادفی اعتبارسنجها در پروتکل امروزی استفاده میشود. ایده RANDAO این است که یک عدد کاملاً تصادفی با مخلوط کردن هشهای ارسالشده توسط مجموعهای از اعتبارسنجهای مستقل تولید میشود. در SnSLE، از این هشها میتوان برای انتخاب پیشنهاددهنده بلوک بعدی استفاده کرد، برای مثال با انتخاب کمارزشترین هش. دامنه هشهای معتبر میتواند برای تنظیم احتمال انتخاب هریک از اعتبارسنجها در هر اسلات محدود شود. با بیان اینکه هش باید کمتر از `2^256 * 5 / N` باشد، که در آن `N` تعداد اعتبارسنجهای فعال است، شانس انتخاب هر اعتبارسنج در هر اسلات `5/N` خواهد بود. در این مثال، احتمال 99/3٪ وجود دارد که حداقل یک پیشنهاددهنده یک هش معتبر در هر شکاف ایجاد کند.
-
-## پیشرفت فعلی {#current-progress}
-
-SSLE و SnSLE هر دو در مرحله تحقیقات هستند. هنوز هیچ مشخصاتی قطعی برای هیچکدام از این دو ایده وجود ندارد. SSLE و SnSLE پیشنهادهایی رقابتی هستند که هر دو همزمان قابل اجرا نیستند. قبل از نهایی شدن، آنها به تحقیق و توسعه بیشتر، نمونهسازی و پیادهسازی در شبکههای تست عمومی نیاز دارند.
-
-## بیشتر بخوانید {#further-reading}
-
-- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/single-slot-finality/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/single-slot-finality/index.md
deleted file mode 100644
index 9c4601bb66a..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/single-slot-finality/index.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: قطعیت اسلات منفرد
-description: توضیحاتی درباره قطعیت اسلات منفرد
-lang: fa
----
-
-# قطعیت اسلات منفرد {#single-slot-finality}
-
-حدود 15 دقیقه زمان لازم است تا یک بلوک اتریوم قطعی شود. با این حال، میتوانیم مکانیزم اجماع اتریوم را به شکلی طراحی کنیم که معتبر ساختن بلوکها در حالت بهینهتری انجام شود و از این طریق زمان قطعی شدن بلاکها را به شدت کاهش دهیم. به جای انتظار 15 دقیقهای، بلوکها میتوانند در یک اسلات یکسان پیشنهاد شوند و در همان اسلات هم قطعی شوند. این مفهوم تحت عنوان **قطعیت اسلات منفرد (SSF)** شناخته میشود.
-
-## قطعیت چسیت؟ {#what-is-finality}
-
-در مکانیزم اجماع مبتنی بر اثبات سهام اتریوم، قطعیت به این تضمین اشاره دارد که بلوک نتواند تغییر کند یا از زنجیرهی بلوکی حذف شود، مگر 33 درصد از کل اتریوم سهامگذاریشده را بسوزاند. این یک امنیت «رمزنگاری اقتصادی» است زیرا حصول اطمینان لازم با صرف هزینه بسیار بالایی بابت تغییر ترتیب زنجیره یا محتوای آن انجام میشود و بنابراین مانع روی آوردن فعالان اقتصادی منطقگرا به انجام این کار میشود.
-
-## چرا باید به دنبال سریعتر کردن قطعیت باشیم؟ {#why-aim-for-quicker-finality}
-
-در حال حاضر زمان لازم برای قطعیت بلوکها خیلی طولانی است. اکثر کاربران نمیخواهند برای قطعیت تراکنشها 15 دقیقه منتظر بمانند و از طرفی انتظار برای اطمینان از تحقق یافتن تراکنشها در برنامهها و صرافیها که باید تعداد بالایی از دادههای ورودی تراکنشها داشته باشند، نامطلوب است. همچنین، تأخیر ایجادشده بین پیشنهاد شدن بلوکها و قطعی شدن آن، موقعیت را برای سازماندهی دوباره فراهم میکند و مهاجم میتواند از آن برای پنهان کردن بلوکهای خاص یا استخراج MEV استفاده کند. مکانیزمی که مسئولیت ارتقای بلوکها در مراحل مختلف را به عهده دارد نیز بسیار پیچیده است و پچهای مختلفی بارها برای بستن حفرههای امنیتی آن ارائه شده است، که آن را به یکی از قسمتهای کدهای پایۀ اتریوم تبدیل میکند و در آنجا وقوع باگهای ریز محتملتر است. همه این مشکلات با کاهش زمان قطعیت یک اسلات قابل رفع هستند.
-
-## تمرکززدایی/ زمان/مدیریت سربار {#the-decentralization-time-overhead-tradeoff}
-
-ضمانت قطعیت جزء ویژگیهای یک بلوک جدید نیست، قطعی شدن یک بلوک جدید زمان میبرد. دلیل این موضوع این است که اعتبارسنجهایی که حداقل دوسوم از کل اتریوم سهامگذاریشده در شبکه را در اختیار دارند باید به بلوک رأی دهند («تصدیق کنند») تا بلوک قطعی محسوب شود. هر گره اعتبارسنج در شبکه باید تصدیقهای مرتبط به دیگر گرهها را پردازش کند تا برایش مشخص شود که یک بلوک به آن آستانه دوسوم رسیده است یا نه.
-
-از آنجایی که فرآیند تصدیق باید با سرعت بیشتری انجام شود، هرچه زمان قطعی شدن تراکنشها کمتر باشد، هر نود به توان پردازشی بیشتری نیاز دارد. همچنین، هرچه گرههای اعتبارسنج بیشتری در شبکه وجود داشته باشد، تعداد تصدیقهای لازم به پردازش برای هر بلوک بیشتر میشود، که این موضوع به قدرت پردازش موردنیاز نیز میافزاید. هرچه قدرت پردازش بیشتری مورد نیاز باشد، افراد کمتری میتوانند در اعتبارسنجی شرکت کنند چراکه در این شرایط به سختافزار گرانتری برای اجرای هر گرۀ اعتبارسنج نیاز است. افزایش زمان بین بلوکها قدرت محاسباتی مورد نیاز برای هر گره را کاهش میدهد اما زمان مورد نیاز برای قطعیت آن را افزایش میدهد، چراکه در این حالت فرآیند تصدیق با سرعت کمتری انجام میشود.
-
-بنابراین، تعاملی میان بار اضافی (قدرت محاسباتی)، غیرمتمرکزسازی (تعداد گرههایی که میتوانند در فرآیند اعتبارسنجی زنجیره شرکت کنند) و زمان مورد نیاز برای قطعیت، وجود دارد. یک سیستم ایدهآل تعادلی بین این سه ویژگی یعنی حداقل توان محاسباتی، بیشترین حالت غیرمتمرکزسازی و کمترین زمان برای قطعیت، ایجاد میکند.
-
-مکانیزم اجماع فعلی اتریوم این سه پارامتر را به شکل زیر متعادل کرده است:
-
-- **تنظیم حداقل سهامگذاری روی 32 واحد اتر**. این تنظیمات یک حد بالا برای سقف تعداد تصدیق اعتبارسنجها ایجاد میکند که باید توسط گرههای منفرد پردازش شوند، و بنابراین یک حد بالا نیز برای توان محاسباتی مورد نیاز هر گره ایجاد میکند.
-- **تنظیم زمان قطعیت روی حدود 15 دقیقه**. این تنظیم زمان کافی را در اختیار اعتبارسنجهایی که بر روی کامپیوترهای خانگی عادی اجرا میشوند قرار میدهد تا بتوانند به صورت امن تصدیق هر بلوک را پردازش کنند.
-
-در طرح مکانیزم فعلی، برای کاهش زمان قطعیت، لازم است که تعداد اعتبارسنجهای شبکه کاهش پیدا کند یا توان سختافزاری مورد نیاز هر گره افزایش یابد. با این حال، ارتقاهایی در نحوه پردازش تصدیقها صورت گرفته که به وسیله آن، بدون اینکه به بار اضافی بر روی هر گره افزوده شود، امکان شمارش تصدیقهای بیشتری فراهم گردد. پردازش بهینهتر میتواند تعیین زمان قطعیت را به جای اینکه روی دو ایپوک انجام گیرد، در یک اسلات منفرد امکانپذیر سازد.
-
-## مسیرهای منتهی به SSF {#routes-to-ssf}
-
-
-
-مکانیزم اجماع فعلی تصدیقهای دریافتشده از اعتبارسنجهای مختلف را، که تحت عنوان کمیته شناخته میشوند، ترکیب میکند تا تعداد پیامهایی را که هر اعتبارسنج برای تأیید معتبر ساختن یک بلوک باید تأیید کند کاهش دهد. هر اعتبارسنج این فرصت را دارد که تصدیق را در هر ایپوک (32 اسلات) انجام دهد. اما در هر اسلات، فقط زیرمجموعهای از اعتبارسنجها که تحت عنوان «کمیته» شناخته میشوند تصدیق میکنند. آنها این کار را با تقسیم شدن به زیرشبکهها انجام میدهند که در هریک از آنها، تعدادی اعتبارسنج به عنوان «تجمیعکنندهها» انتخاب میشوند. هرکدام از آن تجمیعکنندهها تمام امضاهایی را که از سایر اعتبارسنجهای حاضر در زیرشبکه میبینند در یک امضای تجمیعی واحد تلفیق میکنند. تجمیعکنندهای که بیشترین تعداد مشارکت افراد را ثبت کرده باشد، امضای تجمیعی خود را در اختیار پیشنهاددهنده بلوک قرار میدهد؛ پیشنهاددهنده نیز این امضا را به همراه امضای تجمیعی سایر کمیتهها در بلوک قرار میدهد.
-
-این فرآیند ظرفیت کافی را بر هر اعتبارسنج ایجاد میکند تا در فرآیند رأی دادن به هر ایپوک شرکت کند، چراکه 32 اسلات ضرب در 64 کمیته ضرب در 256 اعتبارسنج به ازای هر کمیته برابر است با 524,288 اعتبارسنج در هر ایپوک. در زمان نگارش (فوریه 2023)، تقریباً 513,000 اعتبارسنج فعال وجود دارد.
-
-در این طرح، برای هر اعتبارسنج تنها این امکان وجود دارد که با توزیع تصدیقهایش در کل ایپوک، به یک بلوک رأی دهد. با این حال، به صورت بالقوه راههایی برای بهبود مکانیزم وجود دارد تا _هر اعتبارسنج شانس تصدیق کردن در هر اسلات را داشته باشد_.
-
-
-از زمانی که مکانیزم اجماع اتریوم طراحی شد، مشخص شد که طرح تجمیع امضا (BLS) بسیار مقیاسپذیرتر از آنچه در ابتدا تصور میشد بوده است. این در حالی است که توانایی کلاینتها برای پردازش و تأیید امضاها نیز بهبود یافته است. به نظر میرسد که پردازش تصدیقها توسط تعداد عظیمی اعتبارسنج درواقع در داخل یک اسلات امکانپذیر باشد. به عنوان نمونه، با یک میلیون اعتبارسنج که هر کدام دو بار در هر اسلات رأی میدهند و زمان 16 ثانیهای که برای هر اسلات تنظیم شده است، گرهها باید امضاها را حداقل با نرخ 125,000 تجمیع در ثانیه تأیید کنند تا بتوانند کل 1 میلیون تصدیق را در داخل اسلات پردازش کنند. در واقعیت، برای یک کامپیوتر معمولی حدود 500 نانوثانیه طول میکشد تا یک تأیید امضا را انجام دهد، به این معنی که 125,000 امضا را میتوان در 62/5 میلیثانیه انجام داد - بسیار کمتر از آستانه یک ثانیه.
-
-با ایجاد ابَرکمیتهها که مثلاً 125,000 اعتبارسنج تصادفی در هر اسلات داشته باشند، میتوان به افزایش بازدهی دست یافت. فقط این اعتبارسنجها میتوانند در مورد یک بلوک رأی دهند و بنابراین فقط این زیرمجموعه از اعتبارسنجها تصمیم میگیرند که آیا یک بلوک نهایی شود یا خیر. خوب بودن یا نبودن این ایده به این بستگی دارد که اعضای جامعه اتریوم ترجیح دهند هزینه حمله موفقیتآمیز به اتریوم چقدر سنگین باشد. این بدان خاطر است که به جای نیاز به دوسوم از کل اترهای سهامگذاریشده، مهاجم میتواند یک بلوک غیر صادقانه را با دوسوم اترهای سهامگذاریشده _در آن ابَرکمیته_ قطعی کند. این هنوز یک حوزه تحقیقاتی فعال است، اما امکانپذیر به نظر میرسد که برای مجموعهای از اعتبارسنجها در اندازهای که در وهله اول نیاز به ابَرکمیته داشته باشد، هزینه حمله به یکی از آن زیر کمیتهها بسیار بالا خواهد بود (مثلاً هزینه حمله به اتریوم بر این اساس `2/3 * 125,000 * 32 = تقریباً 2/6 میلیون اتر` خواهد بود). هزینه حمله را میتوان با افزایش بزرگی مجموعۀ اعتبارسنجها تنظیم کرد (به عنوان مثال اندازه اعتبارسنج را طوری تنظیم کنید که هزینه حمله برابر با 1 میلیون اتر، 4 میلیون اتر، 10 میلیون اتر و غیره باشد). [نظرسنجیهای اولیه](https://youtu.be/ojBgyFl6-v4?t=755) از اعضای جامعه اتریوم نشان میدهد که 1 تا 2 میلیون اتر، هزینه قابل قبولی برای حمله است، که به این معنی است: 65,536 - 97,152 اعتبارسنج در هر ابَرکمیته.
-
-با این حال، تأییدیه مسئله اصلی نیست - در واقع این تجمیع امضا است که گرههای اعتبارسنج را به چالش میکشد. برای مقیاسپذیری تجمیع امضا، احتمالاً نیاز به افزایش تعداد اعتبارسنجها در هر زیرشبکه، افزایش تعداد زیرشبکهها، یا افزودن لایههای اضافی تجمیع (یعنی پیادهسازی کمیتههایی برای کمیتهها) خواهد بود. بخشی از راه حل میتواند صدور مجوز برای تجمیعکنندههای تخصصی باشد - شبیه نحوه ایجاد بلوک و توسعه تعهدات برای اطلاعات رولآپشده به بلوکسازان تخصصی مبتنی بر جداسازی پیشنهاددهنده-سازنده (PBS) و Danksharding.
-
-## نقش قانون انتخاب فورک در SSF چیست؟ {#role-of-the-fork-choice-rule}
-
-مکانیزم اجماع فعلی بر یک پیوند محکم میان ابزار قطعیت (الگوریتمی که تعیین میکند آیا دوسوم از اعتبارسنجها زنجیره خاصی را تصدیق کردهاند) و قانون انتخاب فورک (الگوریتمی که در صورت وجود چندین زنجیره، تصمیم میگیرد کدام زنجیره صحیح است) متکی است. الگوریتم انتخاب فورک بلوکها را فقط _از_ آخرین بلوک قطعی درنظر میگیرد. بر مبنای SSF هیچ بلوکی برای قانون انتخاب فورک وجود نخواهد داشت، زیرا قطعیت در همان اسلاتی رخ میدهد که بلوک پیشنهاد شده است. این بدان معناست که بر مبنای SSF، _یکی از این دو_ در هر زمانی فعال خواهد بود: الگوریتم انتخاب فورک _یا_ ابزار قطعیت. ابزار قطعیت بلوکهایی را قطعی خواهد کرد که دوسوم از اعتبارسنجها آنلاین بوده و با صداقت تصدیق کرده باشند. اگر یک بلوک نتواند از آستانه دوسوم عبور کند، قانون انتخاب فورک برای تعیین زنجیرهای که باید دنبال شود وارد عمل خواهد شد. این همچنین فرصتی برای حفظ مکانیزمهای تشخیص وقوع عدم فعالیت ایجاد میکند تا زنجیرهای به کمک آن بازیابی شود که >یکسوم از اعتبارسنجها آفلاین میشوند، البته با تفاوتهایی اندک.
-
-## موضوعات قابل ملاحظه {#outstanding-issues}
-
-مشکل مقیاسپذیری تجمیع با افزایش تعداد اعتبارسنجها در هر زیرشبکه این است که منجر به ترافیک بیشتر در شبکه همتا به همتا میشود. مشکل اضافه کردن لایههای تجمیع این است که مهندسی آن کاملاً پیچیده است و تأخیر را بیشتر میکند (یعنی ممکن است مدت بیشتری طول بکشد تا پیشنهاددهندۀ بلوک اطلاعات را از همه تجمیعکنندگان زیرشبکه دریافت کند). همچنین مشخص نیست که چگونه میتوان با سناریویی برخورد کرد که در آن تعداد اعتبارسنجهای فعال در شبکه از تعدادی که پردازششان در هر اسلات عملاً امکانپذیر است بیشتر میشود، حتی با تجمیع امضای BLS. یک راه حل بالقوه این است که، چون تمام اعتبارسنجها هر اسلات را تصدیق میکنند و کمیتهای بر مبنای SSF وجود ندارد، محدودیت 32 اتر در موجودی را میتوان به طور کامل حذف کرد؛ به عبارتی، اپراتورهایی که چندین اعتبارسنج را مدیریت میکنند می توانند سهامگذاری خود را تجمیع کنند و کمتر فعالیت کنند تا تعداد پیامهایی که گرههای اعتبارسنجی باید برای لحاظ کردن کل مجموعه اعتبارسنجها پردازش کنند کاهش یابد. این به نظرِ سهامگذاران بزرگ وابسته است که بپذیرند اعتبارسنجهای خود را ادغام کنند. همچنین این امکان وجود دارد که در هر زمانی، یک سقف ثابت برای تعداد اعتبارسنجها یا مقدار اتر سهامگذاریشده اعمال شود. با این حال، این نیاز به مکانیزمی برای تصمیمگیری دارد که کدام اعتبارسنج مجاز به مشارکت است و کدام مجاز نیست، که ممکن است اثرات ثانویه ناخواسته ایجاد کند.
-
-## پیشرفت فعلی {#current-progress}
-
-SSF در مرحله تحقیقاتی است. انتظار نمیرود تا چندین سال آتی تحقق یابد، و احتمالاً باید ابتدا ارتقاهای اساسی دیگر مانند [درختان ورکل](/roadmap/verkle-trees/) و [Danksharding](/roadmap/danksharding/) را پشت سر گذاشت.
-
-## بیشتر بخوانید {#further-reading}
-
-- [ویتالیک در EDCON 2022 راجع به SSF میگوید](https://www.youtube.com/watch?v=nPgUKNPWXNI)
-- [یادداشتهای ویتالیک: مسیرهایی به سوی قطعیت اسلات منفرد](https://notes.ethereum.org/@vbuterin/single_slot_finality)
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/statelessness/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/statelessness/index.md
deleted file mode 100644
index 022bacdf28c..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/statelessness/index.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: بیحالتی، انقضای حالت و انقضای تاریخچه
-description: توضیح انقضای تاریخچه و اتریوم بیحالت
-lang: fa
----
-
-# بیحالتی، انقضای حالت و انقضای تاریخچه {#statelessness}
-
-توانایی اجرای گرههای اتریوم بر روی سختافزار متوسط برای غیرمتمرکزسازی صحیح بسیار مهم است. دلیل آن این است که گره به کاربران این امکان را میدهد که بجای اعتماد به شخص ثالث در ارسال دادهها با انجام بررسیهای رمزنگاریشده بهطور مستقل اطلاعات را تأیید کنند. اجرای یک گره به کاربران اجازه میدهد تا به جای اعتماد به یک واسط، تراکنش ها را بهطور مستقیم به شبکه همتابه همتای اتریوم ارسال کنند. اگر این مزایا تنها برای کابرانی که دارای سختافزارهای گران قیمت هستند امکانپذیر باشد، غیرمتمرکزسازی ممکن نیست. درعوض، گرهها باید قادر به اجرا با تجهیزات حافظه و پردازشی بسیار معمول باشند بهطوری که بتوانند بر روی تلفنهای همراه، میکرو کامپیوترها یا درحد غیرقابلتوجه بر روی کامپیوتر خانگی اجرا شوند.
-
-امروزه، الزامات فضای دیسک بالا مانع اصلی دسترسی جامع به گرهها است. این در درجه اول، به دلیل نیاز به ذخیرهسازی مقادیر قابل توجه دادههای حالت اتریوم است. این دادههای حالت شامل اطلاعات مهم مورد نیاز برای پردازش صحیح بلوکها و تراکنشهای جدید است. در زمان نگارش این مقاله، یک حافظه سریع 2 ترابایتی SSD برای اجرای یک گره کامل اتریوم مورد نیاز است. برای گرهای که دادههای قدیمی را حذف نمیکند، حافظه مورد نیاز حدوداً 14 گیگابایت در هفته زیاد میشود، و گرههای آرشیو که تمام دادهها را از زمان پیدایش بلاک اول ذخیره میکند، به 12 ترابایت نزدیک میشود (در زمان نگارش، فوریه 2023).
-
-از هارد دیسکهای ارزانتر میتوان برای ذخیرهسازی دادههای قدیمیتر استفاده کرد، اما آنها برای همگام شدن با بلوکهای ورودی جدید بسیار کند هستند. حفظ مدلهای ذخیرهسازی فعلی برای کلاینتها درحالیکه ذخیرهسازی داده را ارزانتر و آسانتر میکند، تنها یک راه حل موقت و جزئی برای رفع این مشکل است، زیرا رشد حالت اتریوم «نامحدود» است، یعنی الزامات ذخیرهسازی فقط میتواند افزایش یابد، و پیشرفتهای فناوری همواره باید با رشد مستمر حالت همگام باشد. لذا، کلاینتها باید راههای جدیدی برای تأیید بلوکها و تراکنشها پیدا کنند که متکی بر جستجوی دادهها از پایگاههای دادهای محلی نباشد.
-
-## کاهش حافظه مورد نیاز گرهها {#reducing-storage-for-nodes}
-
-راههای مختلفی برای کاهش حجم دادهای که هر گره باید ذخیره کند وجود دارد، که هر کدام نیازمند بهروزرسانی پروتکل اصلی اتریوم به میزان متفاوت هستند:
-
-- **انقضای تاریخچه**: به گرهها امکان میدهد تا دادههای حالت قدیمیتر از حالت بلوکهای X را حذف کنند، اما چگونگی نحوه مدیریت دادههای حالت توسط کلاینتها اتریوم را تغییر نمیدهد
-- **انقضای حالت**: اجازه میدهد دادههای حالتی که بهطور متداول استفاده نمیشوند غیرفعال شوند. کلاینتها میتوانند تا زمان فراخوانی مجدد، دادههای غیرفعال را نادیده بگیرند.
-- **بیحالتی ضعیف**: فقط ایجادکنندگان بلوک نیاز به دسترسی به دادههای حالت کامل دارند، سایر گرهها میتوانند بدون پایگاه داده حالت محلی بلوکها را تأیید کنند.
-- **بیحالتی شدید**: هیچ یک از گرهها نیاز به دسترسی به دادههای کامل حالت ندارند.
-
-## انقضای دادهها {#data-expiry}
-
-### انقضای تاریخچه {#history-expiry}
-
-انقضای تاریخچه به کلاینتهایی اشاره دارد که دادههای قدیمیتر که بعید است نیاز شود را حذف میکند، بنابراین آنها فقط مقدار کوچکی از دادههای قبلی را ذخیره میکنند، دادههای قدیمیتر را با رسیدن دادههای جدید حذف میکنند. کلاینتها به دو دلیل نیاز به دادههای قبلی دارند: همگامسازی و پردازش درخواستهای داده. در ابتدا، کلاینتها مجبور بودند از بلوک ایجاد همگامسازی کنند، تأیید کنند که هر بلوک متوالی تا سر زنجیره صحیح است. امروزه، کلاینتها از "نقطههای بررسی ضعیف" برای بوتاسترپ کردن راه خود به سر زنجیره استفاده میکنند. این نقاط بررسی نقاط شروع قابل اعتمادی هستند، مانند داشتن یک بلوک ایجاد که بهجای زمان آغازین اتریوم، نزدیکتر به زمان حال است. این یعنی کلاینتها میتوانند تمام اطلاعات را قبل از جدیدترین نقطه بررسی ضعیف حذف کنند، بدون اینکه توانایی همگامسازی تا سر زنجیره از دست برود. کلاینتها در حال حاضر درخواستها (که از طریق JSON-RPC میرسند) برای دادههای قبلی را با گرفتن آنها از پایگاههای داده محلی خود پردازش میکنند. با این حال، اگر دادههای درخواستشده حذف شده باشد، با انقضای تاریخچه این کار ممکن نخواهد بود. جهت پردازش دادههای قبلی، یک سری راهکارهای خلاقانه مورد نیاز است.
-
-یک گزینه این است که کلاینتهای دادههای قبلی را با استفاده از راهکاریی مانند «شبکه پورتال» درخواست کنند. «شبکه پورتال» یک شبکه همتابه همتای درحال توسعه برای پردازش دادههای قدیمی است که هر گره مقدار کوچکی از تاریخچه اتریوم را ذخیره میکند، بهطوری که کل تاریخچه در سراسر شبکه به صورت توزیعشده وجود دارد. درخواستها با جستجوی همتاهایی که دادههای مربوطه را ذخیره میکنند پردازش میشود، و دادهها را از آنها درخواست میکند. یا درعوض، از آنجایی که این برنامهها هستند که معمولاً نیاز به دسترسی به دادههای قبلی دارند، مسئولیت ذخیره آنها را میتوان به آنها داد. ممکن است به اندازه کافی بازیگرهای نوعدوست نیز در محیط اتریوم وجود داشته باشند که خواهان نگهداری آرشیوهای قدیمی باشند. میتواند یک DAO باشد که برای مدیریت فضای ذخیرهسازی دادههای قبلی راهاندازی میشود، یا در حالت ایدهآل ترکیبی از همه این گزینهها باشد. این ارائهدهندگان میتوانند دادهها را به روشهای بسیاری، از جمله تورنت، FTP، Filecoin یا IPFS پردازش کنند.
-
-انقضای تاریخچه بهنحوی بحثانگیز است، زیرا تاکنون اتریوم همیشه بهطور ضمنی دسترسی به دادههای قبلی را ضمانت کرده است. همگامسازی کامل از بلوک پیدایش همیشه بهعنوان استاندارد ممکن بوده است، حتی اگر متکی به بازسازی برخی از دادههای قدیمیتر اسنپشاتها باشد. انقضای تاریخچه این مسئولیتپذیری برای این تضمین را به خارج از پروتکل اصلی اتریوم منتقل میکند. اگر سازمانهای متمرکز در نهایت برای ارائه دادههای قبلی دخیل شوند، خطرات سانسور شدن جدیدی ممکن است پدید آید.
-
-EIP-4444 درحال حاضر آماده عرضه نیست، اما تحت بحث و بررسی فعال است. جالب است که چالشهای EIP-4444 زیاد جنبه فنی ندارد، اما اکثراً مربوط به مسائل مدیریت جامعه اتریوم است. به منظور عرضه آن، نه تنها نیاز به پذیرش جامعه اتریوم است، بلکه باید تعهداتی برای ذخیرهسازی و پردازش دادههای قبلی از نهادهای مورد اعتماد وجود داشته باشد.
-
-این ارتقا اصولاً نحوه مدیریت دادههای حالت توسط گرههای اتریوم را تغییر نمیدهد، بلکه فقط نحوه دسترسی به دادههای قبلی را تغییر میدهد.
-
-### انقضای حالت {#state-expiry}
-
-انقضای حالت به حذف حالت از گرههای منفرد اشاره دارد، درصورتی که اخیراً مورد دسترس قرار گرفته نشده باشند. برای اجرایی کردن آن چندین راه وجود دارد:
-
-- **انقضا با اجاره**: مطالبه «اجاره» از حسابها و انقضای آنها زمانیکه اجاره به صفر میرسد
-- **انقضا با زمان**: غیرفعال کردن حساب درصورتیکه خواندن/نوشتن دادهها در آن حساب برای مدت زمان خاصی وجود نداشته باشد
-
-انقضا با اجاره میتواند بهصورت مطالبه اجاره مستقیم از حسابها برای نگه داشتن آنها در پایگاه داده حالت فعال باشد. انقضا با زمان میتواند شمارش معکوس از آخرین تعامل حساب یا انقضای دورهای تمام حسابها باشد. همچنین مکانیزمیهایی میتواند وجود داشته باشد که عناصر هر دو مدل برپایه زمان و اجاره را ترکیب کند، برای مثال اگر حسابهای فردی قبل از انقضای زمانی هزینه اندکی بپردازند، حالت فعال آنها ادامه یابد. در انقضای حالت، باید توجه داشت که حالت فعال **حذفنشده** است، فقط جدا از حالت فعال ذخیره میشود. حالت غیرفعال را میتوان به حالت فعال بازیابی کرد.
-
-نحوه کار آن احتمالاً این طور خواهد بود که یک درخت حالت برای دورههای زمانی خاصی وجود داشته باشد (شاید حدود 1 سال). هر زمانی که یک دوره جدید شروع شود، یک درخت حالت جدید نیز ایجاد میشود. فقط درخت حالت کنونی قابل اصلاح است، مابقی درختها قابل تغییر نیستند. از گرههای اتریوم فقط انتظار میرود که درخت حالت کنونی و درخت حالت اخیر را نگهداری کند. این کار به روشی نیاز دارد که طی آن یک آدرس با دورهای که در آن موجود میباشد برچسب زمانی زده شود. [چندین روش ممکن](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) برای انجام این کار وجود دارد، اما بهترین گزینه [افزایش طول آدرسها](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) برای تطبیق با اطلاعات اضافی است و مزیت آدرسهای طولانیتر امنتر بودن آنها است. مورد «نقشه راه» که این کار را انجام میدهد [گسترش فضای آدرس](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) گفته میشود.
-
-مشابه انقضای تاریخچه، براساس انقضای حالت، مسئولیت ذخیرهسازی دادههای حالت از کاربران فردی برداشته میشود و به نهادهای دیگر از جمله ارائهدهندگان متمرکز، اعضای جامعه نوعدوست یا راهکارهای غیرمتمرکز مدرنتری نظیر «شبکه پورتال» محول میشود.
-
-انقضای وضعیت هنوز در مرحله تحقیقاتی است و هنوز آماده عرضه نیست. انقضای حال ممکن است پس از انقضای تاریخچه و کلاینتهای بیحالت روی دهد، زیرا آن ارتقاها حالت با اندازه بزرگ را برای اکثر اعتبارسنجها بهآسانی ممکن میسازد.
-
-## بیوضعیتی {#statelessness}
-
-بیحالتی تاحدی یک نامگذاری اشتباه است، زیرا به معنی مفهوم حذف شدن «حالت» نیست، بلکه شامل تغییراتی در نحوه مدیریت دادههای حالت توسط گرههای اتریوم میشود. «بیحالتی» خودش بر دو نوع خاص است: بیحالتی ضعیف و بیحالتی قوی. بیحالتی ضعیف با محول کردن مسئولیت ذخیرهسازی حالت به چندین گره آنها را بیحالت میکند. بیحالتی قوی نیاز گرهها به ذخیرهسازی دادههای حالت کامل را کلاً رفع میکند. هر دو بیحالتی ضعیف و قوی دارای مزایای زیر برای اعتبارسنجهای عادی هستند:
-
-- همگامسازی تقریباً فوری
-- توانایی اعتبارسنجی بدون نظم بلوکها
-- گرهها بتوانند با الزامات سختافزاری خیلی پایین اجرا شوند (برای مثال در تلفنها)
-- گرهها بتوانند روی هارد دیسکهای ارزان اجرا شوند، زیرا نیازی به خواندن/نوشتن روی دیسک وجود ندارد
-- سازگار بودن با ارتقاهای آینده رمزنگاری اتریوم
-
-### بیحالتی ضعیف {#weak-statelessness}
-
-بیحالتی ضعیف شامل تغییرات در نحوه تأیید تغییرات حالت توسط گرههای اتریوم نیست، اما این مسئله نیاز به ذخیرهسازی حالت را در تمام گرههای شبکه رفع نمیکند. درعوض، بیحالتی ضعیف مسئولیت ذخیرهسازی حالت را به پیشنهاددهندگان بلوک محول میکند، درحالی که سایر گرههای شبکه بدون ذخیرهسازی دادههای حالت کامل، بلوکها را تأیید میکنند.
-
-**در بیحالتی ضعیف، بلوکهای پیشنهاددهنده نیاز به دسترسی دادههای حالت کامل دارند، اما بلوکهای تأییدکننده به دادههای حالت نیاز ندارند**
-
-برای این رویداد، [درختهای ورکل](/roadmap/verkle-trees/) باید از قبل در کلاینتهای اتریوم پیادهسازی شده باشند. درختهای ورکل یک ساختار داده جایگزین برای ذخیرهسازی دادههای حالت اتریوم است که اجازه میدهد «شاهدهای» کوچک با اندازه ثابت در دادهها بین همتاها رد و بدل شود و برای تأیید بلوکها بهجای تأیید از طریق پایگاههای داده محلی استفاده شود. [تفکیک پیشنهاددهنده-سازنده](/roadmap/pbs/) نیز لازم است، زیرا این کار اجازه میدهد سازندگان بلوک گرههای خاص با سختافزار قویتر باشند و آنها گرههایی هستند که نیاز به دسترسی به دادههای حالت کامل دارند.
-
-
-
-بیحالتی به این بستگی دارد که سازندگان بلوک، یک نسخه از دادههای حالت کامل نگهداری کنند تا آنها بتوانند شاهدهایی تولید کنند که برای تأیید بلوک استفاده شود. سایر گرهها نیاز به دسترسی به دادههای حالت ندارند، تمام اطلاعات لازم برای تأیید بلوک در شاهد قابل دسترس است. این شرایطی بهوجود میآورد که پیشنهاد یک بلوک گران تمام میشود، اما تأیید بلوک ارزان است که حاکی از آن است که عملگرهای کمتری اجراکننده یک بلوک پیشنهاددهنده گره خواهند کرد. با این حال، تمرکززدایی پیشنهاددهندههای بلوک تا زمانیکه بسیاری از شرکتکنندهها بتوانند بهطور مستقل تأیید کنند که بلوکهای پیشنهادی معتبر است ضرورت ندارد.
-
-درباره یادداشتهای Dankrad بیشتر بخوانید
-
-
-پیشنهاددهندههای بلوک از دادههای حالت برای ایجاد «شاهدها» استفاده میکنند - حداقل مجموعه دادهایی که مقادیر حالت درحال تغییر توسط تراکنشها در یک بلوک را اثبات میکند. سایر اعتبارسنجها دربردارنده حالت نمیباشند، آنها صرفاً ریشه حالت را ذخیره میکنند (هش کل حالت). آنها یک بلوک و یک شاهد دریافت میکنند و از آنها برای بهروزرسانی ریشه حالت خود استفاده میکنند. این کار گره اعتبارسنجی را بهشدت سبک میکند.
-
-بیحالتی ضعیف یک حالت پیشرفته تحقیقاتی است، اما متکی به پیادهسازی تفکیک پیشنهاددهنده-سازنده و درختهای ورکل است تا بتوان شاهدهای کوچک را بین همتایان رد و بدل کرد. بهعبارتی بیحالتی ضعیف احتمالاً چند سال از «شبکه اصلی» فاصله دارد.
-
-### بیحالتی قوی {#strong-statelessness}
-
-بیحالتی قوی، نیاز به هرگونه گره برای ذخیره داده های حالت را از بین می برد. درعوض، تراکنشها با شاهدهایی ارسال میشوند که میتوان آنها را با ایجادکنندههای بلوک گردآوری کرد. از این رو، ایجادکنندههای بلوک درقبال ذخیرهسازی آن حالتی که برای ایجاد شاهدهای حسابهای مربوطه مورد نیاز است مسئول هستند. مسئولیت حالت تقربیاً بهطور کل به کاربران انتقال داده شده است، زیرا آنها شاهدها و «لیستهای دسترسی» را برای اعلام حسابها و کلیدهای ذخیرهسازی ارسال میکنند که با آنها تعامل دارند. این کار گرههای بسیار سبک را ممکن خواهد کرد، اما ریسکهایی وجود دارد، از جمله اینکه تعامل با قراردادهای هوشمند را مشکلتر میسازد.
-
-محققین بیحالتی قوی را مورد تحقیق قرار دادهاند، اما انتظار نمیرود اکنون بخشی از نقشهٔ راه اتریوم باشد - به احتمال بیشتر بیحالتی ضعیف برای نیازهای مقیاسپذیری اتریوم کافی است.
-
-## پیشرفت فعلی {#current-progress}
-
-بیحالتی ضعیف، انقضای تاریخچه و انقضای حالت همگی در مرحله تحقیق است و انتظار میرود چند سال بعد عرضه شوند. هیچ تضمینی وجود ندارد که تمام این پیشنهادها پیادهسازی شوند، برای مثال، اگر انقضای حالت ابتدا پیادهسازی شود، ممکن است دیگر نیازی به پیادهسازی انقضای تاریخچه نباشد. همچنین موارد دیگری از نقشه راه وجود دارد، از جمله [درختهای ورکل](/roadmap/verkle-trees) و [تفکیک پیشنهاددهنده-سازنده](/roadmap/pbs) که باید اول تکمیل شود.
-
-## بیشتر بخوانید {#further-reading}
-
-- [بیحالتی ویتالیک AMA](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/)
-- [نظریه مدیریت اندازه حالت](https://hackmd.io/@vbuterin/state_size_management)
-- [وابستگی حالت کمینهسازی-بازیابی-تضاد](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739)
-- [مسیرها به بیحالتی و انقضای حالت](https://hackmd.io/@vbuterin/state_expiry_paths)
-- [خصوصیات EIP-4444](https://eips.ethereum.org/EIPS/eip-4444)
-- [Alex Stokes پیرامون EIP-4444](https://youtu.be/SfDC_qUZaos)
-- [چرا بیحالت شدن آنقدر اهمیت دارد](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html)
-- [یادداشتهای اصلی مفهوم کلاینت بیحالت](https://ethresear.ch/t/the-stateless-client-concept/172)
-- [اطلاعات بیشتر درباره انقضای حالت](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry)
-- [باز هم اطلاعات بیشتر درباره انقضای حالت](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry)
diff --git a/public/content/translations/fa/12) Roadmap 2/roadmap/verkle-trees/index.md b/public/content/translations/fa/12) Roadmap 2/roadmap/verkle-trees/index.md
deleted file mode 100644
index aeadcd6c7ef..00000000000
--- a/public/content/translations/fa/12) Roadmap 2/roadmap/verkle-trees/index.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: درختان ورکل
-description: شرح تخصصی درختان ورکل و نقش کاربردی آن در ارتقای شبکه اتریوم
-lang: fa
-summaryPoints:
- - درباره ماهیت درختان ورکل بیشتر بدانید
- - درباره دلیل اهمیت درختان ورکل به عنوان یک ارتقای سودمند برای اتریوم بخوانید
----
-
-# درختان ورکل {#verkle-trees}
-
-درختان ورکل (ترکیب دو واژۀ «تعهد وکتور» و «درختان مرکل») نوعی ساختار دادهها است که در ارتقای گرههای اتریوم مورد استفاده قرار میگیرد. بر مبنای این ارتقا گرهها میتوانند بدون ذخیره کردن حجم وسیعی از دادههای حالت، همچنان بلوکها را تأیید کنند.
-
-## بیوضعیتی {#statelessness}
-
-درختان ورکل یک گام بنیادی در مسیر رسیدن به کلاینتهای بیحالت اتریوم است. کلاینتهای بیحالت آنهایی هستند که نیاز نیست برای تأیید و اعتباربخشی به بلوکهای ورودی، کل پایگاه دادۀ حالتها را ذخیره کنند. کلاینتهای بیحالت به جای ذخیرهسازی یک کپی محلی از حالت اتریوم جهت تأیید بلوکها، از یک «شاهد» برای دادههای حالت که همراه با بلوک از راه میرسد استفاده میکنند. شاهد عبارت است از مجموعهای از قطعههای مجزای دادههای حالت که برای اجرایی شدن برخی از مجموعه تراکنشها لازم است، و اثبات رمزنگاریشده که شاهد به واقع بخشی از یک مجموعه کامل از دادهها است. شاهد _به جای_ پایگاه دادۀ حالتها مورد استفاده قرار میگیرد. برای اینکه این مکانیزم کارا باشد، شاهدها باید حجم بسیار اندکی داشته باشند تا بتوانند بهطور ایمن و به موقع در سرتاسر شبکه پخش شوند و اعتبارسنجها بتوانند آنها را در داخل یک اسلات 12 ثانیهای پردازش کنند. ساختار فعلی دادههای حالت مناسب نیست، چرا که حجم شاهدها بسیار زیاد است. درختان ورکل با کوچک کردن حجم شاهدها این مسئله را حل میکنند تا یکی از موانع اصلی سد راه کلاینتهای بیحالت برداشته شود.
-
-
-
-کلاینتهای اتریوم درحال حاضر از یک ساختار داده به نام Patricia Merkle Trie جهت ذخیرهسازی دادههای حالت استفاده میکنند. اطلاعات حسابهای فردی در قالب برگهای درخت پیشوندی (ترای) ذخیره میشوند و جفتهای برگها به طور مکرر هش میشوند تا وقتی که تنها یک هش منفرد باقی بماند. این هش آخر به عنوان «ریشه» شناخته میشود. کلاینتهای اتریوم برای تأیید کردن بلوکها، تمام تراکنشها را در یک بلوک پیادهسازی میکنند و ترای حالت محلی خودشان را بهروزرسانی میکنند. اگر ریشه درخت محلی با آن درختی که پیشنهاددهندۀ بلوک ارائه کرده است یکی باشد، اعتبار بلوک تأیید میشود، چون هرگونه تفاوتی میان محاسبات صورتگرفته توسط پیشنهاددهندۀ بلوک و گرۀ اعتبارسنج باعث میشود هش نهایی ریشه کاملاً متفاوت باشد. در این روش، مشکل اساسی این است که برای تأیید اعتبار زنجیره بلوکی، هر کلاینت باید کل ترای حالت را برای بلوک صدر و چند بلوک قبلی ذخیره کند (پیشفرض Geth این است که دادههای حالت برای 128 بلوک قبل از بلوک صدر نگهداری شود). این موضوع نیازمند این است که کلاینتها به فضای ذخیرهسازی بزرگی دسترسی داشته باشند، و این مسئله مانعی است برایاجرای گرهها با هزینه کم و سختافزار کممصرف. راه حل این مشکل بهروزرسانی ترای حالت و ساختاری بهینهتر (درختان ورکل) است که بتوان آن را با استفاده از یک «شاهد» کوچک برای دادههایی که به جای کل دادههای حالت قابل اشتراکگذاری باشد خلاصه کرد. تغییر شکل ساختار دادههای حالت به درختان ورکل یک گام بنیادی و بزرگ در مسیر رسیدن به کلاینتهای بیحالت است.
-
-
-
-## شاهد چیست و چرا به آن نیاز داریم؟ {#what-is-a-witness}
-
-تأیید اعتبار یک بلوک به معنای دوباره اجرا کردن تراکنشهای موجود در آن، اعمال تغییرات در ترای حالت اتریوم، و محاسبات هش ریشۀ جدید است. بلوک تأییدشده در واقع بلوکی است که هش ریشۀ حالت آن پس از محاسبه با هشی که همراه بلوک ارائه شده است یکی باشد (این نشان میدهد که پیشنهاددهندۀ بلوک محاسبات مورد ادعایش را واقعاً انجام داده است). درحال حاضر کلاینتهای اتریوم برای بروزرسانی حالت نیازمند دسترسی به کل ترای حالت هستند. این ترای نوع بزرگی از ساختار دادههاست که باید بهصورت محلی ذخیرهسازی شود. شاهد تنها شامل قطعاتی از کل دادههای حالت را که برای اجرای تراکنشها در یک بلوک نیاز است دربر دارد. سپس، اعتبارسنج میتواند فقط با همان قطعات، تأیید کند که پیشنهاددهندۀ بلوک تراکنشهای بلوک را اجرا و حالت را بهدرستی بهروزرسانی کرده است. با این حال، این روند مستلزم انتقال سریع شاهدها بین همتایان موجود در شبکه اتریوم است به طوری که توسط هر کدام از گرهها در یک اسلات 12 ثانیهای به روشی امن دریافت و پردازش شوند. اگر شاهد حجم زیادی داشته باشد، ممکن است دانلود آن و همپا شدن با زنجیره برای بعضی از گرهها خیلی زمان ببرد. این روند یک عامل متمرکزسازی محسوب میشود، چون فقط گرههایی که به اینترنت پرسرعتتر دسترسی دارند میتوانند در اعتبارسنجی بلوکها سهیم شوند. با استفاده از مکانیزم درختان ورکل دیگر نیازی نیست دادههای حالت را بر روی هارد خود ذخیره کنید؛ _هر چیزی_ که برای تأیید اعتبار بلوک نیاز دارید در خود بلوک قرار گرفته است. متأسفانه، شاهدهایی که توسط ترایهای مرکل قابل تولید هستند حجم بالایی دارند و به همین خاطر از کلاینتهای بیحالت پشتیبانی نمیکنند.
-
-## چرا مکانیزم درختان ورکل شاهدهای کمحجمتری ایجاد میکنند؟ {#why-do-verkle-trees-enable-smaller-witnesses}
-
-ساختار ترای مرکل شاهدهای بسیار بزرگی ایجاد میکند، آنقدر بزرگ که پخش امن آنها بین همتایان در داخل یک اسلات 12 ثانیهای میسر نمیشود. این بدان خاطر است که شاهد درواقع مسیری رابط بین دادهها (که در برگها نگه داشته میشود) به هش ریشه است. تأیید اعتبار دادهها نه تنها مستلزم داشتن تمام هشهای واسط است که هر برگ را به ریشه متصل میکنند، بلکه داشتن تمام گرههای «همخانواده» نیز ضروری است. هر گره در روند اثبات دارای گرههای همخانوادهای است که با آن هش میشود تا هش بعدی را در بالای ترای ایجاد کند. حجم این اطلاعات بسیار زیاد است. درختان ورکل با کاهش فاصله میان برگهای درخت و ریشه آن و همچنین مرتفع کردن نیاز به ارائه گرههای همخانوده برای تأیید هش ریشه، حجم شاهدها را کاهش میدهند. حتی با استفاده از طرح تعهد چندجملهای قدرتمند به جای تعهد وکتوری هشمحور، میتوان فضای مورد نیاز برای ذخیرهسازی را بهینهتر کرد. تعهد چندجملهای این امکان را فراهم میکند که شاهد، فارغ از تعداد برگهایی که ثابت میکند، اندازه ثابتی داشته باشند.
-
-بر مبنای طرح تعهد چندجملهای، حجم شاهدها مدیریت میشود و به راحتی در شبکه همتا به همتا قابل انتقال است. این امر به کلاینتها اجازه میدهد تا تغییرات در حالت هر بلوک را با کمترین میزان دادهها تأیید کنند.
-
-
-
-حجم هر شاهد به تعداد برگهایی که دربر دارد وابسته است. تصور کنید یک شاهد 1000 برگ را پوشش دهد. حجم یک شاهد برای یک ترای مرکل در حدود 3.5 مگابایت میشود (با فرض وجود 7 سطح تا رسیدن به ترای). حجم یک شاهد برای همان دادهها در درختان ورکل (با فرض وجود 4 سطح تا رسیدن به درخت)، در حدود 150 کیلوبایت خواهد بود، یعنی تقریباً **23 برابر کوچکتر**. این کاهش حجم در شاهدها به شاهدهای کلاینتهای بیحالت این امکان را میدهد که در حد قابل قبولی کوچک شوند. شاهدهای چند جمله ای بسته به اینکه کدام تعهد چند جمله ای خاص استفاده می شود بین 0.128 تا 1 کیلوبایت هستند.
-
-
-
-## ساختار درخت ورکل چیست؟ {#what-is-the-structure-of-a-verkle-tree}
-
-درختان ورکل جفتهای `(کلید،ارزش)` هستند که در آنها کلیدها عبارتند از عناصری با حجم 32 بایت که از یک _ساقه_ 31 بایتی و یک _پسوند_ تکبایتی تشکیل شدهاند. این کلیدها به گرههای _افزونه_ و گرههای _داخلی_ طبقهبندی میشوند. گرههای افزونه بازنمای یک ساقه منفرد 256 فرزندی با پسوندهای متمایز است. گرههای داخلی هم 256 فرزند دارند، اما آنها میتوانند جزء سایر گرههای افزونه باشند. تفاوت اصلی میان ساختار درخت ورکل و درخت مرکل این است که درخت ورکل مسطحتر است، یعنی تعداد گرههای واسط که یک برگ را به ریشه وصل میکنند کمتر است، و بنابراین به دادههای کمتری برای ایجاد یک اثبات نیاز است.
-
-![](./verkle.png)
-
-[درباره ساختار درختان ورکل بیشتر بخوانید](https://blog.ethereum.org/2021/12/02/verkle-tree-structure)
-
-## پیشرفت فعلی {#current-progress}
-
-در حال حاضر شبکههای تست درختان ورکل هماکنون برقرار و درحال اجراست، اما هنوز هم جای بهروزرسانیهایی اساسی روی کلاینتها دارد که برای پشتیبانی از درختان ورکل نیاز است. میتوانید با بهکارگیری قراردادها در شبکههای تست یا اجرای کلاینتهای شبکه تست، پیشرفت آن را سرعت دهید.
-
-[شبکه آزمایشی Verkle Gen Devnet 2 را کاوش کنید](https://verkle-gen-devnet-2.ethpandaops.io/)
-
-[ Condrieu Verkle Guillaume Ballet را تماشا کنید شبکه آزمایشی Condrieu Verkle را توضیح دهید](https://www.youtube.com/watch?v=cPLHFBeC0Vg)(توجه داشته باشید که شبکه آزمایشی Condrieu اثبات کار بود و اکنون توسط Verkle Gen Devnet 2 testnet جایگزین شده است).
-
-## بیشتر بخوانید {#further-reading}
-
-- [درختان Verkle برای بیتابعیتی](https://verkle.info/)
-- [Dankrad Feist درباره درختان ورکل روی PEEPanEIP توضیح میدهد](https://www.youtube.com/watch?v=RGJOQHzg3UQ)
-- [Guillaume Ballet درباره درختان ورکل در ETHGlobal توضیح میدهد](https://www.youtube.com/watch?v=f7bEtX3Z57o)
-- [«چگونه درختان ورکل اتریوم را مختصر و مفید میکنند» از Guillaume Ballet در دِوکان 6](https://www.youtube.com/watch?v=Q7rStTKwuYs)
-- [Piper Merriam از ETHDenver 2020 درباره کلاینتهای بیحالت میگوید](https://www.youtube.com/watch?v=0yiZJNciIJ4)
-- [دانکارد فیست در پادکست Zero Knowledge درختان ورکل و بیحالتی را توضیح میدهد](https://zeroknowledge.fm/episode-202-stateless-ethereum-verkle-tries-with-dankrad-feist/)
-- [Vitalik Buterin درباره درختان ورکل میگوید](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
-- [Dankrad Feist درباره درختان ورکل میگوید](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)
-- [مستندات مربوط به EIP درختان ورکل](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/accounts/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/accounts/index.md
deleted file mode 100644
index 9613b68f342..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/accounts/index.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: حسابهای اتریوم
-description: توضیحی برای حسابهای اتریوم - ساختار دادههایشان و ارتباطشان با رمزنگاری جفت کلیدی.
-lang: fa
----
-
-حساب اتریوم موجودیتی است شامل موجودی اتر (ETH) که میتواند در اتریوم تراکنش ارسال کند. حسابهای کاربری میتوانند توسط کاربر کنترل شوند یا بهعنوان قرارداد هوشمند مورد استفاده قرار بگیرند.
-
-## پیشنیازها {#prerequisites}
-
-برای کمک به بهتر فهمیدن این صفحه، ایتدا خواندن [معرفی اتریوم](/developers/docs/intro-to-ethereum/) را توصیه می کنیم.
-
-## نوع حسابها {#types-of-account}
-
-اتریوم، دو نوع اکانت دارد:
-
-- حساب مالکیت خارجی (EOA) - توسط هر کسی که کلید خصوصی را دارد کنترل می شود
-- حساب قرارداد - یک قرارداد هوشمند مستقر در شبکه که توسط کد کنترل می شود. دربارهی [قراردادهای هوشمند](/developers/docs/smart-contracts/) بیشتر بدانید
-
-هر دو نوع حساب توانایی این را دارند که:
-
-- میتوانند اتر و توکنها را دریافت کنند، نگه دارند، و ارسال کنند
-- با قراردادهای هوشمند بکارگرفتهشده تعامل کنند
-
-### تفاوتهای کلیدی {#key-differences}
-
-**مالکیت خارجی**
-
-- ساختن یک حساب هیچ هزینهای ندارد
-- میتواند تراکنشها را آغاز کند
-- تراکنشهای مابین حسابهایی با مالکیت خارجی تنها میتوانند بهصورت انتقال توکن یا اتر باشند
-- از یک جفت کلید رمزنگاری تشکیل شده است: کلیدهای عمومی و خصوصی که فعالیت های حساب را کنترل می کنند
-
-**قرارداد**
-
-- ساخت یک قرار داد به علت استفاده شما از حافظهی شبکه دارای هزینه است
-- تنها میتوانند در پاسخ به دریافت یک تراکنش یک تراکنش بفرستند
-- تراکنشهای مابین یک حساب خارجی و یک حساب قراردادی میتوانند کدی راهاندازی کنند که میتواند کارهای مختلفی انجام دهد، از انتقال توکنها گرفته تا ساخت قرارداد جدید
-- حساب های قراردادی کلید خصوصی ندارند. در عوض، آنها با منطق کد قرارداد هوشمند کنترل می شوند
-
-## بررسی یک حساب {#an-account-examined}
-
-حسابهای اتریوم دارای چهار فیلد هستند:
-
-- `Nonce` – شمارنده ای که تعداد تراکنش ارسالی از هر حساب مالکیت-خارجی به شبکه یا تعداد قرارداد های ایجاد شده توسط هر حساب قراردادی را نشان میدهد. برای جلوگیری از حمله اجرای مجدد (reply attack) که در آن تراکنش های امضا شده به طور مکرر به شبکه ارسال و اجرا میشوند، با هر Nonce تنها یک تراکنش میتواند اجرا شود.
-- `موجودی` - مقدار wei تحت مالکیت این آدرس wei واحد شمارش اتریوم است و هر اتریوم 10 به توان هجده wei است.
-- `codeHash` – هش به _کد_ یک حساب موجود در ماشین مجازی اتریوم (EVM) اشاره دارد. حساب قرارداد دارای قطعه کدهای برنامهنویسیشده است که میتوانند عملیاتهای متفاوتی را انجام دهند. این کد EVM در صورتی که حساب پیام تلفنی دریافت کند اجرا خواهد شد. برخلاف مابقی بخشهای حساب، نمیتوان آن را تغییر داد. تمام قطعات کد موجود تحت هش متناسب خود برای بازیابیهای بعدی در دیتابیس قرار گرفتهاند. مقدار این هش به عنوان codeHash شناخته میشود. برای حسابهای مالکیت خارجی، فیلد این codeHash یک رشته خالی هش شده است.
-- `storageRoot` - که بهعنوان حافظهی هش نیز شناخته میشود. یک هش 256 بیتی از گره ریشهای از یک درختوارهی هش Merkle Patricia است که محتویات حافظهی حساب را رمزگذاری میکند (نگاشتی میان مقادیر صحیح 256 بیتی)، که بهصورت یک درختوارهی هش بهعنوان نگاشتی از هش 256 بیتی Keccak از کلیدهای اعداد صحیح 256 بیتی بر روی کلیدهایی رمزنگاریشده است، با RLP با مقادیر صحیح 256 بیتی رمزنگاری میشود. این درختوارهی هش محتویات حافظهی حساب را رمزنگاری میکند، و بهصورت پیشفرض خالی است.
-
-![یک نمودار که ساختن یک حساب را نشان میدهد](./accounts.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## حسابهای دارای مالکیت خارجی و جفت کلیدها {#externally-owned-accounts-and-key-pairs}
-
-یک حساب کاربری از یک جفت کلید رمزنگاری تشکیل شده است: عمومی و خصوصی. به کمک این دو کلید میتوان ثابت کرد که یک تراکنش از طریق فرستنده بوده و از جعل جلوگیری میکند. کلید خصوصی شما همان چیزی است که برای امضای تراکنش از آن استفاده میکنید، پس اختیار شما بر وجوه مرتبط با حسابتان را تأیید میکند. بنابراین در واقع شما رمزارزی نگهداری نمیکنید، شما کلید خصوصی را نگه میدارید - سرمایهی شما همیشه در دفتر کل اتریوم نگهداری میشود.
-
-و با این کار جلوی عاملان بداندیشی که میخواهند اطلاعات تقلبی بفرستند را میگیرد، زیرا شما میتوانید اثبات کنید چه کسی فرستندهی تراکنش بوده است.
-
-اگر آلیس میخواهد به حساب باب اتر بفرستد، باید یک تراکنش ایجاد کند و آن را به شبکه بفرستد تا تأیید شود. استفاده از کلید عمومی رمزنگاری به آلیس این امکان را میدهد که اثبات کند او فرستندهی این تراکنش بوده است. بدون استفاده از این مکانیزم، یک آدم بداندیش فرضی به اسم ایو میتواند بهآسانی درخواستی شبیه «از حساب آلیس به حساب ایو 5 اتر ارسال شود» را منتشر کند، و هیجکس نمیتواند اثبات کند که این درخواست از طرف آلیس نبوده است.
-
-## ساختن حساب {#account-creation}
-
-هنگامی که میخواهید یک حساب بسازید، اکثر کتابخانهها یک کلید خصوصی تصادفی برای شما تولید می کنند.
-
-یک کلید خصوصی از 64 کاراکتر هگز تشکیل شده است که میتواند به وسیلهی یک گذرواژه رمزنگاری شود.
-
-مثال:
-
-`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f`
-
-کلید عمومی با استفاده از [الگوریتم امضای دیجیتال منحنی بیضوی](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) از کلید خصوصی ساخته میشود. شما با حذف 20 بایت انتهایی هش keccak-256 کلید عمومی خود و افزودن `0X` در ابتدای آن یک آدرس عمومی برای حسابتان خواهید داشت.
-
-این بدان معناست که یک حساب دارای مالکیت خارجی (EOA) دارای یک آدرس 42 کاراکتری است (بخش 20 بایتی که 40 کاراکتر هگزا دسیمال به اضافه پیشوند `0x` است).
-
-مثال:
-
-`0x5e97870f263700f46aa00d967821199b9bc5a120`
-
-مثال زیر نحوه استفاده از ابزار امضا به نام [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) را برای ایجاد یک حساب جدید نشان می دهد. Clef یک ابزار مدیریت و امضای حساب است که همراه با مشتری اتریوم، [Geth](https://geth.ethereum.org) ارائه میشود. دستور `clef newaccount` یک جفت کلید جدید ایجاد می کند و آنها را در یک فروشگاه کلید رمزگذاری شده ذخیره می کند.
-
-```
-> کلید حساب جدید --keystore
-
-لطفا یک رمز عبور برای ایجاد حساب جدید وارد کنید:
-> <رمز عبور>
-
-------------
-INFO [10-28|16:19:09.156] کلید جدید شما ایجاد شد آدرس=0x5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] لطفاً از مسیر فایل کلید خود نسخه پشتیبان تهیه کنید=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e9737000f200f201b60b201b60b201b66b66b66b66b61b69b69b60b6b6b6b6b5b6b6b5b6b5b6b6b5b6b6b5b6b5b6b6b5b10b6b5b6b5b10b6b5b6b5b6b5b5b5b5b5b5b5b5b5bwd
-هشدار [10-28|16:19:09.306] لطفا رمز عبور خود را به خاطر بسپارید!
-حساب ایجاد شده 0x5e97870f263700f46aa00d967821199b9bc5a120
-```
-
-[مستندات Geth](https://geth.ethereum.org/docs)
-
-شما میتوانید از کلید خصوصی خود کلیدهای عمومی جدید به دست بیاورید، اما نمیتوانید از کلیدهای عمومی کلید خصوصی به دست بیاورید. ایمن و همانطور که از نام آن پیداست یعنی **خصوصی** نگه داشتن کلیدهای خصوصی، حیاتی است.
-
-شما برای امضای پیامها و تراکنشهایی را که خروجی امضا دارند به کلید خصوصی نیاز دارید. دیگران متعاقباً میتوانند امضای شما را دریافت کنند و به وسیلهی آن از کلید عمومی شما مشتق بگیرند، و نویسندهی پیام را ثابت کنند. در برنامهتان، می توانید از کتابخانه جاوا اسکریپت برای ارسال تراکنش ها به شبکه استفاده کنید.
-
-## حسابهای قرارداد {#contract-accounts}
-
-حسابهای قرارداد نیز دارای یک آدرس حاوی 42 کاراکتر هگز هستند:
-
-مثال:
-
-`0x06012c8cf97bead5deae237070f9587f8e7a266d`
-
-آدرس قرارداد معمولا وقتی داده میشود که قرارداد توسط زنجیرهی بلوکی اتریوم گسترش داده میشود. آدرس از طریق سازندهی آدرس و عدد تراکنش آن آدرس («Nonce») میآید.
-
-## کلیدهای اعتبار سنج {#validators-keys}
-
-همچنین نوع دیگری از کلید در اتریوم وجود دارد که زمانی معرفی شد که اتریوم از اثبات کار به اجماع مبتنی بر اثبات سهام تغییر کرد. اینها کلیدهای 'BLS' هستند و برای شناسایی اعتبارسنج ها استفاده می شوند. این کلیدها را می توان به طور مؤثر جمع کرد تا پهنای باند مورد نیاز برای رسیدن به اجماع شبکه را کاهش دهد. بدون این تجمیع کلید، حداقل سهام برای یک اعتبارسنج بسیار بیشتر میشد.
-
-[اطلاعات بیشتر در مورد کلیدهای اعتبارسنج](/developers/docs/consensus-mechanisms/pos/keys/).
-
-## یادداشتی درباره کیف پولها {#a-note-on-wallets}
-
-حساب با کیف پول متفاوت است. کیفپول یک رابط یا برنامه ای است که به شما امکان می دهد با حساب اتریوم خود، چه یک حساب خارجی یا یک حساب قراردادی، تعامل داشته باشید.
-
-## یک نسخهی آزمایشی تصویری {#a-visual-demo}
-
-آستین را مشاهده کنید که توابع هش و جفت کلیدها را توضیح میدهد.
-
-
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [درک حساب های اتریوم](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
-- [تراکنشها](/developers/docs/transactions/)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/blocks/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/blocks/index.md
deleted file mode 100644
index 77c0b1a2d76..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/blocks/index.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-title: بلوکها
-description: یک بررسی اجمالی از بلوکها در زنجیرهی بلوکی اتریوم - ساختار دادههای آن، چرا مورد نیاز هستند و چگونه ساخته میشوند.
-lang: fa
----
-
-بلوکها دستههایی از تراکنش با یک هش به بلوک قبلی خود در زنجیره هستند. این کار بلوکها را (در یک زنجیره) به هم متصل میکند، چون هشها بهصورت رمزنگاریشده از دادههای بلوکها به دست میآیند. این کار همچنین از تقلب جلوگیری میکند، چرا که یک تغییر کوچک در هر بلوکی در تاریخچه تمام بلوکهای بعدی را از اعتبار خواهد انداخت چرا که تمام هشهای متعاقب تغییر خواهند کرد و هر کسی که زنجیرهی بلوکی را اجرا میکند متوجه خواهد شد.
-
-## پیشنیازها {#prerequisites}
-
-فهم بلوکها موضوعی ساده برای افراد مبتدی است. اما برای کمک به فهمیدن این صفحه، بهتر است [حسابها](/developers/docs/accounts/) ،[تراکنشها](/developers/docs/transactions/) و [مقدمهای بر اتریوم](/developers/docs/intro-to-ethereum/) را مطالعه کنید.
-
-## چرا بلوکها؟ {#why-blocks}
-
-برای اطمینان از این که تمام افرادی که در شبکهی اتریوم مشارکت دارند در یک وضعیت مشترک هستند و بر یک تاریخچهی مشترک از تراکنشهای توافق دارند، ما تراکنشها را به بلوکها دستهبندی میکنیم. این یعنی ده ها (یا صدها) تراکنش به صورت یکجا انجام میشوند و مورد توافق قرار می گیرند و همزمان به زنجیره اضافه می شوند.
-
-![یک نمودار که تراکنشهای یک بلوک که باعث تغییر وضعیت میشوند را نشان میدهد](./tx-block.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-با ایجاد فاصله زمانی بین هر بلاک، ما به همه شرکتکنندگان شبکه زمان کافی می دهیم که به اجماع ملحق شوند: این یعنی اگر ده ها درخواست ثبت عملیات جدید در ثانیه ارائه شود فقط هر دوازده ثانیه یک بار هر بلاک اتریوم به زنجیره اضافه می شود.
-
-## بلوکها چگونه کار میکنند {#how-blocks-work}
-
-برای حفظ تاریخچهی تراکنشها، بلوکها ترتیب کاملاً مشخصی دارند (هر بلوک جدیدی که ساخته میشود شامل یک ارجاع به بلوک والد خود است)، و تراکنشهای درون هر بلوک هم ترتیب کاملاً مشخصی دارند. جز در موارد نادر، همواره همهی مشارکتکنندگان شبکه بر سر تعداد دقیق و تاریخچهی بلوکها توافق دارند و در حال کار بر روی درخواستهای تراکنش در حال انجام فعلی برای بلوک بعدی هستند.
-
-زمانی که یک بلاک توسط یک اعتبارسنج که رندم انتخاب شده است داخل شبکه گذاشته میشود، این به بقیه شبکه تکثیر می شود، همه گرهها این بلاک را به زنجیره خود اضافه می کنند و اعتبارسنج جدید برای بلاک بعدی انتخاب می شود. فرایند اضافه شدن بلاک و اجماع/تعهد در حال حاضر با پروتکل اثبات سهام اتریوم مشخص می شود.
-
-## پروتکل اثبات سهام {#proof-of-work-protocol}
-
-پروتکل اثبات سهام دارای معانی زیر می باشد:
-
-- گرههای اعتبارسنجی باید مقدار 32 اتر در یک قرارداد مشخص سهامگذاری کنند تا در برابر رفتارهای خطا به عنوان یک وثیقه عمل کند. این موضوع به امنیت شبکه کمک می کند چون اقدامات غیر صادقانه می تواند بخشی از دارایهای سهامگذاری شده یا تمام آن را از بین ببرد.
-- در هر اسلات ( فاصله زمانی دوازده ثانیه بین هر بلاک) یک اعتبارسنج بصورت تصادفی به عنوان پیشنهاد دهنده بلاک انتخاب می شود. آنها تراکنشها را با یکدیگر جمع می کنند و آنها را اجرا می کنند و و یک «حالت» جدید را در زنجیره ایجاد می کنند. آنها این داده ها را داخل یک بلاک جمع می کنند و آن را برای دیگر اعتبارسنجها انتقال می دهند.
-- باقی اعتبارسنجها که این اطلاعات را دریافت کرده اند، خود آن بلاک را اجرا می کنند تا از صحت تغییرات اعمال شده به حالت کلی بلاک چین مطمئن شوند. با فرض این که یک بلاک درست است، آنها می توانند آن را به دیتا بیس خود اضافه کنند.
-- اگر یک اعتبارسنج متوجه شود که دو بلاک همزمان در یک اسلات تایید شده اند از الگوریتم فورک استفاده می کنند و آن بلاکی را اضافه می کند که اتر بیشتری را سهام گذاری کرده است.
-
-[اطلاعات بیشتر دربارهی اثبات سهام](/developers/docs/consensus-mechanisms/pos)
-
-## چه چیزی در یک بلوک است؟ {#block-anatomy}
-
-مقدار زیادی اطلاعات داخل یک بلوک می باشد. در بالاترین سطح، یک بلوک دارای فیلدهای زیر می باشد:
-
-| میدان | توضیح |
-|:---------------- |:-------------------------------------------------------------------- |
-| `اسلات` | اسلاتی که بلوک به آن متعلق است |
-| `proposer_index` | شناسه اعتبارسنجی که بلاک را پیشنهاد میکند |
-| `parent_root` | هش بلاک قبلی |
-| `state_root` | هش ریشه موضوع حالت |
-| `body` | یک موضوع چندین فیلد را داخل خود ذخیره می کند که در زیر ارائه شده است |
-
-`بدنه` بلاک که خود دارای چندین فیلد می باشد:
-
-| میدان | توضیح |
-|:-------------------- |:------------------------------------------------------------------------- |
-| `randao_reveal` | یک مقدار که برای تعیین پیشنهاددهنده بلاک بعدی استفاده می شود |
-| `eth1_data` | اطلاعاتی در مورد قرارداد سپرده |
-| `graffiti` | داده اختیاری که برای تگ بلاکها استفاده می شود |
-| `proposer_slashings` | لیست اعتبارسنجهایی که قرار است اسلش شوند |
-| `attester_slashings` | لیست گواهیدهندگانی که باید اسلش یا جریمه شوند |
-| `تصدیقها` | لیست تصدیقهایی که بلاک فعلی را تایید میکنند |
-| `سپرده` | لیست سپردههای جدید مربوط به قرارداد سپرده |
-| `voluntary_exits` | لیست اعتبارسنجهای در حال خروج از شبکه |
-| `sync_aggregate` | زیر مجموعه ای از اعتبارسنجهایی که برای کاربرهای رقیق سرویس رسانی می کنند |
-| `execution_payload` | تراکنشهایی که از کاربرهای اجرایی عبور کرده اند |
-
-فیلد `تصدیق ها` که در واقع لیستی از تمام تصدیق های بلاک می باشد. تصدیق ها دارای اطلاعات مربوط به خود هستند که چندین قطعه داده را داخل خود دارند. هر تصدیق دارای اطلاعات زیر می باشد:
-
-| میدان | توضیح |
-|:------------------ |:--------------------------------------------------- |
-| `aggregation_bits` | لیستی از اعتبارسنجها که در این تصدیق شرکت کرده اند |
-| `دادهها` | یک کانتینر که چند تا فیلد فرعی دارد |
-| `امضا` | یک امضا گروهی از تمام اعتبارسنجهای تصدیق کننده |
-
-فیلد `داده` در `تصدیق` شامل موارد زیر می باشد:
-
-| میدان | توضیح |
-|:------------------- |:------------------------------------------------------ |
-| `اسلات` | اسلات مربوط به تصدیق |
-| `index` | شاخصهای مربوط به اعتبارسنجهای تصدیق |
-| `beacon_block_root` | هش ریشه مربوط به بلاک بیکن که این موضوع را در خود دارد |
-| `منبع` | آخرین نقطه بازرسی تایید شده |
-| `target` | آخرین بلاک مرز ایپوک |
-
-اجرا کردن تراکنشها داخل `محل اجراها` باعث اپدیت شدن حالت کلی بلاکچین می شود. تمام کاربرها نراکنشهای مربوط به `محل اجرای` بلاکها را مجددا اجرا می کنند که مطمئن شوند که حالت جدید با فیلد `ریشه بلاک` همخوانی دارد. با این فرایند کاربرها می توانند اعلام کنند که یک بلاک معتبر است و برای اضافه شدن به بلاک چین آنها امنیت دارد. `محل اجراها` نیز خود داری چندین فیلد می باشد. همچنین یک تیتر با عنوان `محل اجرا` وجود دارد که خلاصه ای از دادههای اجرا را در خود نگه می دارد. ساختارهای داده مطابق زیر سازماندهی میشوند:
-
-`تیتر یا سربرگ محل اجرا` که فیلدهای زیر را دارد:
-
-| میدان | توضیح |
-|:------------------- |:------------------------------------------------------- |
-| `parent_hash` | هش بلاک والد |
-| `fee_recipient` | آدرس حسابی که قرار است کارمزد تراکنش به آن پرداخت شود |
-| `state_root` | هش ریشه مربوط به حالت کلی بعد از اعمال تغییرات این بلاک |
-| `receipts_root` | هش رسیدهای تراکنش |
-| `logs_bloom` | ساختار داده ها دارای گزارشهای رویداد |
-| `prev_randao` | مقدار استفاده شده در انتخاب اعتبارسنج تصادفی |
-| `block_number` | شماره بلاک فعلی |
-| `gas_limit` | ماگزیمم گاز اجازه داده شده در این بلاک |
-| `gas_used` | مقدار واقعی گاز استفاده شده در این بلاک |
-| `برچسب زمان` | زمان بلاک |
-| `extra_data` | اطلاعات اضافی دلخواه به عنوان بایتهای خام |
-| `base_fee_per_gas` | مقدار کارمزد پایه |
-| `block_hash` | هش بلاک اجرایی |
-| `transactions_root` | هش ریشه تراکنشها داخل محل اجرا |
-| `withdrawal_root` | هش ریشه برداشتها در محل اجرا |
-
-`محل اجرا` نیز خود دارای موارد زیر است (توجه کنید که این با سربرگ یکی است، جز این که به جای هش ریشه تراکنشها، شامل لیست واقعی تراکنشها و اطلاعات برداشت است):
-
-| میدان | توضیح |
-|:------------------ |:------------------------------------------------------- |
-| `parent_hash` | هش بلاک والد |
-| `fee_recipient` | آدرس حسابی که قرار است کارمزد تراکنش به آن پرداخت شود |
-| `state_root` | هش ریشه مربوط به حالت کلی بعد از اعمال تغییرات این بلاک |
-| `receipts_root` | هش رسیدهای تراکنش |
-| `logs_bloom` | ساختار داده ها دارای گزارشهای رویداد |
-| `prev_randao` | مقدار استفاده شده در انتخاب اعتبارسنج تصادفی |
-| `block_number` | شماره بلاک فعلی |
-| `gas_limit` | ماگزیمم گاز اجازه داده شده در این بلاک |
-| `gas_used` | مقدار واقعی گاز استفاده شده در این بلاک |
-| `برچسب زمان` | زمان بلاک |
-| `extra_data` | اطلاعات اضافی دلخواه به عنوان بایتهای خام |
-| `base_fee_per_gas` | مقدار کارمزد پایه |
-| `block_hash` | هش بلاک اجرایی |
-| `تراکنشها` | لیست تراکنشهایی که باید اجرا شوند |
-| `برداشت وجه` | لیست موضوعهای برداشت |
-
-لیست `برداشتها` شامل موضوعهای `برداشت` با ساختاربندی زیر:
-
-| میدان | توضیح |
-|:---------------- |:------------------------------- |
-| `آدرس` | آدرس حسابی که که برداشت شده است |
-| `مقدار` | مقدار برداشت شده |
-| `index` | مقدار شاخص برداشت |
-| `validatorIndex` | مقدار شاخص اعتبارسنج |
-
-## زمان بلوک {#block-time}
-
-زمان بلاک، به بلاکهای جدا شده از هم با زمان اشاره دارد. در اتریوم، زمان به دوره های دوازده ثانیه به نام 'اسلات' تقسیم شده است. در هر اسلات یک اعتبارسنج برای پیشنهاد دادن بلاک انتخاب میشود. با فرض اینکه تمام اعتبارسنجها آنلاین و کاملا آماده هستند، در هر اسلات یک بلوک به وجود می آید، و به این ترتیب زمان هر بلاک 12 ثانیه می شود. با این حال، گاهی اوقات اعتبار سنجی که قرار است بلاک را تایید کند آنلاین نیست تا بلاک را پیشنهاد دهد، در نتیجه اسلات بعضی اوقات خالی میماند.
-
-این اجرا با سیستمهای اثبات-کار که در آن طول زمانی بلوک ها احتمالی است و با سختی استخراج هدف پروتکل تغییر می کند متفاوت است. [زمان تقریبی هر بلاک](https://etherscan.io/chart/blocktime) در اتریوم مثال کاملی از این است که در آن گذار از اثبات کار به اثبات سهام میتواند به طور آشکار بر پایه هماهنگی زمان بلاک 12 ثانیهای جدید استنتاج شود.
-
-## اندازهی بلوک {#block-size}
-
-یک نکته مهم نهایی این است که خود بلوکها از نظر اندازه محدود هستند. هر بلوک یک اندازه هدف به میزان 15 میلیون گاز دارد، اما اندازه بلوکها میتواند بسته به تقاضای شبکه بیشتر یا کمتر شود و بیشترین حد آن 30 میلیون گاز است (2 برابر اندازه هدف بلوک). حد گس بلوک را میتوان با ضریب 1 به 1024 از حد گس بلوک قبلی به سمت بالا یا پایین تنظیم کرد. در نتیجه، اعتبار سنجها می توانند حد گس بلوک را از طریق اجماع تغییر دهند. مجموع کل گاز خرجشده توسط همه تراکنشها در بلوک باید کمتر از حد گاز بلوک باشد. این نکته مهمی است، چون تضمین میکند که یک بلوک نمیتواند بهاندازه دلخواه بزرگ باشد. اگر بلوکها بتوانند به اندازه دلخواه بزرگ باشند، آنگاه گرههای کاملی که اندکی قدرت کمتری دارند با توجه به سرعت و فضای مورد نیاز به تدریج نمیتوانند با شبکه پیش بیایند. هر چه بلوک بزرگتر باشد، توان محاسبه بیشتری برای پردازش به موقع آن در بلوک بعدی لازم است. این یک نیروی متمرکز کننده است، که با محدود کردن سایز بلوک محدود میشود.
-
-## بیشتر بدانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [تراکنشها](/developers/docs/transactions/)
-- [گاز](/developers/docs/gas/)
-- [اثبات سهام](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/dapps/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/dapps/index.md
deleted file mode 100644
index 5ff228dde35..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/dapps/index.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: مقدمه ای بر dappها
-description:
-lang: fa
----
-
-یک برنامهی غیرمتمرکز (dapp) برنامهای است که روی یک شبکهی غیرمتمرکز ساخته شده است و یک [قرارداد هوشمند](/developers/docs/smart-contracts/) را با یک رابط کاربری فرانتاند ترکیب میکند. در اتریوم، قراردادهای هوشمند در دسترس و شفاف هستند - مانند وب سرویسهای باز - بنابراین dapp شما حتی میتواند شامل قرارداد هوشمندی که شخص دیگری نوشته است نیز باشد.
-
-## پیشنیازها {#prerequisites}
-
-قبل از یادگیری در مورد dappها، باید [اصول زنجیرهی بلوکی](/developers/docs/intro-to-ethereum/) را بیاموزید و در مورد شبکهی اتریوم و نحوهی غیرمتمرکز بودن آن مطالعه کنید.
-
-## تعریف dapp {#definition-of-a-dapp}
-
-یک dapp کد بکاند خود را در یک شبکهی همتا به همتای غیرمتمرکز اجرا میکند. این را با برنامهای مقایسه کنید که کد بکاند آن روی سرورهای متمرکز اجرا میشود.
-
-یک dapp میتواند دارای کد فرانتاند و رابطهای کاربری باشد که به هر زبانی (درست مانند یک برنامه) برای برقراری تماس با بکاند خود نوشته شده است. علاوه بر این، بخش ظاهری آن میتواند در فضای ذخیرهسازی غیرمتمرکز مانند [IPFS](https://ipfs.io/) میزبانی شود.
-
-- **غیرمتمرکز** - dappها روی اتریوم به عنوان یک پلتفرم غیرمتمرکز عمومی باز کار میکنند که هیچ شخص یا گروهی آن را کنترل نمیکند
-- **قطعی** - dappها صرفنظر از محیطی که در آن اجرا میشوند عملکرد یکسانی دارند
-- **تورینگ کامل** - dappها میتوانند هر عملی را با توجه به منابع مورد نیاز انجام دهند
-- **ایزوله** - dappها در یک محیط مجازی به نام ماشین مجازی اتریوم اجرا میشوند تا اگر قرارداد هوشمند باگ داشته باشد، عملکرد عادی شبکهی زنجیرهی بلوکی را مختل نکند
-
-### دربارهی قراردادهای هوشمند {#on-smart-contracts}
-
-برای معرفی dappها، باید قراردادهای هوشمند را معرفی کنیم - چون اصطلاح بهتری نداریم آن را بکاند برای dapp مینامیم. برای یک نمای کلی دقیق، به بخش ما در مورد [قراردادهای هوشمند](/developers/docs/smart-contracts/) بروید.
-
-قرارداد هوشمند کدی است که بر روی زنجیرهی بلوکی اتریوم وجود دارد و دقیقاً طبق برنامه اجرا میشود. پس از استقرار قراردادهای هوشمند در شبکه، نمیتوانید آنها را تغییر دهید. dappها میتوانند غیرمتمرکز باشند، زیرا منطق نوشتهشده در قرارداد کنترلشان میکند، نه یک فرد یا شرکت. این مهم همچنین به این معنی است که شما باید قراردادهای خود را با دقت طراحی کنید و آنها را کاملاً آزمایش کنید.
-
-## مزایای توسعهی dapp {#benefits-of-dapp-development}
-
-- **خرابی صفر** – وقتی قراردادی هوشمند مستقر شده و روی زنجیرهی بلوکی قرار گرفته است، شبکه بهعنوان یک کل همیشه میتواند به کلاینتهایی که دنبال تعامل با قرارداد هستند خدماترسانی کند. بنابراین فعالان بداندیش نمیتوانند حملات به خدمات را با هدف قرار دادن dappهای منفرد آغاز کنند.
-- **حریم خصوصی** - برای استقرار یا تعامل با یک dapp، نیازی به ارائهی هویت واقعی ندارید.
-- **مقاومت در برابر سانسور** – هیچ نهاد واحدی در شبکه نمیتواند کاربران را از ارسال تراکنشها، استقرار dappها یا خواندن دادهها از زنجیرهی بلوکی منع کند.
-- **صحت و تمامیت کامل داده** - دادههای ذخیرهشده در زنجیرهی بلوکی، به لطف رمزنگاریهای اولیه، تغییرناپذیر و غیرقابلانکار هستند. عوامل بداندیش نمیتوانند تراکنشها یا سایر دادههایی را که قبلاً عمومی شدهاند، جعل کنند.
-- **محاسبات بدون اعتماد/رفتار قابل تأیید** – قراردادهای هوشمند را میتوان تجزیه و تحلیل کرد و تضمین کرد که به روشهای قابلپیشبینی و بدون نیاز به اعتماد به یک مقام مرکزی اجرا شوند. این مورد در مدلهای سنتی صادق نیست. به عنوان مثال، هنگامی که ما از سیستمهای بانکداری آنلاین استفاده میکنیم، باید اعتماد کنیم که مؤسسات مالی از دادههای مالی ما سوء استفاده نمیکنند، سوابق را دستکاری نمیکنند یا هک نمیشوند.
-
-## معایب توسعهی dapp {#drawbacks-of-dapp-development}
-
-- **نگهداری** – نگهداری از dappها دشوارتر است زیرا اصلاح کد و دادههای منتشر شده در زنجیرهی بلوکی سختتر است. برای توسعهدهندگان سخت است که بهروزرسانیهای dapp خود (یا دادههای زیربنایی ذخیرهشده توسط dapp) را پس از استقرار آنها انجام دهند، حتی اگر اشکالات یا خطرات امنیتی در نسخهی قدیمی شناسایی شدهباشند.
-- **سربار عملکرد** - سربار عملکرد بسیار زیادی وجود دارد، و مقیاسپذیری واقعاً سخت است. برای دستیابی به سطح امنیت، صحت و تمامیت، شفافیت و قابلیت اطمینان مورد نظر اتریوم، هر گره هر تراکنش را اجرا و ذخیره میکند. علاوه بر این، اجماع اثبات سهام نیز به زمان نیاز دارد.
-- **ازدحام شبکه** – وقتی یک برنامه از منابع محاسباتی بیش از حد استفاده میکند، از کل شبکه پشتیبانگیری میشود. در حال حاضر، شبکه فقط میتواند حدود 10-15 تراکنش را در ثانیه پردازش کند. اگر تراکنشها سریعتر از این ارسال شوند، مجموعه تراکنشهای تأیید نشده به سرعت میتواند افزایش یابد.
-- **تجربهی کاربری** – مهندسی تجربیات کاربرپسند ممکن است دشوارتر باشد، زیرا عموماً برای کاربر نهایی عادی سخت است که مجموعهای از ابزار لازم برای تعامل با زنجیرهی بلوکی را به شیوهای واقعاً ایمن را ایجاد کند.
-- **متمرکز کردن** – راهحلهای کاربرپسند و توسعهدهندهپسند ساختهشده بر روی لایهی پایه اتریوم ممکن است به هر حال شبیه سرویسهای متمرکز به نظر برسند. بهعنوان مثال، چنین سرویسهایی ممکن است کلیدها یا سایر اطلاعات حساس را در سمت سرور ذخیره کنند، با استفاده از یک سرور متمرکز یک فرانتاند ارائه دهند، یا قبل از نوشتن در زنجیرهی بلوکی، منطق تجاری مهمی را بر روی یک سرور متمرکز اجرا کنند. متمرکزسازی بسیاری از (اگر نه همه) مزایای زنجیرهی بلوکی را نسبت به مدل سنتی حذف میکند.
-
-## با تصویر راحتتر یاد میگیرید؟ {#visual-learner}
-
-
-
-## ابزارهایی برای ساخت dapps {#dapp-tools}
-
-**Scaffold-ETH _- بهسرعت Solidity را با استفاده از یک فرانتاند که با قرارداد هوشمندتان سازگار است آزمایش کنید._**
-
-- [گیتهاب](https://github.com/scaffold-eth/scaffold-eth-2)
-- [dapp نمونه](https://punkwallet.io/)
-
-**برنامهی اتریومی بسازید _- با یک فرمان برنامههای بر پایهی اتریوم بسازید._**
-
-- [گیتهاب](https://github.com/paulrberg/create-eth-app)
-
-**One Click Dapp _- ابزار FOSS برای تولید صفحات فرانت dapp از
-ABI.
-
-- [oneclickdapp.com](https://oneclickdapp.com)
-- [گیت هاب](https://github.com/oneclickdapp/oneclickdapp-v1)
-
-**Etherflow _- ابزار FOSS برای توسعهدهندگان اتریوم بهمنظور آزمایش گره خود، نوشتن و اشکالزدایی فراخوانیهای RPC از مرورگر._**
-
-- [etherflow.quiknode.io](https://etherflow.quiknode.io/)
-- [گیتهاب](https://github.com/abunsen/etherflow)
-
-**thirdweb _- کیت توسعهٔ نرمافزار به هر زبان، قراردادهای هوشمند، ابزارها، و زیرساخت توسعه Web3._**
-
-- [صفحه اصلی](https://thirdweb.com/)
-- [اسناد](https://portal.thirdweb.com/)
-- [گیت هاب](https://github.com/thirdweb-dev/)
-
-**پلتفرم Crossmint _- پلتفرم توسعه Web3 در سطح سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از API برای ایجاد، توزیع، فروش، ذخیره و ویرایش NFTها است._**
-
-- [crossmint.com](https://www.crossmint.com)
-- [اسناد](https://docs.crossmint.com)
-- [دیسکورد](https://discord.com/invite/crossmint)
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [کاوش در برنامههای غیرمتمرکز](/dapps)
-- [معماری یک اپلیکیشن Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _پریتی کسیردی_
-- [راهنمای 2021 برای اپلیکیشنهای غیرمتمرکز](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_
-- [اپلیکیشنهای غیرمتمرکز چه هستند؟](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_
-- [اپلیکیشنهای غیرمتمرکز پرطرفدار](https://www.alchemy.com/dapps) - _Alchemy_
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-
-
-## موضوعات مرتبط {#related-topics}
-
-- [مقدمه ای بر پشته اتریوم](/developers/docs/ethereum-stack/)
-- [چارچوبهای توسعه](/developers/docs/frameworks/)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/evm/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/evm/index.md
deleted file mode 100644
index a7a5d7ef135..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/evm/index.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: ماشین مجازی اتریوم (EVM)
-description: مقدمهای بر ماشین مجازی اتریوم و نحوه ارتباط آن با حالات متناهی، تراکنشها و قراردادهای هوشمند.
-lang: fa
----
-
-ماشین مجازی اتریوم (EVM) یک محیط مجازی غیرمتمرکز است که کد را به طور مداوم و ایمن در تمام گرههای اتریوم اجرا میکند. گرهها، EVM را برای اجرای قراردادهای هوشمند، با استفاده از "[گس](/gas/)" برای اندازه گیری تلاش محاسباتی مورد نیاز برای [عملیاتها](/developers/docs/evm/opcodes/) اجرا می کنند و تخصیص کارآمد منابع و امنیت شبکه را تضمین میکنند.
-
-## پیشنیازها {#prerequisites}
-
-برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/ Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و درخت مرکل.
-
-## از دفتر کل تا ماشین حالات متناهی {#from-ledger-to-state-machine}
-
-تشبیه «دفتر کل توزیعشده» اغلب برای توصیف زنجیرههای بلوکی مانند بیتکوین استفاده میشود که یک ارز غیرمتمرکز را با استفاده از ابزارهای بنیادین رمزنگاری امکانپذیر میسازد. دفتر کل سوابقی از فعالیت ها را حفظ می کند که باید به مجموعه ای از قوانین پایبند باشد که آنچه را که شخص می تواند و نمی تواند انجام دهد تا دفتر کل را اصلاح کند، تعیین می کنند. به عنوان مثال، یک آدرس بیت کوین نمیتواند بیت کوین بیشتری از آنچه قبلا دریافت کرده است خرج کند. این قوانین زیربنای تمامی تراکنشهای بیتکوین و بسیاری از زنجیرههای بلوکی دیگر است.
-
-در حالی که اتریوم دارای رمزارز بومی خود (اتر) است که تقریباً بهطور کامل از قوانین شهودی مشابهی پیروی میکند، کارکرد بسیار قدرتمندتری را نیز ممکن میسازد: [قراردادهای هوشمند](/developers/docs/smart-contracts/). برای این ویژگی پیچیدهتر، قیاس پیچیدهتری نیز لازم است. به جای یک دفتر کل توزیع شده، اتریوم یک [ماشین حالات متناهی](https://wikipedia.org/wiki/Finite-state_machine) توزیعشده است. وضعیت اتریوم یک ساختار دادهی بزرگ است که نهتنها همه حسابها و موجودیها را در خود نگه میدارد، بلکه _وضعیت ماشین_ را نیز در خود جای میدهد که میتواند طبق مجموعهای از قوانین از پیش تعریفشده از بلوکی به بلوک دیگر تغییر کند و کد ماشینی دلخواه را اجرا کند. قوانین خاص تغییر حالت از بلوک به بلوک توسط EVM تعریف شده است.
-
-![نموداری که ساختار EVM را نشان میدهد](./evm.png) _نمودار برگرفته از[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## تابع گذار حالت اتریوم {#the-ethereum-state-transition-function}
-
-EVM مانند یک تابع ریاضی عمل میکند: با توجه به یک ورودی، یک خروجی قطعی تولید میکند. از این رو توصیف رسمیتر اتریوم به عنوان دارندهی یک **تابع گذار وضعیت** بسیار مفید است:
-
-```
-Y(S, T)= S'
-```
-
-با توجه به یک وضعیت معتبر قدیمی `(S)` و مجموعه جدیدی از تراکنشهای معتبر `(T)`، تابع گذار وضعیت اتریوم `Y(S, T)` یک وضعیت خروجی معتبر جدید `S'` ایجاد میکند
-
-### وضعیت {#state}
-
-در زمینهی اتریوم، وضعیتْ یک ساختار دادهای عظیم به نام [درخت مارکل پاتریشیای اصلاحشده](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) است که همهی [حسابها](/developers/docs/accounts/) را با هش مرتبط نگه میدارد و به یک هش ریشهای که در زنجیرهی بلوکی ذخیرهشده قابل تقلیل است.
-
-### تراکنشها {#transactions}
-
-تراکنشها دستورالعملهایی هستند که به صورت رمزنگاری از حسابها امضا میشوند. دو نوع تراکنش وجود دارد: آنهایی که منجر به فراخوانی یک پیام میشوند و آنهایی که منجر به ایجاد یک قرارداد میشوند.
-
-ایجاد قرارداد منجر به ایجاد یک حساب قرارداد جدید میشود که حاوی [قرارداد هوشمند](/developers/docs/smart-contracts/anatomy/) بایتکد کامپایلشده است. هر زمان که حساب دیگری یک پیام فراخوانی با آن قرارداد برقرار کند، بایتکد آن قرارداد را اجرا میکند.
-
-## دستورالعملهای EVM {#evm-instructions}
-
-EVM به صورت یک [ماشین پشتهای](https://wikipedia.org/wiki/Stack_machine) با عمق 1024 آیتم اجرا میشود. هر آیتم یک کلمهی 256 بیتی است که برای سهولت استفاده با رمزنگاری 256 بیتی (مانند هش Keccak-256 یا امضاهای secp256k1) انتخاب شده است.
-
-در طول اجرا، EVM یک _حافظه_ گذرا (به عنوان یک آرایه بایت آدرسدهی کلمه) را حفظ میکند که بین تراکنشها باقی نمیماند.
-
-با این حال، قراردادها حاوی یک درخت _حافظه_ مرکل پاتریشیا (بهعنوان یک آرایه کلمه قابل آدرسدهی به کلمه) هستند که با حساب موردنظر و بخشی از حالت همگانی مرتبط است.
-
-بایتکد قرارداد هوشمند کامپایلشده به صورت تعدادی [کدگذاریهای](/developers/docs/evm/opcodes) EVM اجرا میشود که عملیاتهای استاندارد پشته مانند `XOR`، `AND `، `ADD`، `SUB` و غیره را انجام میدهد. EVM همچنین تعدادی عملیات پشتهی مخصوص زنجیرهی بلوکی را نیز اجرا میکند، مانند `ADDRESS`، `BALANCE`، `BLOCKHASH` و غیره.
-
-![نموداری که نشان میدهد کجا گاز برای عملیات EVM موردنیاز است](../gas/gas.png) _نمودارها برگرفته از[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## پیادهسازی EVM {#evm-implementations}
-
-تمام پیادهسازیهای EVM باید به مشخصاتی که در یلو پیپر اتریوم توضیح داده شده است پایبند باشند.
-
-در تاریخ 9 ساله اتریوم، EVM دستخوش چندین بازنگری شده است و چندین اجرا و پیادهسازی از EVM در زبان های مختلف برنامه نویسی وجود دارد.
-
-[کاربرهای اجرای اتریوم](/developers/docs/nodes-and-clients/#execution-clients) شامل یک اجرای EVM هستند. علاوه بر این، چندین اجرای مستقل وجود دارد، از جمله:
-
-- [Py-EVM](https://github.com/ethereum/py-evm) - _پایتون_
-- [evmone](https://github.com/ethereum/evmone) - _سیپلاسپلاس_
-- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _جاوا اسکریپت_
-- [revm](https://github.com/bluealloy/revm) - _Rust_
-
-## اطلاعات بیشتر {#further-reading}
-
-- [یلو پیپر اتریوم](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [Jellopaper با نام مستعار KEVM: معناشناسی EVM در K](https://jellopaper.org/)
-- [بژپیپر](https://github.com/chronaeon/beigepaper)
-- [کدگذاریهای ماشین مجازی اتریوم](https://www.ethervm.io/)
-- [مرجع تعاملی کدگذاری های ماشین مجازی اتریوم](https://www.evm.codes/)
-- [مقدمهای کوتاه در مستندات Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
-- [تسلط بر اتریوم - ماشین مجازی اتریوم](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc)
-
-## موضوعات مرتبط {#related-topics}
-
-- [گاز](/developers/docs/gas/)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/evm/opcodes/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/evm/opcodes/index.md
deleted file mode 100644
index faeac85aa50..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/evm/opcodes/index.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-title: کدگذاری ها برای ماشین مجازی اتریوم (EVM)
-description: لیستی از همه کدگذاری های (opcodes) موجود برای ماشین مجازی اتریوم (EVM).
-lang: fa
----
-
-## نگاه اجمالی {#overview}
-
-این یک نسخه بروز شده از صفحه مرجع EVM در [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) است. همچنین از [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)، [Jello Paper](https://jellopaper.org/evm/) و پیادهسازیِ [geth](https://github.com/ethereum/go-ethereum) گرفته شده است. این به عنوان یک مرجع قابل دسترس در نظر گرفته شده است، اما به شکل ویژه دقیق نیست. اگر میخواهید از درستی هر حالت خاصی که نرمافزار در آن قرار میگیرد مطمئن باشید، توصیه میشود از Jello Paper یا پیادهسازی کاربر استفاده کنید.
-
-به دنبال یک مرجع تعاملی هستید؟ پس اینجا را ببینید [evm.codes](https://www.evm.codes/).
-
-برای عملیات هایی با هزینه گس پویا، به [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md) مراجعه کنید.
-
-💡 نکته: برای مشاهده کل خطوط، از `[shift] + scroll` استفاده کنید تا به صورت افقی روی صفحه حرکت کنید.
-
-| پشته | نام | گاز | پشته اولیه | پشته حاصل شده | حافظه | یادداشت ها |
-|:-----:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 00 | STOP | 0 | | | | halt execution |
-| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 |
-| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 |
-| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 |
-| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division |
-| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division |
-| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus |
-| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus |
-| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N |
-| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N |
-| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 |
-| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes |
-| 0C-0F | _invalid_ | | | | | |
-| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than |
-| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than |
-| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than |
-| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than |
-| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality |
-| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero |
-| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND |
-| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR |
-| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR |
-| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT |
-| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left |
-| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left |
-| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right |
-| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right |
-| 1E-1F | _invalid_ | | | | | |
-| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
-| 21-2F | _invalid_ | | | | | |
-| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract |
-| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei |
-| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx |
-| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender |
-| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei |
-| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` |
-| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes |
-| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data |
-| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes |
-| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode |
-| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
-| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes |
-| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` |
-| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes |
-| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
-| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `هش` | | hash = addr.exists ? keccak256(addr.code) : 0 |
-| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `.` | `block.coinbase` | | آدرس پیشنهاد دهنده بلوک فعلی |
-| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block |
-| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block |
-| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon |
-| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block |
-| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
-| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei |
-| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block |
-| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
-| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
-| 4B-4F | _invalid_ | | | | | |
-| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it |
-| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
-| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory |
-| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory |
-| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage |
-| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage |
-| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest |
-| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` |
-| 58 | PC | 2 | `.` | `$pc` | | program counter |
-| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes |
-| 5A | GAS | 2 | `.` | `gasRemaining` | | |
-| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | write word to transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copy memory from one area to another ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
-| 5F | PUSH0 | 2 | `.` | `uint8` | | مقدار ثابت 0 را روی پشته هُل دهید |
-| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack |
-| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack |
-| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack |
-| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack |
-| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack |
-| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack |
-| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack |
-| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack |
-| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack |
-| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack |
-| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack |
-| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack |
-| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack |
-| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack |
-| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack |
-| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack |
-| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack |
-| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack |
-| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack |
-| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack |
-| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack |
-| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack |
-| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack |
-| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack |
-| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack |
-| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack |
-| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack |
-| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack |
-| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack |
-| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack |
-| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack |
-| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack |
-| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack |
-| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack |
-| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack |
-| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack |
-| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack |
-| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack |
-| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack |
-| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack |
-| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack |
-| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack |
-| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack |
-| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack |
-| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack |
-| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack |
-| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack |
-| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack |
-| 90 | SWAP1 | 3 | `a, b` | `b, a` | | |
-| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | |
-| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | |
-| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | |
-| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
-| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) |
-| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
-| A5-EF | _invalid_ | | | | | |
-| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
-| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen
| `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
-| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] |
-| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
-| F6-F9 | _invalid_ | | | | | |
-| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| FB-FC | _invalid_ | | | | | |
-| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
-| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract |
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md
deleted file mode 100644
index df39471d21f..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/gas/index.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: گس و کارمزدها
-description:
-lang: fa
----
-
-گاز برای شبکهی اتریوم حیاتی است. سوختی است که به شبکه امکان کار کردن میدهد، همانطور که یک اتومبیل نیاز به بنزین دارد.
-
-## پیشنیازها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه میشود که ابتدا [تراکنشها](/developers/docs/transactions/) و [ماشین مجازی اتریوم](/developers/docs/evm/) را مطالعه کنید.
-
-## گاز چیست؟ {#what-is-gas}
-
-گاز به واحدی گفته میشود که میزان زحمت محاسباتی موردنیاز را برای اجرای یک عمل خاص در شبکهی اتریوم اندازهگیری میکند.
-
-از آنجا که هر تراکنش اتریوم برای اجرا به منابع محاسباتی نیاز دارد، این منابع باید پرداخت شوند تا اطمینان حاصل شود که اتریوم در برابر اسپم آسیب پذیر نیست و نمی تواند در حلقه های محاسباتی نامحدود گیر کند. پرداخت برای محاسبه به شکل کارمزد گاز انجام می شود.
-
-کارمزد گاز **مقدار گازی است که برای انجام عملیات استفاده می شود، ضربدر هزینه هر واحد گاز**. کارمزد صرف نظر از موفقیت یا شکست یک تراکنش پرداخت می شود.
-
-![نموداری که نشان میدهد کجا گاز در عملیاتهای EVM مورد نیاز است](./gas.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-کارمزد گاز باید با ارز بومی اتریوم یعنی اتر (ETH) پرداخت شود. قیمت گاز معمولا برحسب Gwei، که یکی از شاخه های ETH است، بیان می شود. هر Gwei برابر با یک میلیاردم ETH است (0.000000001 ETH یا 10-9 ETH).
-
-برای مثال به جای این که بگوییم گاز 0.000000001 اتر است، میتوانید بگویید گاز به انداره 1 gwei است.
-
-کلمه 'Gwei' مخفف 'Giga-wei' است که به معنای 'میلیارد wei' است. یک Gwei برابر یک میلیارد wei است. Wei (نامگذاری شده از [wei Dai](https://wikipedia.org/wiki/Wei_Dai) سازنده [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) خود کوچکترین واحد اتر است.
-
-## چگونه کارمزدهای گاز محاسبه می شوند؟ {#how-are-gas-fees-calculated}
-
-می توانید مقدار گازی را که مایل به پرداخت آن هستید در هنگام ارائه یک تراکنش تنظیم کنید. با پیشنهاد مقدار مشخصی گاز، پیشنهاد می کنید که تراکنش شما در بلاک بعدی قرار گیرد. اگر مبلغ بسیار کمی پیشنهاد دهید، اعتبارسنج ها احتمال کمتری دارند که تراکنش شما را برای ورود انتخاب کنند، به این معنی که ممکن است تراکنش شما دیر انجام شود یا اصلا انجام نشود. اگر بیش از حد پیشنهاد دهید، ممکن است مقداری ETH را هدر دهید. بنابراین، چگونه می توانید بگویید که چقدر باید پرداخت کنید؟
-
-مجموع گاز که پرداخت می کنید به دو بخش تقسیم می شود: `کارمزد پایه` و `کارمزد اولویت` (انعام).
-
-`کارمزد پایه` توسط پروتکل تعیین می شود - شما باید حداقل این مبلغ را پرداخت کنید تا تراکنش شما معتبر تلقی شود. `کارمزد اولویت` انعامی است که شما به کارمزد پایه اضافه می کنید تا تراکنش شما برای اعتبارسنجان جذاب شود تا آنها آن را برای ورود به بلاک بعدی انتخاب کنند.
-
-تراکنشی که تنها `کارمزد پایه` را پرداخت می کند، از نظر فنی معتبر است اما احتمال شامل شدن آن بعید به نظر می رسد زیرا هیچ انگیزه ای برای اعتبارسنجان وجود ندارد که آن را نسبت به تراکنش های دیگر انتخاب کنند. کارمزد `اولویت` "صحیح" با استفاده از شبکه در زمانی که تراکنش خود را ارسال می کنید تعیین می شود - اگر تقاضای زیادی وجود داشته باشد، ممکن است مجبور شوید کارمزد `اولویت` خود را بالاتر تنظیم کنید، اما وقتی تقاضای کمتری وجود داشته باشد، می توانید هزینه کمتری پرداخت کنید.
-
-برای مثال، فرض کنید جردن باید 1 ETH به تیلور بپردازد. یک انتقال ETH به 21000 واحد گاز نیاز دارد و هزینه پایه 10 Gwei است. جردن 2 gwei را بهعنوان انعام اضافه میکند.
-
-حال هزینه کل برابر است با:
-
-`واحدهای گاز مصرفی * (کارمزد پایه + کارمزد اولویت)`
-
-که در آن `کارمزد پایه` مقداری است که توسط پروتکل تعیین می شود و `کارمزد اولویت` مقداری است که توسط کاربر به عنوان انعام به اعتبارسنج تعیین می شود.
-
-یعنی `21,000 * (10 + 2) = 252,000 Gwei` (یا 0.000252 ETH).
-
-زمانی که جردن پول را میفرستد، 1.000252 اتر از حساب جردن کم میشود. تیلور 1.0000 اتر دریافت میکند. اعتبارسنج انعام 0.000042 ETH را دریافت می کند. `هزینه پایه` به مقدار 0.00021 ETH سوزانده می شود.
-
-### کارمزد پایه {#base-fee}
-
-هر بلوک یک کارمزد پایه دارد که بهعنوان قیمت ذخیره عمل میکند. جهت احراز شرایط برای گنجانده شدن در بلوک، قیمت ارائه شده برای گاز باید حداقل به اندازه کارمزد پایه باشد. کارمزد پایه بهطور مستقل از این بلوک محاسبه میشود و توسط بلوکهای قبلی مشخص میشود - که باعث میشود کارمزدهای تراکنش برای کاربران پیشبینیپذیرتر باشند. هنگامی که بلوک ایجاد می شود این **هزینه پایه "سوزانده" می شود** و از گردش خارج می شود.
-
-کارمزد پایه توسط فرمولی که اندازه بلوک قبلی (مقدار گازی که توسط تمام تراکنشها استفاده میشود) را با اندازه هدف مقایسه میکند، محاسبه میشود. اگر اندازه بلوک از اندازه هدف بلوک بیشتر شود، کارمزد پایه حداکثر به اندازه 12.5% در هر بلوک افزایش مییابد. این رشد نمایی باعث میشود که از نظر اقتصادی بهصرفه نباشد که اندازه بلوک تا ابد بالا بماند.
-
-| شمارهی بلوک | گاز لحاظشده | افزایش کارمزد | کارمزد پایهی فعلی |
-| ------------ | ------------:| -------------:| ------------------:|
-| 1 | 15 میلیون | 0% | 100 gwei |
-| 2 | 30 میلیون | 0% | 100 gwei |
-| 3 | 30 میلیون | 12.5% | 112.5 gwei |
-| 4 | 30 میلیون | 12.5% | 126.6 gwei |
-| 5 | 30 میلیون | 12.5% | 142.4 gwei |
-| 6 | 30 میلیون | 12.5% | 160.2 gwei |
-| 7 | 30 میلیون | 12.5% | 180.2 gwei |
-| 8 | 30 میلیون | 12.5% | 202.7 gwei |
-
-با توجه به جدول فوق - برای ثبت یک تراکنش در بلوک شماره 9 یک کیف پول به کاربر اجازه میدهد که با قطعیت بداند که **حداکثر کارمزد پایه** که به بلوک بعدی اضافه میشود برابر با `کارمزد پایه فعلی * 112.5%` یا `202.7 gwei * 112.5% = 228.1 gwei` خواهد بود.
-
-همچنین باید خاطرنشان کرد احتمال اینکه بلوکهای پر ادامه پیدا کنند، به دلیل سرعت بالا رفتن کارمزد پایه قبل از یک بلوک پر، کم است.
-
-| شمارهی بلوک | گاز لحاظشده | افزایش کارمزد | کارمزد پایهی فعلی |
-| ------------ | ------------:| -------------:| ------------------:|
-| 30 | 30 میلیون | 12.5% | 2705.6 gwei |
-| ... | ... | 12.5% | ... |
-| 50 | 30 میلیون | 12.5% | 28531.3 gwei |
-| ... | ... | 12.5% | ... |
-| 100 | 30 میلیون | 12.5% | 10302608.6 gwei |
-
-### کارمزد اولویت (انعام) {#priority-fee}
-
-کارمزد اولویت (انعام) اعتبارسنجان را تشویق می کند تا یک تراکنش را در بلوک بگنجانند. بدون انعام، برای اعتبارسنجان از نظر اقتصادی به صرفه است که بلوکهای خالی را استخراج کنند چرا که همان میزان پاداش بلوک را دریافت میکنند. انعام های کم به اعتبارسنجان انگیزه حداقلی برای گنجاندن یک تراکنش می دهند. برای این که تراکنشها ترجیحاً زودتر از بقیه تراکنشها در بلوک یکسان گنجانده شوند، انعام بیشتری می تواند اضافه شود تا از تراکنش های رقیب پیشی بگیرند.
-
-### حداکثر کارمزد {#maxfee}
-
-برای اجرای یک تراکنش در شبکه، کاربران میتوانند برای پرداخت کارمزد تراکنششان سقف مشخص کنند. این پارامتر دلخواه به نام `maxFeePerGas` شناخته میشود. برای اجرای یک تراکنش، حداکثر کارمزد باید از مجموع کارمزد پایه و انعام بیشتر باشد. فرستنده تراکنش تفاضل حداکثر کارمزد و مجموع کارمزد پایه و انعام را بازپس خواهد گرفت.
-
-### اندازه بلوک {#block-size}
-
-هر بلوک اندازه هدفی به اندازه 15 میلیون گاز دارد اما سایز بلوکها میتواند بسته به تقاضای شبکه بیشتر یا کمتر شود و بیشترین حد آن 30 میلیون گاز است (2 برابر اندازه بلوک). پروتکل از طریق فرایند _tâtonnement_ بهطور میانگین به اندازه بلوک متوازن 15 میلیون دست مییابد. این بدین معنا است که اگر اندازه بلوک از اندازه هدف بلوک بیشتر باشد، پروتکل کارمزد پایه را برای بلوک بعدی بیشتر میکند. به صورتی مشابه، پروتکل زمانی که اندازه بلوک از اندازه هدف بلوک کمتر باشد کارمزد پایه را کاهش میدهد. مقداری که کارمزد پایه با آن تنظیم میشود بستگی به فاصله اندازه بلوک از اندازه هدف دارد. [اطلاعات بیشتر درباره بلوکها](/developers/docs/blocks/).
-
-### محاسبه کارمزدهای گاز در عمل {#calculating-fees-in-practice}
-
-می توانید به صراحت اعلام کنید که برای اجرای تراکنش خود حاضر به پرداخت چه مبلغی هستید. با این حال، اکثر ارائه دهندگان کیف پول به طور خودکار کارمزد تراکنش پیشنهادی (کارمزد پایه + کارمزد اولویت توصیه شده) را تنظیم خواهند کرد تا میزان پیچیدگی تحمیل شده بر کاربران خود را کاهش دهند.
-
-## چرا کارمزد گاز وجود دارد؟ {#why-do-gas-fees-exist}
-
-به طور خلاصه، کارمزد گاز به حفظ امنیت شبکه اتریوم کمک میکند. با درخواست کارمزد برای اجرای هر محاسبه روی شبکه، ما از اسپم کردن شبکه توسط خرابکاران جلوگیری میکنیم. برای جلوگیری از حلقههای بینهایت خواسته یا ناخواسته یا دیگر هدررفتهای محاسباتی در کد، هر تراکنش لازم است مشخص کند که چند گام محاسباتی از اجرای کد را میتواند استفاده کند. واحد محاسباتی پایه «گاز» است.
-
-هر چند که تراکنش حدی دارد، اما گاز استفاده نشده در یک تراکنش به کاربر بازگردانده میشود (یعنی `حداکثر کارمزد - (کارمزد پایه + انعام)` برگردانده میشود).
-
-![شکلی نشاندهندهی نحوهی بازپرداخت گاز مصرفنشده](../transactions/gas-tx.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-## حد گاز چیست؟ {#what-is-gas-limit}
-
-حد گاز به حداکثر میزان گازی که میخواهید برای یک تراکنش مصرف کنید گفته میشود. تراکنشهای پیچیدهتر شامل [قراردادهای هوشمند](/developers/docs/smart-contracts/) نیاز به کار محاسباتی بیشتر دارند، در نتیجه نسبت به یک پرداخت ساده نیاز به حد گاز بالاتری دارند. یک انتقال استاندارد اتر نیاز به حد گازی برابر با 21,0000 واحد گاز دارد.
-
-برای مثال اگر حد گاز را برای یک انتقال ساده اتر برابر با 50,000 قرار دهید، ماشین مجازی اتریوم 21,000 عدد را مصرف کرده و شما 29,000 عدد مانده را پس میگیرید. هر چند، اگر گاز بسیار پایینی مشخص کنید، برای مثال حد گاز برابر 20,000 برای یک انتقال ساده اتر، ماشین مجازی اتریوم همه 20,000 واحد گاز را مصرف میکند تا تراکنش را انجام دهد اما تراکنش کامل نخواهد شد. ماشین مجازی اتریوم همه تغییرات را برمیگرداند اما از آنجا که اعتبارسنج به اندازه 20,000 واحد گاز کار کرده است، آن گاز مصرف میشود.
-
-## چرا کارمزد گاز میتواند انقدر زیاد شود؟ {#why-can-gas-fees-get-so-high}
-
-بالا بودن کارمزد گاز به دلیل محبوبیت اتریوم است. اگر تقاضای بیش از حد وجود داشته باشد، کاربران باید انعام بیشتری بدهند تا تلاش کنند از تراکنشهای دیگر کاربران جلو بیفتند. انعام بیشتر میتواند باعث شود احتمال اینکه تراکنش در بلوک بعدی ثبت شود بیشتر شود. همچنین، اپلیکیشن های پیچیدهتر قرارداد هوشمند ممکن است عملیات زیادی برای پشتیبانی از عملکردهای خود انجام دهند و باعث شوند آن ها گاز زیادی مصرف کنند.
-
-## ابتکارها برای کاهش هزینههای گاز {#initiatives-to-reduce-gas-costs}
-
-[ارتقاهای مقیاسپذیری](/roadmap/) اتریوم در نهایت باید به برخی از مسائل مربوط به کارمزد گاز رسیدگی کند، که به نوبه خود، پلتفرم را قادر میسازد تا هزاران تراکنش را در ثانیه پردازش کند و در سطح جهانی مقیاسپذیر شود.
-
-مقیاسپذیری لایه 2 یک ابتکار اولیه برای بهبود هزینه گاز، تجربه کاربری و مقیاسپذیری است. [اطلاعات بیشتر درباره مقیاسپذیری لایه 2](/developers/docs/scaling/#layer-2-scaling).
-
-## نظارت بر کارمزدهای گس {#monitoring-gas-fees}
-
-اگر میخواهید قیمت گاز را رصد کنید، تا بتوانید اترتان را با هزینه کمتری بفرستید، میتوانید از ابزارهای متفاوتی مثل موارد زیر استفاده کنید:
-
-- [Etherscan](https://etherscan.io/gastracker) _تخمینزنندهی قیمت گاز تراکنش_
-- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _افزونه Chrome برای تخمین گاز با پشتیبانی تراکنشهای نوع 0 میراث (Legacy) و تراکنشهای نوع 2 EIP-1559._
-- [ماشین حساب کارمزد گاز Cryptoneur](https://www.cryptoneur.xyz/gas-fees-calculator) _کارمزد گاز را برای انواع مختلف تراکنش در Mainnet و Arbitrum و Polygon به ارز محلی خود محاسبه کنید._
-
-## ابزارهای مرتبط {#related-tools}
-
-- [پلتفرم گاز Blocknative](https://www.blocknative.com/gas) _وب سرویس تخمین گاز تحت پشتیبانی پلفترم داده استخر حافظه جهانی Blocknative_
-
-## بیشتر بخوانید {#further-reading}
-
-- [توضیحی دربارهی گاز اتریوم](https://defiprime.com/gas)
-- [کاهش مصرف گاز قراردادهای هوشمندتان](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
-- [اثبات سهام در مقابل اثبات کار](https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/)
-- [استراتژی های بهینهسازی گاز برای توسعه دهندگان](https://www.alchemy.com/overviews/solidity-gas-optimization)
-- [اسناد EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
-- [منابع تیم بیکو درباره EIP-1559](https://hackmd.io/@timbeiko/1559-resources).
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/index.md
deleted file mode 100644
index 78e4465405a..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/index.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: اسناد توسعه اتریوم
-description: معرفی مستندات توسعه ethereum.org.
-lang: fa
----
-
-مستندات برای کمک به شما برای ساختن با اتریوم طراحی شدهاند. این مستندات، اتریوم را در مقام یک مفهوم شرح میدهد، پشته فناوری اتریوم را توضیح میدهد و موضوعات پیشرفته را برای اپلیکیشنها و موارد پیچیدهتر مستند میکند.
-
-مستندات به کوشش جامعه متن باز تهیه میشود، پس برای پیشنهاد دادن موضوعات جدید، افزودن محتوای جدید، ساخت مثال و هرچیزی که فکر میکنید مفید است راحت باشید. تمام مستندات میتوانند در گیتهاب ویرایش شوند - اگر مطمئن نیستید چگونه میتوان این کار را انجام دارد، [ این دستورالعملها را دنبال کنید](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
-
-## ماژولهای توسعه {#development-modules}
-
-اگر این اولین تلاش شما برای توسعه اتریوم است، به شما پیشنهاد میکنیم یادگیری و کار را از طریق یک کتاب شروع کنید.
-
-### موضوعات بنیادی {#foundational-topics}
-
-
-
-### پشتهی اتریوم {#ethereum-stack}
-
-
-
-### پیشرفته {#advanced}
-
-
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ether/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ether/index.md
deleted file mode 100644
index dfe1a1ac5fe..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ether/index.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: معرفی اتر
-description: معرفی ارز رمزنگاریشده اتر برای توسعهدهندگان
-lang: fa
----
-
-## پیشنیازها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه میشود که ابتدا [مقدمهای بر اتریوم](/developers/docs/intro-to-ethereum/) مطالعه شود.
-
-## ارز رمزنگاریشده چیست؟ {#what-is-a-cryptocurrency}
-
-ارزهای رمزنگاریشده واسطهی تبادلی است که توسط یک دفتر کل مبتنی بر زنجیرهی بلوکی ایمن میشود.
-
-واسطهی تبادل هر چیزی است که بهطور گسترده بهعنوان پرداخت برای کالاها و خدمات پذیرفته میشود، و دفتر کل یک نگهدارندهی داده است که تراکنش ها را پیگیری میکند. فناوری زنجیرهی بلوکی به کاربران این امکان را میدهد تا بدون اتکا به شخص ثالث قابلاعتماد برای نگهداری دفتر کل، تراکنشهای خود را در دفتر کل انجام دهند.
-
-اولین ارز رمزنگاری شده بیتکوین بود که توسط ساتوشی ناکاموتو خلق شد. از زمان عرضهی بیتکوین در سال 2009، مردم هزاران ارز رمزنگاریشده را در زنجیرههای بلوکی متعدد ساختهاند.
-
-## اتر چیست؟ {#what-is-ether}
-
-**اتر (ETH)** ارز رمزنگاریشدهای است که برای بسیاری چیزها در شبکهی اتریوم استفاده میشود. اساساً، این تنها روش قابل قبول پرداخت برای کارمزد تراکنش است و پس از [ادغام](/roadmap/merge)، اتر برای اعتبارسنجی و پیشنهاد بلوکها در شبکه اصلی لازم است. اتر همچنین بهعنوان شکل اصلی وثیقه در بازارهای وامدهی [دیفای](/defi)، بهعنوان واحد محاسبه در بازارهای NFT، بهعنوان پرداخت کسبشده برای انجام خدمات یا فروش کالاهای واقعی و موارد دیگر استفاده میشود.
-
-اتریوم به توسعهدهندگان اجازه میدهد [**برنامههای غیرمتمرکز (dappها)**](/developers/docs/dapps) ایجاد کنند که همگی دارای قدرت محاسباتی مشترک هستند. این استخر مشترک محدود است، بنابراین اتریوم به مکانیزمی برای تعیین اینکه چه کسی میتواند از آن استفاده کند نیاز دارد. در غیر این صورت، یک dapp میتواند بهطور تصادفی یا بهطور مخرب تمام منابع شبکه را مصرف کند، که باعث میشود دسترسی دیگران به آن مسدود شود.
-
-ارز رمزنگاریشده اتر از مکانیزم قیمتگذاری برای قدرت محاسباتی اتریوم پشتیبانی میکند. هنگامی که کاربران میخواهند تراکنش انجام دهند، برای آنکه تراکنش آنها در زنجیره بلوکی شناسایی شود، باید اتر بپردازند. این هزینههای استفاده بهعنوان [هزینههای گاز](/developers/docs/gas/) شناخته میشوند، و هزینه گاز به میزان توان محاسباتی موردنیاز برای اجرای تراکنش و تقاضای گسترده به شبکه برای محاسبهی توان محاسباتی در آن زمان بستگی دارد.
-
-بنابراین، حتی اگر یک dapp بداندیش یک حلقه بینهایت ارسال کند، تراکنش تا زمان مصرف اتر تمام میشود و خاتمه مییابد و به شبکه اجازه میدهد به حالت عادی بازگردد.
-
-بهکار بردن اتر و اتریوم [بهجای](https://www.reuters.com/article/us-crypto-currencies-lending-insight-idUSKBN25M0GP#:~:text=price%20of%20ethereum) [یکدیگر](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845#:~:text=cryptocurrencies%20including%20ethereum) [متداول](https://www.cnn.com/2021/03/14/tech/nft-art-buying/index.html#:~:text=price%20of%20ethereum) است — وقتی مردم به «قیمت اتریوم» اشاره می کنند، در واقع به قیمت اتر اشاره میکنند.
-
-## استخراج اتر {#minting-ether}
-
-استخراج فرایندی است که در آن اتر جدید در دفتر کل اتریوم ایجاد میشود. پروتکل زیربنایی اتریوم، اتر جدید را ایجاد میکند و امکان ایجاد اتر برای کاربر وجود ندارد.
-
-اتر به عنوان پاداش برای هر بلوک پیشنهادی و در هر نقطه بازرسی ایپوک برای سایر فعالیت های اعتبارسنج مربوط به رسیدن به اجماع ضرب می شود. مجموع مبلغ صادر شده به تعداد اعتباردهنده ها و مقدار اتری که آنها سهامگذاری کرده اند بستگی دارد. این صدور کل به طور مساوی بین اعتبار سنج ها در حالت ایده آل تقسیم می شود که همه اعتبار سنج های قابل اعتماد و آنلاین هستند، اما در واقعیت، بر اساس عملکرد اعتبار سنج متفاوت است. حدود 1/8 از کل صدور به پیشنهاد دهنده بلوک می رسد. باقیمانده در بین اعتبارسنجهای دیگر توزیع میشود. پیشنهاد دهندگان بلاک نیز انعامهایی را از کارمزد تراکنش ها و درآمدهای مرتبط با MEV دریافت می کنند، اما اینها از اتر بازیافت شده است، نه صدور جدید.
-
-## سوزاندن اتر {#burning-ether}
-
-همانند ایجاد اتر از طریق پاداش های بلوک، اتر می توانند از طریق یک فرآیند به نام 'سوزاندن' از بین برود. وقتی اتر میسوزد، برای همیشه از چرخهی زنجیره خارج میشود.
-
-سوختن اتر در تمام تراکنشهای روی اتریوم رخ میدهد. هنگامی که کاربران برای تراکنشهای خود پرداخت میکنند، هزینهی گاز پایه که توسط شبکه بر اساس تقاضای تراکنش تعیین میشود، از بین میرود. این موضوع به همراه اندازهی بلوکهای متغیر و حداکثر کارمزد گاز، تخمین کارمزد تراکنش را در اتریوم ساده میکند. وقتی تقاضای شبکه زیاد است، [بلوکها](https://etherscan.io/block/12965263) میتوانند اتر بیشتری نسبت به تولید خود بسوزانند و بهطور مؤثری تولید اتر را جبران کنند.
-
-سوزاندن کارمزد پایه، مانع از دستکاری تراکنش ها از سوی تولیدکنندگان بلوک می شود. برای مثال، اگر تولیدکنندگان بلوک کارمزد پایه را دریافت میکردند، میتوانستند تراکنشهای خود را بهصورت رایگان درج کنند و کارمزد پایه را برای بقیه افزایش دهند. از طرف دیگر، آنها می توانند کارمزد پایه را به برخی از کاربران خارج از زنجیره بازپرداخت کنند، که منجر به بازار کارمزد تراکنش مبهم و پیچیدهتر میشود.
-
-## واحدهای خرد اتر {#denominations}
-
-از آنجایی که مقدار بسیاری از تراکنشها در اتریوم کوچک هستند، اتر دارای چندین نام است که ممکن است برای مقادیر کمتر به آنها اشاره شود. از میان این واحدهای شمارش، Wei و gwei از اهمیت ویژهای برخوردارند.
-
-Wei کوچکترین مقدار ممکن اتر است و در نتیجه بسیاری از پیادهسازیهای فنی مانند [یلو پیپر اتریوم](https://ethereum.github.io/yellowpaper/paper.pdf)، تمام محاسبات خود را بر اساس Wei انجام خواهند داد.
-
-Gwei که مخفف giga-wei است، اغلب برای توصیف هزینههای گاز در اتریوم استفاده میشود.
-
-| نام واحد شمارش | ارزش به اتر | کاربرد رایج |
-| -------------- | ---------------- | ---------------------------------- |
-| Wei | 10-18 | پیادهسازیهای فنی |
-| Gwei | 10-9 | هزینهی گاز قابلخواندن توسط انسان |
-
-## انتقال اتر {#transferring-ether}
-
-هر تراکنش در اتریوم حاوی یک بخش `value` است که مقدار اتری را که باید منتقل شود، بر حسب wei، برای ارسال از آدرس فرستنده به آدرس گیرنده مشخص میکند.
-
-با توجه به اینکه آدرس گیرنده یک [قرارداد هوشمند](/developers/docs/smart-contracts/) است، زمانی که این قرارداد هوشمند کد خود را اجرا میکند، میتوان از این اتر منتقلشده برای پرداخت هزینهی گاز استفاده شود.
-
-[اطلاعات بیشتر در مورد تراکنشها](/developers/docs/transactions/)
-
-## استعلام اتر {#querying-ether}
-
-کاربران میتوانند موجودی اتر هر [حساب](/developers/docs/accounts/) را با بررسی بخش `موجودی` حساب، که داراییهای اتر را بر حسب wei نشان میدهد، استعلام کنند.
-
-[Etherscan](https://etherscan.io) یک ابزار محبوب برای بررسی موجودی حساب از طریق برنامهای مبتنی بر وب است. برای مثال، [این صفحهی Etherscan](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae) حساب بنیاد اتریوم را نشان میدهد. موجودی حساب را میتوان با استفاده از کیف پول یا بهطور مستقیم با درخواست از گرهها جستجو کرد.
-
-## بیشتر بخوانید {#further-reading}
-
-- [تعریف اتر و اتریوم](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _گروه CME_
-- [برگه سفید اتریوم](/whitepaper/): پیشنهاد اصلی برای اتریوم. این سند شامل توضیحاتی دربارهی اتر و انگیزههای ساخت آن است.
-- [ماشین حساب Gwei](https://www.alchemy.com/gwei-calculator): از این ماشین حساب gwei برای تبدیل آسان wei، gwei و اتر استفاده کنید. به سادگی هر مقدار wei، gwei یا ETH را وصل کنید و تبدیل را بهطور خودکار محاسبه کنید.
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md
deleted file mode 100644
index d995b07a135..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: معرفی اتریوم
-description: مقدمهای بر مفاهیم اصلی اتریوم برای توسعهدهندگان برنامههای غیرمتمرکز.
-lang: fa
----
-
-## زنجیرهی بلوکی چیست؟ {#what-is-a-blockchain}
-
-زنجیرهی بلوکی یک پایگاه دادهی عمومی است که بر روی رایانههای متعددی در یک شبکه، بهروزرسانی شده و به اشتراک گذاشته میشود.
-
-کلمهی «بلوک» به داده و وضعیتی اشاره دارد که در گروههای متوالی داده که با عنوان «بلوکها» شناخته میشوند، ذخیره میشود. اگر مقداری اتر برای فردی ارسال کنید، برای موفقیتآمیز بودن تراکنش، اطلاعات آن باید درون یک بلوک قرار گیرد.
-
-«زنجیره» به این واقعیت اشاره دارد که هر بلوک، به صورت رمزنگاریشده به بلوک قبل از خود ارجاع دارد. به عبارت دیگر، بلوکها به یکدیگر زنجیر میشوند. اگر دادههای موجود در یکی از بلوکها تغییر داده شود، کلیه بلوکهای بعد از آن نیز باید تغییر کنند، که متعاقباً برای انجام چنین تغییری تمام شبکه باید در مورد آن به توافق برسند.
-
-همه رایانههای درون شبکه باید با هر بلوک جدید و نیز کل زنجیرهی بلوکها موافقت داشته باشند. این رایانهها بهعنوان «گره» شناخته میشوند. گرهها اطمینان حاصل میکنند همه افرادی که با زنجیرهی بلوکی تعامل میکنند دادههای یکسانی در اختیار داشته باشند. برای دستیابی به چنین توافقی، زنجیرههای بلوکی به یک مکانیزم اجماع نیاز دارند.
-
-اتریوم از یک [مکانیزم اجماع مبتنی بر اثبات سهم](/developers/docs/consensus-mechanisms/pos/) استفاده میکند. هرکس که می خواهد بلوک های جدیدی را به زنجیره اضافه کند باید ETH - یعنی ارز اصلی در اتریوم- را وثیقه بگذارد و نرمافزار اعتبارسنج را اجرا کند. سپس این "اعتبارسنج ها" می توانند به صورت تصادفی انتخاب شوند تا بلوک هایی را پیشنهاد دهند که اعتبارسنج های دیگر بررسی می کنند و به بلاکچین اضافه می کنند. سیستمی از پاداش ها و جریمهها وجود دارد که هرچه بیشتر شرکت کنندگان را به صداقت و در دسترس بودن آنلاین تشویق می کند.
-
-اگر دوست دارید ببینید داده های بلاکچین چگونه هش می شوند و پس از آن به تاریخچه ارجاعات بلاک اضافه می شوند، حتما [این دمو](https://andersbrownworth.com/blockchain/blockchain) را توسط آندرس براون ورث بررسی کنید و ویدئوی همراه آن را در زیر تماشا کنید.
-
-توضیحات آندِرس را در رابطه با «هش» در بلاکچین تماشا کنید:
-
-
-
-## اتریوم چیست؟ {#what-is-ethereum}
-
-اتریوم یک بلاکچین است که یک کامپیوتر در آن تعبیه شده است. این اساس ساخت اپلیکیشنها و سازمانها به روشی غیرمتمرکز، بدون مجوز و مقاوم در برابر سانسور است.
-
-در دنیای اتریوم، یک رایانه واحد و استاندارد وجود دارد (به نام ماشین مجازی اتریوم یا EVM) که وضعیت آن مورد توافق همه افراد حاضر در شبکه اتریوم است. همه شرکتکنندگان در شبکه اتریوم (همه گرههای اتریوم) یک رونوشت از وضعیت این رایانه را نگهداری میکنند. علاوه بر این، هر شرکتکننده میتواند درخواستی برای انجام محاسبات دلخواه به این رایانه ارسال کند. هرگاه چنین درخواستی منتشر گردد، سایر شرکتکنندگان در شبکه آن را بازبینی میکنند، تأیید میکنند و محاسبات مورد نظر را انجام می دهند («اجرا» میکنند). اجرای این محاسبات موجب تغییر وضعیت در EVM میگردد، که در کل تحویل و تکثیر میشود.
-
-درخواست انجام محاسبه، درخواست تراکنش نامیده میشود؛ تاریخچه کلیه تراکنشها و وضعیت فعلی EVM روی بلاکچین ذخیره میشود، که متقابلاً تمام گرههای شبکه در مورد آن توافق کرده و آن را ذخیره میکنند.
-
-مکانیزمهای رمزنگاری تضمین میکنند که به محض اینکه تراکنشها بهعنوان تراکنش معتبر تأیید شده و به بلاکچین اضافه شدند، دیگر قابل دستکاری نباشند. همین مکانیزمها همچنین تضمین میکنند که هر تراکنش با «مجوزهای» مناسب امضا و اجرا شوند (هیچکس غیر از خود آلیس نباید بتواند از حساب آلیس سرمایههای دیجیتال را برداشت کند).
-
-## اتر چیست؟ {#what-is-ether}
-
-**اتر (ETH)** ارز رمزنگاریشده بومی اتریوم است. هدف ETH فراهمسازی امکان محاسبه برای بازار است. چنین بازاری یک مشوق اقتصادی برای شرکتکنندگان جهت تأیید و اجرای درخواستهای تراکنش و فراهمسازی منابع محاسباتی برای شبکه ایجاد میکند.
-
-هر شرکتکننده که درخواست تراکنشی را پخش میکند باید مقداری ETH را هم بهعنوان جایزه به شبکه ارائه دهد. شبکه بخشی از جایزه را میسوزاند و بقیه را به هر کس که در نهایت کار تأیید تراکنش، اجرای آن، ثبت آن در بلاکچین و پخش آن به شبکه را انجام دهد، اعطا می کند.
-
-مقدار ETH پرداختشده، با منابع مورد نیاز برای انجام محاسبه تطابق دارد. این جایزهها همچنین مانع از این میشوند که شرکتکنندگان بداندیش بتوانند عمداً با درخواست اجرای محاسبات بینهایت یا سایر اسکریپتهای پرمصرف شبکه را مسدود کنند، زیرا این شرکتکنندگان باید هزینه منابع محاسبه را بپردازند.
-
-ETH (اتر) همچنین برای تامین امنیت اقتصاد-کریپتویی برای شبکه به سه روش اصلی استفاده می شود: 1) به عنوان وسیله ای برای پاداش دادن به اعتبارسنجانی که بلوک ها را پیشنهاد می دهند یا رفتار نادرست را از سوی دیگر اعتبارسنجان اعلام می کنند، استفاده می شود؛ 2) توسط اعتبارسنجان به عنوان وثیقه در برابر رفتار نادرست عمل می کند- اگر اعتبارسنجان تلاش کنند که رفتار نادرست داشته باشند ETH آنها می تواند نابود شود؛ 3) از آن برای وزن کردن "آرا" بلوک های پیشنهادی جدید استفاده می شود، که به بخش انتخاب فورک مکانیزم اجماع وارد می شود.
-
-## قراردادهای هوشمند چه هستند؟ {#what-are-smart-contracts}
-
-در عمل، شرکتکنندگان هر بار که میخواهند محاسبهای در EVM درخواست کنند، کد جدیدی نمینویسند. در عوض، توسعهدهندگان برنامهها، دستوراتی (قطعههای قابلاستفاده مجدد کد) را در وضعیت EVM بارگذاری میکنند و کاربران درخواستهایی را برای اجرای این قطعه کدها با پارامترهای متفاوت ارائه میدهند. ما برنامههای بارگذاریشده روی شبکه و اجرا شده توسط شبکه را قراردادهای هوشمند مینامیم.
-
-در سطحی بسیار ابتدایی، میتوانید یک قرارداد هوشمند را مشابه یک دستگاه فروش خودکار در نظر بگیرید: اسکریپتی که وقتی با پارامترهای خاصی فراخوانی میشود، در صورت برآورده شدن شرایط خاص، برخی اقدامات یا محاسبات را انجام میدهد. بهعنوان مثال، اگر فراخوانکننده اتر را برای گیرنده خاصی ارسال کند، یک قرارداد هوشمند فروشنده ساده میتواند مالکیت یک دارایی دیجیتال را ایجاد کند و به آن اختصاص دهد.
-
-هر توسعهدهنده میتواند با استفاده از بلاکچین بهعنوان لایه داده، در ازای هزینهای که به شبکه میپردازد، یک قرارداد هوشمند بسازد و آن را برای شبکه عمومی کند. سپس هر کاربر میتواند دوباره با پرداخت هزینهای به شبکه، قرارداد هوشمند را برای اجرای کد آن فراخوانی کند.
-
-بنابراین، با قراردادهای هوشمند، توسعهدهندگان میتوانند اپلیکیشنها و سرویسهای دلخواه پیچیدهای را بسازند و بهکار بگیرند که با کاربر مواجه هستند، مانند: بازارها، ابزارهای مالی، بازیها و غیره.
-
-## اصطلاحشناسی {#terminology}
-
-### زنجیرهی بلوکی {#blockchain}
-
-دنبالهای از تمام بلوکهایی که در تاریخچه شبکه به شبکه اتریوم تحویل شدهاند. این نامگذاری به این دلیل است که هر بلوک حاوی یک ارجاع به بلوک قبلی است که به ما کمک میکند ترتیبی را در تمام بلوکها حفظ کنیم (و در نتیجه تاریخچه دقیق).
-
-### اتر {#eth}
-
-**اتر (ETH)** ارز رمزنگاریشدهی بومی اتریوم است. کاربران به سایر کاربران اتر پرداخت میکنند تا درخواستهای اجرای کد آنها انجام شود.
-
-[اطلاعات بیشتر دربارهی اتر](/developers/docs/intro-to-ether/)
-
-### ماشین مجازی اتریوم (EVM) {#evm}
-
-ماشین مجازی اتریوم یک رایانه مجازی جهانی است که هر شرکتکننده در شبکه اتریوم وضعیت آن را ذخیره میکند و با آن موافق است. هر شرکتکننده میتواند اجرای کد دلخواه را در EVM درخواست کند و اجرای کد، وضعیت EVM را تغییر میدهد.
-
-[اطلاعات بیشتر درباره EVM](/developers/docs/evm/)
-
-### گره {#nodes}
-
-ماشینهای واقعی که وضعیت EVM را ذخیره میکنند. گرهها با یکدیگر ارتباط برقرار میکنند تا اطلاعات مربوط به وضعیت EVM و تغییرات وضعیت جدید را تکثیر کنند. هر کاربر همچنین میتواند با پخش یک درخواست اجرای کد از یک گره، اجرای آن کد را درخواست کند. شبکه اتریوم خود مجموعهای از تمام گرههای اتریوم و ارتباطات آنها است.
-
-[اطلاعات بیشتر دربارهی گرهها](/developers/docs/nodes-and-clients/)
-
-### حساب {#accounts}
-
-جایی که اتر ذخیره میشود. کاربران میتوانند حسابها را راهاندازی کنند، اتر را به حسابها واریز کنند و اتر را از حسابهای خود به سایر کاربران انتقال دهند. حساب و موجودی حساب در جدولی بزرگ در EVM ذخیره میشوند؛ آنها بخشی از وضعیت کلی EVM هستند.
-
-[اطلاعات بیشتر در مورد حسابها](/developers/docs/accounts/)
-
-### تراکنشها {#transactions}
-
-«درخواست تراکنش» اصطلاح رسمی برای اشاره به درخواست اجرای کد در EVM است و «تراکنش» یک درخواست تراکنش انجام شده و تغییر مربوطه در وضعیت EVM است. هر کاربر میتواند درخواست تراکنش را از یک گره به شبکه ارسال کند. برای اینکه درخواست تراکنش بر وضعیت EVM توافقشده تأثیر بگذارد، باید توسط گره دیگری تأیید شود، اجرا شود و «به شبکه تحویل شود». اجرای هر کد باعث تغییر وضعیت در EVM میشود. در صورت تحویل شدن، این تغییر وضعیت در تمام گرههای شبکه پخش میشود. چند نمونه از تراکنشها:
-
-- X اتر را از حساب من به حساب آلیس ارسال کنید.
-- تعدادی کد قرارداد هوشمند را در وضعیت EVM اجرا کنید.
-- کد قرارداد هوشمند موجود در آدرس X در EVM با آرگومان Y را اجرا کنید.
-
-[اطلاعات بیشتر در مورد تراکنشها](/developers/docs/transactions/)
-
-### بلوکها {#blocks}
-
-حجم تراکنشها بسیار زیاد است، بنابراین تراکنشها به صورت دستهای یا بلوکی «تحویل» میشوند. بلوکها معمولا شامل دهها تا صدها تراکنش هستند.
-
-[اطلاعات بیشتر درباره بلوکها](/developers/docs/blocks/)
-
-### قراردادهای هوشمند {#smart-contracts}
-
-یک قطعه کد قابلاستفاده مجدد (یک برنامه) که یک توسعهدهنده آن را در وضعیت EVM منتشر میکند. هر کس میتواند با درخواست تراکنش، درخواست کند که کد قرارداد هوشمند اجرا شود. از آنجا که توسعهدهندگان میتوانند با انتشار قراردادهای هوشمند، برنامههای اجرایی دلخواه را در EVM (بازیها، بازارها، ابزارهای مالی و غیره) بنویسند، اینها اغلب [dappها یا اپلیکیشنهای غیرمتمرکز](/developers/docs/dapps/) نیز نامیده میشوند.
-
-[اطلاعات بیشتر درباره قراردادهای هوشمند](/developers/docs/smart-contracts/)
-
-## بیشتر بخوانید {#further-reading}
-
-- [وایتپیپر اتریوم](/whitepaper/)
-- [به هر حال اتریوم چگونه کار می کند؟](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasirdy_ (**توجه** این منبع هنوز ارزشمند است اما توجه داشته باشید که این منبع پیش از [ادغام](/roadmap/merge) است و بنابراین هنوز هم به مکانیزم اثبات کار اتریوم اشاره دارد - اتریوم در واقع اکنون با استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos) ایمن شده است)
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-## آموزشهای مرتبط {#related-tutorials}
-
-- [راهنمای اتریوم برای توسعهدهندگان، بخش 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– بررسی بسیار کاربرپسند اتریوم با استفاده از پایتون و web3.py_
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/networks/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/networks/index.md
deleted file mode 100644
index c02d9aee46d..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/networks/index.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: شبکهها
-description: مروری بر شبکههای اتریوم و محل دریافت اتر (ETH) شبکهی تست برای آزمایش برنامهی خود.
-lang: fa
----
-
-شبکه های اتریوم گروهی از کامپیوتر های متصل به هم هستند که از طریق پروتکل اتریوم با هم ارتباط برقرار میکنند. تنها یک شبکه اصلی اتریوم وجود دارد، اما شبکه های مستقلی مطابق با قوانین پروتکلی یکسان می توانند به منظور آزمایش و توسعه ایجاد شوند. تعداد زیادی "شبکه های" مستقل وجود دارند که بدون تعامل با یکدیگر با پروتکل تطابق دارند. حتی می توانید برای آزمایش قراردادهای هوشمند و اپلیکیشن های Web3 خود، یکی را بر روی کامپیوتر خود به صورت محلی راه اندازی کنید.
-
-حساب اتریوم شما در شبکه های مختلف کار می کند، اما موجودی حساب و سابقهی تراکنش شما از شبکهی اصلی اتریوم منتقل نمیشود. برای مقاصد آزمایشی، دانستن اینکه کدام شبکهها در دسترس هستند و چگونه میتوان اتر شبکه آزمایشی را برای کار کردن با آن به دست آورد، مفید است. به طور کلی، بنا به دلایل امنیتی، اسفاده مجدد از حساب های شبکه اصلی بروی شبکه آزمایشی یا برعکس، توصیه نمی شود.
-
-## پیشنیازها {#prerequisites}
-
-قبل از کسب اطلاعات در مورد شبکههای مختلف، باید [اصول اتریوم](/developers/docs/intro-to-ethereum/) را بدانید، زیرا شبکههای تست نسخهای ارزان و ایمن از اتریوم را برای تجربه کردن در اختیار شما قرار میدهند.
-
-## شبکههای عمومی {#public-networks}
-
-شبکههای عمومی برای هر کسی در جهان با اتصال به اینترنت قابلدسترسی هستند. هر کسی میتواند تراکنشهایی را در یک زنجیرهی بلوکی عمومی بخواند یا ایجاد کند و تراکنشهای در حال اجرا را تأیید کند. اجماع بین همتایان در مورد گنجاندن تراکنشها و وضعیت شبکه تصمیم میگیرد.
-
-### شبکهی اصلی اتریوم {#ethereum-mainnet}
-
-شبکهی اصلی اولین زنجیرهی بلوکی عمومی تولید اتریوم است که تراکنشهای توزیع شده با ارزش واقعی در دفتر کل روی آن انجام میشود.
-
-وقتی مردم و صرافیها درباره قیمت اتر صحبت میکنند، در مورد اتر روی شبکهی اصلی صحبت میکنند.
-
-### شبکههای تست اتریوم {#ethereum-testnets}
-
-علاوه بر شبکه اصلی، شبکههای تست عمومی نیز وجود دارند. علاوه بر شبکهی اصلی، شبکههای تست عمومی نیز وجود دارند. این را بهعنوان یک آنالوگ برای تولید در مقابل سرورهای مرحلهای در نظر بگیرید.
-
-قبل از استقرار در شبکهی اصلی باید هر کد قراردادی را که روی یک شبکهی تست مینویسید آزمایش کنید. قبل از استقرار در شبکهی اصلی باید هر کد قراردادی را که روی یک شبکهی تست مینویسید آزمایش کنید.
-
-بیشتر شبکه های تست با استفاده از یک گواهی صلاحیت مکانیزم اجماع مجاز شروع کرده اند. این بدان معناست که تعداد کمی از گرهها برای اعتبارسنجی تراکنشها و ایجاد بلوکهای جدید انتخاب میشوند و هویت آنها در این فرایند سهامگذاری میشود. از سوی دیگر، بعضی شبکه های تست مکانیزم اثبات سهام عمومی دارند که درست مثل شبکه اصلی اتریوم، هر کس میتواند راهاندازی و نگهداری اعتبار سنج شبکه را تست کند.
-
-قرار است اتر در شبکه های تست ارزش واقعی نداشته باشد، یا این حال، بازارهایی برای انواع خاصی از شبکه تست اتر ایجاد شده است که دسترسی به آنها سخت شده است. از آنجا که برای تعامل واقعی با اتریوم به اتر احتیاج دارید (حتی بر روی شبکه تست)، بسیاری از افراد اتر شبکه تست را از فاست ها به طور رایگان دریافت می کنند. بیشتر فاستها برنامههای تحت وب هستند که میتوانید آدرسی را که درخواست ارسال اتر به آن آدرس را دارید در آنها وارد کنید.
-
-#### از کدام شبکه تست باید استفاده کنم؟
-
-دو شبکه تست عمومی که کاربران توسعهدهنده در حال حاضر نگهداری میکنند Goerli و Sepolia هستند. Sepolia یک شبکه برای قرارداد و اپلیکیشن است که توسعهدهندگان برنامه های خود را روی آن آزمایش می کنند. شبکه Goerli به توسعهدهندگان پروتکل اجازه می دهد ارتقا شبکه را آزمایش کنند، و به سهام گذاران اجازه می دهد تا اعتبارسنج های در حال اجرا را تست کنند.
-
-#### Sepolia {#sepolia}
-
-**Sepolia شبکه تست پیش فرض توصیه شده برای توسعه اپلیکیشن می باشد**. شبکه Sepolia از یک مجموعه اعتبارسنج مجاز استفاده می کند. که این نسبتا جدید می باشد، و به این معنی است که تاریخچه و وضعیت آن بسیار کوچک می باشد. این به این معنی است که همگامسازی شبکه بسیار سریع است و اجرای یک گره بر روی آن به حافظه کمی احتیاج دارد. این برای کاربرانی که می خواهند سریعا یک گره را چرخانده و با شبکه به طور مستقیم تعامل داشته باشند، مفید است.
-
-- مجموعه اعتبارسنج بسته، کنترل شده توسط کاربر &، تیم های تست
-- شبکه تست جدید، با استقرارر اپلیکیشنهای کمتر نسبت به بقیه شبکه های تست
-- همگام سازی سریع و اجرای یک گره نیاز به حداقل فضای دیسک دارد
-
-##### منابع
-
-- [وب سایت](https://sepolia.dev/)
-- [گیت هاب](https://github.com/eth-clients/sepolia)
-- [Otterscan](https://sepolia.otterscan.io/)
-- [Etherscan](https://sepolia.etherscan.io)
-- [Blockscout](https://eth-sepolia.blockscout.com/)
-
-##### فاست ها
-
-- [فاست QuickNode Sepolia](https://faucet.quicknode.com/drip)
-- [Grabteeth](https://grabteeth.xyz/)
-- [فاست PoW](https://sepolia-faucet.pk910.de/)
-- [فاست کیف پول Coinbase | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet)
-- [فاست Alchemy Sepolia](https://sepoliafaucet.com/)
-- [فاست Infura Sepolia](https://www.infura.io/faucet)
-- [فاست Chainstack Sepolia](https://faucet.chainstack.com/sepolia-faucet)
-- [فاست اتریوم اکوسیستم](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia)
-
-#### Goerli_(پشتیبانی طولانی مدت)_ {#goerli}
-
-_توجه:[شبکه تست Goerli منسوخ شده است](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) و در 2023 با [Holesovice](https://github.com/eth-clients/holesovice) جایگزین خواهد شد. لطفاً انتقال اپلیکیشنهای خود را به Sepolia در نظر بگیرید._
-
-Goerli یک شبکه تست برای آزمایش اعتبارسنجی و سهام گذاری است. شبکه Goerli برای کاربرانی که می خواهند اعتبارسنجی یک شبکه تست را اجرا کنند، باز است. سهام گذارانی که می خواهند آپدیت های پروتکل را قبل از پیادهسازی بر روی شبکه اصلی آزمایش کنند، پس باید از Goerli استفاده کنند.
-
-- مجموعه اعتبارسنج باز، سهام گذاران می توانند ارتقا شبکه را تست کنند
-- وضعیت بزرگ داده ای، مفید برای تست تعاملات قرارداد هوشمند پیچیده
-- همگام سازی بیشتر طول میشکد و حافظه بیشتری برای اجرای گره احتیاج است
-
-##### منابع
-
-- [وبسایت](https://goerli.net/)
-- [گیتهاب](https://github.com/eth-clients/goerli)
-- [Etherscan](https://goerli.etherscan.io)
-- [Blockscout](https://eth-goerli.blockscout.com/)
-
-##### فاست ها
-
-- [فاست QuickNode Goerli](https://faucet.quicknode.com/drip)
-- [Grabteeth](https://grabteeth.xyz/)
-- [فاست PoW](https://goerli-faucet.pk910.de/)
-- [فاست Paradigm](https://faucet.paradigm.xyz/)
-- [فاست Alchemy Goerli](https://goerlifaucet.com/)
-- [فاست All That Node Goerli](https://www.allthatnode.com/faucet/ethereum.dsrv)
-- [فاست کیف پول Coinbase | Sepolia](https://coinbase.com/faucets/ethereum-goerli-faucet)
-- [فاست Chainstack Sepolia](https://faucet.chainstack.com/goerli-faucet)
-
-برای راهاندازی اعتبارسنج بر روی شبکه تست گورلی (Goerli)، از [سکوی پرتاپ"اعتبار سنج ارزان گورلی"](https://goerli.launchpad.ethstaker.cc/en/) که توسط جامعه Ethstaker ارائه میشود استفاده کنید.
-
-### شبکههای تست لایه 2 {#layer-2-testnets}
-
-[لایه 2 (L2)](/layer-2/) یک اصطلاح جمعی برای توصیف مجموعه خاصی از راهحلهای مقیاسپذیری اتریوم است. لایه 2 یک بلاکچین جداگانه است که اتریوم را گسترش میدهد و تضمینهای امنیتی اتریوم را به ارث میبرد. شبکههای تست لایه 2 معمولاً محکم به شبکههای تست عمومی اتریوم متصل میشوند.
-
-#### شبکه تست Arbitrum Goerli {#arbitrum-goerli}
-
-یک شبکه تست برای [Arbitrum](https://arbitrum.io/).
-
-##### فاست ها
-
-- [فاست Chainlink](https://faucets.chain.link/)
-
-#### Optimistic Goerli {#optimistic-goerli}
-
-یک شبکه تست برای [Optimism](https://www.optimism.io/).
-
-##### فاست ها
-
-- [فاست Paradigm](https://faucet.paradigm.xyz/)
-- [فاست کیف پول Coinbase | Sepolia](https://coinbase.com/faucets/optimism-goerli-faucet)
-
-#### Starknet Goerli {#starknet-goerli}
-
-یک شبکه تست برای [Starknet](https://www.starknet.io).
-
-##### فاست ها
-
-- [فاست Starknet](https://faucet.goerli.starknet.io)
-
-## شبکههای خصوصی {#private-networks}
-
-یک شبکه اتریوم در صورتی که گرههای آن به یک شبکه عمومی متصل نباشند یک شبکه خصوصی است (یعنی شبکه اصلی یا یک شبکه تست). در این زمینه، خصوصی فقط به معنای اختصاصی یا مجزا است، نه محافظتشده یا امن.
-
-### شبکههای توسعه {#development-networks}
-
-برای اینکه یک برنامه اتریوم را توسعه دهید، لازم است آن را در یک شبکه خصوصی اجرا کنید تا قبل از بکارگیری آن، نحوه کارکردش را ببینید. مشابه نحوه ایجاد یک سرور محلی در رایانه خود برای توسعه وب، میتوانید یک نمونه بلاکچین محلی برای آزمایش برنامه غیرمتمرکز خود ایجاد کنید. بدینترتیب، امکان تکرار بسیار سریعتر در مقایسه با یک شبکه تست عمومی فراهم میشود.
-
-پروژهها و ابزارهایی برای کمک به این امر اختصاص داده شده است. درباره [شبکههای توسعه](/developers/docs/development-networks/) بیشتر بدانید.
-
-### شبکههای کنسرسیومی {#consortium-networks}
-
-فرایند اجماع توسط مجموعهای از گرههای تعریفشده که قابلاعتماد هستند کنترل میشود. بهعنوان مثال، یک شبکه خصوصی از مؤسسات دانشگاهی شناختهشده که هر یک گره واحدی را حکمرانی میکنند، و بلوکها توسط آستانهای از امضاکنندگان در شبکه اعتبارسنجی میشوند.
-
-اگر یک شبکه عمومی اتریوم مانند اینترنت عمومی است، یک شبکه کنسرسیومی مثل یک اینترانتِ خصوصی است.
-
-## ابزارهای مرتبط {#related-tools}
-
-- [فهرست زنجیرهای](https://chainlist.org/) _فهرست شبکههای EVM برای اتصال کیف پولها و ارائهدهندگان به شناسهی زنجیره و شناسهی شبکه مناسب_
-- [زنجیرههای مبتنی بر EVM](https://github.com/ethereum-lists/chains) _مخزن فرادادههای زنجیره در گیتهاب که موتور محرک فهرست زنجیرهای است_
-
-## بیشتر بخوانید {#further-reading}
-
-- [طرح پیشنهادی: چرخه زندگی قابل پیشبینی شبکه تست اتریوم](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17)
-- [سیر تکامل شبکههای تست اتریوم](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/transactions/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/transactions/index.md
deleted file mode 100644
index 0430b80cc8b..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/transactions/index.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-title: تراکنشها
-description: مروری بر تراکنشهای اتریوم - نحوهی کارکرد، ساختار دادههای آنها و نحوه ارسالشان از طریق برنامهی کاربردی.
-lang: fa
----
-
-تراکنشها شامل دستورالعملهایی از حسابها هستند که به صورت رمزنگاریشده امضا شدهاند. یک حساب برای بهروزرسانی وضعیت شبکه اتریوم، تراکنشی را آغاز میکند. سادهترین تراکنش، انتقال اتر از یک حساب به حساب دیگر است.
-
-## پیشنیازها {#prerequisites}
-
-برای کمک به فهمیدن این صفحه، بهتر است [حساب های کاربری](/developers/docs/accounts/) و [مقدمهای بر اتریوم](/developers/docs/intro-to-ethereum/) را مطالعه کنید.
-
-## تراکنش چیست؟ {#whats-a-transaction}
-
-تراکنش اتریوم به اقدامی اشاره دارد که توسط یک حساب تحت مالکیت خارجی آغاز میشود، به عبارت دیگر حسابی که توسط یک انسان مدیریت میشود، نه یک قرارداد. بهعنوان مثال، اگر باب به آلیس 1 اتر ارسال کند، حساب باب باید بدهکار شود و حساب آلیس باید بستانکار شود. این عمل تغییر وضعیت توسط یک تراکنش صورت میگیرد.
-
-![شکلی نشاندهندهی یک تراکنش که باعث تغییر وضعیت میشود](./tx.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-تراکنشهایی که وضعیت EVM را تغییر میدهند، باید در کل شبکه پخش شوند. هر گره میتواند اجرای تراکنش در ماشین مجازی اتریوم (EVM) را درخواست کند؛ پس از این اتفاق، یک اعتبارسنج تراکنش را اجرا میکند و تغییر حالت حاصل را در بقیه شبکه تکثیر میکند.
-
-تراکنش ها نیاز به کارمزد دارند و باید در یک بلوک تأیید شده قرار گیرند. برای سادهتر کردن این نمای کلی، کارمزدهای گاز و اعتبارسنجی را در جای دیگری پوشش خواهیم داد.
-
-تراکنش ارسالی شامل اطلاعات زیر است:
-
-- `از` - آدرس فرستنده که تراکنش را امضا خواهد کرد. این یک حساب مالکیت خارجی خواهد بود، چون حساب قرارداد نمیتواند تراکنش ارسال کنند.
-- `به` - آدرس دریافت کننده (اگر یک حساب با مالکیت خارجی باشد، تراکنش یک مقدار را منتقل خواهد کرد. اگر یک حساب قرارداد باشد، تراکنش کد قرارداد را اجرا میکند)
-- `امضاء` - شناسه فرستنده. زمانی ایجاد میشود که کلید خصوصی فرستنده تراکنش را امضا کند و تأیید کند که فرستنده این تراکنش را مجاز کرده است
-- `Nonce` - یک شمارنده که به شکل متوالی افزایش می یابد و تعداد تراکنش های حساب را نشان میدهد
-- `ارزش` - مقدار اتر فرستاده شده از آدرس فرستنده تراکنش به گیرنده (این مقدار در واحد اندازه گیری WEI نمایش داده میشود، که هر اتر برابر با 1e+18 wei است)
-- `داده ورودی(input data)` - قسمتی اختیاری برای قراردادن هر داده دلخواه
-- `gasLimit` - حداکثر مقدار واحدهای گازی که میتواند توسط تراکنش مصرف شود. [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/opcodes) واحدهای گاز لازم برای انجام هر مرحله محاسباتی تراکنش را مشخص می کند
-- `حداکثر انعام به ازای هر گاز (maxPriorityFeePerGas)` - حداکثر قیمت گازهایی که بهعنوان انعام به اعتبارسنج پرداخت میشود
-- `حداکثر کارمزد به ازای هر گاز (maxFeePerGas)` - حداکثر قیمتی که کاربر به ازای هر واحد گاز مایل به پرداخت است (شامل `قیمت پایه به ازای هر گاز (baseFeePerGas)`و`حداکثر قیمت اولویت به ازای هر گاز (maxPriorityFeePerGas)`)
-
-گاز به محاسبات لازم برای پردازش تراکنش توسط اعتبارسنج اشاره میکند. کاربران برای این محاسبه باید هزینهای بپردازند. `محدوده گاز (gasLimit)`، و`حداکثر قیمت اولویت به ازای هر گاز (maxPriorityFeePerGas)` نشان دهنده بیشترین کارمزد تراکنش پرداخت شده به اعتبارسنج می باشد. [دربارهی گاز بیشتر بدانید](/developers/docs/gas/).
-
-شیء تراکنش کمی شبیه به این خواهد بود:
-
-```js
-{
- from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
- to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
- gasLimit: "21000",
- maxFeePerGas: "300",
- maxPriorityFeePerGas: "10",
- nonce: "0",
- value: "10000000000"
-}
-```
-
-اما یک شیء تراکنش باید با استفاده از کلید خصوصی فرستنده امضا شود. این کار ثابت میکند که تراکنش فقط میتواند از طرف فرستنده انجام شود و به صورت تقلبی ارسال نشده است.
-
-یک کلاینت اتریوم مانند Geth این فرایند امضا را انجام میدهد.
-
-نمونه فراخوانی [JSON-RPC](/developers/docs/apis/json-rpc):
-
-```json
-{
- "id": 2,
- "jsonrpc": "2.0",
- "method": "account_signTransaction",
- "params": [
- {
- "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
- "gas": "0x55555",
- "maxFeePerGas": "0x1234",
- "maxPriorityFeePerGas": "0x1234",
- "input": "0xabcd",
- "nonce": "0x0",
- "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
- "value": "0x1234"
- }
- ]
-}
-```
-
-نمونهی پاسخ:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 2,
- "result": {
- "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
- "tx": {
- "nonce": "0x0",
- "maxFeePerGas": "0x1234",
- "maxPriorityFeePerGas": "0x1234",
- "gas": "0x55555",
- "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
- "value": "0x1234",
- "input": "0xabcd",
- "v": "0x26",
- "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
- "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
- "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
- }
- }
-}
-```
-
-- `raw` تراکنشی امضا شده است در فرم کدگذاری شده [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp)
-- `tx` تراکنش امضاشده به شکل JSON است
-
-با هش امضا، میتوان به صورت رمزنگاری ثابت کرد که تراکنش از فرستنده آمده و به شبکه ارسال شده است.
-
-### فیلد دادهها {#the-data-field}
-
-اکثریت قریببهاتفاق تراکنشها از طریق یک حساب دارای مالکیت خارجی به یک قرارداد دسترسی دارند. اکثر قراردادها در Solidity نوشته شدهاند و فیلد دادههای آنها را مطابق با [رابط باینری برنامه (ABI)](/glossary/#abi) تفسیر میکنند.
-
-چهار بایت اول با استفاده از هش نام تابع و آرگومانها مشخص میکند که کدام تابع را فراخوانی کند. گاهی اوقات میتوانید تابع را از انتخابگر با استفاده از [این پایگاه داده](https://www.4byte.directory/signatures/) شناسایی کنید.
-
-بقیه فراخواندادهها (calldata) آرگومان هستند، که [مطابق با مشخصات ABI مشخص شدهاند](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding).
-
-برای مثال، بیایید به [این تراکنش](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1) نگاه کنیم. از **برای مشاهدهی بیشتر کلیک کنید** برای دیدن فراخواندادهها استفاده کنید.
-
-انتخابگر تابع `0xa9059cbb` است. چندین [تابع شناختهشده با این امضا وجود دارد](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). در این مورد [کد منبع قرارداد](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) در Etherscan آپلود شده است، بنابراین میدانیم که این تابع `transfer(address, uint256)` است.
-
-بقیه دادهها عبارتند از:
-
-```
-0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
-000000000000000000000000000000000000000000000000000000003b0559f4
-```
-
-با توجه به مشخصات ABI، مقادیر صحیح (مانند آدرسها که اعداد صحیح 20 بایتی هستند) در ABI به صورت کلمات 32 بایتی ظاهر میشوند که ممکن است یک یا چند صفر در ابتدای آنها قرار داده شود. بنابراین ما میدانیم که آدرس `«to»`
-`4f6742badb049791cd9a302791cd9a302791cd99a32791cd99a310.com است.
-مقدار` 0x3b0559f4 = 990206452 است.
-
-
-
-## انواع تراکنشها {#types-of-transactions}
-
-در اتریوم چند نوع تراکنش مختلف وجود دارد:
-
-- تراکنش های منظم: تراکنش از یک حساب به حساب دیگر.
-- تراکنشهای استقرار قرارداد: تراکنش بدون آدرس «to»، که در آن از فیلد دادهها برای کد قرارداد استفاده میشود.
-- اجرای قرارداد: تراکنشی که با یک قرارداد هوشمند مستقر تعامل دارد. در این مورد، آدرس «to»، آدرس قرارداد هوشمند است.
-
-
-
-### دربارهی گاز {#on-gas}
-
-همانطور که گفته شد، انجام تراکنشها [گاز](/developers/docs/gas/) مصرف میکند. تراکنشهای انتقال ساده به 21000 واحد گاز نیاز دارند.
-
-بنابراین برای اینکه باب 1 اتر را به آلیس با `baseFeePerGas` به میزان 190 gwei و `maxPriorityFeePerGas` به میزان 10 gwei ارسال کند، باب باید هزینهی زیر را بپردازد:
-
-
-
-```
-(190 + 10) * 21000 = 4,200,000 gwei
---یا--
-0.0042 اتر
-```
-
-
-مقدار **1.0042 اتر** از حساب باب کسر خواهد شد (1 اتر برای آلیس + 0.0042 اتر برای هزینه گاز)
-
-به حساب آلیس **1.0+ اتر** بستانکار خواهد شد
-
-کارمزد پایه **0.00399- اتر** خواهد شد
-
-اعتبارسنج انعام **+0.000210 ETH** را نگه می دارد
-
-![شکلی نشاندهندهی نحوهی بازپرداخت گاز مصرفنشده](./gas-tx.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-
-هر گازی که در تراکنش استفاده نشده باشد به حساب کاربری مسترد میشود.
-
-
-
-### تعاملات قرارداد هوشمند {#smart-contract-interactions}
-
-گاز برای هر تراکنشی که شامل یک قرارداد هوشمند است، لازم است.
-
-قراردادهای هوشمند همچنین میتوانند دارای عملکردهایی باشند که بهعنوان عملکردهای [`نما`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) یا [`خالص`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) شناخته میشوند، که وضعیت قرارداد را تغییر نمیدهند. به این ترتیب، فراخوانی این توابع از یک EOA نیازی به گاز ندارد. فراخوان RPC اصلی برای این سناریو [`eth_call`](/developers/docs/apis/json-rpc#eth_call) است
-
-برخلاف زمانی که با استفاده از `eth_call` قابل دسترسی است، این توابع `نما` یا `خالص` معمولاً به صورت داخلی نیز فراخوانده می شوند (یعنی از خود قرارداد یا از قرارداد دیگری) که کارمزد گس را به همراه دارد.
-
-
-
-## چرخهی حیات تراکنش {#transaction-lifecycle}
-
-هنگامی که تراکنش ارسال شد، موارد زیر اتفاق میافتد:
-
-1. یک هشِ تراکنش به صورت رمزنگاری شده تولید میشود: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
-
-2. سپس تراکنش شما در شبکه مخابره می شود و به استخری که شامل تمامی تراکنش های شبکه است که در حال انتظار می باشند اضافه می شود.
-
-3. به منظور تایید و "موفقیت آمیز" در نظر گرفته شدن تراکنش شما، یک اعتبارسنج باید تراکنش شما را انتخاب کرده و داخل یک بلوک قرار دهد.
-4. با گذر زمان بلوکی که حامل تراکنش شما است به وضعیت "مشروع" و سپس "نهایی" برروز رسانی می شود. این ارتقاها موجب می شوند که کاملا مطمئن شوید که تراکنش شما موفقیت آمیز بوده و هرگز تغییر نخواهد کرد. زمانی که یک بلوک "نهایی" شد فقط تنها زمانی که مورد یک حمله در حد و سطح شبکه قرار بگیرد می تواند تغییر یابد که چندین میلیارد دلار هزینه به بار خواهد آورد.
-
-
-
-## یک نسخهی آزمایشی تصویری {#a-visual-demo}
-
-آستین را تماشا کنید که شما را دربارهی تراکنشها، گاز و استخراج راهنمایی میکند.
-
-
-
-
-
-## پاکت تراکنش تایپشده {#typed-transaction-envelope}
-
-اتریوم در ابتدا یک قالب برای تراکنشها داشت. هر تراکنش حاوی نانس (nonce)، قیمت گاز، حد گاز، آدرس گیرنده، مقدار، داده، v، r و s بود. این فیلد ها [کدگذاری شده RLP](/developers/docs/data-structures-and-encoding/rlp/) هستند، تا چیزی شبیه این به نظر برسند:
-
-`RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])`
-
-اتریوم به گونهای تکامل یافته است که از چندین نوع تراکنش پشتیبانی میکند تا پیادهسازی ویژگیهای جدیدی مانند لیستهای دسترسی و [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) را بدون تأثیر بر قالبهای تراکنش قدیمی امکانپذیر سازد.
-
-[EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) چیزی است که به این رفتار اجازه می دهد. تراکنش ها به صورت زیر تفسیر می شوند:
-
-`نوع معامله || TransactionPayload`
-
-که در آن فیلدها به صورت زیر تعریف میشوند:
-
-- `TransactionType` - عددی بین 0 و 0x7f، برای مجموع 128 نوع تراکنش ممکن.
-- `TransactionPayload` - یک آرایهی بایت دلخواه که توسط نوع تراکنش تعریف شده است.
-
-بر اساس مقدار `TransactionType`، تراکنش را می توان به موارد زیر طبقهبندی کرد
-
-1. **تراکنش های نوع صفر (قدیمی):** فرمت تراکنش اصلی که از زمان راهاندازی اتریوم استفاده شده است. اینها شامل ویژگیهای [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) مانند محاسبات دینامیک هزینه گس یا لیست دسترسی برای قراردادهای هوشمند نمیشوند. تراکنشهای قدیمی فاقد پیشوند خاصی هستند که نوع آنها را به صورت سریالی نشان میدهد، و با بایت `0xf8` هنگام استفاده از رمزگذاری [پیشوند طول بازگشتی (RLP)](/developers/docs/data-structures-and-encoding/rlp) شروع میشوند. مقدار TransactionType برای این تراکنشها `0x0` است.
-
-2. **تراکنشهای نوع یک:**در [پیشنهاد EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) بهعنوان بخشی از [ارتقای برلین](/history/#berlin) اتریوم معرفی شدند، این تراکنشها شامل پارامتر `accessList` هستند. این فهرست اقدام به مشخصکردن آدرسها و کلیدهای ذخیرهسازی میکند که تراکنش انتظار دارد به آنها دسترسی داشته باشد، و به کاهش بالقوه هزینههای [گس](/developers/docs/gas/) برای تراکنشهای پیچیده شامل قراردادهای هوشمند کمک میکند. تغییرات بازار کارمزد EIP-1559 در تراکنشهای نوع یک گنجانده نشدهاند. تراکنشهای نوع 1 همچنین شامل یک پارامتر `yParity` هستند که میتواند `0x0` یا `0x1` باشد که نشاندهنده برابری مقدار y امضای secp256k1 است. تشخیص آنها اینطور است که با بایت `0x01` شناسایی می شوند و مقدار TransactionType آنها `0x1` است.
-
-3. **تراکنشهای نوع 2** که معمولاً به تراکنشهای EIP-1559 گفته میشوند، تراکنشهایی هستند که در [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)، در [بهروزرسانی لندن](/history/#london) اتریوم معرفی شدهاند. آنها به مدل تراکنش استاندارد در شبکه اتریوم تبدیل شدهاند. این تراکنشها یک مکانیزم جدید بازار کارمزد را معرفی میکنند که با تفکیک کارمزد معامله به کارمزد پایه و کارمزد اولویت، قابلیت پیشبینی را بهبود میبخشد. آنها با بایت `0x02` شروع می شوند و شامل فیلدهایی مانند `maxPriorityFeePerGas` و `maxFeePerGas` میشوند. تراکنشهای نوع 2 اکنون به دلیل انعطافپذیری و کارایی، پیشفرض هستند، بهویژه در دورههای شلوغی بالای شبکه به دلیل توانایی آنها در کمک به کاربران در مدیریت قابل پیشبینیتر کارمزد تراکنشها مورد توجه قرار میگیرند. مقدار TransactionType برای این تراکنش ها `0x2` است.
-
-
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [EIP-2718: پاکت تراکنش تایپشده](https://eips.ethereum.org/EIPS/eip-2718)
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-
-
-## موضوعات مرتبط {#related-topics}
-
-- [حسابها](/developers/docs/accounts/)
-- [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)
-- [گاز](/developers/docs/gas/)
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
deleted file mode 100644
index 4162df41553..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/web2-vs-web3/index.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Web2 در مقابل Web3
-description:
-lang: fa
----
-
-Web2 به نسخهای از اینترنت اشاره دارد که امروزه اکثر ما میشناسیم. اینترنت تحت سلطهی شرکتهایی که در ازای اطلاعات شخصی شما خدمات ارائه میدهند. در بافت اتریوم، Web3 به برنامههای غیرمتمرکز اطلاق میشود که روی زنجیرهی بلوکی اجرا میشوند. اینها برنامههایی هستند که به هر کسی امکان میدهند بدون ثبت دادههای شخصی خود مشارکت داشته باشد.
-
-به دنبال منبعی هستید که برای مبتدیان مناسبتر باشد؟ [معرفی Web3](/web3/) ما را ببینید.
-
-## مزایای Web3 {#web3-benefits}
-
-بسیاری از توسعهدهندگان Web3 به دلیل تمرکززدایی ذاتی اتریوم، به سراغ ساختن dappها رفتهاند:
-
-- هر کسی که در شبکه است اجازه استفاده از این سرویس را دارد - یا به عبارت دیگر، مجوز لازم نیست.
-- هیچ کس نمیتواند شما را مسدود کند یا از دسترسی شما به این سرویس جلوگیری کند.
-- پرداختها از طریق توکن بومی، اتر (ETH) انجام میشوند.
-- اتریوم تورینگ کامل است، به این معنی که تقریباً میتوانید هر چیزی را برنامهنویسی کنید.
-
-## مقایسههای عملی {#practical-comparisons}
-
-| Web2 | Web3 |
-| --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| توییتر میتواند هر حساب کاربری یا توییتی را سانسور کند | توییتهای Web3 غیرقابل سانسور هستند زیرا کنترل غیرمتمرکز است |
-| ممکن است سرویس پرداخت تصمیم بگیرد که برای انواع خاصی از کار، پرداخت را مجاز نکند | برنامههای پرداخت Web3 به اطلاعات شخصی نیاز ندارند و نمیتوانند از پرداخت جلوگیری کنند |
-| سرورهای برنامههای اقتصادی کلان ممکن است از کار بیفتند و بر درآمد کارگران تأثیر بگذارند | سرورهای Web3 نمیتوانند از کار بیفتند - آنها از اتریوم، یک شبکه غیرمتمرکز از هزاران رایانه بهعنوان پشتیبان خود استفاده میکنند |
-
-این بدان معنا نیست که همهی خدمات باید به dapp تبدیل شوند. این مثالها تفاوتهای اصلی بین خدمات web2 و web3 را نشان میدهند.
-
-## محدودیتهای Web3 {#web3-limitations}
-
-Web3 در حال حاضر محدودیتهایی دارد:
-
-- مقیاسپذیری - تراکنشها در Web3 کندتر هستند چون غیرمتمرکز هستند. تغییرات در حالت، مانند پرداخت، باید توسط یک گره پردازش شده و در سراسر شبکه منتشر شود.
-- UX – تعامل با برنامههای web3 ممکن است به مراحل، نرم افزار و آموزش اضافی نیاز داشته باشد. این موضوع میتواند مانعی برای پذیرش باشد.
-- قابلیت دسترسی – عدم یکپارچگی در مرورگرهای وب مدرن باعث میشود که Web3 برای اکثر کاربران کمتر در دسترس باشد.
-- هزینه – اکثر dappهای موفق بخشهای بسیار کوچکی از کد خود را روی زنجیرهی بلوکی قرار میدهند، چون این کار گران است.
-
-## تمرکز در مقابل عدم تمرکز {#centralization-vs-decentralization}
-
-در جدول زیر، برخی از مزایا و معایب شبکههای دیجیتال متمرکز و غیرمتمرکز را فهرست کردهایم.
-
-| سیستمهای متمرکز | سیستمهای غیرمتمرکز |
-| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| قطر شبکهی کم (همه شرکتکنندگان به یک مرجع مرکزی متصل هستند). اطلاعات به سرعت منتشر میشود، زیرا انتشار توسط یک مرجع مرکزی با منابع محاسباتی فراوان اداره میشود. | دورترین مشارکت کنندگان در شبکه ممکن است به طور بالقوه از یکدیگر بسیار دور باشند. انتشار اطلاعات از یک طرف شبکه ممکن است زمان زیادی طول بکشد تا به طرف دیگر برسد. |
-| معمولاً کارایی بالاتر (بازدهی بیشتر، منابع محاسباتی مصرفشدهی کمتر در مجموع) و پیادهسازی آسانتری دارند. | معمولاً کارایی کمتر (توان عملیاتی کمتر، منابع محاسباتی مصرفشدهی بیشتر در مجموع) و پیادهسازی پیچیدهتری دارند. |
-| در صورت وجود دادههای متناقض، حل و فصل آنها روشن و آسان است: منبع نهایی حقیقت، قدرت مرکزی است. | اگر همتایان ادعاهای متناقضی در مورد وضعیت دادههایی داشته باشند که قرار است شرکتکنندگان روی آن هماهنگ شوند، یک پروتکل (اغلب پیچیده) برای حل اختلاف موردنیاز است. |
-| تک نقطهی شکست: کاربران مخرب ممکن است بتوانند با هدف قرار دادن بخش مرکزی، شبکه را از بین ببرند. | هیچ نقطهی شکست واحدی وجود ندارد: حتی اگر تعداد زیادی از شرکتکنندگان مورد حمله/خروج قرار گیرند، شبکه همچنان میتواند کار کند. |
-| هماهنگی بین شرکتکنندگان در شبکه بسیار آسانتر است و توسط یک مقام مرکزی اداره میشود. قدرت مرکزی میتواند شرکت کنندگان شبکه را وادار کند که ارتقا، بهروزرسانی پروتکل و غیره را با تنش کمتری انجام دهند. | هماهنگی اغلب دشوار است، زیرا هیچ عاملی حرف آخر را در تصمیمگیریهای سطح شبکه، ارتقای پروتکل و غیره نمیزند. در بدترین حالت، زمانی که در مورد تغییرات پروتکل اختلاف نظر وجود داشته باشد، شبکه مستعد از بین رفتن است. |
-| مرجع مرکزی میتواند دادهها را سانسور کند و به طور بالقوه بخشهایی از شبکه را از تعامل با بقیه شبکه قطع کند. | سانسور بسیار سختتر است، زیرا اطلاعات راههای زیادی را برای انتشار در سراسر شبکه دارند. |
-| مشارکت در شبکه توسط مرجع مرکزی کنترل میشود. | هر کسی میتواند در شبکه مشارکت کند. هیچ «نگهبانی» وجود ندارد. در حالت ایدهآل، هزینهی مشارکت بسیار پایین است. |
-
-توجه داشته باشید که اینها الگوهای کلی هستند که ممکن است در هر شبکهای صادق نباشند. علاوه بر این، در واقعیت، میزان متمرکز/غیرمتمرکز بودن یک شبکه در یک طیف قرار دارد. هیچ شبکهای کاملاً متمرکز یا کاملاً غیرمتمرکز نیست.
-
-## بیشتر بخوانید {#further-reading}
-
-- [Web3 چیست؟](/web3/) - _ethereum.org_
-- [معماری یک برنامه Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _پریتی کسیردی_
-- [معنای تمرکززدایی](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _6 فوریه 2017، ویتالیک بوترین_
-- [چرا تمرکززدایی مهم است](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) _18 فوریه 2018 - کریس دیکسون_
-- [Web 3.0 چیست و چرا مهم است](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _31 دسامبر 2019 - مکس مِرش و ریچارد موریهد_
-- [چرا به وب 3.0 نیاز داریم](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _12 سپتامبر 2018 - گاوین وود_
diff --git a/public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md b/public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md
deleted file mode 100644
index e92be3f2ac5..00000000000
--- a/public/content/translations/fa/13) Foundational Docs/developers/docs/wrapped-eth/index.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: رپد اتر (WETH) چیست؟
-description: مقدمه ای بر رپد اتر (WETH) - یک پوشش سازگار با ERC20 برای اتر (ETH).
-lang: fa
----
-
-# رپد اتر (WETH) {#intro-to-weth}
-
-اتر (ETH) ارز اصلی اتریوم است. از آن برای چندین هدف مانند سهام گذاری، به عنوان ارز، و پرداخت هزینه های گس برای محاسبه استفاده می شود. **WETH عملاً یک شکل ارتقا یافته از ETH با برخی عملکردهای اضافی مورد نیاز بسیاری از برنامهها و [ERC-20 tokens](/glossary/#erc-20)** است که انواع دیگری از داراییهای دیجیتال در اتریوم هستند. برای کار با این توکن ها، ETH باید از همان قوانینی که به عنوان استاندارد ERC-20 شناخته می شوند، پیروی کند.
-
-برای پر کردن این شکاف، رپد اتر (WETH) ایجاد شد. **رپد اتر (WETH) یک قرارداد هوشمند است که به شما اجازه میدهد هر مقدار اتر را به این قرارداد واریز کنید و به ازای هر اتر واریزی، مقدار برابر آن را به صورت توکن WETH ضرب شده دریافت کنید** که مطابق با استاندارد توکن ERC-20 است. WETH گونهای از ETH است که به شما امکان می دهد با آن به عنوان یک توکن ERC-20 تعامل داشته باشید، نه به عنوان ETH دارایی بومی. برای پرداخت هزینه های گس همچنان به ETH بومی نیاز دارید، بنابراین مطمئن شوید که هنگام واریز مقداری پس انداز کرده اید.
-
-با استفاده از قرارداد هوشمند WETH می توانید WETH را به ETH تبدیل کنید. با قرارداد هوشمند WETH می توانید هر مقدار WETH را بازخرید کنید و همان مقدار را به صورت اتریوم دریافت خواهید کرد. سپس WETH سپرده شده سوزانده میشود و از منبع در حال گردش WETH خارج می شود.
-
-**تقریباً 3٪ از عرضه ETH در گردش در قرارداد توکن WETH قفل شده است** و آن را به یکی از پرکاربردترین [قراردادهای هوشمند] تبدیل می کند (/glossary/#smart-contract). WETH به ویژه برای کاربرانی که با برنامههای کاربردی در امور مالی غیرمتمرکز (DeFi) تعامل دارند، مهم است.
-
-## چرا به رپد ETH به عنوان ERC-20 نیاز داریم؟ {#why-do-we-need-to-wrap-eth}
-
-[ERC-20](/developers/docs/standards/tokens/erc-20/) یک رابط استاندارد برای توکنهای قابل انتقال تعریف میکند، بنابراین هر کس میتواند توکنهایی ایجاد کند که به طور یکپارچه با برنامهها و توکنهایی که از این استاندارد در اکوسیستم اتریوم استفاده میکنند، تعامل داشته باشند. از آنجا که **ETH قبل از استاندارد ERC-20** ایجاد شده است، ETH با این مشخصات مطابقت ندارد. این به این معنی است که **شما نمی توانید به راحتی** ETH را با سایر توکنهای ERC-20 مبادله کنید یا **از ETH در برنامه ها با استفاده از استاندارد ERC-20 استفاده کنید**. رپ کردن ETH به شما این فرصت را می دهد که کارهای زیر را انجام دهید:
-
-- **مبادله ETH با توکن های ERC-20**: شما نمی توانید ETH را مستقیماً با سایر توکن های ERC-20 مبادله کنید. WETH گونهای اتر است که با استاندارد توکن قابل تعویض ERC-20 مطابقت دارد و می تواند با سایر توکن های ERC-20 مبادله شود.
-
-- **از ETH در dapp ها استفاده کنید**: از آنجا که ETH با ERC20 سازگار نیست، توسعه دهندگان باید رابط های جداگانه ای (یکی برای ETH و دیگری برای توکن های ERC-20) در dapp ها ایجاد کنند. رپ کردن ETH این مانع را برطرف میکند و توسعهدهندگان را قادر میسازد تا ETH و سایر توکنها را در همان dapp مدیریت کنند. بسیاری از برنامه های مالی غیرمتمرکز از این استاندارد استفاده می کنند و بازارهایی را برای مبادله این توکن ها ایجاد می کنند.
-
-## رپد اتر (WETH) در مقابل اتر (ETH): تفاوت در چیست؟ {#weth-vs-eth-differences}
-
-| | **اتر (ETH)** | **رپد اتر (WETH)** |
-| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| عرضه | عرضه ETH توسط پروتکل اتریوم مدیریت می شود. هنگام پردازش تراکنشها و ایجاد بلوک، [issuance](/roadmap/merge/issuance) اتر توسط اعتبارسنجهای اتریوم مدیریت میشود. | WETH یک توکن ERC-20 است که عرضه آن توسط یک قرارداد هوشمند مدیریت می شود. واحدهای جدید WETH پس از دریافت سپرده های ETH از کاربران توسط قرارداد صادر می شوند، یا زمانی که کاربر می خواهد WETH را برای ETH بازخرید کند، واحدهای WETH سوزانده می شوند. |
-| مالکیت | مالکیت توسط پروتکل اتریوم از طریق موجودی حساب شما مدیریت می شود. | مالکیت WETH توسط قرارداد هوشمند توکن WETH مدیریت می شود که توسط پروتکل اتریوم ایمن شده است. |
-| گاز | اتر (ETH) واحد پرداخت پذیرفته شده برای محاسبه در شبکه اتریوم است. هزینه های گس بر حسب gwei (واحد اتر) تعیین می شود. | پرداخت گس با توکن های WETH به صورت بومی پشتیبانی نمی شود. |
-
-## سوالات متداول {#faq}
-
-
-
-برای رپ یا آنرپ کردن ETH با استفاده از قرارداد WETH هزینه گس می پردازید.
-
-
-
-
-
-WETH به دلیل اینکه بر اساس یک قرارداد هوشمند ساده و آزمایششده ساخته شده است، به طور کلی امن در نظر گرفته میشود. قرارداد WETH نیز به طور رسمی تأیید شده است که بالاترین استاندارد امنیتی برای قراردادهای هوشمند در اتریوم است.
-
-
-
-
-
-علاوه بر پیادهسازی متعارفِ WETH[canonical implementation of WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) که در این صفحه توضیح داده شد، نسخههای دیگری از آن نیز وجود دارند. اینها ممکن است توکنهای سفارشی ایجاد شده توسط توسعهدهندگان اپلیکیشن یا نسخههای منتشر شده در سایر بلاک چینها باشند و ممکن است رفتار متفاوت یا ویژگیهای امنیتی متفاوت داشته باشند. **همیشه اطلاعات توکن را دوباره بررسی کنید تا بدانید با کدام اجرای WETH در حال تعامل هستید.**
-
-
-
-
-
-- [شبکه اصلی اتریوم](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
-- [آربیتروم](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
-- [آپتیمیزم](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
-
-
-
-## ادامه مطلب {#further-reading}
-
-- [آیا WTF WETH است؟](https://weth.tkn.eth.limo/)
-- [اطلاعات توکن WETH در Etherscan](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2)
-- [تأیید رسمی WETH](https://zellic.io/blog/formal-verification-weth)
diff --git a/public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md b/public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md
deleted file mode 100644
index 933e7e19a27..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/code-of-conduct/index.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: آییننامه رفتاری
-description: استانداردهای اصلی که ما در کل فضای ethereum.org برای آنها تلاش میکنیم.
-lang: fa
----
-
-# آییننامه رفتاری {#code-of-conduct}
-
-## مأموریت {#mission}
-
-توسعه و حفظ جامعترین و دسترسپذیرترین مرکز دانش برای شبکۀ اتریوم.
-
-## ارزشها {#values}
-
-جامعۀ ethereum.org در تلاش است که اینگونه باشد:
-
-- آموزشی؛ با قصد کمک به همه افراد در فهمیدن اتریوم
-- فراگیر
-- در دسترس
-- جامعه-محور
-- متمرکز بر تکنولوژی و کاربردهای اصلی اتریوم
-- متمرکز بر معنای کلی و اصول طراحی اتریوم
-
-## آنچه ما نیستیم {#what-we-are-not}
-
-- وبسایت بنیاد اتریوم
-- یک پلتفرم برای ترویج سرمایهگذاری و یا کسب سود از هر نوعی
-- پلتفرمی برای ارتقا یا حمایت از پروژهها یا سازمانها
-- یک DEX یا CEX یا نوع دیگری از پلتفرمهای مالی
-- پلتفرمی که مشاورۀ مالی یا حقوقی از هر نوع ارائه میدهد
-
-## آییننامه رفتاری {#code-of-conduct}
-
-### تعهد {#pledge}
-
-مشارکت باز و آزادانه، هستۀ اصلی صفات و شخصیت جامعۀ ethereum.org است. ما یک وبسایت و جامعهای استقراریافته توسط هزاران مشارکتکننده هستیم که فقط از طریق ایجاد یک محیط مشارکتی و پذیرا امکانپذیر است. برای این مقصود، مشارکتکنندگان تعهد میدهند که یک محیط عاری از تعرض و آزار برای تمام اعضای مشارکتجو در هر یک از پلتفرمها و انجمنهای ethereum.org به وجود آورند. وبسایت ethereum.org پذیرای هر فردی است که به مشارکت سازنده و دوستانه علاقه دارد و بدون توجه به سن، قومیت، جنسیت، هویت، سطح مهارت و تجربه، زمینۀ کاری، تحصیلات، وضعیت اقتصادی-اجتماعی، ملیت، ظاهر شخصی، نژاد، مذهب یا هر بُعد دیگر گوناگونی، به آنها ارزش مینهد.
-
-### محدوده {#scope}
-
-این آییننامۀ رفتاری در تمام فضای کاری ethereum.org مانند GitHub، Discord، Twitter، Figma Crowdin و سایر پلتفرمهای آنلاین و همچنین هر جا که این جامعه در فضای عمومی دنیای واقعی (نشستها، کنفرانسها و رویدادها) ظاهر میشود، صادق است.
-
-### استانداردهای ما {#our-standards}
-
-مثالهای رفتاری که به ایجاد یک محیط سازنده و مثبت کمک میکند شامل این موارد است:
-
-- استفاده از زبان خوشایند و فراگیر
-- محترم شمردن تجربیات و دیدگاههای متفاوت
-- پذیرش موقرانه و یا طرح همدلانۀ انتقادهای سازنده
-- حفظ آرامش و رفتار حرفهای هنگام حل تعارضها و اختلاف نظر
-- نشان دادن همدلی و بردباری در مواجهه با سایر اعضای جامعه
-- تشویق و تقویت آرا و نظرات جدید در جامعه
-
-مثالهای رفتارهای غیرقابل پذیرش از سوی اعضا شامل این موارد است:
-
-- خشونت فیزیکی، خشونت تهدید آمیز یا ترغیب و ترویج خشونت فیزیکی از هر نوع
-- استفاده از زبان و تصاویر جنسیتزده یا تحمیل توجه جنسی ناخواسته
-- جعل هویت سایرین یا ادعای دروغِ داشتن رابطه با یک فرد یا سازمان
-- مسخره کردن، نظرات توهینآمیز یا تحقیرآمیز و حملات شخصی یا سیاسی
-- آزار رساندن به سایر اعضای جامعه در کانالهای عمومی و خصوصی
-- منتشر کردن اطلاعات خصوصی دیگران مانند آدرس فیزیکی یا الکترونیکی، بدون اجازۀ صریح
-- مهندسی اجتماعی، اسکم کردن یا اعمال نفوذ بر اعضای جامعه
-- تبلیغ و ترویج فرصتهای سرمایهگذاری، توکنها، پروژهها یا هر نوع دیگر از عایدی شخصی مالی یا غیرمالی
-- ارسال اطلاعات هرز به سرور با موضوعات غیرمرتبط
-- بیاعتنایی به درخواستها و هشدارهای مدیران انجمنها و جوامع
-- اقدام به هر گونه رفتار دیگر که در یک محیط حرفهای میتواند نامناسب پنداشته شود
-
-### گزارشدهی {#reporting}
-
-تخطی از آییننامه رفتاری، اغلب بر اعضای جامعه آشکار خواهد بود چون ما هر کاری را در کانالها و فضای باز و عمومی انجام میدهیم، در واقع میگذاریم خودِ اعضای جامعه، پلیس باشند و نظم را برقرار کنند.
-
-به هر حال اگر اتفاقی افتاد که از نظرتان نیاز به توجه و رسیدگی دارد، میتوانید آن را با فردی که نقش میانجیگری دارد (برای مثال راهنمای دیسکورد) مطرح کنید تا بتوانند به فرایند بررسی و واکنش مناسب کمک کنند.
-
-هنگام گزارشدهی بهتر است تا جایی که میتوانید جزئیات مختلف مانند مثالهای خاص و برچسبهای زمان را درج کنید. این کار در دستیابی به نتیجهای عادلانه اثربخش است.
-
-### اعمال قانون {#enforcement}
-
-افرادی که قوانین رفتاری را نقض کنند، بسته به شدت عمل ممکن است هشدار بگیرند، به صورت موقت محروم شوند یا مشمول ممنوعیت دائمی از جامعۀ etheruem.org شوند.
diff --git a/public/content/translations/fa/14) Community Pages/community/events/index.md b/public/content/translations/fa/14) Community Pages/community/events/index.md
deleted file mode 100644
index 373618a54a3..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/events/index.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: رویدادهای اتریوم
-description: چگونه در انجمن اتریوم شرکت کنیم؟
-lang: fa
-hideEditButton: true
----
-
-# رویدادهای پیشرو {#events}
-
-**هر ماه، رویدادهای مهم اتریوم در سرتاسر جهان برگزار میشود.** شرکت در یکی از رویدادهای نزدیک به خود را در نظر داشته باشید تا با افراد بیشتری در جامعه آشنا شوید، درباره فرصتهای شغلی اطلاع کسب کنید و مهارتهای جدید را توسعه دهید.
-
-
-
-این یک لیست غیرجامع است که توسط انجمن ما نگهداری می شود. از رویداد آتی اتریوم برای اضافه کردن به این لیست اطلاع دارید؟ [لطفاً آن را اضافه کنید](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-events.json)!
-
-## گردهماییهای اتریوم {#meetups}
-
-رویدادی را نمیبینید که برای شما مفید باشد؟ شرکت در یک گردهمایی را امتحان کنید. گردهماییها رویدادهای کوچکتری هستند که توسط گروههایی از علاقهمندان به اتریوم برگزار میشوند - فرصتی برای افراد علاقهمند به اتریوم تا دور هم جمع شوند، درباره اتریوم صحبت کنند، و در مورد پیشرفتهای اخیر اطلاعات کسب کنند.
-
-
-
-علاقهمند به برگزاری گردهمایی خود هستید؟ [شبکهی BUIDL](https://consensys.net/developers/buidlnetwork/) را بررسی کنید، ابتکاری توسط ConsenSys برای کمک به حمایت از انجمنهای ملاقات اتریوم.
-
-این یک فهرست غیرجامع است که توسط انجمن ما ساخته شده است. میتوانید [گردهماییهای اتریوم بیشتری را در اینجا بیابید](https://www.meetup.com/topics/ethereum/). گروه ملاقات فعالی برای اضافه کردن به این فهرست میشناسید؟ [لطفاً آن را اضافه کنید](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-meetups.json)!
diff --git a/public/content/translations/fa/14) Community Pages/community/get-involved/index.md b/public/content/translations/fa/14) Community Pages/community/get-involved/index.md
deleted file mode 100644
index ab71b2d4692..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/get-involved/index.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: چطور میتوانم مشارکت کنم؟
-description: چگونه در انجمن اتریوم شرکت کنیم؟
-lang: fa
----
-
-# چطور میتوانم مشارکت کنم؟ {#get-involved}
-
-جامعهی اتریوم شامل افرادی با زمینهها و مهارتهای مختلف است. فرقی نمیکند توسعهدهنده باشد، هنرمند یا حسابدار؛ راههایی برای مشارکت وجود دارد. در اینجا فهرستی از پیشنهاداتی که ممکن است به شما در شروع کار کمک کند، وجود دارد.
-
-با مطالعه ماموریت و ارزش های ethereum.org در [منشور اخلاقی](/community/code-of-conduct) ما شروع کنید.
-
-## توسعهدهندگان {#developers}
-
-- در [ethereum.org/developers/](/developers/) درباره اتریوم یاد بگیرید و آن را امتحان کنید
-- در یک هکاتون [ETHGlobal](http://ethglobal.co/) در نزدیکی خود شرکت کنید!
-- [پروژههای مرتبط با حوزهی تخصصی یا زبان برنامهنویسی انتخابی خود را بررسی کنید](/developers/docs/programming-languages/)
-- [فراخوانهای لایه اجماع و اجرا](https://www.youtube.com/@EthereumProtocol/streams) را تماشا کنید یا در آن شرکت کنید
-- [فهرست نیازمندیهای برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/wishlist/) - ابزار، اسناد و مناطق زیرساختی که در آن برنامه حمایت از اکوسیستم اتوریوم فعالانه به دنبال کمک به برنامههای کمکی است
-- [Web3Bridge](https://www.web3bridge.com/) - برای شناسایی، آموزش و حمایت از صدها توسعهدهنده و اعضای انجمن در سراسر آفریقا به جامعهی مشتاق web3 بپیوندید
-- به [ دیسکورد Eth R&&D](https://discord.com/invite/VmG7Uxc) بپیوندید
-- به [دیسکورد Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) بپیوندید
-
-## محققان و دانشگاهیان {#researchers-and-academics}
-
-آیا سابقهای در زمینه ریاضیات، رمزنگاری یا اقتصاد دارید؟ ممکن است به برخی از کارهای پیشرفتهای که در اکوسیستم اتریوم انجام میشود علاقهمند باشید:
-
-- به [ دیسکورد Eth R&&D](https://discord.com/invite/VmG7Uxc) بپیوندید
-- نوشتن یا بررسی یک پیشنهاد بهبود اتریوم
- - یک EIP (پیشنهاد بهبود اتریوم) بنویسید
- 1. ایده خود را در [Ethereum Magicians](https://ethereum-magicians.org) ارسال کنید
- 2. [EIP-1](https://eips.ethereum.org/EIPS/eip-1) را بخوانید - **بله، این _کل_ سند است.**
- 3. دستورالعمل ها را در EIP-1 دنبال کنید. در حین نگارش پیش نویس، به آن ارجاع دهید.
- - یاد بگیرید که چگونه یک [ویرایشگر EIP](https://eips.ethereum.org/EIPS/eip-5069) شوید
- - حالا می توانید EIPها را مورد بازبینی قرار دهید! [PRهای موجود با تگ`e-review` را مشاهده کنید](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review). بازخورد فنی را با کلیک بر `discussion-to` ثبت کنید.
- - در [حاکمیت پیشنهادهای بهبود اتریوم](https://github.com/ethereum-cat-herders/EIPIP) مشارکت کنید
- - به [دیسکورد Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) بپیوندید
- - [اطلاعات بیشتر درباره EIPها](/eips/)
-- [Challenges.ethereum.org](https://challenges.ethereum.org/) - مجموعهای از جایزههای تحقیقاتی با ارزش، که در آن میتوانید تا >100,000 دلار آمریکا کسب کنید
-- [Ethresear.ch](https://ethresear.ch) - انجمن اصلی اتریوم برای تحقیقات، و تأثیرگذارترین انجمن جهان برای اقتصاد رمزنگاری
-- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - مجموعهای ادامهدار از پرسش &و پاسخ با پژوهشگران. با باز شدن هر قسمت جدید، هر کس میتواند سؤالاتش را ارسال کند.
-- [فهرست نیازمندیهای برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/wishlist/) - زمینههای تحقیقاتی که در آنها برنامه پشتیبانی اکوسیستم اتریوم فعالانه به دنبال درخواستهای کمک مالی است
-- [AllWalletDevs](https://allwallet.dev) - انجمنی برای توسعه دهندگان، طراحان و کاربران علاقه مند اتریوم که به طور منظم گرد هم می آیند و درباره کیفپول ها بحث می کنند
-
-[حیطههای پژوهشی فعال بیشتری را کشف کنید](/community/research/).
-
-## مجموعهی مهارتهای غیرفنی {#non-technical}
-
-اگر توسعهدهنده نیستید، ممکن است دانستن اینکه از کجا در اتریوم شروع کنید سخت باشد. در اینجا چند پیشنهاد به همراه منابعی برای زمینههای حرفهای خاص آورده شده است.
-
-### یک گردهمایی در شهر خود ترتیب دهید {#meetups}
-
-- نمیدانید چگونه شروع کنید؟ [شبکهی BUIDL](https://consensys.net/developers/buidlnetwork/) میتواند به شما کمک کند.
-
-### در مورد اتریوم مطلب بنویسید {#write-content}
-
-- اتریوم نیاز به نویسندگان خوبی دارد که بتوانند ارزش آن را به زبان ساده توضیح دهند
-- برای انتشار مقالات خود آماده نیستید؟ کمک به بهبود مطالب و مقالات کنونی موجود در منابع جامعه اتریوم، یا [پیشنهاد محتوای جدید برای ethereum.org](/contributing/) را به عنوان راهی برای مشارکت در نظر بگیرید!
-
-### پیشنهاد یادداشتبرداری برای تماسهای انجمن {#take-notes}
-
-- تماسهای جامعه متنباز بسیاری وجود دارد و داشتن یادداشتنویسی کمک بزرگی است. اگر علاقهمند هستید، به [Ethereum Cat Herders در دیسکورد](https://discord.com/invite/Nz6rtfJ8Cu) بپیوندید و خود را معرفی کنید!
-
-### محتوای اتریوم را به زبان مادری خود ترجمه کنید {#translate-ethereum}
-
-- ethereum.org یک برنامهی ترجمه دارد که وبسایت و سایر منابع را به بسیاری از زبانهای مختلف ترجمه میکند
-- نحوهی مشارکت را در [اینجا](/contributing/translation-program) بیاموزید
-
-### راهاندازی یک گره {#run-a-node}
-
-به هزاران اپراتور گره بپیوندید تا به تمرکززدایی بیشتر اتریوم کمک کنید.
-
-- [اطلاعات بیشتر در مورد نحوهی اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/)
-
-### اتر خود را سهامگذاری کنید {#staking}
-
-با سهامگذاری ETH خود میتوانید پاداش به دست آورید و در عین حال به ایمنسازی شبکه اتریوم کمک کنید.
-
-- [اطلاعات بیشتر درباره سرمایهگذاری](/staking/)
-
-### حمایت از پروژهها {#support-projects}
-
-اکوسیستم اتریوم به دنبال تأمین مالی کالاهای عمومی و پروژههای تأثیرگذار است. با کمکهای مالی بسیار کوچک میتوانید حمایت خود را نشان دهید و کمک کنید کارهای مهم محقق شود.
-
-- [Gitcoin](https://gitcoin.co/fund)
-- [clr.fund](https://clr.fund/#/about)
-
-## متخصصان مالی و حسابداران {#financial-professionals}
-
-- اتریوم خانهی اکوسیستم «امور مالی غیرمتمرکز» است - شبکهای از پروتکلها و برنامههای کاربردی که یک سیستم مالی جایگزین را ارائه میدهد. اگر در امور مالی حرفهای هستید، به برخی اپلیکیشنهای اقتصادی غیرمتمرکز (DeFi) در [DeFi Pulse](https://defillama.com/) یا [DeFiPrime](https://defiprime.com) سر بزنید
-- حسابدار هستید؟ داراییهای موجود در اتریوم - اتر، توکنها، دیفای و غیره - بسیاری از مسائل جدید حسابداری را معرفی میکنند. میتوانید با بررسی پروژههایی که هدفشان کمک به کاربران ارزهای دیجیتال برای حل چالشهای دفترداری و حسابداری است، مانند [Rotki](https://rotki.com/)، شروع کنید
-
-## مدیران محصول {#product-managers}
-
-- اکوسیستم اتریوم به استعدادهای شما نیاز دارد! بسیاری از شرکتها در حال استخدام برای سمت مدیر محصول هستند. اگر میخواهید با مشارکت در یک پروژه منبع باز شروع کنید، با [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) یا [RaidGuild](https://www.raidguild.org/) تماس بگیرید
-
-## بازاریابی {#marketing}
-
-- موقعیتهای بازاریابی و ارتباطی زیادی در اکوسیستم اتریوم وجود دارد!
-
-## فرصتهای شغلی اتریوم {#ethereum-jobs}
-
-**میخواهید یک شغل مرتبط با اتریوم پیدا کنید؟**
-
-- [فرصتهای شغلی ethereum.org](/about/#open-jobs)
-- [سایت استخدامی بنیاد اتریوم (Lever)](https://jobs.lever.co/ethereumfoundation)
-- [سایت استخدامی بنیاد اتریوم (BambooHR)](https://ethereum.bamboohr.com/jobs/)
-- [JobStash](https://jobstash.xyz)
-- [فرصتهای شغلی مرتبط با ارزهای رمزنگاریشده](https://cryptocurrencyjobs.co/ethereum/)
-- [مشاغل در ConsenSys](https://consensys.net/careers/)
-- [فهرست فرصتهای شغلی رمزنگاری](https://cryptojobslist.com/ethereum-jobs)
-- [سایت استخدامی Bankless](https://pallet.xyz/list/bankless/jobs)
-- [فرصتهای شغلی وب 3](https://web3.career)
-- [Web3 Army](https://web3army.xyz/)
-- [فرصتهای شغلی Crypto Valley](https://cryptovalley.jobs/)
-- [فرصتهای شغلی اتریوم](https://startup.jobs/ethereum-jobs)
-- [CryptoJobster](https://cryptojobster.com/tag/ethereum/)
-
-## پیوستن به DAO {#decentralized-autonomous-organizations-daos}
-
-«DAOها» سازمانهای مستقل غیرمتمرکز هستند. این گروهها از فناوری اتریوم برای تسهیل سازماندهی و همکاری استفاده میکنند. به عنوان مثال، برای کنترل عضویت، رأی دادن در مورد پیشنهادها، یا مدیریت داراییهای مشارکتی. درست است که DAOها هنوز آزمایشی هستند، اما فرصتهایی را برای شما فراهم می کنند تا گروههایی را که با آنها همسو هستید پیدا کنید و تأثیر خود را روی جامعه اتریوم افزایش دهید. [درباره DAOها بیشتر بدانید](/dao/)
-
-- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) - _مفهوم DAO را در زمینه غیر فناوری ترویج میکند و در ایجاد ارزش از طریق DAO به افراد کمک میکند_
-- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) - _جامعهی سازندگانی که به مالکیت جمعی اینترنت اعتقاد دارند_
-- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) - *شرکت جمعی توسعهی Web3 Freelancer که بهعنوان DAO کار میکند*
-- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) - *حاکمیت اجتماعی DAOhaus*
-- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) - *مهندسی حقوقی*
-- [Machi X](https://machix.com) [@MachiXOfficial](https://twitter.com/MachiXOfficial) - *جامعهی هنری*
-- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) - *سرمایه گذاری برای پروژه های کریپتو پیش از آغاز به کار*
-- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) - *مکانیزمهای بازیهای MMORPG در زمان حال*
-- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) - *برندهای پوشاک دیجیتالی*
-- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) - *جامعهای با تمرکز بر تأمین مالی توسعهی اتریوم*
-- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) - *مجموعهی سازندگان Web3*
-
-لطفا هر زمان خواستید در ethereum.org مشارکت کنید به یاد داشته باشید از [منشور اخلاقی](/community/code-of-conduct) ethereum.org پیروی کنید!
diff --git a/public/content/translations/fa/14) Community Pages/community/grants/index.md b/public/content/translations/fa/14) Community Pages/community/grants/index.md
deleted file mode 100644
index 0cbd9a0ca1c..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/grants/index.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: بنیاد اتریوم و برنامههای کمک مالی جامعه
-description: فهرستی از برنامههای کمک مالی در کل اکوسیستم اتریوم.
-lang: fa
----
-
-# کمکهای مالی اتریوم {#ethereum-grants}
-
-برنامههای فهرست شده در زیر، کمکهای مالی گوناگونی برای پروژهها جهت موفقیت و رشد اکوسیستم اتریوم اعطا میکنند. از این فهرست بهعنوان یک راهنما برای یافتن و درخواست کردن کمکهای مالی جهت کمک به موفقیت پروژه بعدی اتریوم خود استفاده کنید.
-
-این فهرست توسط جامعهی ما جمعآوری میشود. اگر چیزی ناقص یا نادرست است، لطفاً این صفحه را ویرایش کنید!
-
-## اکوسیستم گستردهی اتریوم {#broad-ethereum-ecosystem}
-
-این برنامهها از اکوسیستم گستردهی اتریوم با اعطای کمکهای مالی به دامنهی وسیعی از پروژهها حمایت میکنند. راهحلهایی جهت مقیاسپذیری، جامعهسازی، ایمنی، حریم شخصی و غیره از این جمله هستند. این کمکهای مالی مختص به یک پلتفرم اتریوم خاص نیستند و اگر مردد هستید نقطهی خوبی برای شروع است.
-
-- [برنامه پشتیبانی اکوسیستم بنیاد اتریوم](https://esp.ethereum.foundation) - _تامین مالی پروژههای منبع بازی که به اتریوم سودرسانی میکنند، با تمرکز بر ابزار های جهانی، زیرساخت، پژوهش و منافع عمومی_
-- [Moloch DAO](https://www.molochdao.com/) - _حریم خصوصی، مقیاسپذیری لایهی 2، امنیت کاربر و غیره_
-- [ کمکهای مالی DAO](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) - _صفحهگسترده Google از سازمانهای ارائهدهندهی کمکهای مالی_
-- [کمکهای مالی تحصیلی](https://esp.ethereum.foundation/academic-grants)-_کمکهای مالی برای تحقیقات آکادمیک مربوط به اتریوم_
-- [Blockworks Grantfarm](https://blockworks.co/grants/programs) - _Blockworks یک مجموعه جامع از تمامی کمکهای مالی، RFPها، و پاداشهای گزارش اشکالات._
-
-## خاص هر پروژه {#project-specific}
-
-این پروژهها برای پروژههایی که در راستای توسعه و آزمایش فناوری خود هستند کمکهای مالی خود را ساختهاند.
-
-- [برنامهی کمکهای مالی Aave](https://aavegrants.org/) - _[Aave](https://aave.com/) DAO_ را اعطا میکند
-- [Balancer](https://grants.balancer.community/) – _صندوق اکوسیستم [Balancer](https://balancer.fi/)_
-- [Chainlink Grants Program](https://chain.link/community/grants) - _ کمکهای مالی جامعه [Chainlink](https://chain.link/)_
-- [برنامه کمکهای مالی Decentraland](https://governance.decentraland.org/grants/) – _[Decentraland](https://decentraland.org/) DAO Metaverse_
-- [سازمان کمکهای مالی اکوسیستم Lido (LEGO)](https://lido.fi/lego) – _[اکوسیستم تأمین مالی Lido](https://lido.fi/)_
-- [برنامهی Metamask](https://metamaskgrants.org/) - _[سازمان خودمختار غیرمتمرکز کمکهای مالی کارمندمحور MetaMask](https://metamask.io/)_
-- [برنامه کمکهای مالی شبکه SKALE](https://skale.space/developers#grants) - _[اکوسیستم شبکه ](https://skale.space/)SKALE_
-- [برنامه کمک مالی بنیاد Swarm](https://my.ethswarm.org/grants) - _اکوسیستم [بنیاد Swarm](https://www.ethswarm.org/)_
-- [The Graph](https://thegraph.com/ecosystem/grants/) – _اکوسیستم [The Graph](https://thegraph.com/)_
-- [برنامه کمک مالی Uniswap](https://www.uniswapfoundation.org/approach) - _جامعه [Uniswap](https://uniswap.org/)_
-
-## کمک مالی درجهی دوم {#quadratic-funding}
-
-ریشههای متنباز اتریوم منجر به رشد مدل جدید و جالبی از جذب سرمایه شد: کمک مالی درجهی دوم. این مدل بهطور بالقوه میتواند روش کمک مالی ما به انواع و اقسام کارهای عامالمنفعه را بهبود دهد. کمک مالی درجهی دوم اطمینان حاصل میکند پروژههایی سرمایهی بیشتری جذب میکنند که دارای بیشترین تقاضای منحصربهفرد هستند. به عبارت دیگر، پروژههایی که هدفشان بهبود زندگی اکثریت مردم است. [اطلاعات بیشتر درباره کمک مالی درجهی دوم.](/defi/#quadratic-funding)
-
-- [Gitcoin](https://gitcoin.co/grants)
-- [clr.fund](https://clr.fund/)
-
-## کار کردن در اتریوم {#work-in-ethereum}
-
-آیا آمادهی شروع پروژهی شخصی خود نیستید؟ صدها شرکت هستند که به دنبال افراد پرشور برای کار و شرکت در اکوسیستم اتریوم هستند. اطلاعات بیشتر میخواهید؟ [مشاغل مرتبط با اتریوم را بررسی کنید](/community/get-involved/#ethereum-jobs)
diff --git a/public/content/translations/fa/14) Community Pages/community/language-resources/index.md b/public/content/translations/fa/14) Community Pages/community/language-resources/index.md
deleted file mode 100644
index 5d37dbbb7c5..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/language-resources/index.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: منابع زبانی
-description: منابع غیرانگلیسی برای یادگیری در مورد اتریوم
-lang: fa
----
-
-# منابع زبانی {#language-resources}
-
-جامعهی اتریوم یک جامعهی جهانی است و متشکل از میلیونها غیرانگلیسی زبان است.
-
-هدف ما ارائهی محتوای آموزشی به همه زبانها و کمک به غلبه بر موانع زبانی است که ورود افراد از سراسر جهان به اتریوم را به چالش تبدیل میکند.
-
-اگر ترجیح میدهید به زبان مادری خود مطالعه کنید یا فردی را میشناسید که انگلیسی صحبت نمیکند، میتوانید فهرستی از منابع مفید غیرانگلیسی را در زیر بیابید. صدها هزار نفر از مشتاقان اتریوم در این انجمنهای آنلاین گرد هم میآیند تا خبرها را به اشتراک بگذارند، درباره پیشرفتهای اخیر صحبت کنند، درباره مسائل فنی بحث کنند و آینده را تصور کنند.
-
-منبع آموزشی به زبان خود میشناسید؟ برای افزودن به فهرست [مسألهای مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new/choose)!
-
-## منابع Ethereum.org {#ethereum-org}
-
-وبسایت Ethereum.org بهطور بومی به بیش از 40 زبان ترجمه شده است که می توانید با استفاده از منوی انتخابگر زبان که در بالای هر صفحه قرار دارد، آنها را بیابید.
-
-![منوی انتخاب زبان](./language-selector-menu.png)
-
-اگر دوزبانه هستید و میخواهید به ما کمک کنید تا افراد بیشتری را جذب کنیم، میتوانید در [برنامهی ترجمه ethereum.org](/contributing/translation-program/#translation-program) نیز مشارکت داشته باشید و به ما کمک کنید تا وبسایت را ترجمه کنیم.
-
-## منابع انجمن {#community}
-
-### پرتغالی برزیلی {#br-pt}
-
-**اخبار**
-
-- [BeInCrypto](http://www.beincrypto.com.br) - اخبار و مقالات ارزهای دیجیتال، از جمله فهرستی از صرافیهای موجود در برزیل
-- [Cointelegraph](http://cointelegraph.com.br/category/analysis) - نسخهی برزیلی Cointelegraph، یک رسانه خبری مهم ارزهای دیجیتال
-- [Livecoins](http://www.livecoins.com.br/ethereum) - ابزارها و اخبار ارزهای رمزنگاریشده
-- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) - اخبار و گزارشهای ارزهای رمزنگاریشده
-- [Modular Crypto](https://modularcrypto.xyz/) - اخبار و مقالات آموزشی در مورد رمزارز
-
-**آموزشی**
-
-- [web3dev](https://www.web3dev.com.br/) - مرکز محتوا و انجمن دیسکورد برای توسعهدهندگان web 3.
-- [Web3Brasil](https://github.com/web3brasil/web3brasil) - منابعی برای آموزش Web3 و DeFi
-- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) - اخبار و آموزش ارزهای رمزنگاریشده، از جمله «اتریوم برای مبتدیان» و «دیفای» برای مبتدیان
-- [CriptoAtivos](http://www.criptoativos.wiki.br/) - اطلاعاتی از فضای رمزارز، آموزش و وبلاگ
-- [Cointimes](http://www.cointimes.com.br/) - اخبار و آموزش ارزهای رمزنگاریشده
-- [بستهی آغازین Web3](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) - راهنمایی برای پاسخ به سؤالات پرتکرار و سؤالات بنیادی ارزهای رمزنگاریشده
-
-### چینی {#zh}
-
-**منابع کلی**
-
-- [Ethereum.cn](https://www.ethereum.cn/) - محتوای نگهداریشده توسط انجمن، پوشش ارتقای لایه اجماع، تمام یادداشتهای گردهماییهای برنامهنویسی هسته، لایهی 2 و غیره.
-- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) - همهچیز را از اصول اولیه تا موضوعات پیشرفتهی اتریوم بیاموزید
-- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) - محتوای نگهداری شده توسط انجمن، پوشش دانش مرتبط با اتریوم، دیفای، NFT، Web3
-- [123ETH](https://123eth.org/) - دروازهای به اکوسیستم اتریوم
-- [Zhen Xiao](http://zhenxiao.com/blockchain/) - دورههای آنلاین رایگان درباره ارزهای دیجیتال و کاربردهای آن
-- [Whitepaper اتریوم](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6) - نسخهی چینی وایتپیپر
-
-**اکوسیستم اتریوم**
-
-- [ETHPlanet](https://www.ethplanet.org/) - هکاتونهای آنلاین و حضوری، ارائهدهندهی آموزش به دانشجویان دانشگاه
-- [PrimitivesLane](https://www.primitiveslane.org/) - یک گروه تحقیقاتی غیرانتفاعی با تمرکز بر فناوری زنجیرهی بلوکی
-- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) - انجمنی که به ترجمهی محتوای آموزشی اتریوم اختصاص دارد
-
-**برای توسعهدهندگان**
-
-- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) - یک گروه آموزشی برای مطالعهی پروژههای dapp و تبادل اندیشه و نظرات بهصورت هفتگی
-- [LearnBlockchain](https://learnblockchain.cn/) - انجمنی برای توسعهدهندگان جهت اشتراکگذاری اطلاعات در مورد فناوری زنجیرهی بلوکی
-
-**برای محققین رمزنگاری**
-
-- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) - یک حساب WeChat که رمزنگاری، امنیت و غیره را توضیح میدهد
-- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) - یک حساب WeChat که فناوری zk را توضیح میدهد
-
-### چک {#cs}
-
-- [Gwei.cz](https://gwei.cz) - جامعهی محلی با محوریت Web3 که محتوای آموزشی تولید میکند و رویدادهای آنلاین و حضوری را ساماندهی میکند
-- [Gwei.cz Příručka](https://prirucka.gwei.cz/) - راهنمای اتریوم برای مبتدیان
-- [DAO Příručka](https://dao.gwei.cz/) - راهنمای DAOها برای مبتدیان
-- [تبحر در اتریوم](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) - یادگیری زیروبم اتریوم به زبان چک
-
-### فرانسوی {#fr}
-
-- [اتریوم فرانسه](https://www.ethereum-france.com/) - اتریوم فرانسه رویدادها را سازماندهی میکند، محتوا تولید میکند و بحثهای مربوط به اتریوم را ترویج میکند
-- [Ethereum.fr](https://ethereum.fr/) - اخبار و آموزش اتریوم
-- [BanklessFR](https://banklessfr.substack.com/) - خبرنامهی Bankless به زبان فرانسوی
-- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) - انجمن ارزهای رمزنگاری شده با زیرصفحهای برای اتریوم
-
-### آلمانی {#de}
-
-- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) - از Solidity استفاده کنید
-- [Microsoft Learn (قراردادهای هوشمند)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - نوشتن قراردادهای هوشمند اتریوم با Solidity
-- [Microsoft Learn (شبکههای اتریوم)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) - آموزش اتصال به شبکههای اتریومی و استقرار آنها
-- [Microsoft Learn (زنیرههای بلوکی)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) - ورود به حوزهی توسعهی زنجیرهی بلوکی
-
-### عبری {#he}
-
-- [Udi Wertheimer - چیزهایی که کاربران بیت کوین می توانند از Ethereum یاد بگیرند](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/)
-- [عمر گرایسمان (OpenZeppelin) - چگونه از هک 15 میلیارد دلاری قرارداد هوشمند جلوگیری کردیم](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/)
-- [شای داتیکا (INX) - توکنیزه کردن و آینده وثیقه ها، از جمله این که آیا اتریوم یک وثیقه است](https://www.cryptojungle.co.il/shy-datika-tokenization/)
-- [روی کونفینو (Lemonade) - بیمه در اتریوم](https://www.cryptojungle.co.il/roy-confino-insurance/)
-- [ایدان اُفرات (Fireblocks) - پذیرش موسسهای](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/)
-- [گل وایزمن (MetaMask) - MetaMask چیست؟](https://www.cryptojungle.co.il/gal-weizman-metamask/)
-- [درور اَویلی (Consensys) - مرکز اتریوم](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/)
-- [نیر روزین - کریپتوپانک بودن](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/)
-- [اَدَن کِدِم - بازی & Metaverse](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/)
-- [اوری کولودنی (Starkware) - اتریوم و لایههای بلاکچین](https://www.cryptojungle.co.il/uri-kolodny-starkware/)
-- [اودی وِرتهایمر - اتریوم 2.0 در برابر رقابت](https://www.cryptojungle.co.il/udi-on-eth2/)
-- [بن ساموچا (myself) - اتریوم 2.0 - یک فرصت؟](https://www.cryptojungle.co.il/etherurm2-week-summary/)
-- [الان موراچ (Bloxstaking) - اتریوم 2.0 چیست؟](https://www.cryptojungle.co.il/alon-moroch-eth2/)
-- [ایلوم اَویو (Collider Ventures) - مشکل اتریوم 2.0 چه چیز میتواند باشد؟](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/)
-- [ایلون اَویو (Collider Ventures) - چرا به اتریوم 2.0 نیاز داریم؟](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/)
-
-### ایتالیایی {#it}
-
-- [اتریوم ایتالیا](https://www.ethereum-italia.it/) - آموزش، رویدادها و اخبار اتریوم با تمرکز بر قراردادهای هوشمند و فناوری زنجیرهی بلوکی
-- [پادکست اتریوم ایتالیا](https://www.ethereum-italia.it/podcast/) - پادکست اتریوم به زبان ایتالیایی
-- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) - یاد بگیرید چگونه از Solidity استفاده کنید
-- [Microsoft Learn (قراردادهای هوشمند)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) - با نوشتن قراردادهای هوشمند با استفاده از Solidity آشنا شوید
-- [Microsoft Learn (dappها)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) - یک رابط کاربری با برنامههای غیرمتمرکز بسازید
-
-### ژاپنی {#ja}
-
-- [انجمن تبادل داراییهای مجازی و رمزنگاریشدهی ژاپن](https://jvcea.or.jp/)
-- [انجمن تجارت داراییهای رمزنگاریشدهی ژاپن](https://cryptocurrency-association.org/)
-- [با توسعهی زنجیرهی بلوکی شروع کنید - بیاموزید | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) - این سایت، شما را با مسیر یادگیری زنجیرهی بلوکی و توسعه در پلتفرم اتریوم آشنا میکند
-- [تبحر در اتریوم](https://www.oreilly.co.jp/books/9784873118963/) - یادگیری زیروبم اتریوم به زبان ژاپنی
-- [توسعهی قراردادهای هوشمند بهصورت عملی با Solidity و اتریوم](https://www.oreilly.co.jp/books/9784873119342/) - توسعهی قراردادهای هوشمند عملی با Solidity و اتریوم به زبان ژاپنی
-
-### روسی {#ru}
-
-- [آکادمی سایبر](https://cyberacademy.dev) - فضای آموزشی برای سازندگان وب 3
-- [Forklog](https://forklog.com) - اخبار و مقالات درباره کریپتو به طور کلی، فنآوریهای موجود و ارتقاهای آینده بلاکچینهای متفاوت
-- [BeInCrypto](https://ru.beincrypto.com) - اخبار، تحلیل قیمت کریپتو و مقالات غیرفنآوری با توضیحات ساده درباره همهچیز در کریپتو
-
-### اسپانیایی {#es}
-
-- [اتریوم مادرید](https://ethereummadrid.com/) - دورهها، رویدادها و وبلاگ در مورد زنجیرهی بلوکی، DeFi و حاکمیت
-- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) - راهنمای اتریوم برای مبتدیان به زبان اسپانیایی
-- [Tutoriales online](https://tutoriales.online/curso/solidity) - Solidity و برنامهنویسی در اتریوم را بیاموزید
-- [دورهی معرفی توسعهی اتریوم](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) - اصول Solidity، تست کردن و ساختن اولین قرارداد هوشمند خود
-- [دوره مقدماتی امنیت و هک در اتریوم](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) - آسیبپذیریها و مشکلات امنیتی رایج در قراردادهای هوشمند واقعی را متوجه شوید
-- [مقدمه ای بر دورهی توسعه DeFi](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) - یاد بگیرید که قراردادهای هوشمند دیفای چگونه با Solidity کار میکنند و بازارساز خودکار (Automated Market Maker) خود را بسازید
-- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) - آموزش زنجیرهی بلوکی به زبان غیرفنی از سطح مقدماتی تا سطح پیشرفته. همهچیز را دربارهی رمزارز و اتریوم یاد بگیرید.
-
-### ترکی استانبولی {#tr}
-
-- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) - دورهی آموزشی با تمرکز بر زنجیرهی بلوکی و رمزارزها
-- [تغییر نام عالی: چه اتفاقی برای Eth2 افتاد؟](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) - ترجمهی ترکی پست وبلاگی تغییر نام عالی که فاصله گرفتن از اصطلاح «Eth2» را توضیح میدهد
-
-### ویتنامی {#vi}
-
-- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) - مرور کلی اتریوم، dAppها، کیف پولها و سؤالات متداول
-- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) - پلتفرم وب با زیرصفحاتی در مورد اخبار و آموزش اتریوم
-- [Coin68](https://coin68.com/ethereum-tieu-diem/) - درگاه رمزارزها با اخبار و محتوای آموزشی اتریومی
diff --git a/public/content/translations/fa/14) Community Pages/community/online/index.md b/public/content/translations/fa/14) Community Pages/community/online/index.md
deleted file mode 100644
index 0410fdb710c..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/online/index.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: جوامع آنلاین
-description: فهرستی از برنامههای کمک هزینه از سرتاسر اکوسیستم اتریوم.
-lang: fa
----
-
-# جوامع آنلاین {#online-communities}
-
-صدها هزار نفر از مشتاقان اتریوم در این انجمنهای آنلاین گرد هم میآیند تا خبرها را به اشتراک بگذارند، درباره پیشرفتهای اخیر صحبت کنند، درباره مسائل فنی بحث کنند و آینده را تصور کنند.
-
-## انجمنها {#forums}
-
-r/ethereum - همهچیز اتریوم
-r/ethfinance - جنبهی مالی اتریوم، از جمله دیفای
-r/ethdev - متمرکز بر توسعهی اتریوم
-r/ethtrader - روندها و تحلیل بازار
-r/ethstaker - خوشآمدگویی به همهی علاقهمندان به سهامگذاری در اتریوم
-Fellowship of Ethereum Magicians - جامعهای با محوریت استانداردهای فنی در اتریوم
-Ethereum Stackexchange - بحث و کمک برای توسعهدهندگان اتریوم
-Ethereum Research - تأثیرگذارترین تالار گفتگ برای تحقیقات اقتصادی رمزارزها
-
-## اتاقهای گفتگو {#chat-rooms}
-
-Cat Herderهای اتریوم - جامعهای با محوریت ارائهی کمک در بحث مدیریت پروژه برای توسعهی اتریوم
-هکرهای اتریوم - فضای گفتگوی Discord تحت مدیریت ETHGlobal: یک انجمن آنلاین برای هکرهای اتریوم در سراسر جهان
-CryptoDevs - انجمن Discord متمرکز بر توسعهی اتریوم
-دیسکورد EthStaker - راهنمایی، آموزش، حمایت و مجموعه منابعی برای سهام گذاران کنونی و آینده که از سوی اعضای جامعه Ethstaker تهیه شده و اداره میشود
-تیم وب سایت Ethereum.org - با تیم و افراد جامعه توسعه و طراحی وب ethereum.org گفتگو کنید
-دیسکورد Matos - جامعه خالقان web3 که در آن سازندگان، چهرههای مطرح صنعت و علاقهمندان به اتریوم دور هم جمع میشوند. ما مشتاق توسعه، طراحی و فرهنگ Web3 هستیم. بیایید در ساختن، همراه ما شوید.
-Solidity Gitter - فضای گفتگو برای توسعه solidity (Gitter)
-Solidity Matrix - فضای گفتگو برای توسعه solidity (Matrix)
-بورس سهام اتریوم *- انجمن پرسش و پاسخ*
-Peeranha *- انجمن پرسش و پاسخ غیرمتمرکز*
-
-## یوتیوب و توییتر {#youtube-and-twitter}
-
-بنیاد اتریوم - از تازهترین اخبار «بنیاد اتریوم» مطلع شوید
-@ethereum - حساب رسمی بنیاد اتریوم
-@ethdotorg - پایگاه اینترنتی اتریوم، ساختهشده برای جامعهی جهانی در حال رشد ما
-فهرست حسابهای تأثیرگذار اتریوم در توییتر
-
-
-
-
-
-
- درباره DAOها بیشتر بدانید
-
-
-
diff --git a/public/content/translations/fa/14) Community Pages/community/research/index.md b/public/content/translations/fa/14) Community Pages/community/research/index.md
deleted file mode 100644
index a57086aa479..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/research/index.md
+++ /dev/null
@@ -1,399 +0,0 @@
----
-title: حوزههای تحقیقات در حال انجام در اتریوم
-description: حوزههای مختلف تحقیق باز را کاوش کنید و یاد بگیرید که چگونه مشارکت کنید.
-lang: fa
----
-
-# حوزه های فعال تحقیقات اتریوم {#active-areas-of-ethereum-research}
-
-یکی از نقاط قوت اولیه اتریوم این است که یک جامعه تحقیق و مهندسی فعال به طور مداوم آن را بهبود می بخشد. بسیاری از افراد ماهر و مشتاق در سرتاسر جهان مشتاقند که در زمینه مسائل مهم اتریوم مشغول به کار شوند اما فهمیدن آن که کدام مسائل در درجه اول اهمیت قرار دارند همیشه آسان نیست. این صفحه، به عنوان یک راهنمایی کلی درباره آخرین پیشرفتهای اتریوم، به حوزههای تحقیقاتی مهم و کلیدی اشاره میکند.
-
-## تحقیقات اتریوم چطور کار میکند {#how-ethereum-research-works}
-
-تحقیقات اتریوم باز و شفاف است و اصول [علم غیرمتمرکز (DeSci)] (https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science) را در بر می گیرد. یکی از اصول اتریوم این است که ابزارها و خروجیهای تحقیق تا حد امکان در دسترس و تعاملی باشند، مثلاً از طریق دفترچههای قابل اجرا. تحقیقات اتریوم بهسرعت پیش میرود و یافتههای جدید در انجمنهایی مانند [ethresear.ch](https://ethresear.ch/) پست شده و مورد بحث قرار میگیرد، نه اینکه پس از دورهای بررسی همتایان از طریق انتشارات سنتی به جامعه برسد.
-
-## منابع تحقیقات عمومی {#general-research-resources}
-
-صرف نظر از موضوع خاص، اطلاعات زیادی در مورد تحقیقات اتریوم در [ethresear.ch](https://ethresear.ch) و [کانال Eth R&D Discord](https://discord.gg/qGpsxSA) وجود دارد. این دو اصلیترین منابعی هستند که محققان اتریوم درباره آخرین ایدهها و فرصتهای توسعه در آنجا بحث و تبادل نظر میکنند.
-
-این گزارش که در ماه می 2022 توسط [DelphiDigital] (https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) منتشر شده است، نمای کلی خوبی از نقشه راه اتریوم ارائه می دهد.
-
-## منابع تامین هزینه {#sources-of-funding}
-
-شما میتوانید برای شرکت در پروژههای تحقیقاتی اتریوم دستمزد بگیرید! به عنوان مثال، [بنیاد اتریوم](/foundation/) اخیراً یک [دور کمک های مالی دانشگاهی] (https://esp.ethereum.foundation/academic-grants) را اجرا کرد. میتوانید اطلاعات مربوط به فرصتهای مالی فعال و آینده را در [صفحه کمکهای مالی اتریوم] (/community/grants/) بیابید.
-
-## تحقیقات پروتکل {#protocol-research}
-
-تحقیقات پروتکل به لایه پایه اتریوم برمیگردد - این لایه مجموعهای از قوانینیست که نحوه اتصال، ارتباط، تبادل و ذخیره دادههای اتریوم توسط گرهها را تعریف میکنند و در مورد وضعیت بلاکچین به اجماع میرسند. تحقیقات پروتکل به دو دسته تقسیم میشود: اجماع و اجرا.
-
-### اجماع {#consensus}
-
-تحقیقات اجماع مربوط به [مکانیزم اثبات سهام اتریوم] (/developers/docs/consensus-mechanisms/pos/) است. چند نمونه از موضوعات تحقیق اجماع عبارتند از:
-
-- شناسایی و اصلاح آسیبپذیریها؛
-- کمی کردن امنیت اقتصاد رمزنگاری؛
-- افزایش امنیت یا عملکرد اجراهای کاربر؛
-- و توسعه کاربرهای سبک.
-
-علاوه بر تحقیقات آیندهنگر، برای بهبود عمده اتریوم، در حال حاضر تحقیق روی برخی از طراحیهای مجدد و مهم پروتکل، مانند نهایی شدن تک اسلات، نیز در جریان است. علاوه بر این، کارایی، ایمنی و نظارت بر شبکههای همتا به همتا بین کاربرهای اجماع نیز از موضوعات مهم تحقیقاتی است.
-
-#### مطالعه پیشزمینه {#background-reading}
-
-- [مقدمه ای بر اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
-- [مقاله Casper-FFG](https://arxiv.org/abs/1710.09437)
-- [شرح Casper-FFG](https://arxiv.org/abs/1710.09437)
-- [مقاله Gasper](https://arxiv.org/abs/2003.03052)
-
-#### تحقیقات اخیر {#recent-research}
-
-- [اجماع Ethresear.ch](https://ethresear.ch/c/consensus/29)
-- [دوراهی دسترسیپذیری/نهاییپذیری](https://arxiv.org/abs/2009.04987)
-- [نهاییسازی تک اسلات](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259)
-- [تفکیک پیشنهاددهنده-سازنده](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
-
-### اجرا {#execution}
-
-لایه اجرا مربوط به اجرای تراکنشها، اجرای [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) و تولید بارهای اجرایی برای انتقال به لایه اجماع است. در این حوزه موضوعات فعالی برای تحقیق وجود دارد، از جمله:
-
-- پشتیبانی کاربر سبک؛
-- تحقیق در مورد حدود گس؛
-- و گنجاندن ساختارهای داده جدید (به عنوان مثال Verkle Tries).
-
-#### مطالعه پیشزمینه {#background-reading-1}
-
-- [مقدمه ای بر ماشین مجازی اتریوم](/developers/docs/evm)
-- [لایه اجرای Ethresear.ch](https://ethresear.ch/c/execution-layer-research/37)
-
-#### تحقیقات اخیر {#recent-research-1}
-
-- [بهینه سازی های پایگاه داده](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md)
-- [انقضای حالت] (https://notes.ethereum.org/@vbuterin/state_expiry_eip)
-- [راه های انقضای حالت](https://hackmd.io/@vbuterin/state_expiry_paths)
-- [پیشنهاد انقضای Verkle و حالت](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal)
-- [مدیریت سابقه] (https://eips.ethereum.org/EIPS/eip-4444)
-- [درختان Verkle](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
-- [نمونهسازی در دسترس بودن داده](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)
-
-## توسعه کاربر {#client-development}
-
-کاربرهای اتریوم در واقع اجراهای پروتکل اتریوم هستند. توسعه کاربر نتایج تحقیقات پروتکل را با ساختن آنها در این کاربرها به واقعیت تبدیل میکند. توسعه کاربر شامل به روز رسانی ویژگیهای کاربر و نیز ایجاد اجراهای ویژه است.
-
-برای اجرای دو بخش از نرمافزار به یک گره اتریوم نیاز است:
-
-1. کاربر اجماع برای ردیابی راس بلاکچین، بلوکهای بیمورد و مدیریت منطق اجماع
-2. یک کاربر اجرا برای پشتیبانی ماشین مجازی اتریوم و اجرای تراکنشها و قراردادهای هوشمند
-
-برای جزئیات بیشتر در مورد گرهها و کاربرها و فهرستی از تمام اجراهای کاربر فعلی، به [صفحه گرهها و کاربرها](/developers/docs/nodes-and-clients/) مراجعه کنید. همچنین میتوانید تاریخچه تمام ارتقاهای اتریوم را در [صفحه تاریخچه] (/history/) بیابید.
-
-### کاربرهای اجرا {#execution-clients}
-
-- [مشخصات کاربر اجرا](https://github.com/ethereum/execution-specs)
-- [مشخصات API اجرا](https://github.com/ethereum/execution-apis)
-
-### کاربرهای اجماع {#consensus-clients}
-
-- [مشخصات کاربر اجماع](https://github.com/ethereum/consensus-specs)
-- [مشخصات API بیکن](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot)
-
-## مقیاسپذیری و عملکرد {#scaling-and-performance}
-
-مقیاسپذیری اتریوم برای محققان اتریوم جای پژوهش زیادی دارد. رویکردهای فعلی شامل بارگذاری تراکنشها روی رول-آپها و ارزانتر کردن آنها با استفاده از تودههای داده متمرکز است. اطلاعات مقدماتی در مورد مقیاسپذیری اتریوم در [صفحه مقیاسپذیری] ما در دسترس است (/developers/docs/scaling).
-
-### لایه 2 {#layer-2}
-
-در حال حاضر چندین پروتکل لایه 2 وجود دارد که با استفاده از تکنیکهای مختلف برای دستهبندی تراکنشها و ایمن کردن آنها در لایه 1، اتریوم را مقیاسبندی میکنند. این بخش به سرعت در حال رشد است و پتانسیل تحقیق و توسعه زیادی دارد.
-
-#### مطالعه پیشزمینه {#background-reading-2}
-
-- [معرفی لایه 2](/layer-2/)
-- [Polynya: رولآپها، DA و زنجیرههای مدولار](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d)
-
-#### تحقیقات اخیر {#recent-research-2}
-
-- [ترتیب منصفانه آربیتروم برای ترتیب دهنده ها](https://eprint.iacr.org/2021/1465)
-- [لایه 2 ethresear.ch](https://ethresear.ch/c/layer-2/32)
-- [نقشه راه رول آپ محور](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)
-- [L2Beat](https://l2beat.com/)
-
-### پل ها {#bridges}
-
-یکی از حوزههای لایه 2 که نیاز به تحقیق و توسعه بیشتر دارد، پلهای ایمن و کارآمدند. این شامل پلهایی بین لایههای 2 مختلف و پلهای بین لایه 1 و لایه 2 است. این حوزه تحقیقاتی بسیار مهمی است زیرا پلها از اهداف مورد علاقه هکرها هستند.
-
-#### مطالعه پیشزمینه {#background-reading-3}
-
-- [مقدمه ای بر پل های بلاکچین](/bridges/)
-- [مقاله ویتالیک درباره پل ها](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/)
-- [مقاله پلهای بلاکچین](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8)
-- [ارزش محبوس در پلها](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\))
-
-#### تحقیقات اخیر {#recent-research-3}
-
-- [پلهای اعتبارسنجی](https://stonecoldpat.github.io/images/validatingbridges.pdf)
-
-### زنجیرهایسازی {#sharding}
-
-زنجیرهای سازی بلاکچین اتریوم مدتهاست که بخشی از نقشه راه توسعه بوده است. با این حال، راهحلهای مقیاسبندی جدید مانند دنکشاردینگ در حال حاضر در مرکز توجهاند.
-
-پیشرو برای دنک شاردینگ کامل که با عنوان پروتو-دنک شاردینگ شناخته میشود، با ارتقاء شبکه Cancun-Deneb ("Dencun") فعال شد.
-
-[اطلاعات بیشتر در مورد ارتقاء Dencun](/roadmap/dencun/)
-
-#### مطالعه پیشزمینه {#background-reading-4}
-
-- [یادداشتهای پروتو-دنکشاردینگ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq)
-- [ویدیوی دنکشاردینگ بدون بانک](https://www.youtube.com/watch?v=N5p0TB77flM)
-- [خلاصه تحقیق زنجیرهایسازی اتریوم](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view)
-- [دنکشاردینگ (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe)
-
-#### تحقیقات اخیر {#recent-research-4}
-
-- [EIP-4844: پروتو-دنکشاردینگ](https://eips.ethereum.org/EIPS/eip-4844)
-- [نظر ویتالیک درباره زنجیرهایسازی و نمونهسازی دسترسی داده](https://hackmd.io/@vbuterin/sharding_proposal)
-
-### سخت افزار {#hardware}
-
-[گرههای در حال اجرا](/developers/docs/nodes-and-clients/run-a-node/) روی سختافزار متوسط، برای غیرمتمرکز نگه داشتن اتریوم ضروری است. بنابراین، بررسی راههای به حداقل رساندن نیازهای سختافزاری برای اجرای گرهها یکی از حوزههای مهم تحقیقات است.
-
-#### مطالعه پیشزمینه {#background-reading-5}
-
-- [اتریوم در ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/)
-
-#### تحقیقات اخیر {#recent-research-5}
-
-- [ecdsa در FPGAها](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738)
-
-## امنیت {#security}
-
-امنیت شبکه، حوزه گستردهای است که جلوگیری از هرزنامه/کلاهبرداری، امنیت کیف پول، امنیت سختافزار، امنیت ارز دیجیتال، پیدا کردن باگها و آزمایش اپلیکیشنها و نرمافزار کاربر و مدیریت کلید را در بر میگیرد. انباشت اطلاعات در این زمینه به افزایش پذیرش در جریان اصلی کمک میکند.
-
-### رمزنگاری و ZKP {#cryptography--zkp}
-
-اثباتهای دانش صفر (ZKP) و رمزنگاری، برای حفظ حریم خصوصی و امنیت در اتریوم و اپلیکیشنهای آن حیاتیاند. دانش صفر، فضایی نسبتا جدید اما به سرعت در حال پیشرفت است و در خود فرصتهای زیادی برای توسعه و تحقیق دارد. برخی از احتمالات عبارتند از توسعه پیادهسازیهای کارآمدتر [الگوریتم هشسازی Keccak] (https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview)، یافتن تعهدات چند جمله ای بهتر از آنچه در حال حاضر وجود دارد یا کاهش هزینه تولید کلید عمومی ecdsa و مدارهای تأیید امضا.
-
-#### مطالعه پیشزمینه {#background-reading-6}
-
-- [0xparc blog](https://0xparc.org/blog)
-- [zkp.science](https://zkp.science/)
-- [پادکست دانش صفر](https://zeroknowledge.fm/)
-
-#### تحقیقات اخیر {#recent-research-6}
-
-- [پیشرفت اخیر در رمزنگاری منحنی بیضی](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346)
-- [Ethresear.ch ZK](https://ethresear.ch/c/zk-s-nt-arks/13)
-
-### کیف پول ها {#wallets}
-
-کیف پولهای اتریوم به شکل افزونههای مرورگر، اپلیکیشنهای دسکتاپ و موبایل یا قراردادهای هوشمند روی اتریوم در دسترساند. کیف پولهای بازیابی اجتماعی همچنان موضوع مهمی برای بررسی و پژوهشاند که برخی از خطرات مربوط به مدیریت کلید کاربر را کاهش میدهند. همراه با توسعه کیفهای پول، اشکال جایگزین انتزاع حساب هم حوزه تحقیقات مهم اما نوپایی است.
-
-#### مطالعه پیشزمینه {#background-reading-7}
-
-- [معرفی کیف های پول](/wallets/)
-- [مقدمه ای بر امنیت کیف پول](/security/)
-- [ethresear.ch امنیت](https://ethresear.ch/tag/security)
-- [EIP-2938 انتزاع حساب](https://eips.ethereum.org/EIPS/eip-2938)
-- [EIP-4337 انتزاع حساب](https://eips.ethereum.org/EIPS/eip-4337)
-
-#### تحقیقات اخیر {#recent-research-7}
-
-- [کیفپولهای قرارداد هوشمند متمرکز بر اعتبارسنجی](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603)
-- [آینده حساب ها](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603)
-- [کدگذاری های EIP-3074 AUTH و AUTHCALL](https://eips.ethereum.org/EIPS/eip-3074)
-- [انتشار کد در یک آدرس EOA] (https://eips.ethereum.org/EIPS/eip-5003)
-
-## جامعه، آموزش و پشتیبانی {#community-education-and-outreach}
-
-اتریوم برای جذب کاربران جدید به منابع آموزشی و رویکردهای جدید برای پشتیبانی نیازمند است. این ممکن است شامل پستها و مقالات وبلاگ، کتابها، پادکستها، میمها، منابع آموزشی، رویدادها و هر چیز دیگری باشد که باعث ایجاد انجمنها، استقبال از شروعکنندگان جدید و آموزش مردم در مورد اتریوم میشود.
-
-### UX/UI {#uxui}
-
-همچنین برای جذب کاربران بیشتر به اتریوم، اکوسیستم باید UX/UI را بهبود بخشد. این امر مستلزم آن است که طراحان و کارشناسان محصول، طرح کیف پولها و اپلیکیشنها را دوباره بررسی کنند.
-
-#### مطالعه پیشزمینه {#background-reading-8}
-
-- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24)
-
-#### تحقیقات اخیر {#recent-research-8}
-
-- [دیسکورد طرح Web3](https://discord.gg/FsCFPMTSm9)
-- [اصول طراحی Web3] (https://www.web3designprinciples.com/)
-- [بحث UX جادوگران اتریوم](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3)
-
-### اقتصاد {#economics}
-
-تحقیقات اقتصادی در اتریوم دو رویکرد مشخص دارند: اعتبارسنجی امنیت مکانیسمهای متکی بر انگیزههای اقتصادی (اقتصاد خرد) و تجزیه و تحلیل جریانهای ارزش بین پروتکلها، اپلیکیشنها و کاربران (اقتصاد کلان). فاکتورهای پیچیده اقتصاد کریپتو در رابطه با توکن اتریوم (اتر) و توکنهای ساخته شده روی آن (به عنوان مثال NFTها و توکنهای ERC20) وجود دارد.
-
-#### مطالعه پیشزمینه {#background-reading-9}
-
-- [گروه مشوق های بزرگ](https://ethereum.github.io/rig/)
-- [کارگاه ETHconomics در Devconnect](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm)
-
-#### تحقیقات اخیر {#recent-research-9}
-
-- [تحلیل تجربی EIP1559](https://arxiv.org/abs/2201.05574)
-- [تعادل عرضه در حال گردش](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954)
-- [کمی سازی MEV: جنگل چقدر تاریک است؟](https://arxiv.org/abs/2101.05511)
-
-### فضای بلوک و بازارهای کارمزد {#blockspace-fee-markets}
-
-بازارهای بلاکاسپیس، شمول تراکنشهای کاربر نهایی، چه به طور مستقیم در اتریوم (لایه 1) یا در پلها، به عنوان مثال، رول-آپها (لایه 2) را کنترل میکنند. تراکنشها در اتریوم به بازار کارمزد فرستاده میشوند که درون پروتکل بهعنوان EIP-1559 اجرا شده و از شبکه در برابر اسپمها و تراکم قیمتگذاری محافظت میکند. در هر دو لایه، تراکنشها ممکن است تأثیرات بیرونی داشته باشند که به عنوان حداکثر ارزش استخراج (MEV) شناخته میشود، که باعث خواهد شد ساختارهای بازار جدید این تاثیرات را بگیرند یا مدیریت کنند.
-
-#### مطالعه پیشزمینه {#background-reading-10}
-
-- [طراحی مکانیزم کارمزد تراکنش برای بلاک چین اتریوم: تحلیل اقتصادی EIP-1559 (تیم رافگاردن، 2020)](https://timroughgarden.org/papers/eip1559.pdf)
-- [شبیهسازی EIP-1559 (گروه مشوقهای قوی)] (https://ethereum.github.io/abm1559)
-- [اقتصاد رولآپ از اصول اولیه](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url)
-- [Flash Boys 2.0: پیشروی، ترتیب دوباره تراکنش، و ناپایداری اجماع در صرافیهای غیرمتمرکز](https://arxiv.org/abs/1904.05234)
-
-#### تحقیقات اخیر {#recent-research-10}
-
-- [ارائه ویدئویی چند بعدی EIP-1559](https://youtu.be/QbR4MTgnCko)
-- [MEV چند دامنهای](http://arxiv.org/abs/2112.01472)
-- [حراجهای MEV](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788)
-
-### مشوقهای اثبات سهام {#proof-of-stake-incentives}
-
-اعتبارسنجها، از دارایی بومی اتریوم (اتر) برای جلوگیری از رفتارهای غیرصادقانه به عنوان وثیقه استفاده میکنند. اقتصاد کریپتویی آن، امنیت شبکه را تضمین میکند. اعتبارسنجهای پیشرفته، میتوانند با سوءاستفاده از تفاوتهای جزئی لایه پاداش، حملات صریحی برای شبکه تدارک ببینند.
-
-#### مطالعه پیشزمینه {#background-reading-11}
-
-- [مستر کلاس اقتصاد اتریوم و مدل اقتصادی](https://github.com/CADLabs/ethereum-economic-model)
-- [شبیهسازیهای مشوقهای PoS (گروه مشوقهای قوی)] (https://ethereum.github.io/beaconrunner/)
-
-#### تحقیقات اخیر {#recent-research-11}
-
-- [افزایش مقاومت سانسوری تراکنشها تحت جداسازی پیشنهاددهنده/سازنده (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ)
-- [سه حمله به اثبات سهام اتریوم](https://arxiv.org/abs/2110.10086)
-
-### سهامگذاری نقد و مشتقات {#liquid-staking-and-derivatives}
-
-کاربرانی که کمتر از 32 اتر دارند با سهام گذاری نقدینه میتوانند با معاوضه توکنی که اتر سهام گذاری شده را نمایندگی میکند سود دریافت کنند. با این حال، انگیزهها و پویاییهای بازار مرتبط با سهام گذاری نقدینه و همچنین تأثیر آن بر امنیت اتریوم (مانند خطرات متمرکز شدن) هنوز باید بررسی شود.
-
-#### Background reading {#background-reading-12}
-
-- [Ethresear.ch liquid staking](https://ethresear.ch/search?q=liquid%20staking)
-- [Lido: The road to trustless Ethereum staking](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/)
-- [Rocket Pool: Staking protocol introduction](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd)
-
-#### Recent research {#recent-research-12}
-
-- [Handling withdrawals from Lido](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873)
-- [Withdrawal credentials](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722)
-- [The risks of Liquid Staking Derivatives](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
-
-## Testing {#testing}
-
-### Formal verification {#formal-verification}
-
-راستیآزمایی رسمی، نوشتن کدی برای تأیید صحت و بدون اشکال بودن مشخصات اجماع اتریوم است. یک نسخه قابل اجرا از مشخصات نوشته شده در Python وجود دارد که نیاز به نگهداری و توسعه دارد. تحقیقات بیشتر میتواند به بهبود پیادهسازی مشخصات Python کمک کند و ابزارهایی را اضافه کند که سلامت شبکه را قویاً تأیید و مشکلات آن را شناسایی کنند.
-
-#### Background reading {#background-reading-13}
-
-- [Introduction to formal verification](https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html)
-- [Formal Verification (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf)
-
-#### Recent research {#recent-research-13}
-
-- [Formal verification of the deposit contract](https://github.com/runtimeverification/deposit-contract-verification)
-- [Formal verification of the Beacon Chain specification](https://github.com/runtimeverification/deposit-contract-verification)
-
-## Data science and analytics {#data-science-and-analytics}
-
-برای آگاهی از فعالیت در اتریوم و سلامت شبکه نیاز به ابزارهای تجزیه و تحلیل داده ها و داشبوردهای بیشتری وجود دارد.
-
-### Background reading {#background-reading-14}
-
-- [Dune Analytics](https://dune.com/browse/dashboards)
-- [Client diversity dashboard](https://clientdiversity.org/)
-
-#### Recent research {#recent-research-14}
-
-- [Robust Incentives Group Data Analysis](https://ethereum.github.io/rig/)
-
-## Apps and tooling {#apps-and-tooling}
-
-لایه اپلیکیشن از اکوسیستم متنوعی از برنامهها پشتیبانی میکند که تراکنشها را در لایه پایه اتریوم مستقر میکنند. تیم توسعه، با ایجاد نسخههای قابل ترکیب، بینیاز از مجوز و مقاوم در برابر سانسور از برنامههای مهم Web2 یا ایجاد مفاهیم کاملاً جدید بومی Web3، بهصورت پیوسته در حال یافتن راههای جدیدی برای استفاده از اتریوم است. در همین زمان، ابزار جدیدی در حال توسعه است که باعث میشود ساخت اپلیکیشنهای غیرمتمرکز در اتریوم سادهتر شود.
-
-### DeFi {#defi}
-
-امور مالی غیرمتمرکز (DeFi) یکی از کلاسهای اصلی اپلیکیشنهای ساخته شده بر روی اتریوم است. هدف DeFi ایجاد «لگوهای پول» قابل ترکیب است که با آن کاربران میتوانند با استفاده از قراردادهای هوشمند داراییهای رمزارزی را ذخیره کنند، انتقال دهند، وام بگیرند و روی رمزارزها سرمایهگذاری کنند. دیفای با سرعت بالایی در حال پیشرفت و بهروزرسانی است. تحقیق در مورد پروتکلهای ایمن، کارآمد و قابل دسترس، به صورت مستمر ضروری است.
-
-#### Background reading {#background-reading-15}
-
-- [DeFi](/defi/)
-- [Coinbase: What is DeFi?](https://www.coinbase.com/learn/crypto-basics/what-is-defi)
-
-#### Recent research {#recent-research-15}
-
-- [Decentralized finance, centralized ownership?](https://arxiv.org/pdf/2012.09306.pdf)
-- [Optimism: The road to sub-dollar transactions](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92)
-
-### DAOs {#daos}
-
-سازماندهی غیرمتمرکز با DAO ها یکی از موارد قابل توجه از اتریوم است. در مورد اینکه چطور میتوان برای اجرای فرمهای بهتر حکمرانی، بهعنوان یک ابزار هماهنگی با حداقل اعتماد، DAOها را در اتریوم توسعه داد، تحقیقات زیادی در حال انجام است.
-
-#### Background reading {#background-reading-16}
-
-- [Introduction to DAOs](/dao/)
-- [Dao Collective](https://daocollective.xyz/)
-
-#### Recent research {#recent-research-16}
-
-- [Mapping the DAO ecosystem](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy)
-
-### Developer tools {#developer-tools}
-
-ابزارهای توسعهدهندگان اتریوم به سرعت در حال بهبودند. تحقیقات و توسعههای زیادی در این زمینه عمومی در حال انجام است.
-
-#### Background reading {#background-reading-17}
-
-- [Tooling by programming language](/developers/docs/programming-languages/)
-- [Developer Frameworks](/developers/docs/frameworks/)
-- [Consensus developer tools list](https://github.com/ConsenSys/ethereum-developer-tools-list)
-- [Token standards](/developers/docs/standards/tokens/)
-- [CryptoDevHub: EVM Tools](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools)
-
-#### Recent research {#recent-research-17}
-
-- [Eth R&D Discord Consensus Tooling channel](https://discordapp.com/channels/595666850260713488/746343380900118528)
-
-### Oracles {#oracles}
-
-اوراکلها دادههای بیرون از زنجیره را به روشی بینیاز از مجوز و غیرمتمرکز وارد بلاکچین میکنند. با دریافت این دادهها در زنجیره، اپلیکیشنهای غیرمتمرکز میتوانند نسبت به پدیدههای دنیای واقعی مانند نوسانات قیمت در داراییهای دنیای واقعی، رویدادهای اپلیکیشنهای خارج از زنجیره یا حتی تغییرات آبوهوا واکنش نشان دهند.
-
-#### Background reading {#background-reading-18}
-
-- [Introduction to Oracles](/developers/docs/oracles/)
-
-#### Recent Research {#recent-research-18}
-
-- [Survey of blockchain oracles](https://arxiv.org/pdf/2004.07140.pdf)
-- [Chainlink white paper](https://chain.link/whitepaper)
-
-### App security {#app-security}
-
-هکرهای اتریوم معمولاً به جای خود پروتکل از آسیبپذیریهای اپلیکیشنها سوء استفاده میکنند. هکرها و توسعهدهندگان اپلیکیشنها، در رقابت تسلحیاتی برای توسعه حملات و دفاعهای جدید قفل شدهاند. بنابراین، برای ایمن نگهداشتن اپلیکیشنها و جلوگیری از هک شدن آنها تحقیقات در این زمینه اهمیت بالایی دارد.
-
-#### Background reading {#background-reading-19}
-
-- [Wormhole exploit report](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/)
-- [List of Ethereum contract hack post-mortems](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191)
-- [Rekt News](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg)
-
-#### Recent research {#recent-research-19}
-
-- [ethresear.ch Applications](https://ethresear.ch/c/applications/18)
-
-### Technology stack {#technology-stack}
-
-تمرکززدایی از پشته فناوری در اتریوم یک حوزه تحقیقاتی مهم است. در حال حاضر، dappهایی که روی اتریوم ساخته شدهاند معمولا به واسطه اتکا به ابزارها یا زیرساختهای متمرکز بهطور کامل غیرمتمرکز نیستند.
-
-#### Background reading {#background-reading-20}
-
-- [Ethereum stack](/developers/docs/ethereum-stack/)
-- [Coinbase: Intro to Web3 Stack](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0)
-- [Introduction to smart contracts](/developers/docs/smart-contracts/)
-- [Introduction to decentralized storage](/developers/docs/storage/)
-
-#### Recent research {#recent-research-20}
-
-- [Smart contract composability](/developers/docs/smart-contracts/composability/)
diff --git a/public/content/translations/fa/14) Community Pages/community/support/index.md b/public/content/translations/fa/14) Community Pages/community/support/index.md
deleted file mode 100644
index b7ab4916c40..00000000000
--- a/public/content/translations/fa/14) Community Pages/community/support/index.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-title: پشتیبانی اتریوم
-description: در اکوسیستم اتریوم پشتیبانی دریافت کنید.
-lang: fa
----
-
-# پشتیبانی اتریوم {#support}
-
-## پشتیبانی رسمی اتریوم {#official-support}
-
-آیا به دنبال پشتیبانی رسمی اتریوم هستید؟ اولین چیزی که باید بدانید این است که اتریوم غیرمتمرکز است. این بدان معناست که هیچ سازمان مرکزی، نهاد یا شخصی مالک اتریوم نیست و به همین دلیل، هیچ کانال پشتیبانی رسمی وجود ندارد.
-
-درک ماهیت غیرمتمرکز اتریوم بسیار مهم است زیرا هرکسی که ادعا میکند پشتیبان رسمی اتریوم است، احتمالاً سعی دارد از شما کلاهبرداری کند! بهترین محافظت در برابر کلاهبرداران، آموزش خود و جدی گرفتن امنیت است.
-
-
- امنیت اتریوم و جلوگیری از کلاهبرداری
-
-
-
- اصول اتریوم را بیاموزید
-
-
-علیرغم عدم پشتیبانی رسمی، بسیاری از گروهها، جوامع و پروژهها در سراسر اکوسیستم اتریوم با کمال میل به شما کمک میکنند و شما میتوانید اطلاعات و منابع مفید زیادی را در این صفحه بیابید. هنوز سؤالی دارید؟ به [دیسکورد ethereum.org](/discord/) بپیوندید، و ما سعی میکنیم کمکتان کنیم.
-
-## پرسشهای متداول {#faq}
-
-### من به کیف پول اشتباهی اتر فرستادهام {#wrong-wallet}
-
-تراکنش ارسالشده روی اتریوم برگشتناپذیر است. متأسفانه اگر به کیف پول اشتباهی اتر ارسال کرده باشید، هیچ راهی برای برگرداندن آن وجود ندارد. هیچ سازمان مرکزی، نهاد یا شخصی مالک اتریوم نیست، به این معنی که هیچکس نمیتواند تراکنشها را برگشت دهد. بنابراین، همیشه ضروری است که تراکنشهای خود را قبل از ارسال دوباره بررسی کنید.
-
-### چگونه میتوانم هدایای اتریوم خودم را مطالبه کنم؟ {#giveaway-scam}
-
-هدایای اتریوم کلاهبرداریهایی است که برای سرقت اتریوم شما طراحی شدهاند. در معرض وسوسهی پیشنهادهایی که به نظر خیلی خوب و واقعی به نظر میرسند قرار نگیرید - اگر اتوریومی را به یک آدرس هدیهدهنده ارسال کنید، هدیهای دریافت نخواهید کرد و نمیتوانید وجوه خود را بازیابی کنید.
-
-[اطلاعات بیشتر در مورد پیشگیری از کلاهبرداری](/security/#common-scams)
-
-### تراکنش من گیر کرده است {#stuck-transaction}
-
-اگر به دلیل تقاضای شبکه کارمزد تراکنش کمتری را نسبت به آنچه که لازم است ارسال کرده باشید، تراکنشهای اتریوم گاهی ممکن است گیر کنند. بسیاری از کیف پولها گزینهای برای ارسال مجدد همان تراکنش با کارمزد تراکنش بالاتر را ارائه میدهند تا امکان پردازش تراکنش فراهم شود. از طرف دیگر، میتوانید با ارسال یک تراکنش به آدرس خودتان و استفاده از nonce همان تراکنش معلق، یک تراکنش معلق را لغو کنید.
-
-[نحوهی سرعت بخشیدن یا لغو تراکنش معلق در MetaMask](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction)
-
-[چگونه تراکنشهای معلق اتریوم را لغو کنیم؟](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/)
-
-### چگونه میتوانم اتریوم استخراج کنم؟ {#mining-ethereum}
-
-استخراج اتریوم دیگر امکانپذیر نیست. وقتی اتریوم از [اثبات کار](/glossary/#pow) به [اثبات سهام](/glossary/#pos) منتقل شد، استخراج خاموش شد. اکنون به جای ماینر، اتریوم اعتبارسنج دارد. هر کس میتواند برای اجرای نرمافزار اعتبارسنج برای ایمن کردن شبکه، اتر را [سهامگذاری](/glossary/#staking) کرده و پاداشهای سهامگذاری را دریافت کند.
-
-### چطور یک سهامگذار شوم / یک اعتبارسنج اجرا کنم؟ {#how-to-stake}
-
-برای تبدیل شدن به یک اعتبارسنج، باید 32 اتر در قرارداد سپردهگذاری کنید و یک گرهی اعتبارسنج راهاندازی کنید. اطلاعات بیشتر در [صفحات سهامگذاری](/staking) و در [سکوی پرتاب سهامگذاری](https://launchpad.ethereum.org/) ما در دسترس است.
-
-## ساخت برنامههای غیرمتمرکز (dappها) {#building-support}
-
-ساختن میتواند سخت باشد. در اینجا برخی از فضاهای متمرکز توسعه با توسعهدهندگان باتجربهای وجود دارند که خوشحال میشوند به شما کمکی کنند.
-
-- [دانشگاه شیمی](https://university.alchemy.com/#starter_code)
-- [دیسکورد CryptoDevs](https://discord.com/invite/5W5tVb3)
-- [StackExchange اتریوم](https://ethereum.stackexchange.com/)
-- [StackOverflow](https://stackoverflow.com/questions/tagged/web3)
-- [دانشگاه Web3](https://www.web3.university/)
-- [LearnWeb3](https://discord.com/invite/learnweb3)
-
-همچنین میتوانید مستندات و راهنمای توسعه را در بخش [منابع توسعهدهندگان اتریوم](/developers/) ما بیابید.
-
-### ابزارسازی {#dapp-tooling}
-
-آیا سؤال شما به ابزار، پروژه یا کتابخانه خاصی مربوط میشود؟ بیشتر پروژهها دارای سرورهای چت یا انجمنهایی هستند که برای پشتیبانی از شما اختصاص دادهشدهاند.
-
-در اینجا برخی از نمونههای محبوب آورده شده است:
-
-- [Solidity](https://gitter.im/ethereum/solidity)
-- [ethers.js](https://discord.gg/6jyGVDK6Jx)
-- [web3.js](https://discord.gg/GsABYQu4sC)
-- [Hardhat](https://discord.gg/xtrMGhmbfZ)
-- [Alchemy](http://alchemy.com/discord)
-- [Tenderly](https://discord.gg/fBvDJYR)
-
-## راهاندازی یک گره {#node-support}
-
-اگر از یک گره یا یک اعتبارسنج استفاده میکنید، در اینجا چند انجمن وجود دارد که به شما در شروع کار کمک میکنند.
-
-- [دیسکورد EthStaker](https://discord.gg/ethstaker)
-- [ردیت EthStaker](https://www.reddit.com/r/ethstaker)
-
-اکثر تیمهایی که کلاینت های اتریومی را میسازند، فضاهای اختصاصی و عمومی دارند که میتوانید از آنها پشتیبانی دریافت کنید و سؤال بپرسید.
-
-### کلاینتهای اجرا {#execution-clients}
-
-- [Geth](https://discord.gg/FqDzupGyYf)
-- [Nethermind](https://discord.gg/YJx3pm8z5C)
-- [Besu](https://discord.gg/p8djYngzKN)
-- [Erigon](https://github.com/ledgerwatch/erigon/issues)
-- [Reth](https://github.com/paradigmxyz/reth/discussions)
-
-### کلاینتهای اجماع {#consensus-clients}
-
-- [Prysm](https://discord.gg/prysmaticlabs)
-- [Nimbus](https://discord.gg/nSmEH3qgFv)
-- [Lighthouse](https://discord.gg/cyAszAh)
-- [Teku](https://discord.gg/7hPv2T6)
-- [Lodestar](https://discord.gg/aMxzVcr)
-
-همچنین میتوانید [نحوهی اجرای یک گره را در اینجا بیاموزید](/developers/docs/nodes-and-clients/run-a-node/).
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
deleted file mode 100644
index a26391d9d4c..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md"
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: نود آرشیو در اتریوم
-description: مروری بر نود آرشیو در اتریوم
-lang: fa
-sidebarDepth: 2
----
-
-یک گره آرشیو نمونهای از کاربر اتریوم است که برای آرشیو تمامی وضعیتهای تاریخی شبکه پیکربندی شده است. این گره ابزاری مفید برای استفاده در موارد خاص بوده ولی ممکن است اجرای آن نسبت به گره کامل دشوارتر باشد.
-
-## پیشنیازها {#prerequisites}
-
-شما باید قبل از استفاده از نود آرشیوگر درک درستی از مواردی مانند [مفهوم نود در اتریوم](/developers/docs/nodes-and-clients/) ،[معماری آن](/developers/docs/nodes-and-clients/node-architecture/), [استراتژیهای همگامسازی](/developers/docs/nodes-and-clients/#sync-modes), تمرینهای مرتبط با [راهاندازی](/developers/docs/nodes-and-clients/run-a-node/) و [استفاده از این نوع نودها](/developers/docs/apis/json-rpc/).
-
-## گره آرشیوگر چیست؟
-
-برای درکی درست از اهمیت یک گره آرشیو، بیایید مفهوم «حالت» را برایتان روشن کنیم. اتریوم را میتوان به عنوان _ماشین حالتی که مبتنی بر تراکنش است_ نامگذاری نمود. این ماشین شامل حسابها و برنامههایی است که با اجرای تراکنشها وضعیت خود را تغییر میدهند. دادههای جهانی به همراه اطلاعات هر حساب و قرارداد، در یک پایگاه دادۀ درختی به نام وضعیت ذخیرهسازی میشوند. این عمل توسط کاربر در لایۀ اجرا (EL) انجام میگیرد که شامل موارد زیر است:
-
-- موجودیها و نانسهای حساب
-- کد قرارداد و ذخیرهسازی
-- دادههای مربوط به اجماع مانند قرارداد سهام گذاری
-
-برای تعامل با شبکه، تایید و تولید بلاک جدید، کاربرهای اتریوم باید با آخرین تغییرات (انتهای زنجیرۀ شبکه) و وضعیت فعلی آن همگام باشند. کاربر لایۀ اجرا که به عنوان یک نود کامل پیکربندی شده است آخرین وضعیت شبکه را تایید و از آن پیروی میکند اما فقط چند حالت گذشته را میتواند در خود ذخیره کند، به عنوان مثال، تنها قابلیت ذخیرهسازی وضعیت مرتبط با 128 بلوک آخر در شبکه را دارد، بنابراین این کاربر میتواند سازماندهی مجدد زنجیره را مدیریت کرده و دسترسی سریع به دادههای اخیر را فراهم نماید. وضعیت اخیر حالتی است که تمامی کاربرها برای تایید تراکنشهای دریافتی و استفاده از شبکه به آن نیاز دارند.
-
-شما میتوانید وضعیت را به عنوان اسنپشات شبکه در یک بلوک مشخص و آرشیو را به عنوان بازپخش تاریخی آن تصور کنید.
-
-وضعیتهای تاریخی را میتوان با خیال راحت از بین برد، چون این وضعیتها برای عملکرد شبکه ضروری نیستند و نگهداری از تمامی دادههای قدیمی برای کاربر بیهوده است. وضعیتهایی که قبل از چند بلوک اخیر وجود داشتهاند (مانند 128 بلوک از آخر) دور ریخته میشوند. گرههای کامل تنها دادههای تاریخی بلاکچین را نگهداری میکنند (بلوکها و تراکنشها) و اسنپشاتهای تاریخی میتوانند گهگاه در صورت درخواست برای بازسازی دوبارۀ وضعیتهای قدیمیتر استفاده شوند. آنها این کار را با اجرای مجدد تراکنشهای گذشته در EVM انجام میدهند، که زمانی که وضعیت موردنظر از نزدیکترین اسنپشات فاصله دارد، ممکن است سخت باشد.
-
-با این حال، این بدین معنی است که دسترسی به یک وضعیت تاریخی در یک گره کامل، محاسباتی زیادی لازم دارد. کاربر ممکن است نیاز به اجرای تمام تراکنشهای گذشته و محاسبۀ یک وضعیت تاریخی از پیدایش داشته باشد. گرههای آرشیو این مشکل را با ذخیرهسازیِ نه فقط وضعیتهای اخیر بلکه تمام وضعیتهای تاریخی ایجاد شده بعد از هر بلوک حل میکنند. این کار اساساً نوعی مبادلۀ دو طرفه با فضای بیشتر دیسک را ایجاد میکند.
-
-توجه به این نکته بسیار مهم است که شبکه به گرههای آرشیو برای نگهداری و ارائه تمام دادههای تاریخی وابسته نیست. همانطور که در بالا اشاره شد، تمام وضعیتهای موقت تاریخی میتوانند از طریق گرههای کامل به دست آیند. تراکنشها توسط هر گره کامل ذخیره میشوند (در حال حاضر کمتر از 400G) و میتوان برای ساخت کل آرشیو، مجدداً آنها را در شبکه پخش کرد.
-
-### موارد استفاده
-
-استفادۀ منظم از شبکۀ اتریوم مانند ارسال تراکنشها، استقرار قراردادها، تایید اجماعها و غیره نیازی به دسترسی داشتن به وضعیتهای تاریخی ندارد. به طور کلی کاربران هرگز برای تعامل استاندارد با شبکه نیازی به گره آرشیو ندارند.
-
-مزیت اصلی آرشیوِ وضعیت، دسترسی سریع به درخواستهای مرتبط با وضعیتهای تاریخی است. برای مثال، گره آرشیو با سرعت زیادی به نتایجی مانند موارد زیر میرسد:
-
-- _موجودی حساب اتریومی 0x1337… در بلوک 15537393 چقدر بود؟_
-- _موجودی توکن 0x در بلوک 1920000 چقدر است؟_
-
-همانطور که در بالا توضیح داده شد، یک گره کامل باید این دادهها را با اجرای EVM که از CPU استفاده میکند و بسیار زمانبر است، تولید کند. گرههای آرشیو به تمام این دادهها بر روی دیسک دسترسی دارند و بلافاصله پاسخها را نسبت به این قبیل مسائل ارائه میدهند. این ویژگی برای بخشهای خاصی از زیرساخت شبکه مفید است، برای مثال:
-
-- ارائهدهندگان سرویسهایی مثل جستجوگرهای بلوک
-- پژوهشگران
-- تحلیلگران امنیتی
-- توسعهدهندگان برنامههای غیرمتمرکز یا Dappها
-- حسابرسی و انطباق
-سرویسهای رایگان مختلف وجود دارند که امکان دسترسی به دادههای تاریخی را فراهم میکنند. از آنجا که اجرای یک گره آرشیو پرزحمت تر است، دسترسی به آن از طریق سرویسهای مختلف عمدتاً محدود بوده و ممکن است این سرویسها تنها بعضی اوقات کار کنند. اگر پروژۀ شما نیاز به دسترسی پیوسته به دادههای تاریخی دارد، بهتر است خودتان یک گره آرشیو بر روی سیستمتان اجرا کنید.
-
-
-
-## اجراها و کاربرد
-
-گره آرشیو به معنای دادههای ارائه شده از سوی کاربرهایی است که با کاربرهای لایه اجرا روبه رو هستند زمانی که آنها پایگاه دادۀ وضعیت را مدیریت کرده و نقاط پایانی JSON-RPC را فراهم میکنند. گزینههای پیکربندی، زمان همگامسازی و سایز دادهها ممکن است بسته به کاربر متفاوت باشد. برای جزئیات بیشتر، لطفا به اسناد ارائه شده توسط کاربرتان رجوع کنید.
-
-قبل از شروع راهاندازی گره آرشیوتان، در رابطه با تفاوتهای بین کاربرها و علی الخصوص [نیازمندیهای سختافزاریشان](/developers/docs/nodes-and-clients/run-a-node/#requirements) مطالعه کنید. شایان ذکر است که اکثر کاربرها بهینهسازی نشدهاند و آرشیوشان نیاز به فضای بیش از 12 ترابایت دارد. در مقابل، پیادهسازیهایی مانند Erigon میتوانند همان داده را در کمتر از 3 ترابایت ذخیره کنند که موثرترین راه برای اجرای یک گره آرشیو محسوب میشود.
-
-
-
-## اقدامات توصیه شده
-
-جدا از [توصیههای کلی برای اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/)، یک گره آرشیو ممکن است از نظر سختافزار و نگهداری الزامات بیشتری داشته باشد. با توجه به [ویژگیهای کلیدی](https://github.com/ledgerwatch/erigon#key-features) عملیترین رویکرد در این زمینه همان استفاده از پیادهسازی کاربر [Erigon](/developers/docs/nodes-and-clients/#erigon) است.
-
-
-
-### سختافزار
-
-همیشه مطمئن شوید که الزامات سخت افزاری برای یک حالت معین در اسناد کاربر را تایید میکنید. بزرگترین نیاز برای گرههای آرشیو فضای دیسک است. این فضا بسته به کاربر، میتواند از 3 ترابایت تا 12 ترابایت متفاوت باشد. حتی اگر HDD راهحل بهتری برای حجم زیادی از داده به نظر رسد، برای همگامسازی و به روزرسانی پیوستهاش با زنجیرۀ شبکه، به درایوهای SSD نیاز خواهد داشت. درایوهای [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) به اندازۀ کافی خوب هستند ولی باید کیفیت قابل اعتماد حداقل در حد [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences) داشته باشند. دیسکها را میتوان بر روی کامپیوتر یا یک سرور با اسلات کافی نصب کرد. چنین دستگاههایی برای اجرای گره با زمان کاریِ بالا ایده آل و مناسب هستند. اجرای آن بر روی لپ تاپ نیز امکانپذیر است ولی قابل حمل بودنش هزینۀ اضافی به همراه خواهد داشت.
-
-تمامی دادهها باید در یک حجم قرار گیرند بنابراین دیسکها باید به عنوان مثال توسط [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) یا [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html) به هم متصل شوند. همچنین ممکن است استفاده از سیستم فایل [ZFS](https://en.wikipedia.org/wiki/ZFS) از آنجا که از ویژگی Copy-on-write پشتیبانی میکند، ارزشمند باشد، در واقع این ویژگی اطمینان حاصل میکند که دادهها به درستی بر روی دیسک و بدون هیچ گونه خطای سطح پایین نوشته شده باشند.
-
-برای ثبات و امنیت بیشتر به منظور جلوگیری از خرابی تصادفی در پایگاه داده، به خصوص در تنظیمات حرفهای، از [ECC memory](https://en.wikipedia.org/wiki/ECC_memory) در صورتی که توسط سیستمتان پشتیبانی میشود، استفاده کنید. به طور کلی توصیه میشود سایز RAM هم اندازۀ گره کامل باشد ولی در کل RAM بیشتر میتواند به سرعت همگامسازی کمک کند.
-
-در طول همگامسازی اولیه، کاربرها در حالت آرشیو هر تراکنشی را از زمان پیدایش اجرا میکنند. سرعت اجرا بیشتر توسط CPU محدود میشود، بنابراین CPU سریعتر میتواند به زمان همگامسازی اولیه کمک کند. در یک کامپیوتر معمولی، زمان همگامسازی اولیه میتواند تا یک ماه طول بکشد.
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [گره کامل اتریوم در مقایسه با گره آرشیو](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) - _QuickNode، سپتامبر 2022_
-- [گره آرشیو اتریوم خودتان را بسازید](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) - _تامس جی راش، اوت 2021_
-- [چگونه Erigon را نصب کنیم، RPC اِریگون و TrueBlocks (اسکریپ و API) به عنوان خدمات](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– ماگنون هانسن، بهروز رسانی سپتامبر 2022_
-
-
-
-## موضوعات مرتبط {#related-topics}
-
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
-- [راهاندازی یک گره](/developers/docs/nodes-and-clients/run-a-node/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
deleted file mode 100644
index 34e555578f9..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md"
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: مقدمه ای بر بوتنودهای اتریوم
-description: اطلاعات اولیه ای که برای درک بوت نودها نیاز دارید
-lang: fa
----
-
-هنگامی که یک گره جدید به شبکه اتریوم میپیوندد، باید به گرههایی که از قبل در شبکه هستند متصل شود تا همتاهای جدید را کشف کند. به این نقاط ورود به شبکه اتریوم، بوت نود می گویند. کاربرها معمولاً فهرستی از بوت نودها را دارند که در آنها کدگذاری شده است. این بوت نودها معمولاً توسط تیم توسعه دهنده بنیاد اتریوم یا خود تیم های کاربر اجرا می شوند. توجه داشته باشید که بوت نودها با گره های استاتیک یکسان نیستند. گره های استاتیک بارها و بارها فراخوانی می شوند، در حالی که بوت نودها فقط زمانی فراخوانی می شوند که همتاهای کافی برای اتصال به آن ها وجود نداشته باشد و یک گره نیاز به بوت استرپ برخی از اتصالات جدید داشته باشد.
-
-## اتصال به یک بوت نود {#connect-to-a-bootnode}
-
-اکثر کاربرها فهرستی از بوتنودها را در خود دارند، اما ممکن است بخواهید بوتنود خود را نیز اجرا کنید، یا از یکی استفاده کنید که بخشی از لیست کدهای سخت کاربر نیست. در این مورد، می توانید آنها را هنگام راهاندازی کاربر خود به شرح زیر مشخص کنید (به عنوان مثال برای Geth، لطفاً اسناد کاربر خود را بررسی کنید):
-
-```
-geth --bootnodes "enode://@:"
-```
-
-## اجرای یک بوت نود {#run-a-bootnode}
-
-بوت نودها گره های کاملی هستند که پشت NAT نیستند ([ترجمه آدرس شبکه](https://www.geeksforgeeks.org/network-address-translation-nat/)). هر گره کامل تا زمانی که در دسترس عموم باشد می تواند به عنوان یک بوت نود عمل کند.
-
-هنگامی که یک گره را راهاندازی می کنید، باید [enode](/developers/docs/networking-layer/network-addresses/#enode) شما را ثبت کند، که یک شناسه عمومی است که دیگران می توانند از آن برای اتصال به گره شما استفاده کنند.
-
-این enode معمولاً در هر راهاندازی مجدد بازسازی میشود، بنابراین مطمئن شوید که به مستندات کاربر خود در مورد نحوه ایجاد یک enode پایدار برای بوتنود خود نگاه کنید.
-
-برای اینکه بوتنود خوبی باشید، ایده خوبی است که حداکثر تعداد همتاهایی را که میتوانند به آن متصل شوند، افزایش دهید. اجرای یک بوت نود با همتایان زیاد، پهنای باند مورد نیاز را به میزان قابل توجه افزایش می دهد.
-
-## بوت نودهای موجود {#available-bootnodes}
-
-فهرستی از بوت نودهای داخلی در go-ethereum را میتوانید [اینجا](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23) پیدا کنید. این بوت نودها توسط بنیاد اتریوم و تیم go-ethereum نگهداری می شوند.
-
-لیست های دیگری از بوت نودها وجود دارد که توسط داوطلبان نگهداری می شوند. لطفاً مطمئن شوید که همیشه حداقل یک بوتنود رسمی گنجانده شده است، در غیر این صورت ممکن است تحت حمله Eclipse قرار بگیرید.
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
deleted file mode 100644
index 9a2fcf0b6b2..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md"
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: تنوع کلاینتها
-description: توضیح سطح بالایی از اهمیت تنوع کلاینت در اتریوم.
-lang: fa
-sidebarDepth: 2
----
-
-رفتار یک گرهی اتریوم توسط نرمافزار کلاینتی که اجرا میکند کنترل میشود. چندین کلاینت اتریوم در سطح تولید وجود دارند که هر کدام به زبانهای مختلف توسط تیمهای جداگانه توسعه یافته و نگهداری میشوند. کلاینتها بر اساس مشخصات مشترکی ساخته شدهاند که تضمین میکند کلاینتها بهطور یکپارچه با یکدیگر ارتباط برقرار میکنند و عملکرد یکسانی دارند و تجربهی کاربری برابری را ارائه میدهند. با این حال، در حال حاضر توزیع کلاینتها در سراسر گرهها به اندازهی کافی برای تحقق این تقویت شبکه با پتانسیل کامل آن برابر نیست. در حالت ایدهآل، کاربران تقریباً بهطور مساوی بین کلاینتهای مختلف تقسیم میکنند تا بیشترین تنوع کلاینت را به شبکه بیاورند.
-
-## پیشنیازها {#prerequisites}
-
-اگر از قبل نمیدانید گرهها و کاربرها چیست، [گرهها و کاربرها](/developers/docs/nodes-and-clients/) را بررسی کنید. لایههای [اجرا](/glossary/#execution-layer) و [اجماع](/glossary/#consensus-layer) در واژهنامه تعریف شدهاند.
-
-## چرا چندین کلاینت وجود دارد؟ {#why-multiple-clients}
-
-کلاینتهای متعددی وجود دارند که بهطور مستقل توسعه یافته و نگهداری میشوند زیرا تنوع کلاینت شبکه را در برابر حملات و اشکالهای نرمافزاری سرسختتر میکند. تعدد کلاینتها یک نقطهی قوت منحصربهفرد برای اتریوم است - سایر زنجیرههای بلوکی بر مصونیت یک کلاینت از خطای تکیه دارند. با این حال، صرفاً در دسترس داشتن چندین کلاینت کافی نیست، آنها باید توسط جامعه پذیرفته شوند و کل گرههای فعال بهطور نسبتاً مساوی در بین آنها توزیع شوند.
-
-## چرا تنوع کلاینت مهم است؟ {#client-diversity-importance}
-
-داشتن کلاینتهای توسعهیافته بهطور مستقل و نگهداریشدهی متعدد برای سلامت یک شبکهی غیرمتمرکز حیاتی است. بیایید دلایل آن را بررسی کنیم.
-
-### اشکالات نرمافزاری {#bugs}
-
-یک اشکال در یک کلاینت منفرد که نمایندهی اقلیتی از گرههای اتریوم باشد، خطر کمتری برای شبکه دارد. با توزیع تقریباً یکنواخت گرهها در بین بسیاری از کلاینتها، احتمال اینکه اکثر کلاینتها از یک مشکل مشترک رنج ببرند اندک است و در نتیجه شبکه قویتر است.
-
-### تابآوری در برابر حملات {#resilience}
-
-تنوع کلاینت همچنین باعث تابآوری در برابر حملات میشود. بهعنوان مثال، حمله ای که [یک کلاینت خاص را به سمت شاخهی خاصی از زنجیره فریب دهد](https://twitter.com/vdWijden/status/1437712249926393858) بعید است موفقیت آمیز باشد زیرا بعید است سایر کلاینتها به همان شیوه فریب بخورند و زنجیرهی متعارف خراب نمیشود. تنوع کم کلاینت، خطر مرتبط با هک در کلاینت غالب را افزایش میدهد. قبلاً ثابت شده است که تنوع کلاینت، دفاع مهمی در برابر حملات مخرب در شبکه است. بهعنوان مثال، حملهی محرومسازی از سرویس شانگهای در سال 2016 به این خاطر امکانپذیر بود که مهاجمان توانستند کلاینت غالب (Geth) را فریب دهند که یک دیسک آهستهی عملیات i/o را دهها هزار بار در هر بلوک اجرا کند. از آنجایی که کلاینتهای جایگزین نیز آنلاین بودند و آسیبپذیری را نداشتند، اتریوم توانست در مقابل حمله مقاومت کند و تا زمانی که آسیبپذیری در Geth رفع شد، به کار خود ادامه دهد.
-
-### قطعیت اثبات سهام {#finality}
-
-یک باگ در یک کاربر توافقی با بیش از 33 درصد از گرههای اتریوم میتواند از نهایی شدن لایه اجماع جلوگیری کند، به این معنی که کاربران نمیتوانند اعتماد کنند که تراکنشها در مقطعی بازگردانده یا تغییر نخواهند کرد. این برای بسیاری از برنامه های ساخته شده در بالای اتریوم، به ویژه DeFi، بسیار مشکل ساز خواهد بود.
-
- بدتر از آن، یک اشکال حیاتی در کلاینت با اکثریت دو سوم میتواند باعث شود که زنجیره بهاشتباه تقسیم و نهایی شود، که باعث میشود مجموعهی بزرگی از اعتبارسنجها در زنجیرهای نامعتبر گیر کنند. اگر بخواهند دوباره به زنجیرهی درست بپیوندند، این اعتبارسنجها با برخورد شدید یا خروج و فعالسازی مجدد داوطلبانهی آهسته و پرهزینه مواجه میشوند. شدت برخورد شدید متناسب با تعداد گرههای مقصر است و دو سوم اکثریت مورد شدیدترین برخورد قرار میگیرند (32 اتر).
-
-اگرچه این سناریوها بعید هستند، اما اکوسیستم اتریوم میتواند ریسک آنها را با یکنواخت کردن توزیع کلاینتها در سراسر گرههای فعال کاهش دهد. در حالت ایده آل، هیچ کاربر اجماع هرگز به سهم 33% از کل گره ها نخواهد رسید.
-
-### مسئولیت مشترک {#responsibility}
-
-داشتن اکثریت کلاینتها هزینهی انسانی هم دارد. این کار، فشار و مسئولیت بیش از حدی بر دوش یک تیم توسعهی کوچک وارد میکند. هرچه تنوع کلاینت کمتر باشد، بار مسئولیت توسعهدهندگانی که از کلاینت اکثریت نگهداری میکنند، بیشتر میشود. پخش کردن این مسئولیت بین تیمهای متعدد، هم برای سلامت شبکهی گرههای اتریوم و هم برای شبکهی افراد آن مفید است.
-
-## تنوع کلاینت فعلی {#current-client-diversity}
-
-![نمودار دایرهای که تنوع کلاینت را نشان میدهد](./client-diversity.png) _دادههای نمودار از [ethernodes.org](https://ethernodes.org) و [ clientdiversity.org](https://clientdiversity.org/)_
-
-دو نمودار دایرهای بالا تصاویری فوری از تنوع کلاینت فعلی برای لایههای اجرا و اجماع (در زمان نگارش در ژانویه 2022) را نشان میدهند. لایهی اجرا غالباً در سلطهی [Geth](https://geth.ethereum.org/) است، [Open Ethereum با فاصله دوم است، ](https://openethereum.github.io/) [Erigon](https://github.com/ledgerwatch/erigon) سوم است و [Nethermind](https://nethermind.io/) چهارم است، و در عین حال سایر کلاینتها که کمتر از 1% شبکه را تشکیل میدهند. رایجترین کلاینت مورد استفاده در لایهی اجماع - [Prysm](https://prysmaticlabs.com/#projects) - به اندازه Geth غالب نیست، اما در عین حال بیش از 60% از شبکه را نمایندگی میکند. [Lighthouse](https://lighthouse.sigmaprime.io/) و [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) به ترتیب 20% و حدود 14% حضور دارند و سایر کلاینتها بهندرت استفاده میشوند.
-
-داده های لایه اجرا از [Ethernodes](https://ethernodes.org) در 23 ژانویه 2022 به دست آمدند. دادههای کلاینتهای اجماع از [Michael Sproul](https://github.com/sigp/blockprint) گرفته شده است. بهدست آوردن دادههای کاربر اجماع دشوارتر است، زیرا کاربرهای لایه اجماع همیشه دارای ردپاهای واضحی نیستند که بتوان از آنها برای شناسایی استفاده کرد. دادهها با استفاده از یک الگوریتم طبقهبندی تولید شدهاند که گاهی برخی از کلاینتهای اقلیت را گیج میکند (برای جزئیات بیشتر به [اینجا](https://twitter.com/sproulM_/status/1440512518242197516) مراجعه کنید). در نمودار بالا، این طبقهبندیهای مبهم یک برچسب یا این/یا آن (بهعنوان مثال Nimbus/Teku) دارند. با وجود این، واضح است که اکثریتِ شبکه Prysm را اجرا میکند. دادهها، تصویری از مجموعهی ثابتی از بلوکها هستند (در این مورد، بلوکهای بیکن در اسلاتهای 2048001 تا 2164916) و حضور غالب Prysm گاهی اوقات بالاتر و بیش از 68% بوده است. علیرغم صرفاً یک تصویر بودن، مقادیر نمودار درک کلی خوبی از وضعیت فعلی تنوع کلاینت ارائه میدهند.
-
-داده های به روز شده تنوع مشتری، برای لایه اجماع اکنون در [clientdiversity.org](https://clientdiversity.org/) در دسترس است.
-
-## لایهی اجرا {#execution-layer}
-
-تا به حال، گفتگو پیرامون تنوع کلاینت عمدتاً بر لایهی اجماع متمرکز بوده است. با این حال، کلاینت اجرای [Geth](https://geth.ethereum.org) در حال حاضر حدود 85% از کل گرهها را تشکیل میدهد. این درصد به دلایل یکسان برای کلاینتهای اجماع مشکلساز است. برای مثال، یک اشکال نرمافزاری در Geth که روی انجام دادن تراکنش تأثیر میگذارد یا پیلودهای اجرایی درست میکند، میتواند منجر به این شود که کلاینتهای اجماع تراکنشهای مشکلساز یا مشکلدار را نهایی کنند. بنابراین، اتریوم با توزیع یکنواختتری از کلاینتهای اجرایی سالمتر خواهد بود. حالت ایدهآل این است که هیچ کلاینتی بیش از 33% از شبکه را نمایندگی نکند.
-
-## از کلاینت اقلیت استفاده کنید {#use-minority-client}
-
-توجه کردن به تنوع کلاینت به بیش از کاربران منفردی نیاز دارد که کلاینتهای اقلیت را انتخاب کنند - این کار نیازمند استخرهای استخراج/ اعتبارسنج و نهادهایی مانند dappها و صرافیهای اصلی است تا کلاینتها را هم تغییر دهند. با این حال، همهی کاربران میتوانند سهم خود را در اصلاح عدم توازن فعلی و عادیسازی استفاده از تمام نرمافزارهای موجود اتریوم انجام دهند. پس از ادغام، تمام عملگرهای گره ملزم به اجرای یک کلاینت اجرا و یک کلاینت اجماع خواهند بود. انتخاب ترکیبی از کلاینتهای پیشنهادشده در زیر به افزایش تنوع کلاینت کمک میکند.
-
-### کلاینتهای اجرا {#execution-clients}
-
-[Besu](https://www.hyperledger.org/use/besu)
-
-[Nethermind](https://downloads.nethermind.io/)
-
-[Erigon](https://github.com/ledgerwatch/erigon)
-
-[Go-Ethereum](https://geth.ethereum.org/)
-
-### کلاینتهای اجماع {#consensus-clients}
-
-[Nimbus](https://nimbus.team/)
-
-[Lighthouse](https://github.com/sigp/lighthouse)
-
-[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
-
-[Lodestar](https://github.com/ChainSafe/lodestar)
-
-[Prysm](https://docs.prylabs.network/docs/getting-started)
-
-کاربران فنی میتوانند با نوشتن آموزشها و مستندات بیشتر برای کلاینتهای اقلیت و تشویق همتایان گرهگردان خود به مهاجرت کردن دور از کلاینتهای غالب، به تسریع این فرایند کمک کنند. راهنماهای تغییر به کلاینت اجماع اقلیت در [clientdiversity.org](https://clientdiversity.org/) موجود است.
-
-## داشبوردهای تنوع کلاینت {#client-diversity-dashboards}
-
-چند داشبورد آمار تنوع کلاینت را بهصورت لحظهای برای لایهی اجرا و اجماع ارائه میدهند.
-
-**لایهی اجماع:**
-
-- [Rated.network](https://www.rated.network/)
-- [clientdiversity.org](https://clientdiversity.org/) **لایه اجرا:**
-
-- [supermajority.info](https://supermajority.info//)
-- [Ethernodes](https://ethernodes.org/)
-
-## اطلاعات بیشتر {#further-reading}
-
-- [تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
-- [ادغام اتریوم: کلاینت اکثریت را با ریسک خودتان اجرا کنید!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) - _دانکراد فیست، 24 مارس 2022_
-- [اهمیت تنوع کلاینت](https://our.status.im/the-importance-of-client-diversity/)
-- [فهرست خدمات گرهی اتریوم](https://ethereumnodes.com/)
-- [«پنج چرا»ی مشکل تنوع کلاینت](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
-- [تنوع اتریوم و نحوه حل آن (یوتیوب)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
-- [clientdiversity.org](https://clientdiversity.org/)
-
-## موضوعات مرتبط {#related-topics}
-
-- [اجرای یک گرهی اتریوم](/run-a-node/)
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
deleted file mode 100644
index 97ad557b24c..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md"
+++ /dev/null
@@ -1,307 +0,0 @@
----
-title: گرهها و کلاینتها
-description: نگاهی اجمالی بر گرهها و نرمافزار کلاینت اتریوم، به علاوهی نحوهی راهاندازی یک گره و علت انجام آن.
-lang: fa
-sidebarDepth: 2
----
-
-اتریوم یک شبکه توزیعشده از رایانهها (معروف به گرهها) است که نرمافزاری را اجرا میکنند که میتواند بلوکها و دادههای تراکنش را تأیید کند. نرم افزار باید بر روی رایانهی شما اجرا شود تا آن را به یک نود اتریوم تبدیل کند. برای تشکیل یک گره، دو بخش مجزا از نرمافزار (که به عنوان "کلاینت" شناخته می شوند) مورد نیاز است.
-
-## پیشنیازها {#prerequisites}
-
-پیش از آن که نمونهی کلاینت اتریوم خود را اجرا کنید و در این موضوع عمیق شوید باید [مبانی ماشین مجازی اتریوم](/developers/docs/evm/) و شبکهی همتا به همتا را بدانید و متوجه شوید. به [معرفی اتریوم](/developers/docs/intro-to-ethereum/) ما نگاهی بیندازید.
-
-اگر با موضوع گرهها تازه کار هستید، توصیه میکنیم ابتدا مقدمه کاربرپسند ما در مورد [اجرای گره اتریوم](/run-a-node) را بررسی کنید.
-
-## کلاینتها و گرهها چه هستند؟ {#what-are-nodes-and-clients}
-
-"گره" هر نمونهای از نرمافزار مشتری اتریوم است که به رایانه های دیگری که نرمافزار اتریوم را نیز اجرا می کنند متصل است و یک شبکه را تشکیل میدهد. یک کلاینت یک نرمافزار پیادهسازی اتریوم است که داده ها را بر اساس قوانین پروتکل تأیید می کند و شبکه را ایمن نگه می دارد. یک گره باید دو کلاینت را اجرا کند: یک کلاینت اجماع و یک کلاینت اجرا.
-
-- کلاینت اجرا (همچنین به عنوان مهندس اجرا، کلاینت EL یا قبلاً کلاینت Eth1 شناخته می شود) به تراکنشهای جدید پخش شده در شبکه گوش می دهد، آنها را در EVM اجرا می کند و آخرین وضعیت و پایگاه داده تمام داده های فعلی اتریوم را نگه می دارد.
-- کلاینت اجماع (همچنین به عنوان نود بیکن، کلاینت CL یا قبلاً کلاینت Eth2 شناخته میشود) الگوریتم اجماع اثبات سهام را پیادهسازی میکند، که شبکه را قادر میسازد بر اساس دادههای معتبر از کلاینت اجرا به اجماع برسد. همچنین نرمافزار سومی وجود دارد که به عنوان "اعتبارسنج" شناخته می شود که می تواند به کلاینت اجماع اضافه شود و به یک گره اجازه می دهد تا در ایمنسازی شبکه مشارکت کند.
-
-این کلاینتها با هم کار می کنند تا سر زنجیره اتریوم را پیگیری کنند و به کاربران اجازه دهند با شبکه اتریوم تعامل داشته باشند. طراحی مدولار با چندین نرمافزار که با هم کار می کنند [پیچیدگی کپسوله شده](https://vitalik.eth.limo/general/2022/02/28/complexity.html) نامیده می شود. این رویکرد اجرای یکپارچه [مرج](/roadmap/merge) را آسانتر میکند، نگهداری و توسعه نرمافزار کلاینت را آسانتر میکند، و استفاده مجدد از کلاینتهای تنها را، برای مثال، در [اکوسیستم لایه2](/layer-2/) ممکن میسازد.
-
-![کلاینت اجرا و اجماع کنار هم](./eth1eth2client.png) نمودار سادهشدهی کلاینت اجرا و اجماع کنار هم.
-
-### تنوع کلاینتها {#client-diversity}
-
-هم [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients) و هم [کلاینتهای اجماع](/developers/docs/nodes-and-clients/#consensus-clients) در انواع زبان های برنامه نویسی که توسط تیم های مختلف توسعه یافتهاند وجود دارند.
-
-پیادهسازی های متعدد کلاینت می تواند شبکه را با کاهش وابستگی آن به یک پایگاه کد، قویتر کند. هدف ایده آل دستیابی به تنوع بدون هرگونه تسلط کلاینت بر شبکه است و در نتیجه یک نقطه شکست بالقوه را از بین می برد. تنوع زبان ها همچنین جامعه توسعه دهندگان گسترده تری را دعوت می کند و به آنها اجازه می دهد تا به زبان دلخواه خود ادغام ایجاد کنند.
-
-درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) بیشتر بدانید.
-
-وجه مشترک این پیاده سازی ها این است که همه آنها از یک مشخصات واحد پیروی می کنند. مشخصات نحوه عملکرد شبکه اتریوم و بلاکچین را تعیین می کند. هر جزئیات فنی تعریف شده است و مشخصات را می توان به صورت زیر یافت:
-
-- در اصل، [زردنامه اتریوم](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [مشخصات لایه اجرا](https://github.com/ethereum/execution-specs/)
-- [مشخصات لایه اجماع](https://github.com/ethereum/consensus-specs)
-- [EIPهای](https://eips.ethereum.org/) پیادهسازی شده در گسترهای از [ارتقاهای شبکه](/history/)
-
-### ردیابی نودها در شبکه {#network-overview}
-
-ردیابهای متعدد یک نمای کلی از گرهها در شبکه اتریوم در زمان واقعی ارائه میدهند. توجه داشته باشید که با توجه به ماهیت شبکه های غیرمتمرکز، این خزنده ها تنها می توانند دید محدودی از شبکه ارائه دهند و ممکن است نتایج متفاوتی را گزارش کنند.
-
-- [نقشه نودها](https://etherscan.io/nodetracker) توسط Etherscan
-- [Ethernodes](https://ethernodes.org/) توسط Bitfly
-- [Nodewatch](https://www.nodewatch.io/) توسط Chainsafe، که در نودهای اجماع میخزد
-
-## انواع گره {#node-types}
-
-اگر میخواهید [گرهی خودتان را اجرا کنید](/developers/docs/nodes-and-clients/run-a-node/)، باید بدانید که گرههای مختلفی وجود دارند که دادههای مختلفی را استفاده میکنند. در واقع، کلاینتها می توانند سه نوع مختلف از گره را اجرا کنند: سبک، کامل و آرشیو. همچنین گزینههایی از استراتژیهای همگامسازی مختلف وجود دارد که زمان همگامسازی سریعتر را امکانپذیر میکند. همگامسازی به این اشاره دارد که با چه سرعتی میتوان بهروزترین اطلاعات را در مورد وضعیت اتریوم دریافت کرد.
-
-### گره کامل {#full-node}
-
-گرههای کامل اعتبارسنجی بلوک به بلوک زنجیره بلوک را انجام میدهند، از جمله دانلود و تأیید بدنه بلوک و دادههای حالت برای هر بلوک. کلاسهای مختلفی از گره کامل وجود دارد - برخی از بلوکهای پیدایش شروع میکنند و تک بلوکها را در کل تاریخچه بلاکچین تأیید میکنند. برخی دیگر تأیید خود را در بلوکی جدیدتر که به معتبر بودن آن اعتماد دارند شروع میکنند (مثلاً «همگامسازی فوری» Geth). صرف نظر از جایی که تأیید شروع می شود، گره های کامل فقط یک کپی محلی از داده های نسبتاً اخیر (معمولاً 128 عدد از جدیدترین بلوک ها) را نگه می دارند، که اجازه می دهد تا داده های قدیمی برای صرفهجویی در فضای دیسک حذف شوند. داده های قدیمی را می توان در صورت نیاز دوباره تولید کرد.
-
-- دادههای زنجیرهی بلوکی کامل را بهطور کامل ذخیره میکند (اگرچه حشو و زواید این دادهها به صورت دورهای حذف میشود، بنابراین یک گرهی کامل تمام دادههای حالت را از زمان پیدایش تاکنون ذخیره نمیکند)
-- در اعتبارسنجی بلوکها شرکت میکند و همهی وضعیتها و بلوکها را تأیید میکند.
-- همه حالت ها را می توان یا از حافظه محلی بازیابی کرد یا از «اسنپشاتهایی» توسط یک گره کامل بازسازی کرد.
-- در خدمت شبکه است و دادهها را در زمان درخواست ارائه میدهد.
-
-### گره آرشیو {#archive-node}
-
-گره های آرشیوی گره های کاملی هستند که هر بلوک را از پیدایش تأیید می کنند و هرگز هیچ یک از دادههای دانلود شده را حذف نمی کنند.
-
-- هر چیزی که در گره کامل نگهداری میشود را ذخیره میکند و یک آرشیو کامل از حالتهای تاریخی میسازد. اگر میخواهید چیزی مانند موجودی حساب را در بلوک شماره 4،000،000 جستجو کنید، یا به سادگی و با اطمینان مجموعه تراکنشهای خود را بدون استخراج آنها با استفاده از ردیابی آزمایش کنید، به چنین چیزی نیاز است.
-- این دادهها واحدهای ترابایت را نشان میدهند، که گرههای آرشیوی را برای کاربران متوسط جذابتر میکند، اما میتواند برای خدماتی مانند کاوشگرهای بلوک، فروشندگان کیفپول و تحلیل زنجیره مفید باشد.
-
-همگامسازی کلاینتها در هر حالتی غیر از آرشیو منجر به کاهش دادههای زنجیرهی بلوکی میشود. این بدان معناست که هیچ آرشیوی از تمام حالتهای تاریخی وجود ندارد اما گرهی کامل قادر است آنها را بنا به تقاضا بسازد.
-
-درباره [نودهای آرشیوی](/developers/docs/nodes-and-clients/archive-nodes) بیشتر بدانید.
-
-### گره سبک {#light-node}
-
-به جای دانلود هر بلوک، گره های سبک فقط هدر بلوک ها را دانلود می کنند. این هدرها حاوی اطلاعات خلاصه ای در مورد محتویات بلوک ها هستند. هر اطلاعات دیگری که گره سبک نیاز دارد از یک گره کامل درخواست می شود. سپس گره سبک میتواند به طور مستقل دادههایی را که دریافت میکند با توجه به ریشههای حالت در هدرهای بلوک تأیید کند. گرههای سبک به کاربران امکان میدهند بدون سختافزار قدرتمند یا پهنای باند بالا که برای اجرای گرههای کامل لازم است، در شبکهی اتریوم مشارکت کنند. در نهایت، گرههای سبک ممکن است روی تلفنهای همراه یا دستگاههای تعبیهشده اجرا شوند. گرههای سبک در اجماع شرکت نمیکنند (یعنی نمیتوانند ماینر/اعتبارسنج باشند)، اما میتوانند با همان عملکرد و تضمینهای امنیتی یک گره کامل به بلاکچین اتریوم دسترسی داشته باشند.
-
-کلاینت های سبک ناحیهای برای توسعه فعال اتریوم هستند و انتظار داریم به زودی شاهد کلاینت های سبک جدید برای لایه اجماع و لایه اجرا باشیم. همچنین مسیرهای بالقوهای برای ارائهی دادههای کلاینت سبک از طریق [شبکهی شایعه](https://www.ethportal.net/) وجود دارد. این خودش مزیت است، زیرا شبکهی شایعه میتواند شبکهای از گرههای سبک را بدون نیاز به گرههای کامل برای ارائهی درخواستها پشتیبانی کند.
-
-اتریوم هنوز از گرههای سبک پرتعدادی پشتیبانی نمیکند، اما پشتیبانی از گرههای سبک حوزهای است که انتظار میرود در آیندهی نزدیک بهسرعت توسعه یابد. به طور خاص، کلاینتهایی مانند [Nimbus](https://nimbus.team/) و [Helios](https://github.com/a16z/helios) و [LodeStar](https://lodestar.chainsafe.io/) در حال حاضر به شدت بر روی گره های سبک متمرکز شده اند.
-
-## چرا باید یک گرهی اتریوم را اجرا کنم؟ {#why-should-i-run-an-ethereum-node}
-
-اجرای یک گره به شما این امکان را می دهد که به طور مستقیم، بدون نیاز به شخص ثالث و به صورت خصوصی از اتریوم استفاده کنید و در عین حال از شبکه با قوی تر و غیرمتمرکز نگه داشتن آن پشتیبانی کنید.
-
-### مزایا برای شما {#benefits-to-you}
-
-اجرای گره شما را قادر می سازد از اتریوم به صورت خصوصی، خودکفا و بدون نیاز به شخص ثالث استفاده کنید. نیازی نیست به شبکه اعتماد کنید زیرا میتوانید دادهها را خودتان با کلاینت خود تأیید کنید. «اعتماد نکنید، اعتبارسنجی کنید» یکی از شعارهای اصلی زنجیرهی بلوکی است.
-
-- گره شما تمام تراکنشها و بلوکها را با توجه به قوانین اجماع به تنهایی اعتبارسنجی میکند. این نکته به این معنی است که شما نیازی به اتکا به هیچ گرهی دیگری در شبکه یا اعتماد تام به آنها ندارید.
-- می توانید از کیف پول اتریوم با گره خود استفاده کنید. میتوانید از دپها به صورت ایمنتر و خصوصیتر استفاده کنید، زیرا مجبور نخواهید بود آدرسها و موجودیهای خود را به واسطهها فاش کنید. همهچیز میتواند با کلاینت خودتان بررسی شود. [متاسک](https://metamask.io) و [Frame](https://frame.sh/) و [بسیاری از کیفپولهای دیگر](/wallets/find-wallet/) ورود RPC را پشتیبانی میکنند و به آنها امکان میدهد از گره شما استفاده کنند.
-- میتوانید سرویسهای دیگری را که به دادههای اتریوم وابسته هستند، اجرا و میزبانی کنید. به عنوان مثال، این ممکن است یک اعتبار سنج بیکنچین، نرمافزاری مانند لایه2، زیرساخت، کاوشگرهای بلوک، پردازشگرهای پرداخت و غیره باشد.
-- شما می توانید [نقاط پایانی RPC](/developers/docs/apis/json-rpc/) سفارشی خود را ارائه دهید. حتی می توانید این نقاط پایانی را به صورت عمومی به جامعه ارائه دهید تا به آنها کمک کنید از ارائهدهندگان متمرکز بزرگ اجتناب کنند.
-- شما میتوانید با استفاده از **ارتباط بین پردازشی (IPC)** گرهی خود را متصل کنید یا برای بارگذاری برنامهی خود بهعنوان افزونه آن را بازنویسی کنید. این کار لتنسی کمی را به همراه دارد، که کمک بسیاری می کند، به عنوان مثال، هنگام پردازش دادههای زیادی با استفاده از کتابخانههای وب3.0 یا زمانی که باید تراکنشهای خود را با بیشترین سرعت ممکن جایگزین کنید (یعنی frontrunning).
-- شما میتوانید مستقیماً اتر را برای ایمنسازی شبکه و کسب پاداش سهامگذاری کنید. بخش [سهامگذاری انفرادی](/staking/solo/) را برای شروع ببینید.
-
-![چگونه با استفاده از برنامههای کاربردی و گرهها به اتریوم دسترسی داشته باشید](./nodes.png)
-
-### مزایای شبکه {#network-benefits}
-
-داشتن مجموعهی متنوعی از گرهها برای سلامت، امنیت و انعطافپذیری عملیاتی اتریوم حائظ اهمیت است.
-
-- گره های کامل قوانین لایه اجماع را اجرا می کنند بنابراین نمی توان آنها را فریب داد تا بلوک هایی را بپذیرند که از آن قوانین پیروی نمی کنند. این امر امنیت بیشتری را در شبکه ایجاد می کند زیرا اگر همه گره ها گره های سبک باشند که تأیید کامل را انجام نمی دهند، اعتبار سنجها می توانند به شبکه حمله کنند.
-- در صورت حمله ای که بر دفاعیات اقتصاد رمزنگاریشدهی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/#what-is-pos) غلبه کند، می توان با انتخاب گره های کامل که از زنجیره صادقانه پیروی می کنند، یک بازیابی اجتماعی انجام داد.
-- گرههای بیشتر در شبکه منجر به ایجاد یک شبکه متنوعتر و قویتر میشود، هدف نهایی تمرکززدایی، که سیستمی مقاوم در برابر سانسور و قابل اعتماد را امکانپذیر میسازد.
-- گره های کامل دسترسی به داده های بلاکچین را برای کلاینتهای سَبُکی که به آن وابسته هستند، فراهم می کند. گرههای سبک همهی زنجیره بلوکی را ذخیره نمیکنند و به جای آن دادهها را با [ریشهی حالت درون هدر بلوکها](/developers/docs/blocks/#block-anatomy) اعتبارسنجی میکنند. آنها می توانند در صورت نیاز اطلاعات بیشتری را از گره های کامل درخواست کنند.
-
-اگر یک گره کامل را اجرا کنید، کل شبکه اتریوم از آن سود می برد، حتی اگر اعتبارسنج را اجرا نکنید.
-
-## اجرای گرهی خودتان {#running-your-own-node}
-
-دوست دارید کلاینت اتریوم خودتان را اجرا کنید؟
-
-جهت مطالعهی مقدمهای ویژهی مبتدیان، از صفحهی [اجرای یک گره](/run-a-node)ی ما دیدن کنید تا بیشتر بدانید.
-
-اگر بیشتر یک کاربر فنی هستید، جزئیات و گزینههای بیشتری را در مورد نحوه [ثبتنام گره خود](/developers/docs/nodes-and-clients/run-a-node/) بررسی کنید.
-
-## جایگزینها {#alternatives}
-
-راهاندازی گره خود میتواند برای شما زمان و منابع هزینه داشته باشد، اما همیشه نیازی به اجرای نمونه خود ندارید. در این مورد، می توانید از یک ارائه دهنده API شخص ثالث استفاده کنید. برای مروری بر استفاده از این سرویسها، [گرهها بهعنوان سرویس](/developers/docs/nodes-and-clients/nodes-as-a-service/) را مطالعه کنید.
-
-اگر شخصی یک گره اتریوم را با یک API عمومی در انجمن شما اجرا می کند، می توانید کیف پول های خود را از طریق RPC سفارشی به یک گره انجمن هدایت کنید و از حریم خصوصی بیشتری نسبت به شخص ثالث مورد اعتماد تصادفی برخوردار شوید.
-
-از طرف دیگر، اگر کلاینت را اجرا میکنید، میتوانید آن را با دوستان خود که ممکن است به آن نیاز داشته باشند به اشتراک بگذارید.
-
-## کلاینتهای اجرا {#execution-clients}
-
-جامعهی اتریوم چندین کلاینت اجرای منبعباز (که قبلاً به عنوان «کلاینتهای Eth1» یا صرفاً «کلاینتهای اتریوم» شناخته میشدند) را نگهداری میکند که توسط تیمهای مختلف با استفاده از زبانهای برنامه نویسی مختلف توسعه یافتهاند. این شبکه را قویتر و [متنوعتر](/developers/docs/nodes-and-clients/client-diversity/) میکند. هدف ایدهآل، دستیابی به تنوع بدون تسلط هیچ کلاینتی برای کاهش هر نقطهی شکستی است.
-
-این جدول، اطلاعات کلاینتهای مختلف را بهطور خلاصه نشان میدهد. همهی آنها در [آزمایشهای کلاینت](https://github.com/ethereum/tests) قبول شدهاند و بهطور فعال نگهداری میشوند تا با ارتقاهای شبکه همگام بمانند.
-
-| کلاینت | زبان | سیستمعامل | شبکهها | راهبرد همگامسازی | هرس کردن وضعیت |
-| ------------------------------------------------------------------------ | ---------- | ----------------------- | --------------------------- | -------------------------------------------------------------- | ----------------------- |
-| [Geth](https://geth.ethereum.org/) | Go | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [Snap](#snap-sync), [Full](#full-sync) | آرشیو، هرسشده (Pruned) |
-| [Nethermind](https://www.nethermind.io/) | C#, .NET | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [Snap](#snap-sync) (without serving), Fast, [Full](#full-sync) | آرشیو، هرسشده (Pruned) |
-| [Besu](https://besu.hyperledger.org/en/stable/) | جاوا | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [فوری](#snap-sync), [سریع](#fast-sync), [پر](#full-sync) | آرشیو، هرسشده (Pruned) |
-| [Erigon](https://github.com/ledgerwatch/erigon) | Go | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [کامل](#full-sync) | آرشیو، هرسشده (Pruned) |
-| [Reth](https://reth.rs/) | Rust | لینوکس، ویندوز، مکاواس | شبکه اصلی، Sepolia, Holesky | [کامل](#full-sync) | آرشیو، هرسشده (Pruned) |
-| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | لینوکس، ویندوز، مکاواس | Sepolia, Holesky | [کامل](#full-sync) | Pruned |
-
-جهت کسب اطلاعات بیشتر دربارهی شبکههای پشتیبانیشده [شبکههای اتریوم](/developers/docs/networks/) را بخوانید.
-
-هر کلاینت دارای موارد استفاده و مزایای منحصربهفردی است، بنابراین شما باید یکی را بر اساس ترجیحات خود انتخاب کنید. تنوع اجازه میدهد تا پیادهسازیها بر روی ویژگیهای مختلف و مخاطبان کاربر متمرکز شوند. ممکن است بخواهید کلاینت را بر اساس ویژگیها، پشتیبانی، زبان برنامهنویسی یا مجوزها انتخاب کنید.
-
-### Besu {#besu}
-
-هایپرلجر Besu یک کلاینت اتریوم در ردهی سازمانی برای شبکههای عمومی و مجوزدار است. این کلاینت تمام ویژگیهای اصلی اتریوم، از ردیابی گرفته تا GraphQL را اجرا میکند، نظارت گستردهای دارد و توسط ConsenSys، هم در کانالهای جامعه باز و هم از طریق SLAهای تجاری برای شرکتها، پشتیبانی میشود. این کلاینت به زبان جاوا نوشته شده است و دارای مجوز Apache 2.0 است.
-
-[اسناد](https://besu.hyperledger.org/en/stable/) گسترده Besu شما را در تمام جزئیات مربوط به ویژگیها و تنظیمات آن راهنمایی میکند.
-
-### Erigon {#erigon}
-
-Erigon که قبلاً به عنوان Turbo-Geth شناخته می شد، به عنوان یک فورک Go Ethereum با جهت گیری سرعت و کارایی فضای دیسک شروع به کار کرد. Erigon یک نرمافزار کاملاً بازسازیشده از اتریوم است که در حال حاضر با زبان Go نوشته شده است اما نرمافزارهایی به زبانهای دیگر در دست توسعه دارد. هدف Erigon ارائهی پیادهسازی سریعتر، ماژولارتر و بهینهتر اتریوم است. میتواند با استفاده از حدود 2 ترابایت فضای دیسک، در کمتر از 3 روز، همگامسازی گره آرشیو کامل را انجام دهد.
-
-### Go Ethereum {#geth}
-
-Go Ethereum (به طور خلاصه geth) یکی از پیادهسازیهای اصلی برای پروتکل اتریوم است. در حال حاضر، geth رایجترین کلاینت با بزرگترین پایگاه کاربران و ابزارهای متنوع برای کاربران و توسعهدهندگان است. این کلاینت به زبان Go نوشته شده است، کاملاً منبعباز است و مجوز آن تحت GNU LGPL v3 است.
-
-درباره Geth در [اسناد](https://geth.ethereum.org/docs/) آن بیشتر بیاموزید.
-
-### Nethermind {#nethermind}
-
-Nethermind یک نرمافزار اتریومی است که با پشته فناوری C#.NET، دارای مجوز LGPL-3.0 است که بر روی تمام پلتفرمهای اصلی از جمله ARM اجرا میشود. این پیادهسازی در رابطه با موارد زیر، کارکردی عالی دارد:
-
-- یک ماشین مجازی بهینه
-- دسترسی به حالت
-- شبکه و ویژگیهای غنی مانند داشبوردهای Prometheus/Grafana، پشتیبانی از گزارش سازمانی seq، ردیابی JSON-RPC، و افزونههای تجزیه و تحلیل.
-
-Nethermind همچنین [مستندات مشروح](https://docs.nethermind.io)، پشتیبانی توسعهی قوی، یک جامعهی آنلاین و پشتیبانی 24 ساعته در 7 روز هفته برای کاربران پرمیوم دارد.
-
-### Reth {#reth}
-
-Reth (مخفف Rust Ethereum) یک پیادهسازی گره کامل اتریوم است که بر کاربرپسند بودن، بسیار ماژولار، سریع و کارآمد تمرکز دارد. Reth در اصل توسط Paradigm ساخته و به جلو هدایت شد و تحت مجوز Apache و MIT مجوز دارد.
-
-Reth آماده تولید است و برای استفاده در محیطهای حیاتی مانند سرویسها یا سرویسهای با زمان بالا مناسب است. در موارد استفاده که عملکرد بالا با حاشیه های زیاد مورد نیاز است مانند RPC، MEV، ایندکسینگ، شبیه سازی و فعالیت های P2P، عملکرد خوبی دارد.
-
-با بررسی [Reth Book](https://reth.rs/) یا [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) بیشتر بیاموزید.
-
-### در حال توسعه {#execution-in-development}
-
-این کلاینتها هنوز در مراحل اولیه توسعه هستند و هنوز برای استفاده در تولید توصیه نمی شوند.
-
-#### EthereumJS {#ethereumjs}
-
-کلاینت اجرای EthereumJS (EthereumJS) با TypeScript نوشته شده است و متشکل از تعدادی بسته، از جمله هسته های اولیه اتریوم که توسط کلاس های Block، Transaction و Merkle-Patricia Trie و اجزای اصلی مشتری شامل پیادهسازی ماشین مجازی اتریوم (EVM)، کلاس بلاکچین و پشته شبکه DevP2P ارائه می شود.
-
-با خواندن [اسناد](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) در مورد آن بیشتر بیاموزید
-
-## کلاینتهای اجماع {#consensus-clients}
-
-چندین کلاینت اجماع (که قبلاً بهعنوان کلاینتهای «Eth2» شناخته میشدند) وجود دارد که از [ارتقاهای اجماع](/roadmap/beacon-chain/) پشتیبانی میکنند. آنها مسئول همه منطق مربوط به اجماع از جمله الگوریتم انتخاب فورک، پردازش گواهیها و مدیریت پاداشها و مجازاتهای [اثبات سهام](/developers/docs/consensus-mechanisms/pos) هستند.
-
-| کلاینت | زبان | سیستمعامل | شبکهها |
-| ------------------------------------------------------------- | ---------- | ----------------------- | --------------------------------------------------------------- |
-| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Pyrmont, Sepolia, Ropsten، و غیره |
-| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Sepolia, Ropsten، و غیره |
-| [Nimbus](https://nimbus.team/) | Nim | لینوکس، ویندوز، مکاواس | Beacon Chain, Goerli, Sepolia, Ropsten، و غیره |
-| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | لینوکس، ویندوز، مکاواس | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten، و غیره |
-| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | جاوا | لینوکس، ویندوز، مکاواس | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten، و غیره |
-
-### Lighthouse {#lighthouse}
-
-Lighthouse یک زیرساخت کلاینت اجماع است که با زبان Rust تحت مجوز Apache-2.0 نوشته شده است. توسط Sigma Prime نگهداری می شود و از زمان پیدایش Beacon Chain پایدار و آماده تولید بوده است. شرکت های مختلف، استخرهای سهامگذاری و افراد به آن متکی هستند. هدف آن این است که در محیطهای مختلف، از رایانههای شخصی رومیزی گرفته تا پیادهسازیهای خودکار پیچیده، ایمن و کارآمد و قابل اجرا باشد.
-
-اسناد را می توان در [کتاب Lighthouse](https://lighthouse-book.sigmaprime.io/) پیدا کرد
-
-### Lodestar {#lodestar}
-
-Lodestar یک زیرساخت کلاینت اجرا آماده تولید است که با زبان Typescript تحت مجوز LGPL-3.0 نوشته شده است. این سیستم توسط ChainSafe Systems نگهداری می شود و جدیدترین کلاینت اجماع برای سهامگذاران انفرادی، توسعه دهندگان و محققین است. Lodestar متشکل از یک Beacon Node و کلاینت اعتبارسنج است که توسط زیرساخت جاوا اسکریپت پروتکلهای اتریوم پشتیبانی می شود. هدف Lodestar بهبود قابلیت استفاده اتریوم با کلاینتهای سبک، گسترش دسترسی به گروه بزرگتری از توسعه دهندگان و کمک بیشتر به تنوع اکوسیستم است.
-
-اطلاعات بیشتر را می توانید در [وب سایت Lodestar](https://lodestar.chainsafe.io/) ما بیابید
-
-### Nimbus {#nimbus}
-
-Nimbus یک زیرساخت کلاینت اجماع است که با زبان Nim تحت مجوز Apache-2.0 نوشته شده است. این یک کلاینت آماده تولید است که توسط سهامگذاران انفرادی و استخرهای سهامگذاری استفاده می شود. Nimbus برای بهره وری از منابع طراحی شده است، و اجرای آن را بر روی دستگاه های دارای محدودیت منابع و زیرساخت های سازمانی با سهولت یکسان، بدون به خطر انداختن ثبات یا عملکرد پاداش آسان می کند. ردپای منبع سبکتر به این معنی است که کلاینت دارای حاشیه ایمنی بیشتری در زمانی که شبکه تحت استرس است باشد.
-
-در [اسناد Nimbus](https://nimbus.guide/) بیشتر بیاموزید
-
-### Prysm {#prysm}
-
-Prysm یک کلاینت اجماع با امکانات کامل و منبع باز است که با زبان Go تحت مجوز GPL-3.0 نوشته شده است. دارای یک رابط کاربری وب اپلیکیشن اختیاری است و تجربه کاربر، اسناد و قابلیت پیکربندی را هم برای کاربران شرکتی و هم برای کاربران سازمانی در اولویت قرار می دهد.
-
-برای اطلاعات بیشتر به [اسناد Prysm](https://docs.prylabs.network/docs/getting-started/) مراجعه کنید.
-
-### Teku {#teku}
-
-Teku یکی از کلاینت های اصلی Beacon Chain Genesis است. در کنار اهداف معمول (امنیت، استحکام، پایداری، قابلیت استفاده، عملکرد)، Teku به طور خاص به دنبال مطابقت کامل با استانداردهای مختلف کلاینت اجماع است.
-
-Teku گزینه های استقرار بسیار انعطاف پذیری را ارائه می دهد. گره beacon و کلاینت اعتبارسنج را می توان با هم به عنوان یک فرآیند واحد اجرا کرد که برای سهامگذاران انفرادی بسیار راحت است، یا گره ها را می توان به طور جداگانه برای عملیات های پیچیده ای اجرا کرد. علاوه بر این، Teku به طور کامل با [Web3Signer](https://github.com/ConsenSys/web3signer/) برای امضای امنیت کلید و حفاظت از جریمه قابل استفاده است.
-
-Teku به زبان جاوا نوشته شده و دارای مجوز آپاچی 2.0 است. این کلاینت توسط تیم Protocols در ConsenSys که مسئولیت Besu و Web3Signer را نیز بر عهده دارد، توسعه یافته است. در [اسناد Teku](https://docs.teku.consensys.net/en/latest/) بیشتر بیاموزید.
-
-## حالات همگامسازی {#sync-modes}
-
-برای پیگیری و تأیید دادههای جاری در شبکه، کلاینت اتریوم باید با آخرین حالت شبکه همگام شود. این کار با بارگیری کردن دادهها از همتایان، تأیید رمزنگاری یکپارچگی آنها و ایجاد یک پایگاه دادهی محلی زنجیرهی بلوکی انجام میشود.
-
-حالتهای همگامسازی رویکردهای متفاوتی را برای این فرایند با بدهبستانهای مختلف نشان میدهند. کلاینتها همچنین در پیادهسازیهای الگوریتمهای همگامسازی تفاوت دارند. برای اطلاع از جزئیات پیادهسازی، همیشه به مستندات رسمی کلاینت انتخابی خود مراجعه کنید.
-
-### حالتهای همگامسازی لایه اجرا {#execution-layer-sync-modes}
-
-لایه اجرا ممکن است در حالتهای مختلف اجرا شود تا با موارد استفاده متفاوت مطابقت داشته باشد، از اجرای مجدد حالت سراسریبلاکچین گرفته تا فقط همگامسازی با نوک زنجیره از یک نقطه بازرسی قابل اعتماد.
-
-#### همگامسازی کامل {#full-sync}
-
-یک همگامسازی کامل همه بلوکها (از جمله سرصفحهها و بدنههای بلوک) را دانلود میکند و با اجرای هر بلوک از زمان بلوک جنسیس، حالت بلاکچین را بهصورت تدریجی بازسازی میکند.
-
-- اعتماد را به حداقل میرساند و با تأیید هر تراکنش، بالاترین امنیت را ارائه میدهد.
-- ٰبا افزایش تعداد تراکنشها، پردازش همه تراکنشها ممکن است روزها تا هفتهها طول بکشد.
-
-[گرههای آرشیو](#archive-node) یک همگامسازی کامل را برای ایجاد (و حفظ) تاریخچه کاملی از تغییرات حالت ایجاد شده توسط هر تراکنش در هر بلوک انجام میدهند.
-
-#### همگامسازی سریع {#fast-sync}
-
-همانند یک همگامسازی کامل، یک همگامسازی سریع همه بلوکها (از جمله سرصفحهها، تراکنشها و رسیدها) را دانلود میکند. با این حال، بهجای پردازش مجدد تراکنشهای تاریخی، یک همگامسازی سریع هنگامی که به وضعیت وارد کردن و پردازش کردن بلوکها تغییر مییابد تا یک فول نود را تهیه کند، تا زمانی که به سررسید اخیر برسد، به رسیدها متکی است.
-
-- استراتژی همگامسازی سریع.
-- تقاضای پردازش را به نفع استفاده از پهنای باند کاهش می دهد.
-
-#### همگامسازی فوری {#snap-sync}
-
-همگامسازیهای سریع نیز زنجیره را بلوک به بلوک تأیید میکنند. با این حال، به جای شروع از بلوک جنسیس، یک همگامسازی فوری در یک نقطه بازرسی جدیدتر «معتمد» که به عنوان بخشی از بلاکچین واقعی شناخته شده است، شروع می شود. گره در حین حذف داده های قدیمی تر از سن معین، نقاط بازرسی دوره ای را ذخیره می کند. این اسنپشاتها برای بازسازی دادههای حالت در صورت نیاز به جای ذخیرهسازی برای همیشه استفاده میشوند.
-
-- سریعترین استراتژی همگام سازی، در حال حاضر به طور پیش فرض در شبکه اصلی اتریوم.
-- صرفهجویی در مصرف حافظه و پهنای باند شبکه بدون به خطر انداختن امنیت.
-
-[جزئیات بیشتر همگامسازی سریع](https://github.com/ethereum/devp2p/blob/master/caps/snap.md).
-
-#### همگامسازی سبک {#light-sync}
-
-حالت کلاینت سبک همهی هدرهای بلوک و دادههای بلوک را بارگیری میکند و برخی را بهطور تصادفی تأیید میکند. فقط نوک زنجیره را از نقاط بررسی مطمئن همگامسازی میکند.
-
-- با تکیه بر اعتماد به توسعهدهندگان و مکانیزم اجماع، تنها آخرین وضعیت را دریافت میکند.
-- کلاینت ظرف چند دقیقه با وضعیت فعلی شبکه آماده استفاده است.
-
-**نکته** همگامسازی سبک هنوز با اتریوم اثبات سهام کار نمیکند - نسخههای جدید همگامسازی سبک به زودی عرضه میشوند!
-
-[بیشتر در مورد کلاینت های سبک](/developers/docs/nodes-and-clients/light-clients/)
-
-### حالتهای همگامسازی لایه اجماع {#consensus-layer-sync-modes}
-
-#### همگامسازی خوشبینانه {#optimistic-sync}
-
-همگامسازی خوشبینانه یک استراتژی همگامسازی پس از ارتقاء مرج است که بهمنظور سازگاری با انتخاب و عقبنشینی طراحی شده است و به گرههای اجرا اجازه میدهد از طریق روشهای تعیینشده همگام شوند. موتور اجرا می تواند _بهطور خوشبینانه_ بلوک های بیکن را بدون تأیید کامل آنها وارد کند، آخرین هد را پیدا کند و سپس شروع به همگام سازی زنجیره با روش های بالا کند. سپس، پس از اینکه کلاینت اجرا به نتیجه رسید، اعتبار تراکنشهای موجود در زنجیره بیکن را به کلاینت اجماع اطلاع میدهد.
-
-[حزئیات بیشتر همگامسازی خوشبینانه](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md)
-
-#### همگامسازی نقطه بازرسی {#checkpoint-sync}
-
-همگامسازی نقطه بازرسی، که به عنوان همگامسازی ذهنی ضعیف نیز شناخته میشود، تجربه کاربری برتری را برای همگامسازی Beacon Node ایجاد میکند. این مبتنی بر فرضیات [فردیت ضعیف](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) است که امکان همگام سازی زنجیره بیکن از یک نقطه بازرسی ذهنی ضعیف اخیر را به جای جنسیس فراهم می کند. همگامسازیهای نقطه بازرسی با مفروضات اعتماد مشابهی مانند همگامسازی از زمان بلوک [جنسیس](/glossary/#genesis-block)، زمان همگامسازی اولیه را به میزان قابل توجهی سریعتر میکند.
-
-در عمل، این بدان معناست که گره شما به یک سرویس راه دور متصل می شود تا حالت های نهایی را بارگیری کند و به تأیید داده ها از آن نقطه ادامه می دهد. شخص ثالثی که داده ها را ارائه می دهد مورد اعتماد است و باید با دقت انتخاب شود.
-
-جزئیات بیشتر [همگامسازی نقطه بازرسی](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)
-
-## بیشتر بخوانید {#further-reading}
-
-- [اتریوم مقدماتی - بخش دوم - فهم گرهها](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _- ویل بارنز، 13 فوریه 2019_
-- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جاستین لروکس، 7 نوامبر 2019_
-
-## موضوعات مرتبط {#related-topics}
-
-- [بلوکها](/developers/docs/blocks/)
-- [شبکهها](/developers/docs/networks/)
-
-## آموزشهای مرتبط {#related-tutorials}
-
-- [Raspberry Pi 4 خود را فقط با اتصال کارت MicroSD به یک گره اعتبارسنج تبدیل کنید – راهنمای نصب](/developers/tutorials/run-node-raspberry-pi/) _– Raspberry Pi 4 خود را فلش کنید، یک کابل اترنت به آن وصل کنید، دیسک SSD را وصل کنید و دستگاه را روشن کنید تا Raspberry Pi 4 را به یک گره کامل اتریوم که لایه اجرا (شبکهی اصلی) و / یا لایه اجماع (زنجیرهی بیکن / اعتبارسنج) را اجرا میکند، تبدیل کنید._
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
deleted file mode 100644
index bc48499e54c..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md"
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: کاربرهای رقیق
-description: مقدمهای بر کاربر سبک اتریوم.
-lang: fa
----
-
-اجرای گره کامل روشی خصوصی، مقاوم به سانسور و غیر متمرکز برای تعامل با شبکۀ اتریوم است. با داشتن یک گره کامل در واقع نسخۀ خود از بلاک چین را خواهید داشت که میتوانید از طریق آن به شبکۀ همتا به همتای اتریوم دسترسی مستقیم داشته باشید و در لحظه از آن پرس و جو کنید. به هر حال، اجرای گره کامل نیازمند مقادیر قابل توجه از منابع محاسباتی مانند حافظه، فضای ذخیرهسازی و قدرت پردازش است. بنابراین هر کس در شبکه نمیتواند گره خود را اجرا کند. در نقشۀ راه اتریوم چندین راهحل برای این مسئله وجود دارد برای مثال بیوضعیت بودن یکی از این راهحلهاست که البته چندین سال با اجرای آن فاصله داریم. برای آیندهای نزدیک، چارهای جز فدا کردنِ برخی از مزایای گره کامل در برابر بهبود کارکردی نداریم، این راهکار به افراد اجازه میدهد با الزامات سختافزاری حداقلی بتوانند گرههایی اجرا کنند. گرههایی که این کار را میکنند گره سبک نام دارند.
-
-## کاربر سبک چیست؟ {#what-is-a-light-client}
-
-گره سبک گرهای است که نرمافزار کاربر سبک را اجرا میکند. به جای نگهداری از نسخه های محلی از زنجیرهی بلوکی و تائید مستقل همه تغییرات، در عوض آنها داده های لازم را از بعضی از ارائه دهندگان درخواست می کنند. ارائه دهنده ممکن است به گره کامل دسترسی مستقیم، یا طریق یک سرور RPC متمرکز شده، داشته باشد. پس از آن داده توسط گره سیک تائید می شود، که اجازه می دهد با سر یا راس زنجیره همگام شود. در واقع گره سبک فقط سرتیتر بلوکها را پردازش و نگهداری میکند و فقط در شرایط خاصی محتوای کامل یک بلوک را دانلود میکند. گرهها بسته به ترکیب نرمافزار سَبُکی و کاربر کاملی که اجرا میکنند، میتوانند از نظر سَبُکی متفاوت باشند. برای مثال، سبکترین پیکربندی شامل اجرای یک کاربر اجرای سبک و یک کاربر اجماع سبک خواهد بود. همچنین ممکن است بسیاری از گرهها بخواهند یک گره کامل در لایه اجرا و یک گره سبک در لایه اجماع یا بالعکس باشند.
-
-## کاربرهای سبک چگونه کار میکنند؟ {#how-do-light-clients-work}
-
-زمانی که شبکه اتریوم شروع به استفاده از مکانیزم اجماع اثبات سهام کرد، زیرساخت جدیدی مخصوص پشتیبانی از کاربرهای سبک معرفی شد. این سیستم با انتخاب تصادفی یک زیرمجموعه از دستههای متشکل از 512 گره اعتبارسنج در هر 1.1 ثانیه کار میکند که به عنوان یک **کمیتۀ همگامسازی** عمل میکند. این کمیته همگامسازی، سرتیتر بلوکهای جدید را امضا میکند. سرتیتر هر بلوک شامل امضای تجمیعی اعتبارسنجهای کمیته همگامسازی و نیز یک bifield است که نشان میدهد کدام اعتبارسنجها امضا کرده و کدام یک امضا نکردهاند. به علاوه در سرتیتر بلوک یک لیست اعتبارسنجهایی وجود دارد که انتظار میرود د امضای بلوک بعدی شرکت کنند. در نتیجه یک گره سبک به سرعت میتواند تایید کمیته اعتبارسنج و همچنین اصالت کمیته را بررسی کند، آنها این کار را با مقایسۀ دادههای دریافتی با دادۀ مورد انتظارشان در بلاک قبلی انجام میدهند. از این طریق، گره سبک میتواند بدون دانلود زنجیرۀ کامل اتریوم و تنها با استفاده از سرتیترها، خود را با آخرین وضعیت بلاک چین همگام کند.
-
-در لایۀ اجرا هیچ مشخصات دقیقی برای گرههای سبک وجود ندارد. گره سبک در لایۀ اجرا میتواند یک «حالت سبک» از گره کامل باشد که مشابه با آن دارای تمام قابلیتهای شبکه و ماشین مجازی اتریوم است اما تنها سرتیتر بلاکها را بدون دانلود آنها تایید میکند، یا ممکن است یک کلاینت خلاصهتر باشد که برای تعامل خود با شبکه اتریوم به درخواستهای RPC ارسالی به یک سرور خارجی متکی است.
-
-## چرا گرههای سبک مهم هستند؟ {#why-are-light-clients-important}
-
-گره سبک از این منظر اهمیت دارد که به کاربران امکان میدهد به جای اعتماد کورکورانه به خدمات یک اپراتور واسطه، دادههای ورودی را با تنها کسر کوچکی از منابع محاسباتی یک گره کامل تایید کنند. گرههای سبک میتوانند درستی دادههای دریافتی را با سرتیتر بلاکها که میدانند توسط حداقل دو سومِ مجموعهای تصادفی از 512 اعتبارسنج اتریوم امضا شدهاند، کنترل کنند. این میتواند مدرکی قوی از صحت دادهها باشد.
-
-اجرای یک گره سبک فقط به مقدار کمی قدرت محاسباتی، حافظه و فضای ذخیرهسازی نیاز دارد، بنابراین با یک دستگاه موبایل و از طریق اپلیکیشن یا افزونه مرورگر میتوان به یک گره سبک در شبکه تبدیل شد. در واقع گره سبک روشی بینیاز از اعتماد برای دسترسی به اتریوم است که به همان اندازۀ وابستگی به طرف یک واسطه یا اپراتور خارجی، بدون زحمت و آسان است.
-
-یک مثال ساده را میتوان برای روشن شدن موضوع در نظر گرفت. فرض کنید میخواهیم آخرین موجودی آدرس خود را چک کنیم. برای این کار باید درخواستی را به یک گره کامل اتریوم ارسال کنیم. گره کامل پس از بررسی نسخۀ محلی خود از وضعیت اتریوم میتواند موجودی حساب را به شما اعلام کند. به هر حال، بسیاری از کاربران دسترسی مستقیم به یک گره کامل ندارند و باید از اپراتورهای متمرکز که این خدمات را ارائه میدهند، استفاده کنند. درخواست به آنها ارسال میشود و نتیجه به شما باز میگردد. یک مشکل جدی وجود دارد، باید به آن اپراتور خارجی و صحت دادههایش اعتماد کنید. تا خودتان به عنوان یک گره آنها را تایید نکنید، هرگز راهی وجود ندارد تا از صحت اطلاعات به طور کامل مطمئن شوید.
-
-گره سبک این مشکل را رفع میکند. البته لازم به ذکر است که همچنان دادهها باید از یک اپراتور خارجی درخواست شوند اما وقتی دادهها دریافت شد، گره سبک میتواند صحت آنها را با اطلاعات موجود در سرتیتر بلاکها کنترل کند، در این صورت است که میتوان از درستی دادهها اطمینان داشت. در واقع، اینجا، به جای یک اپراتور مورد اعتماد، خودِ شبکۀ اتریوم است که درستی دادهها را تایید میکند.
-
-## با گره سبک چه ابداعاتی ممکن میشوند؟ {#what-innovations-do-light-clients-enable}
-
-توانمندسازی افراد در دسترسی به شبکۀ اتریوم به صورت مستقل و با سطحی حداقلی از الزامات سختافزاری و اتکا به واسطهها، مزیت اصلی گره سبک است. این برای کاربران سودمند است زیرا میتوانند دادهها را خود تایید کنند و برای شبکه خوب است چون تعداد و تنوع گرههای مشارکتکننده در تایید بلاکها را افزایش میدهد.
-
-توانایی در اجرای گره اتریوم روی دستگاههایی با فضای ذخیره، حافظه و قدرت پردازش محدود، اصلیترین زمینۀ نوآوریهای بعدی است که به واسطۀ راهحل گره سبک شکوفا خواهند شد. در حالی که گرههای اتریوم در حال حاضر نیاز به مقدار قابل توجهی منابع محاسباتی دارند، گره سبک میتواند در مرورگرها تعبیه شود، روی دستگاه موبایل یا حتی دستگاههای کوچکتر مثل ساعت هوشمند اجرا شود. این بدان معناست که کیف پولهای اتریوم با کلاینتهای تعبیهشده میتوانند روی تلفن همراه اجرا شوند. بنابراین کیف پولهای موبایل میتوانند بیشتر از این غیر متمرکز شوند زیرا نیازی به دادههای تامینکنندگان متمرکز ندارند.
-
-فراتر از این، نوآوری گره سبک به **پیادهسازی فناوری اینترنت اشیا (IoT)** کمک میکند. یک گره سبک میتواند به سرعت مالکیت یک توکن یا NFT را تایید کند و فعالیتهایی را در شبکۀ اینترنت اشیا انجام دهد. یک [سرویس کرایۀ دوچرخه](https://youtu.be/ZHNrAXf3RDE?t=929) را در نظر بگیرید که با اجرای یک گره سبک به سرعت میتواند توکن NFT مربوط به سرویس دوچرخه را تایید کند و قفل دوچرخه را برای استفادۀ کاربر باز کند!
-
-رولآپهای اتریوم نیز میتوانند از گرههای سبک بهرهمند شوند. یکی از مشکلات اساسی آنها حملات هکری به پلتفرمهای پل است که برای انتقال داراییها از شبکۀ اصلی اتریوم به یک رولآپ استفاده میشوند. آسیبپذیری اصلی در اراکل بروز میکند که برای اطلاع از واریز شدنِ وجوه کاربر در پلتفرم پل، توسط رولآپ استفاده میشوند. اگر یک اراکل دادههای غلط بفرستد میتواند رولآپ را متقاعد کند که وجوه کاربر به پلتفرم پل فرستاده شدهاند و موجب شود وجوهی را به اشتباه آزاد کند. اجرای گره سبک در یک رولآپ میتواند در برابر اراکل مخرب ایستادگی کند زیرا واریز وجوه به پلتفرم پل توسط خودِ رولآپ تایید میشود. همین مفهوم میتواند برای سایر پلتفرمهای پل بینرنجیرهای نیز صادق باشد.
-
-گرههای سبک همچنین به ارتقای کیف پولهای اتریوم کمک میکنند. به جای اعتماد به دادههای یک اپراتور خارجی، کیف پول شما میتواند با استفاده از یک گره سبک دادهها را به صورت مستقیم تایید کند. این موضوع به افزایش امنیت کیف پولهای اتریوم میانجامد. اگر اپراتور خارجی، متقلب باشد و دادههای نادرست در اختیارتان بگذارد، گره سبک به شما خواهد گفت!
-
-## وضعیت فعلی پیشرفت گره سبک چگونه است؟ {#current-state-of-development}
-
-اکنون چندین نوع گره سبک در حال توسعه هستند که گرههای اجرای سبک، گرههای اجماع سبک یا ترکیبی از این دو هستند. اینها مثالهایی از پیادهسازی گره سبک هستند که تا زمان نوشتن این صفحه وجود دارند:
-
-- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): گره سبک اجماع در زبان TypeScript
-- [Helios](https://github.com/a16z/helios): گره سبک ترکیبی اجماع و اجرا در زبان Rust
-- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): گره سبک اجرا در زبان Go
-- [Nimbus](https://nimbus.guide/el-light-client.html): گره سبک اجماع در زبان Nim
-
-تا آنجا که میدانیم هیچ کدام از این موارد هنوز تولید نهایی نیستند.
-
-همچنین تلاش زیادی لازم است تا راههای دسترسی گرههای سبک به دادههای شبکۀ اتریوم بهبود داده شوند. در حال حاضر، فناوری گره سبک به درخواستهای RPC از گرههای کامل که از مدل سرور/ کلاینت استفاده میکنند، متکی است، اما در آینده، دادهها میتوانند به روشی غیرمتمرکز با استفاده از شبکههای اختصاصی مانند [Portal Network](https://www.ethportal.net/) درخواست شوند که دادههای گره سبک را با استفاده از پروتکل گاسیپ فرد به فرد تامین میکنند.
-
-سایر موارد موجود در [نقشۀ راه اتریوم](/roadmap/) مانند [درخت ورکل](/roadmap/verkle-trees/) و [بیوضعیت بودن](/roadmap/statelessness/) در نهایت میتوانند امنیت گرههای سبک را به امنیت یک گره کامل برسانند.
-
-## بیشتر بخوانید {#further-reading}
-
-- [Zsolt Felfodhi در کلاینتهای Geth light](https://www.youtube.com/watch?v=EPZeFXau-RE)
-- [Etan Kissling در شبکههای کلاینتهای سبک](https://www.youtube.com/watch?v=85MeiMA4dD8)
-- [Etan Kissling درباره کلاینتهای سبک بعد از ادغام](https://www.youtube.com/watch?v=ZHNrAXf3RDE)
-- [Piper Merriam: جاده پر پیچ و خم به سمت مشتریان سبک کاربردی](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
deleted file mode 100644
index d98b0f7bc75..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md"
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: معماری گره
-description: مقدمهای درباره نحوه سازماندهی گرههای اتریوم.
-lang: fa
----
-
-یک گره اتریوم از دو کاربر تشکیل شده است: یک [کاربر اجرا](/developers/docs/nodes-and-clients/#execution-clients) و یک [کاربر اجماع](/developers/docs/nodes-and-clients/#consensus-clients).
-
-زمانی که اتریوم از [مکانیسم اثبات کار](/developers/docs/consensus-mechanisms/pow/) استفاده میکرد، یک کاربر اجرا برای اجرای یک گره کامل اتریوم کافی بود. اما، از زمان اجرای [مکانیسم اثبات سهام](/developers/docs/consensus-mechanisms/pow/)، کاربر اجرا میبایست در کنار نرمافزار دیگری به نام [کاربر اجماع ](/developers/docs/nodes-and-clients/#consensus-clients) استفاده شود.
-
-نمودار زیر رابطۀ بین دو کاربر اتریوم را نشان میدهد. هر یک از این دو کاربر به شبکههای همتا به همتای (P2P) مخصوص خود متصل میشوند. دلیل نیاز به شبکههای همتا به همتای جداگانه این است که: کاربرهای اجرا تراکنشها را از طریق شبکۀ همتا به همتای خود شایعه میکنند که آنها را قادر میسازد استخر تراکنشهای محلی خود را مدیریت کنند، در حالی که کاربرهای اجماع، بلوکها را از طریق شبکۀ همتا به همتا شایعه میکنند، که امکان اجماع و رشد زنجیره را فراهم میکند.
-
-![](node-architecture-text-background.png)
-
-برای اینکه این ساختار دوکاربری بتواند کار کند، کاربرهای اجماع باید دستهای از تراکنشها را به کاربر اجرا منتقل کنند. اجرای تراکنشها به صورت محلی اینگونه است که کاربر تایید میکند تراکنشها هیچ یک از قوانین اتریوم را نقض نمیکنند و بهروزرسانی پیشنهادی برای حالت اتریوم صحیح است. به همین ترتیب، هنگامی که گره به عنوان تولیدکنندۀ بلوک برگزیده میشود، کاربر اجماع باید بتواند دستهای از تراکنشها را از Geth درخواست کند تا در بلوک جدید گنجانده شود و آنها را برای بهروزرسانی حالت کل شبکه اجرا کند. این ارتباط بینِ کاربری توسط یک اتصال RPC محلی با استفاده از [موتور API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) اداره میشود.
-
-## کاربر اجرا چه میکند؟ {#execution-client}
-
-کاربر اجرا مسئول رسیدگی به تراکنش، شایعه تراکنش، مدیریت حالت و پشتیبانی از ماشین مجازی اتریوم ([EVM](/developers/docs/evm/)) است. ولی مسئولیتی در قبال ساخت بلوک، شایعه بلوک یا مدیریت منطق اجماع **ندارد**. این موارد، در حیطۀ اختیارات کاربر اجماع است.
-
-کاربر اجرا، پیلودهای اجرا را ایجاد میکند که شامل فهرست تراکنشها، آزمایش حالت بهروزشده و سایر دادههای مربوط به اجرا میشود. کاربرهای اجماع شامل پیلود اجرا در هر بلوک است. کاربر اجرا همچنین مسئول اجرای مجدد تراکنشها در بلوکهای جدید به منظور اطمینان از معتبر بودن آنها است. اجرای تراکنشها بر روی کامپیوتر تعبیهشدۀ کاربر اجرا به نام [ماشین مجازی اتریوم (EVM)](/developers/docs/evm) انجام میشود.
-
-کاربر اجرا همچنین از طریق [روشهای RPC](/developers/docs/apis/json-rpc) یک رابط کاربری برای اتریوم فراهم میکند که کاربران را قادر میسازد از بلاکچین اتریوم درخواست اطلاعات کنند، تراکنشها را ارسال کنند و قراردادهای هوشمند را به شیوهای مؤثر به کار گیرند. معمولا تماسهای RPC توسط کتابخانهای مانند [Web3js](https://docs.web3js.org/) یا [Web3py](https://web3py.readthedocs.io/en/v5/) یا یک رابط کاربری مانند کیف پول مرورگر انجام میشود.
-
-به طور خلاصه، کاربر اجرا عبارت است از:
-
-- یک دروازۀ کاربری به اتریوم
-- خانۀ ماشین مجازی اتریوم، استخر تراکنش و حالت اتریوم.
-
-## کاربر اجماع چه میکند؟ {#consensus-client}
-
-کاربر اجماع با تمام منطقی سر و کار دارد که یک گره را قادر میسازد با شبکۀ اتریوم همگام بماند. این موارد شامل دریافت بلوکها از همتایان و اجرای یک الگوریتم انتخاب فورک است تا اطمینان حاصل شود گره همواره زنجیرهای با بیشترین انباشت گواه را دنبال میکند (وزندهیشده توسط ترازهای مؤثر اعتبارسنج). مشابه کاربر اجرا، کاربرهای اجماع نیز شبکۀ همتا به همتای خود را دارند که از طریق آن بلوکها و تصدیقها را به اشتراک میگذارند.
-
-کاربر اجماع در تایید یا پیشنهاد بلوکها شرکت نمیکند - این کار توسط یک اعتبارسنج انجام میشود که یک افزونۀ اختیاری برای کاربر اجماع محسوب میشود. یک کاربر اجماع بدون یک اعتبارسنج تنها با سر زنجیره همگام میشود و به گره اجازۀ همگامسازی میدهد. این امر به کاربران امکان میدهد با استفاده از کاربر اجرای خود با اتریوم تراکنش کنند با این اطمینان که در زنجیرۀ صحیح قرار دارند.
-
-## اعتبارسنج ها {#validators}
-
-اپراتورهای گره میتوانند با واریز 32 اتریوم در قرارداد سپرده، یک اعتبارسنج را به کاربر اجماع خود اضافه کنند. کاربر اعتبارسنج با کاربر اجماع همبسته است و میتواند در هر زمان به یک گره اضافه شود. اعتبارسنج، تصدیقها و پیشنهادهای بلوک را مدیریت میکند. آنها یک گره را قادر میسازند تا از طریق جریمه یا اسلشینگ به جمعآوری پاداش بپردازد یا ETH از دست بدهد. اجرای نرمافزار اعتبارسنج همچنین باعث انتخاب یک گره واجد شرایط برای پیشنهاد یک بلوک جدید میشود.
-
-[در مورد سهام گذاری بیشتر بخوانید](/staking/).
-
-## مقایسۀ اجزای گره {#node-comparison}
-
-| کاربر اجرا | کاربر اجماع | اعتبارسنج |
-| --------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------ |
-| تراکنشهای را از طریق شبکۀ همتا به همتای خود شایعه میکند | از طریق شبکۀ همتا به همتای خود، بلوکها و تصدیقها را شایعه میکند | بلوکها را پیشنهاد میکند |
-| تراکنشها را اجرا/ بازاجرا میکند | الگوریتم انتخاب فورک را اجرا میکند | پاداشها/جریمهها را میگیرد |
-| تغییرات حالت ورودی را تایید میکند | سر زنجیره را پیگیری میکند | تصدیقها را میسازد |
-| تلاشهای حالت و رسیدها را مدیریت میکند | حالت بیکن را مدیریت میکند (شامل اطلاعات اجماع و اجرا) | برای سهام گذاری شدن به 32 اتریوم نیاز دارد |
-| پیلود اجرا را ایجاد میکند | تصادفی بودن انباشتهشده در RANDAO را ردیابی میکند | قابل اسلش شدن است |
-| JSON-RPC API را برای تعامل با اتریوم در معرض قرار میدهد | توجیه و نهایی شدن را پیگیری میکند | |
-
-## بیشتر بخوانید {#further-reading}
-
-- [اثبات سهام](/developers/docs/consensus-mechanisms/pos)
-- [پیشنهاد بلوک](/developers/docs/consensus-mechanisms/pos/block-proposal)
-- [پاداشها و جریمههای اعتبارسنج](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
deleted file mode 100644
index 603008296b5..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md"
+++ /dev/null
@@ -1,419 +0,0 @@
----
-title: گرهها بهعنوان سرویس
-description: مرور کلی خدمات گره، مزایا و معایب آنها و ارائهدهندگان محبوب برای تازهواردان.
-lang: fa
-sidebarDepth: 2
----
-
-## مقدمه {#Introduction}
-
-اجرای [گره اتریوم](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) میتواند چالش برانگیز باشد، به خصوص زمانی که به سرعت شروع میشود یا هنگامی که به سرعت مقیاسپذیر میشود. [سرویسهای متعددی](#popular-node-services) وجود دارند که زیرساختهای گرهی بهینهسازیشدهای را برای شما اجرا میکنند، بنابراین میتوانید به جای آن بر توسعهی برنامه یا محصول خود تمرکز کنید. ما نحوهی عملکرد سرویسهای گره، مزایا و معایب استفاده از آنها را توضیح میدهیم و در صورت تمایل به شروع، ارائهدهندگان آنها را فهرست خواهیم کرد.
-
-## پیشنیازها {#prerequisites}
-
-اگر از قبل درک درستی از گرهها و کلاینتها ندارید، به [گرهها و کلاینتها](/developers/docs/nodes-and-clients/) مراجعه کنید.
-
-## سهام گذاران {#stakoooooooooooooors}
-
-سهامداران انفرادی به جای اتکا به ارائه دهندگان شخص ثالث، باید زیرساخت خود را اجرا کنند. این به معنای اجرای یک کلاینت اجرا همراه با یک کلاینت اجماع است. قبل از [ادغام](/roadmap/merge)، این امکان وجود داشت که فقط یک کلاینت اجماع اجرا شود و از یک ارائه دهنده متمرکز برای داده های اجرا استفاده شود. این دیگر امکانپذیر نیست - یک سهام گذار انفرادی باید هر دو مشتری را اجرا کند. با این حال، خدماتی برای تسهیل این فرآیند وجود دارد.
-
-[در مورد اجرای یک گره بیشتر بخوانید](/developers/docs/nodes-and-clients/run-a-node/).
-
-خدماتی که در این صفحه توضیح داده شده است برای گره های بدون شرط بندی است.
-
-## سرویسهای گره چگونه کار میکنند؟ {#how-do-node-services-work}
-
-ارائهدهندگان خدمات گره، کلاینتهای گره توزیع شده را در پشتصحنه برای شما اجرا میکنند، بنابراین نیازی ندارید که خودتان آنها را انجام دهید.
-
-این سرویسها معمولاً یک کلید API ارائه میکنند که میتوانید از آن برای نوشتن و خواندن از زنجیرهی بلوکی استفاده کنید. آنها اغلب علاوه بر شبکهی اصلی به [شبکههای تست اتریوم](/developers/docs/networks/#ethereum-testnets) نیز دسترسی دارند.
-
-برخی از سرویسها، گره اختصاصی خودشان را به شما ارائه میدهند و آنها را برای شما مدیریت میکنند، در حالی که برخی دیگر از متعادلکنندههای بار برای توزیع فعالیت در گرهها استفاده میکنند.
-
-ادغام با اغلب سرویسهای گره بهشدت آسان است، که معمولاً شامل یک خط تغییر در کد خود برای تعویض گرهی که خودتان میزبانی میکنید یا حتی جابجایی آنها بین خودشان میشود.
-
-سرویسهای گره اغلب [کلاینتهای گره](/developers/docs/nodes-and-clients/#execution-clients) و [انواع گره](/developers/docs/nodes-and-clients/#node-types) گوناگونی را اجرا میکنند که به شما این امکان را میدهد علاوه بر روشهای خاص کلاینت در یک API به گرههای کامل و بایگانیشده نیز دسترسی داشته باشید.
-
-خاطرنشان میشود که سرویسهای گرهْ کلیدهای خصوصی یا اطلاعات شما را نباید و نمیتوانند ذخیره کنند.
-
-## مزایای استفاده از یک سرویس گره چیست؟ {#benefits-of-using-a-node-service}
-
-مزیت اصلی استفاده از سرویس گره این است که نیازی به صرف زمان مهندسی برای نگهداری و مدیریت گرهها ندارید. این کار به شما امکان میدهد بهجای نگرانی در مورد تعمیر و نگهداری زیرساخت، روی ساخت محصول خود تمرکز کنید.
-
-اجرای گرههای شخصی شما از ذخیرهسازی تا پهنای باند و زمان مهندسی ارزشمند شما، میتواند بسیار هزینهبر باشد. مواردی مانند چرخش تعداد بیشتری گره هنگام مقیاسبندی، ارتقای گرهها به آخرین نسخهها و اطمینان از ثبات وضعیت، میتواند حواس را از ساختن و صرف منابع روی محصول Web3 موردنظر شما منحرف کند.
-
-## معایب استفاده از یک سرویس گره چیست؟ {#cons-of-using-a-node-service}
-
-با استفاده از یک سرویس گره، وضعیت زیرساختی محصول خود را متمرکز میکنید. به همین دلیل، پروژههایی که در آنها تمرکززدایی از اهمیت بالایی برخوردار است، ممکن است گرههای خود میزبان را به برونسپاری به طرف ثالث ترجیح دهند.
-
-درباره [مزایای اجرای گره خودتان](/developers/docs/nodes-and-clients/#benefits-to-you) بیشتر بخوانید.
-
-## سرویسهای گره محبوب {#popular-node-services}
-
-در اینجا فهرستی از محبوب ترین ارائهدهندگان گره اتریوم آورده شده است، بهراحتی میتوانید مواردی که درج نشدهاند را اضافه کنید! هر سرویس گره علاوه بر سطوح رایگان یا پولی، مزایا و ویژگیهای مختلفی را ارائه میکند، شما باید قبل از تصمیمگیری، بررسی کنید که کدامیک به بهترین شکل با نیازهای شما مطابقت دارند.
-
-- [**شیمی**](https://alchemy.com/)
- - [مستندات](https://docs.alchemyapi.io/)
- - ویژگیها
- - دارای بزرگترین سطح کاربری رایگان با 300 میلیون واحد محاسباتی در ماه (حدود 30 میلیون درخواست getLatestBlock)
- - پشتیبانی چند زنجیرهای برای Polygon، Starknet، Optimism، Arbitrum
- - قدرتبخشی به حدود 70% بزرگترین dappهای اتریوم و حجم تراکنش دیفای
- - هشدارهای قلابهای وب لحظهای از طریق Alchemy Notify
- - بهترین پشتیبانی و اطمینانپذیری / ثبات در این سطح
- - NFT API متعلق به Alchemy
- - داشبورد با Request Explorer، Mempool Watcher و Composer
- - دسترسی به فاست شبکهی تست یکپارچه
- - انجمن سازنده Active Discord با 18 هزار کاربر
-
-- [**همه آن نود**](https://allthatnode.com/)
- - [مستندات](https://docs.allthatnode.com/)
- - ویژگیها
- - 50000 درخواست در روز با ردیف آزاد
- - پشتیبانی از بیش از 40 پروتکل
- - از JSON-RPC (EVM, Tendermint) و REST و APIهای وبسوکت پشتیبانی میشود
- - دسترسی نامحدود به داده های آرشیو
- - پشتیبانی فنی 24/7 و آپتایم 99.9 درصد
- - فاست در چند زنجیر موجود است
- - دسترسی نامحدود به اندپوینت با تعداد نامحدود کلیدهای API
- - پشتیبانی از ردیابی/دیباگ API
- - بهروزرسانیهای خودکار
-
-- [**بلاک چین مدیریت شده آمازون**](https://aws.amazon.com/managed-blockchain/)
- - [مستندات](https://aws.amazon.com/managed-blockchain/resources/)
- - ویژگیها
- - گره های کاملاً مدیریت شده اتریوم
- - موجود در شش منطقه جغرافیایی
- - JSON-RPC از طریق HTTP و WebSocket های امن
- - پشتیبانی از 3 زنجیره
- - SLAها، پشتیبانی 24/7 از AWS
- - Go-ethereum و Lighthouse
-
-- [**Ankr**](https://www.ankr.com/)
- - [مستندات](https://docs.ankr.com/)
- - ویژگیها
- - پروتکل Ankr - دسترسی به نقاط پایانی وب سرویس RPC عمومی را برای بیش از 8 زنجیره باز میکند
- - تعادل بار و نظارت بر سلامت گره برای یک گذرگاه سریع و قابلاعتماد به نزدیکترین گره موجود
- - سطح ممتاز که نقطه پایانی WSS و محدودیت نرخ بدون سقف را فعال میکند
- - استقرار گره کامل و اعتبارسنج با یک کلیک برای بیش از 40 زنجیره
- - مقیاسپذیری دلخواه
- - ابزارهای تحلیل
- - داشبورد
- - نقاط پایانی RPC، HTTPS و WSS
- - پشتیبانی مستقیم
-
-- [**انفجار**](https://blastapi.io/)
- - [مستندات](https://docs.blastapi.io/)
- - ویژگیها
- - پشتیبانی RPC و WSS
- - میزبانی از گره در چندین منطقه
- - زیرساخت غیرمتمرکز
- - API عمومی
- - طرح رایگان اختصاصی
- - پشتیبانی از چند زنجیره (بیش از 17 بلاکچین)
- - نودهای آرشیوی
- - پشتیبانی 24/7 در Discord
- - مانیتورینگ و هشداردهی 24/7
- - SLA کلی در سطح 99.9 درصد
- - پرداخت با رمزارز
-
-- [**BlockDaemon**](https://blockdaemon.com/)
- - [مستندات](https://ubiquity.docs.blockdaemon.com/)
- - مزایا
- - داشبورد
- - بر اساس پایه گره
- - تجزیه و تحلیل
-
-- [**BlockPI**](https://blockpi.io/)
- - [مستندات](https://docs.blockpi.io/)
- - ویژگیها
- - قوی & ساختار گره توزیع شده
- - حداکثر 40 نقطه پایانی HTTPS و WSS
- - بسته ثبتنام رایگان و بسته ماهانه
- - روش ردیابی + پشتیبانی از دادههای آرشیو
- - بستهها تا 90 روز اعتبار دارند
- - برنامهریزی سفارشی و پرداخت دلخواه
- - پرداخت با رمزارز
- - پشتیبانی مستقیم & پشتیبانی فنی
-
-- [**Chainbase**](https://www.chainbase.com/)
- - [مستندات](https://docs.chainbase.com)
- - ویژگیها
- - سرویس RPC بسیار در دسترس، سریع و مقیاسپذیر
- - پشتیبانی از چندزنجیره
- - تعرفههای رایگان
- - داشبورد کاربرپسند
- - خدمات داده بلاک چین را فراتر از RPC ارائه میدهد
-
-- [**Chainstack**](https://chainstack.com/)
- - [مستندات](https://docs.chainstack.com/)
- - ویژگیها
- - گرههای اشتراکی رایگان
- - گرههای اشتراکی آرشیو
- - پشتیبانی از GraphQL
- - نقاط پایانی RPC و WSS
- - گرههای کامل و بایگانی اختصاصی
- - همگامسازی سریع برای استقرار اختصاصی
- - اتصال به سرویسهای ابری خود
- - هزینهی ساعتی
- - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
-
-- [**DataHub**](https://datahub.figment.io)
- - [اسناد](https://docs.figment.io/)
- - ویژگیها
- - گزینهی سطح کاربری رایگان با 3,000,000 درخواست در ماه
- - نقاط پایانی RPC و WSS
- - گرههای کامل و بایگانی اختصاصی
- - مقیاسبندی خودکار (تخفیف حجمی)
- - دادههای بایگانیشدهی رایگان
- - تجزیه و تحلیل سرویس
- - داشبورد
- - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
- - پرداخت با رمزارز (سازمانی)
-
-- [**DRPC**](https://drpc.org/)
- - [مستندات](https://docs.drpc.org/)
- - ویژگیها
- - گرههای RPC غیرمتمرکز
- - بیش از 15 ارائه دهنده گره
- - تعادل گره
- - واحدهای محاسباتی نامحدود ماهانه به صورت رایگان
- - تایید دادهها
- - نقاط پایانی سفارشی
- - نقاط پایانی HTTP و WSS
- - کلیدهای نامحدود (ردیف رایگان و پولی)
- - گزینههای بازگشتی یا فالبک انعطافپذیر
- - [نقطه پایانی عمومی](https://eth.drpc.org)
- - گرههای بایگانیشدهی اشتراکی رایگان
-
-- [**GetBlock**](https://getblock.io/)
- - [مستندات](https://getblock.io/docs/get-started/authentication-with-api-key/)
- - ویژگیها
- - دسترسی به بیش از 40 گره زنجیره بلوکی
- - 40 هزار درخواست رایگان روزانه
- - کلیدهای API نامحدود
- - سرعت اتصال بالا به میزان 1 گیگابایت بر ثانیه
- - ردیابی+آرشیو
- - تجزیه و تحلیل پیشرفته
- - بهروزرسانیهای خودکار
- - پشتیبانی فنی
-
-- [**InfStones**](https://infstones.com/)
- - ویژگیها
- - گزینه ردیف رایگان
- - مقیاسپذیری دلخواه
- - تجزیه و تحلیل
- - داشبورد
- - نقاط پایانی منحصربهفرد API
- - گرههای کامل اختصاصی
- - همگامسازی سریع برای استقرار اختصاصی
- - پشتیبانی مستقیم شبانهروزی در تمام ایام هفته
- - دسترسی به بیش از 50 گره زنجیره بلوکی
-
-- [**Infura**](https://infura.io/)
- - [مستندات](https://infura.io/docs)
- - ویژگیها
- - گزینه ردیف رایگان
- - مقیاسپذیری دلخواه
- - دادههای بایگانیشدهی پولی
- - پشتیبانی مستقیم
- - داشبورد
-
-- [**Kaleido**](https://kaleido.io/)
- - [مستندات](https://docs.kaleido.io/)
- - ویژگیها
- - ردیف رایگان برای شروع کار
- - استقرار گره اتریوم با یک کلیک
- - کلاینتها و الگوریتمهای قابل تنظیم (Geth، Quorum و Besu || PoA، IBFT و Raft)
- - بیش از 500 API اداری و خدماتی
- - رابط RESTful برای ارسال تراکنش اتریوم (با پشتیبانی Apache Kafka)
- - جریانهای خروجی برای ارائه رویداد (با پشتیبانی Apache Kafka)
- - مجموعهای عمیق از خدمات «خارج زنجیره» و فرعی (مانند حملونقل پیامهای رمزگذاریشدهی دوجانبه)
- - نصب راحت و سریع روی شبکه با کنترل دسترسی مبتنی بر نقش و حاکمیت
- - مدیریت پیشرفتهی کاربر هم برای مدیران و هم برای کاربران نهایی
- - زیرساخت بسیار مقیاس پذیر، تابآورتر و در سطح سازمانی
- - مدیریت کلید خصوصی Cloud HSM
- - اتصال شبکهی اصلی اتریوم
- - گواهینامههای ISO 27k و SOC 2، نوع 2
- - پیکربندی پویای زمان اجرا (بهعنوان مثال افزودن ادغامهای ابری، تغییر ورودی گرهها و غیره)
- - پشتیبانی از ارکستراسیونهای چند ابری، چند منطقهای و ترکیبی استقرار
- - قیمتگذاری ساعتی ساده مبتنی بر SaaS
- - SLAها و پشتیبانی شبانهروزی در تمام ایام هفته
-
-- [**شبکه لاوا (Lava)**](https://www.lavanet.xyz/)
- - [مستندات](https://docs.lavanet.xyz/)
- - ویژگیها
- - استفاده رایگان از شبکهی تست
- - افزونگی غیرمتمرکز برای آپ تایم بالا
- - متن باز
- - SDK کاملا غیرمتمرکز
- - ادغام Ethers.js
- - رابط مدیریت پروژه بصری
- - یکپارچگی داده مبتنی بر اجماع
- - پشتیبانی چند زنجیرهای یا مالتی چین
-
-- [**Moralis**](https://moralis.io/)
- - [مستندات](https://docs.moralis.io/)
- - ویژگیها
- - گرههای اشتراکی رایگان
- - گرههای بایگانیشدهی اشتراکی رایگان
- - تمرکز بر حفظ حریم خصوصی (سیاست عدم حفظ سوابق کار)
- - پشتیبانی از زنجیرهی متقاطع
- - مقیاسپذیری دلخواه
- - داشبورد
- - SDK اتریوم منحصربهفرد
- - نقاط پایانی منحصربهفرد API
- - پشتیبانی فنی مستقیم
-
-- [**مگانود نودرئال**](https://nodereal.io/)
- - [مستندات](https://docs.nodereal.io/nodereal/meganode/introduction)
- - ویژگیها
- - خدمات RPC ایپیآی قابل اعتماد، سریع و مقیاسپذیر
- - API پیشرفته برای توسعهدهندگان Web3
- - پشتیبانی از چندزنجیره
- - شروع به استفاده به صورت رایگان
-
-- [**NOWNodes**](https://nownodes.io/)
- - [اسناد](https://documenter.getpostman.com/view/13630829/TVmFkLwy)
- - ویژگیها
- - دسترسی به بیش از 50 گره زنجیره بلوکی
- - کلید API رایگان
- - جستجوگرهای بلوک
- - زمان پاسخ API ⩽ 1 ثانیه
- - تیم پشتیبانی شبانهروزی در تمام ایام هفته
- - مدیر حسابهای شخصی
- - گرههای مشترک، بایگانیشده، پشتیبانی و اختصاصی
-
-- [**شبکهی Pocket**](https://www.pokt.network/)
- - [اسناد](https://docs.pokt.network/home/)
- - ویژگیها
- - پروتکل و بازار RPC غیرمتمرکز
- - 1 میلیون درخواست در روز در سطح رایگان (به ازای هر نقطهی پایانی، حداکثر 2)
- - [نقاط پایانی عمومی](https://docs.pokt.network/developers/public-endpoints)
- - برنامهی +Pre-Stake (در صورت نیاز به بیش از 1 میلیون درخواست در روز)
- - پشتیبانی از بیش از 15 زنجیرهی بلوکی
- - بیش از 6400 گره که برای خدمترسانی به برنامههای کاربردی POKT کسب میکنند
- - گرهی بایگانیشده، گرهی بایگانیشده با ردیابی و پشتیبانی از گرهی شبکهی تست
- - تنوع در کلاینت گره شبکهی اصلی اتریوم
- - هیچ نقطهی شکستی وجود ندارد
- - زمان خاموشی صفر
- - اقتصاد توکنی نزدیک به صفر و مقرونبهصرفه (برای پهنای باند شبکه، یک بار POKT را سهامگذاری کنید)
- - بدون هزینههای ماهانه، زیرساختهای خود را به یک دارایی تبدیل کنید
- - تعادل بار در پروتکل تعبیه شده است
- - تعداد درخواستها در روز و تعداد گرهها را در هر ساعت بهطور بینهایت مقیاسپذیر کنید
- - خصوصیترین و مقاومترین گزینه در برابر سانسور
- - پشتیبانی عملی از توسعهدهندگان
- - داشبورد و تجزیه و تحلیل [پورتال Pocket](https://bit.ly/ETHorg_POKTportal)
-
-- [**QuickNode**](https://www.quicknode.com)
- - [اسناد](https://www.quicknode.com/docs/)
- - ویژگیها
- - پشتیبانی فنی شبانهروزی در تمام ایام هفته و جامعه توسعهدهندگان در Discord
- - شبکهای دارای تعادل جغرافیایی، چند ابری/فلزی، با تأخیر کم
- - پشتیبانی چند زنجیرهای (Optimism، Arbitrum، Polygon + 11 مورد دیگر)
- - لایههای میانی برای سرعت و پایداری (مسیریابی تماس، حافظهی پنهان، نمایهسازی)
- - نظارت بر قرارداد هوشمند از طریق Webhooks
- - داشبورد بصری، بستهی تجزیه و تحلیل، نویسندهی RPC
- - ویژگیهای امنیتی پیشرفته (JWY، ماسک کردن، قرار دادن در فهرست سفید)
- - API دادهها و تجزیه و تحلیل NFT
- - [دارای گواهینامه SOC2](https://www.quicknode.com/security)
- - مناسب برای اشخاص مختلف، از توسعهدهندگان گرفته تا سازمانها
-
-- [**Rivet**](https://rivet.cloud/)
- - [اسناد](https://rivet.readthedocs.io/en/latest/)
- - ویژگیها
- - گزینه ردیف رایگان
- - مقیاسپذیری دلخواه
-
-- [**SenseiNode**](https://senseinode.com)
- - [اسناد](https://docs.senseinode.com/)
- - ویژگیها
- - گرههای اختصاصی و اشتراکی
- - داشبورد
- - میزبانی خاموش AWS در چندین ارائه دهنده میزبانی در مکان های مختلف در آمریکای لاتین
- - کلاینتهای Prysm و Lighthouse
-
-- [**SettleMint**](https://console.settlemint.com/)
- - [اسناد](https://docs.settlemint.com/)
- - ویژگیها
- - دورهی آزمایشی رایگان
- - مقیاسپذیری دلخواه
- - پشتیبانی از GraphQL
- - نقاط پایانی RPC و WSS
- - گرههای کامل اختصاصی
- - اتصال به سرویسهای ابری خود
- - ابزارهای تحلیل
- - داشبورد
- - هزینهی ساعتی
- - پشتیبانی مستقیم
-
-- [**Tenderly**](https://tenderly.co/web3-gateway)
- - [اسناد](https://docs.tenderly.co/web3-gateway/web3-gateway)
- - ویژگیها
- - بخش رایگان شامل 25 میلیون واحد مناقصه در ماه
- - دسترسی رایگان به دادههای تاریخی
- - خوانایی بخشهای سنگین تا 8 برابر سریعتر
- - دسترسی به خواندن 100٪ ثابت
- - نقاط پایانی JSON-RPC
- - سازنده درخواست RPC و پیش نمایش درخواست مبتنی بر رابط کاربری
- - کاملاً با ابزارهای توسعه، اشکالزدایی یا دیباگ کردن و تست تندرلی یکپارچه شده است
- - شبیهسازی تراکنشها
- - تجزیه و تحلیل و فیلتر کردن استفاده
- - دسترسی آسان به مدیریت کلید
- - پشتیبانی مهندسی اختصاصی از طریق چت، ایمیل و دیسکورد
-
-- [**توکن ویو**](https://services.tokenview.io/)
- - [اسناد](https://services.tokenview.io/docs?type=nodeService)
- - ویژگیها
- - پشتیبانی فنی شبانهروزی در تمام ایام هفته & و جامعه توسعهدهندگان در Telegram
- - پشتیبانی از چند زنجیره (بیت کوین، اتریوم، ترون، زنجیره هوشمند بایننس، اتریوم کلاسیک)
- - هر دو نقطه پایانی RPC و WSS برای استفاده باز هستند
- - دسترسی نامحدود به داده های آرشیو API
- - داشبورد با Request Explorer و Mempool Watcher
- - ایپیآی دیتا انافتی (NFT data API) و Webhook اطلاع رسانی میکنند
- - پرداخت با رمزارز
- - پشتیبانی خارجی برای الزامات رفتاری اضافی
-
-- [**Watchdata**](https://watchdata.io/)
- - [اسناد](https://docs.watchdata.io/)
- - ویژگیها
- - اطمینانپذیری دادهها
- - اتصال بدون وقفه بدون توقف
- - خودکارسازی فرایند
- - تعرفههای رایگان
- - سقف بالا برای امکانات گوناگون که برای هر کاربری مناسب است
- - پشتیبانی از گرههای مختلف
- - مقیاسپذیری منابع
- - سرعت پردازش بالا
-
-- [**ZMOK**](https://zmok.io/)
- - [اسناد](https://docs.zmok.io/)
- - ویژگیها
- - پیشدستی بهعنوان سرویس
- - استخر حافظهی معاملات جهانی با روشهای جستجو/فیلتر
- - هزینهی TX نامحدود و گاز بینهایت برای ارسال تراکنشها
- - دریافت بلوک جدید و خواندن زنجیرهی بلوکی به سریعترین شکل ممکن
- - تضمین بهترین قیمت برای هر فراخوانی API
-
-- [**Zeeve**](https://www.zeeve.io/)
- - [اسناد](https://www.zeeve.io/docs/)
- - ویژگیها
- - پلتفرم اتوماسیون بدون کد درجه سازمانی که استقرار، نظارت و مدیریت گره ها و شبکه های بلاکچین را ارائه می دهد
- - بیش از 30 پروتکل پشتیبانی شده & یکپارچهسازی، و افزودن موارد دیگر
- - خدمات زیرساخت Web3 با ارزش افزوده مانند ذخیرهسازی غیرمتمرکز، هویت غیرمتمرکز و APIهای داده دفتر کل بلاکچین برای موارد استفاده در دنیای واقعی
- - پشتیبانی 24 ساعته و نظارت فعال، سلامت گره ها را همیشه تضمین می کند.
- - نقاط پایانی RPC اقدام به ارائه دسترسی تأیید شده به API ها، مدیریت بدون دردسر با داشبورد و تجزیه و تحلیل بصری میکنند.
- - هم سرویس ابری مدیریت شده را ارائه می دهد و هم گزینه های ابری خود را برای انتخاب می آورد و از همه ارائه دهندگان ابر اصلی مانند AWS و Azure و Google Cloud و Digital Ocean و سرویس محلی پشتیبانی میکند.
- - ما هر بار از مسیریابی هوشمند برای رسیدن به نزدیکترین گره به کاربر شما استفاده می کنیم
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [فهرست خدمات گرهی اتریوم](https://ethereumnodes.com/)
-
-## موضوعات مرتبط {#related-topics}
-
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
-
-## آموزشهای مرتبط {#related-tutorials}
-
-- [شروع توسعهی اتریوم با استفاده از Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/)
-- [راهنمای ارسال تراکنشها با استفاده از web3 و Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
diff --git "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" "b/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
deleted file mode 100644
index f01d54b0da4..00000000000
--- "a/public/content/translations/fa/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md"
+++ /dev/null
@@ -1,480 +0,0 @@
----
-title: چرخاندن گرهی اتریوم خودتان
-description: مقدمهای عمومی بر اجرای نمونهی خودتان از کلاینت اتریوم.
-lang: fa
-sidebarDepth: 2
----
-
-اجرای گرهی خودتان مزایای متنوعی برای شما دارد، امکانات جدیدی را در اختیارتان قرار میدهد و به پشتیبانی از اکوسیستم کمک میکند. این صفحه شما را برای چرخاندن گرهی خودتان و ایفای نقش برای اعتبارسنجی تراکنشهای اتریوم راهنمایی میکند.
-
-توجه داشته باشید که پس از [ادغام](/roadmap/merge)، دو کلاینت برای اجرای یک گره اتریوم مورد نیاز است. یک کلاینت **لایه اجرا (EL)** و یک سرویس گیرنده **لایه اجماع (CL)**. این صفحه، نحوه نصب، پیکربندی و اتصال این دو کلاینت برای اجرای یک گره اتریوم را نشان می دهد.
-
-## پیشنیازها {#prerequisites}
-
-شما باید بدانید که گرهی اتریوم چیست و چرا ممکن است بخواهید یک کلاینت را اجرا کنید. این موضوع در [گرهها و کلاینتها](/developers/docs/nodes-and-clients/) بررسی شده است.
-
-اگر موضوع اجرای یک گره برایتان تازه است یا به دنبال راهی هستید که کمتر فنی باشد، توصیه میکنیم ابتدا به مقدمهی کاربرپسند ما دربارهی [اجرای یک گرهی اتریوم](/run-a-node) نگاهی بیاندازید.
-
-## انتخاب یک رویکرد {#choosing-approach}
-
-اولین گام برای چرخاندن گرهی خودتان، انتخاب رویکردتان است. بر اساس الزامات و احتمالات مختلف، شما باید پیاده سازی کلاینت (هم از کلاینتهای اجرا و هم اجماع)، محیط (سخت افزار، سیستم) و پارامترهای تنظیمات کلاینت را انتخاب کنید.
-
-این صفحه شما را از طریق این تصمیمات راهنمایی می کند و به شما کمک می کند تا مناسب ترین راه را برای اجرای نمونه اتریوم خود پیدا کنید.
-
-برای انتخاب از بین پیادهسازیهای کلاینت، همه [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients)، [کلاینتهای اجماع](/developers/docs/nodes-and-clients/#consensus-clients) آماده در شبکه اصلی را ببینید و درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity) اطلاعات کسب کنید.
-
-با در نظر گرفتن [نیازهای](#requirements) کلاینتها، تصمیم بگیرید که آیا نرم افزار را روی [سخت افزار خود یا در فضای ابری](#local-vs-cloud) اجرا کنید.
-
-پس از آمادهسازی محیط، کلاینت های انتخابی را با [رابط مناسب برای مبتدیان](#automatized-setup) یا [به صورت دستی](#manual-setup) با استفاده از ترمینال با گزینه های پیشرفته نصب کنید.
-
-هنگامی که گره در حال اجرا و همگام سازی است، شما آماده [استفاده از آن](#using-the-node) هستید، اما مطمئن شوید که مراقب [نگهداری](#operating-the-node) آن هستید.
-
-![نصب کلاینت](./diagram.png)
-
-### محیط زیست و سختافزار {#environment-and-hardware}
-
-#### محلی یا ابری {#local-vs-cloud}
-
-کلاینتهای اتریوم میتوانند روی رایانههای درجه مصرفکننده کار کنند و به سختافزار خاصی مانند ماشینهای استخراج نیاز ندارند. بنابراین، شما گزینه های مختلفی برای استقرار گره بر اساس نیاز خود دارید. برای سادهسازی، بیایید اجرای یک گره را هم در یک ماشین فیزیکی محلی و هم در یک سرور ابری بررسی کنیم:
-
-- ابر
- - ارائهدهندگانْ زمان بهکار (uptime) سرور بالا و آدرسهای آیپی (IP) عمومی ثابت ارائه میدهند
- - گرفتن سرور اختصاصی یا مجازی ممکن است راحتتر از ساختن سرور شخصی باشد
- - بدهبستان بر سر این است که به یک شخص ثالث - ارائهدهدهی سرور اعتماد کنیم
- - به دلیل اندازهی حافظهی لازم برای گرهی کامل، هزینهی اجارهی سرور ممکن است بالا باشد
-- سختافزار شخصی
- - رویکرد بیاعتمادتر و حاکمیتیتر
- - سرمایهگذاری برای یک بار
- - امکان خرید ماشینهای پیشپیکربندیشده
- - شما باید بهطور فیزیکی دستگاه و شبکه را آماده، نگهداری و احتمالاً عیبیابی کنید
-
-هر دو گزینه مزایای متفاوتی دارند که در بالا خلاصه شده است. اگر به دنبال راهحل ابری هستید، علاوه بر بسیاری از ارائهدهندگان سنتی پردازش ابری، سرویسهایی هم وجود دارند که بر روی بهکارگیری گرهها تمرکز دارند. برای گزینه های بیشتر در مورد گره های میزبان، [گره ها را به عنوان یک سرویس](/developers/docs/nodes-and-clients/nodes-as-a-service/) بررسی کنید.
-
-#### سختافزار {#hardware}
-
-با این حال، یک شبکهی غیرمتمرکز و مقاوم در برابر سانسور نباید بر ارائهدهندگان ابری متکی باشد. در عوض، اجرای گره تان بر روی سختافزار محلی خودتان برای اکوسیستم سالم تر است. [تخمینها](https://www.ethernodes.org/networkType/Hosting) سهم بزرگی از گرههای اجرا شده روی ابر را نشان میدهد که میتواند به یک نقطه شکست تبدیل شود.
-
-کلاینت های اتریوم می توانند بر روی کامپیوتر، لپ تاپ، سرور یا حتی یک کامپیوتر تک برد شما اجرا شوند. در حالی که اجرای کلاینت ها بر روی رایانه شخصی شما امکانپذیر است، داشتن یک ماشین اختصاصی فقط برای گره می تواند عملکرد و امنیت آن را به میزان قابل توجهی افزایش دهد و در عین حال تأثیر آن را بر روی رایانه اصلی شما به حداقل برساند.
-
-استفاده از سخت افزار خودتان می تواند بسیار آسان باشد. بسیاری از گزینه های ساده و همچنین تنظیمات پیشرفته برای افراد فنی بیشتر وجود دارد. بنابراین بیایید به الزامات و ابزارهای اجرای کلاینت های اتریوم بر روی دستگاه شما نگاه کنیم.
-
-#### الزامات {#requirements}
-
-نیازهای سختافزاری برای هر کلاینت متفاوت است، اما معمولاً آنقدر زیاد نیست، چون گره فقط باید همگام بماند. آن را با استخراج که به قدرت محاسباتی بسیار بیشتری نیاز دارد، اشتباه نگیرید. با این حال، سختافزار قدرتمندتر زمان همگامسازی و عملکرد را بهبود میبخشد.
-
-پیش از نصب هر کلاینتی مطمئن شوید که رایانهی شما منابع لازم را برای اجرای آن دارد. در زیر می توانید الزامات حداقل و توصیه شده را بیابید.
-
-گلوگاه سخت افزار شما بیشتر فضای دیسک است. همگام سازی بلاکچین اتریوم بسیار فشرده ورودی/خروجی است و به فضای زیادی نیاز دارد. بهتر است یک **حافظه اس اس دی** با صدها گیگابایت فضای خالی حتی پس از همگام سازی داشته باشید.
-
-اندازه پایگاه داده و سرعت همگام سازی اولیه به مشتری انتخابی، پیکربندی و [استراتژی همگام سازی](/developers/docs/nodes-and-clients/#sync-modes) بستگی دارد.
-
-همچنین مطمئن شوید که اتصال اینترنت شما دارای [محدودیت پهنای باند](https://wikipedia.org/wiki/Data_cap) نباشد. توصیه میشود از یک اتصال نامحدود به اینترنت استفاده کنید، چون حجم پهنای لازم برای همگامسازی اولیه و پخش دادهها در شبکه ممکن است از محدودیت حجمی پهنای باند شما بیشتر باشد.
-
-##### سیستمعامل
-
-همهی کلاینتها از سیستمعاملهای اصلی یعنی لینوکس، مکاواس و ویندوز پشتیبانی میکنند. این بدان معناست که میتوانید گرهها را با سیستمعاملی (OS) که برای شما مناسبتر است، روی رایانههای رومیزی یا سرورهای معمولی اجرا کنید. مطمئن شوید که سیستمعامل شما بهروز است تا از مشکلات احتمالی و آسیبپذیریهای امنیتی جلوگیری شود.
-
-##### الزامات حداقلی
-
-- پردازنده با حداقل 2 هسته
-- 8 گیگ رم
-- 2 ترا SSD
-- پهنای باند حداقل 10 مگابیت بر ثانیه
-
-##### مشخصات پیشنهادی
-
-- پردازندهی سریع با حداقل 4 هسته
-- حداقل 16 گیگابایت رم
-- SSD سریع بالای 2 ترا
-- پهنای باند حداقل 25 مگابیت بر ثانیه
-
-حالت همگامسازی و سرویس گیرندهای که انتخاب میکنید بر فضای مورد نیاز تأثیر میگذارند، اما ما فضای دیسک مورد نیاز برای هر مشتری را در زیر تخمین زدهایم.
-
-| کلاینت | اندازه دیسک (همگام سازی فوری) | فضای حافظه (آرشیو کامل) |
-| ---------- | ----------------------------- | ----------------------- |
-| Besu | 800GB+ | 12TB+ |
-| Erigon | شامل نمیشود | 2.5TB+ |
-| Geth | 500GB+ | 12TB+ |
-| Nethermind | 500GB+ | 12TB+ |
-| Reth | شامل نمیشود | 2.2TB+ |
-
-- توجه: Erigon و Reth همگامسازی فوری را ارائه نمیدهند، اما هرس کامل امکانپذیر است (حدود 2 ترا برای Erigon و حدود 1.2 ترا برای Reth)
-
-برای کلاینتهای اجماع، فضای مورد نیاز به پیادهسازی کلاینت و ویژگیهای فعال (مثلاً جریمهکننده اعتبارسنج) نیز بستگی دارد، اما معمولاً با 200 گیگابایت دیگر مورد نیاز برای دادههای بیکن محاسبه میشود. با تعداد زیادی اعتبارسنج، بار پهنای باند نیز افزایش می یابد. میتوانید [جزئیات مربوط به الزامات کلاینت اجماع را در این تحلیل بیابید](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc).
-
-#### راهکارهای عملی {#plug-and-play}
-
-سادهترین گزینه برای اجرای یک گره با سختافزار خود استفاده از جعبه های راهاندازی آسان است. دستگاههای از پیش تنظیم شده توسط فروشندگان سادهترین تجربه را ارائه می دهند: سفارش، اتصال، اجرا. همه چیز از قبل پیکربندی شده است و به طور خودکار با یک راهنمای بصری و داشبورد برای نظارت و کنترل نرمافزار اجرا می شود.
-
-- [DappNode](https://dappnode.io/)
-- [Avado](https://ava.do/)
-
-#### اتریوم روی رایانهی تکبرد {#ethereum-on-a-single-board-computer}
-
-یک راه آسان و ارزان برای اجرای یک گره اتریوم، استفاده از کامپیوتر تک بردی است، حتی با معماری ARM مانند Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) تصاویری با قابلیت اجرا و اجرای چندگانه مشتری را برای رزبری پای و دیگر بردهای ARM فراهم میکند.
-
-دستگاه های کوچک، مقرون به صرفه و کارآمد مانند این ها برای اجرای یک گره در خانه ایده آل هستند، اما عملکرد محدود آنها را در نظر داشته باشید.
-
-## چرخاندن گره {#spinning-up-node}
-
-راهاندازی واقعی کلاینت را میتوان با راهاندازهای خودکار یا به صورت دستی انجام داد و مستقیماً نرمافزار کلاینت را راهاندازی کرد.
-
-برای کاربران نا آشناتر، رویکرد پیشنهادی استفاده از یک لانچر است، نرمافزاری که شما را در نصب راهنمایی میکند و فرآیند راهاندازی کلاینت را خودکار میکند. با این حال، اگر تجربه استفاده از ترمینال را دارید، مراحل تنظیم دستی باید ساده باشد.
-
-### نصب با راهنما {#automatized-setup}
-
-چندین پروژه کاربرپسند قصد بهبود تجربه راهاندازی یک کلاینت را دارند. این لانچرها نصب و پیکربندی خودکار کلاینت را ارائه میکنند و برخی حتی یک رابط گرافیکی برای راهاندازی و نظارت بر کلاینتها ارائه میدهند.
-
-در زیر چند پروژه وجود دارد که می تواند به شما در نصب و کنترل کلاینت ها فقط با چند کلیک کمک کند:
-
-- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - که همراه دستگاه خریداری شده از یک فروشنده ارائه نمی شود. این نرمافزار، راهانداز گره واقعی و مرکز کنترل با ویژگی های بسیار می توانند بر روی سختافزار دلخواه استفاده شوند.
-- [eth-docker](https://eth-docker.net/) - راهاندازی خودکار با استفاده از داکر با تمرکز بر روی استقرار آسان و ایمن، نیاز به دانش پایه و ترمینال داکر دارد که برای کاربران کمی پیشرفتهتر توصیه میشود.
-- [Stereum](https://stereum.net/ethereum-node-setup/) - یک لانچر برای نصب کلاینتها روی سرور راه دور از طریق اتصال SSH با راهنمای راهاندازی رابط کاربری گرافیکی، مرکز کنترل، و بسیاری از ویژگیهای دیگر.
-- [NiceNode](https://www.nicenode.xyz/) - یک لانچر با تجربه کاربری ساده برای اجرای یک گره در رایانه شما. فقط کلاینتها را انتخاب کنید و آنها را با چند کلیک شروع کنید. همچنان تحت توسعه است.
-- [Sedge](https://docs.sedge.nethermind.io/docs/intro) - ابزار تنظیم گره که به طور خودکار یک پیکربندی داکر را با استفاده از ویزارد CLI ایجاد می کند. توسط Nethermind با زبان Go نوشته شده.
-
-### راهنماب دستی نصب کلاینت {#manual-setup}
-
-گزینه دیگر، دانلود، تأیید و پیکربندی نرمافزار کلاینت به صورت دستی است. حتی اگر برخی از کلاینتها یک رابط گرافیکی ارائه دهند، راهاندازی دستی همچنان به مهارت های اولیه با ترمینال نیاز دارد اما تطبیق پذیری بسیار بیشتری را ارائه می دهد.
-
-همانطور که قبلا توضیح داده شد، راهاندازی گره اتریوم خود مستلزم اجرای یک جفت کلاینت اجماع و اجرا است. برخی از کلاینتها ممکن است شامل یک کلاینت سبک از نوع دیگر باشند و بدون نیاز به نرمافزار دیگری همگام شوند. با این حال، تأیید کامل بدون نیاز به شخص ثالث نیاز به هر دو پیادهسازی دارد.
-
-#### دریافت نرمافزار کلاینت {#getting-the-client}
-
-ابتدا، باید نرمافزار [کلاینت اجرا](/developers/docs/nodes-and-clients/#execution-clients) و [کلاینت اجماع](/developers/docs/nodes-and-clients/#consensus-clients) دلخواه خود را بدست آورید.
-
-شما به سادگی می توانید یک برنامه اجرایی یا بسته نصبی را دانلود کنید که مناسب سیستم عامل و معماری شما باشد. همیشه امضاها و checksumهای بسته های دانلود شده را بررسی کنید. برخی از مشتریان همچنین مخازن یا تصاویر داکر را برای نصب و به روز رسانی آسان تر ارائه می دهند. همه کلاینت ها منبع باز هستند، بنابراین می توانید آنها را از سمت منبع نیز بسازید. این روش پیشرفتهتر است، اما در برخی موارد ممکن است نیاز باشد.
-
-دستورالعملهای نصب هر کلاینت در اسنادی که در فهرست کلاینتهای فوقالذکر پیوند داده شدهاند، ارائه شده است.
-
-در اینجا صفحات انتشار کلاینت ها وجود دارد که می توانید باینری های از پیش ساخته شده آنها یا دستورالعمل های نصب را پیدا کنید:
-
-##### کلاینتهای اجرا
-
-- [Besu](https://github.com/hyperledger/besu/releases)
-- [Erigon](https://github.com/ledgerwatch/erigon/releases)
-- [Geth](https://geth.ethereum.org/downloads/)
-- [Nethermind](https://downloads.nethermind.io/)
-- [Reth](https://reth.rs/installation/installation.html)
-
-همچنین شایان ذکر است که تنوع کلاینتها یک [مسئله در لایه اجرا](/developers/docs/nodes-and-clients/client-diversity/#execution-layer) است. توصیه می شود که خوانندگان به اجرای یک نسخه حداقلی از کلاینت اجرا فکر کنند.
-
-##### کلاینتهای اجماع
-
-- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest)
-- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (یک باینری از پیش ساخته شده ارائه نمی دهد، فقط یک تصویر داکر یا باید از منبع ساخته شود)
-- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest)
-- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest)
-- [Teku](https://github.com/ConsenSys/teku/releases)
-
-[تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) برای گره های اجماع که اعتبارسنج را اجرا می کنند بسیار مهم است. اگر اکثر اعتبارسنجها پیادهسازی یک کلاینت واحد را اجرا کنند، امنیت شبکه در خطر است. بنابراین توصیه می شود که یک کلاینت اقلیتی را در نظر بگیرید.
-
-[آخرین استفاده از کلاینت شبکه را ببینید](https://clientdiversity.org/) و درباره [تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity) بیشتر بدانید.
-
-##### تایید نرم افزار
-
-هنگام دانلود نرمافزار از اینترنت، توصیه می شود بینقص بودن آن را بررسی کنید. این مرحله اختیاری است، اما به خصوص در مورد زیرساخت های حیاتی مانند مشتری اتریوم، مهم است که از بردارهای حمله احتمالی آگاه باشید و از آنها اجتناب کنید. اگر یک باینری از پیش ساخته شده دانلود کرده اید، باید به آن اعتماد کنید و خطر این را در نظر بگیرید که مهاجم ممکن است بتواند فایل اجرایی را با یک فایل مخرب تعویض کند.
-
-توسعه دهندگان، باینری های منتشر شده را با کلیدهای PGP خود امضا می کنند تا بتوانید به صورت رمزنگاری تأیید کنید که دقیقاً نرم افزاری را که ایجاد کرده اند اجرا می کنید. شما فقط باید کلیدهای عمومی مورد استفاده توسعه دهندگان را به دست آورید که می توانند در صفحات انتشار کلاینت یا در اسناد یافت شوند. پس از دانلود نسخه کلاینت و امضای آن، می توانید از پیادهسازی PGP استفاده کنید، به عنوان مثال [GnuPG](https://gnupg.org/download/index.html) تا به راحتی آنها را تأیید کنید. آموزش تأیید نرمافزار منبع باز با استفاده از `gpg` در [لینوکس](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) یا [ویندوز/مک](https://freedom.press/training/verifying-open-source-software/) را بررسی کنید.
-
-شکل دیگر تأیید این است که مطمئن شوید هش، اثر انگشت رمزنگاری منحصربهفرد، نرمافزاری که دانلود کردهاید با آنچه توسعهدهندگان ارائه کردهاند مطابقت دارد. این حتی ساده تر از استفاده از PGP است و برخی از کلاینتها فقط این گزینه را ارائه می دهند. فقط تابع هش را روی نرمافزار دانلود شده اجرا کنید و آن را با یکی از صفحه انتشار مقایسه کنید. برای مثال:
-
-```sh
-sha256sum teku-22.6.1.tar.gz
-
-9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde
-```
-
-#### نصب کلاینت {#client-setup}
-
-پس از نصب، دانلود یا کامپایل نرمافزار کلاینت، آماده اجرای آن هستید. این فقط به این معنی است که باید با پیکربندی مناسب اجرا شود. کلاینتها گزینه های پیکربندی خوبی را ارائه می دهند که میتوانند ویژگی های مختلفی را فعال کنند.
-
-بیایید با گزینه هایی شروع کنیم که می توانند به طور قابل توجهی بر عملکرد کلاینت و استفاده از داده تأثیر بگذارند. [حالتهای همگامسازی](/developers/docs/nodes-and-clients/#sync-modes) روشهای مختلف بارگیری و اعتبارسنجی دادههای زنجیرهی بلوکی را نشان میدهند. پیش از آغاز گره، باید تصمیم بگیرید که از کدام شبکه و کدام حالت همگامسازی استفاده نمایید. مهمترین چیزهایی که باید در نظر بگیرید فضای دیسک و زمان همگام سازی مورد نیاز کلاینت است. برای تعیین اینکه کدام حالت همگام سازی پیش فرض است، به اسناد کلاینت توجه کنید. اگر برای شما مناسب نیست، یکی دیگر را بر اساس سطح امنیت، داده های موجود و هزینه انتخاب کنید. به غیر از الگوریتم همگامسازی، میتوانید هرس (pruning) انواع مختلف دادههای قدیمی را نیز تنظیم کنید. هرس امکان حذف دادههای قدیمی را فراهم میکند، بهعنوان مثال حذف گرههای درخت وضعیت که از بلوکهای اخیر غیرقابلدسترسی هستند.
-
-سایر گزینه های پیکربندی اولیه عبارتند از، به عنوان مثال. انتخاب یک شبکه - شبکه اصلی یا شبکههای آزمایشی، فعال کردن نقطه پایانی HTTP برای RPC یا WebSockets و غیره. شما می توانید تمام ویژگی ها و گزینه ها را در اسناد کلاینت بیابید. پیکربندی های مختلف کلاینت را می توان با اجرای کلاینت با پرچم های مربوطه به طور مستقیم در فایل CLI یا پیکربندی تنظیم کرد. هر کلاینت کمی متفاوت است. لطفاً برای جزئیات بیشتر در مورد گزینه های پیکربندی، همیشه به اسناد رسمی یا صفحه راهنمای آن مراجعه کنید.
-
-برای اهداف آزمایشی، ممکن است ترجیح دهید یک کلاینت را در یکی از شبکه های تست نت اجرا کنید. [مشخصات کلی شبکههای پشتیبانیشده را مشاهده کنید](/developers/docs/nodes-and-clients/#execution-clients).
-
-نمونه هایی از اجرای کلاینت های اجرایی با پیکربندی اولیه را می توان در بخش بعدی یافت.
-
-#### آغاز بهکار کلاینت اجرا {#starting-the-execution-client}
-
-قبل از راهاندازی نرمافزار کلاینت اتریوم، آخرین بررسی را انجام دهید که آیا محیط شما آماده است. برای مثال، مطمئن شوید که:
-
-- فضای دیسک کافی با توجه به شبکه انتخابی و حالت همگام سازی وجود دارد.
-- حافظه و پردازنده توسط برنامههای دیگر استفاده نمیشود.
-- سیستم عامل به آخرین نسخه آپدیت شده است.
-- سیستم زمان و تاریخ صحیح را دارد.
-- روتر و فایروال شما اتصالات را در پورتهای شنونده (listening ports) میپذیرند. به طور پیشفرض کلاینتهای اتریوم از یک پورت شنونده (TCP) و یک پورت یابنده (UDP) که هر دو بهطور پیشفرض روی 30303 هستند استفاده میکنند.
-
-کلاینت خود را ابتدا روی شبکهی تست اجرا کنید تا مطمئن شوید که همهچیز بهدرستی کار میکند.
-
-شما باید هرگونه تنظیمات کلاینت که به صورت پیشفرض وجود ندارند را در ابتدا مشخص کنید. میتوانید از پرچمها و فایلهای پیکربندی برای مشخص کردن پیکربندی موردنظر استفاده کنید. مجموعه ای از ویژگی ها و نحو پیکربندی هر کلاینت متفاوت است. برای جزئیات، اسناد کلاینت خود را بررسی کنید.
-
-کلاینتهای اجرا و اجماع از طریق یک نقطه پایانی تأیید شده مشخص شده در [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine) ارتباط برقرار می کنند. برای اتصال به یک کلاینت اجماع، کلاینت اجرا باید یک [`jwtsecret`](https://jwt.io/) در یک مسیر شناخته شده ایجاد کند. به دلایل امنیتی و پایداری، کلاینتها باید روی یک ماشین اجرا شوند و هر دو کلاینت باید این مسیر را بدانند زیرا برای تأیید اعتبار یک اتصال RPC محلی بین آنها استفاده میشود. کلاینت اجرا همچنین باید یک پورت شنونده (listening port) برای APIهای تایید شده تعریف کند.
-
-این نشانه به طور خودکار توسط نرمافزار کلاینت تولید می شود، اما در برخی موارد، ممکن است لازم باشد خودتان آن را انجام دهید. میتوانید آن را با [OpenSSL](https://www.openssl.org/)تولید کنید:
-
-```sh
-openssl rand -hex 32 > jwtsecret
-```
-
-#### اجرای یک کلاینت اجرا {#running-an-execution-client}
-
-این بخش شما را از طریق راهاندازی کلاینت های اجرا راهنمایی می کند. این فقط به عنوان نمونه ای از یک پیکربندی اولیه عمل می کند که کلاینت را با این تنظیمات شروع میکند:
-
-- شبکه ای را برای اتصال به شبکه اصلی در مثال های ما مشخص می کند
- - در عوض میتوانید [یکی از شبکههای آزمایشی](/developers/docs/networks/) را برای آزمایش اولیه تنظیمات خود انتخاب کنید
-- دایرکتوری داده را تعریف می کند، جایی که تمام داده ها از جمله بلاکچین در آن ذخیره می شود
- - مطمئن شوید که مسیر را با یک مسیر واقعی جایگزین کنید، به عنوان مثال به درایو خارجی شما اشاره می کند
-- رابط ها را برای برقراری ارتباط با کلاینت فعال می کند
- - از جمله JSON-RPC و Engine API برای ارتباط با کلاینت اجماع
-- مسیر `jwtsecret` را برای API احراز هویت شده تعریف می کند
- - مطمئن شوید که مسیر مثال را با یک مسیر واقعی جایگزین کنید که برای کلاینتها قابل دسترسی باشد، مثلاً `/tmp/jwtsecret`
-
-لطفاً به خاطر داشته باشید که این فقط یک مثال اولیه است، تمام تنظیمات دیگر به طور پیش فرض تنظیم می شوند. برای اطلاع از مقادیر، تنظیمات و ویژگیهای پیشفرض، به مستندات هر کلاینت توجه کنید. برای ویژگی های بیشتر، به عنوان مثال برای اجرای اعتبارسنج، نظارت و غیره، لطفاً به مستندات کلاینت خاص مراجعه کنید.
-
-> توجه داشته باشید که جریمههای معکوس `\` در مثال ها فقط برای اهداف قالب بندی هستند. پرچم های پیکربندی را می توان در یک خط تعریف کرد.
-
-##### اجرای Besu
-
-این مثال Besu را در شبکه اصلی شروع میکند، دادههای بلاکچین را در قالب پیشفرض در `/data/ethereum` ذخیره میکند، JSON-RPC و Engine RPC را برای اتصال کلاینت اجماع فعال میکند. Engine API با نشانه `jwtsecret` احراز هویت می شود و فقط تماس از `localhost` مجاز است.
-
-```sh
-besu --network=mainnet \
- --data-path=/data/ethereum \
- --rpc-http-enabled=true \
- --engine-rpc-enabled=true \
- --engine-host-allowlist="*" \
- --engine-jwt-enabled=true \
- --engine-jwt-secret=/path/to/jwtsecret
-```
-
-Besu همچنین دارای یک گزینه لانچر است که یک سری سوالات را می پرسد و فایل پیکربندی را ایجاد می کند. لانچر تعاملی را با استفاده از موارد زیر اجرا کنید:
-
-```sh
-besu --Xlauncher
-```
-
-[اسناد Besu](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) حاوی گزینههای اضافی و جزئیات پیکربندی است.
-
-##### اجرای Erigon
-
-این مثال Erigon را در شبکه اصلی شروع میکند، دادههای بلاکچین را در `/data/ethereum` ذخیره میکند، JSON-RPC را فعال میکند،تعیین می کند که چه فضاهای نامی مجاز است و احراز هویت را برای اتصال کلاینت اجماع که توسط مسیر `jwtsecret` تعریف می شود، فعال می کند.
-
-```sh
-erigon --chain mainnet \
- --datadir /data/ethereum \
- --http --http.api=engine,eth,web3,net \
- --authrpc.jwtsecret=/path/to/jwtsecret
-```
-
-Erigon به طور پیش فرض یک همگام سازی کامل را با 8 گیگابایت هارد دیسک انجام می دهد که منجر به بیش از 2 ترابایت داده آرشیو می شود. مطمئن شوید که `datadir` به دیسک با فضای خالی کافی اشاره می کند یا به پرچم `--prune` نگاه کنید که می تواند انواع مختلف داده را هرس کند. برای کسب اطلاعات بیشتر، `--help` مربوط به Erigon را بررسی کنید.
-
-##### اجرای Geth
-
-این مثال Geth را در شبکه اصلی شروع میکند، دادههای بلاکچین را در `/data/ethereum` ذخیره میکند، JSON-RPC را فعال میکند و مشخص میکند که کدام فضاهای نام مجاز هستند. همچنین احراز هویت را برای اتصال کلاینت اجماع فعال می کند که به مسیر `jwtsecret` نیاز دارد و همچنین گزینه ای را که در مثال ما فقط از `localhost` مجاز است، تعیین می کند.
-
-```sh
-geth --mainnet \
- --datadir "/data/ethereum" \
- --http --authrpc.addr localhost \
- --authrpc.vhosts="localhost" \
- --authrpc.port 8551
- --authrpc.jwtsecret=/path/to/jwtsecret
-```
-
-[اسناد برای همه گزینههای پیکربندی](https://geth.ethereum.org/docs/fundamentals/command-line-options) را بررسی کنید و درباره [اجرای Geth با یک کلاینت اجماع](https://geth.ethereum.org/docs/getting-started/consensus-clients) بیشتر بدانید.
-
-##### اجرای Nethermind
-
-Nethermind [گزینه های نصب](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) مختلفی را ارائه می دهد. این بسته با باینریهای مختلف، از جمله یک لانچر با راهاندازی هدایتشده ارائه میشود که به شما در ایجاد پیکربندی به صورت تعاملی کمک میکند. از طرف دیگر، Runner را پیدا میکنید که خود فایل اجرایی است و فقط میتوانید آن را با پرچمهای پیکربندی اجرا کنید. JSON-RPC بهصورت پیشفرض فعال است.
-
-```sh
-Nethermind.Runner --config mainnet \
- --datadir /data/ethereum \
- --JsonRpc.JwtSecretFile=/path/to/jwtsecret
-```
-
-اسناد Nethermind یک [راهنمای کامل](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) در مورد اجرای Nethermind با کلاینت اجماع ارائه می دهد.
-
-یک کلاینت اجرا، توابع اصلی، نقاط پایانی انتخابی خود را آغاز می کند و شروع به جستجوی همتا می کند. پس از یافتن موفق همتایان، کلاینت شروع به همگامسازی میکند. کلاینت اجرا منتظر اتصال از سمت کلاینت اجماع خواهد بود. دادههای کنونی زنجیرهی بلوکی زمانی آماده خواهد بود که کلاینت بهطور موفقیتآمیز با وضعیت فعلی همگامسازی کرده باشد.
-
-##### اجرای Reth
-
-این مثال با استفاده از موقعیت مکانی داده پیش فرض، Reth را در شبکه اصلی شروع می کند. احراز هویت JSON-RPC و Engine RPC را برای اتصال کلاینت اجماع که توسط مسیر `jwtsecret` تعریف شده است، فعال می کند و فقط تماس از `localhost` مجاز است.
-
-```sh
-reth node \
- --authrpc.jwtsecret /path/to/jwtsecret \
- --authrpc.addr 127.0.0.1 \
- --authrpc.port 8551
-```
-
-برای اطلاعات بیشتر در مورد دایرکتوری های داده پیش فرض داده، به [پیکربندی Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) مراجعه کنید. [اسناد Reth](https://reth.rs/run/mainnet.html) حاوی گزینههای اضافی و جزئیات پیکربندی است.
-
-#### آغاز بهکار کلاینت اجماع {#starting-the-consensus-client}
-
-کلاینت اجماع باید با پیکربندی پورت مناسب شروع شود تا یک اتصال RPC محلی به کلاینت اجرا برقرار شود. کلاینت های اجماع باید با پورت کلاینت اجرای در معرض، به عنوان آرگومان پیکربندی اجرا شوند.
-
-کلاینت اجماع همچنین به مسیر `jwt-secret` کلاینت اجرا نیاز دارد تا بتواند ارتباط RPC بین آنها را تأیید کند. مشابه مثالهای اجرایی بالا، هر کلاینت اجماع یک پرچم پیکربندی دارد که مسیر فایل توکن jwt را به عنوان آرگومان میگیرد. این مسیر باید با مسیر `jwtsecret` ارائهشده به کلاینت اجرا مطابقت داشته باشد.
-
-اگر قصد دارید یک اعتبارسنج را اجرا کنید، مطمئن شوید که یک پرچم پیکربندی که آدرس اتریوم گیرنده کارمزد را مشخص میکند، اضافه کنید. اینجاست که پاداشهای اتر برای اعتبارسنج شما جمع میشوند. هر کلاینت اجماع یک گزینه دارد، مثلاً `--suggested-fee-recipient=0xabcd1`، که آدرس اتریوم را به عنوان آرگومان می گیرد.
-
-هنگام راهاندازی یک بیکننود در یک شبکه آزمایشی، میتوانید با استفاده از یک نقطه پایانی عمومی برای [همگامسازی نقطه چک](https://notes.ethereum.org/@launchpad/checkpoint-sync) زمان همگامسازی قابل توجهی صرفهجویی کنید.
-
-#### اجرای یک کلاینت اجماع {#running-a-consensus-client}
-
-##### اجرای Lighthouse
-
-قبل از اجرای Lighthouse، در [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html) درباره نحوه نصب و پیکربندی آن بیشتر بیاموزید.
-
-```sh
-lighthouse beacon_node \
- --network mainnet \
- --datadir /data/ethereum \
- --http \
- --execution-endpoint http://127.0.0.1:8551 \
- --execution-jwt /path/to/jwtsecret
-```
-
-##### اجرای Lodestar
-
-نرمافزار Lodestar را با کامپایل یا دانلود تصویر داکر نصب کنید. در [اسناد](https://chainsafe.github.io/lodestar/) و جامع تر در [راهنمای راه اندازی](https://hackmd.io/@philknows/rk5cDvKmK) بیشتر بیاموزید.
-
-```sh
-lodestar beacon \
- --rootDir="/data/ethereum" \
- --network=mainnet \
- --eth1.enabled=true \
- --execution.urls="http://127.0.0.1:8551" \
- --jwt-secret="/path/to/jwtsecret"
-```
-
-##### اجرای Nimbus
-
-Nimbus هم با اجماع و هم با کلاینت های اجرا عرضه می شود. این می تواند بر روی دستگاه های مختلف حتی با قدرت محاسباتی بسیار کم اجرا شود. پس از [نصب وابستگی ها و خود Nimbus](https://nimbus.guide/quick-start.html)، می توانید کلاینت اجماع آن را اجرا کنید:
-
-```sh
-nimbus_beacon_node \
- --network=mainnet \
- --web3-url=http://127.0.0.1:8551 \
- --rest \
- --jwt-secret="/path/to/jwtsecret"
-```
-
-##### اجرای Prysm
-
-Prysm همراه با اسکریپت است که امکان نصب خودکار آسان را فراهم می کند. جزئیات را می توان در [اسناد Prysm](https://docs.prylabs.network/docs/install/install-with-script) پیدا کرد.
-
-```sh
-./prysm.sh beacon-chain \
- --mainnet \
- --datadir /data/ethereum \
- --execution-endpoint=http://localhost:8551 \
- --jwt-secret=/path/to/jwtsecret
-```
-
-##### اجرای Teku
-
-```sh
-teku --network mainnet \
- --data-path "/data/ethereum" \
- --ee-endpoint http://localhost:8551 \
- --ee-jwt-secret-file "/path/to/jwtsecret"
-```
-
-هنگامی که یک کلاینت اجماع برای خواندن قرارداد سپرده و شناسایی اعتبارسنجها به کلاینت اجرا متصل می شود، به سایر همتایان بیکننود نیز متصل می شود و شروع به همگام سازی اسلات های اجماع از زمان پیدایش می کند. هنگامی که Beacon Node به دوره فعلی رسید، Beacon API برای اعتبارسنج شما قابل استفاده می شود. درباره [API های Beacon Node](https://eth2docs.vercel.app/) بیشتر بیاموزید.
-
-### افزودن اعتبارسنجها {#adding-validators}
-
-یک کلاینت اجماع به عنوان یک Beacon Node برای اعتبارسنجها برای اتصال عمل می کند. هر کلاینت اجماع دارای نرمافزار اعتبارسنج مخصوص به خود است که در مستندات مربوطه به تفصیل شرح داده شده است.
-
-اجرای اعتبارسنج خود اجازهی [سهامگذاری انفرادی](/staking/solo/)، موثرترین و بی اعتمادترین روش برای پشتیبانی از شبکه اتریوم را میدهد. بااینحال، نیاز به سپردهگذاری 32 اتر دارد. برای اجرای یک اعتبارسنج بر روی گره خود با مقدار کمتر، ممکن است یک استخر غیرمتمرکز با عملگرهای گره بدون مجوز، مانند [Rocket Pool](https://rocketpool.net/node-operators) مورد علاقه شما باشد.
-
-سادهترین راه برای شروع کار با تولید کلید سهامگذاری و اعتبارسنج، استفاده از [لانچپد سهامگذاری شبکهی تست Holesky](https://holesky.launchpad.ethereum.org/) است که به شما امکان می دهد تنظیمات خود را با [گره های در حال اجرا در Holesky](https://notes.ethereum.org/@launchpad/holesky) آزمایش کنید. وقتی برای شبکهی اصلی آماده شدید، میتوانید این مراحل را با استفاده از [سکوی پرتاب سهامگذاری شبکهی اصلی](https://launchpad.ethereum.org/) تکرار کنید.
-
-برای مروری بر گزینه های سهامگذاری به [صفحه سهامگذاری](/staking) نگاه کنید.
-
-### استفاده کردن از گره {#using-the-node}
-
-کلاینتهای اجرا [نقاط پایانی RPC API](/developers/docs/apis/json-rpc/) را ارائه میکنند که میتوانید از آنها برای ارسال تراکنشها، تعامل با قراردادهای هوشمند یا استقرار آنها در شبکه اتریوم به روشهای مختلف استفاده کنید:
-
-- فراخوانی دستی آنها با یک پروتکل مناسب (مثلاً با استفاده از `curl`)
-- ضمیمه کردن کنسول ارائهشده (مثلاً `geth attach`)
-- پیادهسازی آنها در برنامه های کاربردی با استفاده از کتابخانه های web3، مثلاً [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview)، [ethers](https://github.com/ethers-io/ethers.js/)
-
-کلاینتهای مختلف پیادهسازیهای مختلفی برای نقاط پایانی RPC دارند. اما برای JSON-RPC استانداردی وجود دارد که میتوانید برای هر کلاینتی استفاده نمایید. برای مروری اجمالی، [مستندات JSON-RPC را بخوانید](/developers/docs/apis/json-rpc/). برنامههای کاربردی که نیاز به اطلاعات از شبکهی اتریوم دارند میتوانند از RPC استفاده کنند. به عنوان مثال، کیف پول محبوب متامسک به شما امکان می دهد [به نقطه پایانی RPC خود متصل شوید](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) که دارای مزایای امنیتی و حریم خصوصی قوی است.
-
-کلاینتهای اجماع همگی یک [API بیکن](https://ethereum.github.io/beacon-APIs) را در معرض نمایش میگذارند که میتواند با ارسال درخواست با استفاده از ابزارهایی مانند [Curl](https://curl.se) برای بررسی وضعیت کلاینت اجماع یا بارگیری کردن بلوکها و دادههای اجماع استفاده شود. اطلاعات بیشتر در این مورد را میتوان در اسناد مربوط به هر کلاینت اجماع یافت.
-
-#### دستیابی به RPC {#reaching-rpc}
-
-درگاه پیشفرض برای اجرای برنامه JSON-RPC `8545` است اما میتوانید پورتهای نقاط انتهایی محلی را در پیکربندی تغییر دهید. در حالت پیشفرض، رابط RPC فقط در هاست محلی (localhost) رایانهی شما قابل دسترسی است. برای اینکه بتوانید از راه دور به آن دسترسی داشته باشید، میتوانید با تغییر آدرس به `0.0.0.0` آن را در معرض دید عموم قرار دهید. این باعث می شود که از طریق شبکه محلی و آدرس های IP عمومی قابل دسترسی باشد. در بیشتر موارد، باید روی روتر خود باز ارسالی پورت (port forwarding) را هم تنظیم کنید.
-
-با احتیاط به قرار دادن پورت ها در معرض اینترنت نگاه کنید زیرا این کار به هر کسی در اینترنت اجازه می دهد گره شما را کنترل کند. اگر از کلاینت خود بهعنوان کیف پول استفاده میکنید، افراد خرابکار میتوانند به گره شما دسترسی پیدا کنند تا سیستم شما را خراب کنند یا سرمایههای شما را بدزدند.
-
-راهحل این مشکل، جلوگیری از تغییرپذیری روشهای بالقوه خطرناک RPC است. برای مثال، با Geth، میتوانید روشهای اصلاحپذیر را با یک پرچم اعلام کنید: `--http.api web3,eth,txpool`.
-
-دسترسی به رابط RPC را می توان از طریق توسعه APIهای لایه لبه یا برنامه های کاربردی وب سرور، مانند Nginx، و اتصال آنها به آدرس محلی و پورت کلاینت خود گسترش داد. استفاده از یک لایه میانی همچنین میتواند به توسعهدهندگان این امکان را بدهد که گواهی را برای اتصالات `https` ایمن به رابط RPC تنظیم کنند.
-
-راهاندازی یک وب سرور، یک پروکسی یا Rest API روبه خارج تنها راه برای دسترسی به نقطه پایانی RPC گره شما نیست. یکی دیگر از راههای حفظ حریم خصوصی برای تنظیم یک نقطه پایانی قابل دسترسی عمومی، میزبانی گره در سرویس پیاز [Tor](https://www.torproject.org/) خودتان است. بدین ترتیب میتوانید به RPC خارج از شبکهی محلی خود بدون آدرس آیپی (IP) عمومی ثابت یا پورتهای باز شده دسترسی پیدا کنید. با این حال، استفاده از این پیکربندی ممکن است تنها به نقطه پایانی RPC اجازه دهد که از طریق شبکه Tor که توسط همه برنامهها پشتیبانی نمیشود و ممکن است منجر به مشکلات اتصال شود، قابل دسترسی باشد.
-
-برای انجام این کار، باید [سرویس onion](https://community.torproject.org/onion-services/) خود را ایجاد کنید. [اسناد](https://community.torproject.org/onion-services/setup/) راهاندازی سرویس پیاز را برای هاست خود بررسی کنید. می توانید آن را به یک وب سرور با پروکسی به درگاه RPC یا فقط مستقیماً به RPC اشاره کنید.
-
-در نهایت، و یکی از محبوب ترین راه ها برای دسترسی به شبکه های داخلی از طریق اتصال VPN است. بسته به مورد استفاده شما و تعداد کاربرانی که نیاز به دسترسی به گره شما دارند، یک اتصال VPN ایمن ممکن است یک گزینه باشد. [OpenVPN](https://openvpn.net/) یک SSL VPN با امکانات کامل است که برنامه افزودنی شبکه ایمن لایه دوم یا سوم OSI را با استفاده از پروتکل استاندارد صنعتی SSL/TLS پیادهسازی میکند، از روشهای تأیید اعتبار کلاینت انعطافپذیر بر اساس گواهیها، کارتهای هوشمند و/یا نام کاربری پشتیبانی میکند، نام کاربری/رمز را ارائه می دهد و به سیاست های کنترل دسترسی خاص کاربر یا گروه با استفاده از قوانین فایروال اعمال شده در رابط مجازی VPN اجازه کار می دهد.
-
-### استفاده از گره {#operating-the-node}
-
-شما باید بهطور مرتب گره خود را کنترل کنید تا مطمئن شوید که به درستی کار میکند. ممکن است نیاز به انجام تعمیرات گاهبهگاه داشته باشید.
-
-#### آنلاین نگهداشتن گره {#keeping-node-online}
-
-نیازی نیست که گره شما همیشه آنلاین باشد، اما باید آن را تا حد امکان آنلاین نگه دارید تا با شبکه همگام شود. برای راه اندازی مجدد می توانید آن را خاموش کنید، اما به خاطر داشته باشید که:
-
-- اگر وضعیت اخیر همچنان روی دیسک نوشته می شود، خاموش شدن می تواند چند دقیقه طول بکشد.
-- خاموش شدن اجباری می تواند به دیتابیس آسیب برساند و شما را ملزم به همگام سازی مجدد کل گره کند.
-- کلاینت شما با شبکه همگام نمی شود و با راه اندازی مجدد باید مجدداً همگام شود. در حالی که گره می تواند از زمانی که آخرین خاموش شده بود همگام سازی را آغاز کند، بسته به مدت زمانی که آفلاین بوده است، فرآیند ممکن است زمان ببرد.
-
-_این موضوع روی گرههای اعتبار سنج لایهی اجماع اعمال نمیشود._ آفلاین کردن گرهی شما بر تمام سرویسهای وابسته به آن تأثیر میگذارد. اگر یک گره را برای _سهامگذاری_ اجرا میکنید، باید سعی کنید زمان خاموشی را تا حد امکان پایین آورید.
-
-#### ساختن سرویسهای کلاینت {#creating-client-services}
-
-ساختن سرویسی را برای اجرای خودکار کلاینتهای خود در هنگام راهاندازی در نظر بگیرید. به عنوان مثال، در سرورهای لینوکس، بهترین رویه ایجاد یک سرویس است، به عنوان مثال با `systemd`، که کلاینت را با پیکربندی مناسب، تحت یک کاربر با امتیازات محدود اجرا می کند و به طور خودکار ریستارت می شود.
-
-#### بهروزرسانی کلاینتها {#updating-clients}
-
-شما باید نرمافزار کلاینت خود را با آخرین پچهای امنیتی، ویژگیها و [EIPها](/eips/) بهروز نگهدارید. بهویژه قبل از [فورک سخت](/history/)، مطمئن شوید که نسخههای کلاینت صحیح را اجرا میکنید.
-
-> قبل از بهروزرسانیهای مهم شبکه، EF یک پست را در [وبلاگ](https://blog.ethereum.org) خود منتشر میکند. میتوانید [مشترک این اعلامیهها شوید](https://blog.ethereum.org/category/protocol#subscribe) تا زمانی که گره شما نیاز به بروزرسانی دارد، اعلان را در ایمیل خود دریافت کنید.
-
-بروزرسانی کلاینتها بسیار ساده است. هر کلاینت دستورالعملهای خاصی را در مستندات خود دارد، اما فرآیند معمولاً فقط دانلود آخرین نسخه و راهاندازی مجدد کلاینت با فایل اجرایی جدید است. کلاینت باید از جایی که کارش را متوقف کرد، اما با بهروزرسانیهای اعمال شده، به کار خود ادامه دهد.
-
-هر پیادهسازی کلاینت دارای یک رشته نسخه قابلخواندن توسط انسان است که در پروتکل همتا به همتا استفاده میشود، اما از طریق خط فرمان نیز قابلدسترسی است. این رشته نسخه به کاربران امکان می دهد بررسی کنند که آیا نسخه صحیح را اجرا میکنند یا نه و به جستجوگرهای بلوک و سایر ابزارهای تحلیلی علاقهمند به تعیین کمیت توزیع مشتریان خاص اجازهی دسترسی به شبکه را میدهد. لطفاً جهت کسب اطلاعات بیشتر در مورد رشتههای نسخه به مستندات هر کلاینت مراجعه کنید.
-
-#### اجرای سرویسهای اضافه {#running-additional-services}
-
-اجرای گره خودتان به شما امکان میدهد از خدماتی استفاده کنید که نیاز به دسترسی مستقیم به RPC کلاینت اتریوم دارند. اینها خدماتی هستند که بر روی اتریوم ساخته شده اند مانند [راهکارهای لایه 22](/developers/docs/scaling/#layer-2-scaling)، پشتیبان برای کیف پول، کاوشگرهای بلوک، ابزارهای توسعه دهنده و سایر زیرساخت های اتریوم.
-
-#### نظارت بر گره {#monitoring-the-node}
-
-برای نظارت صحیح بر گره خود، معیارهای تجمعی را در نظر بگیرید. کلاینتها نقاط پایانی معیارها را ارائه میکنند تا بتوانید دادههای جامعی درباره گره خود دریافت کنید. از ابزارهایی مثل [InfluxDB](https://www.influxdata.com/get-influxdb/) یا [Prometheus](https://prometheus.io/) برای ساخت پایگاه دادههایی استفاده کنید که میتوانید با استفاده از نرمافزارهایی مثل [Grafana](https://grafana.com/) آنها را تبدیل به بازنمایی بصری و نمودار کنید. تنظیمات زیادی برای استفاده از این نرمافزار و داشبوردهای مختلف Grafana وجود دارد تا بتوانید گره خود و شبکه را کاملاً به شکل بصری بازنمایی کنید. برای مثال، [آموزش نظارت بر Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/) را بررسی کنید.
-
-بهعنوان بخشی از نظارت خود، مطمئن شوید که عملکرد دستگاه خود را زیر نظر داشته باشید. در طول همگامسازی اولیهی گره شما، ممکن است نرمافزار کلاینت برای پردازنده و رم بسیار سنگین باشد. علاوه بر Grafana میتوانید از ابزارهایی که سیستمعاملتان به شما ارائه میدهد، مثل `htop` یا `uptime`، برای این کار استفاده کنید.
-
-## بیشتر بخوانید {#further-reading}
-
-- [راهنماهای سهام گذاری اتریوم](https://github.com/SomerEsat/ethereum-staking-guides) - _Somer Esat، به روز رسانی مکرر_
-- [راهنما | نحوه ایجاد یک اعتبارسنج برای سس اتریوم در شبکه اصلی](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet)_- CoinCashew مرتباً به روز میشود_
-- [راهنماهای ETHStaker درباره اجرای اعتبارسنج در شبکهی تست](https://github.com/remyroy/ethstaker#guides) – _ETHStaker، مرتباً بهروز میشود_
-- [سوالات متداول ادغام برای اپراتورهای نود](https://notes.ethereum.org/@launchpad/node-faq-merge) - _جولای 2022_
-- [تحلیل نیازمندیهای سختافزاری برای تبدیل شدن به یک گرهی کامل معتبر اتریوم](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– آلبرت پالا، 24 سپتامبر 2018_
-- [اجرای گرههای کامل اتریوم: راهنمایی برای افراد کمانگیزه](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– جاستین لروکس، 7 نوامبر 2019_
-- [اجرای یک گرهی هایپرلجر Besu روی شبکهی اصلی اتریوم: مزایا، نیازمندیها و راهاندازی](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– فلیپ فراگی، 7 مه 2020_
-- [بهکارگیری کلاینت اتریوم Nethermind با پشتهی نظارت](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _- Nethermind.eth، 8 ژوئیه 2020_
-
-## موضوعات مرتبط {#related-topics}
-
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
-- [بلوکها](/developers/docs/blocks/)
-- [شبکهها](/developers/docs/networks/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
deleted file mode 100644
index 47abc6b1f51..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md"
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: مکانیزمهای اجماع
-description: توضیحی درباره پروتکلهای اجماع در سیستمهای توزیعشده و نقشی که در اتریوم ایفا میکنند.
-lang: fa
----
-
-مفهوم "مکانیسم اجماع" اغلب به صورت محاورهای برای اشاره به پروتکلهای "اثبات سهام"، "اثبات کار" یا "اثبات صلاحیت" استفاده میشود. با این حال، این موارد فقط اجزایی در مکانیزمهای اجماع هستند که از [حملات سیبیل](/glossary/#sybil-attack) محافظت میکنند. مکانیسمهای اجماع مجموعه کاملی از ایدهها، پروتکلها و مشوقها هستند که مجموعهای از گرهها را قادر میسازد تا در مورد وضعیت یک بلاکچین به توافق برسند.
-
-## پیشنیازها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه میشود ابتدا [مقدمهای بر اتریوم](/developers/docs/intro-to-ethereum/) را مطالعه کنید.
-
-## اجماع چیست؟ {#what-is-consensus}
-
-منظور از اجماع، یک توافقنامه کلی است که به آن دست یافتهایم. فرض کنید گروهی از افراد به سینما میروند. اگر در مورد انتخاب پیشنهادی فیلم اختلاف نظر وجود نداشته باشد، اجماع حاصل می شود. اگر اختلاف نظر وجود داشته باشد، گروه باید ابزاری داشته باشد تا تصمیم بگیرد کدام فیلم را ببیند. در موارد اختلاف شدید، گروه در نهایت از هم جدا می شود.
-
-در رابطه با بلاکچین اتریوم، این فرآیند رسمی شده است و رسیدن به اجماع به این معنی است که حداقل 66 درصد از گرههای شبکه در مورد وضعیت جهانی شبکه توافق دارند.
-
-## مکانیزم اجماع چیست؟ {#what-is-a-consensus-mechanism}
-
-اصطلاح مکانیزم اجماع به کل پشته پروتکلها، مشوقها و ایدههایی اشاره دارد که به شبکهای از گرهها اجازه میدهد در مورد وضعیت یک بلاکچین به توافق برسند.
-
-اتریوم از مکانیزم اجماع مبتنی بر اثبات سهام استفاده میکند که امنیت اقتصاد رمزنگاری خود را از مجموعهای از پاداشها و جریمههای اعمال شده برای سرمایه قفل شده توسط سهام گذاران به دست میآورد. این ساختار انگیزشی اشخاص سهام گذاران را تشویق میکند اعتبارسنجهای صادقانه را اجرا کنند، کسانی را که این کار را نمیکنند تنبیه میکند و هزینه بسیار بالایی برای حمله به شبکه ایجاد میکند.
-
-سپس، پروتکلی وجود دارد که نحوه انتخاب اعتبارسنجهای صادق برای پیشنهاد یا اعتبارسنجی بلوکها، پردازش تراکنشها و رای دادن به دیدگاه آنها در مورد رئیس زنجیره را کنترل میکند. در موقعیتهای نادری که چندین بلوک در یک موقعیت در نزدیکی سر زنجیره قرار دارند، یک مکانیسم انتخاب فورک وجود دارد که بلوکهایی را انتخاب میکند که «سنگینترین» زنجیره را تشکیل میدهند، که با تعداد اعتبارسنج که به بلوکهای وزنشده توسط میزان اتر سهام گذاری شده آنها رأی دادهاند، اندازهگیری میشود.
-
-برخی از مفاهیم برای اجماع مهم هستند مانند امنیت اضافی ارائه شده توسط هماهنگی اجتماعی خارج از باند به عنوان آخرین خط دفاع در برابر حملات در شبکه که به صراحت در کد تعریف نشدهاند.
-
-این اجزا با هم مکانیسم اجماع را تشکیل میدهند.
-
-## انواع مکانیزمهای اجماع {#types-of-consensus-mechanisms}
-
-### بر اساس اثبات کار {#proof-of-work}
-
-مانند بیتکوین، اتریوم زمانی از پروتکل اجماع مبتنی بر **اثبات کار (PoW)** استفاده میکرد.
-
-#### ساختن بلوک {#pow-block-creation}
-
-استخراجگر برای ایجاد بلوکهای جدید پر از تراکنشهای پردازش شده با یکدیگر رقابت میکنند. برنده، بلوک جدید را با بقیه شبکه به اشتراک میگذارد و مقداری اتر تازه ضربشده به دست میآورد. این رقابت را کامپیوتری برنده میشود که قادر به حل سریع ترین معمای ریاضی است. این مورد باعث ایجاد پیوند رمزنگاری بین بلوک فعلی و بلوک قبلی میشود. حل این معما همان کار در «اثبات کار» است. سپس زنجیره متعارف توسط یک قانون فورک انتخاب میشود که مجموعهای از بلوکها را انتخاب میکند که بیشترین کار را برای استخراج آنها انجام دادهاند.
-
-#### ایمنی {#pow-security}
-
-شبکه با توجه به این حقیقت که برای فریب دادن زنجیره نیاز به 51% توان پردازش شبکه دارید، ایمن میماند. این کار نیاز به چنان سرمایهگذاری زیادی برای تجهیزات و انرژی دارد که احتمالاً خرج شما از سودی که به دست خواهید آورد بیشتر خواهد بود.
-
-اطلاعات بیشتر درباره [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
-
-### بر اساس اثبات سهام {#proof-of-stake}
-
-اتریوم اکنون از پروتکل اجماع مبتنی بر **اثبات سهام (PoS)** استفاده میکند.
-
-#### ساختن بلوک {#pos-block-creation}
-
-اعتبارسنجها بلوکها را ایجاد میکنند. یک اعتبارسنج به طور تصادفی در هر اسلات انتخاب میشود تا پیشنهاد دهنده بلوک باشد. کاربر اجماعِ آنها، مجموعهای از تراکنشها را به عنوان "بار اجرایی" از مشتری اجرای جفت شده خود درخواست میکند. آنها این مورد را در دادههای اجماع میپیچانند یا به اصطلاح رپ میکنند تا یک بلوک تشکیل دهند که آن را به گرههای دیگر در شبکه اتریوم ارسال کنند. به این تولید بلوک در اتریوم، پاداش داده میشود. در موارد نادری که چندین بلوک ممکن برای یک اسلات وجود دارد، یا گرهها در زمانهای مختلف درباره بلوکها میشنوند، الگوریتم انتخاب فورک بلوکی را انتخاب میکند که زنجیره با بیشترین وزن اعتبارسنجها را تشکیل میدهد (که وزن تعداد اعتبارسنجهایی است که با مقدار اتر آنها مقیاسبندی شده است).
-
-#### ایمنی {#pos-security}
-
-یک سیستم اثبات سهام از نظر اقتصاد رمزنگاری ایمن است زیرا مهاجمی که تلاش میکند کنترل زنجیره را در دست بگیرد باید مقدار زیادی از اتر را از بین ببرد. یک سیستم پاداش، سهام گذاران را تشویق میکند صادقانه رفتار کنند، و جریمهها، سهامداران را از اقدام شرورانه باز میدارد.
-
-اطلاعات بیشتر درباره [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
-
-### یک راهنمای تصویری {#types-of-consensus-video}
-
-برای کسب اطلاعات بیشتر درباره مکانیزمهای مختلف اجماع که در اتریوم استفادهشده است، نگاه کنید به:
-
-
-
-### مقاومت سیبیل و انتخاب زنجیره {#sybil-chain}
-
-اثبات کار و اثبات سهام به تنهایی پروتکلهای اجماع نیستند، اما اغلب برای سادگی به آنها اشاره میشود. اینها در واقع مکانیزمهای مقاومت سیبیل و انتخابکننده نویسنده بلوک هستند؛ روشی هستند برای انتخاب این که چه کسی آخرین بلوک را بنویسد. مؤلفه مهم دیگر، الگوریتم انتخاب زنجیره (معروف به انتخاب فورک) است که گرهها را قادر می سازد در سناریوهایی که چندین بلوک در یک موقعیت وجود دارند، یک بلوک صحیح را در سر زنجیره انتخاب کنند.
-
-**مقاومت سیبیل** عملکرد یک پروتکل در مقابل یک حمله سیبیل را میسنجد. مقاومت در برابر چنین حملاتی برای یک زنجیره بلوکی غیرمتمرکز بسیار ضروری است و به استخراجگرها و اعتبارسنجها امکان میدهد بر اساس منابعی که در اختیار گذاشتهاند بهصورت مساوی پاداش دریافت کنند. اثبات سهام و اثبات کار با مجبور کردن کاربر به هزینه کردن انرژی بسیار یا گذاشتن وثیقه زیاد، جلوی این حمله را میگیرند. این تمهیدات محافظتی، مانعی بهصرفه علیه حملات سیبیل هستند.
-
-یک **قانون انتخاب زنجیره** برای تصمیمگیری در این باره که کدام زنجیره، زنجیره «درست» است، استفاده میشود. بیتکوین از قانون «طولانیترین زنجیره» استفاده میکند، به این معنی که بلاکچینی که طولانیترین باشد، همان چیزی است که بقیه گرهها آن را معتبر میپذیرند و با آن کار میکنند. برای زنجیرههای اثبات کار، بلندترین زنجیره بر اساس سختی اثبات کار تجمیعی کل زنجیره مشخص میشود. اتریوم از طولانی ترین قانون زنجیره نیز استفاده میکرد؛ با این حال، اکنون که اتریوم بر روی اثبات سهام اجرا میشود، الگوریتم انتخاب فورک بهروزرسانیشدهای را اتخاذ کرد که «وزن» زنجیره را اندازهگیری میکند. وزن، مجموع آرای جمع شده اعتبارسنج است که توسط موجودیهای اتر سهامگذاری شده اعتبارسنج وزن میشود.
-
-اتریوم از مکانیزم اجماع به نام [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) استفاده می کند که [Casper FFG proof-of-stake](https://arxiv.org/abs/1710.09437) را با [قانون انتخاب فورکGHOST](https://arxiv.org/abs/2003.03052) ترکیب می کند.
-
-## بیشتر بخوانید {#further-reading}
-
-- [الگوریتم اجماع زنجیرهی بلوکی چیست؟](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
-- [اجماع ناکاموتو چیست؟ راهنمای کامل مبتدیها](https://blockonomi.com/nakamoto-consensus/)
-- [Casper چگونه کار میکند؟](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
-- [دربارهی ایمنی و کارایی زنجیرههای بلوکی مبتنی بر اثبات کار](https://eprint.iacr.org/2016/555.pdf)
-- [تحمل خطای بیزانس](https://en.wikipedia.org/wiki/Byzantine_fault)
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
-- [استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
-- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
-- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
deleted file mode 100644
index 7dcecc1f3e3..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md"
+++ /dev/null
@@ -1,163 +0,0 @@
----
-title: حمله به پذیرش حق مشارکت در بلاکچین اتریوم و مقابله با آن
-description: در مورد راه های شناخته شده حمله به پذیرش حق مشارکت در بلاکچین اتریوم و نحوه مقابله با آنها بیشتر بدانید.
-lang: fa
----
-
-سارقان و خرابکارها همواره در پی فرصتی هستند تا به نرمافزار دسترسی به شبکه اتریوم حمله کنند. این مقاله به معرفی راه های شناخته شده حمله به لایه اجماع بلاکچین اتریوم و نحوه مقابله با آنها میپردازد. اطلاعات این صفحه از یک [نسخه بلندتر](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) گرفته شده است.
-
-## پیشنیازها {#prerequisites}
-
-مقداری اطلاعات پایه درباره [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) ضروری است. همچنین داشتن دانش پایه درباره [لایه پاداش](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) در اتریوم و الگوریتم انتخاب شاخه های بلاکچین، [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) مفید خواهد بود.
-
-## مهاجمان چه میخواهند؟ {#what-do-attackers-want}
-
-یک تصور غلط رایج این است که یک مهاجم موفق میتواند اتر جدید تولید کند یا اتر را از حسابهای دلخواه تخلیه کند. هیچ یک از اینها امکانپذیر نیست زیرا تمام تراکنشها توسط همه کاربرهای اجرا در شبکه اجرا میشوند. تراکنشها باید شرایط اولیه اعتبار را رعایت کنند (مثلاً تراکنش باید توسط کلید خصوصی فرستنده امضا شده باشد، فرستنده موجودی کافی داشته باشد و غیره) در غیر اینصورت به سادگی برگشت داده میشوند. سه کلاس خروجی اصلی که یک مهاجم میتواند آنها را مورد هدف قرار دهد عبارت است از تنظیم مجدد (reorgs)، قطعیت مضاعف (double finality) یا تاخیر در قطعیت (finality delay).
-
-منظور از **تنظیم مجدد** تغییر شکل بلوکها با یک نظم جدید است که ممکن است با مقداری جمع و تفرق در زنجیره اصلی انجام شود. یک تنظیم مجدد مخرب میتواند از اضافه شدن یا نشدن بلوکهای خاص اطمینان حاصل کند که میتواند منجر به خرج مضاعف یا استخراج ارزش به وسیله پیش دستی با پس دستی در تراکنشها (MEV) شود. تنظیم مجدد همچنین برای جلوگیری از ورود برخی از تراکنشها به زنجیره اصلی قابل استفاده است که نوعی سانسور در شبکه ایجاد میکند. شدیدترین حالت تنظیم مجدد مربوط به «برگشت قطعیت» است که بلوکهایی که قبلا قطعی شدهاند را حذف یا جایگزین میکند. این اتفاق تنها در حالتی رخ میدهد که بیش از یک سوم اترهای سهامگذاری شده توسط مهاجم از بین بروند. این تضمین با عنوان «قطعیت اقتصادی» شناخته میشود که بعدا به آن پرداخته میشود.
-
-**قطعیت مضاعف** شرایط بعید اما شدیدی است که در آن دو فورک از زنجیره به طور همزمان قطعی میشوند که باعث ایجاد یک شکاف دائمی در زنجیره میشود. انجام این کار از نظر تئوری برای مهاجمی که مایل به ریسک 34 درصد از کل اتر سهامگذاری شده است، امکانپذیر است. در این شرایط جامعه مجبور خواهد شد خارج از زنجیره هماهنگ شود و به توافق برسند که کدام زنجیره را دنبال کنند، که این کار مستلزم استحکام در لایه اجتماعی است.
-
-حمله **تاخیر در قطعیت** از رسیدن شبکه به شرایط لازم برای قطعی کردن بخشهای زنجیره جلوگیری میکند. بدون قطعی شدن، به سختی میتوان به برنامههای کاربردی ساخته شده بر روی اتریوم اعتماد کرد. هدف یک حمله تاخیر در قطعیت، به احتمال زیاد صرفاً ایجاد اختلال در اتریوم به جای سود مستقیم است، مگر اینکه مهاجم موقعیت(های) کوتاه استراتژیک داشته باشد.
-
-حمله به لایه اجتماعی ممکن است با هدف تضعیف اعتماد عمومی به اتریوم، کاهش ارزش اتر، کاهش پذیرش یا تضعیف جامعه اتریوم برای دشوارتر کردن هماهنگی خارج از باند باشد.
-
-حالا و پس از مشخص شدن اینکه چرا یک مهاجم ممکن است به اتریوم حمله کند، بخشهای زیر به بررسی _چگونگی_ انجام این حملات میپردازد.
-
-## روشهای حمله {#methods-of-attack}
-
-### حملات لایه 0 {#layer-0}
-
-اول از همه، افرادی که به طور فعال در اتریوم مشارکت نمیکنند (با اجرای نرمافزار کاربر) میتوانند با هدف قرار دادن لایه اجتماعی (لایه 0) اقدام به حمله کنند. لایه 0 پایهای است که اتریوم بر روی آن بنا شده و به این ترتیب سطحی بالقوه برای حملات با عواقبی است که در بقیه پشته گسترش مییابد. برخی از نمونههای احتمالی:
-
-- یک کمپین اطلاعات غلط میتواند اعتماد جامعه به نقشه راه اتریوم، تیمهای توسعهدهندگان، برنامهها، و غیره را از بین ببرد. این امر میتواند تعداد افرادی را که مایل به مشارکت در تامین امنیت شبکه هستند کاهش دهد و هم عدمتمرکز و هم امنیت اقتصادی رمزارز را کاهش دهد.
-- حملات و/یا ارعاب هدفمند به سمت جامعه توسعهدهندگان. این امر میتواند منجر به خروج داوطلبانه توسعهدهندگان و کند شدن پیشروی اتریوم شود.
-
-- قوانین سختگیرانه می تواند حمله به لایه 0 به شمار آید، چرا که می تواند به سرعت در پذیرش و مشارکت تاثیر منفی ایجاد کند.
-- نفوذ طرفهای مطلع ولی بدخواه به جامعه توسعهدهندگان که هدف آنها کاهش سرعت پیشرفت با بحثهای تمامنشدنی، به تاخیر انداختن تصمیمات کلیدی، ایجاد مباحث هرز، و غیره است.
-- رشوههایی به طرفهای کلیدی اکوسیستم اتریوم داده میشود تا بر تصمیمگیری اثر بگذارند.
-
-چیزی که این حملات را به طور ویژه خطرناک میکند این است که در بسیاری از موارد سرمایه یا دانش فنی بسیار کمی مورد نیاز است. یک حمله لایه 0 میتواند تشدیدکننده یک حمله اقتصاد رمزارزی باشد. برای نمونه، اگر سانسور یا برگشت نهایی شدن از سوی یکی از سهامداران عمده بدخواه اگر انجام شود، و به این ترتیب قشر اجتماعی را تضعیف کند، هماهنگی برای تصمیمی گروهی را ممکن است سختتر کند.
-
-در برابر حملات به لایه 0 احتمالا دفاعی سر راست وجود ندارد، اما برخی اصول بنیادی را می توان اینجا مقرر کرد. یکی از آنها دستیابی به نسبت اطلاعات درست به غلط بالا درباره ی اتریوم در سطح دانش عمومی است که از سوی اعضای راستین این انجمن در بلاگ ها و سرورهای دیسکورد و گزارش های تفسیری و کتاب ها و پادکست ها و یوتیوب ایجاد و منتشر می شود. ما در این وبسایت سخت تلاش می کنیم تا اطلاعات دقیق به دست آوریم و آن را تا جای ممکن به زبان های دیگر ترجمه کنیم. محیطی سرشار از اطلاعات نوشتاری و تصویری با کیفیت بالا در برابر داده های غلط دفاعی مؤثر به شمار می آید.
-
-دیگر سنگر مهم در برابر حملات قشر اجتماعی بانفوذ داشتن چشم اندازی روشن و اعمال مجموعه قوانین مرتبط با آن است. اتریوم خود را بهعنوان قهرمان عدمتمرکز و امنیت در میان لایههای قرارداد هوشمند 1 قرار داده است، در حالی که به مقیاسپذیری و پایداری نیز اهمیت زیادی میدهد. هر گونه اختلاف نظر در جامعه اتریوم رخ دهد، این اصول اصلی در کمترین حد به خطر افتاده است. ارزیابی یک روایت در برابر این اصول اصلی، و بررسی آنها از طریق دورهای متوالی بررسی در فرآیند EIP (پیشنهاد بهبود اتریوم)، ممکن است به جامعه کمک کند تا بازیگران خوب را از بد تشخیص دهد و دامنه نفوذ بازیگران مخرب بر مسیر آینده اتریوم را محدود کند.
-
-در نهایت، بسیار مهم است که جامعه اتریوم باز و پذیرای همه شرکتکنندگان باشد. جامعهای همراه با نگهبانان و برونداری، بهطور ویژهای در برابر حملات اجتماعی آسیب پذیر است زیرا ساختن روایت های «ما و آنها» آسان است. قبیله گرایی و اکثریتگرایی سمی به جامعه آسیب می رساند و امنیت لایه0 را از بین می برد. اتربازهایی که به امنیت شبکه علاقه دارند، باید رفتار خود را بهصورت آنلاین و در فضای پوشیده بهعنوان مشارکتکننده مستقیم در امنیت لایه0 اتریوم ببینند.
-
-### حمله به پروتکل {#attacking-the-protocol}
-
-هر کسی می تواند نرمافزار کلاینت اتریوم را اجرا کند. برای افزودن اعتبارسنج به کلاینت، کاربر باید 32 اتر را در قرارداد سپردهگذاری کند. یک اعتبار سنج به کاربر اجازه می دهد تا با پیشنهاد و تأیید بلوک های جدید، فعالانه در امنیت شبکه اتریوم شرکت کند. اعتبارسنج اکنون پیغامی دارد که می تواند از آن برای تأثیرگذاری بر محتویات آینده بلاکچین استفاده کند - آنها می توانند صادقانه این کار را انجام دهند و ذخیره اتر خود را از طریق پاداش افزایش دهند یا می توانند سعی کنند روند را به نفع خود دستکاری کنند و سهام خود را به خطر بیندازند. یکی از راههای انجام حمله، جمعآوری نسبت بیشتری از کل سهام و سپس استفاده از آن برای برتری دادن به اعتبارسنجهای صادق است. هر چه نسبت سهام کنترل شده توسط مهاجم بیشتر باشد، قدرت رای آنها بیشتر می شود، به ویژه در برخی نقاط عطف اقتصادی که بعداً بررسی خواهیم کرد. با این حال، اکثر مهاجمان نمیتوانند اتر کافی برای حمله به این روش جمع کنند، بنابراین در عوض باید از تکنیکهای ظریف برای دستکاری اکثریت صادق استفاده کنند تا به روش خاصی عمل کنند.
-
-اساساً، همه حملات سهام کوچک، تغییرات ظریفی در دو نوع رفتار نادرست اعتبارسنج هستند: فعالیت کم (عدم تأیید/پیشنهاد یا انجام آن با تأخیر) یا فعالیت بیشازحد (پیشنهاد/تثبیت بیشازحد در یک اسلات). در روانترین شکلهایشان، این اقدامات به راحتی توسط الگوریتم انتخاب فورک و لایه انگیزشی انجام میشود، اما راههای هوشمندانهای برای بازی کردن سیستم به نفع مهاجم وجود دارد.
-
-### حملاتی با استفاده از مقادیر کم اتر {#attacks-by-small-stakeholders}
-
-#### دوبارهچینی {#reorgs}
-
-چندین مقاله حملاتی را به اتریوم توضیح دادهاند که تنها با بخش کوچکی از کل اتر سهامگذاریشده، به سازمانهای مجدد یا تاخیر نهایی میرسند. این حملات عموماً متکی بر این است که مهاجم برخی از اطلاعات را از اعتباسنجهای دیگر مخفی میکند و سپس آن را به روشهای ظریف و/یا در لحظهای مناسب منتشر میکند. هدف آنها معمولاً جابجایی برخی بلوک های صادق از زنجیره متعارف است. [نیودر و همکاران، 2020](https://arxiv.org/pdf/2102.02247.pdf) نشان دادند که چگونه یک اعتبارسنج مهاجم می تواند یک بلوک (`B`) برای یک اسلات خاص `n+1` ایجاد کند و تأیید کند، اما از انتشار آن به سایر گرههای شبکه خودداری کند. در عوض، آنها آن بلوک تایید شده را تا اسلات بعدی `n+2` نگه میدارند. یک اعتبارسنج صادق یک بلوک (`C`) برای اسلات `n+2` پیشنهاد میکند. تقریباً همزمان، مهاجم میتواند بلوک پنهانشده خود (`B`) و گواهیهای پنهانشده خود را برای آن آزاد کند، و همچنین با رأیهای خود برای اسلات نشان دهد که `B` رئیس زنجیره است`n+2`، به طور مؤثر وجود بلوک صادق `C` را انکار می کند. وقتی بلوک صادق `D` آزاد می شود، الگوریتم انتخاب فورک می بیند که ساختمان `D` بالای `B` سنگین تر از ساختمان `D` روی `C` است. بنابراین مهاجم موفق شده است بلوک صادق `C` در اسلات `n+2` را با استفاده از یک دوبارهچینی قبلی حذف کند. [یک مهاجم با 34٪](https://www.youtube.com/watch?v=6vzXwwk12ZE) از سهام شانس بسیار خوبی برای موفقیت در این حمله دارد، همانطور که [در این یادداشت](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) توضیح داده شده است. بااینحال، در تئوری، این حمله می تواند با سهام کوچکتر انجام شود. [نیودر و همکاران، 2020](https://arxiv.org/pdf/2102.02247.pdf) توصیف کردند که این حمله با 30٪ سهام کار می کند، اما بعداً نشان داده شد که با [2٪ از کل سهام](https://arxiv.org/pdf/2009.04987.pdf) قابل اجرا است و سپس مجدداً برای یک [اعتبارسنج واحد](https://arxiv.org/abs/2110.10086#) با استفاده از تکنیک های متعادل سازی در بخش بعدی بررسی خواهیم کرد.
-
-![ex-ante re-org](reorg-schematic.png)
-
-یک نمودار مفهومی از حمله دوبارهچینی یک بلوکی که در بالا توضیح داده شد (اقتباس از https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair)
-
-یک حمله پیچیدهتر میتواند مجموعه اعتبارسنج صادق را به گروههای مجزا تقسیم کند که دیدگاههای متفاوتی از رئیس زنجیره دارند. این به عنوان **حمله متعادل کننده** شناخته می شود. مهاجم منتظر فرصت خود برای پیشنهاد یک بلوک است، و هنگامی که آن بلوک می رسد، آن دو را به اشتباه می اندازند و پیشنهاد ارائه میدهند. آنها یک بلوک را به نیمی از مجموعه اعتبارسنج صادق و بلوک دیگر را به نیمی دیگر ارسال می کنند. ابهام توسط الگوریتم فورک انتخاب تشخیص داده می شود و پیشنهاد دهنده بلوک جریمه می شود و از شبکه خارج می شود، اما این دو بلوک همچنان وجود دارند و حدود نیمی از مجموعه اعتبارسنج برای هر فورک تایید می شود. در همین حال، اعتبار سنجهای مخرب باقی مانده، تأییدیه های خود را متوقف می کنند. سپس، با رها کردن انتخابی تاییدیههایی که به نفع یک یا آن فورک هستند به اعتبارسنجهای کافی درست همانطور که الگوریتم انتخاب فورک اجرا میشود، وزن انباشته گواهیها را به نفع یک یا آن فورک منحرف میکنند. با تاییدکنندههای مهاجم که تقسیم یکنواختی از اعتبار سنجها را در دو فورک حفظ می کنند، این اتفاق میتواند بهطور نامحدود ادامه یابد. از آنجایی که هیچ یک از دو فورک نمی توانند اکثریت 2/3 را جذب کنند، شبکه نهایی نمی شود.
-
-**حملات برگشتی** هم همینطورند. رایها مجدداً توسط اعتبارسنج مهاجم متوقف میشوند. به جای آزاد کردن آرا برای حفظ تقسیم یکنواخت بین دو فورک، آنها از آرای خود در لحظات مناسب برای توجیه نقاط بازرسی که به طور متناوب بین فورک A و فورک B استفاده می کنند استفاده می کنند. این تلنگر توجیهی بین دو فورک مانع از وجود جفتهای چکپوینتهای منبع و هدف می شود که می توانند در هر زنجیره نهایی شوند که نتیجتاً نهایی شدن را متوقف می کند.
-
-
-
-هر دو حمله برگشتی و متعادل کننده متکی به این هستند که مهاجم کنترل بسیار خوبی بر زمانبندی پیام در سراسر شبکه داشته باشد، که البته بعید است. با این وجود، دفاعها به شکل وزندهی اضافی به پیامهای سریع در مقایسه با پیامهای آهسته در پروتکل تعبیه شدهاند. که به عنوان [افزایش وزن پیشنهاد دهنده](https://github.com/ethereum/consensus-specs/pull/2730) شناخته می شود. برای دفاع در برابر حملات پرش، الگوریتم انتخاب-فورک بهروزرسانی شد تا آخرین چکپوینت توجیهشده فقط بتواند در طول [1/3 اول اسلاتها در هر ایپاک](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) به زنجیره جایگزین سوییچ کند. این شرایط مانع از ذخیره آرای مهاجم برای استقرار بعدی میشود - الگوریتم انتخاب فورک به سادگی به نقطه بازرسی که در 1/3 اول ایپاک انتخاب کرده بود وفادار میماند که طی آن اکثر اعتبارسنجهای صادق رای میدادند.
-
-در مجموع، این اقدامات سناریویی را ایجاد میکنند که در آن یک پیشنهاد دهنده بلوک صادق، بلوک خود را خیلی سریع پس از شروع اسلات منتشر میکند، سپس یک دوره حدود 1/3 از اسلات (4 ثانیه) وجود دارد که در آنجا آن بلوک جدید ممکن است باعث شود که الگوریتم انتخاب فورک به زنجیره دیگری سوییچ کند. پس از همان مهلت، گواهیهایی که از اعتبارسنجهای کُند میآیند در مقایسه با مواردی که زودتر رسیدهاند، کاهش مییابند. این امر به شدت به پیشنهاد دهندگان و تایید کنندگان سریع در تعیین سر زنجیره کمک می کند و به طور قابل توجهی احتمال یک حمله موفقیت آمیز متعادل کننده یا برگشتی را کاهش می دهد.
-
-شایان ذکر است که تقویت پیشنهاد دهنده به تنهایی تنها در برابر «دوبارهچینی ارزان»، یعنی حملاتی که توسط مهاجمی با سهام کوچک انجام می شود، دفاع می کند. در واقع، خود افزایش پیشنهاد دهنده می تواند توسط سهامداران بزرگتر بازی کند. نویسندگان [این پست](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) توضیح میدهند که چگونه یک مهاجم با 7٪ از سهام میتواند آرای خود را به صورت استراتژیک به کار گیرد تا اعتبارسنجهای صادق را فریب دهد تا بر روی فورک خود بلوک بسازند که نتیجتاً یک بلوک صادق را دوبارهچینی کنند. این حمله با فرض شرایط تأخیر ایده آل که بسیار بعید است ابداع شد. شانس برای مهاجم هنوز بسیار کم است و سهام بیشتر به معنای سرمایه بیشتر در معرض خطر و یک بازدارنده اقتصادی قوی تر است.
-
-یک [حمله متعادل کننده که به طور خاص قانون LMD را هدف قرار می دهد](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) نیز ارائه شد که پیشنهاد شد علیرغم افزایش پیشنهاد دهنده قابل اجرا باشد. یک مهاجم دو زنجیره رقیب را با مبهم کردن طرح بلوک خود و انتشار هر بلوک به حدود نیمی از شبکه ایجاد می کند و تعادل تقریبی بین فورک ها را ایجاد می کند. سپس، اعتبار دهندگان تبانی آرای خود را مبهم می کنند و زمانبندی آن را به گونه ای تنظیم می کنند که نیمی از شبکه ابتدا رای خود را برای فورک`A` و نیمی دیگر رای خود را برای فورک `B` دریافت کنند. از آنجایی که قانون LMD تأیید دوم را کنار میگذارد و فقط اولی را برای هر اعتبارسنج نگه میدارد، نیمی از شبکه رایها را برای `A` و هیچ چیز دیگری برای `B` میبیند، نیمی دیگر نیز رایها را برای `B` و هیچ رأیی را برای `A` نمی بینند. نویسندگان قانون LMD را توصیف می کنند که به حریف «قدرت قابل توجهی» می دهد تا یک حمله متعادل کننده را انجام دهد.
-
-این بردار حمله LMD با [بهروزرسانی الگوریتم انتخاب فورک](https://github.com/ethereum/consensus-specs/pull/2845) بسته شد تا اعتبارسنجهای مبهمکننده را بهکلی از بررسی انتخاب فورک دور کند. اعتبارسنجهای مبهمکننده نیز تأثیر آتی خود را با الگوریتم انتخاب فورک کاهش می دهند. این امر از حمله متعادلکننده که در بالا ذکر شد جلوگیری می کند و در عین حال انعطاف پذیری در برابر حملات آوالانچ را نیز حفظ می کند.
-
-دسته دیگری از حملات، به نام [**حملات آوالانچ**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3)، در [مقاله مارس 2022](https://arxiv.org/pdf/2203.01315.pdf) توضیح داده شده است. برای انجام یک حمله آوالانچ، مهاجم باید چندین بلوک پیشنهاد دهنده متوالی را کنترل کند. در هر یک از اسلاتهای پیشنهادی بلوک، مهاجم بلوک خود را نگه میدارد و آنها را جمع میکند تا زمانی که زنجیره صادق به وزن زیر درختی برابر با بلوکهای پنهان شده برسد. سپس، بلوکهای نگهداشتهشده آزاد میشوند تا در حداکثر توان مبهمسازی کنند. نویسندگان گفتند که تقویت پیشنهاد دهنده بلوک - دفاع اولیه در برابر حملات متعادل کننده و برگشتی- در برابر برخی از انواع حملات آوالانچ ناتوان از محافظت است. با این حال، نویسندگان تنها حمله به نسخه بسیار ایده آل الگوریتم انتخاب فورک اتریوم را نشان دادند (آنها از GHOST بدون LMD استفاده کردند).
-
-حمله آوالانچ توسط بخش LMD الگوریتم انتخاب فورک LMD-GHOST کاهش می یابد. LMD به معنای «جدیدترین پیام محور» است و به جدولی اشاره دارد که توسط هر اعتبارسنج نگهداری میشود و حاوی آخرین پیام دریافتی از اعتبارسنجهای دیگر است. این فیلد فقط در صورتی بهروزرسانی میشود که پیام جدید از اسلات دیگری نسبت به آنچه قبلاً در جدول برای اعتبارسنج خاصی وجود دارد، باشد. در عمل، این بدان معنی است که در هر اسلات، اولین پیام دریافت شده همان پیامی است که پذیرفته شده است و هر پیام اضافی مبهمکننده است که باید نادیده گرفته شود. به عبارت دیگر، کلاینتهای اجماع ابهامات را به حساب نمیآورند - آنها از اولین پیام ارسالی از هر اعتبارسنج استفاده میکنند و مبهمکنندهها به سادگی کنار گذاشته میشوند و از حملات آوالانچی جلوگیری میکنند.
-
-چندین ارتقاء بالقوه دیگر در قانون انتخاب فورک وجود دارد که می تواند به امنیت ارائه شده توسط proposer-boost بیفزاید. یکی [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) است، که در آن گواهیدهندهها دیدگاه خود از انتخاب فورک را `n` ثانیه قبل از شروع یک اسلات ثابت میکنند و پیشنهاددهنده بلوک سپس به همگامسازی نمای زنجیره در سراسر شبکه کمک میکند. ارتقای احتمالی دیگر [single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality) است که با نهایی کردن زنجیره تنها پس از یک اسلات در برابر حملات بر اساس زمانبندی پیام محافظت می کند.
-
-#### تاخیر نهاییسازی {#finality-delay}
-
-[همان مقاله](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) که برای اولین بار حمله کم هزینه دوبارهچینی یک بلوک را توصیف کرد، همچنین یک حمله تاخیر نهاییسازی (معروف به "شکست زندگی") را توصیف کرد که متکی به مهاجم است که پیشنهاد دهنده بلوک برای بلوک لبمرز ایپاک است. این موضوع بسیار مهم است زیرا این بلوکهای لبمرز ایپاک تبدیل به نقاط بازرسی می شوند که Casper FFG از آنها برای نهایی کردن بخش هایی از زنجیره استفاده می کند. مهاجم به سادگی از بلوک خود جلوگیری می کند تا زمانی که اعتبارسنجهای صادق کافی از آرای FFG خود به نفع بلوک مرزی ایپاک قبلی به عنوان هدف نهایی سازی فعلی استفاده کنند. سپس بلوک پنهان شده خود را آزاد می کنند. آنها بلوک خود را تأیید می کنند و اعتبارسنجهای صادق باقی مانده نیز فورکهایی با نقاط بازرسی دارای هدف متفاوت ایجاد می کنند. اگر آنها آن را درست زمانبندی کنند، از نهایی شدن جلوگیری می کنند، زیرا 2/3 اکثریت فوقالعاده ای وجود نخواهد داشت که هر دو فورک را تأیید کند. هرچه سهام کوچکتر باشد، زمانبندی باید دقیق تر باشد، زیرا مهاجم گواهی های کمتری را مستقیماً کنترل می کند، و احتمال اینکه مهاجم کنترل کننده اعتبارسنج را برای یک بلوک مرزی ایپاک معین پیشنهاد کند، کمتر می شود.
-
-#### حملات دوربرد {#long-range-attacks}
-
-همچنین دستهای از حملات خاص برای بلاکچینهای اثبات سهام وجود دارد که شامل اعتبارسنجی است که در بلوک جنسیس شرکت کرده و یک فورک جداگانه از بلاکچین را در کنار فورک صادق نگه میدارد، و در نهایت اعتباردهنده صادق را متقاعد می کند که در زمان مناسبی بعداً به آن روی بیاورد. این نوع حمله به اتریوم امکانپذیر نیست، زیرا این ابزار نهایی تضمین می کند که همه اعتبارسنج ها در فواصل زمانی منظم در مورد حالت زنجیره صادق اجماع دارند ("نقاط بازرسی"). این مکانیزم ساده، مهاجمان دوربرد را خنثی می کند، زیرا کلاینتهای اتریوم به سادگی بلوک های نهاییشده را دوبارهچینی نمی کنند. گرههای جدیدی که به شبکه میپیوندند، این کار را با یافتن یک هش حالت اخیر مورد اعتماد (یک «[سوژه ضعیف](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) نقطه بازرسی») و استفاده از آن بهعنوان یک بلوک شبه جنسیس برای ایجاد در بالای آن انجام میدهند. این یک "دروازه اعتماد" برای یک گره جدید که وارد شبکه می شود قبل از اینکه بتواند اطلاعات را برای خود تأیید کند ایجاد می کند.
-
-#### رد خدمات {#denial-of-service}
-
-مکانیسم اثبات سهام اتریوم یک اعتبارسنج را از مجموع اعتبارسنجها انتخاب میکند تا پیشنهاددهنده بلوک در هر اسلات باشد. این را می توان با استفاده از یک تابع شناخته شده عمومی محاسبه کرد و این امکان برای مهاجم وجود دارد که پیشنهاددهنده بلوک بعدی را کمی قبل از پیشنهاد بلوک خود شناسایی کند. سپس، مهاجم می تواند پیشنهاد دهنده بلوک را اسپم کند تا از مبادله اطلاعات با همتایان خود جلوگیری کند. برای بقیه شبکه، به نظر می رسد که پیشنهاد دهنده بلوک آفلاین است و اسلات به سادگی خالی می شود. این می تواند نوعی سانسور علیهاعتبارسنج های خاص باشد و از افزودن اطلاعات به بلاکچین جلوگیری کند. اجرای انتخابات رهبر مخفی منفرد (SSLE) یا انتخابات رهبر مخفی غیر منفرد خطرات DoS را کاهش می دهد زیرا فقط پیشنهاد دهنده بلوک میداند که آنها انتخاب شده اند و انتخاب از قبل قابل اطلاع نیست. این هنوز اجرا نشده است، اما یک حوزه فعال در [تحقیق و توسعه](https://ethresear.ch/t/secret-non-single-leader-election/11789) است.
-
-همه اینها به این واقعیت اشاره دارد که حمله موفقیت آمیز به اتریوم با یک سهم کوچک بسیار دشوار است. حملات قابل اجرا که در اینجا توضیح داده شده اند به یک الگوریتم انتخاب فورک ایده آل، شرایط شبکه نامحتمل نیاز دارند، یا بردارهای حمله قبلاً با پچهای نسبتاً جزئی برای نرمافزار کلاینت منحل شده اند. البته این امر امکان وجود باگهای زیرودی در ماهیت کد را رد نمیکند، اما نشاندهنده استعداد بسیار بالای استعداد فنی، دانش لایههای اجماع و شانس مورد نیاز برای مؤثر بودن یک مهاجم با سهام حداقلی است. از دیدگاه یک مهاجم، بهترین گزینه ممکن است این باشد که تا حد ممکن اتر جمع کنند و با نسبت بیشتری از کل سهام بازگردد.
-
-### مهاجمانی که از کمتر/مساوی 33% از سهام کل استفاده میکنند {#attackers-with-33-stake}
-
-همه حملاتی که قبلاً در این مقاله ذکر شد، زمانی احتمال موفقیت بیشتری پیدا میکنند که مهاجم دارای اتر بیشتری برای رأی دادن باشد، و اعتبارسنجهای بیشتری که ممکن است برای پیشنهاد بلوکها در هر اسلات انتخاب شوند. بنابراین، یک اعتبارسنج خرابکار ممکن است قصد داشته باشد تا حد امکان اتر سهامگذاریشده را کنترل کند.
-
-33 درصد از اتر سهامگذاری شده معیاری برای مهاجمان است زیرا با هر چیزی بیشتر از این، آنها توانایی جلوگیری از نهایی شدن زنجیره را بدون نیاز به کنترل دقیق اقدامات اعتبارسنجهای دیگر دارند. آنها به سادگی می توانند همه با هم ناپدید شوند. اگر یکسوم یا بیشتر از اتر سهامگذاری شده به طور مخربی بلوک را تأیید کند یا نتواند تأیید کند، در این صورت دوسوم اکثریت نمیتواند وجود داشته باشد و زنجیره نمیتواند نهایی شود. نشت عدم فعالیت یک دفاع در برابر این حمله است. نشت عدم فعالیت آن دسته از اعتبارسنجهایی را شناسایی میکند که در تأیید ناکام هستند یا بر خلاف اکثریت دست به تایید می زنند. اتر سهامگذاریشده متعلق به این اعتبارسنجهای غیر تأییدکننده به تدریج از بین میرود تا اینکه در نهایت آنها در مجموع کمتر از 1/3 کل را نشان میدهند تا زنجیره بتواند دوباره نهایی شود.
-
-هدف از نشت عدم فعالیت، نهایی شدن مجدد زنجیره است. با این حال، مهاجم همچنین بخشی از اتر سهامگذاریشدهی خود را از دست می دهد. عدم فعالیت مداوم در اعتبارسنجهایی که 33 درصد از کل اتر سهامگذاری شده را نشان میدهد، بسیار گران است، حتی اگر اعتبارسنجها قطع نشده باشند.
-
-با فرض اینکه شبکه اتریوم ناهمزمان است (یعنی تاخیرهایی بین ارسال و دریافت پیام ها وجود دارد)، مهاجمی که 34 درصد از کل سهام را کنترل می کند می تواند باعث نهایی شدن دو برابره شود. این کار به این دلیل است که مهاجم میتواند زمانی که به عنوان تولیدکننده بلوک انتخاب میشود، ابهامسازی کند، سپس با همه اعتبارسنجهای رای دو برابری بدهد. این اتفاق وضعیتی را ایجاد می کند که در آن یک فورک از بلاکچین وجود دارد که هر کدام 34 درصد از اترهای سهامگذاری شده به آن رای می دهند. هر فورک فقط به 50 درصد اعتبارسنجهای باقیمانده نیاز دارد که به نفع آن رای دهند تا هر دو فورک توسط اکثریت فوقالعاده پشتیبانی شوند، در این صورت هر دو زنجیره میتوانند نهایی شوند (زیرا 34 درصد اعتبارسنج مهاجمان + نیمی از 66 درصد باقیمانده = 67 درصد روی هر فورک). بلوکهای رقیب هر کدام باید توسط حدود 50 درصد اعتبارسنجهای صادق دریافت شوند، بنابراین این حمله تنها زمانی قابل اجرا است که مهاجم تا حدودی بر زمانبندی پیام هایی که در شبکه منتشر می شوند کنترل داشته باشد تا بتواند نیمی از اعتبارسنج های صادق را به هر زنجیره هدایت کند. مهاجم برای دستیابی به این قطعیت مضاعف، لزوماً کل سهام خود را نابود میکند (34 درصد از 10 میلیون اتر با مجموعه اعتبارسنج امروزی) زیرا 34 درصد از تأییدکنندگان آنها به طور همزمان رأی مضاعف میدهند - یعنی یک تخلف قابل کاهش با حداکثر مجازات در همبستگی. دفاع مناسب در برابر این حمله هزینه بسیار زیاد از بین بردن 34 درصد از کل اتر سهامگذاری شده است. بازیابی از این حمله مستلزم آن است که جامعه اتریوم "بیرون از بازی" هماهنگ باشد و موافقت کند که یکی از فورک ها را دنبال کند و دیگری را نادیده بگیرد.
-
-### مهاجمانی که از 50% کل سهام استفاده می کنند {#attackers-with-50-stake}
-
-در 50% اتر سهامگذاری شده، گروهی از اعتبارسنجهای شرور میتوانند از نظر تئوری زنجیره را به دو فورک با اندازه مساوی تقسیم کنند و سپس به سادگی از کل 50% سهام خود استفاده کنند تا بر خلاف مجموعه اعتبارسنج صادق رای دهند، در نتیجه دو فورک را حفظ کرده و از نهایی شدن جلوگیری کنند. نشت عدم فعالیت در هر دو فورک در نهایت منجر به نهایی شدن هر دو زنجیره می شود. در این مرحله، تنها گزینه بازگشت به ریکاوری اجتماعی است.
-
-بسیار بعید است که یک گروه متخاصم از اعتبارسنجها بتوانند دقیقاً 50 درصد از کل سهام را با توجه به درجهای از نوسان در شمار اعتبارسنج صادقانه، تأخیر شبکه و غیره کنترل کنند - به نظر می رسد هزینه هنگفت ایجاد چنین حمله ای همراه با احتمال کم موفقیت، یک بازدارنده قوی برای یک مهاجم منطقی باشد، به خصوص زمانی که یک سرمایهگذاری کوچک اضافی برای به دست آوردن _بیش از_ 50% قدرت بسیار بیشتری را به ارمغان میآورد.
-
-در >50درصد از کل سهام، مهاجم می تواند بر الگوریتم انتخاب فورک تسلط داشته باشد. در این حالت، مهاجم میتواند با اکثریت آرا تأیید کند و به آنها کنترل کافی برای انجام دوبارهچینیهای کوتاه بدون نیاز به فریب دادن کلاینتهای صادق بدهد. اعتبارسنجهای صادق از این روش پیروی میکنند زیرا الگوریتم انتخاب فورک آنها نیز زنجیره مورد علاقه مهاجم را سنگینترین میداند، بنابراین زنجیره میتواند نهایی شود. این امر مهاجم را قادر میسازد تا تراکنشهای خاصی را سانسور کند،دوبارهچینیهای کوتاهبُرد انجام دهد و با مرتب کردن مجدد بلوکها به نفع خود، حداکثر MEV را استخراج کند. دفاع در برابر این هزینه هنگفت همان سهام اکثریت (در حال حاضر کمتر از 19 میلیارد دلار) است که توسط یک مهاجم در معرض خطر قرار میگیرد، زیرا احتمالاً لایه اجتماعی وارد عمل شده و یک فورک اقلیت صادق را اتخاذ میکند و ارزش سهام مهاجم را به شدت کاهش میدهد.
-
-### مهاجمانی که از >=66٪ از کل سهام استفاده می کنند {#attackers-with-66-stake}
-
-مهاجمی با 66% یا بیشتر از کل اتر سهامگذاری شده میتواند زنجیره مورد نظر خود را بدون نیاز به وادار کردن هیچ اعتبارسنج صادقی نهایی کند. مهاجم میتواند به سادگی به فورک مورد نظر خود رای دهد و سپس آن را نهایی کند، صرفاً به این دلیل که می تواند با اکثریت ناصادق رای دهد. به عنوان ذینفع اکثریت، مهاجم همیشه میتواند محتویات بلوک های نهایی را کنترل کند: با قدرتِ خرج کردن، عقب بردن و دوباره خرج کردن، سانسور برخی تراکنش ها و سازماندهی مجدد زنجیره به شکل دلخواهش. با خرید اتر اضافی برای کنترل 66٪ به جای 51٪، مهاجم به طور مؤثر توانایی انجام مجدد دوبارهچینی و بازگشت نهایی (یعنی تغییر گذشته و همچنین کنترل آینده) را کسب می کند. تنها دفاع واقعی در اینجا هزینه هنگفت 66 درصد از کل اتر سهامگذاری شده و گزینه بازگشت به لایه اجتماعی برای هماهنگ کردن پذیرش یک فورک جایگزین است. در بخش بعدی می توانیم این موضوع را با جزئیات بیشتری بررسی کنیم.
-
-## مردم: آخرین خط دفاع {#people-the-last-line-of-defense}
-
-اگر اعتبارسنجهای ناصادق موفق شوند نسخه دلخواه خودشان از زنجیره را نهایی کنند، جامعه اتریوم در شرایط دشواری قرار می گیرد. زنجیره متعارف شامل یک بخش ناصادقانه است که در تاریخ خود گنجانده شده است، در حالی که تأییدکنندگان صادق می توانند به دلیل تأیید یک زنجیره جایگزین (صادق) مجازات شوند. توجه داشته باشید که یک زنجیره نهایی شده اما نادرست نیز می تواند از یک باگ در کلاینت پراستفاده ایجاد شود. در پایان، بازگشت نهایی، تکیه بر لایه اجتماعی - لایه 0 - برای حل وضعیت است.
-
-یکی از نقاط قوت اجماع اثبات سهام اتریوم این است که [تعدادی از استراتژیهای دفاعی](https://youtu.be/1m12zgJ42dI?t=1712) وجود دارد که جامعه میتواند در مواجهه با حمله از آنها استفاده کند. یک پاسخ حداقلی میتواند خروج اجباری اعتبارسنجهای متعلق ببه مهاجم از شبکه بدون جریمه اضافی باشد. برای ورود مجدد به شبکه، مهاجم باید به صف فعالسازی بپیوندد که تضمین میکند مجموعه اعتبارسنجها به تدریج رشد میکند. به عنوان مثال، افزودن اعتبارسنجهای کافی برای دو برابر کردن مقدار اتر سهامگذاری شده، حدود 200 روز طول میکشد، در واقع اعتبارسنجهای صادق را 200 روز قبل از اینکه مهاجم بتواند حمله 51 درصدی دیگری انجام دهد، خریداری میکند. با این حال، جامعه همچنین میتواند تصمیم بگیرد که مهاجم را با لغو پاداشهای گذشته یا سوزاندن بخشی (تا 100٪) از سرمایه سهامگذاریشدهشان، سختتر مجازات کند.
-
-مجازاتی که برای مهاجم اعمال شود هرچه باشد، جامعه همچنین باید با هم تصمیم بگیرد که آیا زنجیره ناصادق، علیرغم اینکه الگوریتم انتخاب فورک کدگذاری شده در کلاینتهای اتریوم مورد علاقه است، در واقع نامعتبر است و به جای آن جامعه باید در بالای زنجیره صادقانه اقدام به ایجاد بلوک کند. اعتبارسنجهای صادق می توانند به طور جمعی توافق کنند که بلوک را در بالای یک فورک پذیرفته شده توسط جامعه بلاکچین اتریوم ایجاد کنند که ممکن است، برای مثال، زنجیره متعارف را قبل از شروع حمله قطع کرده باشد یا اعتبارسنجهای مهاجمان را به زور حذف کنند. اعتبارسنجهای صادق انگیزه خواهند داشت تا بر روی این زنجیره بلوکسازی کنند، زیرا از مجازات های اعمال شده برای آنها برای عدمتأیید زنجیره مهاجم (که کار خوبی است) اجتناب می کنند. صرافیها، ورودیهای جریان، و برنامههای کاربردی ساختهشده بر روی اتریوم احتمالاً ترجیح میدهند در زنجیره صادق باشند و اعتبارسنجهای صادق را تا بلاکچین صادق دنبال کنند.
-
-با این حال، این یک چالش حاکمیتی اساسی خواهد بود. برخی از کاربران و اعتبارسنجها بدون شک در نتیجه بازگشت به زنجیره صادق ضرر خواهند کرد، تراکنشهای موجود در بلوکهای تایید شده پس از حمله به طور بالقوه میتوانند به عقب برگردند و لایه برنامه را مختل کند، و این امر به سادگی اخلاق برخی از کاربران که به "کد همان قانون است" اعتماد دارند را تضعیف میکند. صرافیها و برنامههای کاربردی به احتمال زیاد اقدامات خارج از زنجیره را به تراکنشهای درون زنجیرهای مرتبط میکنند که ممکن است اکنون به عقب بازگردند، که دومینویی از بازپسگیریها و تجدیدنظرهایی که به سختی میتوان آنها را منصفانه انتخاب کرد شروع خواهد کرد، به خصوص اگر سودهای غیرقانونی به دیفای یا سایر مشتقات با اثرات ثانویه برای کاربران صادق واریز شوند میکس شده باشند. بدون شک برخی از کاربران، شاید حتی افراد نهادی، قبلاً از طریق زیرکی یا از روی خوشفکری از این زنجیره ناصادق بهره می بردند و ممکن بود با یک فورک برای حافظت از دستاوردهای خود مخالفت کنند. فراخوانهایی برای تمرین پاسخ جامعه به حملات >51 درصدی انجام شده است تا بتوان به سرعت یک کاهش هماهنگ معقول انجام داد. بحث مفیدی توسط ویتالیک در ethresear.ch [اینجا](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) و [اینجا](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) و در توییتر [اینجا](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw) وجود دارد. هدف از یک پاسخ اجتماعی هماهنگ باید این باشد که در مورد مجازات مهاجم و به حداقل رساندن اثرات برای سایر کاربران بسیار هدفمند و مشخص باشد.
-
-حاکمیت در حال حاضر یک موضوع پیچیده است. مدیریت یک پاسخ اضطراری لایه 0 به یک زنجیره نهایی ناصادق بدون شک برای جامعه اتریوم چالش برانگیز است، اما [این اتفاق](/history/#dao-fork-summary) - [دوبار](/history/#tangerine-whistle) - در تاریخ اتریوم رخ داده است.
-
-با این وجود، چیزی نسبتاً رضایتبخش در نشست نهایی در زندگی واقعی وجود دارد. در نهایت، حتی با وجود این پشته فنآوری فوقالعاده بالای سرمان، اگر بدترین اتفاق میافتاد، مردم واقعی باید راه خود را برای خروج از آن هماهنگ میکردند.
-
-## خلاصه {#summary}
-
-این صفحه برخی از راههایی را که مهاجمان ممکن است برای سوء استفاده از پروتکل اجماع اثبات سهام اتریوم تلاش کنند را بررسی میکند. دوبارهچینیها و تاخیرهای نهایی برای مهاجمان با افزایش نسبت کل اتر سهامگذاری شده بررسی شدند. به طور کلی، مهاجم ثروتمندتر شانس موفقیت بیشتری دارد زیرا سهام آنها به قدرت رای تبدیل می شود که می توانند از آن برای تأثیرگذاری بر محتوای بلوک های آینده استفاده کنند. در مقادیر آستانه مشخصی از اتر سهامگذاری شده، قدرت مهاجم افزایش می یابد:
-
-33 درصد: تاخیر قطعیت
-
-34 درصد: تاخیر قطعیت، قطعیت دو برابر
-
-51 درصد: تاخیر قطعیت، قطعیت دو برابر، سانسور، کنترل آینده بلاکچین
-
-66 درصد: تأخیر قطعیت، قطعیت دو برابر، سانسور، کنترل آینده و گذشته بلاکچین
-
-همچنین طیف وسیعی از حملات پیچیدهتر وجود دارد که به مقادیر کمی از اتر مستقر نیاز دارند، اما متکی به یک مهاجم بسیار پیشرفته است که کنترل خوبی بر زمانبندی پیام دارد تا اعتبارسنج صادق را به نفع خود سوق دهد.
-
-به طور کلی، با وجود این بردارهای حمله بالقوه، خطر یک حمله موفقیت آمیز کم است، مطمئناً کمتر از معادل های اثبات کار. این به دلیل هزینه هنگفتِ اترِ درمعرضِ خطر است که توسط مهاجمی که قصد دارد اعتبارسنج های صادق را با قدرت رای خود تحت تأثیر قرار دهد. لایه تشویقی تعبیه شده "هویج و چوب" در برابر اکثر تخلفات، به ویژه برای مهاجمان کم خطر محافظت می کند. همچنین بعید است که حملات جهشی و تعادلی ظریفتر موفق شوند زیرا شرایط واقعی شبکه کنترل دقیق تحویل پیام به زیرمجموعههای خاصی از اعتبارسنج ها را بسیار دشوار میکند و تیمهای کلاینت به سرعت بردارهای شناخته شده حملات برگشتی، متعادل کننده و آوالانچ را با وصلههای خنثی کردهاند.
-
-حملات 34 درصد، 51 درصد یا 66 درصد احتمالاً برای حل کردن نیاز به هماهنگی اجتماعی در دنیای واقعی دارند. در حالی که این احتمالاً برای جامعه دردناک است، توانایی یک جامعه برای پاسخگویی خارج از زمین بازی یک عامل بازدارنده قوی برای یک مهاجم است. لایه اجتماعی اتریوم پشتیبان نهایی است - یک حمله فنی موفق هنوز میتواند توسط جامعه با پذیرش یک فورک صادق خنثی شود. یک مسابقه بین مهاجم و جامعه اتریوم وجود خواهد داشت - میلیاردها دلار هزینه شده برای یک حمله 66 درصدی احتمالاً با یک حمله هماهنگی اجتماعی موفقیت آمیز در صورتی که به اندازه کافی سریع تحویل داده شود، از بین می رود و مهاجم را با کیسه های سنگین اتر نقد و سهامگذاری شده اما در یک زنجیره ناصادق که توسط جامعه اتریوم نادیده گرفته شده است، باقی می گذارد. احتمال اینکه این کار برای مهاجم سودآور باشد به اندازه کافی کم است که یک بازدارنده مؤثر باشد. به همین دلیل است که سرمایه گذاری در حفظ یک لایه اجتماعی منسجم با ارزش های کاملاً همسو بسیار مهم است.
-
-## اطلاعات بیشتر {#further-reading}
-
-- [نسخه دقیق تر این صفحه](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [ویتالیک درباره قطعیت تسویه](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
-- [مقاله LMD GHOST](https://arxiv.org/abs/2003.03052)
-- [مقاله Casper-FFG](https://arxiv.org/abs/1710.09437)
-- [مقاله Gasper](https://arxiv.org/pdf/2003.03052.pdf)
-- [مشخصات اجماع افزایش وزن پیشنهاددهنده بلوک](https://github.com/ethereum/consensus-specs/pull/2730)
-- [حملات برگشتی در ethresear.ch](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114)
-- [تحقیقات SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
deleted file mode 100644
index 44027651b38..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md"
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: تصدیقها
-description: توصیفی از تصدیقها در اثبات سهام اتریوم.
-lang: fa
----
-
-از یک اعتبارسنج انتظار می رود در هر ایپوک یک تصدیق ایجاد، امضا و پخش کند. این صفحه نشان میدهد که این گواهیها چگونه هستند و چگونه پردازش میشوند و بین کاربرهای اجماع اعلام میشوند.
-
-## تصدیق چیست؟ {#what-is-an-attestation}
-
-Every [epoch](/glossary/#epoch) (6.4 minutes) a validator proposes an attestation to the network. The attestation is for a specific slot in the epoch. The purpose of the attestation is to vote in favor of the validator's view of the chain, in particular the most recent justified block and the first block in the current epoch (known as `source` and `target` checkpoints). This information is combined for all participating validators, enabling the network to reach consensus about the state of the blockchain.
-
-The attestation contains the following components:
-
-- `aggregation_bits`: a bitlist of validators where the position maps to the validator index in their committee; the value (0/1) indicates whether the validator signed the `data` (i.e. whether they are active and agree with the block proposer)
-- `data`: details relating to the attestation, as defined below
-- `signature`: a BLS signature that aggregates the signatures of individual validators
-
-The first task for an attesting validator is to build the `data`. The `data` contains the following information:
-
-- `slot`: The slot number that the attestation refers to
-- `index`: A number that identifies which committee the validator belongs to in a given slot
-- `beacon_block_root`: Root hash of the block the validator sees at the head of the chain (the result of applying the fork-choice algorithm)
-- `source`: Part of the finality vote indicating what the validators see as the most recent justified block
-- `target`: Part of the finality vote indicating what the validators see as the first block in the current epoch
-
-Once the `data` is built, the validator can flip the bit in `aggregation_bits` corresponding to their own validator index from 0 to 1 to show that they participated.
-
-Finally, the validator signs the attestation and broadcasts it to the network.
-
-### Aggregated attestation {#aggregated-attestation}
-
-There is a substantial overhead associated with passing this data around the network for every validator. Therefore, the attestations from individual validators are aggregated within subnets before being broadcast more widely. This includes aggregating signatures together so that an attestation that gets broadcast includes the consensus `data` and a single signature formed by combining the signatures of all the validators that agree with that `data`. This can be checked using `aggregation_bits` because this provides the index of each validator in their committee (whose ID is provided in `data`) which can be used to query individual signatures.
-
-In each epoch 16 validators in each subnet are selected to be the `aggregators`. The aggregators collect all the attestations they hear about over the gossip network that have equivalent `data` to their own. The sender of each matching attestation is recorded in the `aggregation_bits`. The aggregators then broadcast the attestation aggregate to the wider network.
-
-When a validator is selected to be a block proposer they package aggregate attestations from the subnets up to the latest slot in the new block.
-
-### Attestation inclusion lifecycle {#attestation-inclusion-lifecycle}
-
-1. Generation
-2. Propagation
-3. گردآوری
-4. Propagation
-5. Inclusion
-
-The attestation lifecycle is outlined in the schematic below:
-
-![attestation lifecycle](./attestation_schematic.png)
-
-## پاداشها {#rewards}
-
-Validators are rewarded for submitting attestations. The attestation reward depends on the participation flags (source, target and head), the base reward and the participation rate.
-
-Each of the participation flags can be either true or false, depending on the submitted attestation and its inclusion delay.
-
-The best scenario occurs when all three flags are true, in which case a validator would earn (per correct flag):
-
-`reward += base reward * flag weight * flag attesting rate / 64`
-
-The flag attesting rate is measured using the sum of effective balances of all attesting validators for the given flag compared the total active effective balance.
-
-### Base reward {#base-reward}
-
-The base reward is calculated according to the number of attesting validators and their effective staked ether balances:
-
-`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)`
-
-#### Inclusion delay {#inclusion-delay}
-
-At the time when the validators voted on the head of the chain (`block n`), `block n+1` was not proposed yet. Therefore attestations naturally get included **one block later** so all attestations who voted on `block n` being the chain head got included in `block n+1` and, the **inclusion delay** is 1. If the inclusion delay doubles to two slots, the attestation reward halves, because to calculate the attestation reward the base reward is multiplied by the reciprocal of the inclusion delay.
-
-### Attestation scenarios {#attestation-scenarios}
-
-#### Missing Voting Validator {#missing-voting-validator}
-
-Validators have a maximum of 1 epoch to submit their attestation. If the attestation was missed in epoch 0, they can submit it with an inclusion delay in epoch 1.
-
-#### Missing Aggregator {#missing-aggregator}
-
-There are 16 Aggregators per epoch in total. In addition, random validators subscribe to **two subnets for 256 epochs** and serve as a backup in case aggregators are missing.
-
-#### Missing block proposer {#missing-block-proposer}
-
-Note that in some cases a lucky aggregator may also become the block proposer. If the attestation was not included because the block proposer has gone missing, the next block proposer would pick the aggregated attestation up and include it into the next block. However, the **inclusion delay** will increase by one.
-
-## بیشتر بخوانید {#further-reading}
-
-- [Attestations in Vitalik's annotated consensus spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
-- [Attestations in eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
-
-_در مورد جامعه منابعی که به شما کمک می کنند بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
deleted file mode 100644
index 6da3896f69a..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md"
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: پیشنهاد بلوک
-description: توضیح نحوه پیشنهاد بلوک ها در اتریوم اثبات سهام.
-lang: fa
----
-
-بلوک ها واحدهای بنیادین بلاک چین هستند. بلوکها واحدهای مجزای اطلاعاتی هستند که بین گرهها رد و بدل میشوند، مورد توافق قرار میگیرند و به پایگاه داده هر گره اضافه میشوند. در این صفحه نحوه ایجاد آنها توضیح داده میشود.
-
-## پیشنیازها {#prerequisites}
-
-پیشنهاد بلوک بخشی از پروتکل اثبات سهام است. برای کمک به فهمیدن توضیحات این صفحه، توصیه می کنیم در مورد [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) و [معماری بلوک](/developers/docs/blocks/) مطالعه کنید.
-
-## چه کسی بلوک ها را ایجاد می کند؟ {#who-produces-blocks}
-
-حساب های اعتبارسنج بلوک ها را پیشنهاد می کنند. حسابهای اعتبارسنج توسط اپراتورهای گره مدیریت میشوند که نرمافزار اعتبارسنجی را به عنوان بخشی از کاربرهای اجرا و اجماع خود اجرا میکنند و حداقل 32 اتر را در قرارداد سپردهگذاری کردهاند. با این حال، هر اعتبارسنج فقط بعضا مسئول پیشنهاد یک بلوک است. اتریوم زمان را در اسلات ها و ایپوکها اندازه گیری می کند. هر اسلات دوازده ثانیه است و 32 اسلات (6.4 دقیقه) یک ایپوک را تشکیل می دهند. هر اسلات فرصتی برای افزودن یک بلوک جدید به اتریوم است.
-
-### انتخاب تصادفی {#random-selection}
-
-در هر اسلات، به صورت شبهتصادفی یک اعتبارسنج واحد برای پیشنهاد یک بلوک انتخاب میشود. در یک بلاکچین، تصادفی بودن واقعی وجود ندارد، زیرا اگر هر گره اعداد کاملاً تصادفی تولید کند، نمیتوانند به اجماع برسند. به جای آن، هدف این است که فرآیند انتخاب ولیدیتور غیرقابل پیشبینی باشد. تصادفیسازی در اتریوم با استفاده از الگوریتمی به نام RANDAO انجام میشود که یک هش از پیشنهاددهنده بلوک را با یک بذر که در هر بلوک بهروز میشود، ترکیب میکند. این مقدار برای انتخاب یک اعتبارسنج خاص از کل مجموعه ولیدیتورها استفاده میشود. انتخاب اعتبارسنج دو دوره زمانی قبل از آن تعیین میشود تا از انواع خاصی از دستکاری بذر جلوگیری شود.
-
-اگرچه ولیدیتورها در هر اسلات به RANDAO اضافه میکنند، اما مقدار جهانی RANDAO فقط یک بار در هر دوره بهروز میشود. برای محاسبه شاخص پیشنهاددهنده بلوک بعدی، مقدار RANDAO با شماره اسلات ترکیب میشود تا یک مقدار منحصر به فرد در هر اسلات ایجاد شود. احتمال انتخاب یک اعتبارسنج خاص تنها `1/N` نیست (که در آن `N` = مجموع اعتبارسنجهای فعال است). در عوض، این احتمال با توجه به مانده مؤثر ETH هر اعتبارسنج ارزیابی میشود. حداکثر مانده مؤثر 32 ETH است (این بدان معناست که `مانده < 32 ETH` منجر به وزن کمتری نسبت به `balance == 32 ETH` می شود، اما `مانده > >32 ETH می شود. ETH` منجر به وزن بالاتر از `مانده == 32 ETH`) نمی شود.
-
-فقط یک پیشنهاد بلوک در هر اسلات انتخاب می شود. در شرایط عادی، یک تولیدکننده بلوک واحد، یک بلوک واحد را در اسلات اختصاصی خود ایجاد و منتشر میکند. ایجاد دو بلوک برای یک اسلات، تخطی قابل تنبیه است که اغلب به عنوان "تردید" شناخته میشود.
-
-## بلوک چگونه ایجاد می شود؟ {#how-is-a-block-created}
-
-انتظار میرود پیشنهاددهنده بلوک، یک بلوک بیکن امضا شده را منتشر کند که بر اساس آخرین سر بلوک زنجیره طبق نظر الگوریتم انتخاب فورک محلی خود ساخته شده است. الگوریتم انتخاب فورک، هرگونه تصدیق در صف مانده از اسلات قبلی را اعمال میکند، سپس بلوکی را پیدا میکند که بیشترین وزن انباشته تصدیقها را در تاریخچه خود دارد. آن بلوک، والد بلوک جدید ایجاد شده توسط پیشنهاد دهنده است.
-
-پیشنهاددهنده بلوک با جمعآوری دادهها از پایگاه داده محلی و دیدگاه خود از زنجیره، یک بلوک ایجاد میکند. محتویات بلوک در کادر زیر نشان داده شده است:
-
-```rust
-class BeaconBlockBody(Container):
- randao_reveal: BLSSignature
- eth1_data: Eth1Data
- graffiti: Bytes32
- proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
- attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
- attestations: List[Attestation, MAX_ATTESTATIONS]
- deposits: List[Deposit, MAX_DEPOSITS]
- voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
- sync_aggregate: SyncAggregate
- execution_payload: ExecutionPayload
-```
-
-فیلد `randao_reveal` یک مقدار تصادفی قابل تأیید را می گیرد که پیشنهاد دهنده بلوک، با امضا کردن شماره ایپوک فعلی ایجاد می کند. `eth1_data` رأیی است برای دیدگاه پیشنهاددهنده بلوک در مورد قرارداد سپرده، از جمله ریشه درخت سپرده Merkle و تعداد کل سپردههایی که امکان تأیید سپردههای جدید را فراهم میکنند. `graffiti` یک فیلد اختیاری است که میتوان از آن برای افزودن پیام به بلوک استفاده کرد. `slashings_proposer` و `attester_slashings` فیلدهایی هستند که حاوی اثباتی هستند که نشان میدهد اعتبارسنجهای خاصی طبق دیدگاه پیشنهاددهنده از زنجیره، تخطیهای قابل تنبیه را مرتکب شدهاند. `deposits`لیستی از سپردههای اعتبارسنج جدید است که پیشنهاددهنده بلوک از آن آگاه است، و `voluntary_exits` لیستی از اعتبارسنجهایی است که قصد خروج دارند و پیشنهاددهنده بلوک از طریق شبکه شایعه لایه اجماع از آن مطلع شده است. `sync_aggregate` یک بردار است که نشان میدهد کدام اعتبارسنجها قبلاً به یک کمیته همگامسازی (زیرمجموعهای از اعتبارسنجها که دادههای کاربر سبک را ارائه میدهند) اختصاص داده شدهاند و در امضای دادهها شرکت کردهاند.
-
-`execution_payload` امکان انتقال اطلاعات در مورد تراکنشها بین کاربرهای اجرا و اجماع را فراهم میکند. `execution_payload` بلوکی از دادههای اجرایی است که در داخل یک بلوک بیکن قرار میگیرد. فیلدهای داخل `execution_payload` ساختار بلوک مشخص شده در یلو پیپر اتریوم را منعکس میکنند، با این تفاوت که هیچ Ommer وجود ندارد و `prev_randao` به جای `difficulty` وجود دارد. کاربر اجرا به یک استخر محلی از تراکنشهایی که دربارهاش در شبکه شایعه خود شنیده است، دسترسی دارد. این تراکنشها به صورت محلی اجرا میشوند تا یک درخت حالت بهروز شده به نام پسا-حالت تولید کنند. تراکنشها به عنوان یک لیست به نام `transactions` در `execution_payload` گنجانده شدهاند و پسا-حالت در فیلد `state-root` ارائه شده است.
-
-همه این دادهها در یک بلوک بیکن جمعآوری میشوند، امضا میشوند و برای همتایان پیشنهادکننده بلوک پخش میشوند، که آنها آن را به همتایان خود و غیره منتشر میکنند.
-
-درباره [آناتومی بلوک ها](/developers/docs/blocks) بیشتر بخوانید.
-
-## چه اتفاقی برای بلوک می افتد؟ {#what-happens-to-blocks}
-
-بلوک به پایگاه داده محلی پیشنهاددهنده بلوک اضافه میشود و از طریق شبکه شایعه لایه اجماع به همتایان پخش میشود. هنگامی که یک اعتبارسنج بلوک را دریافت میکند، دادههای داخل آن را تأیید میکند، از جمله بررسی اینکه بلوک والد صحیحی دارد، مربوط به اسلات صحیح است، شاخص پیشنهاددهنده مورد انتظار است، آشکارسازی RANDAO معتبر است و پیشنهاددهنده تنبیه نشده است. `execution_payload` باز میشود و کاربر اجرای اعتبارسنج تراکنشها را در لیست مجدداً اجرا میکند تا تغییر حالت پیشنهادی را بررسی کند. با فرض اینکه بلوک تمام این بررسیها را پاس کند، هر اعتبارسنج بلوک را به زنجیره اصلی خود اضافه میکند. سپس این فرآیند در اسلات بعدی دوباره شروع می شود.
-
-## پاداشهای بلوک {#block-rewards}
-
-پیشنهاددهنده بلوک برای کار خود پاداش دریافت میکند. یک پاداش پایه `base_reward` وجود دارد که به عنوان تابعی از تعداد اعتبارسنجهای فعال و ماندههای مؤثر آنها محاسبه میشود. سپس پیشنهاد دهنده بلوک کسری از `پایه_پاداش` را برای هر تصدیق معتبر موجود در بلوک دریافت می کند. هرچه اعتبارسنجهای بیشتری بلوک را تصدیق کنند، پاداش پیشنهاد دهنده بلوک بیشتر است. همچنین پاداشی برای گزارش اعتبارسنجهایی که باید تنبیه شوند وجود دارد که برابر با `1/512 * مانده مؤثر` برای هر اعتبارسنج تنبیه شده است.
-
-[ اطلاعات بیشتر در مورد پاداشها و مجازاتها](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
-
-## بیشتر بخوانید {#further-reading}
-
-- [مقدمهای بر بلوکها](/developers/docs/blocks/)
-- [مقدمهای بر اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
-- [مشخصات اجماع اتریوم](https://github.com/ethereum/consensus-specs)
-- [مقدمهای بر Gasper](/developers/docs/consensus-mechanisms/pos/)
-- [ارتقای اتریوم](https://eth2book.info/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
deleted file mode 100644
index 0153525196d..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md"
+++ /dev/null
@@ -1,172 +0,0 @@
----
-title: سوالات متداول
-description: سوالات متداول درباره اثبات سهام اتریوم.
-lang: fa
----
-
-## اثبات سهام چیست؟ {#what-is-proof-of-stake}
-
-اثبات سهام دسته ای از الگوریتم است که میتواند با اطمینان از اینکه داراییهای با ارزش توسط مهاجمان متخلف از دست میروند، امنیت را برای بلاکچینها فراهم کند. سیستمهای اثبات سهام به مجموعهای از اعتبارسنجها نیاز دارند تا برخی از داراییها را در دسترس قرار دهند که در صورت مشارکت اعتبارسنج در برخی رفتارهای قابل اثبات نادرست، قابل نابودی باشد. اتریوم از مکانیسم اثبات سهام برای ایمنسازی بلاکچین خود استفاده میکند.
-
-## اثبات سهام چگونه با اثبات کار مقایسه می شود؟ {#comparison-to-proof-of-work}
-
-هم اثبات کار و هم اثبات سهام مکانیسمهایی هستند که از نظر اقتصادی مانع از اسپم کردن یا کلاهبرداری در شبکه توسط طرفهای مخرب میشوند. در هر دو مورد، گرههایی که به طور فعال در اجماع شرکت میکنند، برخی از داراییها را "وارد شبکه" میکنند که در صورت رفتار نادرست از دست خواهند داد.
-
-در اثبات کار، این دارایی انرژی است. گره، که به عنوان استخراجگر شناخته میشود، الگوریتمی را اجرا میکند که هدف آن محاسبه یک مقدار به شکل سریعتر از هر گره دیگر است. سریعترین گره حق پیشنهاد یک بلوک به زنجیره را دارد. برای تغییر تاریخچه زنجیره یا تسلط بر پیشنهاد بلوک، یک استخراجگر باید به قدری قدرت محاسباتی داشته باشد که همیشه برنده مسابقه شود. این کار بسیار پرهزینه و اجرای آن دشوار است و از زنجیره در برابر حملات محافظت می کند. انرژی مورد نیاز برای "استخراج" با استفاده از اثبات کار یک دارایی واقعی است که استخراجگرها برای آن هزینه میکنند.
-
-اثبات سهام نیاز دارد گرههایی که به عنوان اعتبارسنج شناخته میشوند، یک دارایی رمزنگاری را به طور صریح به یک قرارداد هوشمند ارسال کنند. اگر یک اعتبارسنج رفتار نادرستی داشته باشد، این ارز رمزنگاری قابل نابودی است زیرا آنها داراییهای خود را به طور مستقیم در زنجیره "سهام گذاری" میکنند نه به طور غیرمستقیم از طریق مصرف انرژی.
-
-اثبات کار بسیار انرژیبرتر است زیرا در فرآیند استخراج برق مصرف میشود. از سوی دیگر، اثبات سهام فقط به مقدار بسیار کم انرژی نیاز دارد - اعتبارسنجهای اتریوم حتی میتوانند روی دستگاه کم مصرفی مانند Raspberry Pi اجرا شوند. مکانیسم اثبات سهام اتریوم در مقایسه با اثبات کار امنتر تلقی میشود زیرا هزینه حمله بیشتر است و عواقب آن برای مهاجم شدیدتر است.
-
-اثبات کار در مقابل اثبات سهام، موضوعی بحث برانگیز است. [وبلاگ ویتالیک بوترین](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) و مناظره بین جاستین دریک و لین آلدن خلاصه خوبی از استدلال ها ارائه می دهد.
-
-
-
-## آیا اثبات سهام انرژی کم مصرف میکند؟ {#is-pos-energy-efficient}
-
-بله. گرههای موجود در یک شبکه اثبات سهام، مقدار بسیار کمی انرژی مصرف میکنند. یک مطالعه طرف ثالث نتیجه گرفت که کل شبکه اتریوم اثبات سهام حدود 0.0026 تروات ساعت در سال مصرف میکند - تقریباً 13000 برابر کمتر از مصرف انرژی بازیهای ویدیویی تنها در ایالات متحده.
-
-[اطلاعات بیشتر در مورد مصرف انرژی اتریوم](/energy-consumption/).
-
-## آیا اثبات سهام امن است؟ {#is-pos-secure}
-
-اثبات سهام اتریوم بسیار امن است. این مکانیسم، قبل از اینکه به مرحله اجرا برسد، به مدت هشت سال به شدت مورد تحقیق، توسعه و آزمایش قرار گرفت. ضمانتهای امنیتی آن، متفاوت از بلاک چینهای اثبات کار است. در اثبات سهام، اعتبارسنجهای مخرب میتوانند به طور فعال مجازات شوند ("اسلش شده") و از مجموعه اعتبارسنجها اخراج شوند که منجر به از دست دادن مقدار قابل توجهی اتریوم میشود. در اثبات کار، یک مهاجم میتواند تا زمانی که قدرت هش کافی دارد، به تکرار حمله خود ادامه دهد. همچنین انجام حملات معادل بر روی اتریوم اثبات سهام نسبت به اثبات کار هزینه بیشتری دارد. برای تأثیرگذاری بر زنده بودن زنجیره، حداقل 33 درصد از کل اتر سهامگذاری شده در شبکه لازم است (به جز در موارد حملات بسیار پیچیده با احتمال موفقیت بسیار کم). برای کنترل محتوای بلوکهای آینده، حداقل 51 درصد از کل اتریوم سهامگذاری شده لازم است، و برای بازنویسی تاریخچه، بیش از 66 درصد از کل اتریوم سهامگذاری شده لازم است. پروتکل اتریوم این داراییها را در سناریوهای حمله 33% یا 51% از بین میبرد و در سناریوی حمله 66% با اجماع اجتماعی نابود میکند.
-
-- [اطلاعات بیشتر در مورد دفاع از اثبات سهام اتریوم در برابر مهاجمان](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
-- [در مورد طراحی اثبات سهام بیشتر بدانیم](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-
-## آیا اثبات سهام باعث میشود اتریوم ارزانتر شود؟ {#does-pos-make-ethereum-cheaper}
-
-خیر. هزینه ارسال یک تراکنش (کارمزد گس) توسط یک بازار کارمزد پویا تعیین میشود که با افزایش تقاضای شبکه افزایش مییابد. مکانیسم اجماع به طور مستقیم روی این موضوع تأثیر نمیگذارد.
-
-[در مورد گس بیشتر بدانیم](/developers/docs/gas).
-
-## گره ها، کاربرها و اعتبارسنجها چه هستند؟ {#what-are-nodes-clients-and-validators}
-
-گرهها کامپیوترهایی هستند که به شبکه اتریوم متصلاند. کاربرها نرمافزارهایی هستند که روی کامپیوتر اجرا میشوند و آن را به یک گره تبدیل میکنند. دو نوع کلاینت وجود دارد: کاربر اجرایی و کاربر اجماع. هر دو برای ایجاد یک گره ضروری هستند. اعتبارسنج یک افزونه اختیاری برای یک کاربر اجماع است که به گره اجازه میدهد در اجماع اثبات سهام شرکت کند. این به معنای ایجاد و پیشنهاد بلوکها هنگام انتخاب شدن و تصدیق بلوکهایی است که در مورد آنها در شبکه شنیده میشود. برای اجرای یک اعتبارسنج، اپراتور گره باید 32 اتریوم را به قرارداد سپرده واریز کند.
-
-- [اطلاعات بیشتر در مورد گرهها و کاربرها](/developers/docs/nodes-and-clients)
-- [اطلاعات بیشتر درباره سهامگذاری](/staking)
-
-## آیا اثبات سهام ایده جدیدی است؟ {#is-pos-new}
-
-خیر. یک کاربر در بیت کوین تاک در سال 2011 [ایده اصلی اثبات سهام](https://bitcointalk.org/index.php?topic=27787.0) را به عنوان ارتقاء برای بیت کوین پیشنهاد کرد. یازده سال طول کشید تا برای اجرا در شبکه اصلی اتریوم آماده شود. برخی زنجیرههای دیگر، اثبات سهام را زودتر از اتریوم اجرا کردند، اما مکانیسم خاص اتریوم (به نام Gasper) را اجرا نکردند.
-
-## ویژگی خاص اثبات سهام اتریوم چیست؟ {#why-is-ethereum-pos-special}
-
-مکانیسم اثبات سهام اتریوم در طراحی منحصر به فرد است. این اولین مکانیسم اثبات سهام طراحی و اجرا شده نبود، اما قویترین آنها است. مکانیسم اثبات سهام با نام "Casper" شناخته میشود. Casper تعریف میکند که چگونه اعتبارسنجها برای پیشنهاد بلوکها انتخاب میشوند، تصدیقها چگونه و چه زمانی ایجاد میشوند، تصدیقها چگونه شمارش میشوند، پاداشها و جریمههای داده شده به اعتبارسنجها، شرایط تنبیه، مکانیسمهای شکست ایمنی مانند نشت عدم فعالیت و شرایط برای "قطعی بودن" چگونه تعیین میشود. قطعی بودن شرایطی است که برای اینکه یک بلوک به عنوان بخشی دائمی از زنجیره اصلی در نظر گرفته شود، باید توسط حداقل 66 درصد از کل اتریوم سهام گذاری شده در شبکه تأیید شده باشد. محققان Casper را به طور خاص برای اتریوم توسعه دادند و اتریوم اولین و تنها بلاکچینی است که آن را اجرا کرده است.
-
-علاوه بر Casper، اثبات سهام اتریوم از یک الگوریتم انتخاب فورک به نام LMD-GHOST استفاده میکند. این در صورتی لازم است که شرایطی ایجاد شود که دو بلوک برای یک اسلات وجود داشته باشد. این، دو فورک از بلاک چین ایجاد می کند. LMD-GHOST آن بلوکی را انتخاب میکند که بیشترین "وزن" تصدیقها را دارد. وزن تعداد تصدیقهایی است که با مانده مؤثر اعتبارسنجها وزندهی شده است. LMD-GHOST مختص اتریوم است.
-
-ترکیب Casper و LMD_GHOST به عنوان Gasper شناخته میشود.
-
-[اطلاعات بیشتر درمورد Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)
-
-## اسلشینگ (جریمه) چیست؟ {#what-is-slashing}
-
-اسلَشینگ اصطلاحی است که به نابودی بخشی از سهام یک ولیداعتبارسنج و اخراج اعتبارسنج از شبکه اطلاق میشود. مقدار اتریوم از دست رفته در یک اسلَشینگ با تعداد اعتبارسنجهای اسلَش شده مقیاس میشود - این بدان معنی است که اعتبارسنجهای همدست شدیدتر مجازات میشوند.
-
-[اطلاعات بیشتر درباره اسلَشینگ](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing)
-
-## چرا اعتبارسنجها به 32 اتریوم نیاز دارند؟ {#why-32-eth}
-
-اعتبارسنجها باید اتریوم را سهام گذاری کنند تا در صورت رفتار نادرست چیزی برای از دست دادن داشته باشند. دلیل اینکه آنها دقیقاً باید 32 اتریوم استیک کنند این است که به گرهها اجازه میدهد روی سختافزار متوسط اجرا شوند. اگر حداقل اتریوم برای هر اعتبارسنج کمتر بود، تعداد اعتبارسنجها و در نتیجه تعداد پیامهایی که باید در هر اسلات پردازش شوند افزایش مییافت، به این معنی که سختافزار قدرتمندتری برای اجرای یک گره مورد نیاز بود.
-
-## اعتبارسنجها چگونه انتخاب می شوند؟ {#how-are-validators-selected}
-
-یک اعتبارسنج واحد به صورت شبهتصادفی برای پیشنهاد یک بلوک در هر اسلات با استفاده از الگوریتمی به نام RANDAO انتخاب میشود که یک هش از پیشنهاددهنده بلوک را با یک بذر که در هر بلوک بهروز میشود، ترکیب میکند. این مقدار برای انتخاب یک اعتبارسنج خاص از کل مجموعه اعتبارسنجها استفاده میشود. انتخاب اعتبارسنج دو ایپوک پیشتر، تثبیت میشود.
-
-[اطلاعات بیشتر در مورد انتخاب اعتبارسنج](/developers/docs/consensus-mechanisms/pos/block-proposal)
-
-## استیک گرایندینگ چیست؟ {#what-is-stake-grinding}
-
-استیک گرایندینگ نوعی حمله به شبکههای اثبات سهام است که در آن مهاجم تلاش میکند الگوریتم انتخاب اعتبارسنج را به نفع اعتبارسنجهای خود تحت تاثیر قرار دهد. حملات استیک گرایندینگ به RANDAO تقریباً به نصف کل اتریوم سهام گذاری شده نیاز دارند.
-
-[اطلاعات بیشتر درمورد استیک گرایندینگ](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability)
-
-## اسلشینگ اجتماعی چیست؟ {#what-is-social-slashing}
-
-اسلشینگ اجتماعی، توانایی جامعه برای هماهنگی یک فورک بلاک چین در پاسخ به یک حمله است. این امکان را به جامعه میدهد تا از نهایی شدن یک زنجیره نادرست توسط مهاجم بازیابی شود. اسلشینگ اجتماعی همچنین میتواند علیه حملات سانسور به کار رود.
-
-- [اطلاعات بیشتر درباره اسلشینگ اجتماعی](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7)
-- [نظر ویتالیک بوترین در مورد اسلشینگ اجتماعی](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-
-## آیا من جریمه خواهم شد؟ {#will-i-get-slashed}
-
-به عنوان یک اعتبارسنج، جریمه شدن بسیار دشوار است مگر اینکه عمداً در رفتار مخرب شرکت کنید. جریمه فقط در سناریوهای بسیار خاصی اعمال میشود که در آن اعتبارسنجها چندین بلوک برای یک اسلات پیشنهاد میدهند یا با تصدیقهای خود تناقض دارند - این موارد به ندرت به صورت تصادفی رخ میدهند.
-
-[اطلاعات بیشتر درباره شرایط جریمه شدن](https://eth2book.info/altair/part2/incentives/slashing)
-
-## مشکل هیچ-سهامی چیست؟ {#what-is-nothing-at-stake-problem}
-
-مشکل هیچ-سهامی یک موضوع مفهومی با برخی مکانیسم های اثبات سهام است که در آن فقط پاداش وجود دارد و هیچ مجازاتی وجود ندارد. اگر چیزی در سهام نباشد، یک اعتبارسنج عملگرا به همان اندازه خوشحال است که هر یا حتی چند شاخه از بلاک چین را تأیید کند، زیرا این کار باعث افزایش پاداش او می شود. اتریوم با استفاده از شرایط نهایی و جریمه شدن، برای تضمین یک زنجیره متعارف، این موضوع را دور میزند.
-
-[جزئیات بیشتر درباره هیچ-سهامی](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
-
-## الگوریتم انتخاب فورک چیست؟ {#what-is-a-fork-choice-algorithm}
-
-یک الگوریتم انتخاب فورک قوانینی را اجرا میکند که تعیین میکنند کدام زنجیره، زنجیره اصلی است. در شرایط ایدهآل، نیازی به قانون انتخاب فورک نیست زیرا در هر اسلات فقط یک پیشنهاددهنده بلوک وجود دارد و تنها یک بلوک برای انتخاب وجود دارد. با این حال، گاهی اوقات، بلوکهای چندگانه برای یک اسلات یا اطلاعات دیررس منجر به گزینههای متعدد برای سازماندهی بلوکها نزدیک به سر زنجیره میشود. در این موارد، همه کاربرها باید برخی قوانین را به طور یکسان اجرا کنند تا مطمئن شوند که همه آنها توالی صحیح بلوکها را انتخاب میکنند. الگوریتم انتخاب فورک این قوانین را کدگذاری میکند.
-
-الگوریتم انتخاب فورک اتریوم LMD-GHOST نام دارد. این، فورکی را انتخاب میکند که بیشترین وزن تصدیقها را دارد، به این معنی که اکثر اتریوم سهامگذاری شده برای آن رای داده است.
-
-[اطلاعات بیشتر درباره LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice)
-
-## نهایی شدن در اثبات سهام چیست؟ {#what-is-finality}
-
-نهایی شدن در اثبات سهام تضمینی است که یک بلوک مشخص بخشی دائمی از زنجیره اصلی است و نمیتوان آن را برگرداند، مگر اینکه یک شکست اجماع رخ دهد که در آن یک مهاجم ۳۳ درصد از کل اتریوم سهامگذاری شده را بسوزاند. این نهایی شدن "اقتصاد رمزنگاری" است، در مقابل "نهایی شدن احتمالی" که مربوط به بلاک چین های اثبات کار است. در نهایی شدن احتمالی، هیچ حالت مشخصی برای بلوکهای نهاییشده/غیر نهاییشده وجود ندارد - به سادگی احتمال حذف یک بلوک از زنجیره با قدیمیتر شدن آن کمتر و کمتر میشود و کاربران خودشان تعیین میکنند که چه زمانی به اندازه کافی مطمئن هستند که یک بلوک "امن" است. با نهایی شدن اقتصاد رمزنگاری، جفتهای بلوک نقطه بررسی باید ۶۶ درصد از آرای اتریوم سهامگذاری شده را دریافت کنند. اگر این شرط برآورده شود، بلوکهای بین آن نقاط بررسی به طور صریح "نهایی شده" هستند.
-
-[اطلاعات بیشتر درباره نهایی شدن](/developers/docs/consensus-mechanisms/pos/#finality)
-
-## "سویهگیری ضعیف" چیست؟ {#what-is-weak-subjectivity}
-
-سویهگیری ضعیف ویژگی شبکههای اثبات سهام است که در آن از اطلاعات اجتماعی برای تایید وضعیت فعلی بلاکچین استفاده میشود. گرههای جدید یا گرههایی که پس از مدت طولانی آفلاین بودن به شبکه بازمیگردند میتوانند یک وضعیت اخیر دریافت کنند تا گره بتواند بلافاصله ببیند که آیا روی زنجیره صحیح است یا خیر. این حالتها به عنوان "نقاط بررسی سویهگیری ضعیف" شناخته میشوند و میتوان آنها را از اپراتورهای گره دیگر خارج از باند، یا از کاوشگرهای بلوک یا از چندین نقطه انتهایی عمومی دریافت کرد.
-
-[اطلاعات بیشتر درباره سویهگیری ضعیف](/developers/docs/consensus-mechanisms/pos/weak-subjectivity)
-
-## آیا اثبات سهام در برابر سانسور مقاوم است؟ {#is-pos-censorship-resistant}
-
-در حال حاضر اثبات مقاومت در برابر سانسور سخت است. با این حال، بر خلاف اثبات کار، اثبات سهام گزینه ای را برای هماهنگ کردن جریمهها برای مجازات اعتبارسنجهای سانسورکننده ارائه می دهد. تغییراتی در پروتکل در حال انجام است که سازندههای بلوک را از پیشنهاددهندگان بلوک جدا میکند و لیستی از تراکنشهایی را اجرا میکند که سازندهها باید در هر بلوک بگنجانند. این پیشنهاد با نام جداسازی سازنده مناسب شناخته میشود و به جلوگیری از سانسور تراکنشها توسط اعتبارسنجها کمک میکند.
-
-[اطلاعات بیشتر درباره جداسازی پیشنهاددهنده-سازنده](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
-
-## آیا سیستم اثبات سهام اتریوم میتواند مورد حمله ۵۱ درصدی قرار گیرد؟ {#pos-51-attack}
-
-بله. اثبات سهام مانند اثبات کار در برابر حملات ۵۱ درصدی آسیبپذیر است. به جای اینکه مهاجم به ۵۱ درصد قدرت هش شبکه نیاز داشته باشد، مهاجم به ۵۱ درصد کل اتریوم استیک شده نیاز دارد. مهاجمی که ۵۱ درصد از کل استیک را جمعآوری میکند، میتواند الگوریتم انتخاب فورک را کنترل کند. این به مهاجم اجازه میدهد تا تراکنشهای خاصی را سانسور کند، بازآراییهای کوتاهمدت انجام دهد و با مرتب کردن مجدد بلوکها به نفع خود، MEV را استخراج کند.
-
-[جزئیات بیشتر درباره حملات به اثبات سهام](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
-
-## هماهنگی اجتماعی چیست و چرا به آن نیاز داریم؟ {#what-is-social-coordination}
-
-هماهنگی اجتماعی آخرین خط دفاعی برای اتریوم است که امکان بازیابی یک زنجیره صادقانه از یک حمله که بلوکهای نادرست را نهایی کرده است، فراهم میکند. در این حالت، جامعه اتریوم باید به صورت "خارج از باند" هماهنگ شود و توافق کند که از یک فورک اقلیت صادقانه استفاده کند و در این فرآیند اعتبارسنجهای مهاجم را جریمه کند. برای این کار همچنین لازم است برنامهها و صرافیها نیز فورک صادقانه را تشخیص دهند.
-
-[اطلاعات بیشتر درباره هماهنگی اجتماعی](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
-
-## آیا ثروتمندان در اثبات سهام ثروتمندتر میشوند؟ {#do-rich-get-richer}
-
-یک نفر هر چه اتریوم بیشتری برای سهامگذاری داشته باشد، میتواند اعتبارسنجهای بیشتری اجرا کند و پاداش بیشتری کسب کند. پاداشها به صورت خطی با مقدار اتریوم سهام گذاری شده مقیاسبندی میشوند و همه بازده درصد یکسانی دریافت میکنند. اثبات کار ثروتمندان را بیشتر از اثبات سهام غنی میکند زیرا استخراجگرهای ثروتمندتری که سختافزار را در مقیاس خریداری میکنند از صرفه جویی در مقیاس هم بهرهمند میشوند، به این معنی که رابطه بین ثروت و پاداش غیرخطی است.
-
-## آیا اثبات سهام نسبت به اثبات کار متمرکزتر است؟ {#is-pos-decentralized}
-
-خیر، اثبات کار به سمت تمرکز گرایش دارد زیرا هزینههای استخراج افزایش مییابد و افراد را حذف میکند، سپس شرکتهای کوچک را حذف میکند و به همین ترتیب. مشکل فعلی اثبات سهام تاثیر مشتقات سهام گذاری شناور (LSDها) است. اینها توکنهایی هستند که نشاندهنده اتریوم سهام گذاری شده توسط برخی ارائه دهندگان هستند که هر کس میتواند آنها را بدون باز کردن سهام گذاری اتریوم واقعی در بازارهای ثانویه معامله کند. LSDها به کاربران اجازه میدهند تا با کمتر از ۳۲ اتریوم سهام گذاری کنند، اما آنها همچنین خطر تمرکززدایی را ایجاد میکنند که در آن چند سازمان بزرگ میتوانند در نهایت بخش زیادی از سهام را کنترل کنند. به همین دلیل است که [سهام گذاری انفرادی](/staking/solo) بهترین گزینه برای اتریوم است.
-
-[اطلاعات بیشتر در مورد تمرکز سهام در LSD ها](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
-
-## چرا من فقط میتوانم ETH را سهام گذاری کنم؟ {#why-can-i-only-stake-eth}
-
-ETH ارز مربوط به اتریوم است. ضروری است که یک ارز واحد وجود داشته باشد که همه سهامها بر اساس آن تعیین میشوند، هم برای حسابداری ماندههای مؤثر برای وزندهی آرا و هم برای امنیت. خود ETH یک جزء اساسی اتریوم است نه یک قرارداد هوشمند. درج ارزهای دیگر به طور قابل توجه پیچیدگی را افزایش داده و امنیت سهام گذاری را کاهش میدهد.
-
-## آیا اتریوم تنها بلاک چین اثبات سهام است؟ {#is-ethereum-the-only-pos-blockchain}
-
-خیر، چندین بلاک چین اثبات سهام وجود دارد. هیچ کدام با اتریوم یکسان نیستند؛ مکانیسم اثبات سهام اتریوم منحصر به فرد است.
-
-## ادغام چیست؟ {#what-is-the-merge}
-
-ادغام زمانی بود که اتریوم مکانیسم اجماع مبتنی بر اثبات کار خود را خاموش و مکانیسم اجماع مبتنی بر اثبات سهام خود را روشن کرد. ادغام در ۱۵ سپتامبر ۲۰۲۲ اتفاق افتاد.
-
-[اطلاعات بیشتر دربارهی ادغام](/roadmap/merge)
-
-## زنده بودن و ایمنی چه هستند؟ {#what-are-liveness-and-safety}
-
-زنده بودن و ایمنی دو نگرانی اساسی امنیتی برای یک بلاک چین هستند. زنده بودن به معنای در دسترس بودن یک زنجیره نهایی شده است. اگر زنجیره متوقف شود یا کاربران نتوانند به راحتی به آن دسترسی پیدا کنند، اینها زنده بودنهای ناموفق هستند. هزینه بسیار بالای دسترسی نیز میتواند به عنوان یک عدم موفقیت زنده بودن در نظر گرفته شود. ایمنی به این اشاره دارد که حمله به زنجیره چقدر دشوار است - یعنی نهایی کردن نقاط کنترل متناقض.
-
-[اطلاعات بیشتر را در مقاله Casper مطالعه کنید](https://arxiv.org/pdf/1710.09437.pdf)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
deleted file mode 100644
index 6f4a1654013..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md"
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: گاسپر
-description: توضیح در رابطه با مکانیزم اثبات سهام Gasper.
-lang: fa
----
-
-Gasper ترکیبی از گجت قطعیت دوستانه (Casper-FFG) و الگوریتم انتخاب فورک LMD-GHOST است. این دو جزء باهم، مکانیزم اجماع را تشکیل می دهند و اثبات سهام اتریوم را امن میکنند. Casper مکانیزمی است که بلوک های مشخص را تا قطعیت ارتقا میدهد تا شرکتکنندگان جدید شبکه بتوانند از همگام بودن با زنجیره اصلی مطمئن شوند. الگوریتم انتخاب فورک از آرای انباشته شده برای مطمئن شدن از انتخاب راحت و درست در زمان به وجود آمدن فورک در زنجیره بلوکی استفاده میکند.
-
-**توجه کنید** که تعریف اصلی Casper-FFG برای ادغام شدن در Gasper مقداری به روز شد. در این صفحه ما تعریف بهروز شده را درنظر میگیریم.
-
-## پیشنیاز ها
-
-برای درک این مطلب، واجب است تا صفحه مقدمه در [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) را بخوانید.
-
-## نقش Gasper {#role-of-gasper}
-
-Gasper در بالای اثبات سهام زنجیره بلوکی، جایی که گرهها Ether را به عنوان سپردهای تهیه میکنند که قابل تخریب یا تنبل یا ناراست در پیشنهاد معتبر ساختن است مینشیند. Gasper مکانیزمی است که تعریف میکند چگونه اعتبارسنج ها مجازات یا پاداش داده خواهند شد، و کدام بلوک ها پذیرفته و کدام رد، و کدام فورک زنجیره بلوکی بر روی آن ساخته میشود.
-
-## قطعیت چسیت؟ {#what-is-finality}
-
-قطعیت بخشی از بلوک ها است که نمیتوانند برگرداننده شوند مگر بخاطر وفاق بحرانی و زمانی که مهاجمی حداقل 1/3 کل اترهای انباشته شده را نابود میکند. قطعیت بلوک ها به معنی بخشی از اطلاعات است که زنجیره بلوکی درباره آن ها مطمئن است. یک بلوک باید از یک روند دو مرحلهای ارتقا عبور کند تا بتواند قطعی شود:
-
-1. دو-سوم اتر سهام گذاری شده باید به نفع آن بلوک برای پیوستن به زنجیره اصلی رای بدهند. این شرط، بلوک را به مرحله "مشروعیت" ارتقا میدهد. احنمال برگردانی بلوک هایی که به مرحله مشروعیت رسیده باشند، کم است، اما تحت شرایط مشخصی امکانپذیر است.
-2. زمانی که بلوک دیگری در بالای بلوکی دیگر مشروع شود، به مرحله قطعی ارتقا پیدا میکند. قطعی کردن یک بلوک به منزله تعهدی برای اضافه کردن بلوک به زنجیره اصلی است. نمیتواند بازگردانی شود مگر اینکه یک مهاجم میلیون ها اتر (میلیاردها $USD) را از بین ببرد.
-
-این ارتقا بلوک ها در هر اسلات اتفاق نمیافتد. در عوض، تنها بلوک های مرزی ایپوک میتوانند مشروع و قطعی بشوند. این بلوک ها به عنوان "نقاط بررسی" شناخته میشوند. ارتقا نیاز به یک جفت تقطه بررسی دارد. یکی "لینک فوق اکثریت" بین دو نقطه بررسی پیاپی (دو سوم کل اتر سهامگزاری شده باید به درست بودن نقطه بررسی B در برابر A رای دهند) باید وجود داشته باشد تا نقطه بررسی های اخیر را به مرحله قطعیت ارتقا دهد و بلوک را مشروع کند.
-
-زیرا قطعیت نیاز به موافقت حداقل دو-سوم بلوک ها در رابطه با مشروعیت آن دارد، یک مهاجم نمیتواند احتمالا یک نسخه اضافه از زنجیر را بدون موارد زیر قطعی کند:
-
-1. مالکیت یا دستکاری دو-سوم اتر سهامگزاری شده.
-2. نابود کردن حداقل یک-سوم اتر سهامگزاری شده.
-
-شرط اول در صورتی رخ میدهد که دو-سوم اتر سهامگزاری شده برای قطعی کردن زنجیر نیاز باشد. شرط دوم در صورتی پیش میآید چون اگر دو-سوم مجموع سهام به نفع هر دو فورک رای دهند، آن وقت یک-سوم حتما به هر دو رای داده است. جفت رای دادن ها شرایط جریمه درست میکند که به شدت با آن برخورد میشود، و یک-سوم کل سهام از بین خواهد رفت. به طور مثال در می 2022، مهاجم لازم است معادل 10 میلیارد دلار آمریکا اتر بسوزاند. الگوریتمی که در Gasper قطعیت و مشرعیت را بر بلوک اعمال میکند کمی متفاوت از [ Casper از نوع گجت قطعیت دوستانه قطعیت (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) است.
-
-### مشوقها و جریمه {#incentives-and-slashing}
-
-اعتبارسنج ها برای معتبر ساختن صادقانه بلوک ها پاداش دریافت میکنند. اتر به عنوان پاداش به سهام آن ها افزوده خواهد شد. از طرفی دیگر، اعتبارسنج هایی که غایب هستند و در زمان فراخوانی موفق به عمل کردن نمیشوند، پاداش را از دست خواهند داد و گاهی اوقات مقدار کمی از سهام خود را از دست میدهند. با این حال، جریمههای آفلاین بودن ناچیز است و در بیشتر موارد به هزینههای فرصت پاداشهای از دست رفته میرسد. با این حال، انجام برخی از اقدامات اعتبارسنجی به طور تصادفی بسیار دشوار است و اثر مخربی به جا میگذراد، مانند پیشنهاد چندین بلوک برای یک اسلات، تایید چندین بلوک برای یک اسلات، یا مخالفت با آراء نقاط بررسی قبلی. اینها رفتارهای «قابل جریمه» هستند که به شدت جریمه میشوند - این رفتار ها منجر به از بین رفتن بخشی از سهام اعتبارسنج و حذف اعتبارسنج از شبکه اعتباردهندهها میشود. این فرایند 36 روز به طول میانجامد. در روز اول، یک مجازات اولیه تا 1 اتر است. سپس اتر اعتبارسنج جریمه شده به آرامی در طول دوره خروج کم میشود، اما در روز 18، آنها یک "جریمه همبستگی" دریافت میکنند، که وقتی اعتباردهندههای بیشتری در همان زمان جریمه میشوند، بزرگتر میشود. بیشترین مجازات، کل سهام است. این جوایز و جریمهها برای تشویق اعتباردهندگان صادق و بی انگیزه کردن حملات در شبکه طراحی شدهاند.
-
-### نشت عدمفعالیت {#inactivity-leak}
-
-Gasper علاوه بر امنیت، "زنده بودن قابل قبول" را نیز فراهم می کند. این در صورتی است که تا زمانی که دو سوم کل اتر سهاکگذاری شده صادقانه و با پیروی از پروتکل رای بدهد، زنجیره میتواند بدون توجه به هر فعالیت دیگری (مانند حملات، مشکلات تأخیر، یا جریمه ها) قطعی شود. به عبارت دیگر، یک سوم کل اتر سهامگذاری شده باید به نحوی در معرض خطر قرار گیرد تا از نهایی شدن زنجیره جلوگیری شود. در Gasper، یک خط دفاعی اضافی در برابر شکست زنده بودن وجود دارد که به "نشت عدم فعالیت" معروف است. این ساز و کار زمانی فعال می شود که زنجیره برای بیش از چهار دوره نتواند نهایی شود. اعتبارسنجهایی که فعالانه زنجیره اکثریت را تصدیق نمی کنند، سهام آنها به تدریج کم میشود تا زمانی که اکثریت دو سوم کل سهام را به دست آورند، و اطمینان حاصل شود که ناکامیهای زنده بودن فقط موقتی هستند.
-
-### انتخاب فورک {#fork-choice}
-
-تعریف اصلی Casper-FFG شامل یک الگوریتم انتخاب فورک بود که این قانون زیر را دیکته میکرد: `زنجیره ای را که حاوی نقاط بررسی با بیشترین طول است ` که در آن، طول به عنوان بیشترین فاصله از بلوک ایجاد تعریف می شود، دنبال کنید. در Gasper، قانون اصلی انتخاب فورک به نفع یک الگوریتم پیچیدهتر به نام LMD-GHOST منسوخ شده است. درک این نکته مهم است که در شرایط عادی، قانون انتخاب فورک غیرضروری است - برای هر اسلات یک پیشنهاد دهنده بلوک وجود دارد، و اعتبارسنج های صادق آن را تأیید می کنند. تنها در موارد عدم همزمانی شبکه بزرگ یا زمانی که یک پیشنهاد دهنده ناصادق بلوک ایجاد ابهام کرده است که الگوریتم انتخاب فورک مورد نیاز است. با این حال، زمانی که این موارد پیش میآیند، الگوریتم انتخاب فورک یک دفاع حیاتی است که انتخاب زنجیر درست را تضمین میکند.
-
-LMD-GHOST مخفف "جدیدترین درخت فرعی مشاهده شده حریص و سنگین ترین پیام-محور" است. این روشی پیچیده برای تعریف الگوریتمی است که فورکی را با بیشترین وزن انباشته گواهیها بهعنوان نمونه متعارف انتخاب میکند (سنگینترین زیردرخت حریصانه) و اگر چندین پیام از یک اعتبارسنج دریافت شود، فقط آخرین مورد در نظر گرفته میشود (آخرین-پیام محور). قبل از افزودن سنگین ترین بلوک به زنجیره درست خود، هر اعتبارسنج هر بلوک را با استفاده از این قانون ارزیابی می کند.
-
-## اطلاعات بیشتر {#further-reading}
-
-- [Gasper: ترکیبی از GHOST و Casper](https://arxiv.org/pdf/2003.03052.pdf)
-- [Casper، گجت قطعیت دوستانه](https://arxiv.org/pdf/1710.09437.pdf)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
deleted file mode 100644
index 3c6f45b175d..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md"
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: اثبات سهام (PoS)
-description: توضیحی دربارهی پروتکل اجماع اثبات سهام و نقش آن در اتریوم.
-lang: fa
----
-
-اثبات سهام (PoS) زیربنای [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) اتریوم است. اتریوم در سال ۲۰۲۲ به مکانیزم اثبات سهام خود سوییچ کرد؛ زیرا در مقایسه با معماری [اثبات کار](/developers/docs/consensus-mechanisms/pow) قبلی، امن تر، کم مصرف تر و برای پیادهسازی راهکارهای مقیاسپذیری جدید بهتر است.
-
-## پیشنیازها {#prerequisites}
-
-برای درک بهتر این صفحه، ما پیشنهاد میکنیم ابتدا [مکانیزمهای اجماع](/developers/docs/consensus-mechanisms/) را بخوانید.
-
-## اثبات سهام (PoS) چیست؟ {#what-is-pos}
-
-اثبات سهام راهی برای اثبات این موضوع است که اعتبارسنجها چیزی ارزشمند را در شبکه قرار داده اند که اگر غیر صادقانه عمل کنند، می تواند از بین برود. در اثبات سهام اتریوم، اعتبارسنجها به طور مشخص سرمایه خود را به شکل ETH در یک قرارداد هوشمند بر روی اتریوم سهامگذاری میکنند. اعتبارسنج موظف است بررسی کند که بلوکهایی که در شبکه پخش میشوند معتبر هستند و هر از گاهی خود بلوک جدیدی ساخته و در شبکه پخش کند. اگر آن ها سعی کنند از شبکه کلاهبرداری کنند (برای مثال با پیشنهاد چند بلوک در زمانی که باید یک بلوک را بفرستند یا تصدیق های متناقض ارسال کنند)، برخی ETH های سهام گذاری شده آنها یا همه آنها ممکن است از بین بروند.
-
-## اعتبارسنجها {#validators}
-
-برای شرکت بهعنوان اعتبارسنج، کاربر باید 32 اتر را به قرارداد سپرده واریز کند و سه نرمافزار مجزا را اجرا کند: یک کاربر اجرا، یک کاربر اجماع، و یک کاربر اعتبارسنج. هنگام سپردهگذاری ETHها، کاربر به یک صف فعالسازی میپیوندد که نرخ تعداد اعتبارسنجهایی را که به شبکه میپیوندند محدود میکند. زمانی که اعتبارسنج فعال شد، از همتایان درون شبکه اتریوم بلوکهای جدید را دریافت میکند. تراکنشهای تحویل شده در بلوک مجدداً اجرا میشوند تا بررسی شود که تغییرات پیشنهادی در وضعیت اتریوم معتبر هستند و امضای بلوک بررسی میشود. سپس اعتبارسنج یک رای را (که تصدیق نامیده میشود) بر روی شبکه برای آن بلوک ارسال میکند.
-
-در حالی که در اثبات کار، زمان بلوکها توسط سختی استخراج مشخص میشود، در اثبات سهام نرخ ثبت بلوک ثابت است. در اتریوم اثبات سهام، زمان به اسلاتها (۱۲ ثانیه) و ایپوکها (۳۲ اسلات) تقسیم میشود. یک اعتبارسنج به طور تصادفی برای یک پیشنهادکننده بلوک در هر اسلات انتخاب میشود. این اعتبارسنج مسئول ساختن بلوکهای جدید و فرستادن آن به دیگر گرههای شبکه است. همچنین در هر اسلات، یک کمیته از اعتبارسنجها به طور تصادفی انتخاب میشود، که رایهای آن برای معتبر بودن بلوک پیشنهاد شده استفاده میشود. تقسیم کردن اعتبارسنج در کمیته های ایجاد شده برای قابل مدیریت نگه داشتن بار شبکه مهم است. کمیته ها مجموعه اعتبارسنج را به گونه ای تقسیم می کنند که هر اعتبارسنج فعال در هر ایپوک تصدیق می شود، نه در هر اسلات.
-
-## چگونه یک تراکنش در اتریوم PoS اجرا می شود {#transaction-execution-ethereum-pos}
-
-در ادامه، یک توضیح کامل در مورد نحوه اجرای یک تراکنش در اثبات سهام اتریوم ارائه می شود.
-
-1. کاربر یک [تراکنش](/developers/docs/transactions/) را با کلید خصوصی خود ایجاد و امضا می کند. این کار معمولا توسط یک کیف پول یا یک کتابخانه مانند [ether.js](https://docs.ethers.io/v5/) و [web3js](https://docs.web3js.org/) و [web3py](https://web3py.readthedocs.io/en/v5/) و غیره انجام می شود اما کاربر به صورت پنهانی با استفاده از [JSON-RPC API](/developers/docs/apis/json-rpc/) درخواستی را به یک گره می دهد. کاربر میتواند مقدار گازی که تمایل دارد به عنوان انعام به یک اعتبارسنج پرداخت کند را تعریف کند تا او را تشویق کند تراکنش را در یک بلوک قرار دهد. [انعام](/developers/docs/gas/#priority-fee) در حالی به اعتبارسنج پرداخت می شود که [کارمزد پایه](/developers/docs/gas/#base-fee) سوزانده می شود.
-2. تراکنش به یک [کاربر اجرای](/developers/docs/nodes-and-clients/#execution-client) اتریوم ارسال میشود که اعتبار آن را بررسی می کند. این به معنای اطمینان از این است که فرستنده ETH کافی برای انجام تراکنش دارد و آن را با کلید صحیح امضا کرده است.
-3. اگر تراکنش معتبر باشد، کاربر اجرا آن را به استخر حافظه محلی خود (فهرست تراکنشهای معلق) اضافه میکند و همچنین آن را به گرههای دیگر از طریق شبکه شایعه لایه اجرا پخش میکند. هنگامی که گرههای دیگر در مورد تراکنش میشنوند، آن را به استخر حافظه محلی خود نیز اضافه میکنند. کاربران پیشرفته ممکن است از پخش تراکنش خودداری کنند و در عوض آن را به سازندگان بلوک تخصصی مانند [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview) ارسال کنند. این مورد به آنها اجازه میدهد تا تراکنشها را در بلوکهای آینده برای حداکثر سود سازماندهی کنند ([MEV](/developers/docs/mev/#mev-extraction)).
-4. یکی از گرههای اعتبارسنج در شبکه، پیشنهاددهنده بلوک برای اسلات فعلی است که قبلاً به صورت شبه تصادفی با استفاده از RANDAO انتخاب شده است. این گره مسئول ساخت و پخش بلوک بعدی است که به بلاکچین اتریوم اضافه میشود و وضعیت جهانی را به روز میکند. گره از سه بخش تشکیل شده است: یک کاربر اجرا، یک کاربر اجماع و یک کاربر اعتبارسنج. کاربر اجرا تراکنشها را از استخر حافظه محلی به یک "پی لود اجرا" بسته بندی میکند و آنها را به صورت محلی اجرا میکند تا یک تغییر حالت ایجاد کند. این اطلاعات به مشتری اجماع منتقل میشود که در آن پی لود اجرا به عنوان بخشی از یک "بلوک بیکون" رپد میشود که همچنین حاوی اطلاعاتی در مورد پاداشها، جریمهها، اسلشینگها، تصدیق ها و غیره است که شبکه را قادر میسازد بر روی توالی بلوکها در سر زنجیره توافق کند. ارتباط بین کاربران اجرا و اجماع با جزئیات بیشتر در [اتصال کاربران توافق و اجرا](/developers/docs/networking-layer/#connecting-clients) توضیح داده شده است.
-5. گرههای دیگر، بلوک بیکن جدید را در شبکه شایعه لایه اجماع دریافت میکنند. آنها آن را به کاربر اجرای خود ارسال میکنند که در آن تراکنشها به صورت محلی مجدداً اجرا میشوند تا اطمینان حاصل شود که تغییر حالت پیشنهادی معتبر است. سپس کاربر اعتبارسنج تأیید میکند که بلوک معتبر و در دید آنها از زنجیره، بلوک منطقی بعدی است (به این معنی است که بر روی زنجیره ای با بیشترین حجم از تأییدیه ها ساخته میشود که در [قوانین انتخاب فورک](/developers/docs/consensus-mechanisms/pos/#fork-choice) تعریف شده). بلوک مدنظر، در دیتابیس محلی هر گره که آن را تأیید کند اضافه میشود.
-6. اگر تراکنش بین دو نقطه بررسی با "پیوند اکثریت مطلق" بخشی از یک زنجیره شود، می تواند "نهایی شده" در نظر گرفته شود. نقاط بررسی در آغاز هر ایپوک اتفاق میافتد و آنها برای توضیح این واقعیت وجود دارند که فقط یک زیرمجموعه از اعتبارسنجهای فعال در هر اسلات تأییدیه ارائه میدهند، اما تمام اعتبارسنجهای فعال در طول هر ایپوک تأییدیه میدهند. از این رو، تنها بین ایپوکها است که میتوان یک "پیوند اکثریت مطلق" را نشان داد (این جایی است که 66% از همه ETH های استیک شده بر روی شبکه روی دو نقطه بررسی توافق میکنند).
-
-جزئیات بیشتر در مورد قطعیت را در زیر ملاحظه میکنید.
-
-## قطعیت {#finality}
-
-یک تراکنش در شبکه توزیعشده زمانی «قطعیت» دارد که عضوی از بلوکی باشد که نتوان با مصرف کردن میزان قابلتوجهی ETH آن را عوض کرد. در اتریومِ اثبات سهام، این موضوع با استفاده از بلوکهای «نقطه بررسی» مدیریت میشود. اولین بلوک در هر ایپوک یک نقطه بررسی است. اعتبارسنجها به جفت نقطههای بررسی که معتبر میدانند رأی میدهند. اگر یک جفت نقطه بررسی رأی نماینده دستکم دو سوم کل ETH سهامگذاریشده را داشته باشد، نقطههای بررسی ارتقا پیدا میکنند. هر کدام که متأخرتر باشد (هدف) «موجه» در نظر گرفته میشود. آن یکی که قدیمیتر است موجه در نظر گرفته شده است چون «هدف» ایپوک قبلی بوده است. حالا وضعیت آن به «نهاییشده» ارتقا یافته است.
-
-برای برگرداندن یک بلوک نهایی، یک مهاجم متعهد میشود که حداقل یکسوم از کل عرضه ETH سهامگذاریشده را از دست بدهد. دلیل دقیق این موضوع [در این پست وبلاگ بنیاد اتریوم](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) توضیح داده شده است. از آنجا که نهایی شدن نیاز به اکثریت دو سوم دارد، مهاجم میتواند از طریق رأی دادن با یکسوم کل سهام، از نهایی شدن شبکه جلوگیری کند. ساز و کاری برای دفاع در برابر این موضوع وجود دارد: [نشت عدم فعالیت](https://eth2book.info/bellatrix/part2/incentives/inactivity). این ساز و کار هر زمان که زنجیره برای بیش از چهار ایپوک نتواند نهایی شود، فعال میشود. نشت عدم فعالیت، ETH مخاطرهآمیز را از اعتبارسنجهایی که علیه اکثریت رأی میدهند، دور میکند و به اکثریت اجازه میدهد دو سوم اکثریت را دوباره به دست آورند و زنجیره را نهایی کنند.
-
-## امنیت اقتصاد رمزارز {#crypto-economic-security}
-
-اجرای اعتبارسنج یک تعهد است. انتظار میرود اعتبارسنج سختافزار و اتصال کافی به اینترنت را برای مشارکت در اعتبارسنج بلوک و پیشنهاد حفظ کند. در ازای آن، به اعتبارسنج ETH پرداخت میشود (موجودی سهامگذاریشده آن افزایش مییابد). از سوی دیگر، شرکت بهعنوان اعتبارسنج، راههای جدیدی را برای حمله کاربران به شبکه با هدف حصول منافع شخصی یا خرابکاری باز میکند. برای جلوگیری از این امر، اعتبارسنجها در صورت عدم موفقیت در مشارکت هنگام فراخوانی، ETHهای پاداش داده شده را از دست میدهند و در صورت رفتار غیرصادقانه، سهام موجود آنها از بین میرود. دو رفتار اصلی که میتوان آنها را غیرصادقانه در نظر گرفت: پیشنهاد چند بلوک در یک اسلات (مبهمسازی) و ارائه تصدیقهای متناقض.
-
-مقدار ETH که کم میشود به این بستگی دارد که چند اعتبارسنج در آن واحد جریمه می شوند. این را [«جریمه همبستگی»](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) مینامند، و میتواند جزئی باشد (حدود 1% سهام برای یک اعتبارسنج منفرد که مشمول برخورد شدید شود) یا میتواند منجر به از بین رفتن 100% سهام اعتباردهنده شود (جریمه شدید انبوه). برخورد شدید در نیمه راه یک دوره خروج اجباری اعمال میشود که با جریمه فوری (تا 1 اتر) در روز 1، با جریمه همبستگی در روز 18 ادامه مییابد، و در نهایت، با بیرون رانده شدن از شبکه در روز 36 آغاز میشود. آنها هر روز جریمههای جزئی تصدیق دریافت میکنند زیرا در شبکه حضور دارند اما رأی نمیدهند. همهی اینها به این معنی است که یک حمله هماهنگ برای مهاجم بسیار پرهزینه خواهد بود.
-
-## انتخاب فورک {#fork-choice}
-
-هنگامی که شبکه بهطور بهینه و صادقانه عمل میکند، تنها یک بلوک جدید در رأس زنجیره وجود دارد و همه اعتبارسنجها آن را تصدیق میکنند. با این حال، این امکان وجود دارد که اعتبارسنجها به دلیل تأخیر شبکه یا مبهم بودن پیشنهاددهنده بلوک، دیدگاههای متفاوتی نسبت به سر زنجیره داشته باشند. بنابراین، کاربرهای اجماع به یک الگوریتم نیاز دارند تا تصمیم بگیرند کدام یک را ترجیح دهند. الگوریتم مورد استفاده در اثبات سهام اتریوم [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) نام دارد و با شناسایی فورکی که دارای سنگین وزنترین تصدیق در تاریخچه آن است کار میکند.
-
-## اثبات سهام و امنیت {#pos-and-security}
-
-خطر حمله [51%](https://www.investopedia.com/terms/1/51-attack.asp) همچنان در مورد اثبات سهام وجود دارد، همانطور که در اثبات کار وجود دارد، اما برای مهاجمان حتی از این هم خطرناکتر است. یک مهاجم به 51% از ETH سهامگذاریشده نیاز دارد. سپس میتوانستند از تصدیقهای خود استفاده کنند تا اطمینان حاصل کنند که فورک ترجیحی آنها دارای بیشترین تعداد تصدیق است. «وزن» تصدیقهای انباشتهشده همان چیزی است که کاربرهای اجماع برای تعیین زنجیره صحیح استفاده میکنند، بنابراین این مهاجم میتواند فورک خود را به فورک متعارف تبدیل کند. با این حال، نقطه قوت اثبات سهام نسبت به اثبات کار این است که جامعه کاربران آن از امکان تدارک ضدحمله برخوردار است. برای مثال، اعتبارسنجهای صادق میتوانند تصمیم بگیرند که به ساختن زنجیره اقلیت ادامه دهند و فورک مهاجم را نادیده بگیرند و در عین حال برنامهها، صرافیها و استخرها را به انجام همین کار تشویق کنند. آنها همچنین میتوانند تصمیم بگیرند که مهاجم را به زور از شبکه حذف کنند و ETH سهامگذاری شده آن را نابود کنند. اینها دفاعهای اقتصادی قوی در برابر حمله 51% هستند.
-
-علاوه بر حملات 51 درصدی، طرفهای بد ممکن است انواع دیگری از فعالیتهای مخرب را نیز انجام دهند، مانند:
-
-- حملات دوربرد (اگرچه ابزار قطعیت، این بردار حمله را خنثی میکند)
-- "reorgs" کوتاه برد (اگرچه مهلتهای تقویت پیشنهاددهنده و تصدیق این موضوع را کاهش میدهند)
-- حملات برگشتی و متعادل کننده (همچنین با تقویت پیشنهاددهنده کاهش مییابد و این حملات به هر حال فقط در شرایط شبکه ایده آل نشان داده شدهاند)
-- حملات بهمن (خنثیشده توسط قانون الگوریتمهای انتخاب فورک با در نظر گرفتن آخرین پیام)
-
-بهطور کلی، اثبات سهام، به شکلی که در اتریوم پیادهسازی میشود، از نظر اقتصادی امنتر از اثبات کار است.
-
-## مزایا و معایب {#pros-and-cons}
-
-| نقاط مثبت | نقاط منفی |
-| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
-| سهامگذاریْ مشارکت افراد در تأمین امنیت شبکه و افزایش تمرکززدایی را آسانتر میکند. گرهی اعتبارسنج را میتوان روی یک لپتاپ معمولی اجرا کرد. استخرهای سهامگذاری به کاربران امکان میدهند بدون داشتن 32 اتریوم، سهامگذاری کنند. | اثبات سهام در مقایسه با اثبات کار، جوانتر است و کمتر مورد آزمایش قرار گرفته است |
-| سهامگذاری غیرمتمرکزتر است. مزیت مقیاس به شکلی که برای استخراج PoW اعمال میشد، اعمال نمیشود. | اجرای اثبات سهام پیچیدهتر از اثبات کار است |
-| اثبات سهام در مقایسه با اثبات کار، امنیت بیشتری از حیث اقتصاد رمزارز ارائه میدهد | کاربران برای مشارکت در اثبات سهام اتریوم باید سه نرمافزار را اجرا کنند. |
-| برای ایجاد انگیزه در شرکتکنندگان شبکه، کمتر لازم است ETH جدید صادر شود | |
-
-### مقایسه با اثبات کار {#comparison-to-proof-of-work}
-
-اتریوم در ابتدا از اثبات کار استفاده میکرد اما در سپتامبر 2022 به اثبات سهام روی آورد. اثبات سهام چندین مزیت نسبت به اثبات کار دارد، مانند:
-
-- بازده انرژی بهتر - هیچ نیازی به استفاده از انرژی بسیار زیاد محاسبات اثبات کار نیست
-- موانع کمتر برای ورود، سختافزار موردنیاز کمتر – برای برخورداری از شانس ساختن بلوکهای جدید، نیازی به سختافزار عجیب و خاص نیست
-- کاهش ریسک تمرکز - اثبات سهام باید به تعداد گرههای بیشتری در حال برقراری امنیت شبکه بیانجامد
-- به دلیل نیاز به انرژی کمتر، تولید اتر کمتری برای تشویق شرکتکنندهها نیاز است
-- جریمههای اقتصادی برای رفتار اشتباه باعث می شود که حملات مدل 51% برای حملهکننده به نسبت اثبات کار پرهزینه شوند
-- در صورتی که حملهی 51% در شرف فائق آمدن بر دفاعهای رمزارزی-اقتصادی بود، جامعه میتواند به بازیابی اجتماعی یک زنجیرهی صادق متوسل شود.
-
-## بیشتر بخوانید {#further-reading}
-
-- [سؤالات متداول درباره اثبات سهام](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _ویتالیک بوترین_
-- [اثبات سهام چیست؟](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_
-- [اثبات سهام چیست و چرا اهمیت دارد](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _ویتالیک بوترین_
-- [چرا اثبات سهام (نوامبر 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _ویتالیک بوترین_
-- [اثبات سهام: چگونه یاد گرفتم که سویهگیری خفیف را دوست داشته باشم](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _ ویتالیک بوترین_
-- [حمله و دفاع اثبات سهام اتریوم](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [فلسفه طراحی اثبات سهام](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _ویتالیک بوترین_
-- [ویدیو: ویتالیک بوترین اثبات سهام را برای لکس فریدمن توضیح می دهد](https://www.youtube.com/watch?v=3yrqBG-7EVE)
-
-## موضوعات مرتبط {#related-topics}
-
-- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
-- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
deleted file mode 100644
index a3eeec1ff27..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md"
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: کلید ها در اثبات-سهم اتریوم
-description: توضیحی درباره کلیدهای استفاده شده در مکانیسم اجماع اثبات سهام اتریوم
-lang: fa
----
-
-اتریوم از داراییهای کاربران با استفاده از رمزنگاری کلید عمومی-خصوصی محافظت میکند. کلید عمومی به عنوان پایه برای یک آدرس اتریوم استفاده میشود - یعنی برای عموم قابل مشاهده است و به عنوان یک شناسه منحصر به فرد استفاده میشود. کلید خصوصی (یا 'سرّی') باید تنها در دسترس مالک حساب باشد. کلید خصوصی برای "امضای" تراکنشها و دادهها استفاده میشود تا رمزنگاری بتواند ثابت کند که دارنده برخی اقدامات یک کلید خصوصی خاص را تایید میکند.
-
-کلیدهای اتریوم با استفاده از [رمزنگاری منحنی بیضی](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) تولید میشوند.
-
-با این حال، زمانی که اتریوم از [اثبات کار](/developers/docs/consensus-mechanisms/pow) به [اثبات سهام](/developers/docs/consensus-mechanisms/pos) تغییر کرد، نوع جدیدی از کلید به اتریوم اضافه شد. کلیدهای اصلی دقیقاً مانند قبل کار میکنند - هیچ تغییری در کلیدهای مبتنی بر منحنی بیضوی که حسابها را ایمن میکنند ایجاد نشده است. با این حال، کاربران به نوع جدیدی از کلید برای شرکت در اثبات سهام با سهام گذاری اتریوم و اجرای اعتبارسنج ها نیاز داشتند. این نیاز از چالشهای مقیاسپذیری مرتبط با تعداد زیادی پیام بین تعداد زیادی اعتبارسنج ایجاد شد که به یک روش رمزنگاری نیاز داشت که بتواند به راحتی برای کاهش مقدار ارتباط مورد نیاز برای رسیدن شبکه به اجماع جمع شود.
-
-این نوع جدید کلید از طرح امضای [**Boneh-Lynn-Sacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature) استفاده می کند. BLS امکان جمعبندی بسیار کارآمد امضاها را فراهم میکند اما همچنین مهندسی معکوس کلیدهای اعتبارسنج فردی جمعشده را امکانپذیر میکند و برای مدیریت اقدامات بین اعتبارسنج ها ایدهآل است.
-
-## دو نوع کلید اعتبارسنج {#two-types-of-keys}
-
-قبل از تغییر به اثبات سهام، کاربران اتریوم فقط یک کلید خصوصی مبتنی بر منحنی بیضوی برای دسترسی به وجوه خود داشتند. با معرفی اثبات سهام، کاربرانی که میخواستند سهامداران انفرادی باشند نیز به یک **کلید اعتبارسنج** و یک **کلید برداشت** نیاز داشتند.
-
-### کلید اعتبارسنج {#validator-key}
-
-کلید امضای اعتبارسنج از دو بخش تشکیل شده است:
-
-- کلید **خصوصی** اعتبارسنج
-- کلید **عمومی** اعتبارسنج
-
-هدف کلید خصوصی اعتبارسنج امضای عملیات روی زنجیره مانند پیشنهاد بلوک و تصدیقها است. به همین دلیل، این کلیدها باید در یک کیف پول داغ نگهداری شوند.
-
-این انعطافپذیری این مزیت را دارد که کلیدهای امضای اعتبارسنج را خیلی سریع از یک دستگاه به دستگاه دیگر منتقل میکند، با این حال، اگر آنها گم یا دزدیده شده باشند، دزد ممکن است به چند روش **به صورت مخرب** عمل کند:
-
-- اعتبارسنج را با موارد زیر جریمه کنید:
- - یک پیشنهاد دهنده بودن و امضای دو بلوک بیکن متفاوت برای یک اسلات یکسان
- - یک گواهیدهنده بودن و امضای گواهی که گواهی دیگری را "احاطه" میکند
- - یک گواهیدهنده بودن و امضای دو گواهی متفاوت با هدف یکسان
-- خروج داوطلبانه را تحمیل کنید که اعتبارسنج را از سهام گذاری کردن متوقف می کند و دسترسی به موجودی ETH آن را به مالک کلید برداشت اعطا می کند
-
-**کلید عمومی اعتبارسنج** زمانی در دادههای تراکنش گنجانده میشود که کاربر ETH را در قرارداد سهام گذاری سپرده گذاری کند. این به _داده های سپرده_ معروف است و به اتریوم اجازه می دهد اعتبارسنج را شناسایی کند.
-
-### اعتبارنامههای برداشت {#withdrawal-credentials}
-
-هر اعتبارسنج دارای خاصیتی است که به نام _اعتبارنامههای برداشت_ شناخته میشود. این فیلد 32 بایتی با یک `0x00` شروع میشود که نمایانگر اعتبارنامههای خروج BLS است، یا با یک `0x01`، که نشاندهنده اعتبارنامههایی است که به یک آدرس اجرا اشاره میکنند.
-
-اعتبارسنجها با کلیدهای `0x00` BLS باید این اعتبارنامه ها را بهروزرسانی کنند تا به یک آدرس اجرا اشاره کنند تا بتوانند پرداختهای مازاد مانده یا برداشت کامل از سهام گذاری را فعال کنند. این کار را میتوان با ارائه یک آدرس اجرا در داده های سپرده در طول تولید کلید اولیه، _OR_ با استفاده از کلید برداشت در زمان دیگری برای امضا و پخش پیام `BLSToExecutionChange` انجام داد.
-
-### کلید برداشت از حساب {#withdrawal-key}
-
-کلید برداشت از حساب برای بهروزرسانی اعتبارنامه های برداشت برای اشاره به یک آدرس اجرا، در صورتی که در هنگام سپرده اولیه تنظیم نشده باشد، مورد نیاز خواهد بود. این امکان را فراهم میکند که پرداختهای مانده شروع به پردازش شوند و همچنین به کاربران اجازه میدهد تا کل اتریوم سهام گذاری شده خود را برداشت کنند.
-
-درست مانند کلیدهای اعتبارسنجی، کلیدهای برداشت نیز از دو جزء تشکیل شده است:
-
-- کلید **خصوصی** برداشت
-- کلید **عمومی** برداشت
-
-از دست دادن این کلید قبل از بهروزرسانی اعتبارنامه های برداشت به نوع `0x01` به معنای از دست دادن دسترسی به موجودی اعتبارسنج است. اعتبارسنج هنوز میتواند گواهیها و بلوکها را امضا کند زیرا این اقدامات به کلید خصوصی اعتبارسنج نیاز دارند، اما اگر کلیدهای برداشت از بین بروند، انگیزه کمی وجود دارد یا اصلاً وجود ندارد.
-
-جداسازی کلیدهای اعتبارسنج از کلیدهای حساب اتریوم امکان اجرای چندین اعتبارسنج توسط یک کاربر را فراهم میکند.
-
-![شماتیک کلید اعتبارسنج](validator-key-schematic.png)
-
-## استخراج کلیدها از عبارت بذر {#deriving-keys-from-seed}
-
-اگر هر ۳۲ اتریوم سهام گذاری شده به یک مجموعه جدید از ۲ کلید کاملا مستقل نیاز داشت، مدیریت کلید به سرعت غیرقابل کنترل میشد، به ویژه برای کاربرانی که چندین اعتبارسنج را اجرا میکنند. در عوض، چندین کلید اعتبارسنج میتوانند از یک کلید خصوصی مشترک استخراج شوند و ذخیره کردن آن کلید خصوصی واحد امکان دسترسی به چندین کلید اعتبارسنج را فراهم میکند.
-
-[عبارتهای بازیابی](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) و مسیرها ویژگی های برجسته ای هستند که کاربران اغلب هنگام [دسترسی به](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) کیف پول خود با آنها مواجه می شوند. عبارات بازیابی یک دنباله از کلمات است که به عنوان بذر اولیه برای یک کلید خصوصی عمل میکند. هنگامی که با دادههای اضافی ترکیب شود، عبارت بازیابی یک هش به نام "کلید اصلی" تولید میکند. این را می توان به عنوان ریشه یک درخت در نظر گرفت. سپس می توان شاخه هایی از این ریشه را با استفاده از یک مسیر سلسله مراتبی استخراج کرد تا گره های فرزند بتوانند به عنوان ترکیبی از هش گره والد خود و شاخص آنها در درخت وجود داشته باشند. درباره استانداردهای [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) و [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) برای تولید کلید مبتنی بر عبارت بازیابی مطالعه کنید.
-
-این مسیرها ساختار زیر را دارند که برای کاربرانی که با کیف پولهای سختافزاری تعامل داشتهاند آشنا خواهد بود:
-
-```
-m/44'/60'/0'/0`
-```
-
-جریمه ها در این مسیر، اجزای کلید خصوصی را به شرح زیر جدا میکنند:
-
-```
-master_key / purpose / coin_type / account / change / address_index
-```
-
-این منطق به کاربران اجازه میدهد تا بیشترین تعداد ممکن اعتبارسنج را به یک **عبارت بازیابی** متصل کنند، زیرا ریشه درخت میتواند مشترک باشد و تمایز در شاخهها اتفاق میافتد. کاربر می تواند **هر تعداد کلید** را از عبارات بازیابی استخراج کند.
-
-```
- [m / 0]
- /
- /
-[m] - [m / 1]
- \
- \
- [m / 2]
-```
-
-هر شاخه با یک `/` از هم جدا می شود، بنابراین `m/2` به معنای شروع با کلید اصلی و دنبال کردن شاخه 2 است. در طرح زیر از یک عبارت بازیابی واحد برای ذخیره سه کلید برداشت استفاده میشود که هر کدام دارای دو اعتبارسنج مرتبط هستند.
-
-![منطق کلید اعتبارسنج](multiple-keys.png)
-
-## بیشتر بخوانید {#further-reading}
-
-- [پست وبلاگ بنیاد اتریوم توسط Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/)
-- [تولید کلید BLS12-381 بر اساس EIP-2333](https://eips.ethereum.org/EIPS/eip-2333)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
deleted file mode 100644
index e6b2784cf0a..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md"
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: اثبات سهام در برابر اثبات کار
-description: مقایسه مکانیزم های اجماع اثبات سهام و اثبات کار اتریوم
-lang: fa
----
-
-در زمان راهاندازی اتریوم، مکانیزم اثبات سهام هنوز نیاز به تحقیق و توسعه بیشتری داشت تا بتوان برای ایمنسازی اتریوم به آن اعتماد کرد. اثبات کار، مکانیزم سادهتری بود که کارایی آن قبلاً توسط بیتکوین ثابت شده بود. به این معنی که توسعهدهندگان اصلی میتوانستند از این مکانیزم برای راهاندازی سریع اتریوم استفاده کنند. هشت سال دیگر طول کشید تا مکانیزم اثبات سهام به مرحله ای برسد که بتوان آن را پیادهسازی کرد.
-
-این صفحه دلایل تغییر اتریوم از اثبات کار به اثبات سهام و مبادلات مربوط به آن را توضیح می دهد.
-
-## ایمنی {#security}
-
-محققان اتریوم اثبات سهام را امن تر از اثبات کار میدانند. با این حال، مکانیزم اثبات سهام به تازگی روی شبکه اصلی اتریوم پیادهسازی شده است و هنوز به اندازه مکانیزم اثبات کار فرصت اثبات خود در طول زمان را نداشته است. بخشهای زیر به بررسی مزایا و معایب مدل امنیتی اثبات سهام در مقایسه با اثبات کار میپردازد.
-
-### هزینه حمله کردن {#cost-to-attack}
-
-در اثبات سهام، اعتبارسنج ها باید حداقل 32 عدد ETH را در یک قرارداد هوشمند به امانت بگذارند ("سهام گذاری کنند"). اتریوم می تواند به منظور مجازات اعتبارسنج هایی که رفتار مخرب داشته اند، اترهای سهام گذاری شده را از بین ببرد. برای به اجماع رسیدن، باید حداقل 66٪ از کل اتر سهام گذاری شده به نفع مجموعه خاصی از بلوک ها رای دهند. بلوکهایی که با >=66% سهام به آنها رای داده شده است «نهایی میشوند»، به این معنی که نمیتوان آنها را حذف یا سازماندهی مجدد کرد.
-
-حمله به شبکه می تواند به معنای جلوگیری از نهایی شدن زنجیره یا اطمینان از سازماندهی خاصی از بلوک ها در زنجیره متعارف باشد که به نوعی به نفع مهاجم است. این امر مستلزم این است که مهاجم، مسیر اجماع صادقانه را یا با جمعآوری مقدار زیادی اتر و رای دادن مستقیم با آن و یا از طریق فریب اعتبارسنج های صادق به رأی دادن به روشی خاص منحرف کند. حملات پیچیده و کماحتمالی که میتوانند اعتبارسنج های صادق را فریب دهند به کنار، هزینه حمله به اتریوم هزینه سهامی است که مهاجم برای تأثیرگذاری بر اجماع به نفع خود باید آن را جمع کند.
-
-کمترین هزینه حمله، >33٪ از کل سهام است. مهاجمی که >33% از کل سهام را در اختیار دارد می تواند به سادگی با آفلاین شدن باعث تاخیر در نهایی کردن شود. این یک مشکل نسبتاً جزئی برای شبکه است، زیرا مکانیزمی به نام "نشت عدم فعالیت" وجود دارد که سهام را از اعتبار سنج های آفلاین نشت می دهد تا زمانی که اکثریت آنلاین 66٪ از سهام را شامل شوند و بتوانند دوباره زنجیره را نهایی کنند. همچنین از نظر تئوری ممکن است، یعنی هنگامی که از مهاجمی با کمی بیش از 33 درصد از کل سهام خواسته میشود تولید کننده بلوک باشد، با ایجاد دو بلوک به جای یک بلوک، نهایی شدن مضاعف را ایجاد کند و سپس با همه اعتبارسنج های خود رای مضاعف بدهد. هر فورک فقط به 50 درصد از اعتبارسنج های صادق باقی مانده نیاز دارد که ابتدا هر بلوک را ببینند، بنابراین اگر بتوانند پیامهای خود را درست زمانبندی کنند، ممکن است بتوانند هر دو فورک را نهایی کنند. با اینکه احتمال آن کم است، اما اگر مهاجمی بتواند باعث نهایی شدن دوگانه شود، جامعه اتریوم باید تصمیم بگیرد که یک فورک را دنبال کنند؛ در این صورت اعتبارسنج های مهاجم در دیگری جریمه خواهند شد.
-
-با بیش از 33> درصد از کل سهام، یک مهاجم این شانس را دارد که تأثیر جزئی (تاخیر نهایی) یا شدیدتر (نهاییسازی مضاعف) روی شبکه اتریوم داشته باشد. با بیش از 14,000,000 اتر سهامگذاری شده در شبکه و قیمت ارز 1000 دلار/اتر، حداقل هزینه برای اجرای این حملات `1000 ضرب در 14,000,000 ضربدر 0.33 است که مساوی است با 4,620,000,000 دلار`. مهاجم این پول را از طریق جریمه از دست می دهد و از شبکه خارج می شود. برای حمله مجدد، آنها باید بیشتر از 33> درصد اتر سهامگذاری شده را (مجددا) جمع کرده و آن را (دوباره) بسوزانند. هر تلاش برای حمله به شبکه 4.6 میلیارد دلار هزینه در بر خواهد داشت (با 1000 دلار/ETH و 14 میلیون ETH سهام). مهاجم همچنین هنگام جریمه شدن از شبکه خارج می شود و برای پیوستن مجدد باید به صف فعالسازی بپیوندد. این بدان معناست که نرخ یک حمله تکراری نه تنها به نرخی که مهاجم میتواند >33 درصد کل سهام را جمع کند محدود است، بلکه به مدت زمانی که طول میکشد تا تمام اعتبارسنج های خود را وارد شبکه کند. هر بار که مهاجم حمله می کند، بسیار فقیرتر می شود و بقیه افراد جامعه ثروتمندتر می شوند، به لطف شوک عرضه ناشی از آن.
-
-حملات دیگر، مانند حملات 51 درصدی یا بازگشت نهایی با 66 درصد کل سهام، به میزان قابل توجه ETH بیشتری نیاز دارند و برای مهاجم هزینه بیشتری دارند.
-
-این را با اثبات کار مقایسه کنید. هزینه حمله به اتریوم اثبات کار، هزینه مالکیت مداوم >50٪ از کل نرخ هش شبکه بود. این به هزینههای سختافزار و هزینههای جاری قدرت محاسباتی کافی برای پیشی گرفتن از سایر استخراجگرها برای محاسبه مداوم راهحلهای اثبات کار، اضافه شد. اتریوم بیشتر با استفاده از پردازندههای گرافیکی به جای آسیک ها استخراج میشد، که هزینه را پایین نگه داشت (اگرچه اگر اتریوم روی اثبات کار باقی میماند، دستگاه اسیک ممکن بود محبوبتر شود). یک دشمن برای حمله به شبکه اتریوم اثبات کار باید سختافزار زیادی بخرد و هزینه برق را برای اجرای آن بپردازد، اما کل هزینه کمتر از هزینهای است که برای جمعآوری اتر کافی برای انجام یک حمله لازم است. یک حمله 51٪ در اثبات کار نسبت به اثبات سهام، حدود [20 برابر ارزانتر](https://youtu.be/1m12zgJ42dI?t=1562) است. اگر حمله شناسایی شد و زنجیره برای حذف تغییرات آن هارد فورک شود، مهاجم می تواند مکرراً از همان سختافزار برای حمله به فورک جدید استفاده کند.
-
-### پيچيدگي {#complexity}
-
-اثبات سهام بسیار پیچیده تر از اثبات کار است. این می تواند به نفع اثبات کار باشد زیرا وارد کردن تصادفی باگ ها یا اثرات ناخواسته در پروتکل های سادهتر دشوارتر است. با این حال، پیچیدگی با سالها تحقیق و توسعه، شبیه سازی و پیادهسازی شبکه آزمایشی به دست آمده است. پروتکل اثبات سهام به طور مستقل توسط پنج تیم مجزا (در هر یک از لایههای اجرا و اجماع) در پنج زبان برنامهنویسی پیادهسازی شده است که مقاومت در برابر باگهای کلاینت را فراهم میکند.
-
-برای توسعه ایمن و آزمایش منطق اجماع اثبات سهام، بیکنچین دو سال قبل از اجرای اثبات سهام در شبکه اصلی اتریوم راهاندازی شد. بیکنچین به عنوان یک سندباکس برای آزمایش اثبات سهام عمل کرد، زیرا یک بلاکچین زنده بود که منطق اجماع اثبات سهام را پیادهسازی می کرد، اما بدون دست زدن به تراکنش های واقعی اتریوم - عملاً فقط در مورد خودش به اجماع رسید. هنگامی که برای مدت زمان کافی پایدار و بدون اشکال بود، بیکن چین با شبکه اصلی اتریوم ادغام شد. همه اینها به رام کردن پیچیدگی اثبات سهام کمک کرد تا جایی که خطر عواقب ناخواسته یا باگ های کاربر بسیار کم بود.
-
-### سطح حمله {#attack-surface}
-
-اثبات سهام پیچیدهتر از اثبات کار است، به این معنی که بردارهای حمله بالقوه بیشتری برای رسیدگی وجود دارد. به جای یک شبکه همتا به همتا که کاربرها را به هم متصل می کند، دو کاربر وجود دارد که هر کدام یک پروتکل جداگانه را پیادهسازی می کنند. داشتن یک اعتبارسنج خاص از پیش انتخاب شده برای پیشنهاد یک بلوک در هر شکاف، پتانسیل حمله داس را ایجاد می کند که در آن مقادیر زیادی از ترافیک شبکه، آن اعتبارسنج خاص را آفلاین می کند.
-
-همچنین راههایی وجود دارد که مهاجمان میتوانند با دقت زمان انتشار بلوکها یا تصدیقهای خود را به گونهای زمانبندی کنند که توسط بخش خاصی از شبکه صادق دریافت شوند و آنها را تحت تأثیر قرار دهند تا به روشهای خاصی رأی دهند. در نهایت، یک مهاجم میتواند به سادگی اتر کافی برای سهامگذاری کردن و تسلط بر مکانیسم اجماع جمع کند. هر یک از این [بردارهای حمله دارای دفاع های مرتبط هستند](/developers/docs/consensus-mechanisms/pos/attack-and-defense)، اما تحت اثبات کار چنین حملاتی وجود ندارند که بخواهیم از آنها دفاع کنیم.
-
-## غیرمتمرکزسازی {#decentralization}
-
-اثبات سهام بیش از اثبات کار غیرمتمرکز است، زیرا رقابت تجهیزاتی سختافزار استخراج تمایل دارند افراد و سازمانهای کوچک را قیمتگذاری کنند. در حالی که هر کس میتواند از لحاظ فنی استخراج را با سختافزار متوسط شروع کند، احتمال دریافت هر گونه پاداش در مقایسه با عملیات استخراج سازمانی بسیار ناچیز است. با اثبات سهام، هزینه سهامگذاری و درصد بازده آن سهام برای همه یکسان است. در حال حاضر اجرای یک اعتبارسنج، 32 اتر هزینه دارد.
-
-از سوی دیگر، اختراع مشتقات سهامگذاری نقدی به نگرانیهای تمرکزگرایی منجر شده است، زیرا چند ارائهدهنده بزرگ مقادیر زیادی از اتر سهامگذاری شده را مدیریت میکنند. این اتفاق مشکل ساز است و باید در اسرع وقت اصلاح شود، اما در عین حال جزئی تر از آن چیزی است که به نظر می رسد. ارائه دهندگان سهامگذاری متمرکز لزوماً کنترل متمرکز اعتبارسنج ها را ندارند - اغلب این فقط راهی برای ایجاد یک استخر مرکزی اتریوم است که بسیاری از اپراتورهای گره مستقل می توانند بدون اینکه هر شرکت کننده به 32 اتریوم اختصاصی خود نیاز داشته باشد آن را به اشتراک بگذارد.
-
-بهترین گزینه برای اتریوم این است که اعتبارسنج ها به صورت محلی در کامپیوترهای خانگی اجرا شوند و عدم تمرکز را به حداکثر برسانند. به همین دلیل است که اتریوم در برابر تغییراتی که نیازمندی های سخت افزاری برای اجرای یک گره/ اعتبارسنج را افزایش می دهند، مقاومت می کند.
-
-## پایداری {#sustainability}
-
-اثبات سهام یک راهکار کربن ارزان برای ایمنسازی بلاکچین است. در شرایط اثبات کار، استخراجگرها برای حق استخراج یک بلوک رقابت می کنند. استخراجگرها زمانی موفق تر هستند که بتوانند محاسبات را سریعتر انجام دهند و سرمایه گذاری در سختافزار و مصرف انرژی را تشویق کنند. قبل از اینکه اتریوم به اثبات سهام تبدیل شود، این موضوع برای اتریوم مشاهده شد. اندکی قبل از انتقال به اثبات سهام، اتریوم تقریباً 78 تراوات ساعت در سال مصرف می کرد - به اندازه یک کشور کوچک. بااینحال، تغییر به اثبات سهام این هزینه انرژی را تا حدود 99.98٪ کاهش داد. اثبات سهام، اتریوم را به پلتفرمی کم مصرف و کم کربن تبدیل کرد.
-
-[اطلاعات بیشتر در مورد مصرف انرژی اتریوم](/energy-consumption)
-
-## صدور {#issuance}
-
-اتریوم اثبات سهام می تواند با تولید سکه های بسیار کمتر نسبت به اتریوم اثبات کار، هزینه امنیت خود را بپردازد، زیرا اعتبارسنج ها مجبور نیستند هزینه های برق بالایی را بپردازند. در نتیجه، اتریوم می تواند تورم خود را کاهش دهد یا حتی در صورت سوزاندن مقادیر زیادی از اتر، تورم کاهش یابد. سطوح پایینتر تورم به این معنی است که امنیت اتریوم ارزانتر از زمانی است که در زمان اثبات کار بود.
-
-## با توضیحات تصویری راحتترید؟ {#visual-learner}
-
-توضیحات جاستین دریک درباره مزایای اثبات سهام نسبت به اثبات کار را مشاهده کنید:
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [فلسفه طراحی اثبات سهام ویتالیک](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-- [پرسشهای متداول اثبات سهام ویتالیک](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-- [«ویدیو درباره اثبات سهام و اثبات کار» به زبان ساده](https://www.youtube.com/watch?v=M3EFi_POhps)
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
deleted file mode 100644
index 9f99ba62677..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md"
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: پاداشها و جریمهها در اثبات-سهام
-description: درباره مشوق های داخل پروتکل در اتریوم اثبات سهام بیشتر بدانید.
-lang: fa
----
-
-اتریوم با استفاده از رمزارز بومی خود، اتر (ETH) ایمن شده است. اپراتورهای گره که مایل به مشارکت در اعتبارسنجی بلوک ها و شناسایی سر زنجیره هستند، اتر را در [قرارداد سپرده](/staking/deposit-contract/) در اتریوم واریز می کنند. سپس به آنها اتر پرداخت می شود تا نرم افزار اعتبارسنج را اجرا کنند که اعتبار بلوک های جدید دریافت شده از طریق شبکه همتا به همتا را بررسی می کند و الگوریتم انتخاب فورک را برای شناسایی سر زنجیره اعمال می کند.
-
-دو نقش اصلی برای اعتبارسنج وجود دارد: 1) بررسی بلوکهای جدید و "تأیید" آنها در صورت معتبر بودن، 2) پیشنهاد بلوکهای جدید در صورت انتخاب تصادفی از مجموع استخر اعتبارسنجها. اگر اعتبارسنج، وقتی خواسته شد، نتواند هر یک از این وظایف را انجام دهد، دریافت اتر را از دست میدهد. اعتبارسنج ها همچنین گاهی اوقات وظیفه جمع آوری امضا و شرکت در کمیته های همگام سازی را بر عهده دارند.
-
-برخی از اقدامات نیز وجود دارد که انجام آنها به طور تصادفی بسیار دشوار است و نشانهای از قصد مخرب هستند، مانند پیشنهاد چندین بلوک برای یک اسلات یا تأیید چندین بلوک برای یک اسلات. اینها رفتارهای "قابل جریمه شدن" هستند که منجر به سوزاندن مقداری اتر (حداکثر 1 اتر) اعتبارسنج قبل از حذف اعتبارسنج از شبکه می شود که 36 روز طول می کشد. اتر اعتبارسنج جریمه شده به آرامی در طول دوره خروج تخلیه می شود، اما در روز 18 آنها یک "جریمه همبستگی" دریافت می کنند که وقتی اعتبارسنج های بیشتری در همان زمان جریمه می شوند بزرگتر می شود. بنابراین ساختار تشویقیِ مکانیزم اجماع، هزینه صداقت را می پردازد و بازیگران بد را مجازات می کند.
-
-تمام جوایز و مجازات ها، یکبار در هر ایپوک اعمال میشوند.
-
-برای جزئیات بیشتر به مطالعه ادامه دهید...
-
-## پاداش ها و جرایم {#rewards}
-
-### پاداشها {#rewards}
-
-اعتبارسنجها وقتی رایهایی را دریافت میکنند که با اکثریت اعتبارسنج های دیگر مطابقت دارد، وقتی بلوکهایی را پیشنهاد میکنند، و زمانی که در کمیتههای همگامسازی شرکت میکنند، پاداش دریافت میکنند. ارزش پاداش ها در هر ایپوک از یک `base_reward` محاسبه می شود. این واحد پایه ای است که سایر پاداش ها از آن محاسبه می شود. این `base_reward` نشاندهنده میانگین پاداش دریافتی توسط اعتبارسنج در شرایط بهینه در هر ایپوک است. این از تراز مؤثر اعتبارسنج و تعداد کل اعتبارسنج های فعال به شرح زیر محاسبه میشود:
-
-```
-base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))
-```
-
-که در آن `base_reward_factor` عبارت است از 64 و `base_rewards_per_epoch` برابر است با 4 و `sum (موجودی فعال)` کل اتر سهامگذاری شده در تمام اعتبارسنج های فعال است.
-
-این بدین معنی است که پاداش پایه با موجودی مؤثر اعتبارسنج و با تعداد اعتبارسنج ها در شبکه نسبت معکوس دارد. هرچه اعتبارسنج بیشتر باشد، صدور کلی بیشتر است (به عنوان `sqrt(N)` اما `پایه_پاداش` برای هر اعتبارسنج کوچکتر است (به عنوان `1/sqrt(N)`). این عوامل بر APR یک گره سهامگذاری تاثیر می گذارد. دلیل این امر را در [یادداشت های ویتالیک](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards) بخوانید.
-
-سپس پاداش کل به عنوان مجموع پنج جزء محاسبه می شود که هر کدام دارای وزنی هستند که تعیین می کند هر جزء چقدر به پاداش کل اضافه می کند. اجزاء عبارتند از:
-
-```
-1. source vote: the validator has made a timely vote for the correct source checkpoint
-2. target vote: the validator has made a timely vote for the correct target checkpoint
-3. head vote: the validator has made a timely vote for the correct head block
-4. sync committee reward: the validator has participated in a sync committee
-5. proposer reward: the validator has proposed a block in the correct slot
-```
-
-وزن هر جزء به شکل زیر است:
-
-```
-TIMELY_SOURCE_WEIGHT uint64(14)
-TIMELY_TARGET_WEIGHT uint64(26)
-TIMELY_HEAD_WEIGHT uint64(14)
-SYNC_REWARD_WEIGHT uint64(2)
-PROPOSER_WEIGHT uint64(8)
-```
-
-مجموع این وزن ها 64 است. پاداش به صورت مجموع اوزان قابل اعمال تقسیم بر 64 محاسبه می شود. اعتبارسنجی که بهموقع رأیهای منبع، هدف و سر را ایجاد کرده، یک بلوک پیشنهاد کرده و در کمیته همگامسازی شرکت کرده است، میتواند `64/64 * base_reward == base_reward` دریافت کند. با این حال، یک اعتبارسنج معمولاً پیشنهاد دهنده بلوک نیست، بنابراین حداکثر پاداش آنها `64-8 /64 * base_reward == 7/8 * base_reward` است. اعتبار سنج هایی که نه پیشنهاد دهنده بلوک هستند و نه در کمیته همگام سازی، می توانند `64-8-2 / 64 * base_reward == 6.75/8 * base_reward` دریافت کنند.
-
-یک پاداش اضافی برای تشویق تصدیقهای سریع اضافه می شود. این `inclusion_delay_reward` است. این مقدار برابر با `base_reward` ضرب در `1/تأخیر` است که در آن `تاخیر` تعداد اسلاتهایی است که پیشنهاد بلوک و تصدیق را از هم جدا میکنند. به عنوان مثال، اگر تصدیق در یک شکاف از پیشنهاد بلوک ارسال شود، گواهیدهنده `base_reward * 1/1 == base_reward` دریافت میکند. اگر تصدیق در اسلات بعدی برسد، تصدیقکننده `base_reward * 1/2` و غیره دریافت میکند.
-
-پیشنهادکنندگان بلوک `8 / 64 * base_reward` را برای **هر تصدیق معتبر** موجود در بلوک دریافت میکنند، بنابراین ارزش واقعی مقیاسهای پاداش، با تعداد اعتبارسنج های تأییدکننده مقیاسبندی میشود. پیشنهاد دهندگان بلوک همچنین میتوانند پاداش خود را با گنجاندن شواهدی مبنی بر رفتار نادرست سایر اعتبارسنج ها در بلوک پیشنهادی خود افزایش دهند. این پاداشها همان «هویجهایی» هستند که صداقت اعتبارسنج را تشویق میکنند. پیشنهاد دهنده بلوکی که شامل اسلش است با `slashed_validators_effective_balance / 512` پاداش میگیرد.
-
-### مجازات ها {#penalties}
-
-تا اینجا ما اعتبارسنج های کاملاً خوبی را در نظر گرفتهایم، اما در مورد اعتبارسنج هایی که رأیهای سر، منبع و هدف را بهموقع نمیآورند یا آهسته انجام میدهند، چطور؟
-
-جریمههای از دست دادن آرای هدف و منبع برابر با پاداشهایی است که امضاکننده در صورت ارسال آنها دریافت میکرد. این بدان معناست که به جای اضافه شدن پاداش به موجودی شان، ارزش معادلی از موجودی شان حذف می شود. هیچ جریمه ای برای از دست دادن رای سر وجود ندارد (یعنی رای های سر فقط پاداش می گیرند، هرگز جریمه نمی شوند). هیچ جریمه ای در ارتباط با `تاخیر_شمول` وجود ندارد - فقط پاداش به موجودی اعتبارسنج اضافه نمی شود. همچنین هیچ جریمه ای برای عدم پیشنهاد بلوک وجود ندارد.
-
-در [مشخصات اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md) درباره جوایز و مجازاتها بیشتر بخوانید. پاداشها و جریمهها در ارتقاء Bellatrix تنظیم شدند - دنی رایان و ویتالیک را در این [ویدیوی EIP نگاه کنید](https://www.youtube.com/watch?v=iaAEGs1DMgQ) تماشا کنید.
-
-## جریمه کردن (اسلشینگ) {#slashing}
-
-جریمه کردن یک عمل شدیدتر است که منجر به حذف اجباری یک اعتبارسنج از شبکه و از دست دادن اتر سهامگذاری شده اش می شود. سه راه برای جریمه کردن یک اعتبارسنج وجود دارد که همه آنها به منزله پیشنهاد یا تأیید غیرصادقانه بلوک ها هستند:
-
-- با پیشنهاد و امضای دو بلوک مختلف برای یک اسلات
-- با تأیید بلوکی که بلوک دیگری را احاطه کرده است (عملاً تغییر سابقه)
-- با «رای گیری دوباره» از طریق تصدیق دو نامزد برای یک بلوک
-
-اگر این اقدامات شناسایی شوند، اعتبارسنج جریمه می شود. این بدان معنی است که 1/32 اتر سهامگذاری شده آنها (حداکثر 1 اتر) بلافاصله سوزانده می شود، سپس یک دوره حذف 36 روزه آغاز می شود. در طول این دوره حذف، سهام اعتبارسنج به تدریج از بین می رود. در نقطه میانی (روز 18) یک جریمه اضافی اعمال میشود که اندازه آن با کل اتر سهامگذاری شده تمام اعتبارسنج های جریمه شده در 36 روز قبل از رویداد جریمه مقیاسبندی میشود. این بدان معناست که وقتی اعتبارسنج های بیشتری جریمه میشوند، بزرگی جریمه افزایش مییابد. حداکثر جریمه، تراز مؤثر تمام اعتبارسنجهای جریمه شده است (یعنی اگر اعتبارسنج های زیادی جریمه شوند، ممکن است کل سهام خود را از دست بدهند). از سوی دیگر، یک رویداد جریمه مجزا تنها بخش کوچکی از سهام اعتبارسنج را می سوزاند. این جریمه نقطه میانی که با تعداد اعتبارسنجهای جریمه شده مقیاس میشود، «مجازات همبستگی» نامیده میشود.
-
-## نشت عدم فعالیت {#inactivity-leak}
-
-اگر لایه اجماع بیش از چهار ایپوک بدون نهایی شدن طی شده باشد، یک پروتکل اضطراری به نام "نشت عدم فعالیت" فعال می شود. هدف نهایی نشت عدم فعالیت، ایجاد شرایط لازم برای بازیابی نهایی شدن زنجیره است. همانطور که در بالا توضیح داده شد، نهایی شدن نیاز به اکثریت 2/3 از کل اتر سهامگذاری شده برای توافق در مورد نقاط بازرسی منبع و هدف دارد. اگر اعتبارسنج هایی که بیش از 1/3 از مجموع اعتبارسنج ها را نشان میدهند آفلاین شوند یا تصدیقهای صحیح را ارائه نکنند، امکان نهایی کردن پستهای بازرسی برای اکثریت 2/3 وجود ندارد. نشت عدم فعالیت اجازه می دهد تا سهام متعلق به اعتبارسنج های غیرفعال به تدریج از بین برود تا زمانی که آنها کمتر از 1/3 کل سهام را کنترل کنند و به اعتبارسنج های فعال باقی مانده اجازه می دهد زنجیره را نهایی کنند. هر چقدر هم که تعداد اعتبارسنجهای غیرفعال زیاد باشد، اعتبارسنجهای فعال باقی مانده در نهایت بیش از 2/3 سهام را کنترل خواهند کرد. از دست دادن سهام یک انگیزه قوی برای اعتبارسنج های غیرفعال است تا در اسرع وقت دوباره فعال شوند! سناریوی نشت عدم فعالیت در شبکه آزمایشی Medalla زمانی رخ داد که کمتر از 66 درصد از اعتبارسنج های فعال توانستند در مورد سر فعلی بلاکچین به توافق برسند. نشت عدم فعالیت فعال شد و در نهایت نهایی سازی دوباره به دست آمد!
-
-طراحی پاداش، مجازات و جریمه متعلق به مکانیسم اجماع، اعتباسنج های انفرادی را تشویق میکند تا به درستی رفتار کنند. با این حال، از این انتخابهای طراحی، سیستمی پدیدار میشود که به شدت به توزیع برابر اعتبارسنج ها در بین چندین کاربر انگیزه میدهد و باید به شدت از تسلط تک کاربر جلوگیری کند.
-
-## بیشتر بخوانید {#further-reading}
-
-- [بهروز رسانی اتریوم: لایه مشوق](https://eth2book.info/altair/part2/incentives)
-- [مشوقها در پروتکل هیبریدی Casper اتریوم](https://arxiv.org/pdf/1903.04205.pdf)
-- [مشخصات تشریح شده ویتالیک](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
-- [نکات جلوگیری از جریمه شدن Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
-
-_منابع_
-
-- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_
diff --git "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" "b/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
deleted file mode 100644
index 519d98ad8c6..00000000000
--- "a/public/content/translations/fa/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md"
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: فردیت ضعیف
-description: توضیح فردیت ضعیف و نقش آن در اثبات سهام اتریوم.
-lang: fa
----
-
-فردیت در زنجیره بلوکی با اتکا بر اطلاعات اجتماعی برای موافقت با وضعیت فعلی اشاره دارد. ممکن است چندین فورک معتبر وجود داشته باشد که بر اساس اطلاعات جمعآوریشده از سایر همتایان در شبکه انتخاب میشوند. برعکس آن عینیت است که به زنجیرههایی اشاره دارد که در آن تنها یک زنجیره معتبر ممکن وجود دارد که همه گرهها با اعمال قوانین کدگذاری شدهشان لزوماً با آن موافقت خواهند کرد. حالت سومی نیز وجود دارد که به عنوان فردیت ضعیف شناخته می شود. این به زنجیره ای اشاره دارد که می تواند به طور عینی پس از دریافت بذری اولیه از اطلاعات به صورت اجتماعی پیشرفت کند.
-
-## پیشنیازها {#prerequisites}
-
-برای فهم این صفحه، فهم اساسی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) لازم است.
-
-## فردیت ضعیف چه مشکلاتی را حل میکند؟ {#problems-ws-solves}
-
-فردیت ویژگی ذاتی اثبات سهام زنجیره های بلوکی است زیرا انتخاب زنجیره صحیح از چندین فورک با شمارش آرای گذشته انجام میشود. این امر زنجیره بلوکی را در معرض چندین بردار حمله قرار میدهد، مانند حملات دوربرد که به موجب آن گرههایی که خیلی زود در زنجیره شرکت کردهاند، یک فورک جایگزین را حفظ میکنند که بعداً به نفع خود آزادش کنند. از طرف دیگر، اگر 33٪ از اعتبارسنجها سهام خود را پس بگیرند اما به تأیید و تولید بلوکها ادامه دهند، ممکن است یک فورک جایگزین ایجاد کنند که با زنجیره اصلی تضاد دارد. گرههای جدید یا گرههایی که برای مدت طولانی آفلاین بودهاند ممکن است از این موضوع آگاه نباشند که این اعتبارسنجهای مهاجم وجوه خود را برداشتهاند، بنابراین مهاجمان میتوانند آنها را فریب دهند تا یک زنجیره نادرست را دنبال کنند. اتریوم میتواند این بردارهای حمله را با اعمال محدودیتهایی که جنبههای فردی مکانیسم را کاهش میدهد – و بنابراین به فرضیات اعتماد میکند – به حداقل ممکن برساند.
-
-## نقاط بررسی فردیت ضعیف {#ws-checkpoints}
-
-فردیت ضعیف در اثبات سهام اتریوم با استفاده از "نقاط بررسی فردیت ضعیف" اجرا میشود. اینها ریشه های حالتی هستند که همه گره های شبکه توافق دارند به زنجیره اصلی تعلق دارند. آنها همان هدف «حقیقت جهانی» را برای بلوکهای ایجاد انجام میدهند، با این تفاوت که در موقعیت ایجاد در زنجیره بلوکی قرار ندارند. الگوریتم انتخاب فورک اطمینان دارد که حالت زنجیره بلوکی تعریف شده در آن نقطه بررسی درست است و به طور مستقل و عینی زنجیره را از آن نقطه به بعد تأیید می کند. نقاط بررسی بهعنوان «محدودیتهای برگشتی» عمل میکنند، زیرا بلوکهایی که قبل از نقاط بررسی با فردیت ضعیف قرار دارند، قابل تغییر نیستند. این امر باعث تضعیف حملات دوربرد، صرفاً با تعریف فورک های دوربرد به عنوان بخشی از طراحی مکانیزم نامعتبر میشود. اطمینان حاصل کردن از فاصله کمتر نقاط بررسی فردیت ضعیف نسبت به دوره خروج اعتبارسنج از یکدیگر تضمین می کند که اعتبارسنجی که زنجیره را منحرف می کند، حداقل مقداری از آستانه را کاهش می دهد تا بتوانند سهام خود را پس بگیرند و ورود کنندگان جدید نمی توانند توسط اعتبار سنج ها به داخل فورکهای نادرست فریب بخورند که سهام شان برداشته شده است.
-
-## تفاوت بین نقاط بررسی فردیت ضعیف و بلوک های نهایی {#difference-between-ws-and-finalized-blocks}
-
-بلوکهای قطعی و نقاط بررسی فردیت ضعیف به طور متفاوت از سوی گرههای اتریوم استفاده میشوند. اگر یک گره از رقابت بین دو بلوک برای قطعی شدن باخبر شود، در انتخاب بلوک اصلی به تردید میافتد - هیچ راهی برای تشخیص فورک متعارف نخواهد داشت. این نشانه شکست اجماع است. در مقابل، یک گره هر بلوکی را که با فردیت ضعیف خود در تقابل باشد به سادگی رد میکند. از زاویه دید گرهها، نقاط بررسی فردیت ضعیف از حقیقت محضی پرده برمیدارند که توسط هیچ اطلاعات جدیدی ضعیف نمیشود.
-
-## منظور از ضعیف چقدر ضعیف است؟ {#how-weak-is-weak}
-
-جنبه فردیت اثبات سهام اتریوم، لازمه یک وضعیت اخیر (نقطه بررسی فردیت ضعیف) از یک منبع قابل اعتماد برای همگامسازی است. ریسکِ داشتن یک نقطه بررسی فردیت ضعیف به دلیل قابلیت بررسی توسط منابع مستقل متعدد مانند جستجوگرهای بلوک یا گرههای چندگانه، بسیار کم است. اما، همیشه مقداری آزادی برای راهاندازی هر برنامه نرمافزازی لازم است، به عنوان مثال، اعتماد به ساخت برنامهای صادق توسط برنامه نویسان نرمافزار.
-
-نقطه بررسی فردیت ضعیف ممکن است به عنوان بخشی از نرمافزار کاربر ظاهر شود. مسلماً یک مهاجم می تواند نقطه بررسی را در نرمافزار دستکاری کند و به همین راحتی می تواند خود نرمافزار را خراب کند. هیچ راه عملی اقتصاد رمزارز برای حل این مشکل وجود ندارد، اما تاثیر توسعه دهندگان غیرقابل اعتماد در اتریوم با داشتن چندین تیم کاربر مستقل، که هر کدام نرمافزاری معادل را به زبانهای مختلف میسازند، در اتریوم به حداقل میرسد. جستجوگرهای بلوک همچنین ممکن است نقاط بررسی فردیت ضعیف یا راهی برای ارجاع متقابل نقاط بررسی به دست آمده از جاهای دیگر در برابر یک منبع اضافی ارائه دهند.
-
-در نهایت، نقاط بررسی را میتوان از گره های دیگر درخواست کرد. شاید یکی دیگر از کاربران اتریوم که یک گره کامل را اجرا میکند، بتواند یک نقطه بررسی را ارائه کند که اعتبارسنجها میتوانند آن را در برابر دادههای یک جستجوگر بلوک تأیید کنند. روی هم رفته، اعتماد به نقطه بررسی فردیت ضعیف میتواند به اندازه اعتماد به توسعهدهندگان کاربر مشکلساز باشد. اعتماد کلی مورد نیاز کم است. توجه به این نکته مهم است که این ملاحظات تنها در شرایط بسیار بعید مهم میشوند که اکثریت تاییدکنندگان برای تولید یک فورک جایگزین از زنجیره بلوکی توطئه کنند. تحت هر شرایط، تنها یک زنجیره از اتریوم برای انتخاب وجود دارد.
-
-## اطلاعات بیشتر {#further-reading}
-
-- [فردیت ضعیف در Eth2.0](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
-- [ویتالیک: چگونه یاد گرفتم عاشق فردیت ضعیف باشم](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
-- [فردیت ضعیف (مستندهای تکو)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/)
-- [فاز-0 راهنمای فردیت ضعیف](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md)
-- [تحلیل فردیت ضعیف در Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
deleted file mode 100644
index fc0777409a0..00000000000
--- "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md"
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: اثبات صلاحیت (PoA)
-description: توضیح پروتکل اجماع اثبات صلاحیت و نقش آن در اکوسیستم بلاکچین.
-lang: fa
----
-
-**اثبات صلاحیت (PoA)** یک الگوریتم اجماع مبتنی بر شهرت است که یک نسخه اصلاح شده از [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) است. بیشتر در زنجیرههای خصوصی، تستنتها و شبکههای توسعه محلی مورد استفاده قرار میگیرد. PoA یک الگوریتم اجماع مبتنی بر اعتبار است که به جای یک مکانیسم مبتنی بر سهام در PoS، نیاز به اعتماد به یک مجموعه از امضاکنندگان مجاز برای تولید بلوکها دارد.
-
-## پیش نیازها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/)، و [مکانیسمهای اجماع](/developers/docs/) سازوکارهای اجماع را مطالعه کنید.
-
-## اثبات صلاحیت (PoA) چیست؟ {#what-is-poa}
-
-اثبات صلاحیت یک نسخه اصلاح شده از \*\*[اثبات سهام](/developers/docs/consensus-mechanisms/pos/) (PoS) است که یک الگوریتم اجماع مبتنی بر اعتبار به جای مکانیسم مبتنی بر سهام در PoS است. این اصطلاح برای اولین بار در سال 2017 توسط گاوین وود معرفی شد و این الگوریتم اجماع بیشتر توسط زنجیرههای خصوصی، شبکههای آزمایشی و شبکههای توسعه محلی استفاده شده است، زیرا مانند PoW بر نیاز به منابع با کیفیت بالا غلبه میکند و بر مقیاسپذیری غلبه میکند. با داشتن زیرمجموعه کوچکی از گرهها که بلاکچین را ذخیره میکنند و بلوکها را تولید میکنند، بر مشکلات مقیاسپذیری با PoS غلبه میکند.
-
-اثبات صلاحیت مستلزم اعتماد به مجموعهای از امضاکنندگان مجاز است که در [بلوک پیدایش] (/ واژهنامه/#genesis-block) تنظیم شدهاند. در اکثر اجراهای فعلی، همه امضاکنندگان مجاز هنگام تعیین اجماع زنجیره، از قدرت و امتیازات برابر برخوردار هستند. ایده مبنای سهام گذاری شهرت این است که هر اعتبارسنج مجاز از طریق مواردی مانند شناخت مشتری خود (KYC)، یا داشتن یک سازمان شناخته شده که تنها اعتباردهنده است، برای همه شناخته شده است - به این ترتیب اگر اعتبارسنج کار اشتباهی انجام دهد، هویت او مشخص می شود.
-
-چندین اجرای PoA وجود دارد، اما اجرای استاندارد اتریوم **کلیک** است که [EIP-225] (https://eips.ethereum.org/EIPS/eip-225) را اجرا میکند. کلیک یک استاندارد توسعهدهندهپسند و آسان برای اجرا است که از همه انواع همگامسازیهای کاربر پشتیبانی میکند. اجراهای دیگر عبارتند از [IBFT 2.0](https://besu.hyperledger.org/stable/private-networks/concepts/poa) و [Aura](https://openethereum.github.io/Chain-specification).
-
-## چگونه کار میکند {#how-it-works}
-
-در PoA، مجموعه ای از امضاکنندگان مجاز برای ایجاد بلوک های جدید انتخاب می شوند. امضاکنندگان بر اساس شهرت خود انتخاب می شوند و آنها تنها کسانی هستند که اجازه ایجاد بلوک های جدید را دارند. امضاکنندگان به صورت چرخشی انتخاب می شوند و هر امضاکننده مجاز است در یک بازه زمانی خاص یک بلوک ایجاد کند. زمان ایجاد بلوک ثابت است و امضاکنندگان ملزم به ایجاد بلوک در آن چارچوب زمانی هستند.
-
-اعتبار در این زمینه یک چیز کمّی نیست بلکه اعتبار شرکتهای شناخته شدهای مانند مایکروسافت و گوگل است، از این رو روش انتخاب امضاکنندگان مورد اعتماد الگوریتمی نیست بلکه یک عمل انسانی معمولی اعتماد است که در آن یک نهاد مثلاً مایکروسافت یک شبکه خصوصی PoA را بین صدها یا هزاران استارتاپ ایجاد میکند و نقش خود را به عنوان تنها امضاکننده مورد اعتماد با امکان افزودن سایر امضاکنندگان شناخته شده مانند گوگل در آینده ایفا میکند. استارتاپها بدون شک به مایکروسافت اعتماد میکنند که همیشه صادقانه عمل کند و از شبکه استفاده کند. این امر نیاز به مشارکت در شبکههای کوچک/خصوصی مختلف را که برای اهداف مختلف ساخته شدهاند تا غیرمتمرکز بودن و کارکرد آنها را حفظ کند، همراه با نیاز به استخراجگرها که انرژی و منابع زیادی صرف میکنند، برطرف میکند. برخی از شبکه های خصوصی از استاندارد PoA مانند VeChain استفاده می کنند و برخی آن را تغییر می دهند مانند Binance که از [PoSA] استفاده می کند (https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) که یک نسخه تغییر یافته سفارشی از PoA و PoS است.
-
-فرآیند رای گیری توسط خود امضا کنندگان انجام می شود. هر امضاکننده هنگام ایجاد بلوک جدید به اضافه یا حذف یک امضاکننده در بلوک خود رأی میدهد. آرا توسط گرهها جمعآوری میشوند و امضاکنندگان بر اساس آرایی که به آستانه معین `SIGNER_LIMIT` میرسند، اضافه یا حذف میشوند.
-
-ممکن است موقعیتی وجود داشته باشد که فورک های کوچک رخ دهد. سختی یک بلوک به این بستگی دارد که آیا بلوک به نوبت امضا شده است یا خارج از نوبت. بلوک های "نوبتی" سختی 2 دارند و بلوک های "خارج از نوبت" سختی 1 دارند. در مورد فورکهای کوچک، زنجیرهای که اکثر امضاکنندگان آن بلوکها را "نوبتی" مهر و موم میکنند، بیشترین سختی را جمع میکند و برنده میشود.
-
-## بردارهای حمله {#attack-vectors}
-
-### امضاکنندگان مخرب {#malicious-signers}
-
-ممکن است یک کاربر مخرب به لیست امضاکنندگان اضافه شود، یا ممکن است کلید/ماشین امضا در خطر باشد. در چنین سناریویی، پروتکل باید بتواند از خود در برابر سازماندهی مجدد و ارسال اسپم دفاع کند. راهکار پیشنهادی این است که با توجه به لیستی از N امضاکننده مجاز، هر امضاکننده تنها میتواند 1 بلوک از هر K بلوک را ایجاد کند. این تضمین میکند که خسارت محدود شده و باقی اعتبارسنجها میتوانند کاربر مخرب را اخراج کنند.
-
-### سانسور {#censorship-attack}
-
-یکی دیگر از بردارهای جالب حمله این است که یک امضاکننده (یا گروهی از امضاکنندگان) سعی کند بلوک هایی را که به حذف آنها از لیست مجوز رأی می دهند، سانسور کند. برای حل این مشکل، فرکانس ضرب مجاز امضاکنندگان به 1 از N/2 محدود شده است. این امر تضمین می کند که امضاکنندگان مخرب باید حداقل 51٪ از حساب های امضا را کنترل کنند، در این مرحله آنها به طور مؤثر منبع جدیدی از حقیقت برای زنجیره خواهند بود.
-
-### اسپم {#spam-attack}
-
-یکی دیگر از بردارهای کوچک حمله، امضاکنندگان مخربی است که پیشنهادات رای جدید را در داخل هر بلوکی که ضرب میکنند، تزریق میکنند. از آنجا که گره ها برای ایجاد لیست واقعی امضاکنندگان مجاز باید همه آرا را جمعآوری کنند، باید تمام آرا را در طول زمان ثبت کنند. بدون محدود کردن پنجره رأیگیری، این مقدار میتواند به آرامی اما بدون محدودیت افزایش یابد. راه حل این است که یک پنجره متحرک بلوک های W ایجاد کنیم که پس از آن آرا منسوخ در نظر گرفته میشوند. _یک پنجره معقول ممکن است 1-2 ایپوک باشد._
-
-### بلوک های همزمان {#concurrent-blocks}
-
-در یک شبکه PoA، زمانی که N امضاکننده مجاز وجود دارد، هر امضاکننده مجاز به ایجاد یک بلوک از هر K بلوک است که به این معنی است که N-K+1 اعتبارسنج در هر لحظه مجاز به ایجاد بلوک هستند. برای جلوگیری از رقابت این اعتبارسنجها برای ایجاد بلوک، هر امضاکننده باید یک "جابجایی" تصادفی کوچک به زمان انتشار بلوک جدید خود اضافه کند. اگرچه این فرآیند تضمین می کند که فورکهای کوچک نادر هستند، فورکهای گاه به گاه هنوز هم می توانند اتفاق بیفتند، درست مانند شبکه اصلی. اگر مشخص شود که یک امضاکننده از قدرت خود سوء استفاده کرده و باعث ایجاد آشفتگی شده است، امضاکنندگان دیگر میتوانند او را اخراج کنند.
-
-به عنوان مثال، اگر 10 امضاکننده مجاز وجود داشته باشد و هر امضاکننده مجاز باشد از 20 بلوک، 1 بلوک ایجاد کند، در هر زمان، 11 اعتبارسنج می توانند بلوک ایجاد کنند. برای جلوگیری از رقابت آنها برای ایجاد بلوک، هر امضاکننده یک "جابجایی" تصادفی کوچک به زمانی که یک بلوک جدید را منتشر می کند اضافه می کند. این امر احتمال وقوع فورکهای کوچک را کاهش میدهد اما همچنان به فورکهای گاه به گاه مانند آنچه در شبکه اصلی اتریوم دیده میشود اجازه میدهد. اگر یک امضاکننده از صلاحیت خود سوء استفاده کرده و باعث اختلال شود، ممکن است از شبکه حذف شود.
-
-## مزایا و معایب {#pros-and-cons}
-
-| نقاط مثبت | نقاط منفی |
-| ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| مقیاس پذیرتر از مکانیسم های محبوب دیگر مانند PoS و PoW، زیرا بر اساس تعداد محدودی از امضاکنندگان بلوک است | شبکههای PoA معمولاً تعداد نسبتاً کمی گره اعتبارسنج دارند. این، شبکه PoA را متمرکزتر می کند. |
-| بلاک چین های PoA برای اجرا و نگهداری بسیار ارزان هستند | معمولاً برای یک فرد عادی تبدیل شدن به یک امضاکننده مجاز غیرقابل دسترس است، زیرا بلاک چین به نهادهایی با شهرت اثبات شده نیاز دارد. |
-| تراکنشها خیلی سریع تأیید میشوند، زیرا ممکن است به کمتر از ۱ ثانیه برسد، زیرا فقط تعداد محدودی امضاکننده برای اعتبارسنج بلوکهای جدید لازم است | امضاکنندگان مخرب می توانند دوباره سازماندهی کنند، دو برابر هزینه کنند، و تراکنش ها را در شبکه سانسور کنند. این حملات کاهش می یابد، اما همچنان ممکن است |
-
-## ادامه مطلب {#further-reading}
-
-- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique standard_
-- [مطالعه اثبات صلاحیت](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_
-- [اثبات صلاحیت چیست](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_
-- [شرح اثبات صلاحیت](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_
-- [PoA در بلاک چین](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba)
-- [شرح دسته](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d)
-- [PoA منسوخ شده، مشخصات Aura] (https://openethereum.github.io/Chain-specification)
-- [IBFT 2.0، اجرای دیگر PoA](https://besu.hyperledger.org/stable/private-networks/concepts/poa)
-
-### با توضیحات تصویری راحتترید؟ {#visual-learner}
-
-توضیح تصویری اثبات صلاحیت را تماشا کنید:
-
-
-
-## موضوعات مرتبط {#related-topics}
-
-- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
-- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
deleted file mode 100644
index f031539aaee..00000000000
--- "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md"
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: اثبات کار (PoW)
-description: توضیحی دربارهی پروتکل اجماع اثبات کار و نقشش در اتریوم.
-lang: fa
----
-
-شبکه اتریوم با استفاده از یک مکانیزم اجماعی که شامل **[اثبات کار (PoW)](/developers/docs/consensus-mechanisms/pow)** بود، شروع به کار کرد. این موضوع به گره های شبکه اتریوم اجازه داد روی وضعیت تمام اطلاعات ثبت شده روی زنجیره بلوکی اتریوم به توافق برسند و از انواع خاصی از حملات اقتصادی جلوگیری کنند. با این حال، اتریوم اثبات کار را در سال 2022 خاموش کرد و به جای آن شروع به استفاده از [اثبات سهام](/developers/docs/consensus-mechanisms/pos) کرد.
-
-
- در حال حاضر اثبات کار منسوخ شده است. اتریوم دیگر از اثبات کار به عنوان بخشی از مکانیزم اجماع خود استفاده نمی کند. در عوض، از اثبات سهام استفاده می کند. در مورد اثبات سهام و سهام گذاری بیشتر بخوانید.
-
-
-## پیشنیازها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/) و [مکانیزمهای اجماع](/developers/docs/consensus-mechanisms/) را مطالعه کنید.
-
-## اثبات کار (PoW) چیست؟ {#what-is-pow}
-
-اجماع ناکاموتو، که از اثبات کار استفاده می کند، مکانیزمی است که زمانی به شبکه غیرمتمرکز اتریوم اجازه می داد در مورد چیزهایی مانند موجودی حساب و ترتیب تراکنش ها به اجماع برسد (یعنی همه گرهها توافق کنند). این کار جلوی «خرج کردن دوباره» کوینهای کاربران را گرفت و باعث حصول اطمینان از این موضوع شد که حمله و خرابکاری در زنجیره اتریوم فوقالعاده سخت است. این ویژگی های امنیتی اکنون به جای استفاده از مکانیزم اجماع معروف به [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)، از اثبات سهام به دست می آیند.
-
-## اثبات کار و استخراج {#pow-and-mining}
-
-اثبات کار الگوریتمی اساسی است که دشواری و قوانین کاری که استخراجگران باید انجام دهند را در زنجیره های بلوکی اثبات کار تعیین می کند. استخراج، خودِ «کار» است. این همان عمل اضافه کردن بلوکهای معتبر به زنجیره است. این موضوع از آن جهت اهمیت دارد که طول زنجیره به شبکه کمک می کند تا از فورک صحیح زنجیره بلوکی پیروی کند. هر چه «کار» بیشتری انجام شود، زنجیره طولانیتر میشود و هر چه شماره بلوک بیشتر شود، شبکه از وضعیت فعلی مطمئنتر میشود.
-
-[اطلاعات بیشتر دربارهی استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
-
-## اثبات کار اتریوم چگونه کار می کرد؟ {#how-it-works}
-
-تراکنشهای اتریوم به بلوکها پردازش میشوند. در اتریوم اثبات کار که اکنون منسوخ شده است، هر بلوک شامل موارد زیر بود:
-
-- سختی بلوک - برای مثال: 3,324,092,183,262,715
-- mixHash - برای مثال: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
-- نانس (Nonce) - برای مثال: `0xd3ee432b4fb3d26b`
-
-این داده بلوکی ارتباط مستقیمی با اثبات کار داشت.
-
-### کار در اثبات کار {#the-work}
-
-پروتکل اثبات کار، Ethash، نیاز داشت که استخراجگران برای پیدا کردن نانس به روش آزمون و خطا به رقابت شدید بپردازند. تنها بلوک های دارای نانس (Nonce) معتبر میتوانستند به زنجیره اضافه شوند.
-
-استخراجگر در هنگام مسابقه برای ساخت بلوک، به طور منظم و تکراری یک مجموعهداده را، که فقط با دانلود و اجرای همه زنجیره به دست میآید (همان طور که استخراجگر هم دانلود و اجرا میکند)، از یک تابع ریاضی عبور میدهد. مجموعه داده ها برای ایجاد mixHash در زیر یک هدف که توسط سختی بلوک دیکته شده است، استفاده شد. بهترین راه برای انجام این کار آزمون و خطاست.
-
-سختی برای هش یک هدف تعیین کرد. هر چه هدف کمتر باشد، مجموعه هشهای معتبر کوچکتر است. وقتی ساخته شد، راستی آزمایی آن برای دیگر استخراجگران و کاربرها بسیار ساده بود. حتی اگر یک تراکش تغییر کند، هش کاملاً متفاوت خواهد بود و سیگنال تقلب خواهد داد.
-
-هش کردن باعث میشود که به آسانی بتوان تقلبها را کشف کرد. اما اثبات کار در مقام یک فرایند، یک بازدارنده مهم حملات به زنجیره هم بود.
-
-### اثبات کار و امنیت {#security}
-
-استخراجگران برای انجام این کار روی شبکه اصلی اتریوم تشویق شدند. مشوق کمی برای زیرمجموعهای از استخراجگران که زنجیره خودشان را بسازند وجود داشت - که سیستم را تضعیف میکند. زنجیرههای بلوکی بر یک وضعیت بهعنوان منبع حقیقت متکی هستند.
-
-هدف اثبات کار افزایش زنجیره بود. بلندترین زنجیره قابل قبولترین زنجیره به عنوان زنجیره معتبر است، چرا که بیشترین میزان کار پردازشی برای تولید آن انجام شده بود. در سیستم اثبات کار اتریوم، ساخت بلوکهای جدیدی که تراکنشها را پاک کند، تراکنشهای جعلی بسازد یا یک زنجیره دوم را نگهداری کند، تقریباً غیرممکن بود. دلیل این موضوع آن است که استخراجگر بداندیش نیاز خواهد داشت که نانس (Nonce) بلوک را همواره زودتر از هر کس دیگر پیدا کند.
-
-استخراجگر بد اندیش برای این که بهطور مداوم بتواند بلوکهای معتبر اما بداندیش بسازد نیاز دارد بیش از 51% توان استخراج شبکه را داشته باشد تا از بقیه جلو بیفتد. این مقدار "کار" به قدرت محاسباتی بسیار گران قیمت نیاز دارد و انرژی صرف شده حتی ممکن است از سود حاصل از یک حمله بیشتر باشد.
-
-### اقتصاد اثبات کار {#economics}
-
-اثبات کار همچنین مسئول صدور ارز جدید به درون سیستم و تشویق استخراجگران به انجام کار بود.
-
-از زمان [ارتقا Constantinopld](/history/#constantinople)، استخراج گرانی که با موفقیت بلوک میساختند پاداشی برابر با دو اتر و بخشی از کارمزد تراکنش ها دریافت میکردند. بابت ساخت بلوک های عمو همچنین ۱٫۷۵ اتر پرداخت میشود. بلوک های عمو، بلوک های معتبری بودند که یک استخراجگر همزمان با اسخراجگر دیگر آن را به موازات زنجیره ابتدایی ساخته است، که در نهایت با این تصمیم که روی کدام بلوک زنجیره ادامه پیدا میکند مشخص میشوند. بلوکهای عمو معمولا به علت تأخیر شبکه رخ میدادند.
-
-## قطعیت {#finality}
-
-یک تراکنش روی اتریوم زمانی «قطعیت» دارد که عضوی از بلوکی باشد که نتواند عوض شود.
-
-از آنجا که استخراجگران به شکل غیر متمرکز کار کرده اند، دو بلوک معتبر میتوانند در یک زمان استخراج شوند. این کار یک فورک موقت ایجاد میکند. در نهایت، یکی از این زنجیرهها، پس از آنکه بلوک های بعدی استخراج شده به آن اضافه شد و در نتیجه بلندتر شد، زنجیره پذیرفتهشده خواهد شد.
-
-برای پیچیدهتر کردن بیشتر موضوع، تراکنشهایی که در فورک موقت رد شدهاند ممکن است در زنجیره پذیرفتهشده وجود نداشته باشند. این به این معنا است که شرایط میتواند معکوس شود. پس قطعیت به زمانی گفته میشود که یک تراکنش غیرقابل معکوس شدن باشد. زمانی که اتریوم از مکانیزم اجماع اثبات-کار استفاده میکرد، هر چه تعداد بلوک بیشتری روی بلوک `N` استخراج می شد، اطمینان بیشتری حاصل میشد که تراکنش های بلوک`N` موفق بوده اند و بازگردانده نمی شوند. حالا، با اثبات سهم، نهایی شدن، یک دارایی صریح بلوک است تا احتمالی.
-
-## استفاده از انرژی اثبات کار {#energy}
-
-یکی از بزرگترین انتقادها به اثبات کار، میزان مصرف انرژی مورد نیاز برای ایمن نگه داشتن شبکه است. برای حفظ امینت و عدم تمرکز شبکه، اتریوم با اثبات کار انرژی زیادی صرف میکرد. پیش از گذار به اثبات سهام، استخراج گران اتریوم رو هم دیگر حدود ۷۰ تراوات ساعت برق سالانه مصرف میکردند (حدودا برابر با مصرف برق جمهوری چک طبق امار[digieconomist](https://digiconomist.net/)در ۱۸ جولای ۲۰۲۲).
-
-## نقاط مثبت و منفی {#pros-and-cons}
-
-| نقاط مثبت | نقاط منفی |
-| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| اثبات کار خنثی است. شما برای شروع و گرفتن پاداش بلوکها و حرکت از 0 اتر به موجودی مثبت، نیازی به اتر ندارید. با [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)، شما برای شروع نیاز به اتر دارید. | اثبات کار به حدی انرژی مصرف میکند که برای محیط زیست بد است. |
-| اثبات کار یک مکانیزم اجماع آزمودهشده است که بیتکوین و اتریوم را برای سالها ایمن و غیرمتمرکز نگه داشته است. | اگر میخواهید استخراج کنید، نیاز به دستگاههای مخصوصی دارید که برای شروع، سرمایهگذاری گرانی است. |
-| در مقایسه با اثبات سهام، پیادهسازی راحتتری دارد. | با توجه به پردازش موردنیاز روزافزون، استخرهای استخراج احتمالاً تبدیل به غولهای بازی استخراج میشوند و این به ریسک متمرکز شدن و عدم امنیت منجر میشود. |
-
-## در مقایسه با اثبات سهام {#compared-to-pos}
-
-در سطح بالا، اثبات سهام همان هدفی را دارد که اثبات کار دارد: کمک به شبکه غیرمتمرکز برای رسیدن به اجماع بهطور امن. اما تفاوتهایی در فرایند و پرسنل دارد:
-
-- اثبات سهام بهجای توان پردازشی به اتر سهامگذاری شده اهمیت میدهد.
-- اثبات سهام استخراجگرها را با اعتبارسنجها جایگزین میکند. اعتبارسنجها اتر خود را سهامگذاری میکنند تا توانایی ساختن بلوک جدید را فعال کنند.
-- اعتبارسنجها برای ساختن بلوک با هم مسابقه ندارند و بهجای آن بهصورت تصادفی توسط یک الگوریتم انتخاب میشوند.
-- قطعیت واضحتر است: در برخی نقاط زمان، اگر 2/3 اعتبارسنجها بر سر وضعیت بلوک به توافق برسند، این بلوک قطعی در نظر گرفته میشود. اعتبارسنجها باید تمام سهام خود را شرطبندی کنند و اگر بخواهند تبانی کنند تمام سهام خود را از دست میدهند.
-
-[اطلاعات بیشتر دربارهی اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
-
-## با تصویر راحتتر یاد میگیرید؟ {#visual-learner}
-
-
-
-## اطلاعات بیشتر {#further-reading}
-
-- [حملهی اکثریت](https://en.bitcoin.it/wiki/Majority_attack)
-- [دربارهی قطعیت تسویه](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
-
-### ویدیوها {#videos}
-
-- [توضیح فنی پروتکل اثبات کار](https://youtu.be/9V1bipPkCTU)
-
-## موضوعات مرتبط {#related-topics}
-
-- [استخراج](/developers/docs/consensus-mechanisms/pow/mining/)
-- [اثبات سهام](/developers/docs/consensus-mechanisms/pos/)
-- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
deleted file mode 100644
index 501b8ba675c..00000000000
--- "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md"
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: استخراج
-description: توضیحی درباره نحوه کار استخراج روی اتریوم.
-lang: fa
----
-
-
-اثبات-کار دیگر مکانیزم اجماع اتریوم نیست، و در نتیجه استخراج اتریوم متوفف شده است. در عوض، اتریوم توسط اعتبارسنجهایی که اتریوم را سهام گذاری میکنند، ایمن میشود. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. درباره ادغام، اثبات سهام و سهامگذاری بیشتر بخوانید. این صفحه تنها برای علاقمندان به تاریخچه پروژه است.
-
-
-## پیشنیازها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه میکنیم ابتدا [تراکنشها](/developers/docs/transactions/)، [بلوکها](/developers/docs/blocks/) و [اثبات کار](/developers/docs/consensus-mechanisms/pow/) را مطالعه کنید.
-
-## استخراج اتریوم چیست؟ {#what-is-ethereum-mining}
-
-استخراج، فرآیند ایجاد بلوکی از تراکنش ها است که در معماری اثبات کار اتریوم که اکنون منسوخ شده است، به زنجیره بلوکی اتریوم اضافه میشود.
-
-کلمه «استخراج» ریشه در قیاس رمزارزها با طلا دارد. طلا یا فلزات گرانبها کمیاب هستند. توکنهای دیجیتال هم چنین هستند، تنها راه افزایش حجم کل در یک سیستم اثبات کار، استخراج است. در اثبات کار اتریوم، تنها روش صدور از طریق استخراج بود. با این حال، بر خلاف طلا یا فلزات گران بها، استخراج اتریوم راهی برای ایمن کردن شبکه از طریق ساختن، تأیید کردن، منتشر کردن و پخش کردن بلوکها در زنجیره بلوکی نیز بود.
-
-استخراج اتر = ایمنسازی شبکه
-
-استخراج رگ حیاتی هر زنجیره بلوکی اثبات کار است. استخراجکنندگان اتریوم - رایانههایی که نرمافزار را اجرا میکنند - از زمان و قدرت محاسباتی خود برای پردازش تراکنشها و تولید بلوکها پیش از انتقال به اثبات سهام استفاده میکردند.
-
-## چرا استخراجکنندگان وجود دارند؟ {#why-do-miners-exist}
-
-در سیستمهای غیرمتمرکز مانند اتریوم، باید اطمینان حاصل کنیم که همه در مورد ترتیب تراکنشها توافق دارند. استخراجکنندگان با حل پازلهای محاسباتی دشوار برای تولید بلوکها به این امر کمک میکردند و شبکه را در مقابل حملات ایمن نگه میداشتند.
-
-[اطلاعات بیشتر در مورد اثبات کار](/developers/docs/consensus-mechanisms/pow/)
-
-هر کس قبلا می توانست با استفاده از کامپیوتر خود در شبکه اتریوم استخراج کند. با این حال، همه نمیتوانستند اتر (ETH) را بهطور سودآور استخراج کنند. در بیشتر موارد، ماینرها مجبور به خرید سختافزار کامپیوتری اختصاصی و دسترسی به منابع انرژی ارزان قیمت بودند. بعید به نظر می رسید که یک کامپیوتر معمولی به اندازه کافی پاداش بلوک دریافت کند تا هزینه های مربوط به استخراج را پوشش دهد.
-
-### هزینهی استخراج {#cost-of-mining}
-
-- هزینههای بالقوهی سختافزاری لازم جهت ساخت و نگهداری ریگ استخراج
-- هزینهی برق لازم برای تأمین انرژی ریگ استخراج
-- اگر در یک استخر استخراج میکردید، این استخرها معمولاً درصدی هزینه ثابت از هر بلوک تولیدشده توسط استخر را دریافت میکردند
-- هزینهی احتمالی تجهیزات برای پشتیبانی از ریگ استخراج (تهویه، نظارت بر انرژی، سیمکشی برق و غیره)
-
-برای بررسی بیشتر سودآوری استخراج، از یک ماشینحساب استخراج مانند آنچه که [Etherscan](https://etherscan.io/ether-mining-calculator) ارائه میدهد، استفاده کنید.
-
-## تراکنشهای اتریوم چگونه استخراج میشدند {#how-ethereum-transactions-were-mined}
-
-در ادامه مروری بر نحوه استخراج تراکنش ها در اثبات کار اتریوم ارائه میشود. توصیف مشابهی از این فرآیند برای اثبات سهام اتریوم را می توانید در [اینجا](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) بیابید.
-
-1. یک کاربر یک درخواست [تراکنش](/developers/docs/transactions/) را با کلید خصوصی یک [حساب](/developers/docs/accounts/) مینویسد و امضا میکند.
-2. کاربر درخواست تراکنش را از یک [گره](/developers/docs/nodes-and-clients/) به کل شبکه اتریوم ارسال میکند.
-3. پس از شنیدن درخواست تراکنش جدید، هر گره در شبکه اتریوم درخواست را به استخر حافظهای محلی خود اضافه میکند. استخر حافظه لیستی است از تمام درخواستهای تراکنش که در مورد آنها شنیده است و هنوز به زنجیرهی بلوکی در یک بلوک وابسته نشده است.
-4. در برخی مواقع، یک گره استخراج چند ده یا صد درخواست تراکنش را در یک [بلوک](/developers/docs/blocks/) بالقوه تجمیع میکند، به گونهای که [کارمزد تراکنش](/developers/docs/gas/) کسبشدهی آنها را به حداکثر میرساند، در حالی که همچنان زیر حد گاز بلوک باقی میمانند. سپس گرهی استخراج:
- 1. اعتبار هر درخواست تراکنش را تأیید میکند (یعنی هیچکس سعی نمیکند اتر را از حسابی که برای آن امضا تولید نکرده است منتقل کند، درخواست بدفرم نشده است و غیره)، و سپس کد درخواست را اجرا میکند و حالت نسخهی EVM محلی آن را تغییر میدهد. استخراجگر کارمزد تراکنش را برای هر درخواست تراکنش به حساب خود واریز میکند.
- 2. زمانی که تمام درخواستهای تراکنش در بلوک تأیید شده و در نسخه EVM محلی اجرا شد، فرایند تولید «گواهی مشروعیت» اثبات کار برای بلوک بالقوه را آغاز میکند.
-5. در نهایت، یک استخراجگر تولید یک گواهی را برای بلوکی که شامل درخواست تراکنش خاص ما میشود، به پایان میرساند. سپس استخراجگر بلوک تکمیلشده را که شامل گواهینامه و چک تجمیع وضعیت جدید EVM ادعا شده است ارسال میکند.
-6. سایر گرهها در مورد بلوک جدید میشنوند. آنها گواهی را اعتبارسنجی میکنند، همه تراکنشهای روی بلوک را خودشان اجرا میکنند (از جمله تراکنشی که در ابتدا توسط کاربر ما ارسال شد)، و اعتبارسنجی میکنند که بررسی تجمیع وضعیت جدید ماشین مجازی اتریوم (EVM) بعد از اجرای همه تراکنشها، با بررسی تجمیع وضعیت ادعا شده توسط بلوک استخراجگر مطابقت داشته باشد. تنها در این صورت است که این گرهها این بلوک را به انتهای زنجیرهی بلوک خود اضافه میکنند و حالت جدید ماشین مجازی اتریوم (EVM) را بهعنوان حالت متعارف میپذیرند.
-7. هر گره تمام تراکنشهای موجود در بلوک جدید را از استخر حافظهی محلی درخواستهای تراکنش انجامنشدهی خود حذف میکند.
-8. گرههای جدیدی که به شبکه میپیوندند همه بلوکها را به ترتیب دانلود میکنند، از جمله بلوکی که شامل تراکنش مورد علاقه ما است. آنها یک کپی EVM محلی را راه اندازی می کنند (که به عنوان یک EVM حالت خالی شروع می شود)، و سپس فرآیند اجرای هر تراکنش در هر بلوک را در بالای کپی EVM محلی خود انجام می دهند، و بررسی تجمیع وضعیت را در هر بلوک در طول مسیر تأیید می کنند.
-
-هر تراکنش یک بار استخراج میشود (در یک بلوک جدید گنجانده میشود و برای اولین بار منتشر میشود) اما توسط هر شرکتکننده در فرایند پیشرفت حالت متعارف EVM اجرا و تأیید میشود. این نکته یکی از شعارهای اصلی زنجیره بلوکی را خاطرنشان میکند: **اعتماد نکنید، تأیید کنید**.
-
-## بلوک های (عمو) Ommer {#ommer-blocks}
-
-در استخراج بلوک ها در اثبات-کار احتمال دخیل بود، که یعنی به دلیل تاخیر در شبکه احتمال انتشار دو بلوک معتبر همزمان وجود داشت. در این حالت، پروتکل باید طولانیترین زنجیره (و بنابراین زنجیره «معتبر») را تعیین میکرد و همزمان با اعطای بلوک معتبر اضافه نشده، عدالت را در میان استخراجگرها تضمین میکرد. این امر تمرکززدایی بیشتر شبکه را تشویق کرد زیرا ماینرهای کوچکتر، که ممکن است با تأخیر بیشتری مواجه شوند، همچنان میتوانند از طریق پاداشهای بلوک [ommer](/glossary/#ommer) بازدهی ایجاد کنند.
-
-اصطلاح "ommer" اصطلاح ترجیحی از نظر جنسیتی خنثی برای سیبلینگ و بلوک والد است، اما گاهی اوقات به آن عمو (uncle) نیز گفته میشود. **پس از گذر اتریوم به اثبات-کار،هیچ بلوک عمویی استخراج نشده**زیرا تنها یک پیشنهاد دهنده در هر اسلات انتخاب میشود. شما میتوانید این تغییر را در[چارت تاریخی](https://ycharts.com/indicators/ethereum_uncle_rate) بلوک های عموی استخراج شده مشاهده کنید.
-
-## یک نسخهی آزمایشی تصویری {#a-visual-demo}
-
-آستین را تماشا کنید که شما را در راه استخراج و اثبات کار زنجیره بلوکی راهنمایی میکند.
-
-
-
-## الگوریتم استخراج {#mining-algorithm}
-
-شبکه اصلی اتریوم تنها از یک الگوریتم استخراج، یعنی -['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/) استفاده کرده است. Ethash جانشین یک الگوریتم تحقیق و توسعه اصلی شناخته شده به عنوان ["دگر هاشیموتو (Dagger-Hashimoto)"](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) بود.
-
-[اطلاعات بیشتر در مورد الگوریتم های استخراج](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/).
-
-## موضوعات مرتبط {#related-topics}
-
-- [گاز](/developers/docs/gas/)
-- [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)
-- [اثبات کار](/developers/docs/consensus-mechanisms/pow/)
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
deleted file mode 100644
index 3b3f45e7086..00000000000
--- "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md"
+++ /dev/null
@@ -1,334 +0,0 @@
----
-title: Dagger-Hashamoto
-description: نگاهی دقیق به الگوریتم Dagger-Hashimoto.
-lang: fa
----
-
-Dagger-Hashimoto زیرساخت و مشخصات اولیه تحقیقاتی برای الگوریتم استخراج اتریوم بود. Dagger-Hashimoto به [Ethash](#ethash) تغییر نام داده شد. استخراج به طور کامل در [ادغام](/roadmap/merge/) در 15 سپتامبر 2022 خاموش شد. از آن زمان، اتریوم با استفاده از مکانیزم [اثبات سهام](/developers/docs/consensus-mechanisms/pos) ایمن شده است. این صفحه برای رجوع تاریخی است - اطلاعات اینجا دیگر مرتبط به اتریوم پس از ادغام نیست.
-
-## موارد مورد نیاز {#prerequisites}
-
-برای فهم بهتر این مقاله، پیشنهاد می کنیم ابتدا [اجماع اثبات کار](/developers/docs/consensus-mechanisms/pow)،[استخراج](/developers/docs/consensus-mechanisms/pow/mining) و [الگوریتم استخراج](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) را مطالعه کنید.
-
-## Dagger-Hashamoto {#dagger-hashimoto}
-
-Dagger-Hashamato دو هدف را برآورده می کند:
-
-1. **مقاومت در برابر اسیک**: مزیت حاصل از ایجاد سخت افزار تخصصی برای الگوریتم باید تا حد امکان کم باشد
-2. **تأیید پذیری کاربر سبک**: یک بلوک باید به طور مؤثر توسط کاربر سبک قابل تأیید باشد.
-
-با یک تغییر اضافی، همچنین مشخص می کنیم که چگونه می توان یک هدف سوم را در صورت تمایل برآورده کرد، هر چند با بهای افزایش پیچیدگی همراه باشد:
-
-**ذخیرهسازی زنجیره کامل**: استخراج باید به ذخیرهسازی حالت بلاک چین کامل نیاز داشته باشد (به دلیل ساختار نامنظم درخت حالت اتریوم، پیشبینی میکنیم برخی هرسها امکانپذیر باشد، به ویژه در بعضی قراردادهای پرمصرف، ولی می خواهیم این را به حداقل برسانیم).
-
-## تولید DAG {#dag-generation}
-
-کد الگوریتم در Python در زیر تعریف خواهد شد. ابتدا، `encode_int` را برای مارشال کردن اینت های بدون علامت با دقت مشخص به سطرها می دهیم. معکوس آن نیز داده می شود:
-
-```python
-NUM_BITS = 512
-
-def encode_int(x):
- "Encode an integer x as a string of 64 characters using a big-endian scheme"
- o = ''
- for _ in range(NUM_BITS / 8):
- o = chr(x % 256) + o
- x //= 256
- return o
-
-def decode_int(s):
- "Unencode an integer x from a string using a big-endian scheme"
- x = 0
- for c in s:
- x *= 256
- x += ord(c)
- return x
-```
-
-در مرحله بعد فرض می کنیم `sha3` تابعی است که یک عدد صحیح می گیرد و یک عدد صحیح را خروجی می دهد و `dbl_sha3` یک تابع double-sha3 است. اگر این کد مرجع را به یک اجرا تبدیل کنید:
-
-```python
-from pyethereum import utils
-def sha3(x):
- if isinstance(x, (int, long)):
- x = encode_int(x)
- return decode_int(utils.sha3(x))
-
-def dbl_sha3(x):
- if isinstance(x, (int, long)):
- x = encode_int(x)
- return decode_int(utils.sha3(utils.sha3(x)))
-```
-
-### پارامترها {#parameters}
-
-پارامتر هایی که برای الگوریتم مورد استفاده قرار می گیرند:
-
-```python
-SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512
-
-params = {
- "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536
- "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536
- # with epochtime=20000 gives 882 MB growth per year
- "cache_size": 2500, # Size of the light client's cache (can be chosen by light
- # client; not part of the algo spec)
- "diff": 2**14, # Difficulty (adjusted during block evaluation)
- "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated)
- "k": 1, # Number of parents of a node
- "w": w, # Used for modular exponentiation hashing
- "accesses": 200, # Number of dataset accesses during hashimoto
- "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation
-}
-```
-
-`P` در این حالت یک عدد اول انتخاب شده است، طوری که `log₂(P)` فقط کمی کمتر از 512 است، که متناسب با 512 بیتی است که برای نشان دادن اعدادمان استفاده کردهایم. توجه داشته باشید که تنها نیمه دوم DAG در واقع باید ذخیره شود، بنابراین نیاز واقعی RAM از 1 گیگابایت شروع می شود و 441 مگابایت در سال افزایش می یابد.
-
-### ساختار نمودار Dagger {#dagger-graph-building}
-
-ساختار اولیه نمودار Dagger به صورت زیر تعریف می شود:
-
-```python
-def produce_dag(params, seed, length):
- P = params["P"]
- picker = init = pow(sha3(seed), params["w"], P)
- o = [init]
- for i in range(1, length):
- x = picker = (picker * init) % P
- for _ in range(params["k"]):
- x ^= o[x % i]
- o.append(pow(x, params["w"], P))
- return o
-```
-
-اساساً، از یک نمودار به عنوان یک گره منفرد، `sha3(seed)` شروع می شود، و از آنجا شروع به اضافه کردن متوالی گره های دیگر بر اساس گره های تصادفی قبلی می کند. هنگامی که یک گره جدید ایجاد می شود، یک توان مدولار از بذر محاسبه می شود تا به طور تصادفی برخی از شاخص های کمتر از `i` (با استفاده از `x % i` بالا) انتخاب شود، و مقادیر گرهها در آن شاخصها در یک محاسبه برای ایجاد یک مقدار جدید برای `x` استفاده میشوند، که سپس به یک تابع کوچک اثبات کار (بر اساس XOR) وارد میشود تا در نهایت مقدار نمودار در فهرست `i` را ایجاد کند. منطق پشت این طراحی خاص، اجبار به دسترسی متوالی به DAG است. تا زمانی که مقدار فعلی مشخص نشود، مقدار بعدی DAG قابل دسترسی نیست. در نهایت، توان مدولار نتیجه را بیشتر هش می کند.
-
-این الگوریتم بر چندین نتیجه از نظریه اعداد متکی است. برای ادامه بحث به پیوست زیر مراجعه کنید.
-
-## ارزیابی کاربر سبک {#light-client-evaluation}
-
-ساختار نمودار بالا تمایل دارد به هر گره در نمودار اجازه دهد با محاسبه زیردرختی از تعداد کمی گره و نیاز به مقدار کمی حافظه کمکی، بازسازی شود. توجه داشته باشید که با k=1، زیردرخت فقط زنجیره ای از مقادیر است که تا اولین عنصر در DAG بالا می رود.
-
-تابع محاسبات کاربر سبک برای DAG به صورت زیر عمل می کند:
-
-```python
-def quick_calc(params, seed, p):
- w, P = params["w"], params["P"]
- cache = {}
-
- def quick_calc_cached(p):
- if p in cache:
- pass
- elif p == 0:
- cache[p] = pow(sha3(seed), w, P)
- else:
- x = pow(sha3(seed), (p + 1) * w, P)
- for _ in range(params["k"]):
- x ^= quick_calc_cached(x % p)
- cache[p] = pow(x, w, P)
- return cache[p]
-
- return quick_calc_cached(p)
-```
-
-اساساً، این به سادگی بازنویسی الگوریتم فوق است که حلقه محاسبه مقادیر کل DAG را حذف می کند و جستجوی گره قبلی را با یک فراخوان بازگشتی یا جستجوی حافظه پنهان جایگزین می کند. توجه داشته باشید که برای `k=1` حافظه نهان ضروری نیست، اگرچه یک بهینه سازی بیشتر در واقع چند هزار مقدار اول DAG را از قبل محاسبه می کند و آن را به عنوان یک حافظه نهان ثابت برای محاسبات نگه می دارد. برای اجرای کد این مورد به پیوست مراجعه کنید.
-
-## بافر دوگانه DAGها {#double-buffer}
-
-در یک کاربر کامل، یک [_بافر دوگانه_](https://wikipedia.org/wiki/Multiple_buffering) از 2 DAG تولید شده توسط فرمول بالا استفاده می شود. ایده این است که DAG ها در هر تعداد `زمان ایپوک` بلوک، مطابق با پارامترهای بالا تولید می شوند. به جای اینکه مشتری از آخرین DAG تولید شده استفاده کند، از DAG قبلی استفاده می کند. مزیت این کار این است که اجازه می دهد DAG ها در طول زمان بدون نیاز به ترکیب مرحله ای جایگزین شوند که در آن استخراجگرها باید به طور ناگهانی همه داده ها را دوباره محاسبه کنند. در غیر این صورت، پتانسیل کاهش ناگهانی و موقتی در پردازش زنجیره ای در فواصل زمانی منظم و افزایش چشمگیر تمرکز وجود دارد. بنابراین 51 درصد خطر حمله ظرف چند دقیقه قبل از محاسبه مجدد همه داده ها، وجود دارد.
-
-الگوریتم مورد استفاده برای تولید مجموعه ای از DAGهای مورد استفاده برای محاسبه کار برای یک بلوک به شرح زیر است:
-
-```python
-def get_prevhash(n):
- from pyethereum.blocks import GENESIS_PREVHASH
- from pyethereum import chain_manager
- if n <= 0:
- return hash_to_int(GENESIS_PREVHASH)
- else:
- prevhash = chain_manager.index.get_block_by_number(n - 1)
- return decode_int(prevhash)
-
-def get_seedset(params, block):
- seedset = {}
- seedset["back_number"] = block.number - (block.number % params["epochtime"])
- seedset["back_hash"] = get_prevhash(seedset["back_number"])
- seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0)
- seedset["front_hash"] = get_prevhash(seedset["front_number"])
- return seedset
-
-def get_dagsize(params, block):
- return params["n"] + (block.number // params["epochtime"]) * params["n_inc"]
-
-def get_daggerset(params, block):
- dagsz = get_dagsize(params, block)
- seedset = get_seedset(params, block)
- if seedset["front_hash"] <= 0:
- # No back buffer is possible, just make front buffer
- return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
- "block_number": 0}}
- else:
- return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz),
- "block_number": seedset["front_number"]},
- "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz),
- "block_number": seedset["back_number"]}}
-```
-
-## هاشیموتو {#hashimoto}
-
-ایده پشت هاشیموتو اصلی استفاده از بلاک چین به عنوان مجموعه داده، انجام محاسباتی است که N شاخص را از زنجیره بلوکی انتخاب میکند، تراکنشها را در آن شاخصها جمعآوری میکند، XOR این دادهها را انجام میدهد و هشِ نتیجه را برمیگرداند. الگوریتم اصلی Thaddeus Dryja که برای سازگاری به Python ترجمه شده است به شرح زیر است:
-
-```python
-def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce):
- hash_output_A = sha256(prev_hash + merkle_root + nonce)
- txid_mix = 0
- for i in range(64):
- shifted_A = hash_output_A >> i
- transaction = shifted_A % len(list_of_transactions)
- txid_mix ^= list_of_transactions[transaction] << i
- return txid_mix ^ (nonce << 192)
-```
-
-متأسفانه، در حالی که هاشیموتو برای RAM سخت در نظر گرفته می شود، بر محاسبات 256 بیتی متکی است که سربار محاسباتی قابل توجهی دارد. با این حال، Dagger-Hashimoto هنگام نمایه سازی مجموعه داده های خود برای رسیدگی به این مشکل، تنها از حداقل 64 بیت استفاده می کند.
-
-```python
-def hashimoto(dag, dagsize, params, header, nonce):
- m = dagsize / 2
- mix = sha3(encode_int(nonce) + header)
- for _ in range(params["accesses"]):
- mix ^= dag[m + (mix % 2**64) % m]
- return dbl_sha3(mix)
-```
-
-استفاده از SHA3 مضاعف امکان پیشآزمایی فوری و بدون داده را فراهم میکند و فقط تأیید میکند که یک مقدار متوسط صحیح ارائه شده است. این لایه بیرونی اثبات کار بسیار ASIC-پسند و نسبتاً ضعیف است، اما وجود دارد تا DDoS را حتی دشوارتر کند زیرا آن مقدار کم کار باید انجام شود تا بلوکی تولید شود که فوراً رد نشود. این نسخه کاربر سبک است:
-
-```python
-def quick_hashimoto(seed, dagsize, params, header, nonce):
- m = dagsize // 2
- mix = sha3(nonce + header)
- for _ in range(params["accesses"]):
- mix ^= quick_calc(params, seed, m + (mix % 2**64) % m)
- return dbl_sha3(mix)
-```
-
-## استخراج و راستی آزمایی {#mining-and-verifying}
-
-حال، برای االگوریتم استخراج، همه را در کنار یکدیگر قرار می دهیم:
-
-```python
-def mine(daggerset, params, block):
- from random import randint
- nonce = randint(0, 2**64)
- while 1:
- result = hashimoto(daggerset, get_dagsize(params, block),
- params, decode_int(block.prevhash), nonce)
- if result * params["diff"] < 2**256:
- break
- nonce += 1
- if nonce >= 2**64:
- nonce = 0
- return nonce
-```
-
-این الگوریتم تایید است:
-
-```python
-def verify(daggerset, params, block, nonce):
- result = hashimoto(daggerset, get_dagsize(params, block),
- params, decode_int(block.prevhash), nonce)
- return result * params["diff"] < 2**256
-```
-
-راستی آزمایی کاربر سبک:
-
-```python
-def light_verify(params, header, nonce):
- seedset = get_seedset(params, block)
- result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block),
- params, decode_int(block.prevhash), nonce)
- return result * params["diff"] < 2**256
-```
-
-همچنین، توجه داشته باشید که Dagger-Hashimoto الزامات اضافی را بر روی سر بلوک اعمال می کند:
-
-- برای اینکه تأیید دو لایه کار کند، یک سر بلوک باید هم مقدار نانس و هم مقدار میانی pre-sha3 را داشته باشد
-- در جایی، یک سر بلوک باید sha3 مجموعه seedset فعلی را ذخیره کند
-
-## اطلاعات بیشتر {#further-reading}
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
-
-## پیوست {#appendix}
-
-همانطور که در بالا ذکر شد، RNG مورد استفاده برای تولید DAG به برخی نتایج نظریه اعداد متکی است. اول، ما اطمینان می دهیم که Lehmer RNG که مبنایی برای متغیر `picker` است دارای یک دوره گسترده است. دوم، نشان میدهیم که `pow(x,3,P)` `x` را به `1` یا `P-10 نگاشت نمیکند. > x ∈ [2,P-2]` برای شروع ارائه شده است. در نهایت، نشان میدهیم که `pow(x,3,P)` وقتی به عنوان یک تابع هش در نظر گرفته میشود، نرخ برخورد پایینی دارد.
-
-### مولد اعداد تصادفی Lehmer {#lehmer-random-number}
-
-در حالی که تابع `produce_dag` نیازی به تولید اعداد تصادفی بی طرفانه ندارد، یک تهدید بالقوه این است که `seed**i % P` فقط تعداد انگشت شماری از مقادیر را دریافت کند. این می تواند مزیتی برای استخراجگرها ایجاد کند که الگو را نسبت به کسانی که این کار را نمی شناسند، تشخیص دهند.
-
-برای جلوگیری از این امر، از یک نتیجه نظریه اعداد استفاده می شود. [_Safe Prime_](https://en.wikipedia.org/wiki/Safe_prime) به صورت اول `P` تعریف شده است، طوری که `(P-1)/2` نیز اول باشد. _ترتیب_ یک عضو `x` از [گروه ضربی](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` حداقل `m` تعریف شده است، طوری که xᵐ mod P ≡ 1
-با توجه به این تعاریف داریم:
-
-> مشاهده 1. اجازه دهید `x` عضوی از گروه ضربی `ℤ/Pℤ` برای عدد اول امن `P` باشد. اگر `x mod P ≠ 1 mod P` و `x mod P ≠ P-1 mod P`، آنگاه ترتیب `x` یا ` است P-1` یا `(P-1)/2`.
-
-_اثبات_. از آنجا که `P` یک عدد اول امن است، پس با \[قضیه لاگرانژ\] \[لاگرانژ\] میبینیم که ترتیب `x` یا `1` است یا `2` یا `(P-1)/2` یا `P-1`.
-
-ترتیب `x` نمی تواند `1` باشد، زیرا با قضیه کوچک فرما داریم:
-
-xP-1 mod P ≡ 1
-
-بنابراین `x` باید یک هویت ضربی از `ℤ/nℤ` باشد، که منحصر به فرد است. از آنجا که فرض کردیم `x ≠ 1`، بر اساس فرض، این امکان پذیر نیست.
-
-ترتیب `x` نمی تواند `2` باشد مگر اینکه `x = P-1` باشد، زیرا این امر ناقض اصلی بودن `P` است.
-
-از گزاره بالا، می توانیم تشخیص دهیم که تکرار `( picker * init) % P` دارای طول چرخه حداقل `(P-1)/2` خواهد بود. این به این دلیل است که ما `P` را به عنوان یک عدد اول امن تقریباً برابر با توان بالاتر از دو انتخاب کردیم و `init` در بازه `[2,2**256+1]` است. با توجه به بزرگی `P`، هرگز نباید انتظار چرخه ای از توان مدولار داشته باشیم.
-
-هنگامی که اولین سلول را در DAG اختصاص می دهیم (متغیر با برچسب `init`)، `pow(sha3(seed) + 2, 3, P)` را محاسبه می کنیم. در نگاه اول، این تضمین نمی کند که نتیجه نه `1` و نه `P-1` باشد. با این حال، از آنجا که `P-1` یک عدد اول امن است، ما تضمین اضافی زیر را داریم که نتیجه مشاهده 1 است:
-
-> مشاهده 2. اجازه دهید `x` عضوی از گروه ضربی `ℤ/Pℤ` برای عدد اول امن `P` باشد، و اجازه دهید `w` یک عدد طبیعی باشد. اگر `x mod P ≠ 1 mod P` و `x mod P ≠ P-1 mod P`، و همچنین `w mod P ≠ P-1 mod P 0> و w mod P ≠ 0 mod P`، سپس `xʷ mod P ≠ 1 mod P` و `xʷ mod P ≠ P-1 mod P`
-
-### توان مدولار به عنوان یک تابع هش {#modular-exponentiation}
-
-برای مقادیر معینی از `P` و `w`، تابع `pow(x، w، P)` ممکن است برخوردهای زیادی داشته باشد. برای مثال، `pow(x,9,19)` فقط مقادیر `{1,18}` را می گیرد.
-
-با توجه به اینکه `P` اول است، میتوان با استفاده از نتیجه زیر، یک `w` مناسب برای یک تابع درهمسازی توان مدولار انتخاب کرد:
-
-> مشاهده 3. بگذارید `P` عدد اول باشد. `w` و `P-1` نسبتاً اول هستند اگر و فقط اگر برای همه `a` و `b` در `ℤ /Pℤ`:
->
->
-> «aʷ mod P ≡ bʷ mod P» اگر و فقط اگر «a mod P ≡ b mod P»
->
-
-بنابراین، با توجه به اینکه `P` اول است و `w` نسبتاً اول نسبت به `P-1`، داریم که `|{pow(x, w, P) : x ∈ ℤ}| = P`، به این معنی است که تابع هش حداقل نرخ برخورد ممکن را دارد.
-
-در حالت خاصی که `P` همانطور که انتخاب کردهایم یک عدد اول امن است، پس `P-1` فقط فاکتورهای 1، 2، `(P-1)/2` و `P-1` را دارد. از آنجا که `P` > 7، می دانیم که 3 نسبتاً اول نسبت به `P-1` است، بنابراین `w=3` گزاره فوق را برآورده می کند.
-
-## الگوریتم کارآمدتر ارزیابی مبتنی بر حافظه پنهان {#cache-based-evaluation}
-
-```python
-def quick_calc(params, seed, p):
- cache = produce_dag(params, seed, params["cache_size"])
- return quick_calc_cached(cache, params, p)
-
-def quick_calc_cached(cache, params, p):
- P = params["P"]
- if p < len(cache):
- return cache[p]
- else:
- x = pow(cache[0], p + 1, P)
- for _ in range(params["k"]):
- x ^= quick_calc_cached(cache, params, x % p)
- return pow(x, params["w"], P)
-
-def quick_hashimoto(seed, dagsize, params, header, nonce):
- cache = produce_dag(params, seed, params["cache_size"])
- return quick_hashimoto_cached(cache, dagsize, params, header, nonce)
-
-def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
- m = dagsize // 2
- mask = 2**64 - 1
- mix = sha3(encode_int(nonce) + header)
- for _ in range(params["accesses"]):
- mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
- return dbl_sha3(mix)
-```
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
deleted file mode 100644
index 1f40853bfd7..00000000000
--- "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md"
+++ /dev/null
@@ -1,1014 +0,0 @@
----
-title: یک الگوریتم اثبات انجام کار برای اتریوم ۱. ۰
-description: نگاهی دقیق به الگوریتم Ethash.
-lang: fa
----
-
-
- Ethash الگوریتم استخراج اثبات کار اتریوم بود. اثبات کار اکنون **به طور کامل خاموش شده** و اتریوم اکنون با استفاده از اثبات سهام امن شده است. درباره ادغام و اثبات سهام و سهام گذاری بیشتر بخوانید. این صفحه صرفاً برای علاقهمندان به تاریخ است!
-
-
-[Ethash](https://github.com/ethereum/wiki/wiki/Ethash) نسخه اصلاح شده الگوریتم [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) است. اثبات کار Ethash نیازمند [حافظه سخت](https://wikipedia.org/wiki/Memory-hard_function) است که تصور میشد این الگوریتم را در برابر دستگاههای ASIC مقاوم میکند. در نهایت، دستگاههای Ethash ASIC توسعه یافتند، اما تا زمانی که اثبات کار خاموش شد، استخراج با GPU همچنان یک گزینه قابل اجرا بود. Ethash هنوز برای استخراج سکه های دیگر در سایر شبکه های اثبات کار غیر اتریوم استفاده می شود.
-
-## Ethash چگونه کار می کند؟ {#how-does-ethash-work}
-
-سختی حافظه با الگوریتم اثبات کار به دست می آید که مستلزم انتخاب زیر مجموعه های یک منبع ثابت وابسته به سر نانس و بلوک است. این منبع (به اندازه چند گیگابایت) DAG نامیده می شود. DAG هر 30000 بلوک تغییر می کند، یعنی یک پنجره حدودا 125 ساعته به نام ایپوک (تقریباً 5.2 روز) و مدتی طول می کشد تا تولید شود. از آنجا که DAG فقط به ارتفاع بلوک بستگی دارد، میتوان آن را از پیش تولید کرد، اما اگر تولید نشده باشد، کاربر باید تا پایان این فرآیند منتظر بماند تا بتواند بلوک تولید کند. اگر کاربرها DAGها را از قبل تولید و ذخیره نکنند، ممکن است شبکه در هر انتقال دوره با تأخیر عظیم در بلوک مواجه شود. توجه داشته باشید که برای تأیید اثبات کار نیازی به تولید DAG نیست و این امکان را میدهد که تأیید با پردازنده کم مصرف و حافظه کم انجام شود.
-
-مسیر کلی که الگوریتم طی می کند به شرح زیر است:
-
-1. برای هر بلوک یک **بذر** وجود دارد که با اسکن کردن سرهای بلوک تا آن نقطه قابل محاسبه است.
-2. از روی این بذر، میتوان یک **حافظه پنهان شبهتصادفی ۱۶ مگابایتی** محاسبه کرد. کاربرهای سبک، حافظه پنهان را ذخیره میکنند.
-3. از حافظه پنهان، میتوانیم یک مجموعه داده **یک گیگابایتی** تولید کنیم، طوری که هر آیتم در این مجموعه داده فقط به تعداد کمی از آیتمهای حافظه پنهان وابسته است. کاربرهای کامل و استخراجگرها مجموعه داده را ذخیره میکنند. مجموعه داده به صورت خطی با زمان رشد می کند.
-4. استخراج شامل گرفتن برشهای تصادفی از مجموعه داده و هش کردن آنها با هم است. تأیید را میتوان با استفاده از حافظه پنهان برای بازسازی قطعات خاص مجموعه داده مورد نیاز با حافظه کم انجام داد، بنابراین فقط نیاز به ذخیره حافظه پنهان دارید.
-
-مجموعه داده بزرگ هر 30000 بلوک یک بار بهروزرسانی میشود، بنابراین اکثر تلاشهای یک استخراجگر صرف خواندن مجموعه داده میشود، نه ایجاد تغییر در آن.
-
-## تعاریف {#definitions}
-
-ما از تعاریف زیر استفاده می کنیم:
-
-```
-WORD_BYTES = 4 # bytes in word
-DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis
-DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch
-CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis
-CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch
-CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache
-EPOCH_LENGTH = 30000 # blocks per epoch
-MIX_BYTES = 128 # width of mix
-HASH_BYTES = 64 # hash length in bytes
-DATASET_PARENTS = 256 # number of parents of each dataset element
-CACHE_ROUNDS = 3 # number of rounds in cache production
-ACCESSES = 64 # number of accesses in hashimoto loop
-```
-
-### استفاده از 'SHA3' {#sha3}
-
-توسعه اتریوم همزمان با توسعه استاندارد SHA3 انجام شد و فرآیند استانداردسازی تغییری دیرهنگام در پرکردن الگوریتم هش نهایی ایجاد کرد، طوری که هشهای "sha3_256" و "sha3_512" اتریوم هشهای استاندارد sha3 نیستند، بلکه نوعی متفاوت هستند که اغلب در زمینههای دیگر به عنوان "Keccak-256" و "Keccak-512" شناخته میشوند. برای اطلاعات بیشتر، به بحثهای انجام شده در [اینجا](https://eips.ethereum.org/EIPS/eip-1803)، [اینجا](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use)، یا [اینجا](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057) مراجعه کنید.
-
-لطفا این نکته را در نظر داشته باشید که در توضیحات الگوریتم زیر به هشهای "sha3" اشاره شده است.
-
-## پارامترها {#parameters}
-
-پارامترهای حافظه پنهان و مجموعه داده Ethash وابسته به شماره بلوک هستند. اندازه حافظه پنهان و اندازه مجموعه داده هر دو به صورت خطی رشد میکنند؛ با این حال، برای کاهش خطر ایجاد الگوهای تکراری منجر به رفتار چرخهای، همیشه بزرگترین عدد اول کمتر از آستانه رشد خطی را انتخاب میکنیم.
-
-```python
-def get_cache_size(block_number):
- sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
- sz -= HASH_BYTES
- while not isprime(sz / HASH_BYTES):
- sz -= 2 * HASH_BYTES
- return sz
-
-def get_full_size(block_number):
- sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
- sz -= MIX_BYTES
- while not isprime(sz / MIX_BYTES):
- sz -= 2 * MIX_BYTES
- return sz
-```
-
-جدولهای مقادیر اندازه حافظه پنهان و مجموعه داده در ضمیمه ارائه شده است.
-
-## تولید حافظه پنهان {#cache-generation}
-
-اکنون تابع تولید حافظه پنهان را مشخص می کنیم:
-
-```python
-def mkcache(cache_size, seed):
- n = cache_size // HASH_BYTES
-
- # Sequentially produce the initial dataset
- o = [sha3_512(seed)]
- for i in range(1, n):
- o.append(sha3_512(o[-1]))
-
- # Use a low-round version of randmemohash
- for _ in range(CACHE_ROUNDS):
- for i in range(n):
- v = o[i][0] % n
- o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v]))
-
- return o
-```
-
-فرآیند تولید حافظه پنهان شامل پر کردن متوالی 32 مگابایت حافظه میشود، سپس دو پاس از الگوریتم _RandMemoHash_ سرجیو دمیان لرنر از [_Strict Memory Hard Hashing Functions_ (2014) انجام میشود](http://www.hashcash.org/papers/memohash.pdf). خروجی، یک مجموعه شامل ۵۲۴۲۸۸ مقدار ۶۴ بایتی است.
-
-## تابع تجمیع داده ها {#date-aggregation-function}
-
-در برخی موارد از یک الگوریتم الهام گرفته از [هش FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) به عنوان جایگزینی غیر تداعی برای XOR استفاده میکنیم. توجه داشته باشید که ما عدد اول را در کل ورودی ۳۲ بیتی ضرب میکنیم، برخلاف مشخصات FNV-1 که عدد اول را با هر بایت (octet) به نوبت ضرب میکند.
-
-```python
-FNV_PRIME = 0x01000193
-
-def fnv(v1, v2):
- return ((v1 * FNV_PRIME) ^ v2) % 2**32
-```
-
-لطفا توجه داشته باشید که حتی وایتپیپر نیز fnv را به عنوان v1*(FNV_PRIME ^ v2) مشخص میکند، اما تمام اجراهای فعلی به طور مداوم از تعریف بالا استفاده میکنند.
-
-## محاسبه کامل مجموعه داده {#full-dataset-calculation}
-
-هر آیتم ۶۴ بایتی در کل مجموعه داده ۱ گیگابایتی به شرح زیر محاسبه میشود:
-
-```python
-def calc_dataset_item(cache, i):
- n = len(cache)
- r = HASH_BYTES // WORD_BYTES
- # initialize the mix
- mix = copy.copy(cache[i % n])
- mix[0] ^= i
- mix = sha3_512(mix)
- # fnv it with a lot of random cache nodes based on i
- for j in range(DATASET_PARENTS):
- cache_index = fnv(i ^ j, mix[j % r])
- mix = map(fnv, mix, cache[cache_index % n])
- return sha3_512(mix)
-```
-
-در اصل، ما دادهها را از ۲۵۶ گره حافظه پنهان انتخاب شده به صورت شبهتصادفی ترکیب میکنیم و آن را هش میکنیم تا گره مجموعه داده را محاسبه کنیم. کل مجموعه داده سپس با استفاده از روش زیر تولید میشود:
-
-```python
-def calc_dataset(full_size, cache):
- return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
-```
-
-## حلقه اصلی {#main-loop}
-
-حالا حلقه اصلی شبیه به "hashimoto" را مشخص میکنیم که در آن دادهها را از کل مجموعه داده جمعآوری میکنیم تا مقدار نهایی خود را برای یک سر و نانسِ خاص تولید کنیم. در کد زیر، `header` نشان دهنده _هش SHA3-256_ از نمایش RLP یک سر بلوک _بریده شده_ است، یعنی سر بدون فیلدهای **mixHash** و **nonce**. `نانس` هشت بایت از یک عدد صحیح بدون علامت ۶۴ بیتی با ترتیب بزرگ به کوچک است. پس `nonce[::-1]` نمایش هشت بایتی با ترتیب کوچک به بزرگ little-endian از آن مقدار است:
-
-```python
-def hashimoto(header, nonce, full_size, dataset_lookup):
- n = full_size / HASH_BYTES
- w = MIX_BYTES // WORD_BYTES
- mixhashes = MIX_BYTES / HASH_BYTES
- # combine header+nonce into a 64 byte seed
- s = sha3_512(header + nonce[::-1])
- # start the mix with replicated s
- mix = []
- for _ in range(MIX_BYTES / HASH_BYTES):
- mix.extend(s)
- # mix in random dataset nodes
- for i in range(ACCESSES):
- p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
- newdata = []
- for j in range(MIX_BYTES / HASH_BYTES):
- newdata.extend(dataset_lookup(p + j))
- mix = map(fnv, mix, newdata)
- # compress mix
- cmix = []
- for i in range(0, len(mix), 4):
- cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
- return {
- "mix digest": serialize_hash(cmix),
- "result": serialize_hash(sha3_256(s+cmix))
- }
-
-def hashimoto_light(full_size, cache, header, nonce):
- return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))
-
-def hashimoto_full(full_size, dataset, header, nonce):
- return hashimoto(header, nonce, full_size, lambda x: dataset[x])
-```
-
-در اصل، ما یک "میکس" ۱۲۸ بایتی را حفظ میکنیم و به طور متوالی ۱۲۸ بایت را از کل مجموعه داده دریافت کرده و از تابع `fnv` برای ترکیب آن با میکس استفاده میکنیم. از ۱۲۸ بایت دسترسی متوالی استفاده میشود تا هر دور از الگوریتم همیشه یک صفحه کامل را از رم دریافت کند و خطای حافظه پنهان ترجمه را به حداقل برساند که از نظر تئوری ASICها میتوانند از آن جلوگیری کنند.
-
-اگر خروجی این الگوریتم کمتر از هدف مورد نظر باشد، پس نانس معتبر است. توجه داشته باشید که اعمال اضافی `sha3_256` در انتها تضمین میکند که یک نانس میانی وجود دارد که میتواند برای اثبات انجام حداقل مقدار کار ارائه شود؛ این تأیید سریع PoW خارجی میتواند برای اهداف ضد DDoS استفاده شود. همچنین برای ارائه اطمینان آماری از اینکه نتیجه یک عدد ۲۵۶ بیتی بدون سوگیری است، عمل میکند.
-
-## استخراج {#mining}
-
-الگوریتم استخراج به صورت زیر تعریف شده است:
-
-```python
-def mine(full_size, dataset, header, difficulty):
- # zero-pad target to compare with hash on the same digit
- target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
- from random import randint
- nonce = randint(0, 2**64)
- while hashimoto_full(full_size, dataset, header, nonce) > target:
- nonce = (nonce + 1) % 2**64
- return nonce
-```
-
-## تعریف هش بذر {#seed-hash}
-
-برای محاسبه هش بذر که برای استخراج در بالای یک بلوک مورد استفاده قرار می گیرد، از الگوریتم زیر استفاده می کنیم:
-
-```python
- def get_seedhash(block):
- s = '\x00' * 32
- for i in range(block.number // EPOCH_LENGTH):
- s = serialize_hash(sha3_256(s))
- return s
-```
-
-توجه داشته باشید که برای استخراج و تأیید روان، توصیه میشود که seedhashها و مجموعه دادههای آینده را در یک رشته جداگانه از قبل محاسبه کنید.
-
-## بیشتر بخوانید {#further-reading}
-
-_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
-
-## پیوست {#appendix}
-
-در صورتی که علاقهمند به اجرای مشخصات پایتون بالا به عنوان کد هستید، باید کد زیر را در ابتدای آن قرار دهید.
-
-```python
-import sha3, copy
-
-# Assumes little endian bit ordering (same as Intel architectures)
-def decode_int(s):
- return int(s[::-1].encode('hex'), 16) if s else 0
-
-def encode_int(s):
- a = "%x" % s
- return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1]
-
-def zpad(s, length):
- return s + '\x00' * max(0, length - len(s))
-
-def serialize_hash(h):
- return ''.join([zpad(encode_int(x), 4) for x in h])
-
-def deserialize_hash(h):
- return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)]
-
-def hash_words(h, sz, x):
- if isinstance(x, list):
- x = serialize_hash(x)
- y = h(x)
- return deserialize_hash(y)
-
-def serialize_cache(ds):
- return ''.join([serialize_hash(h) for h in ds])
-
-serialize_dataset = serialize_cache
-
-# sha3 hash function, outputs 64 bytes
-def sha3_512(x):
- return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
-
-def sha3_256(x):
- return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x)
-
-def xor(a, b):
- return a ^ b
-
-def isprime(x):
- for i in range(2, int(x**0.5)):
- if x % i == 0:
- return False
- return True
-```
-
-### اندازه داده ها {#data-sizes}
-
-جدولهای جستجوی زیر تقریباً ۲۰۴۸ دوره محاسباتی جدولبندی شده از اندازههای دادهها و اندازههای کش را ارائه میدهند.
-
-```python
-def get_datasize(block_number):
- return data_sizes[block_number // EPOCH_LENGTH]
-
-def get_cachesize(block_number):
- return cache_sizes[block_number // EPOCH_LENGTH]
-
-data_sizes = [
-1073739904, 1082130304, 1090514816, 1098906752, 1107293056,
-1115684224, 1124070016, 1132461952, 1140849536, 1149232768,
-1157627776, 1166013824, 1174404736, 1182786944, 1191180416,
-1199568512, 1207958912, 1216345216, 1224732032, 1233124736,
-1241513344, 1249902464, 1258290304, 1266673792, 1275067264,
-1283453312, 1291844992, 1300234112, 1308619904, 1317010048,
-1325397376, 1333787776, 1342176128, 1350561664, 1358954368,
-1367339392, 1375731584, 1384118144, 1392507008, 1400897408,
-1409284736, 1417673344, 1426062464, 1434451072, 1442839168,
-1451229056, 1459615616, 1468006016, 1476394112, 1484782976,
-1493171584, 1501559168, 1509948032, 1518337664, 1526726528,
-1535114624, 1543503488, 1551892096, 1560278656, 1568669056,
-1577056384, 1585446272, 1593831296, 1602219392, 1610610304,
-1619000192, 1627386752, 1635773824, 1644164224, 1652555648,
-1660943488, 1669332608, 1677721216, 1686109312, 1694497664,
-1702886272, 1711274624, 1719661184, 1728047744, 1736434816,
-1744829056, 1753218944, 1761606272, 1769995904, 1778382464,
-1786772864, 1795157888, 1803550592, 1811937664, 1820327552,
-1828711552, 1837102976, 1845488768, 1853879936, 1862269312,
-1870656896, 1879048064, 1887431552, 1895825024, 1904212096,
-1912601216, 1920988544, 1929379456, 1937765504, 1946156672,
-1954543232, 1962932096, 1971321728, 1979707264, 1988093056,
-1996487552, 2004874624, 2013262208, 2021653888, 2030039936,
-2038430848, 2046819968, 2055208576, 2063596672, 2071981952,
-2080373632, 2088762752, 2097149056, 2105539712, 2113928576,
-2122315136, 2130700672, 2139092608, 2147483264, 2155872128,
-2164257664, 2172642176, 2181035392, 2189426048, 2197814912,
-2206203008, 2214587264, 2222979712, 2231367808, 2239758208,
-2248145024, 2256527744, 2264922752, 2273312128, 2281701248,
-2290086272, 2298476672, 2306867072, 2315251072, 2323639168,
-2332032128, 2340420224, 2348808064, 2357196416, 2365580416,
-2373966976, 2382363008, 2390748544, 2399139968, 2407530368,
-2415918976, 2424307328, 2432695424, 2441084288, 2449472384,
-2457861248, 2466247808, 2474637184, 2483026816, 2491414144,
-2499803776, 2508191872, 2516582272, 2524970368, 2533359232,
-2541743488, 2550134144, 2558525056, 2566913408, 2575301504,
-2583686528, 2592073856, 2600467328, 2608856192, 2617240448,
-2625631616, 2634022016, 2642407552, 2650796416, 2659188352,
-2667574912, 2675965312, 2684352896, 2692738688, 2701130624,
-2709518464, 2717907328, 2726293376, 2734685056, 2743073152,
-2751462016, 2759851648, 2768232832, 2776625536, 2785017728,
-2793401984, 2801794432, 2810182016, 2818571648, 2826959488,
-2835349376, 2843734144, 2852121472, 2860514432, 2868900992,
-2877286784, 2885676928, 2894069632, 2902451584, 2910843008,
-2919234688, 2927622784, 2936011648, 2944400768, 2952789376,
-2961177728, 2969565568, 2977951616, 2986338944, 2994731392,
-3003120256, 3011508352, 3019895936, 3028287104, 3036675968,
-3045063808, 3053452928, 3061837696, 3070228352, 3078615424,
-3087003776, 3095394944, 3103782272, 3112173184, 3120562048,
-3128944768, 3137339264, 3145725056, 3154109312, 3162505088,
-3170893184, 3179280256, 3187669376, 3196056704, 3204445568,
-3212836736, 3221224064, 3229612928, 3238002304, 3246391168,
-3254778496, 3263165824, 3271556224, 3279944576, 3288332416,
-3296719232, 3305110912, 3313500032, 3321887104, 3330273152,
-3338658944, 3347053184, 3355440512, 3363827072, 3372220288,
-3380608384, 3388997504, 3397384576, 3405774208, 3414163072,
-3422551936, 3430937984, 3439328384, 3447714176, 3456104576,
-3464493952, 3472883584, 3481268864, 3489655168, 3498048896,
-3506434432, 3514826368, 3523213952, 3531603584, 3539987072,
-3548380288, 3556763264, 3565157248, 3573545344, 3581934464,
-3590324096, 3598712704, 3607098752, 3615488384, 3623877248,
-3632265856, 3640646528, 3649043584, 3657430144, 3665821568,
-3674207872, 3682597504, 3690984832, 3699367808, 3707764352,
-3716152448, 3724541056, 3732925568, 3741318016, 3749706368,
-3758091136, 3766481536, 3774872704, 3783260032, 3791650432,
-3800036224, 3808427648, 3816815488, 3825204608, 3833592704,
-3841981568, 3850370432, 3858755968, 3867147904, 3875536256,
-3883920512, 3892313728, 3900702592, 3909087872, 3917478784,
-3925868416, 3934256512, 3942645376, 3951032192, 3959422336,
-3967809152, 3976200064, 3984588416, 3992974976, 4001363584,
-4009751168, 4018141312, 4026530432, 4034911616, 4043308928,
-4051695488, 4060084352, 4068472448, 4076862848, 4085249408,
-4093640576, 4102028416, 4110413696, 4118805632, 4127194496,
-4135583104, 4143971968, 4152360832, 4160746112, 4169135744,
-4177525888, 4185912704, 4194303616, 4202691968, 4211076736,
-4219463552, 4227855488, 4236246656, 4244633728, 4253022848,
-4261412224, 4269799808, 4278184832, 4286578048, 4294962304,
-4303349632, 4311743104, 4320130432, 4328521088, 4336909184,
-4345295488, 4353687424, 4362073472, 4370458496, 4378852736,
-4387238528, 4395630208, 4404019072, 4412407424, 4420790656,
-4429182848, 4437571456, 4445962112, 4454344064, 4462738048,
-4471119232, 4479516544, 4487904128, 4496289664, 4504682368,
-4513068416, 4521459584, 4529846144, 4538232704, 4546619776,
-4555010176, 4563402112, 4571790208, 4580174464, 4588567936,
-4596957056, 4605344896, 4613734016, 4622119808, 4630511488,
-4638898816, 4647287936, 4655675264, 4664065664, 4672451968,
-4680842624, 4689231488, 4697620352, 4706007424, 4714397056,
-4722786176, 4731173248, 4739562368, 4747951744, 4756340608,
-4764727936, 4773114496, 4781504384, 4789894784, 4798283648,
-4806667648, 4815059584, 4823449472, 4831835776, 4840226176,
-4848612224, 4857003392, 4865391488, 4873780096, 4882169728,
-4890557312, 4898946944, 4907333248, 4915722368, 4924110976,
-4932499328, 4940889728, 4949276032, 4957666432, 4966054784,
-4974438016, 4982831488, 4991221376, 4999607168, 5007998848,
-5016386432, 5024763776, 5033164672, 5041544576, 5049941888,
-5058329728, 5066717056, 5075107456, 5083494272, 5091883904,
-5100273536, 5108662144, 5117048192, 5125436032, 5133827456,
-5142215296, 5150605184, 5158993024, 5167382144, 5175769472,
-5184157568, 5192543872, 5200936064, 5209324928, 5217711232,
-5226102656, 5234490496, 5242877312, 5251263872, 5259654016,
-5268040832, 5276434304, 5284819328, 5293209728, 5301598592,
-5309986688, 5318374784, 5326764416, 5335151488, 5343542144,
-5351929472, 5360319872, 5368706944, 5377096576, 5385484928,
-5393871232, 5402263424, 5410650496, 5419040384, 5427426944,
-5435816576, 5444205952, 5452594816, 5460981376, 5469367936,
-5477760896, 5486148736, 5494536832, 5502925952, 5511315328,
-5519703424, 5528089984, 5536481152, 5544869504, 5553256064,
-5561645696, 5570032768, 5578423936, 5586811264, 5595193216,
-5603585408, 5611972736, 5620366208, 5628750464, 5637143936,
-5645528192, 5653921408, 5662310272, 5670694784, 5679082624,
-5687474048, 5695864448, 5704251008, 5712641408, 5721030272,
-5729416832, 5737806208, 5746194304, 5754583936, 5762969984,
-5771358592, 5779748224, 5788137856, 5796527488, 5804911232,
-5813300608, 5821692544, 5830082176, 5838468992, 5846855552,
-5855247488, 5863636096, 5872024448, 5880411008, 5888799872,
-5897186432, 5905576832, 5913966976, 5922352768, 5930744704,
-5939132288, 5947522432, 5955911296, 5964299392, 5972688256,
-5981074304, 5989465472, 5997851008, 6006241408, 6014627968,
-6023015552, 6031408256, 6039796096, 6048185216, 6056574848,
-6064963456, 6073351808, 6081736064, 6090128768, 6098517632,
-6106906496, 6115289216, 6123680896, 6132070016, 6140459648,
-6148849024, 6157237376, 6165624704, 6174009728, 6182403712,
-6190792064, 6199176064, 6207569792, 6215952256, 6224345216,
-6232732544, 6241124224, 6249510272, 6257899136, 6266287744,
-6274676864, 6283065728, 6291454336, 6299843456, 6308232064,
-6316620928, 6325006208, 6333395584, 6341784704, 6350174848,
-6358562176, 6366951296, 6375337856, 6383729536, 6392119168,
-6400504192, 6408895616, 6417283456, 6425673344, 6434059136,
-6442444672, 6450837376, 6459223424, 6467613056, 6476004224,
-6484393088, 6492781952, 6501170048, 6509555072, 6517947008,
-6526336384, 6534725504, 6543112832, 6551500672, 6559888768,
-6568278656, 6576662912, 6585055616, 6593443456, 6601834112,
-6610219648, 6618610304, 6626999168, 6635385472, 6643777408,
-6652164224, 6660552832, 6668941952, 6677330048, 6685719424,
-6694107776, 6702493568, 6710882176, 6719274112, 6727662976,
-6736052096, 6744437632, 6752825984, 6761213824, 6769604224,
-6777993856, 6786383488, 6794770816, 6803158144, 6811549312,
-6819937664, 6828326528, 6836706176, 6845101696, 6853491328,
-6861880448, 6870269312, 6878655104, 6887046272, 6895433344,
-6903822208, 6912212864, 6920596864, 6928988288, 6937377152,
-6945764992, 6954149248, 6962544256, 6970928768, 6979317376,
-6987709312, 6996093824, 7004487296, 7012875392, 7021258624,
-7029652352, 7038038912, 7046427776, 7054818944, 7063207808,
-7071595136, 7079980928, 7088372608, 7096759424, 7105149824,
-7113536896, 7121928064, 7130315392, 7138699648, 7147092352,
-7155479168, 7163865728, 7172249984, 7180648064, 7189036672,
-7197424768, 7205810816, 7214196608, 7222589824, 7230975104,
-7239367552, 7247755904, 7256145536, 7264533376, 7272921472,
-7281308032, 7289694848, 7298088832, 7306471808, 7314864512,
-7323253888, 7331643008, 7340029568, 7348419712, 7356808832,
-7365196672, 7373585792, 7381973888, 7390362752, 7398750592,
-7407138944, 7415528576, 7423915648, 7432302208, 7440690304,
-7449080192, 7457472128, 7465860992, 7474249088, 7482635648,
-7491023744, 7499412608, 7507803008, 7516192384, 7524579968,
-7532967296, 7541358464, 7549745792, 7558134656, 7566524032,
-7574912896, 7583300992, 7591690112, 7600075136, 7608466816,
-7616854912, 7625244544, 7633629824, 7642020992, 7650410368,
-7658794112, 7667187328, 7675574912, 7683961984, 7692349568,
-7700739712, 7709130368, 7717519232, 7725905536, 7734295424,
-7742683264, 7751069056, 7759457408, 7767849088, 7776238208,
-7784626816, 7793014912, 7801405312, 7809792128, 7818179968,
-7826571136, 7834957184, 7843347328, 7851732352, 7860124544,
-7868512384, 7876902016, 7885287808, 7893679744, 7902067072,
-7910455936, 7918844288, 7927230848, 7935622784, 7944009344,
-7952400256, 7960786048, 7969176704, 7977565312, 7985953408,
-7994339968, 8002730368, 8011119488, 8019508096, 8027896192,
-8036285056, 8044674688, 8053062272, 8061448832, 8069838464,
-8078227328, 8086616704, 8095006592, 8103393664, 8111783552,
-8120171392, 8128560256, 8136949376, 8145336704, 8153726848,
-8162114944, 8170503296, 8178891904, 8187280768, 8195669632,
-8204058496, 8212444544, 8220834176, 8229222272, 8237612672,
-8246000768, 8254389376, 8262775168, 8271167104, 8279553664,
-8287944064, 8296333184, 8304715136, 8313108352, 8321497984,
-8329885568, 8338274432, 8346663296, 8355052928, 8363441536,
-8371828352, 8380217984, 8388606592, 8396996224, 8405384576,
-8413772672, 8422161536, 8430549376, 8438939008, 8447326592,
-8455715456, 8464104832, 8472492928, 8480882048, 8489270656,
-8497659776, 8506045312, 8514434944, 8522823808, 8531208832,
-8539602304, 8547990656, 8556378752, 8564768384, 8573154176,
-8581542784, 8589933952, 8598322816, 8606705024, 8615099264,
-8623487872, 8631876992, 8640264064, 8648653952, 8657040256,
-8665430656, 8673820544, 8682209152, 8690592128, 8698977152,
-8707374464, 8715763328, 8724151424, 8732540032, 8740928384,
-8749315712, 8757704576, 8766089344, 8774480768, 8782871936,
-8791260032, 8799645824, 8808034432, 8816426368, 8824812928,
-8833199488, 8841591424, 8849976448, 8858366336, 8866757248,
-8875147136, 8883532928, 8891923328, 8900306816, 8908700288,
-8917088384, 8925478784, 8933867392, 8942250368, 8950644608,
-8959032704, 8967420544, 8975809664, 8984197504, 8992584064,
-9000976256, 9009362048, 9017752448, 9026141312, 9034530688,
-9042917504, 9051307904, 9059694208, 9068084864, 9076471424,
-9084861824, 9093250688, 9101638528, 9110027648, 9118416512,
-9126803584, 9135188096, 9143581312, 9151969664, 9160356224,
-9168747136, 9177134464, 9185525632, 9193910144, 9202302848,
-9210690688, 9219079552, 9227465344, 9235854464, 9244244864,
-9252633472, 9261021824, 9269411456, 9277799296, 9286188928,
-9294574208, 9302965888, 9311351936, 9319740032, 9328131968,
-9336516736, 9344907392, 9353296768, 9361685888, 9370074752,
-9378463616, 9386849408, 9395239808, 9403629184, 9412016512,
-9420405376, 9428795008, 9437181568, 9445570688, 9453960832,
-9462346624, 9470738048, 9479121536, 9487515008, 9495903616,
-9504289664, 9512678528, 9521067904, 9529456256, 9537843584,
-9546233728, 9554621312, 9563011456, 9571398784, 9579788672,
-9588178304, 9596567168, 9604954496, 9613343104, 9621732992,
-9630121856, 9638508416, 9646898816, 9655283584, 9663675776,
-9672061312, 9680449664, 9688840064, 9697230464, 9705617536,
-9714003584, 9722393984, 9730772608, 9739172224, 9747561088,
-9755945344, 9764338816, 9772726144, 9781116544, 9789503872,
-9797892992, 9806282624, 9814670464, 9823056512, 9831439232,
-9839833984, 9848224384, 9856613504, 9865000576, 9873391232,
-9881772416, 9890162816, 9898556288, 9906940544, 9915333248,
-9923721088, 9932108672, 9940496512, 9948888448, 9957276544,
-9965666176, 9974048384, 9982441088, 9990830464, 9999219584,
-10007602816, 10015996544, 10024385152, 10032774016, 10041163648,
-10049548928, 10057940096, 10066329472, 10074717824, 10083105152,
-10091495296, 10099878784, 10108272256, 10116660608, 10125049216,
-10133437312, 10141825664, 10150213504, 10158601088, 10166991232,
-10175378816, 10183766144, 10192157312, 10200545408, 10208935552,
-10217322112, 10225712768, 10234099328, 10242489472, 10250876032,
-10259264896, 10267656064, 10276042624, 10284429184, 10292820352,
-10301209472, 10309598848, 10317987712, 10326375296, 10334763392,
-10343153536, 10351541632, 10359930752, 10368318592, 10376707456,
-10385096576, 10393484672, 10401867136, 10410262144, 10418647424,
-10427039104, 10435425664, 10443810176, 10452203648, 10460589952,
-10468982144, 10477369472, 10485759104, 10494147712, 10502533504,
-10510923392, 10519313536, 10527702656, 10536091264, 10544478592,
-10552867712, 10561255808, 10569642368, 10578032768, 10586423168,
-10594805632, 10603200128, 10611588992, 10619976064, 10628361344,
-10636754048, 10645143424, 10653531776, 10661920384, 10670307968,
-10678696832, 10687086464, 10695475072, 10703863168, 10712246144,
-10720639616, 10729026688, 10737414784, 10745806208, 10754190976,
-10762581376, 10770971264, 10779356288, 10787747456, 10796135552,
-10804525184, 10812915584, 10821301888, 10829692288, 10838078336,
-10846469248, 10854858368, 10863247232, 10871631488, 10880023424,
-10888412032, 10896799616, 10905188992, 10913574016, 10921964672,
-10930352768, 10938742912, 10947132544, 10955518592, 10963909504,
-10972298368, 10980687488, 10989074816, 10997462912, 11005851776,
-11014241152, 11022627712, 11031017344, 11039403904, 11047793024,
-11056184704, 11064570752, 11072960896, 11081343872, 11089737856,
-11098128256, 11106514816, 11114904448, 11123293568, 11131680128,
-11140065152, 11148458368, 11156845696, 11165236864, 11173624192,
-11182013824, 11190402688, 11198790784, 11207179136, 11215568768,
-11223957376, 11232345728, 11240734592, 11249122688, 11257511296,
-11265899648, 11274285952, 11282675584, 11291065472, 11299452544,
-11307842432, 11316231296, 11324616832, 11333009024, 11341395584,
-11349782656, 11358172288, 11366560384, 11374950016, 11383339648,
-11391721856, 11400117376, 11408504192, 11416893568, 11425283456,
-11433671552, 11442061184, 11450444672, 11458837888, 11467226752,
-11475611776, 11484003968, 11492392064, 11500780672, 11509169024,
-11517550976, 11525944448, 11534335616, 11542724224, 11551111808,
-11559500672, 11567890304, 11576277376, 11584667008, 11593056128,
-11601443456, 11609830016, 11618221952, 11626607488, 11634995072,
-11643387776, 11651775104, 11660161664, 11668552576, 11676940928,
-11685330304, 11693718656, 11702106496, 11710496128, 11718882688,
-11727273088, 11735660416, 11744050048, 11752437376, 11760824704,
-11769216128, 11777604736, 11785991296, 11794381952, 11802770048,
-11811157888, 11819548544, 11827932544, 11836324736, 11844713344,
-11853100928, 11861486464, 11869879936, 11878268032, 11886656896,
-11895044992, 11903433088, 11911822976, 11920210816, 11928600448,
-11936987264, 11945375872, 11953761152, 11962151296, 11970543488,
-11978928512, 11987320448, 11995708288, 12004095104, 12012486272,
-12020875136, 12029255552, 12037652096, 12046039168, 12054429568,
-12062813824, 12071206528, 12079594624, 12087983744, 12096371072,
-12104759936, 12113147264, 12121534592, 12129924992, 12138314624,
-12146703232, 12155091584, 12163481216, 12171864704, 12180255872,
-12188643968, 12197034112, 12205424512, 12213811328, 12222199424,
-12230590336, 12238977664, 12247365248, 12255755392, 12264143488,
-12272531584, 12280920448, 12289309568, 12297694592, 12306086528,
-12314475392, 12322865024, 12331253632, 12339640448, 12348029312,
-12356418944, 12364805248, 12373196672, 12381580928, 12389969024,
-12398357632, 12406750592, 12415138432, 12423527552, 12431916416,
-12440304512, 12448692352, 12457081216, 12465467776, 12473859968,
-12482245504, 12490636672, 12499025536, 12507411584, 12515801728,
-12524190592, 12532577152, 12540966272, 12549354368, 12557743232,
-12566129536, 12574523264, 12582911872, 12591299456, 12599688064,
-12608074624, 12616463488, 12624845696, 12633239936, 12641631616,
-12650019968, 12658407296, 12666795136, 12675183232, 12683574656,
-12691960192, 12700350592, 12708740224, 12717128576, 12725515904,
-12733906816, 12742295168, 12750680192, 12759071872, 12767460736,
-12775848832, 12784236928, 12792626816, 12801014656, 12809404288,
-12817789312, 12826181504, 12834568832, 12842954624, 12851345792,
-12859732352, 12868122496, 12876512128, 12884901248, 12893289088,
-12901672832, 12910067584, 12918455168, 12926842496, 12935232896,
-12943620736, 12952009856, 12960396928, 12968786816, 12977176192,
-12985563776, 12993951104, 13002341504, 13010730368, 13019115392,
-13027506304, 13035895168, 13044272512, 13052673152, 13061062528,
-13069446272, 13077838976, 13086227072, 13094613632, 13103000192,
-13111393664, 13119782528, 13128157568, 13136559232, 13144945024,
-13153329536, 13161724288, 13170111872, 13178502784, 13186884736,
-13195279744, 13203667072, 13212057472, 13220445824, 13228832128,
-13237221248, 13245610624, 13254000512, 13262388352, 13270777472,
-13279166336, 13287553408, 13295943296, 13304331904, 13312719488,
-13321108096, 13329494656, 13337885824, 13346274944, 13354663808,
-13363051136, 13371439232, 13379825024, 13388210816, 13396605056,
-13404995456, 13413380224, 13421771392, 13430159744, 13438546048,
-13446937216, 13455326848, 13463708288, 13472103808, 13480492672,
-13488875648, 13497269888, 13505657728, 13514045312, 13522435712,
-13530824576, 13539210112, 13547599232, 13555989376, 13564379008,
-13572766336, 13581154432, 13589544832, 13597932928, 13606320512,
-13614710656, 13623097472, 13631477632, 13639874944, 13648264064,
-13656652928, 13665041792, 13673430656, 13681818496, 13690207616,
-13698595712, 13706982272, 13715373184, 13723762048, 13732150144,
-13740536704, 13748926592, 13757316224, 13765700992, 13774090112,
-13782477952, 13790869376, 13799259008, 13807647872, 13816036736,
-13824425344, 13832814208, 13841202304, 13849591424, 13857978752,
-13866368896, 13874754688, 13883145344, 13891533184, 13899919232,
-13908311168, 13916692096, 13925085056, 13933473152, 13941866368,
-13950253696, 13958643584, 13967032192, 13975417216, 13983807616,
-13992197504, 14000582272, 14008973696, 14017363072, 14025752192,
-14034137984, 14042528384, 14050918016, 14059301504, 14067691648,
-14076083584, 14084470144, 14092852352, 14101249664, 14109635968,
-14118024832, 14126407552, 14134804352, 14143188608, 14151577984,
-14159968384, 14168357248, 14176741504, 14185127296, 14193521024,
-14201911424, 14210301824, 14218685056, 14227067264, 14235467392,
-14243855488, 14252243072, 14260630144, 14269021568, 14277409408,
-14285799296, 14294187904, 14302571392, 14310961792, 14319353728,
-14327738752, 14336130944, 14344518784, 14352906368, 14361296512,
-14369685376, 14378071424, 14386462592, 14394848128, 14403230848,
-14411627392, 14420013952, 14428402304, 14436793472, 14445181568,
-14453569664, 14461959808, 14470347904, 14478737024, 14487122816,
-14495511424, 14503901824, 14512291712, 14520677504, 14529064832,
-14537456768, 14545845632, 14554234496, 14562618496, 14571011456,
-14579398784, 14587789184, 14596172672, 14604564608, 14612953984,
-14621341312, 14629724288, 14638120832, 14646503296, 14654897536,
-14663284864, 14671675264, 14680061056, 14688447616, 14696835968,
-14705228416, 14713616768, 14722003328, 14730392192, 14738784128,
-14747172736, 14755561088, 14763947648, 14772336512, 14780725376,
-14789110144, 14797499776, 14805892736, 14814276992, 14822670208,
-14831056256, 14839444352, 14847836032, 14856222848, 14864612992,
-14872997504, 14881388672, 14889775744, 14898165376, 14906553472,
-14914944896, 14923329664, 14931721856, 14940109696, 14948497024,
-14956887424, 14965276544, 14973663616, 14982053248, 14990439808,
-14998830976, 15007216768, 15015605888, 15023995264, 15032385152,
-15040768384, 15049154944, 15057549184, 15065939072, 15074328448,
-15082715008, 15091104128, 15099493504, 15107879296, 15116269184,
-15124659584, 15133042304, 15141431936, 15149824384, 15158214272,
-15166602368, 15174991232, 15183378304, 15191760512, 15200154496,
-15208542592, 15216931712, 15225323392, 15233708416, 15242098048,
-15250489216, 15258875264, 15267265408, 15275654528, 15284043136,
-15292431488, 15300819584, 15309208192, 15317596544, 15325986176,
-15334374784, 15342763648, 15351151744, 15359540608, 15367929728,
-15376318336, 15384706432, 15393092992, 15401481856, 15409869952,
-15418258816, 15426649984, 15435037568, 15443425664, 15451815296,
-15460203392, 15468589184, 15476979328, 15485369216, 15493755776,
-15502146944, 15510534272, 15518924416, 15527311232, 15535699072,
-15544089472, 15552478336, 15560866688, 15569254528, 15577642624,
-15586031488, 15594419072, 15602809472, 15611199104, 15619586432,
-15627975296, 15636364928, 15644753792, 15653141888, 15661529216,
-15669918848, 15678305152, 15686696576, 15695083136, 15703474048,
-15711861632, 15720251264, 15728636288, 15737027456, 15745417088,
-15753804928, 15762194048, 15770582656, 15778971008, 15787358336,
-15795747712, 15804132224, 15812523392, 15820909696, 15829300096,
-15837691264, 15846071936, 15854466944, 15862855808, 15871244672,
-15879634816, 15888020608, 15896409728, 15904799104, 15913185152,
-15921577088, 15929966464, 15938354816, 15946743424, 15955129472,
-15963519872, 15971907968, 15980296064, 15988684928, 15997073024,
-16005460864, 16013851264, 16022241152, 16030629248, 16039012736,
-16047406976, 16055794816, 16064181376, 16072571264, 16080957824,
-16089346688, 16097737856, 16106125184, 16114514816, 16122904192,
-16131292544, 16139678848, 16148066944, 16156453504, 16164839552,
-16173236096, 16181623424, 16190012032, 16198401152, 16206790528,
-16215177344, 16223567744, 16231956352, 16240344704, 16248731008,
-16257117824, 16265504384, 16273898624, 16282281856, 16290668672,
-16299064192, 16307449216, 16315842176, 16324230016, 16332613504,
-16341006464, 16349394304, 16357783168, 16366172288, 16374561664,
-16382951296, 16391337856, 16399726208, 16408116352, 16416505472,
-16424892032, 16433282176, 16441668224, 16450058624, 16458448768,
-16466836864, 16475224448, 16483613056, 16492001408, 16500391808,
-16508779648, 16517166976, 16525555328, 16533944192, 16542330752,
-16550719616, 16559110528, 16567497088, 16575888512, 16584274816,
-16592665472, 16601051008, 16609442944, 16617832064, 16626218624,
-16634607488, 16642996096, 16651385728, 16659773824, 16668163712,
-16676552576, 16684938112, 16693328768, 16701718144, 16710095488,
-16718492288, 16726883968, 16735272832, 16743661184, 16752049792,
-16760436608, 16768827008, 16777214336, 16785599104, 16793992832,
-16802381696, 16810768768, 16819151744, 16827542656, 16835934848,
-16844323712, 16852711552, 16861101952, 16869489536, 16877876864,
-16886265728, 16894653056, 16903044736, 16911431296, 16919821696,
-16928207488, 16936592768, 16944987776, 16953375616, 16961763968,
-16970152832, 16978540928, 16986929536, 16995319168, 17003704448,
-17012096896, 17020481152, 17028870784, 17037262208, 17045649536,
-17054039936, 17062426496, 17070814336, 17079205504, 17087592064,
-17095978112, 17104369024, 17112759424, 17121147776, 17129536384,
-17137926016, 17146314368, 17154700928, 17163089792, 17171480192,
-17179864192, 17188256896, 17196644992, 17205033856, 17213423488,
-17221811072, 17230198912, 17238588032, 17246976896, 17255360384,
-17263754624, 17272143232, 17280530048, 17288918912, 17297309312,
-17305696384, 17314085504, 17322475136, 17330863744, 17339252096,
-17347640192, 17356026496, 17364413824, 17372796544, 17381190016,
-17389583488, 17397972608, 17406360704, 17414748544, 17423135872,
-17431527296, 17439915904, 17448303232, 17456691584, 17465081728,
-17473468288, 17481857408, 17490247552, 17498635904, 17507022464,
-17515409024, 17523801728, 17532189824, 17540577664, 17548966016,
-17557353344, 17565741184, 17574131584, 17582519168, 17590907008,
-17599296128, 17607687808, 17616076672, 17624455808, 17632852352,
-17641238656, 17649630848, 17658018944, 17666403968, 17674794112,
-17683178368, 17691573376, 17699962496, 17708350592, 17716739968,
-17725126528, 17733517184, 17741898112, 17750293888, 17758673024,
-17767070336, 17775458432, 17783848832, 17792236928, 17800625536,
-17809012352, 17817402752, 17825785984, 17834178944, 17842563968,
-17850955648, 17859344512, 17867732864, 17876119424, 17884511872,
-17892900224, 17901287296, 17909677696, 17918058112, 17926451072,
-17934843776, 17943230848, 17951609216, 17960008576, 17968397696,
-17976784256, 17985175424, 17993564032, 18001952128, 18010339712,
-18018728576, 18027116672, 18035503232, 18043894144, 18052283264,
-18060672128, 18069056384, 18077449856, 18085837184, 18094225792,
-18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
-18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
-18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
-18228444544, 18236833408, 18245220736]
-
-cache_sizes = [
-16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
-17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088,
-18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208,
-19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968,
-20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216,
-21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104,
-22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096,
-23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112,
-24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488,
-25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096,
-25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472,
-26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744,
-27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504,
-28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752,
-29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976,
-30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248,
-31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392,
-32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768,
-33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992,
-34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984,
-35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976,
-36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656,
-36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904,
-37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672,
-38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632,
-39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032,
-40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304,
-41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912,
-42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696,
-43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432,
-44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448,
-45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208,
-46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328,
-47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936,
-47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312,
-48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712,
-49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472,
-50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848,
-51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968,
-52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576,
-53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744,
-54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248,
-55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856,
-56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488,
-57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632,
-58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984,
-58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512,
-59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968,
-60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752,
-61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512,
-62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656,
-63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392,
-64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792,
-65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296,
-66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672,
-67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304,
-68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912,
-69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184,
-69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816,
-70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168,
-71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568,
-72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944,
-73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832,
-74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544,
-75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072,
-76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832,
-77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336,
-78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664,
-79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472,
-80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848,
-81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304,
-81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984,
-82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464,
-83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608,
-84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496,
-85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112,
-86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632,
-87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264,
-88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384,
-89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376,
-90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776,
-91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384,
-92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912,
-92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136,
-93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896,
-94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016,
-95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544,
-96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536,
-97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168,
-98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928,
-99352384, 99482816, 99614272, 99745472, 99876416, 100007104,
-100138048, 100267072, 100401088, 100529984, 100662592, 100791872,
-100925248, 101056064, 101187392, 101317952, 101449408, 101580608,
-101711296, 101841728, 101973824, 102104896, 102235712, 102366016,
-102498112, 102628672, 102760384, 102890432, 103021888, 103153472,
-103284032, 103415744, 103545152, 103677248, 103808576, 103939648,
-104070976, 104201792, 104332736, 104462528, 104594752, 104725952,
-104854592, 104988608, 105118912, 105247808, 105381184, 105511232,
-105643072, 105774784, 105903296, 106037056, 106167872, 106298944,
-106429504, 106561472, 106691392, 106822592, 106954304, 107085376,
-107216576, 107346368, 107478464, 107609792, 107739712, 107872192,
-108003136, 108131392, 108265408, 108396224, 108527168, 108657344,
-108789568, 108920384, 109049792, 109182272, 109312576, 109444928,
-109572928, 109706944, 109837888, 109969088, 110099648, 110230976,
-110362432, 110492992, 110624704, 110755264, 110886208, 111017408,
-111148864, 111279296, 111410752, 111541952, 111673024, 111803456,
-111933632, 112066496, 112196416, 112328512, 112457792, 112590784,
-112715968, 112852672, 112983616, 113114944, 113244224, 113376448,
-113505472, 113639104, 113770304, 113901376, 114031552, 114163264,
-114294592, 114425536, 114556864, 114687424, 114818624, 114948544,
-115080512, 115212224, 115343296, 115473472, 115605184, 115736128,
-115867072, 115997248, 116128576, 116260288, 116391488, 116522944,
-116652992, 116784704, 116915648, 117046208, 117178304, 117308608,
-117440192, 117569728, 117701824, 117833024, 117964096, 118094656,
-118225984, 118357312, 118489024, 118617536, 118749632, 118882112,
-119012416, 119144384, 119275328, 119406016, 119537344, 119668672,
-119798464, 119928896, 120061376, 120192832, 120321728, 120454336,
-120584512, 120716608, 120848192, 120979136, 121109056, 121241408,
-121372352, 121502912, 121634752, 121764416, 121895744, 122027072,
-122157632, 122289088, 122421184, 122550592, 122682944, 122813888,
-122945344, 123075776, 123207488, 123338048, 123468736, 123600704,
-123731264, 123861952, 123993664, 124124608, 124256192, 124386368,
-124518208, 124649024, 124778048, 124911296, 125041088, 125173696,
-125303744, 125432896, 125566912, 125696576, 125829056, 125958592,
-126090304, 126221248, 126352832, 126483776, 126615232, 126746432,
-126876608, 127008704, 127139392, 127270336, 127401152, 127532224,
-127663552, 127794752, 127925696, 128055232, 128188096, 128319424,
-128449856, 128581312, 128712256, 128843584, 128973632, 129103808,
-129236288, 129365696, 129498944, 129629888, 129760832, 129892288,
-130023104, 130154048, 130283968, 130416448, 130547008, 130678336,
-130807616, 130939456, 131071552, 131202112, 131331776, 131464384,
-131594048, 131727296, 131858368, 131987392, 132120256, 132250816,
-132382528, 132513728, 132644672, 132774976, 132905792, 133038016,
-133168832, 133299392, 133429312, 133562048, 133692992, 133823296,
-133954624, 134086336, 134217152, 134348608, 134479808, 134607296,
-134741056, 134872384, 135002944, 135134144, 135265472, 135396544,
-135527872, 135659072, 135787712, 135921472, 136052416, 136182848,
-136313792, 136444864, 136576448, 136707904, 136837952, 136970048,
-137099584, 137232064, 137363392, 137494208, 137625536, 137755712,
-137887424, 138018368, 138149824, 138280256, 138411584, 138539584,
-138672832, 138804928, 138936128, 139066688, 139196864, 139328704,
-139460032, 139590208, 139721024, 139852864, 139984576, 140115776,
-140245696, 140376512, 140508352, 140640064, 140769856, 140902336,
-141032768, 141162688, 141294016, 141426496, 141556544, 141687488,
-141819584, 141949888, 142080448, 142212544, 142342336, 142474432,
-142606144, 142736192, 142868288, 142997824, 143129408, 143258944,
-143392448, 143523136, 143653696, 143785024, 143916992, 144045632,
-144177856, 144309184, 144440768, 144570688, 144701888, 144832448,
-144965056, 145096384, 145227584, 145358656, 145489856, 145620928,
-145751488, 145883072, 146011456, 146144704, 146275264, 146407232,
-146538176, 146668736, 146800448, 146931392, 147062336, 147193664,
-147324224, 147455936, 147586624, 147717056, 147848768, 147979456,
-148110784, 148242368, 148373312, 148503232, 148635584, 148766144,
-148897088, 149028416, 149159488, 149290688, 149420224, 149551552,
-149683136, 149814976, 149943616, 150076352, 150208064, 150338624,
-150470464, 150600256, 150732224, 150862784, 150993088, 151125952,
-151254976, 151388096, 151519168, 151649728, 151778752, 151911104,
-152042944, 152174144, 152304704, 152435648, 152567488, 152698816,
-152828992, 152960576, 153091648, 153222976, 153353792, 153484096,
-153616192, 153747008, 153878336, 154008256, 154139968, 154270912,
-154402624, 154533824, 154663616, 154795712, 154926272, 155057984,
-155188928, 155319872, 155450816, 155580608, 155712064, 155843392,
-155971136, 156106688, 156237376, 156367424, 156499264, 156630976,
-156761536, 156892352, 157024064, 157155008, 157284416, 157415872,
-157545536, 157677248, 157810496, 157938112, 158071744, 158203328,
-158334656, 158464832, 158596288, 158727616, 158858048, 158988992,
-159121216, 159252416, 159381568, 159513152, 159645632, 159776192,
-159906496, 160038464, 160169536, 160300352, 160430656, 160563008,
-160693952, 160822208, 160956352, 161086784, 161217344, 161349184,
-161480512, 161611456, 161742272, 161873216, 162002752, 162135872,
-162266432, 162397888, 162529216, 162660032, 162790976, 162922048,
-163052096, 163184576, 163314752, 163446592, 163577408, 163707968,
-163839296, 163969984, 164100928, 164233024, 164364224, 164494912,
-164625856, 164756672, 164887616, 165019072, 165150016, 165280064,
-165412672, 165543104, 165674944, 165805888, 165936832, 166067648,
-166198336, 166330048, 166461248, 166591552, 166722496, 166854208,
-166985408, 167116736, 167246656, 167378368, 167508416, 167641024,
-167771584, 167903168, 168034112, 168164032, 168295744, 168427456,
-168557632, 168688448, 168819136, 168951616, 169082176, 169213504,
-169344832, 169475648, 169605952, 169738048, 169866304, 169999552,
-170131264, 170262464, 170393536, 170524352, 170655424, 170782016,
-170917696, 171048896, 171179072, 171310784, 171439936, 171573184,
-171702976, 171835072, 171966272, 172097216, 172228288, 172359232,
-172489664, 172621376, 172747712, 172883264, 173014208, 173144512,
-173275072, 173407424, 173539136, 173669696, 173800768, 173931712,
-174063424, 174193472, 174325696, 174455744, 174586816, 174718912,
-174849728, 174977728, 175109696, 175242688, 175374272, 175504832,
-175636288, 175765696, 175898432, 176028992, 176159936, 176291264,
-176422592, 176552512, 176684864, 176815424, 176946496, 177076544,
-177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
-177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
-178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
-179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
-180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
-181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
-181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
-182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
-183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
-184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
-185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
-185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
-186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
-187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
-188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
-189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
-189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
-190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
-191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
-192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
-192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
-193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
-194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
-195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
-196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
-196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
-197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
-198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
-199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
-200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
-200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
-201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
-202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
-203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
-203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
-204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
-205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
-206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
-207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
-207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
-208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
-209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
-210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
-211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
-211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
-212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
-213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
-214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
-214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
-215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
-216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
-217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
-218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
-218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
-219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
-220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
-221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
-222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
-222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
-223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
-224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
-225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
-225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
-226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
-227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
-228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
-229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
-229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
-230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
-231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
-232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
-233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
-233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
-234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
-235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
-236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
-236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
-237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
-238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
-239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
-240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
-240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
-241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
-242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
-243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
-244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
-244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
-245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
-246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
-247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
-247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
-248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
-249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
-250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
-251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
-251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
-252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
-253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
-254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
-255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
-255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
-256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
-257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
-258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
-258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
-259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
-260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
-261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
-262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
-262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
-263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
-264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
-265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
-266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
-266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
-267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
-268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
-269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
-270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
-270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
-271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
-272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
-273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
-273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
-274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
-275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
-276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
-277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
-277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
-278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
-279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
-280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
-281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
-281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
-282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
-283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
-284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
-284950208, 285081536]
-```
diff --git "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" "b/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
deleted file mode 100644
index 0d659e167c5..00000000000
--- "a/public/content/translations/fa/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md"
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: الگوریتم های استخراج
-description: نگاه دقیق تر به الگوریتمهای استفاده شده برای استخراج اتریوم.
-lang: fa
----
-
-
-اثبات-کار دیگر مکانیزم اجماع اتریوم نیست، و در نتیجه استخراج اتریوم متوفف شده است. در عوض، اتریوم توسط اعتبارسنجهایی که اتریوم را سهام گذاری میکنند، ایمن میشود. شما میتوانید از امروز شروع به سهامگذاری اتر خود کنید. درباره ادغام، اثبات سهام و سهامگذاری بیشتر بخوانید. این صفحه تنها برای علاقمندان به تاریخچه پروژه است.
-
-
-استخراج اتریوم با استفاده از الگوریتمی به نام Ethash انجام میشد. ایده بنیادی این الگوریتم این است که ماینر تلاش میکند با محاسبات جستجوی فراگیر (brute force)، عدد منحصربفرد (nonce) ورودی را پیدا کند که نتیجه استفاده از آن، تولید هش کوچکتر از حد آستانه تعیین شده توسط سختی محاسبه شده است. سطح سختی به طور دینامیک قابل تنظیم است تا بدین وسیله ساخت بلوک در بازههای زمانی منظم اتفاق بیفتد.
-
-## موارد مورد نیاز {#prerequisites}
-
-برای درک بهتر این قسمت پیشنهاد میکنیم ابتدا مقالات [الگوریتم اجماع اثبات کار](/developers/docs/consensus-mechanisms/pow) و [استخراج](/developers/docs/consensus-mechanisms/pow/mining) را مطالعه کنید.
-
-## الگوریتم دگر هشیموتو (Dagger Hashimoto) {#dagger-hashimoto}
-
-Dagger Hashimoto یک الگوریتم تحقیقاتی پیشرو برای استخراج اتریوم بود که الگوریتم Ethhash جایگزین آن شد. این الگوریتم از ادغام دو الگوریتم Dagger و Hashimoto ایجاد شده بود. این الگوریتم تنها یک پیادهسازی تحقیقاتی بود و در زمان راهاندازی شبکه اصلی اتریوم توسط Ethash جایگزین شد.
-
-[Dagger](http://www.hashcash.org/papers/dagger.html) شامل تولید یک [گراف جهتدار غیرمدور](https://en.wikipedia.org/wiki/Directed_acyclic_graph) است که برش های تصادفی آن باهم هش شدهاند. مولفه اصلی این است که هر نانس فقط به بخش کوچکی از درخت داده کل بزرگ نیاز دارد. محاسبه مجدد زیردرخت برای هر نانس در استخراج ممنوع است - و بنابراین نیاز به ذخیره درخت - اما برای تایید ارزش یک نانس مشکلی وجود ندارد. Dagger طراحی شده بود تا یک جایگزین برای الگوریتمهای موجود مثل Scrypt باشد، الگوریتمهایی که حافظه سختی دارند اما زمانی که سختی حافظه آنها به سطوح ایمن اصل افزایش مییابد، تأیید آن دشوار است. با این حال، Dagger در برابر شتاب سختافزار حافظه مشترک آسیبپذیر بود و به نفع سایر روشهای تحقیق کنار گذاشته شد.
-
-[هشیموتو](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) الگوریتمی است که با محدود بودن به I/O، ویژگی مقاوم بودن در برابر ASIC را به الگوریتم اضافه میکند (یعنی خواندن حافظه، عامل محدود کننده در فرآیند استخراج است). تئوری این است که RAM بیشتر از محاسبات در دسترس است؛ میلیاردها دلار تحقیق در حال حاضر بهینهسازی RAM را برای موارد استفاده مختلف بررسی کردهاند، که اغلب شامل الگوهای دسترسی تقریبا تصادفی است (از این رو به آن حافظه دسترسی تصادفی گفته میشود). در نتیجه، RAM موجود احتمالاً برای ارزیابی الگوریتم نسبتاً نزدیک به حالت بهینه است. هاشیموتو بلاک چین را به عنوان منبع داده استفاده کرده و همزمان مورد 1 و 3 در بالا را برآورده میکند.
-
-Dagger-Hashimoto از نسخههای اصلاح یافته الگوریتمهای Dagger و Hashimoto استفاده کرد. تفاوت بین Dagger Hashimoto و Hashimoto این است که به جای استفاده از بلاک چین به عنوان منبع داده Dagger Hashimoto از یک مجموعه داده سفارشی تولید شده استفاده میکند که این مچموعه داده بر اساس دادههای موجود در بلوکها در هر N بلوک به روز میشود. این مجموعه دادهها با استفاده از الگوریتم Dagger تولید میشود، که امکان محاسبه مؤثر زیرمجموعهای خاص برای هر نانس را برای الگوریتم تأیید کاربر سبک فراهم میکند. تفاوت بین Dagger Hashimoto و Dagger این است که برخلاف Dagger اصلی، مجموعه داده استفاده شده برای استعلام از بلوک نیمه دائمی است و فقط در فواصل زمانی گاه به گاه (به عنوان مثال یک بار در هفته) به روز میشود. این بدان معناست که بخشی از تلاش برای تولید مجموعه داده نزدیک به صفر است، بنابراین استدلالهای سرجیو لرنر در مورد افزایش سرعت حافظه مشترک قابل چشمپوشی میشود.
-
-اطلاعات بیشتر درباره [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto).
-
-## یک الگوریتم اثبات انجام کار برای اتریوم ۱. ۰ {#ethash}
-
-Ethash در واقع همان الگوریتم استخراج بود که در الگوریتم اثبات کار استخراج شبکه اصلی اتریوم که اکنون منسوخ شده، استفاده شده بود. Ethash در واقع نام جدیدی بود که به نسخه خاصی از الگوریتم Dagger-Hashimoto و پس از به روز رسانی قابل توجه آن داده شد، در حالی که هنوز اصول اساسی نسخه قبلی خود را به ارث میبرد. شبکه اصلی اتریوم تاکنون تنها از Ethash استفاده کرده است - Dagger Hashimoto یک نسخه در حال &توسعه از الگوریتم استخراج بود که قبل از شروع استخراج در شبکه اصلی اتریوم، جایگزین شد.
-
-[مطالب بیشتر درباره Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
-
-## بیشتر بخوانید {#further-reading}
-
-_در مورد جامعه منابعی که به شما کمک می کنند بدانید? این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
deleted file mode 100644
index b280a885915..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md"
+++ /dev/null
@@ -1,207 +0,0 @@
----
-title: کتابخانههای وب سرویس بک اند
-description: معرفی وب سرویس کاربرهای اتریوم که به شما اجازه میدهند از برنامه های کاربردی خود با زنجیره بلوکی تعامل داشته باشید.
-lang: fa
----
-
-برای اینکه برنامه با زنجیره بلوکی اتریوم کار کند (مثال: زنجیره بلوکی را بخواند و به شبکه تراکنش بفرستد)، باید به یک گره اتریوم متصل شود.
-
-برای این منظور، هر کاربر اتریوم مشخصات [JSON-RPC](/developers/docs/apis/json-rpc/) را پیادهسازی میکند، بنابراین مجموعه یکنواختی از [روشها](/developers/docs/apis/json-rpc/#json-rpc-methods) وجود دارد که برنامهها میتوانند به آن تکیه کنند.
-
-اگر میخواهید از یک زبان برنامه نویسی خاص برای اتصال به گره اتریوم استفاده کنید، راهحل خود را انجام دهید اما کتابخانه ها و محیط های متعددی وجود دارند که میتوانند آن را برای شما بسیار ساده کنند. با استفاده از این کتابخانه ها توسعهدهندگان میتوانند بدون دانستن برنامه نویسی پپشرفته و با استفاده از کد یک خطی درخواست های JSON-RPC بدهند که با اتریوم تعامل داشته باشد.
-
-## پیشنیازها {#prerequisites}
-
-[پشته اتریوم](/developers/docs/ethereum-stack/) و [کاربر اتریوم](/developers/docs/nodes-and-clients/) میتوانند مطالب مفیدی باشند.
-
-## چرا از کتابخانه استفاده کنیم؟ {#why-use-a-library}
-
-این کتابخانه ها بسیاری از سختی های ازتباط مستقیم با گره اتریوم را از بین میبرند. همچنین توابع کاربردی فراهم میکنند (مثلا تبدیل اتر به GWEI) بنابراین به عنوان یک توسعه دهنده شما زمان کمتری صرف کارکردن با پیچیدگی های کاربر اتریوم، و زمان بیشتری صرف عملکرد برنامه خود میکنید.
-
-## کتابخانههای در دسترس {#available-libraries}
-
-### زیرساحت و خدمات گره {#infrastructure-and-node-services}
-
-**Alchemy** **_پلتفرم توسعه اتریوم_**
-
-- [alchemy.com](https://www.alchemy.com/)
-- [اسناد](https://docs.alchemy.com/)
-- [گیتهاب](https://github.com/alchemyplatform)
-- [دیسکورد](https://discord.com/invite/alchemyplatform)
-
-**All That Node -** **_Node-as-a-Service._**
-
-- [AllThatNode.com](https://www.allthatnode.com/)
-- [اسناد](https://docs.allthatnode.com)
-- [دیسکورد](https://discord.gg/GmcdVEUbJM)
-
-**Blast by Bware Labs -** **_ سرویس APIهای غیرمتمرکز برای شبکه اصلی اتریوم و شبکه های آزمایشی._**
-
-- [blastapi.io](https://blastapi.io/)
-- [اسناد](https://docs.blastapi.io)
-- [دیسکورد](https://discord.gg/bwarelabs)
-
-**BlockPi -** **_ ارائه خدمات RPC کارآمدتر و سریعتر_**
-
-- [blockpi.io](https://blockpi.io/)
-- [مستندات](https://docs.blockpi.io/)
-- [گیت هاب](https://github.com/BlockPILabs)
-- [دیسکورد](https://discord.com/invite/xTvGVrGVZv)
-
-**دروازه اتریوم Cloudflare.**
-
-- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
-
-**اتراسکن - کاوشگر بلوک و APIهای تراکنش**
-- [اسناد](https://docs.etherscan.io/)
-
-**GetBlock-** **_بلاکچین به عنوان سرویس برای توسعه Web3 _ **
-
-- [GetBlock.io](https://getblock.io/)
-- [مستندات](https://getblock.io/docs/)
-
-**Infura -** **_وب سرویس اتریوم به عنوان سرویس._**
-
-- [infura.io](https://infura.io)
-- [اسناد](https://docs.infura.io/api)
-- [گیتهاب](https://github.com/INFURA)
-
-**Node RPC - _ارائه دهنده مقرون به صرفه ماشین مجازی اتریوم JSON-RPC_**
-
-- [noderpc.xyz](https://www.noderpc.xyz/)
-- [مستندات](https://docs.noderpc.xyz/node-rpc)
-
-**NOWNodes - _گرههای کامل و کاوشگرهای بلوک._**
-
-- [NOWNodes.io](https://nownodes.io/)
-- [اسناد](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro)
-
-**QuickNode -** **_زیرساخت بلاکچین به عنوان سرویس._**
-
-- [quicknode.com](https://quicknode.com)
-- [مستندات](https://www.quicknode.com/docs/welcome)
-- [دیسکورد](https://discord.gg/quicknode)
-
-**Rivet****_ وب سرویسهای اتریوم و اتریوم کلاسیک به عنوان یک خدمت قدرت گرفته از نرمافزار متن باز._**
-
-- [rivet.cloud](https://rivet.cloud)
-- [Documentation](https://rivet.cloud/docs/)
-- [گیتهاب](https://github.com/openrelayxyz/ethercattle-deployment)
-
-**Zmok -** **_گره های اتریوم سرعت گرا به عنوان رابط برنامهنویسی کاربردی JSON-RPC/WebSockets _**
-
-- [zmok.io](https://zmok.io/)
-- [گیتهاب](https://github.com/zmok-io)
-- [مستندات](https://docs.zmok.io/)
-- [دیسکورد](https://discord.gg/fAHeh3ka6s)
-
-### ابزارهای توسعه {#development-tools}
-
-**ethers-kt -** **_Async، کتابخانه کاتلین/جاوا/اندروید با عملکرد بالا برای بلاک چینهای مبتنی بر ماشین مجازی اتریوم_**
-
-- [گیتهاب](https://github.com/Kr1ptal/ethers-kt)
-- [مثالها](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
-- [دیسکورد](https://discord.gg/rx35NzQGSb)
-
-**نتریوم****یک کتابخانه متن باز متحد با زنجیره بلوکی**
-
-- [گیتهاب](https://github.com/Nethereum/Nethereum)
-- [مستندات](http://docs.nethereum.com/en/latest/)
-- [دیسکورد](https://discord.com/invite/jQPrR58FxX)
-
-**ابزارسازی پایتون****_کتابخانه های متعدد برای تعامل با اتریوم به وسیله پایتون._**
-
-- [py.ethereum.org](https://python.ethereum.org/)
-- [گیتهاب web3.py](https://github.com/ethereum/web3.py)
-- [چت web3.py](https://gitter.im/ethereum/web3.py)
-
-**Tatum -** **_پلتفرم نهایی توسعه زنجیره بلوکی._**
-
-- [Tatum](https://tatum.io/)
-- [گیت هاب](https://github.com/tatumio/)
-- [مستندات](https://docs.tatum.io/)
-- [دیسکورد](https://discord.gg/EDmW3kjTC9)
-
-**web3j****_یک کتابخانه متحد جاوا/اندروید/کاتلین/اسکالا برای اتریوم_**
-
-- [گیتهاب](https://github.com/web3j/web3j)
-- [مستندات](https://docs.web3j.io/)
-- [گیتر](https://gitter.im/web3j/web3j)
-
-### خدمات بلاک چین {#blockchain-services}
-
-**BlockCypher -** **_APIهای وب اتریوم._**
-
-- [blockcypher.com](https://www.blockcypher.com/)
-- [اسناد](https://www.blockcypher.com/dev/ethereum/)
-
-** -Chainbase** **_زیرساخت داده Web3 همه در یک مورد برای اتریوم.
-
-- [chainbase.com](https://chainbase.com/)
-- [اسناد](https://docs.chainbase.com/)
-- [دیسکورد](https://discord.gg/Wx6qpqz4AF)
-
-**چِین استک****_گره مشترک و اختصاصی اتریوم به عنوان یک سرویس._**
-
-- [chainstack.com](https://chainstack.com)
-- [مستندات](https://docs.chainbase.com/docs)
-- [مرجع API اتریوم](https://docs.chainstack.com/reference/ethereum-getting-started)
-
-**Coinbase Cloud Node -** **_زیرساخت ایپیآی بلاکچین._**
-
-- [گره ابری کوین بیس](https://www.coinbase.com/cloud)
-- [مستندات](https://docs.cloud.coinbase.com/)
-
-**DataHub توسط Figment -** **_سرویسهای مبتنی بر وب سرویس Web3 با شبکه اصلی و شبکههای تستی اتریوم._**
-
-- [DataHub](https://www.figment.io/)
-- [اسناد](https://docs.figment.io/)
-
-**مورالیس-** **_ارائهدهنده API EVM گرید سازمانی._**
-
-- [moralis.io](https://moralis.io)
-- [اسناد](https://docs.moralis.io/)
-- [گیت هاب](https://github.com/MoralisWeb3)
-- [دیسکورد](https://moralis.io/joindiscord/)
-- [تالار گفتگو](https://forum.moralis.io/)
-
-**NFTPport -** **_API دادههای اتریوم و ضرب._**
-
-- [nftport.xyz](https://www.nftport.xyz/)
-- [اسناد](https://docs.nftport.xyz/)
-- [گیت هاب](https://github.com/nftport/)
-- [دیسکورد](https://discord.com/invite/K8nNrEgqhE)
-
-**توکن ویو-** **_پلتفرم عمومی APIهای رمزنگاری چندگانه بلاک چین._
-
-- [services.tokenview.io](https://services.tokenview.io/)
-- [اسناد](https://services.tokenview.io/docs?type=api)
-- [گیت هاب](https://github.com/Tokenview)
-
-**Watchdata -** **_دسترسی آسان و قابل اتکای وبسرویس به زنجیره بلوکی اتریوم._**
-
-- [Watchdata](https://watchdata.io/)
-- [اسناد](https://docs.watchdata.io/)
-- [دیسکورد](https://discord.com/invite/TZRJbZ6bdn)
-
-**Covalent-** **_APIهای بلاک چین غنی شده برای بیش از 200 زنجیره._**
-
-- [covalenthq.com](https://www.covalenthq.com/)
-- [اسناد](https://www.covalenthq.com/docs/api/)
-- [گیت هاب](https://github.com/covalenthq)
-- [دیسکورد](https://www.covalenthq.com/discord/)
-
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
-- [چارچوبهای توسعه](/developers/docs/frameworks/)
-
-## آموزش های مرتبط {#related-tutorials}
-
-- [Web3js را برای استفاده از بلاک چین اتریوم در جاوا اسکریپت راه اندازی کنید](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) *– دستورالعمل هایی برای راه اندازی web3.js در پروژه شما.*
-- [فراخوانی قرارداد هوشمند در جاوا اسکریپت](/developers/tutorials/calling-a-smart-contract-from-javascript/)_- با استفاده از توکن Dai، ببینید چگونه میشود با استفاده از توابع قراردادها را فراخوانی کرد._
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
deleted file mode 100644
index 47c47b754e2..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md"
+++ /dev/null
@@ -1,235 +0,0 @@
----
-title: کتابخانه های API جاوا اسکریپت
-description: مقدمه ای بر کتابخانه های کاربرهای جاوا اسکریپت که به شما اجازه تعامل با زنجیره بلوکی را از سوی نرمافزارتان میدهد.
-lang: fa
----
-
-جهت تعامل یک نرم افزار اینترنتی با زنجیره بلوکی اتریوم (مثلا خواندن داده زنجیره بلوکی و یا فرستادن تراکنش به شبکه)، باید به یک گره اتریوم متصل شد.
-
-برای این منظور، هر مشتری اتریوم مشخصات [JSON-RPC](/developers/docs/apis/json-rpc/) را پیادهسازی میکند، بنابراین مجموعهای یکسان از [روشها](/developers/docs/apis/json-rpc/#json-rpc-methods) وجود دارد که برنامهها میتوانند به آنها تکیه کنند.
-
-اگر میخواهید برای اتصال به یک گره اتریوم از جاوا اسکریپت استفاده کنید، این امکان وجود دارد که از جاوا اسکریپت خالص استفاده کنید اما چندین کتابخانه مناسب درون اکوسیستم وجود دارند که این کار را بسیار سادهتر میسازند. با استفاده از این کتابخانه ها توسعهدهندگان میتوانند بدون دانستن برنامه نویسی پپشرفته و با استفاده از کد یک خطی درخواست های JSON-RPC بدهند که با اتریوم تعامل داشته باشد.
-
-لطفاً توجه داشته باشید که از زمان [ادغام](/roadmap/merge/)، دو قطعه متصل نرم افزار اتریوم - یک کاربر اجرا و یک کاربر توافقی - برای اجرای یک گره مورد نیاز است. لطفاً مطمئن شوید که گره شما شامل یک کاربر اجرایی و توافقی است. اگر گره شما در دستگاه محلی شما نیست (به عنوان مثال، گره شما در یک نمونه AWS در حال اجرا است) آدرس های IP را در آموزش به روز رسانی کنید. برای اطلاعات بیشتر لطفاً به صفحه ما در [اجرای یک گره](/developers/docs/nodes-and-clients/run-a-node/) مراجعه کنید.
-
-## پیشنیازها {#prerequisites}
-
-علاوه بر درک جاوا اسکریپت، فهمیدن [پشته اتریوم](/developers/docs/ethereum-stack/) و [کاربرهای اتریوم](/developers/docs/nodes-and-clients/) نیز احتمالا کمک کننده باشد.
-
-## چرا از کتابخانه ها استفاده کنیم؟ {#why-use-a-library}
-
-این کتابخانه ها بسیاری از سختی های ازتباط مستقیم با گره اتریوم را از بین میبرند. همچنین توابع کاربردی فراهم میکنند (مثال: تبدیل اتر به GWEI) بنابراین به عنوان یک توسعه دهنده شما زمان کمتری صرف کارکردن با پیچیدگی های کاربر اتریوم، و زمان بیشتری صرف عملکرد برنامه خود میکنید.
-
-## ویژگی های کتابخانه {#library-features}
-
-### اتصال به گره های اتریوم {#connect-to-ethereum-nodes}
-
-با استفاده از ارائه کنندگان، این کتابخانه ها به شما اجازه اتصال به اتریوم و خواندن داده های آن را میدهند، چه روی JASON-RPC، INFURA، Etherscan، Alchemy یا MetaMask.
-
-**مثال های اتر**
-
-```js
-// یک BrowserProvider یک ارائه دهنده استاندارد Web3 را میپوشاند که این است
-// آنچه MetaMask به عنوان window.ethereum به هر صفحه وارد میکند
-ارائه دهنده const = new ethers.BrowserProvider(window.ethereum)
-
-// پلاگین MetaMask همچنین امکان امضای تراکنشها را فراهم میکند
-// برای تغییر حالت در بلاک چین اتر ارسال و پرداخت کنید.
-// برای این امر، نیاز به امضا کننده حساب داریم...
-const singer = provider.getSinger()
-```
-
-**مثال Web3js**
-
-```js
-var web3 = new Web3("http://localhost:8545")
-// یا
-var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"))
-
-// تغییر فراهم آورنده
-web3.setProvider("ws://localhost:8546")
-// یا
-web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546"))
-
-// استفاده از فراهم آورنده IPC در نود جیاس
-var net = require("net")
-var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // مسیر mac os
-// یا
-var web3 = new Web3(
- new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net)
-) // مسیر mac os
-// در ویندوز مسیر "\\\\.\\pipe\\geth.ipc" است
-// در لینوکس مسیر "/users/myuser/.ethereum/geth.ipc" است
-```
-
-زمانی که راهاندازی شود، میتوانید موارد زیر را از زنجیره بلوکی ببیند:
-
-- شماره بلوک ها
-- تخمین گاز
-- رویداد های قرارداد های هوشمند
-- شناسه شبکه
-- و موارد دیگر...
-
-### عملکرد کیف پول {#wallet-functionality}
-
-این کتابخانه ها، برای ساخت کیف پول، مدیریت کلید ها و امضای تراکنش، به شما امکان عملکرد میدهند.
-
-در اینجا مثالی از Ethers را داریم
-
-```js
-// ساخت یک کیف پول نمونه از یک یادواره...
-// ارسال اتر
-wallet.sendTransaction(tx)
-```
-
-[همه اسناد را بخوانید](https://docs.ethers.io/v5/api/signer/#Wallet)
-
-زمانی که راهاندازی شد، میتوانید:
-
-- حساب درست کنید
-- تراکنش بفرستید
-- تراکنشها را امضا کنید
-- و موارد دیگر...
-
-### با توابع قرارداد هوشمند تعامل کنید {#interact-with-smart-contract-functions}
-
-کتابخانه های کاربر در جاوا اسکریپت به شما اجازه میدهند توابع قرارداد هوشمند را با خواندن اینترفیس باینری (ABI) از قرارداد کامپایل شده فراخوانی کنید.
-
-ABI به شما توابع قراردادها را در فرمت JSON توضیح میدهد و به شما امکان آن را میدهد که به عنوان یک شئ در جاواسکریپت استفاده کنید.
-
-بنابراین قرارداد solidity در زیر:
-
-```solidity
-contract Test {
- uint a;
- address d = 0x12345678901234567890123456789012;
-
- function Test(uint testInt) { a = testInt;}
-
- event Event(uint indexed b, bytes32 c);
-
- event Event2(uint indexed b, bytes32 c);
-
- function foo(uint b, bytes32 c) returns(address) {
- Event(b, c);
- return d;
- }
-}
-```
-
-باعث انجام این کد جاواسکریپت میشود:
-
-```json
-[{
- "type":"constructor",
- "payable":false,
- "stateMutability":"nonpayable"
- "inputs":[{"name":"testInt","type":"uint256"}],
- },{
- "type":"function",
- "name":"foo",
- "constant":false,
- "payable":false,
- "stateMutability":"nonpayable",
- "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}],
- "outputs":[{"name":"","type":"address"}]
- },{
- "type":"event",
- "name":"Event",
- "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}],
- "anonymous":false
- },{
- "type":"event",
- "name":"Event2",
- "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}],
- "anonymous":false
-}]
-```
-
-این به آن معنیست که شما میتوانید:
-
-- یک تراکنش برای قرارداد هوشمند بفرستید و روش آن را اجرا کنید
-- فراخوانی برای تخمین میزان گازی که یک اجرای روش، زمانی که در ماشین مجازی اتریوم اجرا شده، میگیرد
-- قرارداد را مستقر کنید
-- و موارد دیگر...
-
-### توابع کاربردی {#utility-functions}
-
-توابع کاربردی به شما میانبرهای آسانی میدهند تا به وسیله آن ها ساختن با اتریوم را برای شما راحت کنند.
-
-مقادیر ETH به طور پیش فرض در Wei هستند. 1ETH = 1,000,000,000,000,000,000 WEI - این بدان معناست که شما با اعداد زیادی سر و کار دارید! `web3.utils.toWei` اتر را برای شما به Wei تبدیل می کند.
-
-و در اترها به صورت زیر است:
-
-```js
-// Get the balance of an account (by address or ENS name)
-balance = await provider.getBalance("ethers.eth")
-// { BigNumber: "2337132817842795605" }
-
-// Often you will need to format the output for the user
-// which prefer to see values in ether (instead of wei)
-ethers.utils.formatEther(balance)
-// '2.337132817842795605'
-```
-
-- [توابع کاربردی Web3js](https://docs.web3js.org/api/web3-utils)
-- [توابع کاربردی اترها](https://docs.ethers.io/v5/api/utils/)
-
-## کتابخانه های موجود {#available-libraries}
-
-**Web3.js -** **_API اتریوم جاوا اسکریپت._**
-
-- [مستندات](https://docs.web3js.org/)
-- [گیتهاب](https://github.com/ethereum/web3.js/)
-
-**Ethers.js -** **_اجرای کامل کیف پول اتریوم و ابزارهای کاربردی در جاوا اسکریپت و تایپ اسکریپت._**
-
-- [مستندات](https://docs.ethers.io/)
-- [گیت هاب](https://github.com/ethers-io/ethers.js/)
-
-**The Graph-** **_پروتکلی برای نمایه سازی داده های اتریوم و IPFS و جستجو در آن با استفاده از GraphQL._**
-
-- [The Graph](https://thegraph.com/)
-- [Graph Explorer](https://thegraph.com/explorer/)
-- [اسناد](https://thegraph.com/docs/)
-- [گیتهاب](https://github.com/graphprotocol/)
-- [ديسكورد](https://thegraph.com/discord)
-
-**light.js -** **_یک کتابخانه JS واکنشپذیر سطح بالا که برای کاربرهای سبک بهینهسازی شده است._**
-
-- [گیتهاب](https://github.com/openethereum/js-libs/tree/master/packages/light.js)
-
-**Web3-wrapper -** **_جایگزین تایپ اسکریپ برای Web3.js_**
-
-- [اسناد](https://0x.org/docs/web3-wrapper#introduction)
-- [گیتهاب](https://github.com/0xProject/0x-monorepo/tree/development/packages/web3-wrapper)
-
-**Alchemyweb3 -** **_یک رپر روی Web3.js با تکرارهای خودکار و apiهای بهبودیافته._**
-
-- [اسناد](https://docs.alchemy.com/reference/api-overview)
-- [گیتهاب](https://github.com/alchemyplatform/alchemy-web3)
-
-**Alchemy NFT API -** **_API برای واکشی داده های NFT، از جمله مالکیت، ویژگی های فراداده و غیره._**
-
-- [مستندات](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
-- [گیتهاب](https://github.com/alchemyplatform/alchemy-web3)
-
-**viem -** **_واسط تایپ اسکریپت برای اتریوم._**
-
-- [اسناد](https://viem.sh)
-- [گیت هاب](https://github.com/wagmi-dev/viem)
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
-- [چارچوبهای توسعه](/developers/docs/frameworks/)
-
-## آموزش های مرتبط {#related-tutorials}
-
-- [Web3js را برای استفاده از بلاک چین اتریوم در جاوا اسکریپت راه اندازی کنید](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) *– دستورالعمل هایی برای راه اندازی web3.js در پروژه شما.*
-- [فراخوانی قرارداد هوشمند در جاوا اسکریپت](/developers/tutorials/calling-a-smart-contract-from-javascript/)_- با استفاده از توکن Dai، ببینید چگونه میشود با استفاده از توابع قراردادها را فراخوانی کرد._
-- [ارسال تراکنشها با استفاده از web3 و Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– راهنمای گام به گام برای ارسال تراکنشها از بک اند._
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
deleted file mode 100644
index 026b864b161..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md"
+++ /dev/null
@@ -1,1770 +0,0 @@
----
-title: وب سرویس JSON-RPC
-description: یک پروتکل فراخوانی روش از راه دور (RPC) بدون حالت و سبک وزن برای کلاینت های اتریوم.
-lang: fa
----
-
-برای اینکه یک برنامه نرم افزاری با زنجیره بلوکی اتریوم تعامل داشته باشد (با خواندن داده های زنجیره بلوکی و/یا ارسال تراکنش ها به شبکه)، باید به یک گره (نود) اتریوم متصل شود.
-
-برای این منظور، هر [کلاینت اتریوم](/developers/docs/nodes-and-clients/#execution-clients) یک [مشخصات JSON-RPC](https://github.com/ethereum/execution-apis) را پیادهسازی میکند، بنابراین مجموعه یکنواختی از روشها وجود دارد که برنامهها میتوانند بدون توجه به اجرای گره یا کلاینت خاص به آن تکیه کنند.
-
-JSON-RPC یک پروتکل فراخوانی روش راه دور (RPC) سبک وزن و بدون حالت است. در درجه اول مشخصات، چندین ساختار داده و قوانین پیرامون پردازش آنها را تعریف می کند. در این مبحث مهم نیسب که با چه روشی دادهها را انتقال داد، از طریق همان فرایند، ار طریق سوکتها، بر روی HTTP یا در بسیاری از محیطهای مختلف ارسال پیام. از JSON (RFC 4627) به عنوان فرمت داده استفاده می کند.
-
-## پیادهسازی کلاینت {#client-implementations}
-
-کلاینت های اتریوم هر کدام ممکن است از زبان های برنامه نویسی متفاوتی در هنگام اجرای مشخصات JSON-RPC استفاده کنند. برای جزئیات بیشتر مربوط به زبان های برنامه نویسی خاص، [مستندات کلاینت](/developers/docs/nodes-and-clients/#execution-clients) را مشاهده کنید. توصیه میکنیم اسناد مربوط به هر کلاینت را برای آخرین اطلاعات پشتیبانی وب سرویس بررسی کنید.
-
-## کتابخانه های تسهیل کننده {#convenience-libraries}
-
-در حالی که میتوانید مستقیماً از طریق JSON-RPC API با کلاینت اتریوم تعامل داشته باشید، اغلب گزینههای سادهتری برای توسعهدهندگان dapp وجود دارد. [جاوا اسکریپت](/developers/docs/apis/javascript/#available-libraries) و کتابخانه های [وب سرویس بک اند](/developers/docs/apis/backend/#available-libraries) بسیاری به منظور ارائه wrapper هایی بر روی وب سرویس JSON-RPC وجود دارد. با استفاده از این کتابخانهها، توسعهدهندگان میتوانند روشهای بصری و تک خطی را در زبان برنامهنویسی انتخابی خود بنویسند تا درخواستهای JSON-RPC (تحت سرپوش) را که با اتریوم تعامل دارند، تنظیم کنند.
-
-## APIهای لایه اجماع {#consensus-clients}
-
-این صفحه عمدتاً با JSON-RPC API مورد استفاده توسط کلاینت های اجرا در اتریوم سروکار دارد. با این حال، کلاینت های اجماع یک API RPC نیز دارند که به کاربران اجازه میدهد اطلاعات مربوط به گره، بلوکهای بیکن، حالت بیکن و سایر اطلاعات مربوط به اجماع را مستقیماً از یک گره جستجو کنند. این API در [صفحه وب بیکن API](https://ethereum.github.io/beacon-APIs/#/) مستند شده است.
-
-یک API داخلی نیز برای ارتباط بین کلاینت در یک گره استفاده میشود - یعنی کلاینت اجماع و کلاینت اجرا را قادر میسازد تا دادهها را مبادله کنند. این "Engine API" نامیده می شود و مشخصات آن در [گیتهاب](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) موجود است.
-
-## مشخصات کلاینت اجرا {#spec}
-
-[مشخصات کامل JSON-RPC API را در گیتهاب بخوانید](https://github.com/ethereum/execution-apis). این API در [صفحه وب Execution API](https://ethereum.github.io/execution-apis/api-documentation/) مستند شده است و شامل یک بازرس برای آزمایش همه روشهای موجود است.
-
-## کنوانسیونها {#conventions}
-
-### رمزگذاری مقدار هگز {#hex-encoding}
-
-دو نوع داده کلیدی از JSON منتقل می شوند: آرایه های بایت فرمت نشده و مقادیر. هر دو با یک رمزگذاری هگز ارسال می شوند اما با الزامات مختلف برای قالب بندی.
-
-#### مقادیر {#quantities-encoding}
-
-هنگام رمزگذاری مقادیر (اعداد صحیح، اعداد): رمزگذاری به صورت هگز، پیشوند با "0x"، فشرده ترین نمایش (استثنای جزئی: صفر باید به عنوان "0x0" نمایش داده شود).
-
-در اینجا چند نمونه آورده شده است:
-
-- 0x41 (65 در اعشار)
-- 0x400 (1024 در اعشار)
-- اشتباه: 0x (همیشه باید حداقل یک رقم داشته باشد - صفر همان "0x0" است)
-- اشتباه: 0x0400 (صفرهای ابتدایی مجاز نیستند)
-- اشتباه: ff (باید دارای پیشوند 0x باشد)
-
-### دیتای فرمت نشده {#unformatted-data-encoding}
-
-هنگام رمزگذاری داده های فرمت نشده (آرایه های بایت، آدرس های حساب، هش ها، آرایه های بایت کد): کدگذاری به صورت هگز، پیشوند با "0x"، دو رقم هگز در هر بایت.
-
-در اینجا چند نمونه آورده شده است:
-
-- 0x41 (اندازه 1، "A")
-- 0x004200 (اندازه 3، "0B0")
-- 0x (اندازه 0، "")
-- اشتباه: 0xf0f0f (باید تعداد ارقام زوج باشد)
-- اشتباه: 004200 (باید پیشوند 0x باشد)
-
-### پارامتر بلوک پیش فرض {#default-block}
-
-روش های زیر یک پارامتر بلوک پیش فرض اضافی دارند:
-
-- [eth_getBalance](#eth_getbalance)
-- [eth_getCode](#eth_getcode)
-- [eth_getTransactionCount](#eth_gettransactioncount)
-- [eth_getStorageAt](#eth_getstorageat)
-- [eth_call](#eth_call)
-
-هنگامی که درخواست هایی انجام می شود که بر روی وضعیت اتریوم عمل می کنند، آخرین پارامتر بلوک پیش فرض ارتفاع بلوک را تعیین می کند.
-
-گزینه های زیر برای پارامتر defaultBlock امکان پذیر است:
-
-- `رشته HEX` - یک عدد بلوک عدد صحیح
-- `رشته "Earliest"` برای Earliest/Genesis block
-- `رشته "آخرین"` - برای آخرین بلوک پیشنهادی
-- `رشته "ایمن"` - برای آخرین بلوک سر امن
-- `رشته "نهایی شده"` - برای آخرین بلوک نهایی شده
-- `رشته "در انتظار"` - برای وضعیت/معاملات در انتظار
-
-## مثال ها
-
-در این صفحه نمونههایی از نحوه استفاده از نقاط انتهایی API منفرد JSON_RPC با استفاده از ابزار خط فرمان، [curl](https://curl.se) ارائه میدهیم. این نمونههای نقطه پایان جداگانه در زیر در بخش [نمونههای Curl](#curl-examples) یافت میشوند. در پایین صفحه، ما همچنین یک [نمونه سرتاسری](#usage-example) برای کامپایل و استقرار یک قرارداد هوشمند با استفاده از گره Geth، JSON_RPC API و curl ارائه میدهیم.
-
-## نمونه های Curl {#curl-examples}
-
-نمونه هایی از استفاده از JSON_RPC API با درخواست [curl](https://curl.se) به یک گره اتریوم در زیر ارائه شده است. هر نمونه شامل شرحی از نقطه پایانی خاص، پارامترهای آن، نوع بازگشت، و یک مثال کار شده از نحوه استفاده از آن است.
-
-درخواستهای curl ممکن است پیام خطای مربوط به نوع محتوا را برگردانند. دلیل این امر این است که گزینه `--data` نوع محتوا را روی `application/x-www-form-urlencoded` تنظیم می کند. اگر گره شما از این موضوع شکایت دارد، با قرار دادن `-H "Content-Type: application/json"` در شروع تماس، هدر را به صورت دستی تنظیم کنید. نمونه ها همچنین شامل URL/IP و & ترکیب پورت که باید آخرین آرگومان داده شده به curl باشد (به عنوان مثال `127.0.0.1:8545`). یک درخواست کرل کامل شامل این داده های اضافی به شکل زیر است:
-
-```shell
-curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
-```
-
-## شایعات، حالت، تاریخ {#gossip-state-history}
-
-تعداد انگشت شماری از روشهای هستهای JSON-RPC به دادههایی از شبکه اتریوم نیاز دارند و به طور منظم در سه دسته اصلی قرار میگیرند: _Gossip، State و History_. از پیوندهای موجود در این بخش ها برای رفتن به هر روش استفاده کنید، یا از فهرست مطالب برای بررسی کل لیست روش ها استفاده کنید.
-
-### روش های شایعه پراکنی {#gossip-methods}
-
-> این روش ها سر زنجیره را دنبال می کنند. اینگونه است که تراکنش ها در شبکه راه می یابند، به بلوک ها راه پیدا می کنند و مشتریان چگونه از بلوک های جدید مطلع می شوند.
-
-- [eth_blockNumber](#eth_blocknumber)
-- [eth_sendRawTransaction](#eth_sendrawtransaction)
-
-### روش های حالت {#state_methods}
-
-> روش هایی که وضعیت فعلی تمام داده های ذخیره شده را گزارش می کنند. "وضعیت" مانند یک قطعه RAM مشترک بزرگ است و شامل مانده حساب ها، داده های قرارداد و تخمین گاز است.
-
-- [eth_getBalance](#eth_getbalance)
-- [eth_getStorageAt](#eth_getstorageat)
-- [eth_getTransactionCount](#eth_gettransactioncount)
-- [eth_getCode](#eth_getcode)
-- [eth_call](#eth_call)
-- [eth_estimateGas](#eth_estimategas)
-
-### روش های تاریخ {#history_methods}
-
-> سوابق تاریخی هر بلوک را به زمان پیدایش بازمی گرداند. این مانند یک فایل بزرگ است که فقط ضمیمه می شود و شامل تمام سرصفحه های بلوک، بدنه های بلوک، بلوک های عمو و رسیدهای تراکنش است.
-
-- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash)
-- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber)
-- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash)
-- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber)
-- [eth_getBlockByHash](#eth_getblockbyhash)
-- [eth_getBlockByNumber](#eth_getblockbynumber)
-- [eth_getTransactionByHash](#eth_gettransactionbyhash)
-- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex)
-- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex)
-- [eth_getTransactionReceipt](#eth_gettransactionreceipt)
-- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex)
-- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex)
-
-## JSON-RPC API Playground
-
-میتوانید از [ابزار زمین بازی](https://ethereum-json-rpc.com) برای کشف و آزمایش روشهای API استفاده کنید. همچنین به شما نشان می دهد که کدام روش ها و شبکه ها توسط ارائه دهندگان مختلف گره پشتیبانی می شوند.
-
-## روش های JSON-RPC API {#json-rpc-methods}
-
-### web3_clientVersion {#web3_clientversion}
-
-نسخه کلاینت فعلی را برمی گرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`رشته` - نسخه کلاینت فعلی
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc":"2.0",
- "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1"
-}
-```
-
-### web3_sha3 {#web3_sha3}
-
-Keccak-256 (_نه_ استاندارد SHA3-256) دادههای داده شده را برمیگرداند.
-
-**پارامترها**
-
-1. `DATA` - داده هایی که باید به هش SHA3 تبدیل شوند
-
-```js
-params: ["0x68656c6c6f20776f726c64"]
-```
-
-**برمی گرداند**
-
-`DATA` - نتیجه SHA3 رشته داده شده.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
-// Result
-{
- "id":64,
- "jsonrpc": "2.0",
- "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad"
-}
-```
-
-### net_version {#net_version}
-
-شناسه شبکه فعلی را برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`رشته` - شناسه شبکه فعلی.
-
-فهرست کامل شناسههای شبکه فعلی در [chainlist.org](https://chainlist.org) موجود است. برخی از موارد رایج عبارتند از:
-
-- `1`:以太坊主网
-- `5`: شبکه آزمایشی گورلی
-- `11155111`: شبکه آزمایشی Sepolia
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc": "2.0",
- "result": "3"
-}
-```
-
-### net_listening {#net_listening}
-
-اگر کلاینت فعالانه به اتصالات شبکه گوش دهد، `true` را برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`Boolean` - `درست` هنگام گوش دادن، در غیر این صورت `نادرست`.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc":"2.0",
- "result":true
-}
-```
-
-### net_peerCount {#net_peercount}
-
-تعداد همتاهایی که در حال حاضر به مشتری متصل هستند را برمی گرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح از تعداد همتاهای متصل.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
-// Result
-{
- "id":74,
- "jsonrpc": "2.0",
- "result": "0x2" // 2
-}
-```
-
-### eth_protocolVersion {#eth_protocolversion}
-
-نسخه فعلی پروتکل اتریوم را برمی گرداند. توجه داشته باشید که این روش [در Geth موجود نیست](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924).
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`رشته` - نسخه فعلی پروتکل اتریوم
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc": "2.0",
- "result": "54"
-}
-```
-
-### eth_syncing {#eth_syncing}
-
-یک شی را با دادههای مربوط به وضعیت همگامسازی یا `نادرست` برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-داده های برگشتی دقیق بین پیاده سازی های مشتری متفاوت است. وقتی گره همگامسازی نمیشود، همه کلاینتها `False` را برمیگردانند و همه کلاینتها فیلدهای زیر را برمیگردانند.
-
-`Object|Boolean`، یک شی با دادههای وضعیت همگامسازی یا `FALSE`، در صورت عدم همگامسازی:
-
-- `startingBlock`: `QUANTITY` - بلوکی که در آن واردات شروع شد (فقط پس از اینکه همگامسازی به سرش رسید بازنشانی میشود)
-- `currentBlock`: `QUANTITY` - بلوک فعلی، مانند eth_blockNumber
-- `highestBlock`: `QUANTITY` - تخمین زده شده بالاترین بلوک
-
-با این حال، کلاینت های منفرد ممکن است داده های اضافی را نیز ارائه دهند. به عنوان مثال Geth موارد زیر را برمی گرداند:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "currentBlock": "0x3cf522",
- "healedBytecodeBytes": "0x0",
- "healedBytecodes": "0x0",
- "healedTrienodes": "0x0",
- "healingBytecode": "0x0",
- "healingTrienodes": "0x0",
- "highestBlock": "0x3e0e41",
- "startingBlock": "0x3cbed5",
- "syncedAccountBytes": "0x0",
- "syncedAccounts": "0x0",
- "syncedBytecodeBytes": "0x0",
- "syncedBytecodes": "0x0",
- "syncedStorage": "0x0",
- "syncedStorageBytes": "0x0"
- }
-}
-```
-
-در حالی که Besu اینها را برمیگرداند:
-
-```json
-{
- "jsonrpc": "2.0",
- "id": 51,
- "result": {
- "startingBlock": "0x0",
- "currentBlock": "0x1518",
- "highestBlock": "0x9567a3",
- "pulledStates": "0x203ca",
- "knownStates": "0x200636"
- }
-}
-```
-
-برای جزئیات بیشتر به اسناد کلاینت خاص خود مراجعه کنید.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": {
- startingBlock: '0x384',
- currentBlock: '0x386',
- highestBlock: '0x454'
- }
-}
-// Or when not syncing
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": false
-}
-```
-
-### eth_coinbase {#eth_coinbase}
-
-آدرس کوین بیس مشتری را برمی گرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`DATA`، 20 بایت - آدرس کوین بیس فعلی.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
-// Result
-{
- "id":64,
- "jsonrpc": "2.0",
- "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1"
-}
-```
-
-### eth_chainId {#eth_chainId}
-
-چین آیدی مورد استفاده برای امضای تراکنشهای محافظت شده با پخش مجدد را برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`chainId`، مقدار هگزادسیمال به عنوان رشتهای که عدد صحیح شناسه زنجیره فعلی را نشان میدهد.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
-// Result
-{
- "id":67,
- "jsonrpc": "2.0",
- "result": "0x1"
-}
-```
-
-### eth_mining {#eth_mining}
-
-اگر مشتری فعالانه بلوکهای جدید را استخراج کند، `true` را برمیگرداند. این فقط میتواند `true` را برای شبکههای اثبات کار برگرداند و ممکن است از زمان [ادغام](/roadmap/merge/) در برخی از مشتریان موجود نباشد.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`بولین` - `true` را برمیگرداند که مشتری در حال استخراج است، در غیر این صورت `false` برمیگرداند.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
-//
-{
- "id":71,
- "jsonrpc": "2.0",
- "result": true
-}
-```
-
-### eth_hashrate {#eth_hashrate}
-
-تعداد هشهایی را که گره با آن استخراج میکند، برمیگرداند. این فقط میتواند `true` را برای شبکههای اثبات کار برگرداند و ممکن است از زمان [ادغام](/roadmap/merge/) در برخی از مشتریان موجود نباشد.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`QUANTITY` - تعداد هش در ثانیه.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
-// Result
-{
- "id":71,
- "jsonrpc": "2.0",
- "result": "0x38a"
-}
-```
-
-### eth_gasPrice {#eth_gasprice}
-
-تخمینی از قیمت فعلی هر گس را بر حسب wei برمیگرداند. به عنوان مثال، مشتری Besu 100 بلوک آخر را بررسی میکند و میانگین قیمت واحد گس را به طور پیش فرض برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح قیمت فعلی گس در wei.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
-// Result
-{
- "id":73,
- "jsonrpc": "2.0",
- "result": "0x1dfd14000" // 8049999872 Wei
-}
-```
-
-### eth_accounts {#eth_accounts}
-
-فهرستی از آدرسهای متعلق به مشتری را برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`آرایه داده`، 20 بایت - آدرسهای متعلق به مشتری.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"]
-}
-```
-
-### eth_blockNumber {#eth_blocknumber}
-
-تعداد بلوک اخیر را برمیگرداند.
-
-**پارامترها**
-
-هیچکدام
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح از شماره بلوک فعلی که مشتری روی آن قرار دارد.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
-// Result
-{
- "id":83,
- "jsonrpc": "2.0",
- "result": "0x4b7" // 1207
-}
-```
-
-### eth_getBalance {#eth_getbalance}
-
-موجودی حساب آدرس داده شده را برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، 20 بایت - آدرس برای بررسی مقدار حساب (موجودی).
-2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولینترین"`، `"در انتظار"` ، `"ایمن"` یا `"نهایی"`، به [بلوک پیشفرض پارامتر مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
-```
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح موجودی فعلی در wei.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x0234c8a3397aab58" // 158972490234375000
-}
-```
-
-### eth_getStorageAt {#eth_getstorageat}
-
-مقدار را از یک موقعیت ذخیرهسازی در یک آدرس معین برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، 20 بایت - آدرس محل ذخیره.
-2. `QUANTITY` - عدد صحیح موقعیت در حافظه.
-3. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"`, `"safe"`، `"نهایی شده"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
-
-**برمی گرداند**
-
-`DATA` - مقدار در این موقعیت ذخیرهسازی.
-
-**مثال** محاسبه موقعیت صحیح بستگی به فضای ذخیرهسازی برای بازیابی دارد. قرارداد زیر را که در `0x295a70b2de5e3953354a6a8344e616ed314d7251` با آدرس `0x391694e7e0b0cce554cb130d723a9d29> مستقر شده است در نظر بگیرید.
-
-contract Storage {
- uint pos0;
- mapping(address => uint) pos1;
- function Storage() {
- pos0 = 1234;
- pos1[msg.sender] = 5678;
- }
-}
-`
-
-بازیابی مقدار pos0 مستقیم است:
-
-```js
-curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
-{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
-```
-
-بازیابی یک عنصر از مپ سختتر است. موقعیت یک عنصر در مپ با موارد زیر محاسبه میشود:
-
-```js
-keccak(LeftPad32(key, 0), LeftPad32(map position, 0))
-```
-
-این بدان معناست که برای بازیابی فضای ذخیرهسازی در pos1 ["0x391694e7e0b0cce554cb130d723a9d27458f9298"] باید موقعیت را با این موارد محاسبه کنیم:
-
-```js
-keccak(
- decodeHex(
- "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" +
- "0000000000000000000000000000000000000000000000000000000000000001"
- )
-)
-```
-
-کنسول geth همراه با کتابخانه web3 میتواند برای محاسبه استفاده شود:
-
-```js
-> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
-undefined
-> web3.sha3(key, {"encoding": "hex"})
-"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
-```
-
-اکنون برای فچ کردن فضای ذخیرهسازی:
-
-```js
-curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
-{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
-```
-
-### eth_getTransactionCount {#eth_gettransactioncount}
-
-تعداد تراکنشهای _ارسال شده_ از یک آدرس را برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، بیست بایت - آدرس.
-2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` ، `"ایمن"` یا `"finalized"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-params: [
- "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
- "latest", // state at the latest block
-]
-```
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح تعداد تراکنشهای ارسال شده از این آدرس.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash}
-
-تعداد تراکنشهای یک بلوک را از یک بلوک منطبق با هش بلوک داده شده برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، سی و دو بایت - هش یک بلوک
-
-```js
-پارامترها: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
-```
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح تعداد تراکنشهای این بلوک.
-
-**مثال**
-
-```js
-// درخواست
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}'
-// نتیجه
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x8b" // 139
-}
-```
-
-### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber}
-
-تعداد تراکنشهای یک بلوک مطابق با شماره بلوک داده شده را برمیگرداند.
-
-**پارامترها**
-
-1. `QUANTITY|TAG` - عدد صحیح یک شماره بلوک، یا رشته `"زودترین"`، `"آخرین"`، `"در انتظار"` code>، `"ایمن"` یا `"نهایی"`، مانند [ پارامتر بلوک پیش فرض](/developers/docs/apis/json-rpc/#default-block).
-
-```js
-پارامترها: [
- "0x13738ca", // 20396234
-]
-```
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح تعداد تراکنشهای این بلوک.
-
-**مثال**
-
-```js
-// درخواست
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}'
-// نتیجه
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x8b" // 139
-}
-```
-
-### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash}
-
-تعداد بلاکهای عمو موجود در یک بلوک را از یک بلوک مطابق با هش بلوک داده شده برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، سی و دو بایت - هش یک بلوک
-
-```js
-پارامترها: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
-```
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح تعداد عموهای این بلوک (یک اصطلاح است).
-
-**مثال**
-
-```js
-// درخواست
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}'
-// نتیجه
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber}
-
-تعداد عموهای موجود در یک بلوک را از یک بلوک مطابق با شماره بلوک داده شده برمیگرداند.
-
-**پارامترها**
-
-1. `QUANTITY|TAG` - عدد صحیح یک عدد بلوک، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` code>، `"ایمن"` یا `"نهایی شده"`، به [پیشفرض مراجعه کنید پارامتر بلوک](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-params: [
- "0xe8", // 232
-]
-```
-
-**برمی گرداند**
-
-`QUANTITY` - عدد صحیح تعداد عموهای این بلوک (یک اصطلاح است).
-
-**مثال**
-
-```js
-// درخواست
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'
-// نتیجه
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x0" // 0
-}
-```
-
-### eth_getCode {#eth_getcode}
-
-کد را در یک آدرس داده شده برمی گرداند.
-
-**پارامترها**
-
-1. `DATA`، بیست بایت - آدرس
-2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` ، `"ایمن"` یا `"finalized"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
-
-```js
-پارامترها: [
- "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
- "0x5daf3b", // 6139707
-]
-```
-
-**برمی گرداند**
-
-`DATA` - کد از آدرس داده شده.
-
-**مثال**
-
-```js
-// درخواست
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}'
-// نتیجه
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029"
-}
-```
-
-### eth_sign {#eth_sign}
-
-روش امضا، یک امضای خاص اتریوم را با این موارد محاسبه میکند: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(پیام) + پیام)))`.
-
-با افزودن یک پیشوند به پیام، امضای محاسبه شده به عنوان یک امضای خاص اتریوم قابل تشخیص است. این از سوء استفاده در جایی که یک برنامه مخرب میتواند دادههای دلخواه (مانند تراکنش) را امضا و از امضا برای جعل هویت قربانی استفاده کند، جلوگیری میکند.
-
-توجه: آدرسی که باید با آن امضا کنید باید قفل باشد.
-
-**پارامترها**
-
-1. `DATA`، بیست بایت - آدرس
-2. `DATA`، N بایت - پیام برای امضا
-
-**برمی گرداند**
-
-`DATA`: امضا
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
-}
-```
-
-### eth_signTransaction {#eth_signtransaction}
-
-تراکنشی را امضا میکند که میتواند بعداً با استفاده از [eth_sendRawTransaction](#eth_sendrawtransaction) به شبکه ارسال شود.
-
-**پارامترها**
-
-1. `Object` - شیء معامله
-
-- `نوع`:
-- `از`: `DATA`، 20 بایت - آدرسی که تراکنش از آن ارسال میشود.
-- `به`: `DATA`، 20 بایت - (اختیاری هنگام ایجاد قرارداد جدید) آدرسی که تراکنش به آن هدایت میشود.
-- `گس`: `QUANTITY` - (اختیاری، پیشفرض: 90000) عدد صحیح گس ارائه شده برای اجرای تراکنش. گس استفاده نشده را برمیگرداند.
-- `gasPrice`: `QUANTITY` - (اختیاری، پیشفرض: باید تعیین شود) عدد صحیح گس قیمت مورد استفاده برای هر گس پرداختی، بر حسب Wei.
-- `مقدار`: `QUANTITY` - (اختیاری) عدد صحیح از مقدار ارسال شده با این تراکنش، بر حسب Wei.
-- `data`: `DATA` - کد کامپایل شده یک قرارداد یا هش امضای متد فراخوانی شده و پارامترهای کدگذاری شده.
-- `نانس`: `QUANTITY` - (اختیاری) عدد صحیح یک نانس. این مورد اجازه میدهد تا تراکنشهای در انتظار خود را که از همان نانس استفاده میکنند، بازنویسی کند.
-
-**برمی گرداند**
-
-`DATA`، شی تراکنش رمزگذاری شده با RLP که توسط حساب مشخص شده امضا شده است.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
-// Result
-{
- "id": 1,
- "jsonrpc": "2.0",
- "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
-}
-```
-
-### eth_sendTransaction {#eth_sendtransaction}
-
-اگر فیلد داده حاوی کد باشد، تراکنش تماس یا فراخوانی پیام جدید یا ایجاد قرارداد ایجاد میکند و آن را با استفاده از حساب مشخص شده در `from` امضا میکند.
-
-**پارامترها**
-
-1. `Object` - شیء معامله
-
-- `از`: `DATA`، 20 بایت - آدرسی که تراکنش از آن ارسال میشود.
-- `به`: `DATA`، 20 بایت - (اختیاری هنگام ایجاد قرارداد جدید) آدرسی که تراکنش به آن هدایت میشود.
-- `گس`: `QUANTITY` - (اختیاری، پیشفرض: 90000) عدد صحیح گس ارائه شده برای اجرای تراکنش. گس استفاده نشده را برمیگرداند.
-- `gasPrice`: `QUANTITY` - (اختیاری، پیشفرض: باید تعیین شود) عدد صحیح gasPrice استفاده شده برای هر گس پرداختی.
-- `مقدار`: `QUANTITY` - (اختیاری) عدد صحیح مقدار ارسال شده با این تراکنش.
-- `ورودی`: `DATA` - کد کامپایل شده یک قرارداد یا هش امضای متد فراخوانی شده و پارامترهای کدگذاری شده.
-- `نانس`: `QUANTITY` - (اختیاری) عدد صحیح یک نانس. این مورد اجازه میدهد تا تراکنشهای در انتظار خود را که از همان نانس استفاده میکنند، بازنویسی کند.
-
-```js
-params: [
- {
- from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155",
- to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
- gas: "0x76c0", // 30400
- gasPrice: "0x9184e72a000", // 10000000000000
- value: "0x9184e72a", // 2441406250
- input:
- "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
- },
-]
-```
-
-**برمی گرداند**
-
-`DATA`، 32 بایت - هش تراکنش، یا هش صفر اگر تراکنش هنوز در دسترس نباشد.
-
-از [eth_getTransactionReceipt](#eth_gettransactionreceipt) برای دریافت آدرس قرارداد، پس از پیشنهاد تراکنش در یک بلوک، هنگام ایجاد قرارداد استفاده کنید.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
-}
-```
-
-### eth_sendRawTransaction {#eth_sendrawtransaction}
-
-تراکنش تماس یا فراخوانی پیام جدید یا ایجاد قرارداد برای تراکنشهای امضا شده ایجاد میکند.
-
-**پارامترها**
-
-1. `DATA`، دادههای تراکنش امضا شده.
-
-```js
-params: [
- "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
-]
-```
-
-**برمی گرداند**
-
-`DATA`، 32 بایت - هش تراکنش، یا هش صفر اگر تراکنش هنوز در دسترس نباشد.
-
-از [eth_getTransactionReceipt](#eth_gettransactionreceipt) برای دریافت آدرس قرارداد، پس از پیشنهاد تراکنش در یک بلوک، هنگام ایجاد قرارداد استفاده کنید.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
-}
-```
-
-### eth_call {#eth_call}
-
-بدون ایجاد تراکنش در زنجیره بلوک، یک تماس پیام جدید را بلافاصله اجرا میکند. اغلب برای اجرای توابع قرارداد هوشمند فقط خواندنی، به عنوان مثال `balanceOf` برای قرارداد ERC-20 استفاده میشود.
-
-**پارامترها**
-
-1. `Object` - شیء فراخوانی تراکنش
-
-- `از`: `DATA`, 20 بایت - آدرسی که تراکنش از آن فرستاده میشود (اختیاری).
-- `به`: `DATA`، 20 بایت - آدرسی که تراکنش به آن هدایت میشود.
-- `گس`: `QUANTITY` - (اختیاری) عدد صحیح گس ارائه شده برای اجرای تراکنش. eth_call گس صفر مصرف میکند، اما این پارامتر ممکن است برای برخی از اجراها مورد نیاز باشد.
-- `gasPrice`: `QUANTITY` - (اختیاری) عدد صحیح gasPrice استفاده شده برای هر گس پرداختی
-- `مقدار`: `QUANTITY` - (اختیاری) عدد صحیح مقدار ارسال شده با این تراکنش
-- `ورودی`: `DATA` - (اختیاری) هش امضای روش و پارامترهای کدگذاری شده. برای جزئیات به [ABI قرارداد اتریوم در مستندات یا داکیومنت سالیدیتی](https://docs.soliditylang.org/en/latest/abi-spec.html) مراجعه کنید.
-
-2. `QUANTITY|TAG` - شماره بلوک عدد صحیح، یا رشته `"آخرین"`، `"اولین"`، `"در انتظار"` ، `"ایمن"` یا `"finalized"`، به [پارامتر بلوک پیشفرض مراجعه کنید ](/developers/docs/apis/json-rpc/#default-block)
-
-**برمی گرداند**
-
-`DATA` - مقدار بازگشتی قرارداد اجرا شده.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x"
-}
-```
-
-### eth_estimateGas {#eth_estimategas}
-
-تخمینی از میزان گس لازم برای تکمیل تراکنش را ایجاد و برمیگرداند. تراکنش به بلاک چین اضافه نخواهد شد. توجه داشته باشید که به دلایل مختلفی از جمله مکانیک ماشین مجازی اتریوم و عملکرد گره، تخمین ممکن است به طور قابل توجهی بیشتر از مقدار گس مورد استفاده در معامله باشد.
-
-**پارامترها**
-
-به پارامترهای [eth_call](#eth_call) مراجعه کنید، با این تفاوت که همه ویژگیها اختیاری هستند. اگر محدودیت گس مشخص نشده باشد، گس از حد گس بلوک از بلوک در حال انتظار به عنوان کران بالایی استفاده میکند. در نتیجه برآورد برگشتی ممکن است برای اجرای تماس/معامله زمانی که مقدار گس بیشتر از حد گس بلوک در انتظار باشد کافی نباشد.
-
-**برمی گرداند**
-
-`QUANTITY` - مقدار گس مصرفی.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x5208" // 21000
-}
-```
-
-### eth_getBlockByHash {#eth_getblockbyhash}
-
-اطلاعات مربوط به یک بلوک را با هش برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، 32 بایت - هش یک بلوک.
-2. `بولین` - اگر `true` اشیاء تراکنش کامل را برمیگرداند، اگر `false` فقط هشهای تراکنشها را برمیگرداند.
-
-```js
-params: [
- "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
- false,
-]
-```
-
-**برمی گرداند**
-
-`آبجکت` - یک شیء بلوک، یا `null` هنگامی که هیچ بلوکی پیدا نشد:
-
-- `شماره`: `QUANTITY` - شماره بلوک. `null` زمانی که بلوک در حال انتظار است.
-- `هش`: `DATA`، 32 بایت - هش بلوک. `null` زمانی که بلوک در حال انتظار است.
-- `parentHash`: `DATA`، 32 بایت - هش بلوک والد.
-- `nonce`: `DATA`، 8 بایت - هش اثبات کار ایجاد شده. `null` زمانی که بلوک در حال انتظار است.
-- `sha3Uncles`: `DATA`، 32 بایت - SHA3 از دادههای عمو یا آنکل در بلوک.
-- `logsBloom`: `DATA`، 256 بایت - فیلتر بلوم گزارشهای بلوک. `null` زمانی که بلوک در حال انتظار است.
-- `transactionsRoot`: `DATA`، 32 بایت - ریشه آزمایش تراکنش بلوک.
-- `stateRoot`: `DATA`، 32 بایت - ریشه آزمایش وضعیت نهایی بلوک.
-- `receiptsRoot`: `DATA`، 32 بایت - ریشه آزمایشی رسیدهای بلوک.
-- `miner`: `DATA`، 20 بایت - آدرس ذینفعی که پاداش استخراج به او داده شده است.
-- `سختی`: `QUANTITY` - عدد صحیح دشواری این بلوک.
-- `totalDifficulty`: `QUANTITY` - عدد صحیح کل سختی زنجیره تا این بلوک.
-- `extraData`: `DATA` - قسمت "داده اضافی" این بلوک.
-- `size`: `QUANTITY` - عدد صحیح اندازه این بلوک بر حسب بایت.
-- `gasLimit`: `QUANTITY` - حداکثر گس مجاز در این بلوک.
-- `gasUsed`: `QUANTITY` - کل گس مصرف شده توسط همه تراکنشهای این بلوک.
-- `مهر زمانی یا تایم استمپ`: `QUANTITY` - مهر زمانی یونیکس برای زمانی که بلوک جمعآوری شده است.
-- `معاملات`: `آرایه` - آرایهای از اشیاء تراکنش، یا هش تراکنشهای 32 بایتی بسته به آخرین پارامتر داده شده.
-- `عموها`: `آرایه` - آرایه هشهای عمو.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
-// Result
-{
-{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
- "difficulty": "0x4ea3f27bc",
- "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
- "gasLimit": "0x1388",
- "gasUsed": "0x0",
- "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
- "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171",
- "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843",
- "nonce": "0x689056015818adbe",
- "number": "0x1b4",
- "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54",
- "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
- "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
- "size": "0x220",
- "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d",
- "timestamp": "0x55ba467c",
- "totalDifficulty": "0x78ed983323d",
- "transactions": [
- ],
- "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
- "uncles": [
- ]
-}
-}
-```
-
-### eth_getBlockByNumber {#eth_getblockbynumber}
-
-اطلاعات مربوط به یک بلوک را با شماره بلوک برمیگرداند.
-
-**پارامترها**
-
-1. `QUANTITY|TAG` - عدد صحیح یک شماره بلوک، یا رشته `"زودترین"`، `"آخرین"`، `"در انتظار"` code>، `"ایمن"` یا `"نهایی"`، مانند [ پارامتر بلوک پیش فرض](/developers/docs/apis/json-rpc/#default-block).
-2. `بولین` - اگر `true` اشیاء تراکنش کامل را برمیگرداند، اگر `false` فقط هشهای تراکنشها را برمیگرداند.
-
-```js
-params: [
- "0x1b4", // 436
- true,
-]
-```
-
-**برمیگرداند** به [eth_getBlockByHash](#eth_getblockbyhash) مراجعه کنید
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
-```
-
-نتیجه را ببینید [eth_getBlockByHash](#eth_getblockbyhash)
-
-### eth_getTransactionByHash {#eth_gettransactionbyhash}
-
-اطلاعات مربوط به تراکنش درخواست شده توسط هش تراکنش را برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، 32 بایت - هش تراکنش
-
-```js
-params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
-```
-
-**برمی گرداند**
-
-`آبجکت` - یک شیء تراکنش یا `null` هنگامی که هیچ تراکنشی پیدا نشد:
-
-- `blockHash`: `DATA`، 32 بایت - هش بلوکی که این تراکنش در آن بوده است. `null` زمانی که در حال تعلیق یا سپری شدن است.
-- `blockNumber`: `QUANTITY` - شماره بلوکی که این تراکنش در آن بوده است. `null` زمانی که در حال تعلیق یا سپری شدن است.
-- `از`: `DATA`، 20 بایت - آدرس فرستنده.
-- `گاز`: `QUANTITY` - گس ارائه شده توسط فرستنده.
-- `gasPrice`: `QUANTITY` - قیمت گس ارائه شده توسط فرستنده بر حسب Wei.
-- `هش`: `DATA`، 32 بایت - هش تراکنش.
-- `ورودی`: `DATA` - دادهها همراه با تراکنش ارسال میشوند.
-- `nonce`: `QUANTITY` - تعداد تراکنشهایی که فرستنده قبل از این تراکنش انجام داده است.
-- `به`: `DATA`، 20 بایت - آدرس گیرنده. `null` زمانی که یک معامله ایجاد قرارداد باشد.
-- `transactionIndex`: `QUANTITY` - عدد صحیح موقعیت شاخص تراکنشها در بلوک. `null` زمانی که در حال تعلیق یا سپری شدن است.
-- `مقدار`: `QUANTITY` - مقدار منتقل شده بر حسب Wei.
-- `v`: `QUANTITY` - شناسه بازیابی ECDSA
-- `r`: `QUANTITY` - امضای ECDSA r
-- `s`: `QUANTITY` - امضای ECDSA
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
-// Result
-{
- "jsonrpc":"2.0",
- "id":1,
- "result":{
- "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
- "blockNumber":"0x5daf3b", // 6139707
- "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d",
- "gas":"0xc350", // 50000
- "gasPrice":"0x4a817c800", // 20000000000
- "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b",
- "input":"0x68656c6c6f21",
- "nonce":"0x15", // 21
- "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb",
- "transactionIndex":"0x41", // 65
- "value":"0xf3dbb76162000", // 4290000000000000
- "v":"0x25", // 37
- "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea",
- "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c"
- }
-}
-```
-
-### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex}
-
-اطلاعات مربوط به تراکنش را بر اساس هش بلوک و موقعیت شاخص تراکنش برمیگرداند.
-
-**پارامترها**
-
-1. `DATA`، 32 بایت - هش یک بلوک.
-2. `QUANTITY` - عدد صحیح موقعیت شاخص یا ایندکس تراکنش.
-
-```js
-پارامترها: [
- "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
- "0x0", // 0
-]
-```
-
-**برمیگرداند** ببینید[eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-**مثال**
-
-```js
-// درخواست
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
-```
-
-نتیجه را ببینید [eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
-
-اطلاعات مربوط به یک تراکنش را بر اساس شماره بلوک و موقعیت شاخص تراکنش برمیگرداند.
-
-**پارامترها**
-
-1. `QUANTITY|TAG` - یک شماره بلوک، یا رشته `"زودترین"`، `"آخرین"`، `"در انتظار"` مانند [بلوک پیشفرض، `"ایمن"` یا `"نهایی"` پارامتر](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - موقعیت شاخص تراکنش.
-
-```js
-params: [
- "0x9c47cf", // 10241999
- "0x24", // 36
-]
-```
-
-**برمیگرداند** ببینید[eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
-```
-
-نتیجه را ببینید [eth_getTransactionByHash](#eth_gettransactionbyhash)
-
-### eth_getTransactionReceipt {#eth_gettransactionreceipt}
-
-رسید یک تراکنش را با هش تراکنش برمیگرداند.
-
-**توجه داشته باشید** که رسید برای تراکنشهای در انتظار موجود نیست.
-
-**پارامترها**
-
-1. `DATA`، 32 بایت - هش تراکنش
-
-```js
-params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
-```
-
-`آبجکت` - یک شیء رسید تراکنش، یا `null` زمانی که هیچ رسیدی پیدا نشد:
-
-- `transactionHash`: `DATA`، 32 بایت - هش تراکنش.
-- `transactionIndex`: `QUANTITY` - عدد صحیح موقعیت شاخص تراکنشها در بلوک.
-- `blockHash`: `DATA`، 32 بایت - هش بلوکی که این تراکنش در آن بوده است.
-- `blockNumber`: `QUANTITY` - شماره بلوکی که این تراکنش در آن بوده است.
-- `از`: `DATA`، 20 بایت - آدرس فرستنده.
-- `به`: `DATA`، 20 بایت - آدرس گیرنده. زمانی که یک معامله ایجاد قرارداد باشد، null است.
-- `cumulativeGasUsed` : `QUANTITY` - کل مقدار گسی که هنگام انجام این تراکنش در بلوک استفاده شده است.
-- `effectiveGasPrice` : `QUANTITY` - مجموع هزینه پایه و انعام پرداخت شده به ازای هر واحد گس.
-- `gasUsed`: `QUANTITY` - مقدار گس مصرفی تنها توسط این تراکنش خاص.
-- `contractAddress`: `DATA`, 20 بایت - آدرس قرارداد ایجاد شد، اگر تراکنش یک ایجاد قرارداد بود، در غیر اینصورت `صفر`.
--
-- `logsBloom`: `DATA`, 256 Bytes - Bloom filter for light clients to quickly retrieve related logs.
-- `type`: `QUANTITY` - integer of the transaction type, `0x0` for legacy transactions, `0x1` for access list types, `0x2` for dynamic fees.
-
-It also returns _either_ :
-
-- `root` : `DATA` 32 bytes of post-transaction stateroot (pre Byzantium)
-- `status`: `QUANTITY` either `1` (success) or `0` (failure)
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
-// Result
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {
- "blockHash":
- "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
- "blockNumber": "0xeff35f",
- "contractAddress": null, // string of the address if it was created
- "cumulativeGasUsed": "0xa12515",
- "effectiveGasPrice": "0x5a9c688d4",
- "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
- "gasUsed": "0xb4c8",
- "logs": [{
- // logs as returned by getFilterLogs, etc.
- }],
- "logsBloom": "0x00...0", // 256 byte bloom filter
- "status": "0x1",
- "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
- "transactionHash":
- "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5",
- "transactionIndex": "0x66",
- "type": "0x2"
- }
-}
-```
-
-### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-
-Returns information about a uncle of a block by hash and uncle index position.
-
-**پارامترها**
-
-1. `DATA`, 32 Bytes - The hash of a block.
-2. `QUANTITY` - The uncle's index position.
-
-```js
-پارامترها: [
- "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
- "0x0", // 0
-]
-```
-
-**برمیگرداند** به [eth_getBlockByHash](#eth_getblockbyhash) مراجعه کنید
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
-```
-
-نتیجه را ببینید [eth_getBlockByHash](#eth_getblockbyhash)
-
-**Note**: An uncle doesn't contain individual transactions.
-
-### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-
-Returns information about a uncle of a block by number and uncle index position.
-
-**پارامترها**
-
-1. `QUANTITY|TAG` - a block number, or the string `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, as in the [default block parameter](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - the uncle's index position.
-
-```js
-params: [
- "0x29c", // 668
- "0x0", // 0
-]
-```
-
-**برمیگرداند** به [eth_getBlockByHash](#eth_getblockbyhash) مراجعه کنید
-
-**Note**: An uncle doesn't contain individual transactions.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
-```
-
-نتیجه را ببینید [eth_getBlockByHash](#eth_getblockbyhash)
-
-### eth_newFilter {#eth_newfilter}
-
-Creates a filter object, based on filter options, to notify when the state changes (logs). To check if the state has changed, call [eth_getFilterChanges](#eth_getfilterchanges).
-
-**A note on specifying topic filters:** Topics are order-dependent. A transaction with a log with topics [A, B] will be matched by the following topic filters:
-
-- `[]` "anything"
-- `[A]` "A in first position (and anything after)"
-- `[null, B]` "anything in first position AND B in second position (and anything after)"
-- `[A, B]` "A in first position AND B in second position (and anything after)"
-- `[[A, B], [A, B]]` "(A OR B) in first position AND (A OR B) in second position (and anything after)"
-- **پارامترها**
-
-1. `Object` - The filter options:
-
-- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
-- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
-- `address`: `DATA|Array`, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
-- `topics`: `Array of DATA`, - (optional) Array of 32 Bytes `DATA` topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.
-
-```js
-params: [
- {
- fromBlock: "0x1",
- toBlock: "0x2",
- address: "0x8888f1f195afa192cfee860698584c030f4c9db1",
- topics: [
- "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
- null,
- [
- "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
- "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc",
- ],
- ],
- },
-]
-```
-
-**Returns** `QUANTITY` - A filter id.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_newBlockFilter {#eth_newblockfilter}
-
-Creates a filter in the node, to notify when a new block arrives. To check if the state has changed, call [eth_getFilterChanges](#eth_getfilterchanges).
-
-**Parameters** None
-
-**Returns** `QUANTITY` - A filter id.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-
-Creates a filter in the node, to notify when new pending transactions arrive. To check if the state has changed, call [eth_getFilterChanges](#eth_getfilterchanges).
-
-**Parameters** None
-
-**Returns** `QUANTITY` - A filter id.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": "0x1" // 1
-}
-```
-
-### eth_uninstallFilter {#eth_uninstallfilter}
-
-Uninstalls a filter with given id. Should always be called when watch is no longer needed. Additionally Filters timeout when they aren't requested with [eth_getFilterChanges](#eth_getfilterchanges) for a period of time.
-
-**پارامترها**
-
-1. `QUANTITY` - The filter id.
-
-```js
-params: [
- "0xb", // 11
-]
-```
-
-**Returns** `Boolean` - `true` if the filter was successfully uninstalled, otherwise `false`.
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc": "2.0",
- "result": true
-}
-```
-
-### eth_getFilterChanges {#eth_getfilterchanges}
-
-Polling method for a filter, which returns an array of logs which occurred since last poll.
-
-**پارامترها**
-
-1. `QUANTITY` - the filter id.
-
-```js
-params: [
- "0x16", // 22
-]
-```
-
-**Returns** `Array` - Array of log objects, or an empty array if nothing has changed since last poll.
-
-- For filters created with `eth_newBlockFilter` the return are block hashes (`DATA`, 32 Bytes), e.g. `["0x3454645634534..."]`.
-- For filters created with `eth_newPendingTransactionFilter` the return are transaction hashes (`DATA`, 32 Bytes), e.g. `["0x6345343454645..."]`.
-- For filters created with `eth_newFilter` logs are objects with following params:
- - `removed`: `TAG` - `true` when the log was removed, due to a chain reorganization. `false` if its a valid log.
- - `logIndex`: `QUANTITY` - عدد صحیح موقعیت فهرست گزارش در بلوک. `null` زمانی که گزارش در حال انتظار است.
- - `transactionIndex`: `QUANTITY` - integer of the transactions index position log was created from. `null` زمانی که گزارش در حال انتظار است.
- - `transactionHash`: `DATA`, 32 Bytes - hash of the transactions this log was created from. `null` زمانی که گزارش در حال انتظار است.
- - `blockHash`: `DATA`, 32 Bytes - hash of the block where this log was in. `null` زمانی که در حال تعلیق یا سپری شدن است. `null` زمانی که گزارش در حال انتظار است.
- - `blockNumber`: `QUANTITY` - the block number where this log was in. `null` زمانی که در حال تعلیق یا سپری شدن است. `null` زمانی که گزارش در حال انتظار است.
- - `address`: `DATA`, 20 Bytes - address from which this log originated.
- - `data`: `DATA` - contains zero or more 32 Bytes non-indexed arguments of the log.
- - `topics`: `Array of DATA` - Array of 0 to 4 32 Bytes `DATA` of indexed log arguments. (In _solidity_: The first topic is the _hash_ of the signature of the event (e.g. `Deposit(address,bytes32,uint256)`), except you declared the event with the `anonymous` specifier.)
-- **مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
-// Result
-{
- "id":1,
- "jsonrpc":"2.0",
- "result": [{
- "logIndex": "0x1", // 1
- "blockNumber":"0x1b4", // 436
- "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
- "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
- "transactionIndex": "0x0", // 0
- "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
- "data":"0x0000000000000000000000000000000000000000000000000000000000000000",
- "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
- },{
- ...
- }]
-}
-```
-
-### eth_getFilterLogs {#eth_getfilterlogs}
-
-Returns an array of all logs matching filter with given id.
-
-**پارامترها**
-
-1. `QUANTITY` - The filter id.
-
-```js
-params: [
- "0x16", // 22
-]
-```
-
-**Returns** See [eth_getFilterChanges](#eth_getfilterchanges)
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
-```
-
-Result see [eth_getFilterChanges](#eth_getfilterchanges)
-
-### eth_getLogs {#eth_getlogs}
-
-Returns an array of all logs matching a given filter object.
-
-**پارامترها**
-
-1. `Object` - The filter options:
-
-- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
-- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
-- `address`: `DATA|Array`, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
-- `topics`: `Array of DATA`, - (optional) Array of 32 Bytes `DATA` topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.
-- `blockhash`: `DATA`, 32 Bytes - (optional, **future**) With the addition of EIP-234, `blockHash` will be a new filter option which restricts the logs returned to the single block with the 32-byte hash `blockHash`. Using `blockHash` is equivalent to `fromBlock` = `toBlock` = the block number with hash `blockHash`. If `blockHash` is present in the filter criteria, then neither `fromBlock` nor `toBlock` are allowed.
-
-```js
-params: [
- {
- topics: [
- "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
- ],
- },
-]
-```
-
-**Returns** See [eth_getFilterChanges](#eth_getfilterchanges)
-
-**مثال**
-
-```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
-```
-
-Result see [eth_getFilterChanges](#eth_getfilterchanges)
-
-## Usage Example {#usage-example}
-
-### Deploying a contract using JSON_RPC {#deploying-contract}
-
-This section includes a demonstration of how to deploy a contract using only the RPC interface. There are alternative routes to deploying contracts where this complexity is abstracted away—for example, using libraries built on top of the RPC interface such as [web3.js](https://web3js.readthedocs.io/) and [web3.py](https://github.com/ethereum/web3.py). These abstractions are generally easier to understand and less error-prone, but it is still helpful to understand what is happening under the hood.
-
-The following is a straightforward smart contract called `Multiply7` that will be deployed using the JSON-RPC interface to an Ethereum node. This tutorial assumes the reader is already running a Geth node. More information on nodes and clients is available [here](/developers/docs/nodes-and-clients/run-a-node). Please refer to individual [client](/developers/docs/nodes-and-clients/) documentation to see how to start the HTTP JSON-RPC for non-Geth clients. Most clients default to serving on `localhost:8545`.
-
-```javascript
-contract Multiply7 {
- event Print(uint);
- function multiply(uint input) returns (uint) {
- Print(input * 7);
- return input * 7;
- }
-}
-```
-
-The first thing to do is make sure the HTTP RPC interface is enabled. This means we supply Geth with the `--http` flag on startup. In this example we use the Geth node on a private development chain. Using this approach we don't need ether on the real network.
-
-```bash
-geth --http --dev console 2>>geth.log
-```
-
-This will start the HTTP RPC interface on `http://localhost:8545`.
-
-We can verify that the interface is running by retrieving the Coinbase address and balance using [curl](https://curl.se). Please note that data in these examples will differ on your local node. If you want to try these commands, replace the request params in the second curl request with the result returned from the first.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_coinbase", "id":1}' -H "Content-Type: application/json" localhost:8545
-{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
-
-curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
-{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"}
-```
-
-Because numbers are hex encoded, the balance is returned in wei as a hex string. If we want to have the balance in ether as a number we can use web3 from the Geth console.
-
-```javascript
-web3.fromWei("0x1639e49bba16280000", "ether")
-// "410"
-```
-
-Now that there is some ether on our private development chain, we can deploy the contract. The first step is to compile the Multiply7 contract to byte code that can be sent to the EVM. To install solc, the Solidity compiler, follow the [Solidity documentation](https://docs.soliditylang.org/en/latest/installing-solidity.html). (You might want to use an older `solc` release to match [the version of compiler used for our example](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
-
-The next step is to compile the Multiply7 contract to byte code that can be send to the EVM.
-
-```bash
-echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
-
-======= :Multiply7 =======
-Binary:
-6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
-```
-
-Now that we have the compiled code we need to determine how much gas it costs to deploy it. The RPC interface has an `eth_estimateGas` method that will give us an estimate.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
-{"jsonrpc":"2.0","id":5,"result":"0x1c31e"}
-```
-
-And finally deploy the contract.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545
-{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
-```
-
-The transaction is accepted by the node and a transaction hash is returned. This hash can be used to track the transaction. The next step is to determine the address where our contract is deployed. Each executed transaction will create a receipt. This receipt contains various information about the transaction such as in which block the transaction was included and how much gas was used by the EVM. If a transaction creates a contract it will also contain the contract address. We can retrieve the receipt with the `eth_getTransactionReceipt` RPC method.
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
-{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
-```
-
-قرارداد ما در `0x4d03d617d700cf81935d7f797f4e2ae719648262` ایجاد شد. نتیجه صفر به جای رسید به این معنی است که تراکنش هنوز در یک بلوک گنجانده نشده است. یک لحظه صبر و بررسی کنید که آیا کلاینت اجماع شما در حال اجرا است یا خیر و دوباره آن را امتحان کنید.
-
-#### تعامل با قراردادهای هوشمند {#interacting-with-smart-contract}
-
-در این مثال، ما یک تراکنش را با استفاده از `eth_sendTransaction` به روش `multiply` قرارداد ارسال خواهیم کرد.
-
-`eth_sendTransaction` به چندین آرگومان نیاز دارد، به ویژه `از`، `به` و `داده`. `From` آدرس عمومی حساب ما است و `to` آدرس قرارداد است. آرگومان `data` حاوی باری است که مشخص میکند کدام متد و با کدام آرگومان باید فراخوانی شود. This is where the [ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html) comes into play. The ABI is a JSON file that defines how to define and encode data for the EVM.
-
-The bytes of the payload defines which method in the contract is called. This is the first 4 bytes from the Keccak hash over the function name and its argument types, hex encoded. The multiply function accepts an uint which is an alias for uint256. This leaves us with:
-
-```javascript
-web3.sha3("multiply(uint256)").substring(0, 10)
-// "0xc6888fa1"
-```
-
-The next step is to encode the arguments. There is only one uint256, say, the value 6. The ABI has a section which specifies how to encode uint256 types.
-
-`int: enc(X)` is the big-endian two’s complement encoding of X, padded on the higher-order (left) side with 0xff for negative X and with zero > bytes for positive X such that the length is a multiple of 32 bytes.
-
-This encodes to `0000000000000000000000000000000000000000000000000000000000000006`.
-
-Combining the function selector and the encoded argument our data will be `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
-
-This can now be sent to the node:
-
-```bash
-curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545
-{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"}
-```
-
-Since a transaction was sent, a transaction hash was returned. Retrieving the receipt gives:
-
-```javascript
-{
- blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
- blockNumber: 268,
- contractAddress: null,
- cumulativeGasUsed: 22631,
- gasUsed: 22631,
- logs: [{
- address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d",
- blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
- blockNumber: 268,
- data: "0x000000000000000000000000000000000000000000000000000000000000002a",
- logIndex: 0,
- topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"],
- transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
- transactionIndex: 0
- }],
- transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
- transactionIndex: 0
-}
-```
-
-The receipt contains a log. This log was generated by the EVM on transaction execution and included in the receipt. The `multiply` function shows that the `Print` event was raised with the input times 7. Since the argument for the `Print` event was a uint256 we can decode it according to the ABI rules which will leave us with the expected decimal 42. Apart from the data it is worth noting that topics can be used to determine which event created the log:
-
-```javascript
-web3.sha3("Print(uint256)")
-// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"
-```
-
-This was just a brief introduction into some of the most common tasks, demonstrating direct usage of the JSON-RPC.
-
-## موضوعات مرتبط {#related-topics}
-
-- [JSON-RPC specification](http://www.jsonrpc.org/specification)
-- [گرهها و کاربرها](/developers/docs/nodes-and-clients/)
-- [رابط کاربری جاوا اسکریپت](/developers/docs/apis/javascript/)
-- [وب سرویسهای بکاند](/developers/docs/apis/backend/)
-- [کلاینتهای اجرا](/developers/docs/nodes-and-clients/#execution-clients)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
deleted file mode 100644
index 20d205fb783..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md"
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: جستجوگرهای بلوک
-description: یک معرفی دربارهی جستجوگرهای بلوک، پورتال شما یه جهان دادههای زنجیره بلوکی، که در آن میتوانید اطلاعاتی دربارهی تراکنشها، حسابها، قراردادها و بیشتر را درخواست کنید.
-lang: fa
-sidebarDepth: 3
----
-
-جستجوگرهای بلوک پورتال شما به دادههای اتریوم هستند. میتوانید از آنها برای مشاهده دادههای واقعی در مورد بلوکها، تراکنشها، اعتبارسنجیها، حسابها و سایر فعالیتهای زنجیرهای استفاده کنید.
-
-## پیشنیازها {#prerequisites}
-
-شما باید مفاهیم اساسی اتریوم را درک کنید تا بتوانید داده هایی را که یک جستجوگر بلوک به شما می دهد، درک کنید. با [کعرفی اتریوم](/developers/docs/intro-to-ethereum/) آغاز کنید.
-
-## سرویسها {#services}
-
-- [Etherscan](https://etherscan.io/) - _به زبانهای چینی، کرهای، روسی و ژاپنی هم در دسترس است_
-- [3xpl](https://3xpl.com/ethereum)
-- [Beaconcha.in](https://beaconcha.in/)
-- [Blockchair](https://blockchair.com/ethereum) - _همچنین به زبانهای اسپانیایی، فرانسوی، ایتالیایی، آلمانی، پرتغالی، روسی، چینی و فارسی در دسترس است_
-- [Blockscout](https://eth.blockscout.com/)
-- [Chainlens یا چین لنز](https://www.chainlens.com/)
-- [مرورگر بلوک DexGuru](https://ethereum.dex.guru/)
-- [Etherchain](https://www.etherchain.org/)
-- [Ethernow یا اترنو](https://www.ethernow.xyz/)
-- [Ethplorer](https://ethplorer.io/) - _به زبانهای چینی، اسپانیایی، فرانسوی، ترکیهای، روسی، کرهای و ویتنامی در دسترسی است_
-- [EthVM](https://www.ethvm.com/)
-- [OKLink](https://www.oklink.com/eth)
-- [Rantom](https://rantom.app/)
-
-## ابزارهای متن باز {#open-source-tools}
-
-- [Otterscan](https://otterscan.io/)
-- [اتراسکن-کند](https://github.com/woxjro/lazy-etherscan)
-
-## دادهها {#data}
-
-اتریوم از نظر طراحی شفاف است، بنابراین همه چیز قابل تأیید است. جسنجوگران بلوک یک رابط برای دریافت این اطلاعات ارائه می دهند. و این هم برای شبکه اصلی اتریوم و هم برای شبکه های آزمایشی است در صورتی که به آن داده نیاز داشته باشید. داده ها در اتریوم به داده های اجرا و اجماع دسته بندی میشوند. داده اجرا به داده ای که در یک بلوک مشخص اجرا شده است اشاره میکند. داده اجماع به بلوک ها و اعتبارسنجانی که آن ها را پیشنهاد داده اند اشاره میکند.
-
-در اینجا خلاصه ای از انواع داده هایی است که می توانید از جستجوگر بلوک دریافت کنید.
-
-### دادههای اجرا {#execution-data}
-
-بلوکهای جدید تقریبا هر 12 ثانیه به اتریوم اضافه میشوند (مگر اینکه یک پیشنهاد دهنده نوبتش را از دست بدهد)، بنابراین یک جریان تقریباً ثابت از دادهها وجود دارد که به مرورگر های بلوک اضافه میشود. بلوک ها حاوی بسیاری از داده های مهم هستند که ممکن است برای شما مفید باشد:
-
-**دادههای استاندارد**
-
-- Block height - شماره بلوک و طول زنجیره بلوکی (بر حسب بلوک) هنگام ایجاد بلوک فعلی
-- Timestamp - زمانی که بلوک جدید پیشنهاد شد
-- Transactions- تعداد تراکنشهایی که درون بلوک هستند
-- Fee recipient - آدرسی که انعام تراکنش های بلوک به آن منتقل میشود
-- Block Reward - مقدار اتری که به اعتبارسنج پیشنهاد دهنده ی بلوک داده میشود
-- Size- اندازه داده های داخل بلوک (اندازه گیری شده به واحد بایت)
-- Gas used - کل واحدهای اتر مصرف شده توسط تراکنشها در بلوک
-- Gas limit - مجموع حد گس تعیین شده توسط تراکنش هات در بلوک
-- Base fee per gas - کمترین گازبها لازم برای هر تراکنش برای قرار گیری در این بلوک
-- Burnt fees - مقدار اتر سوزانده شده در این بلوک
-- داده اضافی - هر داده اضافی که سازنده در بلوک گنجانده است
-
-**دادههای پیشرفته**
-
-- Hash - هش رمزنگاری که نشان دهنده سربرگ بلوک (شناسه منحصر به فرد بلوک) است
-- Parent hash - هش بلوکی که قبل از بلوک فعلی آمده است
-- StateRoot - هش ریشهی درخت مرکل که کل وضعیت سیستم را ذخیره می کند
-
-### گاز {#gas}
-
-نه تنها جستجوگران بلوک اطلاعاتی در مورد مصرف گاز در تراکنشها و بلوکها به شما میدهند، بلکه برخی اطلاعاتی درباره قیمتهای فعلی گاز شبکه به شما میدهند. این به شما کمک میکند تا استفاده از شبکه را درک کنید، تراکنشهای ایمن را ارسال کنید و بیش از حد برای گاز خرج نکنید. به دنبال رابطهای نرمافزاری باشید که می توانند به شما کمک کنند این اطلاعات را در رابط محصول خود دریافت کنید. داده های مخصوص گاز شامل موارد زیر است:
-
-- واحدهای تخمینی گاز مورد نیاز برای یک تراکنش ایمن اما کند (+ قیمت و مدت تخمینی)
-- واحدهای تخمینی گاز مورد نیاز برای یک تراکنش میانگین (+ قیمت و مدت تخمینی)
-- واحدهای تخمینی گاز مورد نیاز برای یک تراکنش سریع (+ قیمت و مدت تخمینی)
-- میانگین زمان تایید بر اساس قیمت گاز
-- قراردادهایی که گاز مصرف می کنند - به عبارت دیگر، محصولات محبوبی که در شبکه به زیادی استفاده می شوند
-- حسابهایی که گاز مصرف میکنند - به عبارت دیگر، کاربران همیشگی و فعال شبکه
-
-### تراکنشها {#transactions}
-
-جستجوگران بلوک به مکانی رایج برای پیگیری روند تراکنش های افراد تبدیل شده اند. این به این دلیل است که سطح جزئیاتی که می توانید به دست آورید اطمینان بیشتری را ارائه می دهد. دادههای تراکنش شامل موارد زیر است:
-
-**دادههای استاندارد**
-
-- هش تراکنش - هشی که هنگامی تراکنش ثبت میشود ایجاد میشود
-- وضعیت - نشان دهنده این است که آیا تراکنش در حال انتظار است، شکست خورده یا موفقیت بوده است
-- بلوک - بلوکی که تراکنش در آن گنجانده شده است
-- مهر زمانی یا تایم استمپ - زمانی که یک تراکنش در یک بلوک پیشنهاد شده توسط اعتبارسنج گنجانده شد
-- From - آدرس حسابی که تراکنش را ارسال کرده است
-- To - آدرس گیرنده یا قرارداد هوشمندی که تراکنش با آن تعامل دارد
-- توکن های منتقل شده - لیستی از توکنهایی که به عنوان بخشی از تراکنش منتقل شده اند
-- ارزش- مقدار کل اتری که منتقل می شود
-- کارمزد تراکنش - مبلغ پرداختی به اعتبارسنج برای پردازش تراکنش (محاسبه بر اساس قیمت گس\*گس مصرف شده)
-
-**دادههای پیشرفته**
-
-- حد گاز – حداکثر تعداد واحدهای گازی که این تراکنش می تواند مصرف کند
-- گاز مصرفی - مقدار واقعی واحدهای گاز مصرف شده در تراکنش
-- قیمت گاز - قیمت تعیین شده برای هر واحد گاز
-- نانس - شمارهی تراکنش برای آدرس `from` (در ذهن داشته باشید که با 0 شروع میشود در نتیجه نانس شمارهی `۱۰۰` در واقع ۱۰۱امین تراکنشی است که توسط این حساب ثبت شدهاست)
-- داده های ورودی - هر گونه اطلاعات اضافی مورد نیاز تراکنش
-
-### حساب ها {#accounts}
-
-اطلاعات زیادی در مورد یک حساب وجود دارد که می توانید به آنها دسترسی داشته باشید. به همین دلیل است که اغلب توصیه می شود از چندین حساب استفاده کنید تا دارایی ها و ارزش شما به راحتی قابل ردیابی نباشد. همچنین راهحلهایی برای خصوصیتر کردن تراکنشها و فعالیت حسابها در حال توسعه است. اما در اینجا دادههایی وجود دارد که برای حسابها در دسترس است:
-
-**حسابهای کاربری**
-
-- آدرس حساب - آدرس عمومی که می توانید برای ارسال وجوه به آن استفاده کنید
-- موجودی اتر - مقدار اتر مرتبط با آن حساب
-- مقدار کل اتر - ارزش اتر
-- توکن ها – توکن های مرتبط با حساب و ارزش آنها
-- تاریخچه تراکنش - فهرستی از تمام تراکنش هایی که این حساب فرستنده یا گیرنده آن بوده است
-
-**قراردادهای هوشمند**
-
-حسابهای قرارداد هوشمند دارای تمام دادههایی هستند که یک حساب کاربری خواهد داشت، اما برخی از جستجوگران بلوک حتی برخی از اطلاعات کد را نیز نمایش میدهند. مثالهایی شامل:
-
-- سازنده قرارداد - آدرسی که قرارداد را در شبکهی اصلی پیاده کرده است
-- تراکنش ایجاد - تراکنشی که شامل پیادهسازی قرارداد در شبکهی اصلی می شود
-- کد منبع - کد solidity یا vyper قرارداد هوشمند
-- ABI قرارداد - رابط باینری برنامه ی قرارداد -فراخوانی هایی که قرارداد انجام می دهد و داده های دریافت شده
-- کد ایجاد قرارداد - بایت کد کامپایل شده قرارداد هوشمند - زمانی ایجاد می شود که یک قرارداد هوشمند نوشته شده در Solidity یا Vyper و غیره را کامپایل می کنید.
-- رویدادهای قرارداد- تاریخچه ای از توابع فراخوانده شدن در قرارداد هوشمند-به زبان ساده روشی که نشان میدهد قرارد داد چگونه و چقدر استفاده شده
-
-### توکن ها {#tokens}
-
-توکنها نوعی قرارداد هستند، بنابراین دادههایی مشابه قرارداد هوشمند خواهند داشت. اما از آنجایی که ارزش دارند و قابل معامله هستند، نقاط داده اضافی دارند:
-
-- نوع - خواه ERC-20، ERC-721 یا استاندارد توکن دیگری باشند
-- قیمت - اگر ERC-20 باشند، ارزش بازار فعلی آن ها نمایش داده میشود
-- ارزش بازار - اگر ERC-20 باشند، ارزش بازار کلی دارند (محاسبه شده با قیمت*کل عرضه)
-- عرضه کل - تعداد توکن های در گردش
-- مالکان- تعداد آدرس هایی که توکن را در خود نگه می دارند
-- Transfers - تعداد دفعاتی که توکن بین حساب ها منتقل شده است
-- تاریخچه تراکنش - تاریخچه تمام تراکنش های یک توکن
-- آدرس قرارداد - آدرس توکنی که در شبکهی اصلی مستقر شده است
-- اعشار - توکن های ERC-20 قابل تقسیم هستند و دارای اعداد اعشاری هستند
-
-### شبکه {#network}
-
-بعضی از داده های بلوک ها مربوط به سلامتی کلی اتریوم است.
-
-- کل تراکنش ها – تعداد تراکنش ها از زمان ایجاد اتریوم
-- تراکنش در ثانیه - تعداد تراکنش های قابل پردازش در یک ثانیه
-- قیمت اتر - ارزش فعلی 1 اتر
-- کل عرضه اتر - تعداد اتر در گردش - به یاد داشته باشید که اتر جدید با ایجاد هر بلوک به شکل پاداش بلوک ایجاد می شود
-- ارزش بازار - محاسبه قیمت*عرضه کل
-
-## دادههای لایهی اجماع {#consensus-layer-data}
-
-### ایپاک {#epoch}
-
-به دلایل امنیتی، در انتهای هر ایپاک یک کمیته تصادفی از اعتبارسنجان انتخاب میشود ( هر 6.4 دقیقه). دادههای ایپاک شامل موارد زیر است:
-
-- شمارهی ایپاک
-- وضعیت قطعی - آیا ایپاک قطعی شده یا خیر (آری/نه)
-- زمان - زمانی که ایپاک به پایان رسیده است
-- تصدیق ها - تعداد تصدیقها در ایپاک(رای به بلوک های درون اسلات)
-- سپرده ها - تعداد سپرده های اتر که در ایپاک گنجانده شده است (اعتبارسنجان باید اتر را برای اعتبار سنجی سهامگذاری کنند)
-- Slashings - تعداد جریمه هایی که به پیشنهاد دهندگان بلوک ها یا تصدیق کنندگان داده می شود
-- مشارکت در رای گیری - مقدار اتر سهام گذاری شده که برای تصدیق بلوک ها استفاده می شود
-- اعتبارسنجان - تعداد اعتبارسنجان فعال در ایپاک
-- میانگین موجودی اعتبارسنجان - میانگین موجودی اعتبارسنجان فعال
-- اسلاتها - تعداد اسلاتهای درون ایپاک (اسلات شامل یک بلوک معتبر است)
-
-### اسلات {#slot}
-
-اسلاتها فرصتهایی برای ساخت بلوک هستند، دادههای در دسترس برای هر اسلات شامل موارد زیر است:
-
-- ایپاک - ایپاکی که اسلات در آن معتبر است
-- شمارهی اسلات
-- وضعیت - وضعیت اسلات (پیشنهاد شده/ از دست رفته)
-- زمان - برچسب زمان اسلات
-- پیشنهاد دهنده - اعتبارسنجی که بلوک را برای اسلات پیشنهاد کرده است
-- ریشهی بلوک - هش ریشهی درخت از بلوک بیکن
-- ریشهی پدر - هش بلوکی که پیش از این آمده است
-- ریشهی وضعیت - هش ریشهی درخت از وضعیت بیکن
-- امضا
-- آشکارسازی RanDAO
-- Graffiti - یک پیشنهاد دهنده بلوک می تواند پیامی به طول 32 بایت به پیشنهاد بلوک خود اضافه کند
-- دادههای اجرا
- - هش بلوک
- - میزان سپرده
- - ریشهی سپرده
-- تصدیق - تعداد تصدیقها برای بلوک درون این اسلات
-- سپردهها - تعداد سپردهها در طول این اسلات
-- خروج داوطلبانه - تعداد اعتبار سنج هایی که در طول اسلات خارج شدند
-- Slashings - تعداد جریمه هایی که به پیشنهاد دهندگان بلوک ها یا تصدیق کنندگان داده می شود
-- آرا - اعتبارسنجانی که برای این بلوک در این اسلات رای دادهاند
-
-### بلوکها {#blocks-1}
-
-اثبات-سهام زمان را به دوره اسلات و ایپاک تبدیل میکند. پس این معنی دادههای جدید است!
-
-- پیشنهاددهنده - اعتبارسنجی که به صورت الگوریتمی برای پیشنهاد بلوک جدید انتخاب شده است
-- ایپاک - ایپاکی که بلوک در آن پیشنهاد شده است
-- اسلات - اسلاتی که بلوک در آن پیشنهاد شده است
-- تصدیق ها- تعداد تصدیف های گنجانده شده در اسلات-تصدیق ها مانند رای هایی هستند که نشان میدهند بلوک آماده ثبت در زنجیره بیکن است
-
-### اعتبارسنج ها {#validators}
-
-اعتبار سنج ها مسئول پیشنهاد بلوک ها و تایید آنها در اسلات ها هستند.
-
-- شمارهی اعتبار سنج - شمارهی یکتایی که نشان یک اعتبارسنج است
-- موجودی فعلی - موجودی اعتبارسنج که شامل پاداشها است
-- موجودی موثر - موجودی اعتبارسنج که برای سهام گذاری استفاده میشود
-- درآمد - پاداشها و جریمههایی که اعتبارسنج دریافت کرده
-- وضعیت - آنلاین و فعال بودن یا نبودن اعتبار سنج در حال حاضر
-- اثربخشی تصدیق - میانگین زمانی که طول می کشد تا تصدیق های اعتبارسنج در زنجیره گنجانده شود
-- واجد شرایط بودن برای فعال سازی - تاریخ (و ایپاک) زمانی که اعتبارسنج برای اعتبارسنجی در دسترس قرار گرفت
-- فعال از – تاریخ (و ایپاک) که اعتبارسنج فعال شد
-- بلوک های پیشنهادی – بلوکی که اعتبارسنج پیشنهاد کرده است
-- تصدیق ها - تصدیق هایی که اعتبارسنج ارائه کرده است
-- سپرده ها - آدرس از، هش تراکنش، شماره بلوک، برچسب زمان، مبلغ و وضعیت سپرده گذاری که توسط اعتبارسنج انجام شده است
-
-### تصدیق {#attestations}
-
-تصدیق ها رای "بله" برای گنجاندن بلوک ها در زنجیره هستند. دادههای آنها مربوط به سوابق تصدیق و اعتبارسنج هایی است که تصدیق کردهاند
-
-- اسلات - اسلاتی که تصدیق در آن شکل گرفته است
-- شاخص کمیته - شاخص کمیته در اسلات مشخص شده
-- بیت های تجمیع شده - نشان دهنده جمع تصدیق همه اعتبار سنج های شرکت کننده در تصدیق است
-- اعتبار سنجان- اعتبار سنج هایی که تصدیق ارائه کردند
-- ریشه بلوک بیکن - به بلوکی اشاره می کند که اعتبار سنج ها آن را تصدیق می کنند
-- منبع - به آخرین ایپاک توجیه شده اشاره می کند
-- هدف - به مرز آخرین ایپاک اشاره می کند
-- امضا
-
-### شبکه {#network-1}
-
-داده های سطح بالای لایه اجماع شامل موارد زیر است:
-
-- ایپاک فعلی
-- اسلات فعلی
-- اعتبارسنجان فعال - تعداد اعتبارسنجان فعال
-- اعتبار سنجهای در انتظار - تعداد اعتبارسنج هایی که منتظر فعال شدن هستند
-- اتر سهامگذاری شده - میزان اتر سهامگذاریشده در شبکه
-- موجودی میانگین - میانگین موجودی اتر اعتبار سنجان
-
-## جستجوگرهای بلوک {#block-explorers}
-
-- [Etherscan](https://etherscan.io/) - یک مرورگر بلوک که میتوانید برای دریافت داده از شبکهی اصلی اتریوم و شبکهی آزمایشی Goerli از آن استفاده کنید
-- [3xpl](https://3xpl.com/ethereum) - یک اکسپلورر منبع باز اتریوم بدون آگهی که امکان دانلود مجموعه دادههای آن را فراهم میکند
-- [Beaconcha.in](https://beaconcha.in/) - یک مرورگر بلوک متن باز که میتوانید برای دریافت داده از شبکهی اصلی اتریوم از آن استفاده کنید
-- [Blockchair](https://blockchair.com/ethereum) - خصوصیترین جستجوگر اتریوم. همچنین برای مرتب کردن و فیلتر کردن دادهها (استخر حافظه)
-- [Etherchain](https://www.etherchain.org/) - یک مرورگر بلوک برای شبکهی اصلی اتریوم
-- [Ethplorer](https://ethplorer.io/) - یک مرورگر بلوک با تمرکز بر روی توکنها برای شبکهی اصلی اتریوم و شبکهی آزمایشی Kovan
-- [Rantom](https://rantom.app/)-یک مرورگر تراکنش متن باز که برای مرور جزئیات تراکنش های DeFi&NFT استفاده میشود
-- [Ethernow](https://www.ethernow.xyz/) - یک کاوشگر تراکنش در زمان واقعی که به شما امکان میدهد لایه پیش زنجیره اتریوم شبکه اصلی را ببینید
-
-## بیشتر بخوانید {#further-reading}
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [تراکنشها](/developers/docs/transactions/)
-- [حساب](/developers/docs/accounts/)
-- [شبکهها](/developers/docs/networks/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
deleted file mode 100644
index 1a4363d4f9f..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md"
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: داده ها و تحلیل ها
-description: چگونه می توانید تجزیه و تحلیل و داده های زنجیره ای را برای استفاده در برنامه های غیرمتمرکز خود دریافت کنید
-lang: fa
----
-
-## مقدمه {#Introduction}
-
-از آنجا که استفاده از شبکه همچنان در حال رشد است، مقدار فزاینده ای از اطلاعات ارزشمند در داده های زنجیره ای وجود خواهد داشت. از آنجا که حجم داده ها به سرعت افزایش می یابد، محاسبه و جمعآوری این اطلاعات برای گزارش یا هدایت یک برنامه غیرمتمرکز می تواند به فرآیندی زمانبر و تلاش سنگینی تبدیل شود.
-
-استفاده از ارائه دهندگان داده های موجود می تواند توسعه را تسریع کند، نتایج دقیق تری تولید کند و کارهای مداوم نگهداری را کاهش دهد. این امر یک تیم را قادر میسازد تا بر روی عملکرد اصلی پروژه خود تمرکز کند.
-
-## پیش نیاز ها {#prerequisites}
-
-شما باید مفهوم اصلی [جستجوگران بلوک](/developers/docs/data-and-analytics/block-explorers/) را درک کنید تا استفاده از آنها در زمینه تجزیه و تحلیل داده را بهتر درک کنید. علاوه بر این، با مفهوم [اندیس](/glossary/#index) آشنا شوید تا مزایایی که به طراحی سیستم اضافه میکنند را درک کنید.
-
-از نظر مبانی معماری، درک [رابط برنامهنویسی کاربردی](https://www.wikipedia.org/wiki/API) و [REST](https://www.wikipedia.org/ wiki/Representational_state_transfer)، حتی در تئوری نیز وجود دارد.
-
-## جستجوگرهای بلوک {#block-explorers}
-
-بسیاری از [کاوشگرهای بلوک](/developers/docs/data-and-analytics/block-explorers/) درگاههای [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) را پیشنهاد میکنند که به توسعهدهندگان امکان مشاهده دادهها در بلوکها، تراکنشها، اعتبارسنجها، حسابها و سایر فعالیتهای زنجیرهای را فراهم میکند.
-
-در این صورت توسعه دهندگان میتوانند این دادهها را پردازش و تبدیل کنند تا به کاربران خود بینش و تعاملات منحصر به فرد با [زنجیره بلوکی](/glossary/#blockchain) را بدهند. برای مثال،[Etherscan](https://etherscan.io) داده های اجرا و اجماع بلوک ها را هر 12 ثانیه ارائه میکند.
-
-## The Graph {#the-graph}
-
-[Graph Network](https://thegraph.com/) یک پروتکل شاخص ساز غیرمتمرکز برای سازماندهی داده های زنجیره بلوکی است. توسعه دهندگان می توانند به جای ساختن و مدیریت فروشگاه های داده غیر زنجیره ای و متمرکز برای جمعآوری داده های درون زنجیره ای، با The Graph برنامه های بدون سرور بسازند که به طور کامل بر روی زیرساخت های عمومی اجرا می شوند.
-
-با استفاده از [GraphQL](https://graphql.org/)، توسعهدهندگان میتوانند از هر یک از APIهای باز انتخابشده، که به عنوان sub-graph شناخته میشوند، پرس و جو کنند تا اطلاعات لازم را که برای راهاندازی برنامهی غیرمتمرکز خود نیاز دارند، به دست آورند. با پرس و جو از این نمودارهای فرعی نمایهشده، گزارشها و دادهها نه تنها مزایای عملکرد و مقیاسپذیری را دریافت میکنند، بلکه دقت ایجاد شده توسط اجماع شبکه را نیز دریافت میکنند. با اضافه شدن پیشرفتها و/یا زیر-گراف های جدید به شبکه، پروژههای شما میتوانند به سرعت برای استفاده از این پیشرفتها تکرار شوند.
-
-## تنوع کلاینتها
-
-[تنوع کلاینت](/developers/docs/nodes-and-clients/client-diversity/) برای سلامت کلی شبکه اتریوم مهم است زیرا در برابر اشکالات و سوء استفادهها انعطاف پذیری میکند. اکنون چندین داشبورد تنوع مشتری از جمله [clientdiversity.org](https://clientdiversity.org/)، [rated.network وجود دارد. ](https://www.rated.network)، [supermajority.info](https://supermajority.info//) و [Ethernodes](https://ethernodes.org/).
-
-## Dune Analytics {#dune-analytics}
-
-[Dune Analytics](https://dune.com/) دادههای بلاک چین را در جداول پایگاه داده رابطهای (PostgreSQL و DatabricksSQL) پیش پردازش میکند، به کاربران امکان میدهد با استفاده از SQL دادههای بلاک چین را جستجو کنند و داشبوردهایی بر اساس نتایج جستجو بسازند. دادههای زنجیرهای در ۴ جدول خام سازماندهی میشوند: `بلوکها`، `تراکنشها`، (رویداد) `گزارشها` و (تماس) `ردیابی`. قراردادها و پروتکلهای محبوب رمزگشایی شدهاند و هر کدام مجموعهای از جداول رویداد و فراخوانی خاص خود را دارند. این جداول با رویداد و فراخوان بیشتر پردازش میشوند و بر اساس نوع پروتکلها به جداول انتزاعی سازماندهی میشوند، به عنوان مثال دکس (dex)، وام، استیبل کوینها و غیره.
-
-## شبکه SubQuery {#subquery-network}
-
-[SubQuery](https://subquery.network/) پیشتاز در فهرستکردن دیتا است که به توسعهدهندگان APIهای سریع، قابل اعتماد، غیرمتمرکز و سفارشیشده برای پروژههای Web3 خود میدهد. SubQuery به توسعه دهندگان بیش از 165 اکوسیستم (از جمله اتریوم) با داده های فهرست شده غنی این توانایی را می دهد تا تجربیاتی ملموس و همه جانبه برای کاربران خود ایجاد کنند. شبکه SubQuery برنامه های غیرقابل توقف شما را با یک شبکه زیرساخت انعطاف پذیر و غیرمتمرکز توانمند می سازد. از جعبه ابزار توسعهدهنده بلاکچین SubQuery برای ساخت برنامههای Web3 در آینده، بدون صرف زمان برای ساختن یک Backend سفارشی برای فعالیتهای پردازش داده استفاده کنید.
-
-برای شروع، از [راهنمای شروع سریع اتریوم](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) دیدن کنید تا در عرض چند دقیقه در یک محیط داکر محلی برای آزمایش قبل از شروع کار در [سرویس مدیریت شده SubQuery](https://managedservice.subquery.network/) یا در [شبکه غیرمتمرکز SubQuery](https://app.subquery.network/dashboard) ایندکسینگ انجام شود.
-
-## Ethernow - برنامه دیتای استخر حافظه {#ethernow}
-[Blocknative](https://www.blocknative.com/) دسترسی آزاد به [آرشیو دیتای استخر حافظه](https://www.ethernow.xyz/mempool-data-archive) تاریخی اتریوم خود را فراهم میکند. این به محققان و پروژههای خوب جامعه امکان میدهد تا لایه پیش زنجیره اتریوم شبکه اصلی (Mainnet) را کشف کنند. مجموعه داده به طور فعال نگهداری میشود و جامعترین سابقه تاریخی رویدادهای تراکنش استخر حافظه در اکوسیستم اتریوم را نشان میدهد. جزئیات بیشتر در [Ethernow](https://www.ethernow.xyz/).
-
-## اطلاعات بیشتر {#further-reading}
-
-- [نمای کلی Graph Network](https://thegraph.com/docs/en/about/network/)
-- [زمین بازی درخواستهای Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current)
-- [نمونه کدهای رابط برنامه نویسی کاربردی در EtherScan](https://etherscan.io/apis#contracts)
-- [Beaconcha.in مرورگر زنجیره بیکن](https://beaconcha.in)
-- [مقدمات Dune](https://docs.dune.com/#dune-basics)
-- [راهنمای شروع کار SubQuery](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
deleted file mode 100644
index 65a9fa6ab1e..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md"
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: شبکه های توسعه
-description: مروری بر شبکه های توسعه و ابزارهای موجود برای کمک به ساخت برنامه های اتریومی.
-lang: fa
----
-
-هنگام ساختن یک برنامه اتریوم با قرارداد هوشمند، باید آن را در یک شبکه محلی اجرا کنید تا قبل از استقرار آن، نحوه عملکرد آن را ببینید.
-
-همانگونه که ممکن است برای توسعه وب یک سرور محلی را بر روی رایانه خود اجرا کنید، می توانید از یک شبکه توسعه نیز برای ایجاد یک نمونه زنجیره بلوکی محلی برای آزمایش برنامهی غیرمتمرکز خود استفاده کنید. این شبکههای توسعه اتریومی ویژگیهایی را ارائه میکنند که امکان تکرار اجرای بسیار سریعتری را نسبت به اجرا روی یک شبکهی تست عمومی فراهم میکنند (مثلاً برای دریافت اتر نیازی نیست با یک شبکهی تست سر و کار داشته باشید).
-
-## پیشنیازها {#prerequisites}
-
-شما می بایست پیش از فرو رفتن در شبکه های توسعه با مفهوم [اصول پشته اتریوم](/developers/docs/ethereum-stack/) و [شبکههای اتریوم](/developers/docs/networks/) آشنا باشید.
-
-## شبکه توسعه چیست؟ {#what-is-a-development-network}
-
-شبکه های توسعه اساساً کلاینت های اتریومی (پیادهسازی اتریوم) هستند که به طور خاص برای توسعه محلی طراحی شده اند.
-
-**چرا فقط یک گره استاندارد اتریومی را به صورت محلی اجرا نمی کنید؟**
-
-شما _میتوانید_ [یک گره را اجرا کنید](/developers/docs/nodes-and-clients/#running-your-own-node) اما از آنجایی که شبکههای توسعه بهمنظور توسعه ساخته شدهاند، اغلب دارای ویژگیهای مناسبی هستند مانند:
-
-- بهکارگیری قطعی زنجیره بلوکی محلی تان با داده ها (مانند حساب های دارای موجودی اتر)
-- تولید فوری بلوک با هر تراکنشی که دریافت میکند، به ترتیب و بدون تاخیر است
-- قابلیت گزارش دهی و اشکال زدایی بهبودیافته
-
-## ابزارهای موجود {#available-projects}
-
-**توجه**: اکثر [چارچوبهای توسعه](/developers/docs/frameworks/) دارای یک شبکه توسعه داخلی هستند. توصیه می کنیم با یک چارچوب برای [تنظیم محیط توسعه محلی خود](/developers/local-environment/) شروع کنید.
-
-### Ganache {#ganache}
-
-به سرعت یک زنجیره بلوکی شخصی اتریومی را راهاندازی کنید که میتوان از آن برای اجرای آزمایشها، اجرای دستورها، و بررسی وضعیت در هنگام کنترل نحوه عملکرد زنجیره استفاده کنید.
-
-Ganache هم یک برنامه دسکتاپ (Ganache UI) و هم یک ابزار خط فرمان (`ganache-cli`) ارائه می دهد. آن بخشی از مجموعه ابزار Truffle است.
-
-- [وب سایت](https://www.trufflesuite.com/ganache)
-- [گیت هاب](https://github.com/trufflesuite/ganache)
-- [مستندات](https://www.trufflesuite.com/docs/ganache/overview)
-
-### شبکه Hardhat {#hardhat-network}
-
-یک شبکه محلی اتریومی است که برای توسعه طراحی شده است. این به شما امکان می دهد قرارداد های خود را مستقر کنید، آزمایش های خود را اجرا کنید و کد خود را اشکال زدایی کنید.
-
-شبکه Hardhat که در بطن Hardhat است، یک محیط توسعه اتریوم برای حرفه ای هاست.
-
-- [وب سایت](https://hardhat.org/)
-- [گیت هاب](https://github.com/nomiclabs/hardhat)
-
-### بیکنچینهای محلی {#local-beacon-chains}
-
-برخی از کلاینت های اجماع، دارای ابزارهای داخلی برای چرخاندن بیکنچینهای محلی جهت اهداف آزمایشی هستند. دستورالعمل Lighthouse، Nimbus و Lodestar در دسترس است:
-
-- [شبکهی تست محلی برای Lodestar](https://chainsafe.github.io/lodestar/usage/local/)
-- [شبکهی تست محلی برای Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
-- [شبکهی تست محلی برای Nimbus](https://github.com/status-im/nimbus-eth1/blob/master/fluffy/docs/local_testnet.md)
-
-### زنجیره های آزمایش عمومی اتریوم {#public-beacon-testchains}
-
-همچنین دو زیرساخت آزمایش عمومی در اتریوم وجود دارند: Goerli و Sepolia. شبکه تستی توصیه شده با پشتیبانی طولانی مدت گورلی (Goerli) است که هرکسی میتواند آن را تأیید کند. سپولیا (Sepolia) یک زنجیره جدیدتر و کوچکتر است که همچنین انتظار میرود برای آینده قابل پیش بینی حفظ شود، با یک مجموعه اعتبار سنج مجاز (به این معنی که دسترسی عمومی به اعتبارسنجهای جدید در این شبکه آزمایشی وجود ندارد). انتظار می رود زنجیره روپستن (Ropsten) در سهماهه چهارم 2022 منسوخ شود و زنجیره رینکبی (Rinkeby) در Q2/Q3 2023 منسوخ شود.
-
-- [لانچپد سهامگذاری Goerli](https://goerli.launchpad.ethereum.org/)
-- [Ropsten, Rinkeby & Kiln Deprecation Announcement](https://blog.ethereum.org/2022/06/21/testnet-deprecation)
-
-### بسته کورتوسیس اتریوم {#kurtosis}
-
-کورتوسیس (Kurtosis) یک سیستم توسعهدهی برای محیطهای آزمایشی چندکانتینری است که به توسعهدهندگان این امکان را میدهد تا نمونههای تکرارپذیر شبکههای بلاکچین را به صورت محلی بچرخانند.
-
-بسته کورتوسیس اتریوم را می توان برای نمونه سازی سریع یک شبکه آزمایشی پارامتر پذیر، بسیار مقیاس پذیر، و شبکهی تست خصوصی اتریوم روی Docker یا Kubernetes استفاده کرد. این بسته از کلیه کلاینت های اصلی لایه اجرا (EL) و لایه اجماع (CL) پشتیبانی می کند. کوتسیس (Kurtosis) با ظرافت تمام نقشهبرداریهای پورت محلی و اتصالات خدماتی را برای یک شبکه نماینده انجام میدهد تا در فرآیندهای اعتبارسنجی و تست مربوط به زیرساخت هسته اتریوم استفاده شود.
-
-- [بسته شبکه اتریوم](https://github.com/kurtosis-tech/ethereum-package)
-- [وب سایت](https://www.kurtosis.com/)
-- [گیت هاب](https://github.com/kurtosis-tech/kurtosis)
-- [اسناد](https://docs.kurtosis.com/)
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [چارچوبهای توسعه](/developers/docs/frameworks/)
-- [یک محیط توسعه محلی راهاندازی کنید](/developers/local-environment/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
deleted file mode 100644
index d544718e481..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md"
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: مقدمه ای بر پشته اتریوم
-description: مروری بر لایه های مختلف توده اتریوم و نحوه تطبیق آنها با یکدیگر.
-lang: fa
----
-
-مانند هر پشته نرم افزاری، مجموعه کامل "پشته اتریوم" بسته به اهداف شما از پروژه ای به پروژه دیگر متفاوت خواهد بود.
-
-با این حال، در اتریوم مؤلفههای اصلی وجود دارند که به ارائه یک مدل ذهنی برای نحوه تعامل نرم افزارهای کاربردی با زنجیره ی بلوکی اتریوم کمک می کند. درک لایه های پشته به شما کمک می کند تا راه های مختلف ادغام اتریوم در پروژه های نرم افزاری را درک کنید.
-
-## سطح ۱: ماشین مجازی اتریوم {#ethereum-virtual-machine}
-
-[ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) محیط اجرای قراردادهای هوشمند در اتریوم است. همه قراردادهای هوشمند و تغییرات وضعیت در زنجیره بلوکی اتریوم توسط [تراکنشها](/developers/docs/transactions/) اجرا میشوند. EVM تمام پردازش تراکنشهای شبکه اتریوم را انجام میدهد.
-
-مانند هر ماشین مجازی، EVM سطحی از انتزاع را بین کد در حال اجرا و ماشین اجرا کننده (گره اتریوم) ایجاد می کند. در حال حاضر EVM بر روی هزاران گره توزیع شده در سرتاسر جهان در حال اجرا است.
-
-در زیر روکش خود، EVM از مجموعه ای از دستورالعمل های کدگذاری برای اجرای وظایف خاص استفاده می کند. این کدگذاری ها (140 منحصربهفرد) به EVM اجازه میدهند [تورین کامل](https://en.wikipedia.org/wiki/Turing_completeness) باشد، به این معنی که EVM میتواند تقریباً هر چیزی را با توجه به منابع کافی محاسبه کند.
-
-بهعنوان یک توسعهدهنده dapp، نیازی به دانستن چیزهای زیادی در مورد EVM ندارید، به غیر از وجود آن و اینکه بهطور قابلاطمینانی تمام برنامههای کاربردی موجود در اتریوم را بدون فوت وقت تأمین میکند.
-
-## سطح ۲: قراردادهای هوشمند {#smart-contracts}
-
-[قراردادهای هوشمند](/developers/docs/smart-contracts/) برنامههای اجرایی هستند که بر روی زنجیره بلوکی اتریوم اجرا میشوند.
-
-قراردادهای هوشمند با استفاده از [زبانهای برنامهنویسی](/developers/docs/smart-contracts/languages/) خاص نوشته میشوند که در بایت کد EVM (دستورالعملهای ماشینی سطح پایین به نام کدهای عملیاتی) کامپایل میشوند.
-
-قراردادهای هوشمند نه تنها به عنوان کتابخانههای منبع باز عمل میکنند، بلکه اساساً سرویسهای API باز هستند که همیشه در حال اجرا هستند و نمیتوان آنها را حذف کرد. قراردادهای هوشمند عملکردهای عمومی را ارائه می دهند که کاربران و برنامه های کاربردی ([dapps](/developers/docs/dapps/)) ممکن است بدون نیاز به مجوز با آنها تعامل داشته باشند. هر برنامه کاربردی ممکن است با قراردادهای هوشمند مستقر شده برای ساختن عملکردی، مانند افزودن [فیدهای داده](/developers/docs/oracles/) یا برای پشتیبانی از مبادله توکن، ادغام شود. علاوه بر این، هر کسی میتواند قراردادهای هوشمند جدیدی را برای اتریوم به منظور افزودن قابلیتهای سفارشی برای رفع نیازهای برنامه خود مستقر کند.
-
-بهعنوان یک توسعهدهنده dapp، تنها در صورتی باید قراردادهای هوشمند بنویسید که میخواهید قابلیتهای سفارشی را در زنجیره بلوکی اتریوم اضافه کنید. ممکن است متوجه شوید که میتوانید تنها با ادغام با قراردادهای هوشمند موجود، به اکثر یا تمام نیازهای پروژه خود دست یابید، به عنوان مثال اگر میخواهید از پرداختهای پایدار ارزها پشتیبانی کنید یا تبادل غیرمتمرکز توکنها را فعال کنید.
-
-## سطح 3: گرههای اتریوم {#ethereum-nodes}
-
-برای اینکه برنامه بتواند با زنجیره بلوکی اتریوم تعامل داشته باشد، باید به یک [گره اتریوم](/developers/docs/nodes-and-clients/) متصل شود. اتصال به یک گره به شما امکان می دهد داده های زنجیره بلوکی را بخوانید و/یا تراکنش ها را به شبکه ارسال کنید.
-
-گرههای اتریوم رایانههایی هستند که نرمافزار اجرا میکنند - یک کلاینت اتریوم. یک کلاینت اجرایی از اتریوم است که تمام تراکنشهای هر بلوک را تأیید میکند و شبکه را ایمن نگه میدارد و دادهها را دقیق نگه میدارد. **گرههای اتریوم، زنجیره بلوکی اتریوم هستند**. آنها به طور جمعی وضعیت زنجیره بلوکی اتریوم را ذخیره می کنند و در مورد تراکنش ها برای تغییر وضعیت زنجیره بلوکی به توافق می رسند.
-
-با اتصال برنامه خود به یک گره اتریوم (از طریق [JSON-RPC API](/developers/docs/apis/json-rpc/))، برنامه شما می تواند داده ها را از زنجیره بلوکی بخواند (مانند موجودی حساب کاربر) و همچنین تراکنش های جدید را به شبکه پخش کند (مانند انتقال اتر مابین حساب های کاربری یا اجرای عملکرد قراردادهای هوشمند).
-
-## سطح 4: APIهای کلاینت اتریوم {#ethereum-client-apis}
-
-بسیاری از کتابخانه های راحتی (ساخته شده و نگهداری شده توسط جامعه متن باز اتریوم) به برنامه های کاربردی شما اجازه می دهند به زنجیره بلوکی اتریوم متصل شده و با آن ارتباط برقرار کنند.
-
-اگر برنامه رو به روی کاربر شما یک برنامه وب است، میتوانید با `نصب npm` یک [API جاوا اسکریپت](/developers/docs/apis/javascript/) را مستقیماً در فرانت اند خود داشته باشید. یا شاید شما در نظر دارید که این قابلیت را در سمت سرور، با استفاده از [Python](/developers/docs/programming-languages/python/) یا [جاوا](/developers/docs/ programming-languages/java/) API پیادهسازی کنید.
-
-در حالی که این APIها بخش ضروری پشته نیستند، اما پیچیدگی تعامل مستقیم با گره اتریوم را از بین می برند. همچنین توابع کاربردی فراهم میکنند (مثال: تبدیل اتر به GWEI) بنابراین به عنوان یک توسعه دهنده شما زمان کمتری صرف کارکردن با پیچیدگی های کاربر اتریوم، و زمان بیشتری صرف عملکرد برنامه خود میکنید.
-
-## سطح 5: برنامه های کاربر نهایی {#end-user-applications}
-
-در بالاترین سطح پشته، برنامه های کاربردی رو به روی کاربر قرار دارند. اینها برنامه های استانداردی هستند که امروزه به طور مرتب استفاده می کنید و می سازید: در درجه اول برنامه های وب و موبایل.
-
-روشی که شما این رابط های کاربری را توسعه می دهید اساساً بدون تغییر باقی می ماند. اغلب کاربران نیازی به دانستن اینکه برنامه ای که استفاده می کنند با استفاده از زنجیره بلوکی ساخته شده است، ندارند.
-
-## آماده انتخاب پشته خود هستید؟ {#ready-to-choose-your-stack}
-
-راهنمای ما را برای [تنظیم محیط توسعه محلی](/developers/local-environment/) برای برنامه اتریوم خود بررسی کنید.
-
-## بیشتر بخوانید {#further-reading}
-
-- [معماری یک برنامه Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - از _Preethi Kasireddy_
-
-_در مورد جامعه منابعی که به شما کمک می کنند بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
deleted file mode 100644
index a6aa8987b23..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md"
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: چارچوب های توسعه Dapp
-description: مزایای چارچوب ها را بررسی کنید و گزینه های موجود را مقایسه کنید.
-lang: fa
----
-
-## مقدمه ای بر چارچوب ها {#introduction-to-frameworks}
-
-ساختن یک dapp تمام عیار نیازمند بخش های مختلفی از تکنولوژی است. چارچوبهای نرمافزار بسیاری از ویژگیهای مورد نیاز را در بر دارند و یا سیستمهای افزونه آسانی را برای انتخاب ابزار مورد نظر شما ارائه میدهند.
-
-این چارچوب ها با قابلیت های بسیار گسترده در دسترس اند، قابلیت هایی چون:
-
-- ویژگی هایی برای ایجاد یک نمونه زنجیره بلوکی محلی.
-- قراردادهای هوشمند خود را نهایی کرده و تست کنید.
-- افزونههای توسعه کلاینت برای اینکه برنامه رو در روی کاربرتان را در همان پروژه/مخزن بسازید.
-- پیکربندی برای اتصال به شبکههای اتریوم و استقرار قراردادها، چه در یک نمونه در حال اجرا محلی یا یکی از شبکههای عمومی اتریوم.
-- توزیع غیرمتمرکز برنامه - ادغام با گزینه های ذخیرهسازی مانند IPFS.
-
-## پیشنیازها {#prerequisites}
-
-قبل از فرو رفتن در مباحث چارچوبها، توصیه میکنیم ابتدا مقدمه ما در مورد [دپها](/developers/docs/dapps/) و [پشته اتریوم](/developers/docs/ethereum-stack/) را مطالعه کنید.
-
-## چارچوب های موجود {#available-frameworks}
-
-**Foundry** - **_ابزار Foundry یک جعبه ابزار سریع، قابل حمل و ماژولار برای توسعه برنامه اتریوم است_**
-
-- [نصب Foundry](https://book.getfoundry.sh/)
-- [کتاب Foundry](https://book.getfoundry.sh/)
-- [گروه چت کامیونیتی Foundry در تلگرام](https://t.me/foundry_support)
-- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry)
-
-**Hardhat -** **_محیط توسعه اتریوم برای حرفه ای ها_**
-
-- [hardhat.org](https://hardhat.org)
-- [گیت هاب](https://github.com/nomiclabs/hardhat)
-
-**Ape -** **_ابزار توسعه قرارداد هوشمند برای Pythonistas، دانشمندان داده، و حرفه ای های امنیتی._**
-
-- [مستندات](https://docs.apeworx.io/ape/stable/)
-- [گیت هاب](https://github.com/ApeWorX/ape)
-
-**Web3j -** **_پلتفرمی برای توسعه برنامههای بلاک چین در JVM_**
-
-- [صفحه اصلی](https://www.web3labs.com/web3j-sdk)
-- [اسناد](https://docs.web3j.io)
-- [گیت هاب](https://github.com/web3j/web3j)
-
-**ethers-kt -** **_Async، کتابخانه کاتلین/جاوا/اندروید با عملکرد بالا برای بلاک چینهای مبتنی بر ماشین مجازی اتریوم_**
-
-- [گیت هاب](https://github.com/Kr1ptal/ethers-kt)
-- [مثالها](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
-- [دیسکورد](https://discord.gg/rx35NzQGSb)
-
-**ایجاد برنامه Eth -** **_برنامه های مجهز به اتریوم را با یک دستور ایجاد کنید. با ارائه طیف گسترده ای از چارچوب های رابط کاربری و قالب های DeFi برای انتخاب ارائه می شود._**
-
-- [گیت هاب](https://github.com/paulrberg/create-eth-app)
-- [قالب ها](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
-
-**Scaffold-Eth -** **_Ethers.js + Hardhat + React کامپوننتها و قلابها برای web3: همه چیزهایی که برای شروع به منظور ساختن برنامههای غیرمتمرکز با هوش پیمانها نیاز دارید_**
-
-- [گیت هاب](https://github.com/scaffold-eth/scaffold-eth-2)
-
-**Tenderly -** **_پلتفرم توسعه Web3 که به توسعه دهندگان بلاکچین امکان می دهد قراردادهای هوشمند را بسازند، آزمایش کنند، رفع باگ کنند، نظارت کنند و اجرا کنند و dapp UX را بهبود بخشند._**
-
-- [وب سایت](https://tenderly.co/)
-- [اسناد](https://docs.tenderly.co/ethereum-development-practices)
-
-**The Graph -** **_گرافی برای جستجوی موثر دادههای بلاک چین_**
-
-- [وب سایت](https://thegraph.com/)
-- [آموزش](/developers/tutorials/the-graph-fixing-web3-data-querying/)
-
-**Alchemy** **_پلتفرم توسعه اتریوم_**
-
-- [alchemy.com](https://www.alchemy.com/)
-- [گیت هاب](https://github.com/alchemyplatform)
-- [دیسکورد](https://discord.com/invite/alchemyplatform)
-
-**NodeReal -** **_پلتفرم توسعه اتریوم._**
-
-- [Nodereal.io](https://nodereal.io/)
-- [گیت هاب](https://github.com/node-real)
-- [دیسکورد](https://discord.gg/V5k5gsuE)
-
-**Thirdweb SDK -** **_برنامههای Web3 بسازید که میتوانند با قراردادهای هوشمند شما با استفاده از SDK و CLI قدرتمند ما تعامل داشته باشند._**
-
-- [اسناد](https://portal.thirdweb.com/sdk/)
-- [گیت هاب](https://github.com/thirdweb-dev/)
-
-**Chainstack -** **_پلتفرم توسعه Web3 (اتریوم و سایرین)_**
-
-- [chainstack.com](https://www.chainstack.com/)
-- [گیتهاب](https://github.com/chainstack)
-- [دیسکورد](https://discord.gg/BSb5zfp9AT)
-
-**Crossmint -** **_پلتفرم توسعه Web3 سطح سازمانی، که به شما امکان میدهد برنامههای NFT را بر روی تمام زنجیرههای اصلی EVM Chains (و سایرین) بسازید._**
-
-- [وب سایت](https://www.crossmint.com)
-- [اسناد](https://docs.crossmint.com)
-- [دیسکورد](https://discord.com/invite/crossmint)
-
-**Brownie -** **_محیط توسعه مبتنی بر پایتون و چارچوب آزمایشی._**
-
-- [اسناد](https://eth-brownie.readthedocs.io/en/latest/)
-- [گیت هاب](https://github.com/eth-brownie/brownie)
-- **براونی در حال حاضر نگهداری نمی شود**
-
-**Truffle -** **_یک محیط توسعه، چارچوب آزمایش، خط لوله ساخت و ابزارهای دیگر. _**
-
-- [trufflesuite.com](https://www.trufflesuite.com/)
-- [گیت هاب](https://github.com/trufflesuite/truffle)
-- **توسعه Truffle به پایان رسیده است** - [بیشتر بخوانید](https://twitter.com/trufflesuite/status/1704946902393860589?t=NlIWeLTbBSAaJmS5uUAhSA&s=19)
-
-**OpenZeppelin SDK -** **_ابزارهای نهایی برای قرارداد هوشمند: مجموعه ای از ابزارهایی که به شما در توسعه، کامپایل، ارتقاء، استقرار و تعامل با قرارداد هوشمند کمک می کند._**
-
-- [OpenZeppelin SDK](https://openzeppelin.com/sdk/)
-- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-sdk)
-- [تالار گفتگو](https://forum.openzeppelin.com/c/support/17)
-- **توسعه OpenZeppelin SDK به پایان رسیده است**
-
-**Catapulta -** **_ابزار استقرار قراردادهای هوشمند چند زنجیرهای، تأیید خودکار در کاوشگرهای بلوک، پیگیری قراردادهای هوشمند مستقر شده و اشتراکگذاری گزارشهای استقرار، استفاده آسان برای پروژههای Foundry و Hardhat. _**
-
-- [وب سایت](https://catapulta.sh/)
-- [اسناد](https://catapulta.sh/docs)
-- [Github](https://github.com/catapulta-sh)
-
-**Covalent-** **_APIهای بلاک چین غنی شده برای بیش از 200 زنجیره._**
-
-- [covalenthq.com](https://www.covalenthq.com/)
-- [اسناد](https://www.covalenthq.com/docs/api/)
-- [گیت هاب](https://github.com/covalenthq)
-- [دیسکورد](https://www.covalenthq.com/discord/)
-
-**Wake -** **_چارچوب همهکاره پایتون برای آزمایش قراردادها، فازینگ، پیادهسازی، اسکن آسیبپذیری و پیمایش کد._**
-
-- [صفحه اصلی](https://getwake.io/)
-- [اسناد](https://ackeeblockchain.com/wake/docs/latest/)
-- [گیت هاب](https://github.com/Ackee-Blockchain/wake)
-- [افزونه VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [یک محیط توسعه محلی راهاندازی کنید](/developers/local-environment/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
deleted file mode 100644
index b0aa291f7f6..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md"
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: محیطهای توسعه جامع (IDEs)
-description:
-lang: fa
----
-
-وقتی نوبت به راهاندازی [محیط توسعه یکپارچه (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) می رسد، برنامه نویسی برنامه های کاربردی در اتریوم مشابه برنامه نویسی هر پروژه نرم افزاری دیگری است. گزینه های زیادی برای انتخاب وجود دارد، بنابراین در نهایت، IDE یا ویرایشگر کد را انتخاب کنید که به بهترین وجه مطابق با ترجیحات شما باشد. به احتمال زیاد بهترین انتخاب IDE برای توسعه اتریوم، IDE است که قبلاً برای توسعه نرمافزار سنتی استفاده می کردید.
-
-## IDE های مبتنی بر وب {#web-based-ides}
-
-اگر می خواهید قبل از اینکه [محیط توسعه محلی را راهاندازی کنید](/developers/local-environment/) با کد کار کنید، این برنامههای وب برای توسعه قراردادهای هوشمند اتریوم سفارشی سازی شدهاند.
-
-**[ریمیکس](https://remix.ethereum.org/)** - **_IDE مبتنی بر وب با تجزیه و تحلیل استاتیک داخلی و یک ماشین مجازی آزمایشی بلاک چین است_**
-
-- [مستندات](https://remix-ide.readthedocs.io/en/latest/#)
-- [گیتر](https://gitter.im/ethereum/remix)
-
-**[ChainIDE](https://chainide.com/)** - **_یک IDE چند زنجیرهای مبتنی بر ابر_**
-
-- [مستندات](https://chainide.gitbook.io/chainide-english-1/)
-- [تالار راهنما](https://forum.chainide.com/)
-
-**[رپلیت (Replit)(Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - < strong x-id="1">_یک محیط توسعه قابل تنظیم برای اتریوم با بارگذاری مجدد، بررسی خطا و پشتیبانی درجه یک شبکه آزمایشی است_
-
-- [مستندات](https://docs.replit.com/)
-
-**[سندباکس تندرلی](https://sandbox.tenderly.co/)** - **_یک محیط نمونهسازی سریع که در آن میتوانید قراردادهای هوشمند را در مرورگر با استفاده از سالیدیتی و جاوا اسکریپت بنویسید، اجرا و اشکال زدایی کنید_**
-
-**[EthFiddle](https://ethfiddle.com/)** - **_IDE مبتنی بر وب که به شما امکان میدهد قرارداد هوشمند خود را بنویسید، کامپایل و اشکالزدایی کنید_**
-
-- [گیتر](https://gitter.im/loomnetwork/ethfiddle)
-
-## IDEهای Desktop {#desktop-ides}
-
-اکثر IDE های بهوجود آمده افزونه هایی هستند که برای بهبود تجربه توسعه اتریوم ساخته اند. حداقل، آنها برجسته سازی ترکیبی را برای [زبان های قراردادهای هوشمند](/developers/docs/smart-contracts/languages/) ارائه می دهند.
-
-**ویژوال استودیو کد -****_یک میان پلتفرم حرفهای با پشتیبانی رسمی اتریوم_**
-
-- [Visual Studio Code](https://code.visualstudio.com/)
-- [کارگاه زنجیره بلوکی Azure](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-azure-blockchain.azure-blockchain-workbench?tab=Overview)
-- [نمونه کدها](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
-- [گیتهاب](https://github.com/microsoft/vscode)
-
-**Atom -** **_یک ویرایشگر متن قابل هک برای قرن بیست و یکم_**
-
-- [Atom](https://atom.io/)
-- [گیتهاب](https://github.com/atom)
-- [بستههای اتریوم](https://atom.io/packages/search?utf8=%E2%9C%93&q=keyword%3Aethereum&commit=Search)
-
-**IDEهای JetBrains (IntelliJ IDEA, etc.) -** **_ابزارهای ضروری برای توسعه دهندگان و تیم های نرم افزار_**
-
-- [JetBrains](https://www.jetbrains.com/)
-- [گیتهاب](https://github.com/JetBrains)
-- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
-
-**Remix Desktop -** **_Remix IDE را بر روی کامپیوتر خود تجربه کنید_**
-
-- [دانلود](https://github.com/ethereum/remix-desktop/releases)
-- [گیتهاب](https://github.com/ethereum/remix-desktop)
-
-## پلاگین ها و افزونه ها {#plugins-extensions}
-
-- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - زبان اتریوم Solidity برای Visual Studio Code
-- [سالیدیتی+ هاردهت برای ویاس کد](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) -پشتیبانی سالیدیتی و هاردهت توسط تیم هاردهت
-- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - فرمت دهنده کد با استفاده از Prettier
-
-## بیشتر بخوانید {#further-reading}
-
-- [IDE های اتریوم](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- لیست IDEهای اتریوم آلکمی_
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
deleted file mode 100644
index 43e1e077fd6..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md"
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان Dart
-description: نحوه توسعه اتریوم با استفاده از زبان برنامه نویسی Dart را بیاموزید
-lang: fa
-incomplete: true
----
-
-## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-## آموزشها {#tutorials}
-
-- [Flutter و زنجیره بلوکی - برنامهی غیرمتمرکز سلام دنیا!](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) شما را از تمام مراحل شروع عبور میدهد تا کار را آغاز کنید:
- 1. نصب [مجموعه توسعه Truffle](https://www.trufflesuite.com/)
- 2. نوشتن یک قرارداد هوشمند در [Solidity](https://soliditylang.org/)
- 3. نوشتن یک رابط کاربری در Dart
-- [ساخت دپ موبایل با Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) بسیار کوتاهتر است، که ممکن است بهتر باشد، اگر از قبل اصول اولیه را بدانید
-- اگر ترجیح میدهید با تماشای یک ویدیو چیزی را یاد بگیرید، میتوانید ویدیوی [ساخت اولین اپ فلاتر بلاکچین](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) را تماشا کنید که حدود یک ساعت طول میکشد
-- اگر حوصله ندارید، ممکن است [ساخت یک برنامه غیرمتمرکز زنجیره بلوکی با Flutter و Dart در اتریوم](https://www.youtube.com/watch?v=jaMFEOCq_1s) را ترجیح دهید، که فقط حدود بیست دقیقه است
-- [ادغام متامسک در اپ فلاتر با Web3Modal توسط WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - این ویدیوی کوتاه شما را با مراحل ادغام متامسک در اپ های فلاتر خود با کتابخانه [Web3Modal](https://pub.dev/packages/web3modal_flutter) توسط WalletConnect آشنا می کند
-- [Flutter Dapp Simple Wallet](https://youtu.be/JMfIBpuAhKA) و [First Flutter DApp - Solidity, Truffle, Ganache](https://youtu.be/bHw2gQZxJ_s) - این ویدیوها نحوه ساخت دپ های ساده در Flutter با استفاده از Truffle و Ganache را نشان می دهند
-- [Mobile Blockchain Developer Bootcamp Course With Solidity & Flutte](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - لیست پخش دورههای کامل توسعهدهنده بلاکچین تلفن همراه
-
-## کار با کلاینت های اتریوم {#working-with-ethereum-clients}
-
-از اتریوم می توانید برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapp) که از مزایای فناوری مبتنی بر رمزارز و زنجیره بلوکی استفاده می کنند، استفاده کنید. حداقل دو کتابخانه در حال حاضر برای Dart جهت استفاده از [JSON-RPC API](/developers/docs/apis/json-rpc/) برای اتریوم وجود دارد.
-
-1. [Web3dart از simonbutler.eu](https://pub.dev/packages/web3dart)
-1. [Ethereum 5.0.0 از darticulate.com](https://pub.dev/packages/ethereum)
-
-همچنین کتابخانههای دیگری وجود دارند که به شما امکان میدهند آدرسهای خاص اتریوم را دستکاری کنید یا به شما امکان میدهند قیمت ارزهای دیجیتال مختلف را بازیابی کنید. [میتوانید فهرست کامل را اینجا ببینید](https://pub.dev/dart/packages?q=ethereum).
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
deleted file mode 100644
index 6ee6efd4174..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md"
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان Delphi
-description: نحوه توسعه اتریوم با استفاده از زبان برنامه نویسی Delphi را بیاموزید
-lang: fa
-incomplete: true
----
-
-
-
-نحوه توسعه اتریوم با استفاده از زبان برنامه نویسی Delphi را بیاموزید
-
-
-
-از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در Ethereum مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
-
-برنامههای غیر متمرکز را بر روی اتریوم ایجاد کنید و با استفاده از زبان برنامه نویسی Delphi با قراردادهای هوشمند تعامل کنید!
-
-## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
-
-**اولین قدم های خود را برای ادغام Delphi با اتریوم بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [بیاموزید که چگونه رویه را گردآوری و استفاده کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## مراجع و پیوندهای سطح مبتدی {#beginner-references-and-links}
-
-**معرفی کتابخانه Delphereum**
-
-- [Delphereum چیست؟](https://github.com/svanas/delphereum/blob/master/README.md)
-- [اتصال Delphi به یک زنجیره بلوکی محلی (در حافظه)](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
-- [اتصال Delphi به شبکه اصلی اتریوم](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
-- [اتصال Delphi به قراردادهای هوشمند](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
-
-**آیا میخواهید فعلاً از تنظیمات رد شوید و مستقیماً به سراغ مثالها بروید؟**
-
-- [یک قرارداد هوشمند 3-دقیقه ای و Delphi - قسمت 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
-- [یک قرارداد هوشمند 3-دقیقه ای و Delphi - قسمت 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
-
-## مقالات سطح متوسط {#intermediate-articles}
-
-- [ایجاد یک امضای پیام امضا شده توسط اتریوم در Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
-- [انتقال اتر با Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
-- [انتقال توکن های ERC-20 با Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
-
-## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
-
-- [Delphi و Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
-- [QuikNode و Ethereum و Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
-- [Delphi و Ethereum Dark Forest](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
-- [در Delphi یک توکن را با نشانه دیگر عوض کنید](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
-
-به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/).
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
deleted file mode 100644
index 09e8a7c9919..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md"
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان NET.
-description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر NET. توسعه دهید
-lang: fa
-incomplete: true
----
-
-یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر NET. توسعه دهید
-
-از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و بلاکچین استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در Ethereum مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
-
-برنامه های غیرمتمرکز را بر روی اتریوم بسازید و با قراردادهای هوشمند با استفاده از ابزارها و زبان های پشته فناور مایکروسافت، در تعامل باشید - پشتیبانی از #F# ،#Visual Basic .Net، C بر روی ابزارهایی مانند VSCode و Visual Studio، در سراسر NET Framework/.NET Core/.NET Standard. در عرض چند دقیقه یک زنجیره بلوکی اتریومی را با استفاده از زنجیره بلوکی Azure مایکروسافت بر روی Azure مستقر کنید. عشق NET. را به اتریوم بیاورید!
-
-## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
-
-**اولین قدم های خود را برای ادغام NET. با اتریوم بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [بیاموزید که چگونه Solidity را کامپایل و به کار گیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## مراجع و پیوندهای سطح مبتدی {#beginner-references-and-links}
-
-**معرفی کتابخانه Nethereum و VS Code Solidity**
-
-- [Nethereum، شروع به کار](https://docs.nethereum.com/en/latest/getting-started/)
-- [نصب VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
-- [گردش کار یک برنامه نویس NET. برای ایجاد و فراخوانی قراردادهای هوشمند اتریوم](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
-- [یکپارچه سازی قراردادهای هوشمند با Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
-- [ارتباط با NET. و زنجیره بلوکی اتریوم قراردادهای هوشمند با Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933)، همچنین در [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80 %A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F %88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
-- [Nethereum - یک کتابخانه منبع باز یکپارچه سازی NET. برای زنجیره بلوکی](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
-- [نوشتن تراکنش های اتریوم در پایگاه داده SQL با استفاده از Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
-- [ببینید چگونه می توان به راحتی قراردادهای هوشمند اتریوم را با استفاده از #C و VisualStudio پیادهسازی کرد](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
-
-**آیا میخواهید فعلاً از تنظیمات رد شوید و مستقیماً به سراغ مثالها بروید؟**
-
-- [Playground](http://playground.nethereum.com/) - با اتریوم تعامل داشته باشید و نحوه استفاده از Nethereum را از طریق مرورگر یاد بگیرید.
- - استعلام موجودی حساب [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
- - موجودی قرارداد هوشمند ERC20 را جستجو کنید [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id /2004)
- - انتقال اتر به یک حساب [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id /2003)
- - ... و موارد دیگر!
-
-## مقالات سطح متوسط {#intermediate-articles}
-
-- [کتاب کار/ فهرست مثال های Nethereum](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
-- [زنجیره های آزمایشی توسعه خود را مستقر کنید](https://github.com/Nethereum/Testchains)
-- [VSCode Codegen افزونه ای برای Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
-- [یونیتی و اتریوم: چرا و چگونه](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
-- [ASP.NET Core Web API را برای dappهای اتریوم ایجاد کنید](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
-- [استفاده از Nethereum Web3 برای پیاده سازی یک سیستم ردیابی زنجیره تامین](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
-- [پردازش بلوک Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/)، با [نمونه زمین بازی C#](http://playground.nethereum.com/csharp/id/1025)
-- [جریان وب سوکت Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
-- [Kaleido و Nethereum](https://kaleido.io/kaleido-and-nethereum/)
-- [Quorum و Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
-
-## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
-
-- [Azure Key Vault و Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
-- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
-- [معماری مرجع Ujo Nethereum Backend](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
-
-## پروژه های NET.، ابزارها و سایر موارد سرگرمکننده {#dot-net-projects-tools-and-other-fun-stuff}
-
-- [Nethereum Playground](http://playground.nethereum.com/) - _قطعه کدهای Nethereum را در مرورگر کامپایل، ایجاد و اجرا کنید_
-- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _تولید کد Nethereum با رابط کاربری در Blazor_
-- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _کاوشگر سبک زنجیره بلوکی Wasm SPA و یک کیف پول ساده_
-- [موتور قوانین تجاری Wonka](https://docs.nethereum.com/en/latest/wonka/) - _یک موتور قوانین تجاری (برای هر دو پلتفرم NET. و پلتفرم اتریوم) که ذاتاً مبتنی بر ابر داده_ است
-- [Nethermind](https://github.com/NethermindEth/nethermind) - _یک کلاینت NET. Core اتریومی برای Linux، Windows، MacOs_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _توابعی برای کار با پایگاههای کد مرتبط با اتریوم_
-- [TestChains](https://github.com/Nethereum/TestChains) - _شبکههای توسعهدهنده NET. از پیش تنظیم شده برای پاسخ سریع (PoA)_
-
-به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/).
-
-## مشارکت کنندگان انجمن NET. {#dot-net-community-contributors}
-
-در Nethereum، ما بیشتر در [Gitter](https://gitter.im/Nethereum/Nethereum) وقت می گذرانیم، جایی که همه می توانند سؤال بپرسند/پاسخ دهند، کمک دریافت کنند یا فقط آرام باشند. با خیال راحت در [مخزن Nethereum GitHub](https://github.com/Nethereum) یک گفتگو انجام دهید یا مشکلی را باز کنید، یا فقط پروژههای جانبی/نمونهای که داریم را مرور کنید. همچنین میتوانید ما را در [Discord](https://discord.gg/jQPrR58FxX) پیدا کنید!
-
-اگر تازهوارد Nethermind هستید و برای شروع به کمک نیاز دارید، به [Discord](http://discord.gg/PaCMRFdvWT) ما بپیوندید. توسعه دهندگان ما آماده پاسخگویی به سوالات شما هستند. از باز کردن روابط عمومی یا طرح هر گونه مشکلی دریغ نکنید[مخزن Nethermind GitHub](https://github.com/NethermindEth/nethermind) را بررسی کنید.
-
-## سایر لیست های گردآوری شده {#other-aggregated-lists}
-
-[سایت رسمی Nethereum](https://nethereum.com/)
-[سایت رسمی Nethermind](https://nethermind.io/)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
deleted file mode 100644
index d4842051cfa..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md"
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان Go
-description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر Go توسعه دهید
-lang: fa
-incomplete: true
----
-
-یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر Go توسعه دهید
-
-از اتریوم برای ایجاد برنامه های غیرمتمرکز (یا "dapps") استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در اتریوم مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها غیرمتمرکز هستند، به این معنی که آنها در یک شبکه همتا به همتا اجرا می شوند و هیچ نقطه شکست واحدی در آنها وجود ندارد. هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریبا غیرممکن است. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود.
-
-## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**اولین قدم های خود را برای ادغام Go با اتریوم بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [بیاموزید که چگونه Solidity را کامپایل و بهکارگیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-- [آموزش قرارداد](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
-
-## مقاله ها و کتاب های مبتدی {#beginner-articles-and-books}
-
-- [انتخاب یک کلاینت اتریومی](https://www.trufflesuite.com/docs/truffle/reference/choosing-an-ethereum-client)
-- [شروع به کار با Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
-- [از Golang برای اتصال به اتریوم استفاده کنید](https://www.youtube.com/watch?v=-7uChuO_VzM)
-- [قراردادهای هوشمند اتریوم را با استفاده از Golang مستقر کنید](https://www.youtube.com/watch?v=pytGqQmDslE)
-- [راهنمای گام به گام تست و استقرار قراردادهای هوشمند اتریوم در Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
-- [eBook: توسعه اتریوم با Go](https://goethereumbook.org/) - _برنامههای اتریوم را با Go توسعه دهید_
-
-## مقالات و مستندات سطح متوسط {#intermediate-articles-and-docs}
-
-- [مستندات اتریومی Go](https://geth.ethereum.org/docs/) - _اسناد رسمی مربوط به اتریوم Golang _
-- [راهنمای برنامه نویس اریگون](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _راهنمای مصور از جمله درخت حالت، چند اثبات و پردازش تراکنش_
-- [Erigon و اتریوم بدون حالت](https://youtu.be/3-Mn7OckSus?t=394) - _کنفرانس انجمن اتریوم 2020 (EthCC 3)_
-- [Erigon: بهینه سازی مشتریان اتریوم](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_
-- [Go اتریوم GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
-- [ایجاد Dapp در Go با Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
-- [با Golang و Geth با شبکه خصوصی اتریوم کار کنید](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
-- [واحد تستی قراردادهای Solidity در اتریوم با Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
-- [مرجعی سریع برای استفاده از Geth به عنوان یک کتابخانه](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
-
-## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
-
-- [بک اند شبیه سازی شده GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
-- [برنامه های زنجیره ی بلوکی به عنوان یک سرویس با استفاده از اتریوم و Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
-- [ذخیرهسازی توزیع شده IPFS و Swarm در برنامه های زنجیره بلوکی اتریومی](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
-- [مشتریان موبایل: کتابخانه ها و گره های اتریوم Inproc](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
-- [Dapps بومی: به قراردادهای اتریوم متصل شوید](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
-
-## پروژه ها و ابزارهای Go {#go-projects-and-tools}
-
-- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _پیادهسازی رسمی پروتکل اتریوم با Go _
-- [تجزیه و تحلیل کد اتریوم Go](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _بررسی و تجزیه و تحلیل منبع کد اتریومی Go _
-- [Erigon](https://github.com/ledgerwatch/erigon) - _مشتق سریعتر Go Ethereum، با تمرکز بر گرههای بایگانی_
-- [Golem](https://github.com/golemfactory/golem) - _Golem در حال ایجاد یک بازار جهانی برای قدرت محاسباتی است_
-- [Quorum](https://github.com/jpmorganchase/quorum) - _اجازه اجرای اتریوم با پشتیبانی از حریم خصوصی داده_
-- [Prysm](https://github.com/prysmaticlabs/prysm) - _اجرای اتریوم 'Serenity' 2.0 Go_
-- [Eth Tweet](https://github.com/yep/eth-tweet) - _ توئیتر غیرمتمرکز: یک سرویس میکروبلاگینگ در حال اجرا بر روی زنجیره بلوکی اتریوم_
-- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _اجرای Golang و گسترش حداقل مشخصات پلاسمای قابل دوام_
-- [استخر استخراج اتریوم باز](https://github.com/sammy007/open-ethereum-pool) - _یک استخر استخراج اتریوم منبع باز_
-- [کیف پول اتریوم HD](https://github.com/miguelmota/go-ethereum-hdwallet) - _مشتقات کیف پول اتریوم HD در Go_
-- [Multi Geth](https://github.com/multi-geth/multi-geth) - _پشتیبانی از بسیاری از گونههای شبکههای اتریوم_
-- [Geth Light Client](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _پیادهسازی پروتکل فرعی Light Ethereum Geth _
-- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _اجرای کیف پول اتریوم و ابزارهای کاربردی ساده در Golang_
-- [کووالنت گولنگ SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _دسترسی کارآمد به دادههای بلاک چین از طریق Go SDK برای بیش از 200 بلاک چین امکانپذیر است_
-
-به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/)
-
-## مشارکت کنندگان انجمن Go {#go-community-contributors}
-
-- [Geth Discord](https://discordapp.com/invite/nthXNEv)
-- [Geth Gist](https://gitter.im/ethereum/go-ethereum)
-- [Gophers Slack](https://invite.slack.golangbridge.org/) - [کانال ethereum#](https://gophers.slack.com/messages/C9HP1S9V2)
-- [StackExchange - اتریوم](https://ethereum.stackexchange.com/)
-- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
-- [Ethereum Gitter](https://gitter.im/ethereum/home)
-- [Geth light Client Gitter](https://gitter.im/ethereum/light-client)
-
-## سایر لیست های گردآوری شده {#other-aggregated-lists}
-
-- [اتریوم فوقالعاده](https://github.com/btomashvili/awesome-ethereum)
-- [Consensys: فهرستی قطعی از ابزارهای توسعه دهنده اتریوم](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [منبع GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
deleted file mode 100644
index 7ebca2d9c5f..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md"
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: زبان های برنامه نویسی
-description:
-lang: fa
----
-
-یک تصور غلط رایج این است که توسعه دهندگان باید [قراردادهای هوشمند](/developers/docs/smart-contracts/) بنویسند تا بتوانند بر روی اتریوم بسازند. این نادرست است. یکی از زیباییهای شبکه و انجمن اتریوم این است که شما میتوانید تقریباً در هر زبان برنامهنویسی [شرکت](/community/) داشته باشید.
-
-اتریوم و جامعه آن از منبع باز استقبال می کنند. شما میتوانید پروژههای اجتماعی - پیادهسازی کلاینت، APIها، چارچوبهای توسعه، ابزارهای آزمایشی - را به زبانهای مختلف پیدا کنید.
-
-## زبان خود را انتخاب کنید {#data}
-
-زبان برنامه نویسی منتخب را برای پیدا کردن پروژه ها، منابع و جوامع مجازی انتخاب کنید:
-
-- [اتریوم برای توسعه دهندگان Dart](/developers/docs/programming-languages/dart/)
-- [اتریوم برای توسعه دهندگان Delphi](/developers/docs/programming-languages/delphi/)
-- [اتریوم برای توسعه دهندگان .NET](/developers/docs/programming-languages/dot-net/)
-- [اتریوم برای توسعه دهندگان Go](/developers/docs/programming-languages/golang/)
-- [اتریوم برای توسعه دهندگان جاوا](/developers/docs/programming-languages/java/)
-- [اتریوم برای توسعه دهندگان JavaScript](/developers/docs/programming-languages/javascript/)
-- [اتریوم برای توسعه دهندگان Python](/developers/docs/programming-languages/python/)
-- [اتریوم برای توسعه دهندگان رابی](/developers/docs/programming-languages/ruby/)
-- [اتریوم برای توسعه دهندگان Rust](/developers/docs/programming-languages/rust/)
-
-### اگر زبان من پشتیبانی نشود چه؟ {#other-lang}
-
-اگر میخواهید برای یک زبان برنامهنویسی اضافی به منابع پیوند دهید یا به یک جامعه مجازی اشاره کنید، میتوانید با [باز کردن یک مساله](https://github.com/ethereum/ethereum-org-website/issues/new/ select) صفحه جدیدی را درخواست کنید.
-
-اگر فقط می خواهید با استفاده از زبانی که در حال حاضر پشتیبانی نمی شود، کد بنویسید تا با زنجیره بلوکی ارتباط برقرار کنید می توانید از [رابط JSON-RPC](/developers/docs/apis/json-rpc/) برای اتصال به شبکه اتریوم استفاده کنید. هر زبان برنامه نویسی که بتواند از TCP/IP استفاده کند می تواند از این رابط استفاده کند.
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
deleted file mode 100644
index a613deab1d2..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md"
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان جاوا
-description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر جاوا توسعه دهید
-lang: fa
-incomplete: true
----
-
-یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر جاوا توسعه دهید
-
-از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در اتریوم مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
-
-## شروع کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**اولین قدم های خود را برای ادغام جاوا با اتریوم بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرسهای زیر را بررسی کنید [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/)
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین هوش پیمان خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [نحوه کامپایل و استقرار Solidity را بیاموزید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## کار با کلاینت های اتریوم {#working-with-ethereum-clients}
-
-نحوه استفاده از [Web3J](https://github.com/web3j/web3j) و Hyperledger Besu، دو کلاینت پیشرو جاوا اتریوم را بیاموزید
-
-- [اتصال به کلاینت اتریوم با Java، Eclipse و Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
-- [یک حساب اتریوم را با Java و Web3j مدیریت کنید](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
-- [از قرارداد هوشمند خود یک Java Wrapper ایجاد کنید](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
-- [تعامل با یک قرارداد هوشمند اتریومی](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
-- [گوش دادن به رویدادهای قرارداد هوشمند اتریومی](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
-- [استفاده از Besu (Pantheon)، کلاینت Java اتریوم با لینوکس](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
-- [اجرای یک گره Hyperledger (Pantheon) در آزمونهای ادغام Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
-- [برگه Cheat Web3j](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c)
-
-نحوه استفاده از [ethers-kt](https://github.com/Kr1ptal/ethers-kt) را بیاموزید که یک کتابخانه همگام و با کارایی بالا کاتلین برای تعامل با بلاکچینهای مبتنی بر ماشین مجازی اتریوم است. هدف قرار دادن پلتفرمهای JVM و اندروید.
-- [انتقال توکنهای ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
-- [سواپ Uniswap ورژن 2 با گوش دادن به رویداد (event listening)](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
-- [ردیاب تعادل ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
-
-## مقالات سطح متوسط {#intermediate-articles}
-
-- [مدیریت فضای ذخیره سازی در برنامه Java با IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
-- [مدیریت توکن های ERC20 در Java با Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
-- [مدیران تراکنش Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
-
-## الگوهای استفاده پیشرفته {#advanced-use-patterns}
-
-- [استفاده از اتریوم برای ساخت داده حافظه پنهان از یک قرارداد هوشمند جاوایی](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
-
-## پروژه ها و ابزارهای جاوا {#java-projects-and-tools}
-
-- [Hyperledger Besu (Pantheon) (کلاینت اتریوم)](https://docs.pantheon.pegasys.tech/en/stable/)
-- [Web3J (کتابخانه ای برای تعامل با کلاینت های اتریوم)](https://github.com/web3j/web3j)
-- [ethers-kt (Async، کتابخانه کاتلین/جاوا/اندروید با کارایی بالا برای بلاک چینهای مبتنی بر ماشین مجازی اتریوم.)](https://github.com/Kr1ptal/ethers-kt)
-- [Eventeum (شنونده رویداد)](https://github.com/ConsenSys/eventeum)
-- [Mahuta (ابزار توسعه دهنده IPFS)](https://github.com/ConsenSys/mahuta)
-
-به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/)
-
-## مشارکت کنندگان انجمن جاوا {#java-community-contributors}
-
-- [IO Builders](https://io.builders)
-- [Kauri](https://kauri.io)
-- [Besu HL chat](https://chat.hyperledger.org/channel/besu)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
deleted file mode 100644
index 1d68fc64734..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md"
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان جاوا اسکریپت
-description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر جاوا اسکریپت توسعه دهید.
-lang: fa
----
-
-جاوا اسکریپت از محبوب ترین زبان ها در اکوسیستم اتریوم است. در واقع، یک [تیم](https://github.com/ethereumjs) وجود دارد که تا حد ممکن اتریوم را به جاوا اسکریپت بیاورند.
-
-در [همه سطوح پشته](/developers/docs/ethereum-stack/) فرصتهایی برای نوشتن جاوا اسکریپت (یا چیزی نزدیک به آن) وجود دارد.
-
-## تعامل با اتریوم {#interact-with-ethereum}
-
-### کتابخانه های API جاوا اسکریپت {#javascript-api-libraries}
-
-اگر میخواهید جاوا اسکریپت بنویسید تا زنجیره بلوکی را پرس و جو کنید، تراکنشها را ارسال کنید، راحتترین راه برای انجام این کار استفاده از [کتابخانه API جاوا اسکریپت](/developers/docs/apis/javascript/) است. این APIها به توسعه دهندگان این امکان را می دهند تا به راحتی با [گره های شبکه اتریوم](/developers/docs/nodes-and-clients/) تعامل داشته باشند.
-
-میتوانید از این کتابخانهها برای تعامل با قراردادهای هوشمند در اتریوم استفاده کنید، بنابراین میتوانید یک dapp بسازید که در آن از جاوا اسکریپت تنها برای تعامل با قراردادهای قبلی استفاده کنید.
-
-**بررسی**
-
-- [Web3.js](https://web3js.readthedocs.io/)
-- [Ethers.js](https://docs.ethers.io/) _– شامل پیادهسازی کیف پول اتریوم و ابزارهای کاربردی در جاوا اسکریپت و تایپ اسکریپت میشود._
-- [viem](https://viem.sh) – یک واسط تایپ اسکریپت برای اتریوم که موارد اولیه بدون حالت سطح پایین را برای تعامل با اتریوم فراهم میکند.
-
-### قراردادهای هوشمند {#smart-contracts}
-
-اگر یک توسعهدهنده جاوا اسکریپت هستید و میخواهید قرارداد هوشمند خود را بنویسید، بهتر است با [Solidity](https://solidity.readthedocs.io) آشنا شوید. این محبوب ترین زبان قرارداد هوشمند است و از نظر ترکیبی شبیه به جاوا اسکریپت است که ممکن است یادگیری آن را آسان تر کند.
-
-اطلاعات بیشتر در مورد [قراردادهای هوشمند](/developers/docs/smart-contracts/).
-
-## پروتکل را درک کنید {#understand-the-protocol}
-
-### ماشین مجازی اتریوم {#the-ethereum-virtual-machine}
-
-یک پیادهسازی جاوا اسکریپتی از [ماشین مجازی اتریوم](/developers/docs/evm/) وجود دارد. که از آخرین قوانین فورک پشتیبانی می کند. قوانین فورک به تغییراتی اشاره دارد که در نتیجه ارتقاهای برنامه ریزی شده در EVM ایجاد شده است.
-
-این به بسته های مختلف جاوا اسکریپت تقسیم می شود که می توانید برای درک بهتر آن ها را بررسی کنید:
-
-- حساب ها
-- بلوکها
-- خود زنجیره بلوکی
-- تراکنشها
-- و موارد دیگر...
-
-این به شما کمک می کند مواردی مانند "ساختار داده یک حساب" را درک کنید.
-
-اگر ترجیح می دهید کد بخوانید، این جاوا اسکریپت می تواند جایگزین خوبی برای خواندن از طریق اسناد ما باشد.
-
-** monorepo را بررسی کنید**
-[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm)
-
-### گرهها و کاربرها {#nodes-and-clients}
-
-یک کلاینت Ethereumjs در حال توسعه فعال است که به شما امکان میدهد نحوه کار مشتریان اتریوم را به زبانی که بهتر میفهمید بررسی کنید و آن جاوا اسکریپت است!
-
-قبلاً در یک [`مخزن`](https://github.com/ethereumjs/ethereumjs-client) مستقل قرار داشت، اما بعداً به عنوان یک بسته در مونورپو اتریوم ویام ادغام شد.
-
-** کلاینت را بررسی کنید**
-[`ethereumjs-client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
-
-## پروژه های دیگر {#other-projects}
-
-همچنین چیزهای بسیار دیگر در سرزمین جاوا اسکریپت اتریوم در حال انجام است، از جمله:
-
-- کتابخانه های خدمات کیف پول.
-- ابزارهایی برای تولید، وارد کردن، و صدور کلیدهای اتریوم.
-- پیادهسازی `merkle-patricia-tree` - ساختار داده ای که در مقاله زرد اتریوم مشخص شده است.
-
-در [ مخزن EthereumJS](https://github.com/ethereumjs) هر چیزی را که بیشتر به آن علاقه دارید جستجو کنید
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
deleted file mode 100644
index 71c206cf840..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md"
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان پایتون
-description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر پایتون توسعه دهید
-lang: fa
-incomplete: true
----
-
-یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر پایتون توسعه دهید
-
-از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در اتریوم مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
-
-## شروع به کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**اولین قدم های خود را برای ادغام پایتون با Ethereum بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [بیاموزید که چگونه Solidity را کامپایل و بهکارگیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## مقالات مبتدی {#beginner-articles}
-
-- [راهنمای توسعهدهنده (Python) برای اتریوم](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
-- [گزارش وضعیت پایتون در بلاک چین 2023](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
-- [مقدمه ای بر قراردادهای هوشمند با Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
-- [توکن ERC20 خود را با Python و Brownie مستقر کنید](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
-- [چطور می توان قرارداد اتریوم را با استفاده از Python Flask توسعه داد؟](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
-- [معرفی Web3.py · اتریوم برای توسعه دهندگان Python](https://www.dappuniversity.com/articles/web3-py-intro)
-- [چگونه یک تابع قرارداد هوشمند را با استفاده از پایتون وweb3.py فراخوانی کنیم](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
-
-## مقالات سطح متوسط {#intermediate-articles}
-
-- [توسعه ی برنامه های غیرمتمرکز برای برنامه نویسان پایتون](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
-- [ساخت یک رابط پایتون اتریوم: قسمت 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
-- [قراردادهای هوشمند اتریوم در پایتون: یک راهنمای جامع](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
-- [استفاده از Brownie و Python برای استقرار قراردادهای هوشمند](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
-- [ایجاد NFT ها در OpenSea با Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
-
-## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
-
-- [کامپایل، توسعه و فراخوانی قرارداد هوشمند اتریوم با استفاده از پایتون](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
-- [قراردادهای هوشمند رویه ای را با لغزش گر تجزیه و تحلیل کنید](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
-- [آموزش Fintech زنجیره بلوکی: وام دادن و قرض گرفتن با Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
-
-## پروژه ها و ابزارهای Python {#python-projects-and-tools}
-
-### فعال: {#active}
-
-- [Web3.py](https://github.com/ethereum/web3.py) - _کتابخانه Python برای تعامل با اتریوم_
-- [Vyper](https://github.com/ethereum/vyper/) - _زبان قرارداد هوشمند Pythonic برای EVM_
-- [Ape - __ابزار توسعه قرارداد هوشمند برای Pythonistas، دانشمندان داده، و حرفه ای های امنیتی.](https://github.com/ApeWorX/ape)
-- [py-evm](https://github.com/ethereum/py-evm) - _پیادهسازی ماشین مجازی اتریوم_
-- [eth-tester](https://github.com/ethereum/eth-tester) - _ابزارهایی برای تست برنامههای مبتنی بر اتریوم_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _utility _ توابعی برای کار با پایگاه های کد مرتبط با اتریوم
-- [py-solc-x](https://pypi.org/project/py-solc-x/) - _Python wrapper در اطراف کامپایلر solc solidity با پشتیبانی 0.5.x_
-- [pymaker](https://github.com/makerdao/pymaker) - _Python API برای قراردادهای سازنده_
-- [siwe](https://github.com/spruceid/siwe-py) - _برای پایتون با اتریوم وارد شوید (siwe)_
-- [Web3 DeFi برای ادغامهای اتریوم](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _یک بسته پایتون با ادغامهای آماده برای ERC-20، Uniswap و سایر پروژه های محبوب_
-- [Wake](https://getwake.io) - _چارچوب یکپارچه پایتون برای آزمایش قراردادها، فازبندی، استقرار، اسکن آسیبپذیری و پیمایش کد (سرور زبان - [ابزارهای سالیدیتی](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
-
-### بایگانی شده / دیگر نگهداری نمی شود: {#archived--no-longer-maintained}
-
-- [Trinity](https://github.com/ethereum/trinity) - _کاربر Python اتریوم_
-- [Mamba](https://github.com/arjunaskykok/mamba) - _چارچوبی برای نوشتن، کامپایل و استقرار قراردادهای هوشمند نوشته شده به زبان Vyper_
-- [Brownie](https://github.com/eth-brownie/brownie) - _Python چارچوبی برای توسعه، تست و تعامل با قراردادهای هوشمند اتریوم_
-- [pydevp2p](https://github.com/ethereum/pydevp2p) - _پیاده سازی پشته P2P اتریوم_
-- [py-wasm](https://github.com/ethereum/py-wasm) - _پیاده سازی مفسر اسمبلی وب توسط پایتون_
-
-به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/).
-
-## پروژه هایی که از ابزار Python استفاده می کنند {#projects-using-python-tooling}
-
-پروژههای مبتنی بر اتریوم زیر از ابزارهایی استفاده میکنند که در این صفحه ذکر شده است. مخازن منبع باز مرتبط، به عنوان یک مرجع خوب برای نمونه کد و بهترین شیوه ها عمل می کنند.
-
-- [Yearn Finance](https://yearn.finance/) و [مخزن قراردادهای Yearn Vault](https://github.com/yearn/yearn-vaults)
-- [Curve](https://curve.fi/) و [مخزن قراردادهای هوشمند Curve](https://github.com/curvefi/curve-contract)
-- [BadgerDAO](https://badger.com/) و [قراردادهای هوشمندی که از زنجیره ابزار Brownie استفاده می کنند](https://github.com/Badger-Finance/badger-system)
-- [Sushi](https://sushi.com/) از [Python در مدیریت و استقرار قراردادهای خود استفاده می کند](https://github.com/sushiswap/sushi-vesting-protocols)
-- [Alpha Finance](https://alphafinance.io/)، معروف به Alpha Homora، از [ Brownie برای آزمایش و استقرار قراردادهای هوشمند استفاده میکند](https://github.com/AlphaFinanceLab/alpha-staking-contract)
-
-## بحث جامعه پایتون {#python-community-contributors}
-
-- [Ethereum Python Community Discord](https://discord.gg/9zk7snTfWe) برای Web3.py و سایر بحثهای چارچوب پایتون
-- [دیسکورد وایپر](https://discord.gg/SdvKC79cJk) برای بحث برنامهنویسی قرارداد هوشمند وایپر
-
-## سایر لیست های گردآوری شده {#other-aggregated-lists}
-
-ویکی Vyper یک [فهرست باورنکردنی از منابع برای Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) دارد
\ No newline at end of file
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
deleted file mode 100644
index b872efead18..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md"
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان رابی
-description: یاد بگیرید چگونه برای اتریوم با استفاده از پروژه ها و ابزارهای مبتنی بر رابی توسعه دهید.
-lang: fa
-incomplete: false
----
-
-یاد بگیرید چگونه برای اتریوم با استفاده از پروژه ها و ابزارهای مبتنی بر رابی توسعه دهید.
-
-از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند، به این معنا که وقتی در Ethereum مستقر شوند، همیشه طبق برنامه اجرا می شوند. آنها می توانند دارایی های دیجیتال را برای ایجاد انواع جدیدی از برنامه های کاربردی مالی کنترل کنند. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
-
-## شروع به کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**اولین قدم های خود را برای ادغام رابی با اتریوم بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرس زیر را بررسی کنید [ethereum.org/learn](/learn/) or [ethereum.org/developers](/developers/).
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [بیاموزید که چگونه Solidity را کامپایل و به کار گیری کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## مقالات مبتدی {#beginner-articles}
-
-- [در نهایت درک حساب های اتریوم](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
-- [در نهایت احراز هویت کاربران Rails با MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
-- [ورود به سیستم با اتریوم - انتشار نمونههای کتابخانه رابی و ریل](https://blog.spruceid.com/sign-in-with-ethereum-ruby-library-release-and-rails-examples/)
-- [نحوه اتصال به شبکه اتریوم با استفاده از رابی](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
-- [نحوه ایجاد یک آدرس جدید اتریوم در رابی](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
-
-## مقالات سطح متوسط {#intermediate-articles}
-
-- [اپلیکیشن بلاک چین با رابی](https://www.nopio.com/blog/blockchain-app-ruby/)
-- [از رابی متصل به اتریوم برای اجرای قرارداد هوشمند استفاده کنید](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
-
-## پروژه ها و ابزارهای رابی {#ruby-projects-and-tools}
-
-### فعال {#active}
-
-- [eth.rb](https://github.com/q9f/eth.rb) - _کتابخانه Ruby و RPC-client برای مدیریت حسابهای اتریوم، پیامها و معاملات_
-- [keccak.rb](https://github.com/q9f/keccak.rb) - _هش Keccak (SHA3) مورد استفاده اتریوم_
-- [siwe-ruby](https://github.com/spruceid/siwe-ruby) - _اجرای رابی ورود به سیستم با اتریوم_
-- [siwe_rails](https://github.com/spruceid/siwe_rails) - _نگین Rails که مسیرهای ورود به سیستم محلی SIWE را اضافه میکند_
-- [siwe-rails-examples](https://github.com/spruceid/siwe-rails-examples) - _نمونه SIWE با استفاده از Ruby on Rails با کنترل کننده سفارشی_
-- [omniauth-siwe](https://github.com/spruceid/omniauth-siwe) - _استراتژی OmniAuth برای ورود با اتریوم (SIWE)_
-- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _استراتژی OmniAuth برای احراز هویت از طریق مالکیت NFT_
-- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _الگوی Ethereum on Rails که امکان اتصال MetaMask به Ruby on Rails را فراهم میکند_
-
-### بایگانی شده / دیگر نگهداری نمی شود {#archived--no-longer-maintained}
-
-- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _ فراخوانی روشهای RPC گره اتریوم با رابی_
-- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _کتابخانه Ruby برای تولید آدرسهای ETH از کیف پول قطعی سلسله مراتبی طبق استاندارد BIP32 _
-- [etherlite](https://github.com/budacom/etherlite) - _ادغام اتریوم برای Ruby on Rails_
-- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _کلاینت Ruby Ethereum با استفاده از رابط JSON-RPC برای ارسال تراکنش ها ، ایجاد و تعامل با قراردادها و همچنین جعبه ابزار مفید برای کار با Ethereum node_
-- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _استراتژی ارائهدهنده اتریوم را برای OmniAuth اجرا میکند_
-
-به دنبال منابع بیشتری هستید؟ [خانه برنامهنویس ما](/developers/) را بررسی کنید.
-
-## مشارکت کنندگان جامعه رابی {#ruby-community-contributors}
-
-[گروه تلگرام اتریوم روبی](https://t.me/ruby_eth) میزبان جامعهای است که به سرعت در حال رشد است و منبع اختصاصی برای بحث در مورد هر یک از پروژههای فوق و موضوعات مرتبط است.
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
deleted file mode 100644
index 856874774fe..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md"
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: اتریوم برای توسعه دهندگان Rust
-description: یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر rust توسعه دهید
-lang: fa
-incomplete: true
----
-
-یاد بگیرید چطور اتریوم را با پروژه ها و ابزارهای مبتنی بر Rust توسعه دهید
-
-از اتریوم برای ساخت برنامه های غیرمتمرکز (اصطلاحا dapps) ی که از مزایای فناوری مبتنی بر رمزراز و زنجیره بلوکی استفاده می کنند، استفاده کنید. این برنامه های غیرمتمرکز می توانند قابل اعتماد باشند،به این معنا که وقتی آنها در Ethereum مستقر شوند ، همیشه طبق برنامه اجرا می شوند. آنها با ایجاد انواع جدیدی از برنامه های کاربردی مالی، قادر به کنترل دارایی های دیجیتال خواهند بود. آنها می توانند غیرمتمرکز باشند ، به این معنی که هیچ نهاد یا شخص واحدی آنها را کنترل نمی کند و سانسور آنها تقریباً غیرممکن است.
-
-## شروع به کار با قراردادهای هوشمند و زبان Solidity {#getting-started-with-smart-contracts-and-solidity}
-
-**اولین قدم های خود را برای ادغام Rust با اتریوم بردارید**
-
-آیا به توضیحات پایهای بیشتری نیاز دارید؟ آدرسهای زیر را بررسی کنید [ethereum.org/learn](/learn/) یا [ethereum.org/developers](/developers/).
-
-- [زنجیره بلوکی توضیح داده شده است](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [درک قراردادهای هوشمند](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [اولین قرارداد هوشمند خود را بنویسید](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [بیاموزید که چگونه رویه را گردآوری و استفاده کنید](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-
-## مقالات مبتدی {#beginner-articles}
-
-- [انتخاب یک کلاینت اتریومی](https://www.trufflesuite.com/docs/truffle/reference/choosing-an-ethereum-client)
-- [کلاینت Rust Ethereum](https://openethereum.github.io/) \* **توجه داشته باشید که OpenEthereum [منسوخ شده است](https://medium.com/openethereum/gnosis-joins-erigon-forerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) و دیگر نگهداری نمی شود.** از آن با احتیاط استفاده کنید و ترجیحاً به پیاده سازی کلاینت دیگری بروید.
-- [ارسال تراکنش به اتریوم با استفاده از Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
-- [آموزش گام به گام نحوه نوشتن قراردادها در Rust Wasm برای Kovan](https://github.com/paritytech/pwasm-tutorial)
-
-## مقالات سطح متوسط {#intermediate-articles}
-
-## الگوهای مورد استفاده سطح پیشرفته {#advanced-use-patterns}
-
-- [pwasm_ethereum کتابخانه خارجی برای تعامل با شبکه شبیه اتریوم](https://github.com/openethereum/pwasm-ethereum)
-- [ایجاد یک چت غیرمتمرکز با استفاده از JavaScript و Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
-- [با استفاده از Vue.js & Rust یک برنامه غیرمتمرکز Todo بسازید](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
-
-- [یک بلاک چین در Rust بسازید](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
-
-## پروژه ها و ابزارهای Rust {#rust-projects-and-tools}
-
-- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _مجموعهای از بخشهای خارجی برای تعامل با شبکههای شبه اتریوم em>
-- [Lighthouse](https://github.com/sigp/lighthouse) - _کلاینت لایهی اجماع سریع اتریوم_
-- [اتریوم وب اسمبلی](https://ewasm.readthedocs.io/en/mkdocs/) - _طراحی مجدد لایه اجرای قرارداد هوشمند اتریوم با استفاده از بخش قطعی زیر مجموعه را ارائه میدهد. WebAssembly_
-- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _مرجع API OASIS_
-- [سولاریس](https://github.com/paritytech/sol-rs) - _دستگاه تست واحد قراردادهای هوشمند سالیدیتی با استفاده از Parity Client EVM اصلی.< /em>
-- [SputnikVM](https://github.com/rust-blockchain/evm) - _پیاده سازی ماشین مجازی Rust Ethereum_
-- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _قرارداد هوشمند Wavelet در Rust_
-- [فوندری](https://github.com/foundry-rs/foundry) - _ابزار توسعه برنامه اتریوم_
-- [آلوی](https://alloy.rs) - _با عملکرد بالا، به خوبی آزمایش شده و amp; کتابخانههای مستند شده برای تعامل با اتریوم و سایر زنجیرههای مبتنی بر ماشین مجازی اتریوم_
-- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _اجرای کیف پول و کتابخانه اتریوم_
-- [SewUp](https://github.com/second-state/SewUp) - _کتابخانه ای که به شما کمک می کند قرارداد وب اسمبلی اتریوم خود را با Rust بسازید و درست مانند توسعه در یک بکاند مشترک_
-- [جریانهای فرعی](https://github.com/streamingfast/substreams) - _فناوری نمایهسازی دادههای بلاکچین موازی_
-- [Reth](https://github.com/paradigmxyz/reth) Reth (مخفف راست اتریوم Rust) یک پیادهسازی تمام نود یا گره جدید اتریوم است
-- [اتریوم Rust عالی](https://github.com/Vid201/awesome-ethereum-rust) - _مجموعه سرپرستی شده از پروژهها در اکوسیستم اتریوم است. Rust_
-
-به دنبال منابع بیشتری هستید؟ پس اینجا را ببینید [ethereum.org/developers.](/developers/)
-
-## مشارکت کنندگان انجمن Rust {#rust-community-contributors}
-
-- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby)
-- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby)
-- [Parity Gitter](https://gitter.im/paritytech/parity)
-- [Enigma](https://discord.gg/SJK32GY)
diff --git "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" "b/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
deleted file mode 100644
index 8e12ae8a172..00000000000
--- "a/public/content/translations/fa/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md"
+++ /dev/null
@@ -1,217 +0,0 @@
----
-title: ذخیرهسازی غیرمتمرکز
-description: مروری بر ذخیرهسازی غیرمتمرکز و ابزارهای موجود برای ادغام آن در یک برنامهی غیرمتمرکز.
-lang: fa
----
-
-برخلاف یک سرور متمرکز که توسط یک شرکت یا سازمان اداره میشود، سیستمهای ذخیرهسازی غیرمتمرکز متشکل از یک شبکه همتا به همتا از اپراتورهای کاربر هستند که بخشی از دادههای کلی را نگه میدارند و یک سیستم اشتراکگذاری ذخیرهسازی فایل انعطافپذیر را ایجاد میکنند. اینها می توانند در یک برنامه مبتنی بر زنجیرهی بلوکی یا هر شبکه مبتنی بر همتا به همتا باشند.
-
-خود اتریوم می تواند به عنوان یک سیستم ذخیرهسازی غیرمتمرکز مورد استفاده قرار گیرد و این برای زمانی است که صحبت از ذخیرهسازی کد در تمام قراردادهای هوشمند می شود. با این حال، وقتی صحبت از حجم زیاد داده می شود، اتریوم برای آن طراحی نشده است. این زنجیره به طور پیوسته در حال رشد است، اما در زمان نگارش مقاله، زنجیره اتریوم حدود 500 گیگابایت - 1 ترابایت است ([بسته به کلاینت](https://etherscan.io/chartsync/chaindefault))، و هر گره در شبکه باید بتواند تمام داده ها را ذخیره کند. اگر زنجیره به حجم زیادی از داده ها (مثلاً 5 ترابایت) گسترش یابد، ادامه کار برای همه گره ها امکانپذیر نخواهد بود. همچنین، هزینه استقرار این مقدار داده در شبکهی اصلی به دلیل هزینههای [گاز](/developers/docs/gas) بسیار گران خواهد بود.
-
-با توجه به این محدودیت ها، ما به یک زنجیره یا روش متفاوت برای ذخیره مقادیر زیادی از داده ها به صورت غیرمتمرکز نیاز داریم.
-
-هنگامی که به گزینه های ذخیرهسازی غیرمتمرکز (dStorage) نگاه می کنید، چند نکته وجود دارد که کاربر باید در نظر داشته باشد.
-
-- مکانیسم پایداری / ساختار انگیزه
-- تقویت حفظ داده ها
-- عدم تمرکز
-- اجماع
-
-## مکانیسم پایداری / ساختار انگیزه {#persistence-mechanism}
-
-### بر پایهی زنجیرهی بلوکی {#blockchain-based}
-
-برای اینکه یک داده برای همیشه باقی بماند، باید از مکانیزم پایداری استفاده کنیم. به عنوان مثال، در اتریوم، مکانیسم پایداری این است که کل زنجیره هنگام اجرای یک گره باید در نظر گرفته شود. قطعات جدید داده در انتهای زنجیره قرار میگیرند و به رشد خود ادامه میدهند - که هر گره باید تمام دادههای تعبیهشده را تکرار کند.
-
-این به عنوان پایداری **بر پایهی زنجیرهی بلوکی** شناخته میشود.
-
-مشکل پایداری مبتنی بر زنجیرهی بلوکی این است که این زنجیره میتواند بسیار بزرگتر از آن باشد که تمام دادهها را به طور عملی نگهداری و ذخیره کند (به عنوان مثال [بسیاری از منابع](https://healthit.com.au/how-big-is-the-internet -and-how-do-we-measure-it/) تخمین می زنند که اینترنت به بیش از 40 زتابایت ظرفیت ذخیره سازی نیاز دارد).
-
-زنجیره بلوکی همچنین باید دارای نوعی ساختار انگیزشی باشد. برای پایداری بر پایهی زنجیرهی بلوکی، یک پرداخت به استخراجگر وجود دارد. هنگامی که داده ها به زنجیره اضافه می شوند، اعتباردهنده ها برای اضافه کردن داده ها به آن پول پرداخت می کنند.
-
-پلتفرمهایی با پایداری مبتنی بر زنجیرهی بلوکی:
-
-- اتریوم
-- [Arweave](https://www.arweave.org/)
-
-### بر پایهی قرارداد {#contract-based}
-
-پایداری **مبتنی بر قرارداد** این شهود را دارد که دادهها را نمیتوان توسط هر گره تکرار کرد و برای همیشه ذخیره کرد، و در عوض باید با توافقات قراردادی نگهداری شوند. اینها توافقاتی هستند که با گره های متعددی که قول داده اند یک قطعه داده را برای مدتی نگهداری کنند، انجام شده است. آنها باید هر زمان که تمام می شوند بازپرداخت یا تمدید شوند تا داده ها باقی بمانند.
-
-در بیشتر موارد، به جای ذخیره همه داده ها در زنجیره، هش محل قرارگیری داده ها در زنجیره ذخیره می شود. به این ترتیب، کل زنجیره برای حفظ تمام داده ها نیازی به مقیاس پذیری ندارد.
-
-پلتفرمهایی با پایداری مبتنی بر قرارداد:
-
-- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/)
-- [Skynet](https://siasky.net/)
-- [Storj](https://storj.io/)
-- [0Chain](https://0chain.net/)
-- [شبکه پوسته](https://crust.network)
-- [Swarm](https://www.ethswarm.org/)
-- [4EVERLAND](https://www.4everland.org/)
-
-### ملاحظات دیگر {#additional-consideration}
-
-IPFS یک سیستم توزیع شده برای ذخیره و دسترسی به فایل ها، وب سایت ها، برنامه ها و داده ها است. این یک طرح تشویقی داخلی ندارد، اما در عوض میتواند با هر یک از راهحلهای تشویقی مبتنی بر قرارداد بالا برای پایداری طولانیمدت استفاده شود. راه دیگر برای ماندگاری داده ها در IPFS کار با یک سرویس پین است که داده های شما را برای شما "پین" می کند. شما حتی می توانید گره IPFS خود را اجرا کنید و به شبکه کمک کنید تا داده های خود و/یا دیگران را به صورت رایگان حفظ کنید!
-
-- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/)
-- [Pinata](https://www.pinata.cloud/) _(سرویس پین کردن IPFS)_
-- [web3.storage](https://web3.storage/) _(سرویس پین کردن IPFS/Filecoin)_
-- [Infura](https://infura.io/product/ipfs) _(سرویس پین کردن IPFS)_
-- [اسکن IPFS](https://ipfs-scan.io) _(کاوشگر پین کردن IPFS)_
-- [4اورلند](https://www.4everland.org/)_(سرویس پینکردن IPFS)
-- [فایل بیس (Filebase)](https://filebase.com) _(سرویس پین کردن IPFS)_
-- [شبکه اسفرن](https://spheron.network/) _(سرویس پین کردن IPFS/فایل کوین)_
-
-سوارم (SWARM) یک فناوری ذخیرهسازی و توزیع داده غیرمتمرکز با سیستم انگیزشی ذخیرهسازی و اوراکل قیمت اجاره ذخیرهسازی است.
-
-## حفظ دادهها {#data-retention}
-
-برای حفظ دادهها، سیستمها باید مکانیزمی برای اطمینان از حفظ دادهها داشته باشند.
-
-### مکانیسم چالش {#challenge-mechanism}
-
-یکی از محبوبترین راهها برای اطمینان از حفظ دادهها، استفاده از نوعی چالش رمزنگاری است که برای گرهها صادر میشود تا مطمئن شوید که هنوز دادهها را دارند. یک مورد ساده به اثبات دسترسی Arweave نگاه می کند. آنها یک چالش برای گره ها صادر می کنند تا ببینند آیا آنها داده ها را در آخرین بلوک و بلوک تصادفی در گذشته دارند یا خیر. اگر گره نتواند به پاسخ برسد، جریمه می شود.
-
-انواع dStorage با مکانیزم چالش:
-
-- 0Chain
-- Skynet
-- Arweave
-- Filecoin
-- شبکه پوسته
-- 4EVERLAND
-
-### عدم تمرکز {#decentrality}
-
-ابزارهای خوبی برای اندازهگیری سطح تمرکززدایی پلتفرمها وجود ندارد، اما به طور کلی، شما میخواهید از ابزارهایی استفاده کنید که نوعی KYC ندارند تا مدرکی ارائه دهید که متمرکز نیستند.
-
-ابزارهای غیرمتمرکز بدون KYC:
-
-- 0Chain (اجرای یک نسخه غیر KYC)
-- Skynet
-- Arweave
-- Filecoin
-- IPFS
-- اتریوم
-- شبکه پوسته
-- 4EVERLAND
-
-### اجماع {#consensus}
-
-اکثر این ابزارها نسخه خود از [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) را دارند اما عموما بر اساس [**اثبات کار (PoW)**](/developers/docs/consensus-mechanisms/pow/) یا [**اثبات سهام (PoS)**](/developers/docs/consensus-mechanisms/pos/) بنا نهاده شده اند.
-
-بر اساس اثبات کار:
-
-- Skynet
-- Arweave
-
-بر اساس اثبات سهام:
-
-- اتریوم
-- Filecoin
-- 0Chain
-- شبکه پوسته
-
-## ابزارهای مرتبط {#related-tools}
-
-**IPFS - _InterPlanetary File System یک ذخیرهسازی غیرمتمرکز و سیستم مرجع فایل برای اتریوم است._**
-
-- [Ipfs.io](https://ipfs.io/)
-- [مستندات](https://docs.ipfs.io/)
-- [گیتهاب](https://github.com/ipfs/ipfs)
-
-**Storj DCS -_ذخیره سازی غیرمتمرکز اشیاء ابری ایمن، خصوصی و سازگار با S3 برای توسعه دهندگان._**
-
-- [Storj.io](https://storj.io/)
-- [اسناد](https://docs.storj.io/)
-- [گیتهاب](https://github.com/storj/storj)
-
-**Skynet -_Skynet یک زنجیرهی اثبات کار غیرمتمرکز است که به اینترنت غیرمتمرکز اختصاص دارد_**
-
-- [Skynet.net](https://siasky.net/)
-- [مستندات](https://siasky.net/docs/)
-- [گیتهاب](https://github.com/SkynetLabs/)
-
-**Filecoin -_Filecoin از همان تیم پشتیبان IPFS ایجاد شد. یک لایه انگیزشی در بالای ایده آل های IPFS است._**
-
-- [Filecoin.io](https://filecoin.io/)
-- [مستندات](https://docs.filecoin.io/)
-- [گیتهاب](https://github.com/filecoin-project/)
-
-**Arweave - _Arweave یک پلتفرم dStorage برای ذخیره داده است._**
-
-- [Arweave.org](https://www.arweave.org/)
-- [مستندات](https://docs.arweave.org/info/)
-- [Arweave](https://github.com/ArweaveTeam/arweave/)
-
-**0chain - _0Chain یک پلتفرم dStorage اثبات سهام با خرده زنجیرهها و حباب است._**
-
-- [0Chain.net](https://0chain.net/)
-- [مستندات](https://docs.0chain.net/0chain/)
-- [گیتهاب](https://github.com/0chain/)
-
-**Crust Network - _Crust یک پلت فرم dStorage در بالای IPFS است._**
-
-- [شبکه پوسته](https://crust.network)
-- [مستندات](https://wiki.crust.network)
-- [گیت هاب](https://github.com/crustio)
-
-**Swarm - _یک پلتفرم ذخیرهسازی توزیع شده و سرویس توزیع محتوا برای پشته اتریوم web3._**
-
-- [EthSwarm.org](https://www.ethswarm.org/)
-- [مستندات](https://docs.ethswarm.org/docs/)
-- [گیتهاب](https://github.com/ethersphere/)
-
-**OrbitDB - _ پایگاه داده همتا به همتا غیرمتمرکز بر روی IPFS._**
-
-- [OrbitDB.org](https://orbitdb.org/)
-- [مستندات](https://github.com/orbitdb/field-manual/)
-- [گیتهاب](https://github.com/orbitdb/orbit-db/)
-
-**Aleph.im - _پروژه ابری غیرمتمرکز (پایگاه داده، ذخیرهسازی فایل، محاسبات و DID). ترکیبی منحصربهفرد از فناوری همتا به همتای روی زنجیرهای و خارج زنجیرهای. IPFS و سازگاری چند زنجیره ای._**
-
-- [Aleph.im](https://aleph.im/)
-- [مستندات](https://aleph.im/#/developers/)
-- [گیتهاب](https://github.com/aleph-im/)
-
-**Ceramic - _ذخیرهسازی پایگاه داده IPFS کنترلشده توسط کاربر برای برنامههای کاربردی غنی از داده و جذاب._**
-
-- [Ceramic.network](https://ceramic.network/)
-- [Documentation](https://developers.ceramic.network/learn/welcome/)
-- [گیتهاب](https://github.com/ceramicnetwork/js-ceramic/)
-
-**فایل بیس- _ ذخیرهسازی غیرمتمرکز سازگار با S3 و سرویس پین کردن IPFS اضافی. همه فایلهایی که از طریق فایل بیس به IPFS آپلود میشوند، بهطور خودکار به زیرساخت فایل بیس با 3 بار تکرار به صورت سراسری پین میشوند._**
-
-- [Filebase.com](https://filebase.com/)
-- [Documentation](https://docs.filebase.com/)
-- [گیتهاب](https://github.com/filebase)
-
-**4EVERLAND- _یک پلتفرم محاسبات ابری Web 3.0 که قابلیتهای هسته ذخیرهسازی، محاسباتی و شبکه را ادغام میکند، با S3 سازگار است و ذخیرهسازی دادههای همزمان را در شبکههای ذخیرهسازی غیرمتمرکز مانند IPFS و Arweave فراهم میکند._**
-
-- [4everland.org](https://www.4everland.org/)
-- [مستندات](https://docs.4everland.org/)
-- [گیتهاب](https://github.com/4everland)
-
-**کالیدو (Kaleido)- _یک پلتفرم بلاک چین به عنوان سرویس با گرههای IPFS دکمه کلیکی_**
-
-- [Kaleido](https://kaleido.io/)
-- [مستندات](https://docs.kaleido.io/kaleido-services/ipfs/)
-- [گیتهاب](https://github.com/kaleido-io)
-
-**Spheron Network - _اسفرن یک پلتفرم بهعنوان سرویس (PaaS) است که برای dAppهایی طراحی شده است که به دنبال راهاندازی برنامههای خود بر روی زیرساخت غیرمتمرکز با بهترین عملکرد هستند. محاسبات، ذخیرهسازی غیرمتمرکز، CDN&. میزبانی وب خارج از بخش اصلی را ارائه میکند._**
-
-- [spheron.network](https://spheron.network/)
-- [اسناد](https://docs.spheron.network/)
-- [گیت هاب](https://github.com/spheronFdn)
-
-## بیشتر بخوانید {#further-reading}
-
-- [ذخیرهسازی غیرمتمرکز چیست؟](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
-- [شکستن پنج افسانه رایج در مورد ذخیرهسازی غیرمتمرکز](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [چارچوبهای توسعه](/developers/docs/frameworks/)
diff --git a/public/content/translations/fa/19) Learn Pages 2/glossary/index.md b/public/content/translations/fa/19) Learn Pages 2/glossary/index.md
deleted file mode 100644
index 530219c0dab..00000000000
--- a/public/content/translations/fa/19) Learn Pages 2/glossary/index.md
+++ /dev/null
@@ -1,499 +0,0 @@
----
-title: واژهنامه اتریوم
-description: یک واژه نامه ناکامل از واژگان فنی و غیر فنی مربوط به اتریوم
-lang: fa
----
-
-# واژه نامه {#ethereum-glossary}
-
-## \# {#section-numbers}
-
-
-
-
-
-## A {#section-a}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## B {#section-b}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## C {#section-c}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## D {#section-d}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## E {#section-e}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## F {#section-f}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## G {#section-g}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## H {#section-h}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## I {#section-i}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## K {#section-k}
-
-
-
-
-
-
-
-
-
-
-
-## L {#section-l}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## M {#section-m}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## N {#section-n}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## O {#section-o}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## P {#section-p}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## R {#section-r}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## S {#section-s}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## T {#section-t}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## V {#section-v}
-
-
-
-
-
-
-
-
-
-
-
-
-
-## W {#section-w}
-
-
-
-
-
-
-
-
-
-## Z {#section-z}
-
-
-
-
-
-
-
-
-
-## منابع {#sources}
-
-_ارائه شده با استفاده از [تسلط بر اتریوم](https://github.com/ethereumbook/ethereumbook) نوشته [ آندراس م.انتوپولوس،گوین وود](https://ethereumbook.info) تحت لایسنس CC-BY-SA_
-
-
-
-## در بهبود این صفحه مشارکت کنید {#contribute-to-this-page}
-
-چیزی را از قلم انداخته ایم؟ چیزی اشتباه است؟ به ما از طریق مشارکت در گیتهاب برای بهبود واژه نامه کمک کنید!
-
-[درباره مشارکت کردن بیشتر بدانید](/contributing/adding-glossary-terms)
diff --git a/public/content/translations/fa/19) Learn Pages 2/history/index.md b/public/content/translations/fa/19) Learn Pages 2/history/index.md
deleted file mode 100644
index bb4743eed55..00000000000
--- a/public/content/translations/fa/19) Learn Pages 2/history/index.md
+++ /dev/null
@@ -1,738 +0,0 @@
----
-title: تاریخچه فورک های اتریوم
-description: تاریخچه بلاک چین اتریوم و نقطه عطف ها، انتشارها و فورک های عمده.
-lang: fa
-sidebarDepth: 1
----
-
-# تاریخچه اتریوم {#the-history-of-ethereum}
-
-تایم لاین همه اتفاقات، فورک ها و به روزرسانی های بلاک چین اتریوم.
-
-
-
-فورکها زمانی هستند که باید ارتقاء یا تغییرات فنی عمده در شبکه انجام شود - آنها معمولاً از پیشنهادهای بهبود اتریوم (EIP) سرچشمه میگیرند و "قوانین" پروتکل را تغییر میدهند.
-
-زمانی که در نرم افزار قدیمی و با کنترل مرکزی به ارتقاء نیاز است،این شرکت فقط یک نسخه جدید را برای کاربر نهایی منتشر خواهد کرد. بلاک چین ها متفاوت عمل می کنند زیرا مالکیت مرکزی وجود ندارد. کلاینتهای اتریوم باید نرمافزارشان را بهروزرسانی کنند تا قوانین فورک جدید را پیادهسازی کنند. سازندگان بلاک بعلاوه (استخداج کننده ها در دنیای اثبات کار، اعتبار سنجیها در دنیای اثبات سهام) و مشتری نرم افزار روی شبکه باید بلاکها را ایجاد کرده و در برابر قوانین جدید اعتبارسنجی کنند. اطلاعات بیشتر در مورد مکانیسمهای اجماع
-
-این تغییرات قوانین ممکن است یک تقسیم موقت در شبکه ایجاد کند. بلوک های جدید را می توان بر اساس قوانین جدید یا قوانین قدیمی تولید کرد. 0x65B2EeA31601D5477AF8E643EDe26348D83d0dB0. با این حال، در موارد نادر، اختلاف نظر در مورد فورکها میتواند باعث شود که شبکه بهطور دائمی تقسیم شود – مثل اتریوم کلاسیک با دائو فورک.
-
-
-
-
-
-نرمافزاری که زیربنای اتریوم است از دو نیمه تشکیل شده است که به نامهای [لایه اجرا](/واژهنامه/#لایه-اجرا) و [لایه اجماع] (/واژهنامه/#لایه اجماع) شناخته میشوند.
-
-**نامگذاری ارتقاء اجرایی**
-
-از سال 2021، ارتقاء به **لایه اجرا** بر اساس نام شهرهای [مکانهای دوکان (Devcon) قبلی] (https://devcon.org/en/past-events/) به ترتیب زمانی نامگذاری میشوند:
-
-| ارتقا نام | دوکان سال | شماره دوکان| تاریخ ارتقا |
-| ------------ | ----------- | ------------- | ------------ |
-| برلین | 2015 | 0 | Apr 15, 2021 |
-| بندن | 2016 | I | Aug 5, 2021 |
-| شانگهای | 2017 | II | Apr 12, 2023 |
-| **کنکان | 2018 | III | Mar 13, 2024 |
-| پراگ | 2019 | IV | بعدا مشخص می شود
-|
-| اوساکا | 2020 | V | بعدا مشخص می شود
-|
-| بوگوتو | 2022 | VI | بعدا مشخص می شود
-|
-| بنکوک | 2024 | VII | بعدا مشخص می شود
-|
-
-
-
-**نامگذاری ارتقای اجماع**
-
-از زمان راه اندازی [بیکون چین](/واژه نامه/#beacon-chain)، ارتقاها به **لایه اجماع** به نام ستاره های آسمانی نامگذاری شدهاند که با حروف شروع میشوند و به ترتیب حروف الفبا ادامه مییابند:
-| نام ارتقاء | تاریخ ارتقاء |
-| ----------------------------------------------------------- | ------------ |
-| منشا بیکون چین | Dec 1, 2020 |
-| [Altair](https://en.wikipedia.org/wiki/Altair) | Oct 27, 2021 |
-| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix) | Sep 6, 2022 |
-| [Capella](https://en.wikipedia.org/wiki/Capella) | Apr 12, 2023 |
-| [**Deneb**](https://en.wikipedia.org/wiki/Deneb) | Mar 13, 2024 |
-| [_Electra_]() | بعدا مشخص میشود|
-
-**نامگذاری ترکیبی**
-
-بهروزرسانیهای اجرایی و توافقی ابتدا در زمانهای مختلف انجام شد، اما پس از [ارتقاء مرج](/roadmap/merge/) در سال 2022، این موارد به طور همزمان اجرا شدند. به این ترتیب، اصطلاحات محاورهای برای ساده کردن منابع به این ارتقاها با استفاده از یک اصطلاح به هم پیوسته پدید آمدهاند. این کار با ارتقای _Shanghai-Capella_ که معمولاً به عنوان "**Shapella**" نامیده میشود، آغاز شد و با ارتقای _Cancun-Deneb_ که ممکن است به عنوان "**Dencun**" نامیده شود، ادامه یافت
-
-| ارتقاء اجرا | ارتقاء اجماع | نام کوتاه |
-| ----------------- | ----------------- | ---------- |
-| شانگهای | کاپلا | "شاپلا" |
-| کانکان | دنب | "دنکان" |
-
-
-
-مستقیماً به اطلاعات مربوط به برخی از بهروزرسانیهای مهم گذشته بروید: [زنجیرهی Beacon](/roadmap/beacon-chain/)؛ [ادغام یا همان مرج](/roadmap/merge/)؛ و [EIP-1559](#london)
-
-به دنبال ارتقاهای آینده پروتکل هستید؟ [درباره ارتقاهای آینده نقشه راه اتریوم بیاموزید](/roadmap/).
-
-
-
-## 2024 {#2024}
-
-### کانکان-دنب ("دنکان") {#dencun}
-
-
-
-#### خلاصه کنکان {#cancun-summary}
-
-ارتقای کانکان شامل مجموعهای از پیشرفتها در _اجرای اتریوم_ با هدف بهبود مقیاسپذیری، همراه با ارتقاء اجماع دنب است.
-
-به طور قابلتوجهی این مورد شامل EIP-4844، معروف به **Proto-دنک شاردینگ** میشود که هزینه ذخیرهسازی دادهها را برای مجموعههای لایه 2 بهطور قابلتوجهی کاهش میدهد. این امر از طریق معرفی "بلاب (blobs)" داده به دست میآید که به رولآپها امکان میدهد دادهها را برای مدت کوتاهی به شبکه اصلی یا همان مین نت ارسال کنند. این مورد منجر به کاهش بسیاری از کارمزد تراکنش برای کاربران لایه 2 رولآپها میشود.
-
-
-
-
-
-
-
-- [رولآپهای لایه 2](/layer-2/)
-- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding)
-- [دانکشاردینگ](/roadmap/danksharding/)
-- [مشخصات ارتقاء کانکان را بخوانید](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
-
-#### خلاصه دنب {#deneb-summary}
-
-ارتقاء دنب شامل مجموعهای از پیشرفتها برای _اجماع_ اتریوم است که هدف آن بهبود مقیاسپذیری است. این ارتقاء همراه با بهروزرسانیهای اجرای کنکان برای فعال کردن پروتو-دنک شاردینگ (EIP-4844)، همراه با سایر پیشرفتها در بیکون چین ارائه میشود.
-
-«پیامهای خروج داوطلبانه» امضا شده از پیش تولید شده دیگر منقضی نمیشوند، بنابراین کنترل بیشتری به کاربرانی میدهد که وجوه خود را با یک اپراتور گره یا نود شخص ثالث به اشتراک میگذارند. با این پیام خروج امضا شده، استیککنندگان میتوانند عملیات گره را در حالی که توانایی خروج ایمن و برداشت وجوه خود را در هر زمان، بدون نیاز به درخواست اجازه، حفظ و واگذار کنند.
-
-EIP-7514 با محدود کردن نرخ "چرخش (churn)" که اعتبارسنجها میتوانند در شبکه به هشت (8) مورد در هر دوره بپیوندند، صدور اتر را سختتر میکند. از آنجایی که صدور اتر متناسب با کل اترها است، تعداد اعتبارسنجهایی که به _نرخ رشد_ اتریوم جدید صادر شده محدود میشوند، در عین حال الزامات سختافزاری را برای اپراتورهای گره کاهش میدهد و به تمرکززدایی کمک میکند.
-
-
-
-
-
-
-
-- [مشخصات ارتقاء دنب را بخوانید](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
-- [سوالات متداول کنکان-دنب ("دنکان")](/roadmap/dencun/)
-
-
-
-## 2023 {#2023}
-
-### شانگهای-کاپلا ("شاپلا") {#shapella}
-
-
-
-#### خلاصه شانگهای {#shanghai-summary}
-
-ارتقای شانگهای، برداشتهای استیکینگ را به لایه اجرا آورد. همزمان با ارتقاء کاپلا (Capella)، این بلوکها را قادر میسازد تا عملیات برداشت را بپذیرند، که به سهامداران یا همان استیک کنندگان اجازه میدهد اتر خود را از زنجیره بیکون به لایه اجرا خارج کنند.
-
-
-
-
-
-
-
-- [مشخصات ارتقا شانگهای را بخوانید](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
-
-#### خلاصه کاپلا {#capella-summary}
-
-ارتقاء کاپلا سومین ارتقاء عمده به لایه اجماع (Beacon Chain) بود و امکان برداشت استیک را فراهم کرد. کاپلا همزمان با ارتقاء لایه اجرا، شانگهای رخ داد و قابلیت برداشت استیک را فعال کرد.
-
-این ارتقاء لایه توافقی این توانایی را برای سهامدارانی که اعتبار برداشت را با سپرده اولیه خود ارائه نکرده بودند، به ارمغان آورد و در نتیجه امکان برداشت را فراهم کرد.
-
-این ارتقا همچنین قابلیت سوییپ کردن خودکار حساب را ارائه میکند که به طور مداوم حسابهای اعتبارسنجی یا ولیدیتور را برای هرگونه پرداخت پاداش یا برداشت کامل پردازش میکند.
-
-- [اطلاعات بیشتر در مورد برداشتهای استیکینگ](/staking/withdrawals/).
-- [مشخصات ارتقاء کاپلا را بخوانید](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/)
-
-
-
-## ۲۰۲۲ {#2022}
-
-### پاریس (مرج) {#paris}
-
-
-
-#### خلاصه {#paris-summary}
-
-ارتقای پاریس برای هدف خود در بلاکچین اثبات کار[ با سختی کل 58750000000000000000000 ](/glossary/#terminal-total-difficulty) انجام پذیرفت. این اتفاق در بلوک 15537393 در 15 سپتامبر 2022 رخ داد و باعث ارتقای بلوک بعدی پاریس شد. پاریس انتقال [مرج](/roadmap/merge/) بود - ویژگی اصلی آن خاموش کردن [اثبات الگوریتم استخراج](/developers/docs/consensus-mechanisms/pow) و منطق اجماع مرتبط و روشن کردن [اثبات سهام](/developers/docs/consensus-mechanisms/pos) به جای آن بود. پاریس خود ارتقاء یافته به [مشتری های اجرایی](/developers/docs/nodes-and-clients/#execution-clients) (معادل بلاتریکس در لایه توافق) بود که به آنها امکان میداد دستورالعملها را مشتریان توافقی متصل آنها دریافت کنند. از
-
-. این به مجموعه جدیدی از روشهای API داخلی نیاز داشت که در مجموع به عنوان API موتور API فعال شود. مسلماً این مهمترین ارتقا در تاریخ اتریوم از زمان [هوم استد ](#homestead) بوده است!
-
-- [مشخصات ارتقاء پاریس را بخوانید](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md)
-
-
-
-
-
-
-
----
-
-
-
-### بلاتریکس {#bellatrix}
-
-
-
-
-
-#### خلاصه {#bellatrix-summary}
-
-ارتقاء بلاتریکس دومین ارتقاء برنامه ریزی شده برای [زنجیره بیکون](/roadmap/beacon-chain) بود که زنجیره را برای [مرج](/roadmap/merge/) آماده میکرد. a>. جریمههای اعتبارسنجی را برای عدم فعالیت و جرایم قابل کاهش به ارزش کامل خود میرساند. همچنین بلاتریکس شامل بروزرسانی قوانین انتخاب فورک برای آماده سازی زنجیره برای مرج و انتقال از آخرین بلوک اثبات کار به اولین بلوک اثبات سهام است. این مورد شامل آگاه کردن مشتریان اجماع از [سختی کل پایانی](/glossary/#terminal-total-difficulty) 587500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 میباشد.
-
-- [مشخصات ارتقاء بلاتریکس را بخوانید](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix)
-
-
-
----
-
-
-
-### گری گلاسیر {#gray-glacier}
-
-
-
-
-
-#### خلاصه {#gray-glacier-summary}
-
-ارتقاء شبکه گری گلاسیر[بمب سختی](/glossary/#difficulty-bomb) را سه ماه عقب انداخت. این تنها تغییری است که در این ارتقاء ایجاد شده است و ماهیت آن شبیه [گلاسیر پیکان](#arrow-glacier) و [ارتقاء گلاسیر مویر](#muir-glacier) است. a>. تغییرات مشابهی در [بیزانس](#byzantium)، [کنستانتینوپل](#constantinople) و ارتقاء شبکه لندن.
-
-- [EF Blog - اطلاعیه ارتقاء گری گلاسیر](https://blog.ethereum.org/2022/06/16/gray-glacier-announcement/)
-
-
-
-
- - EIP-5133 - بمب سختی را تا سپتامبر 2022 به تعویق میاندازد
-
-
-
-
-
-
-
-
-## 2021 {#2021}
-
-
-
-### ارو گلیسیر {#arrow-glacier}
-
-
-
-
-
-#### خلاصه {#arrow-glacier-summary}
-
-ارتقاء شبکه Arrow Glacier [بمب سختی](/glossary/#difficulty-bomb) را چندین ماه عقب انداخت. این تنها تغییری است که در این ارتقاء ارائه شده است و ماهیت آن مشابه ارتقاء [Muir Glacier](#muir-glacier) است. تغییرات مشابهی در [بیزانس](#byzantium)، [کنستانتینوپل](#constantinople) و ارتقاء شبکه لندن.
-
-- [بلاگ EF - اطلاعیه ارتقاء Arrow Glacier](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/)
-- [Ethereum Cat Herders - ارتقاء Glacier Ethereum Arrow](https://medium.com/ethereum-cat-herders/ethereum-arrow-glacier-upgrade-e8d20fa4c002)
-
-
-
-
- - EIP-4345 - بمب سختی را تا ژوئن 2022 به تعویق میاندازد
-
-
-
-
----
-
-
-
-### آلتر {#altair}
-
-
-
-
-
-#### خلاصه {#altair-summary}
-
-ارتقاء آلتر اولین ارتقاء برنامه ریزی شده برای [زنجیره بیکون](/roadmap/beacon-chain) بود. پشتیبانی از «کمیتههای همگامسازی» را اضافه میکند - کلاینتهای سبک را فعال میکند و با پیشرفت توسعه به سمت مرج، عدم فعالیت اعتبارسنجی یا ولیدیتور و کاهش مجازاتها را افزایش میدهد.
-
-- [مشخصات ارتقاء آلتر را بخوانید](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
-
-
-
-#### حقیقت جذاب! {#altair-fun-fact}
-
-آلتر اولین ارتقاء شبکه بزرگی بود که زمان عرضه دقیقی داشت. هر ارتقای قبلی بر اساس یک شماره بلوک اعلام شده در زنجیره اثبات کار بود، جایی که زمان بلوک متفاوت است. زنجیره بیکون برای اثبات کار نیازی به حل ندارد و در عوض بر روی یک سیستم عصر اپوک (epoch) بر زمان متشکل از 32 «اسلات» دوازده ثانیهای کار میکند که اعتبارسنجیها میتوانند بلوکهایی را پیشنهاد کنند. به همین دلیل است که ما دقیقا میدانستیم چه زمانی میتوانیم به اپوک 74240 برسیم و آلتر اجرا شد!
-
-- [زمان بلوک](/developers/docs/blocks/#block-time)
-
-
-
----
-
-
-
-### لندن {#london}
-
-
-
-
-
-#### خلاصه {#london-summary}
-
-ارتقاء لندن [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) را معرفی کرد که بازار کارمزد معاملات را همراه با تغییراتی در نحوه رسیدگی به بازپرداخت گس اصلاح و برنامه [عصر یخبندان](/glossary/#ice-age) را مدیریت کرد.
-
-
-
-#### ارتقاء لندن (London Upgrade) / EIP - 1559 چه بود؟ {#eip-1559}
-
-پیش از ارتقاء لندن، بلوکهای اتریوم اندازه ثابتی داشتند. در زمان تقاضای بالای شبکه، این بلوک ها با ظرفیت کامل کار می کردند. در نتیجه، کاربران عموماً باید صبر میکردند که تقاضای بالا کاهش یابد تا بتوانند در یک بلوک جای بگیرند، و این موضوع باعث میشد تجربه کاربری چندان خوب نباشد. ارتقاء لندن بلوکهای با اندازه متغیر را به اتریوم معرفی کرد.
-
-روشی که کارمزد تراکنش در شبکه اتریوم محاسبه میشد با [ارتقاء لندن](/history/#london) در اوت 2021 تغییر کرد. قبل از ارتقاء لندن، کارمزدها بدون تفکیک کارمزدهای `پایه` و `اولویت` به شرح زیر محاسبه می شد:
-
-فرض کنید آلیس باید 1 اتر به باب میپرداخت. در این تراکنش محدوده گاز برابر 21,000 واحد بود و قیمت گاز برابر 200 gwei.
-
-کارمز کلی معادل `واحد گاز (محدوده) * قیمت گاز به ازای هر واحد` یعنی 21,000 * 200 = 4,200,000 Gwei
یا 0.0042 ETH است
-
-اجرای [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) در ارتقاء لندن باعث شد که مکانیزم پرداخت کارمزد تراکنش پیچیدهتر شود، اما کارمزدهای گاز را قابل پیشبینیتر کرد که منجر به بازار کارمزد تراکنش کارآمدتر شد. کاربران میتوانند تراکنش را با یک `maxFeePerGas` مطابق با مبلغی که مایل هستند برای اجرای تراکنششان بپردازند ارسال کنند؛ با علم به این که نیازی نیست چیزی بیشتر از قیمت بازار برای گاز (`baseFeePerGas`) بپردازند، و اضافهپرداخت بیشتر از انعامشان را بازپس بگیرند.
-
-این ویدیو EIP-1559 و مزایای آن را توضیح میدهد: [EIP-1559 توضیح داده شده](https://www.youtube.com/watch?v=MGemhK9t44Q)
-
-- [آیا شما یک توسعه دهنده برنامه غیرمتمرکز (dapp) هستید؟ حتما کتابخانه ها و ابزار خود را ارتقا دهید.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md)
-- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/)
-- [توضیح دهنده اتریوم کت هدر را بخوانید](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41)
-
-
-
-
- - EIP-1559 - بازار کارمزد تراکنش را بهبود میبخشد
- - EIP-3198 -
BASEFEE
را از یک بلوک برمیگرداند
- - EIP-3529 - بازپرداخت گس را برای عملیات ماشین مجازی اتریوم (EVM) کاهش میدهد
- - EIP-3541 - از استقرار قراردادهایی که با
0xEF
شروع میشوند، جلوگیری میکند
- - EIP-3554 - عصر یخبندان را تا دسامبر 2021 به تعویق میاندازد
-
-
-
-
----
-
-
-
-### برلین {#berlin}
-
-
-
-
-
-#### خلاصه {#berlin-summary}
-
-ارتقاء برلین هزینه گس را برای برخی اقدامات ماشین مجازی اتریوم بهینه کرد و پشتیبانی از انواع مختلف تراکنش را افزایش داد.
-
-- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/)
-- [توضیح دهنده اتریوم کت هدر را بخوانید](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80)
-
-
-
-
-
-
-
-
-
-
-
-## 2020 {#2020}
-
-
-
-### ویژگی های زنجیره بیکن {#beacon-chain-genesis}
-
-
-
-
-
-#### خلاصه {#beacon-chain-genesis-summary}
-
-[بیکون زنجیره](/roadmap/beacon-chain/) برای ارسال ایمن به 16384 سپرده به 32 اتر استیک شده نیاز داشت. این اتفاق در 27 نوامبر رخ داد، به این معنی که زنجیره بیکون در 1 دسامبر 2020 شروع به تولید بلوک کرد. این اولین قدم مهم در دستیابی به [چشم انداز اتریوم](/roadmap/vision/) است.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21/)
-
-
- زنجیره بیکن
-
-
----
-
-
-
-### قرارداد واریز یا سپرده گذاری استیک دپلوی شد {#staking-deposit-contract}
-
-
-
-
-
-#### خلاصه {#deposit-contract-summary}
-
-قرارداد سپرده گذاری، [استیکینگ](/glossary/#staking) را به اکوسیستم اتریوم معرفی کرد. اگرچه یک قرارداد [شبکه اصلی](/glossary/#mainnet) بود، اما تأثیر مستقیمی بر جدول زمانی راهاندازی [زنجیره بیکون](/roadmap/beacon-chain/) داشت. a>، که یک [ارتقای مهم اتریوم](/roadmap/) است.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/)
-
-
- سهام گذاری
-
-
----
-
-
-
-### Muir Glacier {#muir-glacier}
-
-
-
-
-
-#### خلاصه {#muir-glacier-summary}
-
-فورک مویر گلاسیر(Muir Glacier) یک تاخیر برای [بمب سختی](/glossary/#difficulty-bomb) معرفی کرد. افزایش سختی بلوک مکانیزم اجماع [اثبات کار](/developers/docs/consensus-mechanisms/pow/)، با افزایش زمان انتظار برای ارسال تراکنشها و افزایش زمان انتظار برای ارسال تراکنشها و استفاده از dappها، قابلیت استفاده اتریوم را کاهش میدهد.
-
-- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/)
-- [توضیح دهنده اتریوم کت هدر را بخوانید](https://medium.com/ethereum-cat-herders/ethereum-muir-glacier-upgrade-89b8cea5a210)
-
-
-
-
- - EIP-2384 - بمب سختی را برای 4,000,000 بلوک دیگر یا تقریبا 611 روز به تاخیر میاندازد. >
-
-
-
-
-
-
-
-
-## 2019 {#2019}
-
-
-
-### استانبول {#istanbul}
-
-
-
-
-
-#### خلاصه {#istanbul-summary}
-
-فورک استانبول:
-
-- بهینه سازی هزینه [گس](/glossary/#gas) برخی اقدامات در [ماشین مجازی اتریوم](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
-- بهبود انعطاف پذیری حملات انکار سرویس (denial-of-service).
-- راهحلهای [مقیاسگذاری لایه 2](/developers/docs/scaling/#layer-2-scaling) را بر اساس SNARK و STARK کارآمدتر کرد.
-- اتریوم و Zcash را فعال کرد تا با هم همکاری کنند.
-- به قراردادهای برای معرفی عملکردهای خلاقانه تر اجازه میدهد.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/)
-
-
-
-
- - EIP-152 - به اتریوم اجازه میدهد با ارزهای حفظ حریم خصوصی مانند Zcash کار کند.
- - EIP-1108 - رمزنگاری ارزانتر برای بهبود گس هزینه ها.
- - EIP-1344 - با افزودن
CHAINID
از اتریوم در برابر حملات تکراری محافظت میکند. href="/developers/docs/ethereum-stack/#ethereum-virtual-machine">opcode.
- - EIP-1884 - قیمتهای گس آپکد بر اساس مصرف بهینهسازی میکند.
- - EIP-2028 - هزینه CallData را کاهش میدهد تا دادههای بیشتری را در بلوکها - برای مقیاسگذاری لایه 2 فراهم کند.
- - EIP-2200 - سایر تغییرات قیمت گس کد opcode.
-
-
-
-
----
-
-
-
-### قسطنطنیه {#constantinople}
-
-
-
-
-
-#### خلاصه {#constantinople-summary}
-
-فورک قسطنطنیه (Constantinople):
-
-- پاداشهای بلاک [mining](/developers/docs/consensus-mechanisms/pow/mining/) از 3 به 2 اتر کاهش یافت.
-- اطمینان حاصل شد که بلاکچین قبل از [اجرای اثبات سهام](#beacon-chain-genesis) فریز نشده است.
-- بهینه سازی هزینه [گس](/glossary/#gas) برخی اقدامات در [ماشین مجازی اتریوم](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
-- قابلیت تعامل با آدرسهایی که هنوز ایجاد نشدهاند، اضافه شده است.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/)
-
-
-
-
- - EIP-145 - هزینه برخی اقدامات روی زنجیره را بهینه میکند.
- - EIP-1014 - به شما امکان تعامل با آدرس هایی که نپزساخته نشده اند میدهد.
- - EIP-1052 - هزینه برخی اقدامات روی زنجیره را بهینه میکند.
- - EIP-1234 - اطمینان حاصل میکند که بلاک چین قبل از اثبات سهام ثابت (فریز) نمیشود و پاداش بلوک را از 3 به 2 اتر کاهش میدهد.
-
-
-
-
-
-
-
-
-## 2017 {#2017}
-
-
-
-### بیزانتیوم {#byzantium}
-
-
-
-
-
-#### خلاصه {#byzantium-summary}
-
-فورک بیزانتیوم:
-
-- پاداش[استخراج](/developers/docs/consensus-mechanisms/pow/mining/) بلوک را از ۵ به ۳ اتر کاهش داد.
-- [بمب سختی شبکه](/glossary/#difficulty-bomb)را یک سال به تاخیر انداخت.
-- توانایی ارسال درخواست به دیگر قرارداد ها بدون تغییر در وضعیت قرارداد اضافه کرد.
-- روش ها رمزنگاری معینی به پروتکل اضافه کرد تا مقیاس پذیری از طریق [لایه ۲ ](/developers/docs/scaling/#layer-2-scaling)میسر شوند.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/)
-
-
-
-
- - EIP-140 - آپکد
REVERT
را اضافه میکند.
- - EIP-658 - فیلد وضعیت به رسیدهای تراکنش اضافه شد تا موفقیت یا شکست را نشان دهد.
- - EIP-196 - منحنی بیضی و ضرب اسکالر را برای زد-کی اسنارکز اضافه میکند. ZK-Snarks.
- - EIP-197 - منحنی بیضی و ضرب اسکالر را برای زد-کی اسنارکز اضافه می کند ZK-Snarks.
- - EIP-198 - تأیید امضای RSA را فعال میکند.
- - EIP-211 - پشتیبانی از مقادیر بازگشتی طول متغیر را اضافه میکند.
- - EIP-214 - آپکد
STATICCALL
را اضافه میکند و امکان تغییر حالت را برای فراخوانی قراردادهای دیگر نمیدهد.
- - EIP-100 - فرمول تنظیم سختی شبکه را تغییر داد.
- - EIP-649 -بمب سختی شبکهزا به مدت یک سال به تعویق انداخت و پاداش بلوک ها را از ۵ اتر به ۳ اتر کاهش داد.
-
-
-
-
-
-
-
-
-## 2016 {#2016}
-
-
-
-### Spurious Dragon {#spurious-dragon}
-
-
-
-
-
-#### خلاصه {#spurious-dragon-summary}
-
-فورک اسپوروس دراگون (Spurious Dragon) دومین پاسخ به حملات انکار سرویس (DoS) در شبکه بود (سپتامبر/اکتبر 2016) از جمله:
-
-- برای جلوگیری از حملات آتی به شبکه، پرایسینگ آپکد را تنظیم میکند.
-- فعال کردن "debloat" وضعیت بلاکچین.
-- اضافه کردن محافظت در برابر حمله ارسال مجدد.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/)
-
-
-
-
- - EIP-155 - از انتشار دوباره یک تراکنش از یک شبکه اتریوم ، در یک شبکه دیگر جلوگیری میکند,به عنوان مثال تراکنشی بر روی شبکه تست نت دوباره بر روی شبکه اصلی اجرا شود.
- - EIP-160 - پرایسینگ آپکد
EXP
را تنظیم میکند - کار را برای کند کردن شبکه از طریق عملیات قراردادی گرانقیمت دشوارتر میکند.
- - EIP-161 - امکان حذف حساب های خالی اضافه شده با حمله DOS را فراهم میکند.
- - EIP-170 - بیشیبنه سایزی که کد های یک قراردادهوشمند روی زنجیره بلوکی میتواند داشته باشد را به 24576بایت تغییر میدهد.
-
-
-
-
----
-
-
-
-### Tangerine Whistle {#tangerine-whistle}
-
-
-
-
-
-#### خلاصه {#tangerine-whistle-summary}
-
-فورک Tangerine Whistle اولین پاسخ به حمله های داس سپتامبر/اکتبر۲۰۱۶ به شبکه بود که شامل:
-
-- پرداختن به مسائل فوری سلامت شبکه مربوط به کدهای عملیاتی ارزان قیمت.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/)
-
-
-
-
-
-
-
----
-
-
-
-### فورک DAO {#dao-fork}
-
-
-
-
-
-#### خلاصه {#dao-fork-summary}
-
-فورک DAO در واکنش به [حملهی DAO در سال 2016](https://www.coindesk.com/learn/understanding-the-dao-attack/) رخ داد که در آن در یک هک، یک قرارداد [DAO](/glossary/#dao) ناامن از بیش از 3.6 میلیون اتر تخلیه شد. فورک وجوه از قرارداد معیوب را به [قرارداد جدید](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) با یک عملکرد واحد منتقل کرد: برداشت. هر کسی که سرمایه خود را از دست داده میتواند به ازای هر 100 توکن DAO در کیف پول خود 1 اتر برداشت کند.
-
-این کار توسط جامعهی اتریوم رأیگیری شد. هر دارندهی اتر میتوانست از طریق یک تراکنش در یک [سکوی رأیگیری](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/) رأی بدهد. تصمیم انجام فورک بیشتر از 85% از آرا را به خود اختصاص داد.
-
-بعضی استخراج گران از فورک شبکه امتناع کردند، زیرا حادثه DAOبخاطر ایرادی در پروتکل اتریوم نبود. آنها با هم دیگر [اتریوم کلاسیک](https://ethereumclassic.org/) را ساختند.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/07/20/hard-fork-completed/)
-
-
-
----
-
-
-
-### میهن {#homestead}
-
-
-
-
-
-#### خلاصه {#homestead-summary}
-
-فورک هوم استد که به آینده مربوط است. این مورد شامل چندین تغییر پروتکل و یک تغییر شبکه بود که به اتریوم امکان ارتقای شبکه بیشتر را داد.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2016/02/29/homestead-release/)
-
-
-
-
-
-
-
-
-
-
-
-## 2015 {#2015}
-
-
-
-### ثاوینگ فرانتیر {#frontier-thawing}
-
-
-
-
-
-#### خلاصه {#frontier-thawing-summary}
-
-فورک ثاوینگ فرانتیر محدودیت 5000 [گس](/glossary/#gas) در هر [بلاک](/glossary/#block) را برداشت و قیمت پیشفرض گس را بر روی 51 قرار میدهد[gwei](/glossary/#gwei). این مورد امکان را برای تراکنشها فراهم میکند - تراکنشهایی که به 21000 گاز نیاز دارند. [بمب سختی](/glossary/#difficulty-bomb) برای اطمینان از یک هارد فورک آینده برای [اثبات سهام](/glossary/#pos) معرفی شد. .
-
-- [اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2015/08/04/the-thawing-frontier/)
-- [به روز رسانی ۱ پروتکل اتریوم را مطالعه کنید](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/)
-
-
-
----
-
-
-
-### مرز (فرانتیر) {#frontier}
-
-
-
-
-
-#### خلاصه {#frontier-summary}
-
-فرانتیر اجرا شده بود، اما پیادهسازی از پروژه اتریوم بود. فاز تست موفقیت آمیز المپیک را به دنبال داشت. این مورد برای کاربران فنی، به ویژه توسعه دهندگان در نظر گرفته شده بود. [بلوکها](/glossary/#block) دارای محدودیت [گس](/glossary/#gas) 5000 بودند. این دوره «ثاوینگ» به استخراجکنندگان این امکان را میدهد تا عملیات خود را آغاز کنند و برای پذیرندگان اولیه مشتریان خود را بدون نیاز به «عجله» نصب کنند.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare/)
-
-
-
-
-
-## 2014 {#2014}
-
-
-
-### فروش اتر {#ether-sale}
-
-
-
-اتر به طور رسمی به مدت ۴۲ روز به فروش رسید. شما میتوانستید با بیتکوین آن را بخرید.
-
-[اطلاعیه بنیاد اتریوم را بخوانید](https://blog.ethereum.org/2014/07/22/launching-the-ether-sale/)
-
-
-
----
-
-
-
-### یلو پیپر منتشر شد {#yellowpaper}
-
-
-
-یلو پیپر نوشته دکتر گاوین وود یک تعریف فنی از پروتکل اتریوم است.
-
-[مشاهده یلو پیپر](https://github.com/ethereum/yellowpaper)
-
-
-
-
-
-## 2013 {#2013}
-
-
-
-### وایت پیپر منتشر شد {#whitepaper}
-
-
-
-مقاله مقدماتی که در سال 2013 توسط ویتالیک بوترین، بنیانگذار اتریوم، قبل از راه اندازی پروژه در سال 2015 منتشر شد.
-
-
- وایت پیپر
-
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
deleted file mode 100644
index f6ff8aa65f8..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md"
+++ /dev/null
@@ -1,658 +0,0 @@
----
-title: آناتومی قراردادهای هوشمند
-description: یک نگاه عمیق به آناتومی قرارداد هوشمند - توابع، دادهها و متغیرها.
-lang: fa
----
-
-قرارداد هوشمند برنامه ای است که در آدرسی در اتریوم اجرا می شود. آنها از داده ها و توابعی تشکیل شده اند که می توانند هنگام دریافت تراکنش اجرا شوند. در اینجا یک نمای کلی از آنچه که یک قرارداد هوشمند را تشکیل می دهد آورده شده است.
-
-## پیشنیازها {#prerequisites}
-
-مطمئن شوید که ابتدا درباره [قراردادهای هوشمند](/developers/docs/smart-contracts/) بخوانید. این سند فرض می کند که شما قبلاً با زبان های برنامه نویسی مانند جاوا اسکریپت یا پایتون آشنا هستید.
-
-## دادهها {#data}
-
-هر گونه داده قرارداد باید به مکانی اختصاص داده شود: یا به `حافظه` یا `مموری`. تغییر فضای ذخیرهسازی در یک قرارداد هوشمند پرهزینه است، بنابراین باید در نظر بگیرید که داده های شما در کجا قرار دارند.
-
-### ذخیرهسازی {#storage}
-
-داده های پایدار به عنوان ذخیرهسازی نامیده می شوند و با متغیرهای وضعیت نمایش داده می شوند. این مقادیر به طور دائم در زنجیره بلوکی ذخیره می شوند. باید نوع آن را اعلام کنید تا قرارداد بتواند در هنگام کامپایل کردن زنجیره بلوکی میزان فضای ذخیرهسازی مورد نیاز خود را پیگیری کند.
-
-```solidity
-// Solidity example
-contract SimpleStorage {
- uint storedData; // State variable
- // ...
-}
-```
-
-```python
-# Vyper example
-storedData: int128
-```
-
-اگر قبلاً زبان های شیگرا را برنامه ریزی کرده اید، احتمالاً با بیشتر انواع آن آشنا خواهید بود. با این حال، اگر در توسعه اتریوم تازهکار هستید، `آدرس` باید برای شما جدید باشد.
-
-یک نوع `آدرس` میتواند یک آدرس اتریوم را که برابر با 20 بایت یا 160 بیت است، در خود جای دهد. در نماد هگزادسیمال (مبنای ۱۶) با 0x در ابتدا برمی گردد.
-
-انواع دیگر شامل موارد زیر است:
-
-- Boolean
-- عدد صحیح
-- اعداد با نقطه ثابت
-- آرایه بایتی با سایز ثابت
-- آرایه بایتی با سایز پویا
-- لیترال صحیح و منطقی
-- لیترالهای رشتهای
-- اعداد هگز
-- اینام ها
-
-برای توضیحات بیشتر نگاهی به اسناد بیاندازید:
-
-- [نوعهای Vyper را ببینید](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types)
-- [نوعهای Solidity را ببینید](https://solidity.readthedocs.io/en/latest/types.html#value-types)
-
-### مموری {#memory}
-
-مقادیری که فقط برای طول عمر اجرای یک تابع قرارداد ذخیره می شوند، متغیرهای مموری نامیده می شوند. از آنجایی که این ها به طور دائم در زنجیره بلوکی ذخیره نمی شوند، استفاده از آنها بسیار ارزانتر است.
-
-در [مستندات Solidity](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack) دربارهی چگونگی نگهداری دادهها (حافظه، مموری و پشته) در ماشین مجازی اتریوم بیاموزید.
-
-### متغیرهای محیطی {#environment-variables}
-
-علاوه بر متغیرهایی که در قرارداد خود تعریف می کنید، چند متغیر جهانی ویژه نیز وجود دارد. آنها در درجه اول برای ارائه اطلاعات در مورد زنجیره بلوکی یا تراکنش فعلی استفاده می شوند.
-
-مثال ها:
-
-| **ابزار** | **متغیر حالت** | **توضیح** |
-| ----------------- | -------------- | ------------------------------ |
-| `block.timestamp` | uint256 | برچسب زمان ایپوک بلوک فعلی |
-| `msg.sender` | آدرس | فرستندهی پیام (فراخوانی فعلی) |
-
-## توابع {#functions}
-
-به سادهترین شکل، توابع میتوانند اطلاعات دریافت کنند یا اطلاعات را در پاسخ به تراکنشهای دریافتی تنظیم کنند.
-
-دو نوع فراخوانی تابع وجود دارد:
-
-- `داخلی` - اینها یک فراخوانی ماشین مجازی اتریوم را نمیسازند
- - توابع داخلی و متغیرهای حالت فقط به صورت داخلی قابل دسترسی هستند (یعنی از داخل قرارداد فعلی یا قراردادهای ناشی از آن)
-- `خارجی` - اینها یک فراخوان ماشین مجازی اتریوم را میسازند
- - توابع خارجی بخشی از رابط قرارداد هستند، به این معنی که می توان آنها را از قراردادهای دیگر و از طریق تراکنش ها فراخوانی کرد. یک تابع خارجی `f` نمیتواند به صورت داخلی فراخوانی شود (یعنی `f()` کار نمیکند اما `this.f()` کار میکند.
-
-توابع میتوانند `عمومی` یا `خصوصی` باشند
-
-- توابع `عمومی` میتوانند به صورت داخلی از داخل قرارداد و به صورت خارجی با پیامها فراخوانی شوند
-- توابع `خصوصی` فقط برای خود قرارداد قابل مشاهده هستند و دیگر قراردادها آن را نمیبینند
-
-هم تابع ها و هم متغیرهای حالت را می توان عمومی یا خصوصی کرد
-
-در اینجا یک تابع برای به روز رسانی یک متغیر حالت در یک قرارداد آمده است:
-
-```solidity
-// Solidity example
-function update_name(string value) public {
- dapp_name = value;
-}
-```
-
-- پارامتر `value` از نوع `رشته` به تابع `update_name` داده میشود
-- به شکل `عمومی` اعلام شده، به این معنی که هر کسی میتواند به آن دسترسی داشته باشد
-- به شکل `view` اعلام نشده، بنابراین می تواند وضعیت قرارداد را تغییر دهد
-
-### توابع View {#view-functions}
-
-این توابع قرار است وضعیت داده های قرارداد را تغییر ندهند. مثالهای رایج توابع «getter» هستند – برای مثال میتوانید از آن برای دریافت موجودی کاربر استفاده کنید.
-
-```solidity
-// Solidity example
-function balanceOf(address _owner) public view returns (uint256 _balance) {
- return ownerPizzaCount[_owner];
-}
-```
-
-```python
-dappName: public(string)
-
-@view
-@public
-def readName() -> string:
- return dappName
-```
-
-آنچه حالت اصلاحی در نظر گرفته می شود:
-
-1. نوشتن بر روی متغیرهای حالت.
-2. [بیرون دادن رویدادها](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events).
-3. [ساختن دیگر قراردادها](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts).
-4. استفاده از `selfdestruct`.
-5. فرستادن اتر از طریق فراخوانیها.
-6. فراخوانی هر تابعی که `view` یا `pure` نباشد.
-7. استفاده از فراخوانیهای سطح پایین.
-8. استفاده از اسمبلی به صورت درخط که شامل کدگذاری های خاصی باشد.
-
-### توابع سازنده {#constructor-functions}
-
-توابع `constructor` فقط یک بار زمانی که قرارداد برای اولین بار ساخته میشود اجرا میشوند. مانند `constructor` در بسیاری از زبان های برنامه نویسی مبتنی بر کلاس، این توابع اغلب متغیرهای حالت را به مقادیر مشخص شده خود مقداردهی اولیه می کنند.
-
-```solidity
-// Solidity example
-// Initializes the contract's data, setting the `owner`
-// to the address of the contract creator.
-constructor() public {
- // All smart contracts rely on external transactions to trigger its functions.
- // `msg` is a global variable that includes relevant data on the given transaction,
- // such as the address of the sender and the ETH value included in the transaction.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
- owner = msg.sender;
-}
-```
-
-```python
-# Vyper example
-
-@external
-def __init__(_beneficiary: address, _bidding_time: uint256):
- self.beneficiary = _beneficiary
- self.auctionStart = block.timestamp
- self.auctionEnd = self.auctionStart + _bidding_time
-```
-
-### توابع Built-in {#built-in-functions}
-
-علاوه بر متغیرها و توابعی که در قرارداد خود تعریف می کنید، چند تابع داخلی ویژه نیز وجود دارد. بدیهیترین مثال این است:
-
-- `address.send()` - Solidity
-- `send(address)` – Vyper
-
-اینها به قراردادها اجازه می دهد اتر را به حساب های دیگر ارسال کنند.
-
-## توابع Writing {#writing-functions}
-
-تابع شما به موارد زیر نیاز دارد:
-
-- متغیر پارامتر و نوع (در صورت پذیرش پارامترها)
-- اعلامیه داخلی/خارجی
-- اعلامیهی خالص/نما/قابل پرداخت
-- نوع بازگشت ها ( اگر که مقداری را برمیگرداند)
-
-```solidity
-pragma solidity >=0.4.0 <=0.6.0;
-
-contract ExampleDapp {
- string dapp_name; // state variable
-
- // Called when the contract is deployed and initializes the value
- constructor() public {
- dapp_name = "My Example dapp";
- }
-
- // Get Function
- function read_name() public view returns(string) {
- return dapp_name;
- }
-
- // Set Function
- function update_name(string value) public {
- dapp_name = value;
- }
-}
-```
-
-یک قرارداد کامل ممکن است چیزی شبیه به این باشد. در اینجا تابع `constructor` یک مقدار اولیه برای متغیر `dapp_name` ارائه میکند.
-
-## رویدادها و گزارشها {#events-and-logs}
-
-رویدادها، قراردادهای هوشمند شما را قادر به برقراری ارتباط با فرانت اند یا سایر اپلیکیشن هایی که نیاز به کسب اطلاع از وقایع درون قرارداد هوشمند دارند می کنند. هنگامی که یک تراکنش اعتبارسنجی شده و به یک بلاک اضافه می شود، قراردادهای هوشمند می توانند رویدادها را نمایش داده و اصطلاحاً ساتع کنند و لاگ اطلاعات را چاپ کنند، بدین ترتیب فرانت اند می تواند اطلاعاتی که ساتع شده را پردازش کرده و آن را به کار بگیرد.
-
-## نمونه های مشروح {#annotated-examples}
-
-اینها نمونه هایی هستند که در Solidity نوشته شده اند. اگر میخواهید با کد بازی کنید، میتوانید در [Remix](http://remix.ethereum.org) با آنها تعامل داشته باشید.
-
-### سلام دنیا {#hello-world}
-
-```solidity
-// Specifies the version of Solidity, using semantic versioning.
-// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
-pragma solidity ^0.5.10;
-
-// Defines a contract named `HelloWorld`.
-// A contract is a collection of functions and data (its state).
-// Once deployed, a contract resides at a specific address on the Ethereum blockchain.
-// Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
-contract HelloWorld {
-
- // Declares a state variable `message` of type `string`.
- // State variables are variables whose values are permanently stored in contract storage.
- // The keyword `public` makes variables accessible from outside a contract
- // and creates a function that other contracts or clients can call to access the value.
- string public message;
-
- // Similar to many class-based object-oriented languages, a constructor is
- // a special function that is only executed upon contract creation.
- // Constructors are used to initialize the contract's data.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
- constructor(string memory initMessage) public {
- // Accepts a string argument `initMessage` and sets the value
- // into the contract's `message` storage variable).
- message = initMessage;
- }
-
- // A public function that accepts a string argument
- // and updates the `message` storage variable.
- function update(string memory newMessage) public {
- message = newMessage;
- }
-}
-```
-
-### توکن {#token}
-
-```solidity
-pragma solidity ^0.5.10;
-
-contract Token {
- // An `address` is comparable to an email address - it's used to identify an account on Ethereum.
- // Addresses can represent a smart contract or an external (user) accounts.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address
- address public owner;
-
- // A `mapping` is essentially a hash table data structure.
- // This `mapping` assigns an unsigned integer (the token balance) to an address (the token holder).
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types
- mapping (address => uint) public balances;
-
- // Events allow for logging of activity on the blockchain.
- // Ethereum clients can listen for events in order to react to contract state changes.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events
- event Transfer(address from, address to, uint amount);
-
- // Initializes the contract's data, setting the `owner`
- // to the address of the contract creator.
- constructor() public {
- // All smart contracts rely on external transactions to trigger its functions.
- // `msg` is a global variable that includes relevant data on the given transaction,
- // such as the address of the sender and the ETH value included in the transaction.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
- owner = msg.sender;
- }
-
- // Creates an amount of new tokens and sends them to an address.
- function mint(address receiver, uint amount) public {
- // `require` is a control structure used to enforce certain conditions.
- // If a `require` statement evaluates to `false`, an exception is triggered,
- // which reverts all changes made to the state during the current call.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
-
- // Only the contract owner can call this function
- require(msg.sender == owner, "You are not the owner.");
-
- // Enforces a maximum amount of tokens
- require(amount < 1e60, "Maximum issuance exceeded");
-
- // Increases the balance of `receiver` by `amount`
- balances[receiver] += amount;
- }
-
- // Sends an amount of existing tokens from any caller to an address.
- function transfer(address receiver, uint amount) public {
- // The sender must have enough tokens to send
- require(amount <= balances[msg.sender], "Insufficient balance.");
-
- // Adjusts token balances of the two addresses
- balances[msg.sender] -= amount;
- balances[receiver] += amount;
-
- // Emits the event defined earlier
- emit Transfer(msg.sender, receiver, amount);
- }
-}
-```
-
-### دارایی دیجیتال منحصربفرد {#unique-digital-asset}
-
-```solidity
-pragma solidity ^0.5.10;
-
-// Imports symbols from other files into the current contract.
-// In this case, a series of helper contracts from OpenZeppelin.
-// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files
-
-import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol";
-import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol";
-import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol";
-import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol";
-
-// The `is` keyword is used to inherit functions and keywords from external contracts.
-// In this case, `CryptoPizza` inherits from the `IERC721` and `ERC165` contracts.
-// Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance
-contract CryptoPizza is IERC721, ERC165 {
- // Uses OpenZeppelin's SafeMath library to perform arithmetic operations safely.
- // Learn more: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath
- using SafeMath for uint256;
-
- // Constant state variables in Solidity are similar to other languages
- // but you must assign from an expression which is constant at compile time.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables
- uint256 constant dnaDigits = 10;
- uint256 constant dnaModulus = 10 ** dnaDigits;
- bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;
-
- // Struct types let you define your own type
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs
- struct Pizza {
- string name;
- uint256 dna;
- }
-
- // Creates an empty array of Pizza structs
- Pizza[] public pizzas;
-
- // Mapping from pizza ID to its owner's address
- mapping(uint256 => address) public pizzaToOwner;
-
- // Mapping from owner's address to number of owned token
- mapping(address => uint256) public ownerPizzaCount;
-
- // Mapping from token ID to approved address
- mapping(uint256 => address) pizzaApprovals;
-
- // You can nest mappings, this example maps owner to operator approvals
- mapping(address => mapping(address => bool)) private operatorApprovals;
-
- // Internal function to create a random Pizza from string (name) and DNA
- function _createPizza(string memory _name, uint256 _dna)
- // The `internal` keyword means this function is only visible
- // within this contract and contracts that derive this contract
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters
- internal
- // `isUnique` is a function modifier that checks if the pizza already exists
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers
- isUnique(_name, _dna)
- {
- // Adds Pizza to array of Pizzas and get id
- uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1);
-
- // Checks that Pizza owner is the same as current user
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
-
- // note that address(0) is the zero address,
- // indicating that pizza[id] is not yet allocated to a particular user.
-
- assert(pizzaToOwner[id] == address(0));
-
- // Maps the Pizza to the owner
- pizzaToOwner[id] = msg.sender;
- ownerPizzaCount[msg.sender] = SafeMath.add(
- ownerPizzaCount[msg.sender],
- 1
- );
- }
-
- // Creates a random Pizza from string (name)
- function createRandomPizza(string memory _name) public {
- uint256 randDna = generateRandomDna(_name, msg.sender);
- _createPizza(_name, randDna);
- }
-
- // Generates random DNA from string (name) and address of the owner (creator)
- function generateRandomDna(string memory _str, address _owner)
- public
- // Functions marked as `pure` promise not to read from or modify the state
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions
- pure
- returns (uint256)
- {
- // Generates random uint from string (name) + address (owner)
- uint256 rand = uint256(keccak256(abi.encodePacked(_str))) +
- uint256(_owner);
- rand = rand % dnaModulus;
- return rand;
- }
-
- // Returns array of Pizzas found by owner
- function getPizzasByOwner(address _owner)
- public
- // Functions marked as `view` promise not to modify state
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions
- view
- returns (uint256[] memory)
- {
- // Uses the `memory` storage location to store values only for the
- // lifecycle of this function call.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack
- uint256[] memory result = new uint256[](ownerPizzaCount[_owner]);
- uint256 counter = 0;
- for (uint256 i = 0; i < pizzas.length; i++) {
- if (pizzaToOwner[i] == _owner) {
- result[counter] = i;
- counter++;
- }
- }
- return result;
- }
-
- // Transfers Pizza and ownership to other address
- function transferFrom(address _from, address _to, uint256 _pizzaId) public {
- require(_from != address(0) && _to != address(0), "Invalid address.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- require(_from != _to, "Cannot transfer to the same address.");
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
-
- ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1);
- ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1);
- pizzaToOwner[_pizzaId] = _to;
-
- // Emits event defined in the imported IERC721 contract
- emit Transfer(_from, _to, _pizzaId);
- _clearApproval(_to, _pizzaId);
- }
-
- /**
- * Safely transfers the ownership of a given token ID to another address
- * If the target address is a contract, it must implement `onERC721Received`,
- * which is called upon a safe transfer, and return the magic value
- * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
- * otherwise, the transfer is reverted.
- */
- function safeTransferFrom(address from, address to, uint256 pizzaId)
- public
- {
- // solium-disable-next-line arg-overflow
- this.safeTransferFrom(from, to, pizzaId, "");
- }
-
- /**
- * Safely transfers the ownership of a given token ID to another address
- * If the target address is a contract, it must implement `onERC721Received`,
- * which is called upon a safe transfer, and return the magic value
- * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
- * otherwise, the transfer is reverted.
- */
- function safeTransferFrom(
- address from,
- address to,
- uint256 pizzaId,
- bytes memory _data
- ) public {
- this.transferFrom(from, to, pizzaId);
- require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received.");
- }
-
- /**
- * Internal function to invoke `onERC721Received` on a target address
- * The call is not executed if the target address is not a contract
- */
- function _checkOnERC721Received(
- address from,
- address to,
- uint256 pizzaId,
- bytes memory _data
- ) internal returns (bool) {
- if (!isContract(to)) {
- return true;
- }
-
- bytes4 retval = IERC721Receiver(to).onERC721Received(
- msg.sender,
- from,
- pizzaId,
- _data
- );
- return (retval == _ERC721_RECEIVED);
- }
-
- // Burns a Pizza - destroys Token completely
- // The `external` function modifier means this function is
- // part of the contract interface and other contracts can call it
- function burn(uint256 _pizzaId) external {
- require(msg.sender != address(0), "Invalid address.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
-
- ownerPizzaCount[msg.sender] = SafeMath.sub(
- ownerPizzaCount[msg.sender],
- 1
- );
- pizzaToOwner[_pizzaId] = address(0);
- }
-
- // Returns count of Pizzas by address
- function balanceOf(address _owner) public view returns (uint256 _balance) {
- return ownerPizzaCount[_owner];
- }
-
- // Returns owner of the Pizza found by id
- function ownerOf(uint256 _pizzaId) public view returns (address _owner) {
- address owner = pizzaToOwner[_pizzaId];
- require(owner != address(0), "Invalid Pizza ID.");
- return owner;
- }
-
- // Approves other address to transfer ownership of Pizza
- function approve(address _to, uint256 _pizzaId) public {
- require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner.");
- pizzaApprovals[_pizzaId] = _to;
- emit Approval(msg.sender, _to, _pizzaId);
- }
-
- // Returns approved address for specific Pizza
- function getApproved(uint256 _pizzaId)
- public
- view
- returns (address operator)
- {
- require(_exists(_pizzaId), "Pizza does not exist.");
- return pizzaApprovals[_pizzaId];
- }
-
- /**
- * Private function to clear current approval of a given token ID
- * Reverts if the given address is not indeed the owner of the token
- */
- function _clearApproval(address owner, uint256 _pizzaId) private {
- require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- if (pizzaApprovals[_pizzaId] != address(0)) {
- pizzaApprovals[_pizzaId] = address(0);
- }
- }
-
- /*
- * Sets or unsets the approval of a given operator
- * An operator is allowed to transfer all tokens of the sender on their behalf
- */
- function setApprovalForAll(address to, bool approved) public {
- require(to != msg.sender, "Cannot approve own address");
- operatorApprovals[msg.sender][to] = approved;
- emit ApprovalForAll(msg.sender, to, approved);
- }
-
- // Tells whether an operator is approved by a given owner
- function isApprovedForAll(address owner, address operator)
- public
- view
- returns (bool)
- {
- return operatorApprovals[owner][operator];
- }
-
- // Takes ownership of Pizza - only for approved users
- function takeOwnership(uint256 _pizzaId) public {
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
- address owner = this.ownerOf(_pizzaId);
- this.transferFrom(owner, msg.sender, _pizzaId);
- }
-
- // Checks if Pizza exists
- function _exists(uint256 pizzaId) internal view returns (bool) {
- address owner = pizzaToOwner[pizzaId];
- return owner != address(0);
- }
-
- // Checks if address is owner or is approved to transfer Pizza
- function _isApprovedOrOwner(address spender, uint256 pizzaId)
- internal
- view
- returns (bool)
- {
- address owner = pizzaToOwner[pizzaId];
- // Disable solium check because of
- // https://github.com/duaraghav8/Solium/issues/175
- // solium-disable-next-line operator-whitespace
- return (spender == owner ||
- this.getApproved(pizzaId) == spender ||
- this.isApprovedForAll(owner, spender));
- }
-
- // Check if Pizza is unique and doesn't exist yet
- modifier isUnique(string memory _name, uint256 _dna) {
- bool result = true;
- for (uint256 i = 0; i < pizzas.length; i++) {
- if (
- keccak256(abi.encodePacked(pizzas[i].name)) ==
- keccak256(abi.encodePacked(_name)) &&
- pizzas[i].dna == _dna
- ) {
- result = false;
- }
- }
- require(result, "Pizza with such name already exists.");
- _;
- }
-
- // Returns whether the target address is a contract
- function isContract(address account) internal view returns (bool) {
- uint256 size;
- // Currently there is no better way to check if there is a contract in an address
- // than to check the size of the code at that address.
- // به https://ethereum.stackexchange.com/a/14016/36603 مراجعه کنید
- // برای جزئیات بیشتر در مورد نحوه کار این.
- // TODO قبل از انتشار Serenity دوباره این مورد را بررسی کنید، زیرا همه آدرس ها خواهند بود
- // سپس قرارداد می بندد.
- // solium-disable-next-line security/no-inline-assembly
- assembly {
- size := extcodesize(account)
- }
- return size > 0;
- }
-}
-```
-
-## بیشتر بخوانید {#further-reading}
-
-برای بررسی کاملتر قراردادهای هوشمند، مستندات Solidity و Vyper را بررسی کنید:
-
-- [Solidity](https://solidity.readthedocs.io/)
-- [Vyper](https://vyper.readthedocs.io/)
-
-## موضوعات مرتبط {#related-topics}
-
-- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
-- [ماشین مجازی اتریوم](/developers/docs/evm/)
-
-## آموزشهای مرتبط {#related-tutorials}
-
-- [کوچک کردن قراردادها برای مبارزه با محدودیت اندازه قرارداد](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _ – چند نکته کاربردی برای کاهش اندازه قرارداد هوشمند شما._
-- [گزارش دادههای قراردادهای هوشمند با رویدادها](/developers/tutorials/logging-events-smart-contracts/) _– مقدمهای بر رویدادهای قرارداد هوشمند و چگونگی استفاده از آنها برای ثبت داده ها_
-- [تعامل با سایر قراردادهای Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– نحوه استقرار هوشمند قرارداد از یک قرارداد موجود و تعامل با آن._
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
deleted file mode 100644
index 2cb3fbe499a..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md"
+++ /dev/null
@@ -1,282 +0,0 @@
----
-title: تدوین قرارداد هوشمند
-description: توضیحی در مورد اینکه چرا باید هوش پیمان را کامپایل کنید و کامپایل در واقع چه کاری انجام می دهد.
-lang: fa
-incomplete: true
----
-
-شما باید قرارداد خود را کامپایل کنید تا برنامه وب و ماشین مجازی اتریوم (EVM) بتوانند آن را درک کنند.
-
-## پیشنیازها {#prerequisites}
-
-شاید برای شما مفید باشد که قبل از مطالعه در مورد کامپایل، مقدمه [قراردادهای هوشمند](/developers/docs/smart-contracts/) و [ماشین مجازی اتریوم](/developers/docs/evm/) را بخوانید.
-
-## EVM {#the-evm}
-
-برای اینکه [EVM](/developers/docs/evm/) بتواند قرارداد شما را اجرا کند، باید به صورت **بایت کد** باشد. فرآیند کامپایل کردن این را:
-
-```solidity
-pragma solidity 0.4.24;
-
-contract Greeter {
-
- function greet() public constant returns (string) {
- return "Hello";
- }
-
-}
-```
-
-**به این تغییر می دهد**
-
-```
-PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900
-```
-
-اینها **آپکدها** نامیده میشوند. آپکدهای ماشین مجازی اتریوم دستورالعملهای سطح پایینی هستند که ماشین مجازی اتریوم (EVM) میتواند اجرا کند. هر کد عملیاتی یک عملیات خاص مانند عملیات حسابی، عملیات منطقی، دستکاری دادهها، جریان کنترل و غیره را نشان میدهد.
-
-[اطلاعات بیشتر در مورد کدهای عملیاتی](/developers/docs/evm/opcodes/)
-
-## برنامه های کاربردی وب {#web-applications}
-
-کامپایلر همچنین **Application Binary Interface (ABI)** را تولید می کند که برای اینکه برنامه شما بتواند یک قرارداد را درک کند و توابع قرارداد را فراخوانی کند به آن نیاز دارید.
-
-ABI یک فایل JSON است که قرارداد مستقر شده و توابع آن قرارداد هوشمند را توصیف می کند. این مورد به پر کردن شکاف بین web2 و web3 کمک می کند
-
-یک [کتابخانه کلاینتی Javascript](/developers/docs/apis/javascript/) که **ABI** را می خواند تا بتوانید قرارداد هوشمند را در رابط برنامه وب خود فراخوانی کنید.
-
-در زیر ABI برای قرارداد توکن ERC-20 آورده شده است. ERC-20 توکنی است که می توانید با آن در اتریوم معامله کنید.
-
-```json
-[
- {
- "constant": true,
- "inputs": [],
- "name": "name",
- "outputs": [
- {
- "name": "",
- "type": "string"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": false,
- "inputs": [
- {
- "name": "_spender",
- "type": "address"
- },
- {
- "name": "_value",
- "type": "uint256"
- }
- ],
- "name": "approve",
- "outputs": [
- {
- "name": "",
- "type": "bool"
- }
- ],
- "payable": false,
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [],
- "name": "totalSupply",
- "outputs": [
- {
- "name": "",
- "type": "uint256"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": false,
- "inputs": [
- {
- "name": "_from",
- "type": "address"
- },
- {
- "name": "_to",
- "type": "address"
- },
- {
- "name": "_value",
- "type": "uint256"
- }
- ],
- "name": "transferFrom",
- "outputs": [
- {
- "name": "",
- "type": "bool"
- }
- ],
- "payable": false,
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [],
- "name": "decimals",
- "outputs": [
- {
- "name": "",
- "type": "uint8"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [
- {
- "name": "_owner",
- "type": "address"
- }
- ],
- "name": "balanceOf",
- "outputs": [
- {
- "name": "balance",
- "type": "uint256"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [],
- "name": "symbol",
- "outputs": [
- {
- "name": "",
- "type": "string"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "constant": false,
- "inputs": [
- {
- "name": "_to",
- "type": "address"
- },
- {
- "name": "_value",
- "type": "uint256"
- }
- ],
- "name": "transfer",
- "outputs": [
- {
- "name": "",
- "type": "bool"
- }
- ],
- "payable": false,
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "constant": true,
- "inputs": [
- {
- "name": "_owner",
- "type": "address"
- },
- {
- "name": "_spender",
- "type": "address"
- }
- ],
- "name": "allowance",
- "outputs": [
- {
- "name": "",
- "type": "uint256"
- }
- ],
- "payable": false,
- "stateMutability": "view",
- "type": "function"
- },
- {
- "payable": true,
- "stateMutability": "payable",
- "type": "fallback"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "name": "owner",
- "type": "address"
- },
- {
- "indexed": true,
- "name": "spender",
- "type": "address"
- },
- {
- "indexed": false,
- "name": "value",
- "type": "uint256"
- }
- ],
- "name": "Approval",
- "type": "event"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "name": "from",
- "type": "address"
- },
- {
- "indexed": true,
- "name": "to",
- "type": "address"
- },
- {
- "indexed": false,
- "name": "value",
- "type": "uint256"
- }
- ],
- "name": "Transfer",
- "type": "event"
- }
-]
-```
-
-## بیشتر بخوانید {#further-reading}
-
-- [ABI spec](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _ – Solidity_
-
-## موضوعات مرتبط {#related-topics}
-
-- [کتابخانههای کلاینتی Javascript](/developers/docs/apis/javascript/)
-- [ماشین مجازی اتریوم](/developers/docs/evm/)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
deleted file mode 100644
index 17ced1fd775..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md"
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: استقرار قرارداد هوشمند
-description:
-lang: fa
----
-
-به منظور در دسترس بودن قرارداد هوشمند شما برای کاربران یک شبکه اتریوم، شما باید آن را پیادهسازی کنید.
-
-برای استقرار یک قرارداد هوشمند، شما فقط یک تراکنش اتریوم حاوی کد کامپایل شده قرارداد هوشمند را بدون تعیین هیچ گیرنده ای ارسال می کنید.
-
-## پیشنیازها {#prerequisites}
-
-شما باید [شبکهی اتریوم](/developers/docs/networks/)، [تراکنشها](/developers/docs/transactions/) و [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) را پیش از استقرار قرارداد هوشمند بدانید.
-
-پیادهسازی یک قرارداد نیز همچنین دارای هزینه اتر (ETH) است زیرا آنها بر روی زنجیرهی بلوکی ذخیره شده اند، بنابراین بایستی با مفهوم [هزینه و کارمزد](/developers/docs/gas/) بر روی اتریوم آشنا باشید.
-
-نهایتا نیاز به کامپایل کردن قرارداد خود پیش از استقرار آن دارید، پس مطمئن شوید که دربارهی [کامپایل کردن قرارداد هوشمند](/developers/docs/smart-contracts/compiling/) مطالعه کرده باشید.
-
-## چگونه یک قرارداد هوشمند را مستقر کنیم {#how-to-deploy-a-smart-contract}
-
-### آنچه نیاز خواهید داشت {#what-youll-need}
-
-- بایتکد قراردادتان - این توسط [کامپایل کردن](/developers/docs/smart-contracts/compiling/) ساخته میشود
-- اتر برای گاز - شما حد گاز خود را مانند سایر تراکنشها تعیین میکنید، بنابراین توجه داشته باشید که استقرار قرارداد به گاز بسیار بیشتری نسبت به یک انتقال ساده اتر نیاز دارد
-- یک اسکریپت یا افزونه استقرار
-- دسترسی به یک[گره اتریوم](/developers/docs/nodes-and-clients/)، با اجرای خودتان، یا اتصال به یک گره عمومی، و یا با استفاده از یک[سرویس گره](/developers/docs/nodes-and-clients/nodes-as-a-service/) از طریق یک API
-
-### گامهای استقرار یک قرارداد هوشمند {#steps-to-deploy}
-
-مراحل خاص مربوط به چارچوب توسعه مورد نظر بستگی دارد. برای مثال، میتوانید [ مستندات یا همان اسناد هاردهت در مورد استقرار قراردادهای خود](https://hardhat.org/guides/deploying.html) یا [ مستندات فاندری در مورد استقرار و تأیید قرارداد هوشمند را بررسی کنید](https://book.getfoundry.sh/forge/deploying). پس از استقرار، قرارداد شما مانند سایر [حسابها](/developers/docs/accounts/) دارای یک آدرس اتریوم خواهد بود و میتوان آن را با استفاده از ابزار تأیید کد منبع[](/developers/docs/smart-contracts/ تأیید کرد. verifying/#source-code-verification-tools).
-
-## ابزارهای مرتبط {#related-tools}
-
-**Remix - _Remix IDE امکان توسعه، استقرار و مدیریت قراردادهای هوشمند برای اتریوم مانند بلاک چین را فراهم می کند._**
-
-- [Remix](https://remix.ethereum.org)
-
-**Tenderly - _پلتفرم توسعه دهندگی در Web3 که با ارائه سرویس هایی چون دیباگ، نظارت و زیرساخت های توسعه قرارداد هوشمند توسعه، تست، نظارت، و اجرا قراردادهای هوشمند را میسر میسازد_**
-
-- [tenderly.co](https://tenderly.co/)
-- [Docs](https://docs.tenderly.co/)
-- [گیتهاب](https://github.com/Tenderly)
-- [دیسکورد](https://discord.gg/eCWjuvt)
-
-**Hardhat - _یک محیط توسعه برای کامپایل، استقرار، آزمایش و اشکال زدایی نرمافزار اتریوم شما_**
-
-- [hardhat.org](https://hardhat.org/getting-started/)
-- [مستنداتی بر استقرار قرارداد خودتان](https://hardhat.org/guides/deploying.html)
-- [گیت هاب](https://github.com/nomiclabs/hardhat)
-- [دیسکورد](https://discord.com/invite/TETZs2KK4k)
-
-**thirwenb - _با یک دستور، هر قرارداد هوشمندی را بر هر شبکه سازگار با ماشین مجازی اتریوم (EVM) به راحتی پیاده کنید_**
-
-- [اسناد](https://portal.thirdweb.com/deploy/)
-
-**کراس مینت- _پلتفرم توسعه Web3 درجه سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از API برای ایجاد، توزیع، فروش، ذخیره و ویرایش انافتی است._**
-
-- [crossmint.com](https://www.crossmint.com)
-- [اسناد](https://docs.crossmint.com)
-- [دیسکورد](https://discord.com/invite/crossmint)
-- [بلاگ](https://blog.crossmint.com)
-
-## آموزش های مرتبط {#related-tutorials}
-
-- [استقرار اولین قرارداد هوشمندتان](/developers/tutorials/deploying-your-first-smart-contract/) _- مقدمه ای برای استقرار اولین قرارداد هوشمندتان در یک شبکه آزمایشی اتریوم._
-- [ سلام دنیا! | آموزش قرارداد هوشمند](/developers/tutorials/hello-world-smart-contract/)_–آموزشی ساده برای ساخت و& پیاده کردن یک قرارداد هوشمند ابتدایی روی اتریوم._
-- [تعامل با سایر قراردادهای Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– نحوه استقرار هوشمند قرارداد از یک قرارداد موجود و تعامل با آن._
-- [چگونه اندازه قرارداد خود را کوچک کنیم](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- چگونه اندازه قرارداد خود را کاهش دهید تا آن را زیر حد مجاز نگه دارید و در مصرف گاز صرفه جویی کنید_
-
-## بیشتر بخوانید {#further-reading}
-
-- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_
-- [استقرار قراردادتان با Hardhat](https://hardhat.org/guides/deploying.html) - _Nomic Labs_
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## موضوعات مرتبط {#related-topics}
-
-- [چارچوبهای توسعه](/developers/docs/frameworks/)
-- [اجرای یک گرهی اتریوم](/developers/docs/nodes-and-clients/run-a-node/)
-- [گره-بهعنوان-خدمت](/developers/docs/nodes-and-clients/nodes-as-a-service)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
deleted file mode 100644
index f0c2ad57684..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md"
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: معرفی قراردادهای هوشمند
-description: مروری بر قراردادهای هوشمند، با تمرکز بر ویژگی ها و محدودیت های منحصر به فرد آنها.
-lang: fa
----
-
-## قراردادهای هوشمند چه هستند؟ {#what-is-a-smart-contract}
-
-«قرارداد هوشمند» به سادگی برنامه ای است که بر روی زنجیره بلوکی اتریوم اجرا می شود. مجموعه ای از کد (توابع آن) و داده ها (وضعیت آن) است که در یک آدرس خاص در زنجیره بلوکی اتریوم قرار دارد.
-
-قراردادهای هوشمند نوعی [حساب اتریوم](/developers/docs/accounts/) هستند. این بدین معنی است که آن ها میتوانند موجودی(دارایی) داشته باشند و تراکنش به آن ها ارسال شود. با این حال آنها توسط یک کاربر کنترل نمی شوند، در عوض در شبکه مستقر می شوند و طبق برنامه اجرا می شوند. سپس حسابهای کاربر میتوانند با ارسال تراکنشهایی که تابعی تعریف شده در قرارداد هوشمند را اجرا میکند، با یک قرارداد هوشمند تعامل کنند. قراردادهای هوشمند می توانند قوانینی را مانند یک قرارداد معمولی تعریف کنند و به طور خودکار آنها را از طریق کد اجرا کنند. قراردادهای هوشمند را نمی توان به طور پیش فرض حذف کرد و تعامل با آنها غیر قابل برگشت است.
-
-## پیش نیاز ها {#prerequisites}
-
-اگر تازه شروع کرده اید یا به دنبال معرفی کمتر تخصصی هستید، [معرفی قراردادهای هوشمند](/smart-contracts/) را توصیه می کنیم.
-
-مطمئن شوید که بخشهای [حسابها](/developers/docs/accounts/)، [تراکنشها](/developers/docs/transactions/) و [ماشین مجازی اتریوم](/developers/docs/evm/) را پیش از ورود به دنیای قراردادهای هوشمند خوانده باشید.
-
-## یک دستگاه فروش دیجیتال {#a-digital-vending-machine}
-
-همانطور که توسط [Nick Szabo](https://unenumerated.blogspot.com/) توضیح داده شده است، شاید بهترین استعاره برای یک قرارداد هوشمند، یک دستگاه فروش خودکار باشد. با ورودی های مناسب، خروجی مشخصی تضمین می شود.
-
-برای دریافت یک خوراکی از دستگاه فروش خودکار:
-
-```
-money + snack selection = snack dispensed
-```
-
-این منطق در ماشین فروش برنامه ریزی شده است.
-
-یک قرارداد هوشمند، مانند یک دستگاه فروش خودکار، منطق در آن برنامه ریزی شده است. مثالی ساده از یک دستگاه فروش خودکار اگر قرارداد هوشمندی به زبان سالیدیتی بود:
-
-```solidity
-pragma solidity 0.8.7;
-
-contract VendingMachine {
-
- // Declare state variables of the contract
- address public owner;
- mapping (address => uint) public cupcakeBalances;
-
- // When 'VendingMachine' contract is deployed:
- // 1. set the deploying address as the owner of the contract
- // 2. set the deployed smart contract's cupcake balance to 100
- constructor() {
- owner = msg.sender;
- cupcakeBalances[address(this)] = 100;
- }
-
- // Allow the owner to increase the smart contract's cupcake balance
- function refill(uint amount) public {
- require(msg.sender == owner, "Only the owner can refill.");
- cupcakeBalances[address(this)] += amount;
- }
-
- // Allow anyone to purchase cupcakes
- function purchase(uint amount) public payable {
- require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
- require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase");
- cupcakeBalances[address(this)] -= amount;
- cupcakeBalances[msg.sender] += amount;
- }
-}
-```
-
-قراردادهای هوشمند می توانند جایگزین واسطه ها در بسیاری از صنایع شوند، مانند اینکه چگونه یک دستگاه فروش خودکار نیاز به کارمند فروشنده را برطرف می کند.
-
-## بدون نیاز به مجوز {#permissionless}
-
-هر کسی می تواند یک قرارداد هوشمند بنویسد و آن را در شبکه مستقر کند. فقط باید یاد بگیرید که چگونه در [زبان قرارداد هوشمند](/developers/docs/smart-contracts/languages/) کدنویسی کنید، و اتر کافی برای اجرای قرارداد خود داشته باشید. پیاده سازی یک قرارداد هوشمند از نظر فنی یک تراکنش است، بنابراین باید [کارمزد](/developers/docs/gas/) خود را مانند وقتی که نیاز به پرداخت کارمزد برای انتقال ساده اتر دارید، پرداخت کنید. با این تفاوت که،کارمزد پیادهسازی یک قرارداد هوشمند بسیار بالاتر است.
-
-اتریوم دارای زبانهای مناسب برای توسعهدهندگان برای نوشتن قراردادهای هوشمند است:
-
-- Solidity
-- Vyper
-
-[بیشتر دربارهی زبانها](/developers/docs/smart-contracts/languages/)
-
-با این حال، آنها باید قبل از استقرار آنها کامپایل شوند تا ماشین مجازی اتریوم بتواند قرارداد را تفسیر و ذخیره کند. [اطلاعات بیشتر دربارهی کامپایل کردن](/developers/docs/smart-contracts/compiling/)
-
-## ترکیب پذیری {#composability}
-
-قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. این بدان معناست که می توانید قراردادهای هوشمند دیگری را در قرارداد هوشمند خود فرا بخوانید تا آنچه ممکن است را تا حد زیادی گسترش دهید. قراردادها حتی می توانند قراردادهای دیگری را مستقر کنند.
-
-دربارهی [ترکیب پذیری قرارداد هوشمند](/developers/docs/smart-contracts/composability/) بیشتر یاد بگیرید.
-
-## محدودیتها {#limitations}
-
-قراردادهای هوشمند به تنهایی نمی توانند اطلاعات مربوط به رویدادهای "دنیای واقعی" را دریافت کنند زیرا نمی توانند اطلاعاتی از منابع خارج زنجیره دریافت کنند. این بدین معنیست که نمیتوانند به اتفاقات دنیای واقعی پاسخ دهند. این بر اساس طراحی است. تکیه بر اطلاعات خارجی می تواند اجماع را که برای امنیت و تمرکززدایی مهم است، به خطر بیندازد.
-
-اما، برنامه های روی زنجیره باید بتوانند از اطلاعات خارج زنجیره استفاده کنند. راه حل آن [اوراکل ها](/developers/docs/oracles/) هستند که اطلاعات خارج زنجیره را جمع میکنند و در اختیار قراردادهای هوشمند میگذارند.
-
-یکی دیگر از محدودیت های قراردادهای هوشمند، حداکثر اندازه قرارداد است. یک قرارداد هوشمند می تواند حداکثر 24 کیلوبایت باشد وگرنه گاز آن تمام می شود. با استفاده از [الگوی الماس](https://eips.ethereum.org/EIPS/eip-2535) میتوان این موضوع را دور زد.
-
-## قراردادهای چند امضایی {#multisig}
-
-قراردادهای Multisig (چند امضایی) حسابهای قرارداد هوشمندی هستند که برای اجرای یک تراکنش به چندین امضای معتبر نیاز دارند. این مورد برای اجتناب از نقاط شکست منفرد برای قراردادهایی که مقادیر قابل توجهی اتر یا توکنهای دیگر دارند، بسیار مفید است. همچنین چند امضاییها مسئولیت اجرای قرارداد و مدیریت کلید را بین چندین طرف تقسیم میکند و از گم شدن یک کلید خصوصی که منجر به از دست دادن غیرقابل برگشت سرمایه میشود، جلوگیری میکنند. به این دلایل، قراردادهای چند امضایی را میتوان برای مدیریت ساده DAO استفاده کرد. چند امضاییها برای اجرا به N امضا از M امضای قابل قبول ممکن (که N ≤ M و M > 1) نیاز دارند. معمولاً از `N = 3، M = 5` و `N = 4، M = 7` استفاده میشود. یک چندامضایی 4/7 به چهار امضا از هفت امضای معتبر ممکن نیاز دارد. این بدان معناست که حتی اگر سه امضا از بین برود، وجوه هنوز قابل بازیابی هستند. در این مورد نیز به این معناست که اکثریت دارندگان کلید باید توافق و امضا کنند تا قرارداد اجرا شود.
-
-## منابع قرارداد هوشمند {#smart-contract-resources}
-
-**قراردادهای OpenZeppelin -** **_کتابخانهای برای توسعه قراردادهای هوشمند ایمن._**
-
-- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/)
-- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-contracts)
-- [تالار گفتگو](https://forum.openzeppelin.com/c/general/16)
-
-## بیشتر بخوانید {#further-reading}
-
-- [کوین بیس: قراردادهای هوشمند چه هستند؟](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract)
-- [چین لینک: قراردادهای هوشمند چه هستند؟](https://chain.link/education/smart-contracts)
-- [ویدیو: توضیح ساده قرارداد های هوشمند](https://youtu.be/ZE2HxTmxfrI)
-- [Cyfrin Updraft: بستر یادگیری و ممیزی Web3](https://updraft.cyfrin.io)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
deleted file mode 100644
index cb5283f2962..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md"
+++ /dev/null
@@ -1,326 +0,0 @@
----
-title: زبان های قرارداد هوشمند
-description: بررسی اجمالی و مقایسه دو زبان اصلی قرارداد هوشمند - Solidity و Vyper.
-lang: fa
----
-
-یکی از جنبههای مهم در مورد اتریوم این است که قراردادهای هوشمند میتوانند با استفاده از زبانهای نسبتاً مناسب برای توسعهدهندگان برنامهنویسی شوند. اگر با پایتون و یا هر [ زبان براکت کرلی](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages) دیگر تجربه دارید، می توانید یک زبان با ترکیب مشابه را پیدا کنید.
-
-دو زبان فعال و نگهداری شده عبارتند از:
-
-- Solidity
-- Vyper
-
-Remix IDE یک محیط توسعه جامع برای ایجاد و تست قراردادها در سالیدیتی و وایپر فراهم میکند. [برای شروع کدنویسی، محیط توسعه Remix IDE](https://remix.ethereum.org) درون مرورگر را امتحان کنید.
-
-توسعهدهندگان با تجربهتر ممکن است بخواهند از Yul یک زبان میانی برای [ماشین مجازی اتریوم](/developers/docs/evm/)، یا Yul+ افزونهای برای Yul استفاده کنند.
-
-اگر کنجکاو هستید و دوست دارید زبانهای جدیدی را آزمایش کنید که هنوز در حال توسعه هستند، میتوانید با Fe، یک زبان قرارداد هوشمند نوظهور که در حال حاضر هنوز در مراحل ابتدایی خود است، آزمایش کنید.
-
-## پیشنیازها {#prerequisites}
-
-دانش قبلی از زبان های برنامه نویسی، به ویژه جاوا اسکریپت یا پایتون، می تواند به شما کمک کند تفاوت زبان های قرارداد هوشمند را درک کنید. ما همچنین توصیه می کنیم قبل از اینکه به مقایسه عمیق زبانها بپردازید، قراردادهای هوشمند را به عنوان یک مفهوم درک کنید. معرفی [قراردادهای هوشمند](/developers/docs/smart-contracts/).
-
-## Solidity {#solidity}
-
-- زبان شیگرا و سطح بالا برای اجرای قراردادهای هوشمند.
-- زبان براکتی کرلی که عمیقترین تأثیر را از C++ گرفته است.
-- استاتیک تایپ (نوع متغیر در زمان کامپایل مشخص است).
-- موارد زیر را پشتیبانی میکند:
- - ارثبری (شما میتوانید دیگر قراردادها را بسط دهید).
- - کتابخانه ها (شما می توانید کدهای قابل استفاده مجدد ایجاد کنید که می توانید آنها را از قراردادهای مختلف فراخوانی کنید - مانند توابع استاتیک در یک کلاس ثابت در سایر زبان های برنامه نویسی شی گرا).
- - انواع پیچیده مشخصشده توسط کاربر.
-
-### پیوند های مهم {#important-links}
-
-- [مستندات](https://docs.soliditylang.org/en/latest/)
-- [پرتال زبان Solidity](https://soliditylang.org/)
-- [Solidity با مثال](https://docs.soliditylang.org/en/latest/solidity-by-example.html)
-- [گیت هاب](https://github.com/ethereum/solidity/)
-- [چت روم گیتر Solidity](https://gitter.im/ethereum/solidity) با پلی به [چت روم ماتریس Solidity](https://matrix.to/#/#ethereum_solidity:gitter.im)
-- [برگه تقلب](https://reference.auditless.com/cheatsheet)
-- [وبلاگ Solidity](https://blog.soliditylang.org/)
-- [توییتر Solidity](https://twitter.com/solidity_lang)
-
-### قرارداد نمونه {#example-contract}
-
-```solidity
-// SPDX-License-Identifier: GPL-3.0
-pragma solidity >= 0.7.0;
-
-contract Coin {
- // The keyword "public" makes variables
- // accessible from other contracts
- address public minter;
- mapping (address => uint) public balances;
-
- // Events allow clients to react to specific
- // contract changes you declare
- event Sent(address from, address to, uint amount);
-
- // Constructor code is only run when the contract
- // is created
- constructor() {
- minter = msg.sender;
- }
-
- // Sends an amount of newly created coins to an address
- // Can only be called by the contract creator
- function mint(address receiver, uint amount) public {
- require(msg.sender == minter);
- require(amount < 1e60);
- balances[receiver] += amount;
- }
-
- // Sends an amount of existing coins
- // from any caller to an address
- function send(address receiver, uint amount) public {
- require(amount <= balances[msg.sender], "Insufficient balance.");
- balances[msg.sender] -= amount;
- balances[receiver] += amount;
- emit Sent(msg.sender, receiver, amount);
- }
-}
-```
-
-این مثال باید به شما این حس را بدهد که سینتکس قرارداد Solidity چگونه است. برای جزئیات بیشتر در مورد توابع و متغیرها [مستندات را مشاهده کنید](https://docs.soliditylang.org/en/latest/contracts.html).
-
-## Vyper {#vyper}
-
-- زبان برنامه نویسی پایتونیک
-- تایپ کردن قوی
-- کد کامپایلر کوچک و قابل فهم
-- تولید بایت کد کارآمد
-- عمدا دارای ویژگی های کمتری نسبت به Solidity با هدف ایمن تر کردن قراردادها و تسهیل حسابرسی است. Vyper موارد زیر را پشتیبانی نمی کند:
- - اصلاحکنندهها
- - ارثبری
- - اسمبلی درخط
- - اضافه بار تابع
- - اضافه باز اپراتور
- - فراخوانی بازگشتی
- - لوپهای طول بینهایت
- - نقاط ثابت دوتایی
-
-برای اطلاعات بیشتر [منطق Vyper را مطالعه کنید](https://vyper.readthedocs.io/en/latest/index.html).
-
-### لینک های مهم {#important-links-1}
-
-- [مستندات](https://vyper.readthedocs.io)
-- [Vyper با مثال](https://vyper.readthedocs.io/en/latest/vyper-by-example.html)
-- [Vyper بیشتر با مثال](https://vyper-by-example.org/)
-- [گیتهاب](https://github.com/vyperlang/vyper)
-- [انجمن چت Vyper Discord](https://discord.gg/SdvKC79cJk)
-- [برگه ی تقلب](https://reference.auditless.com/cheatsheet)
-- [چارچوب ها و ابزارهای توسعه قرارداد هوشمند برای Vyper](/developers/docs/programming-languages/python/)
-- [VyperPunk - یاد بگیرید که قراردادهای هوشمند Vyper را ایمن و هک کنید](https://github.com/SupremacyTeam/VyperPunk)
-- [VyperExamples - نمونه های آسیب پذیری Vyper](https://www.vyperexamples.com/reentrancy)
-- [Vyper Hub برای توسعه](https://github.com/zcor/vyper-dev)
-- [نمونههای مهم قرارداد هوشمند Vyper](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts)
-- [منابع عالی Vyper سرپرستی شده](https://github.com/spadebuilders/awesome-vyper)
-
-### مثال {#example}
-
-```python
-# Open Auction
-
-# Auction params
-# Beneficiary receives money from the highest bidder
-beneficiary: public(address)
-auctionStart: public(uint256)
-auctionEnd: public(uint256)
-
-# Current state of auction
-highestBidder: public(address)
-highestBid: public(uint256)
-
-# Set to true at the end, disallows any change
-ended: public(bool)
-
-# Keep track of refunded bids so we can follow the withdraw pattern
-pendingReturns: public(HashMap[address, uint256])
-
-# Create a simple auction with `_bidding_time`
-# seconds bidding time on behalf of the
-# beneficiary address `_beneficiary`.
-@external
-def __init__(_beneficiary: address, _bidding_time: uint256):
- self.beneficiary = _beneficiary
- self.auctionStart = block.timestamp
- self.auctionEnd = self.auctionStart + _bidding_time
-
-# Bid on the auction with the value sent
-# together with this transaction.
-# The value will only be refunded if the
-# auction is not won.
-@external
-@payable
-def bid():
- # Check if bidding period is over.
- assert block.timestamp < self.auctionEnd
- # Check if bid is high enough
- assert msg.value > self.highestBid
- # Track the refund for the previous high bidder
- self.pendingReturns[self.highestBidder] += self.highestBid
- # Track new high bid
- self.highestBidder = msg.sender
- self.highestBid = msg.value
-
-# Withdraw a previously refunded bid. The withdraw pattern is
-# used here to avoid a security issue. If refunds were directly
-# sent as part of bid(), a malicious bidding contract could block
-# those refunds and thus block new higher bids from coming in.
-@external
-def withdraw():
- pending_amount: uint256 = self.pendingReturns[msg.sender]
- self.pendingReturns[msg.sender] = 0
- send(msg.sender, pending_amount)
-
-# End the auction and send the highest bid
-# to the beneficiary.
-@external
-def endAuction():
- # It is a good guideline to structure functions that interact
- # with other contracts (i.e. they call functions or send ether)
- # into three phases:
- # 1. checking conditions
- # 2. performing actions (potentially changing conditions)
- # 3. interacting with other contracts
- # If these phases are mixed up, the other contract could call
- # back into the current contract and modify the state or cause
- # effects (ether payout) to be performed multiple times.
- # If functions called internally include interaction with external
- # contracts, they also have to be considered interaction with
- # external contracts.
-
- # 1. Conditions
- # Check if auction endtime has been reached
- assert block.timestamp >= self.auctionEnd
- # Check if this function has already been called
- assert not self.ended
-
- # 2. Effects
- self.ended = True
-
- # 3. Interaction
- send(self.beneficiary, self.highestBid)
-```
-
-این مثال باید به شما این حس را بدهد که سینتکس قرارداد Vyper چگونه است. برای جزئیات بیشتر در مورد توابع و متغیرها [مستندات را مشاهده کنید](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction).
-
-## Yul و +Yul {#yul}
-
-اگر به تازگی وارد اتریوم شده اید و هنوز هیچ کدنویسی با زبان های قرارداد هوشمند انجام نداده اید، توصیه می کنیم با Solidity یا Vyper شروع کنید. فقط زمانی به Yul یا +Yul نگاه کنید که با بهترین روشهای امنیتی قرارداد هوشمند و ویژگیهای کار با EVM آشنا شدید.
-
-**Yul**
-
-- زبان میانی برای اتریوم.
-- از [ماشین مجازی اتریوم](/developers/docs/evm) و [Ewasm](https://github.com/ewasm)، یک WebAssembly با طعم اتریوم، پشتیبانی می کند و طراحی شده تا مخرج مشترک قابل استفاده هر دو پلتفرم باشد.
-- هدف خوبی برای مراحل بهینهسازی سطح بالا است که میتواند برای هر دو پلتفرم ماشین مجازی اتریوم و Ewasm به طور یکسان مفید باشد.
-
-**+Yul**
-
-- یک برنامه افزودنی سطح پایین و بسیار کارآمد برای Yul.
-- در ابتدا برای یک قرارداد [رول آپ خوش بینانه](/developers/docs/scaling/optimistic-rollups/) طراحی شد.
-- +Yul را میتوان بهعنوان پیشنهاد ارتقای آزمایشی Yul در نظر گرفت و ویژگیهای جدیدی را به آن اضافه کرد.
-
-### پیوند های مهم {#important-links-2}
-
-- [مستندات Yul](https://docs.soliditylang.org/en/latest/yul.html)
-- [مستندات +Yul](https://github.com/fuellabs/yulp)
-- [زمین بازی +Yul](https://yulp.fuel.sh/)
-- [پست معرفی +Yul](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f)
-
-### قرارداد نمونه {#example-contract-2}
-
-مثال ساده زیر یک تابع توان را پیادهسازی می کند. میتواند با استفاده از `solc --strict-assembly --bin input.yul` کامپایل شود. مثال باید در فایل input.yul ذخیره شود.
-
-```
-{
- function power(base, exponent) -> result
- {
- switch exponent
- case 0 { result := 1 }
- case 1 { result := base }
- default
- {
- result := power(mul(base, base), div(exponent, 2))
- if mod(exponent, 2) { result := mul(base, result) }
- }
- }
- let res := power(calldataload(0), calldataload(32))
- mstore(0, res)
- return(0, 32)
-}
-```
-
-اگر قبلاً در قراردادهای هوشمند تجربه خوبی دارید، پیادهسازی کامل ERC20 در Yul را میتوانید در [اینجا](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example) پیدا کنید.
-
-## Fe {#fe}
-
-- زبان تایپ ایستا برای ماشین مجازی اتریوم (EVM).
-- با الهام از پایتون و Rust.
-- هدف این است که یادگیری آسان باشد -- حتی برای توسعه دهندگانی که به تازگی وارد اکوسیستم اتریوم شده اند.
-- توسعه Fe هنوز در مراحل اولیه خود است، این زبان در ژانویه 2021 انتشار نسخه آلفای خود را داشت.
-
-### پیوند های مهم {#important-links-3}
-
-- [گیتهاب](https://github.com/ethereum/fe)
-- [اطلاعیه Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/)
-- [نقشهی راه ۲۰۲۱ Fe](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg)
-- [چت دیسکورد Fe](https://discord.com/invite/ywpkAXFjZH)
-- [توییتر Fe](https://twitter.com/official_fe)
-
-### قرارداد نمونه {#example-contract-3}
-
-در زیر یک قرارداد ساده اجرا شده در Fe است.
-
-```
-type BookMsg = bytes[100]
-
-contract GuestBook:
- pub guest_book: map
-
- event Signed:
- book_msg: BookMsg
-
- pub def sign(book_msg: BookMsg):
- self.guest_book[msg.sender] = book_msg
-
- emit Signed(book_msg=book_msg)
-
- pub def get_msg(addr: address) -> BookMsg:
- return self.guest_book[addr].to_mem()
-
-```
-
-## چگونه انتخاب کنیم {#how-to-choose}
-
-مانند هر زبان برنامه نویسی دیگری، بیشتر در مورد انتخاب ابزار مناسب برای کار مناسب و همچنین ترجیحات شخصی است.
-
-اگر هنوز هیچ یک از زبان ها را امتحان نکرده اید، چند نکته را در نظر بگیرید:
-
-### چه چیز دربارهی Solidity عالی است؟ {#solidity-advantages}
-
-- اگر مبتدی هستید، آموزش ها و ابزارهای یادگیری زیادی وجود دارد. در بخش [آموزش با برنامهنویسی](/developers/learning-tools/) اطلاعات بیشتری در مورد آن ببینید.
-- ابزار توسعه دهنده خوب در دسترس است.
-- Solidity یک جامعه توسعه دهندگان بزرگ دارد، به این معنی که به احتمال زیاد پاسخ سوالات خود را خیلی سریع پیدا خواهید کرد.
-
-### چه چیز دربارهی Vyper عالی است؟ {#vyper-advatages}
-
-- راه عالی برای شروع برای توسعه دهندگان پایتون که می خواهند قراردادهای هوشمند بنویسند.
-- Vyper تعداد کمتری ویژگی دارد که آن را برای نمونه سازی سریع ایده ها عالی می کند.
-- هدف Vyper این است که برای ممیزی آسان و برای انسان حداکثر خوانا باشد.
-
-### چه چیزی در مورد Yul و +Yul عالی است؟ {#yul-advantages}
-
-- زبان سطح پایین ساده و کاربردی.
-- اجازه می دهد تا به EVM خام نزدیک تر شوید، که می تواند به بهینهسازی مصرف گاز در قراردادهای شما کمک کند.
-
-## مقایسههای زبان {#language-comparisons}
-
-برای مقایسه ترکیب اولیه، چرخه عمر قرارداد، رابط ها، عملگر ها، ساختارهای داده، توابع، جریان کنترل و موارد دیگر، این [برگه تقلب از Auditless](https://reference.auditless.com/cheatsheet/) را بررسی کنید
-
-## اطلاعات بیشتر {#further-reading}
-
-- [کتابخانه قراردادهای Solidity از OpenZeppelin](https://docs.openzeppelin.com/contracts)
-- [Solidity با مثال](https://solidity-by-example.org)
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
deleted file mode 100644
index c8381e55810..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md"
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: کتابخانه های قرارداد هوشمند
-description:
-lang: fa
----
-
-لازم نیست هر قرارداد هوشمندی را در پروژه خود از ابتدا بنویسید. بسیاری از کتابخانههای قراردادهای هوشمند منبع باز موجود هستند که بلوکهای ساختن قابل استفاده مجدد را برای پروژه شما فراهم میکنند که میتواند شما را از اختراع مجدد چرخ نجات دهد.
-
-## پیشنیازها {#prerequisites}
-
-قبل از ورود به کتابخانه های قرارداد هوشمند، ایده خوبی است که درک خوبی از ساختار قرارداد هوشمند داشته باشید. اگر هنوز این کار را نکردهاید، به [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) بروید.
-
-## در یک کتابخانه چه چیز است؟ {#whats-in-a-library}
-
-معمولاً میتوانید دو نوع بلوک ساختن را در کتابخانههای قراردادهای هوشمند بیابید: رفتارهای قابل استفاده مجدد که میتوانید به قراردادهای خود اضافه کنید، و اجرای استانداردهای مختلف.
-
-### رفتارها {#behaviors}
-
-هنگام نوشتن قراردادهای هوشمند، این احتمال وجود دارد که شما بارها و بارها الگوهای مشابهی را بنویسید، مانند اختصاص یک آدرس _ادمین_ برای انجام عملیات محافظت شده در یک قرارداد، یا افزودن دکمه _مکث_ اضطراری در صورت بروز مشکل غیرمنتظره.
-
-کتابخانههای قراردادهای هوشمند معمولاً پیادهسازیهای قابل استفاده مجدد از این رفتارها را بهعنوان [کتابخانهها](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) یا [ارثبری](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) در Solidity ارائه میکنند.
-
-به عنوان یک مثال، یک نسخهی سادهشده از [قرارداد `قابل تصاحب`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) از [کتابخانهی قراردادهای OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts) را دنبال کنید که یک آدرس را به عنوان مالک قرارداد تعیین می کند و یک اصلاح کننده برای محدود کردن دسترسی به یک روش فقط به آن مالک ارائه می دهد.
-
-```solidity
-contract Ownable {
- address public owner;
-
- constructor() internal {
- owner = msg.sender;
- }
-
- modifier onlyOwner() {
- require(owner == msg.sender, "Ownable: caller is not the owner");
- _;
- }
-}
-```
-
-برای استفاده از یک بلوک مانند این در قرارداد خود، باید ابتدا آن را وارد کنید، و سپس آن را در قراردادهای خود بسط دهید. این به شما امکان می دهد از اصلاح کننده ارائه شده توسط قرارداد پایه `Ownable` برای ایمنسازی توابع خود استفاده کنید.
-
-```solidity
-import ".../Ownable.sol"; // Path to the imported library
-
-contract MyContract is Ownable {
- // The following function can only be called by the owner
- function secured() onlyOwner public {
- msg.sender.transfer(1 ether);
- }
-}
-```
-
-یک مثال محبوب دیگر [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) یا [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html) است. اینها کتابخانههایی هستند (برخلاف قراردادهای پایه) که توابع حسابی را با بررسیهای سرریز ارائه میکنند که توسط زبان ارائه نمیشود. استفاده از هر یک از این کتابخانه ها به جای عملیات محاسباتی بومی برای محافظت از قرارداد شما در برابر سرریزها، که می تواند عواقب فاجعه باری داشته باشد، تمرین خوبی است!
-
-### استانداردها {#standards}
-
-برای تسهیل [ترکیب پذیری و قابلیت همکاری](/developers/docs/smart-contracts/composability/)، جامعهی اتریوم چند استاندارد به شکل **ERCها** طراحی کرده است. شما میتوانید دربارهی آنها در بخش [استانداردها](/developers/docs/standards/) بیشتر بخوانید.
-
-هنگامی که یک ERC را به عنوان بخشی از قراردادهای خود درج می کنید، ایده خوبی است که به جای اجرای پیادهسازی های خود، به دنبال پیادهسازی های استاندارد باشید. بسیاری از کتابخانه های قراردادهای هوشمند شامل پیادهسازی هایی برای محبوب ترین ERC ها هستند. برای مثال [استاندارد توکنهای قابل معاوضه ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) که همهجا وجود دارد میتوانند در [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)، [DappSys](https://github.com/dapphub/ds-token/) و [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) یافت شوند. علاوه بر این، برخی از ERC ها نیز پیادهسازی های متعارف را به عنوان بخشی از خود ERC ارائه می دهند.
-
-شایان ذکر است که برخی از ERC ها مستقل نیستند، بلکه اضافه شده به سایر ERC ها هستند. برای مثال، [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) یک افزونهای به ERC20 برای بهبود استفادهاش اضافه میکند.
-
-## چگونه یک کتابخانه اضافه کنیم {#how-to}
-
-برای دستورالعملهای خاص در مورد نحوه گنجاندن کتابخانه در پروژه، همیشه به مستندات کتابخانهای که اضافه میکنید مراجعه کنید. چندین کتابخانه قرارداد Solidity با استفاده از `npm` بسته بندی شده اند، بنابراین شما می توانید آنها را `npm install` کنید. بیشتر ابزارهای [کامپایل کردن](/developers/docs/smart-contracts/compiling/) قراردادها، به `node_modules` برای کتابخانههای قرارداد هوشمند نگاه میکنند، در نتیجه شما میتوانید به روش زیر عمل کنید:
-
-```solidity
-// This will load the @openzeppelin/contracts library from your node_modules
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-
-contract MyNFT is ERC721 {
- constructor() ERC721("MyNFT", "MNFT") public { }
-}
-```
-
-صرف نظر از روشی که استفاده میکنید، هنگام گنجاندن کتابخانه، همیشه به نسخه [زبان](/developers/docs/smart-contracts/languages/) توجه داشته باشید. به عنوان مثال، اگر قراردادهای خود را در Solidity 0.5 می نویسید، نمی توانید از کتابخانه برای Solidity 0.6 استفاده کنید.
-
-## چه زمانی استفاده کنیم {#when-to-use}
-
-استفاده از کتابخانه قرارداد هوشمند برای پروژه شما مزایای متعددی دارد. اول از همه، با ارائه بلوکهای ساخت آمادهای که میتوانید در سیستم خود بگنجانید، در وقت شما صرفهجویی میکند، نه اینکه خودتان آنها را کدنویسی کنید.
-
-امنیت نیز یک مزیت اصلی است. کتابخانه های قراردادهای هوشمند منبع باز نیز اغلب به شدت مورد بررسی قرار می گیرند. با توجه به اینکه بسیاری از پروژهها به آنها وابسته هستند، جامعه انگیزه زیادی برای نگه داشتن آنها تحت بررسی دائمی دارد. یافتن خطا در کد برنامه بسیار رایج تر از کتابخانه های قراردادی قابل استفاده مجدد است. برخی از کتابخانهها نیز برای امنیت بیشتر تحت [ممیزیهای خارجی](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) قرار میگیرند.
-
-با این حال، استفاده از کتابخانههای قرارداد هوشمند خطر گنجاندن کدهایی را که با آنها آشنا نیستید در پروژه خود به همراه دارد. وسوسه انگیز است که یک قرارداد را وارد کنید و آن را مستقیماً در پروژه خود شامل کنید، اما بدون درک خوب از آنچه آن قرارداد انجام می دهد، ممکن است به دلیل یک رفتار غیرمنتظره به طور ناخواسته مشکلی را در سیستم خود وارد کنید. همیشه مطمئن شوید که مستندات کدی را که وارد میکنید بخوانید و سپس قبل از اینکه آن را بخشی از پروژه خود کنید، خود کد را بررسی کنید!
-
-در آخر، هنگام تصمیم گیری در مورد گنجاندن کتابخانه، استفاده کلی از آن را در نظر بگیرید. یک مورد که به طور گسترده پذیرفته شده است و دارای مزایای داشتن یک جامعه بزرگتر و افراد بیشتر در آن برای رسیدگی به مسائل است. هنگام ساخت با قراردادهای هوشمند، امنیت باید تمرکز اصلی شما باشد!
-
-## ابزارهای مرتبط {#related-tools}
-
-**قراردادهای OpenZeppelin -** **_محبوب ترین کتابخانه برای توسعه قراردادهای هوشمند ایمن._**
-
-- [مستندات](https://docs.openzeppelin.com/contracts/)
-- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-contracts)
-- [انجمن گفتگو](https://forum.openzeppelin.com/c/general/16)
-
-**DappSys -** **_بلوک های ساخت ایمن، ساده و انعطافپذیر برای قراردادهای هوشمند._**
-
-- [مستندات](https://dappsys.readthedocs.io/)
-- [گیت هاب](https://github.com/dapphub/dappsys)
-
-**HQ20 -** **_یک پروژه Solidity با قراردادها، کتابخانه ها و نمونه هایی که به شما کمک می کند تا برنامه های کاربردی توزیع شده با ویژگی های کامل را برای دنیای واقعی بسازید._**
-
-- [گیت هاب](https://github.com/HQ20/contracts)
-
-**کیت توسعه نرمافزار سالیدیتی Thirdweb-****_ ابزار های لازم برای ساخت قراردادهای هوشمند بهینه و مؤثر را در اختیار توسعه دهندگان میگذارد_**
-
-- [اسناد](https://portal.thirdweb.com/solidity/)
-- [گیت هاب](https://github.com/thirdweb-dev/contracts)
-
-## آموزش های مرتبط {#related-tutorials}
-
-- [ملاحظات امنیتی برای توسعه دهندگان اتریوم](/developers/docs/smart-contracts/security/) _- آموزشی در مورد ملاحظات امنیتی هنگام ساخت قراردادهای هوشمند، از جمله استفاده از کتابخانه._
-- [فهم قرارداد هوشمند توکن ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _- آموزشی بر استاندارد ERC20، فراهم شده توسط چندین کتابخانه._
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" "b/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
deleted file mode 100644
index 9ea1fe4f85d..00000000000
--- "a/public/content/translations/fa/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md"
+++ /dev/null
@@ -1,580 +0,0 @@
----
-title: امنیت قرارداد هوشمند
-description: مروری بر دستورالعملهای ساخت قراردادهای هوشمند ایمن در اتریوم
-lang: fa
----
-
-قراردادهای هوشمند بسیار انعطافپذیر هستند و می توانند مقادیر زیادی از ارزش و داده را کنترل کنند، در حالی که منطق تغییرناپذیر مبتنی بر کد مستقر در بلاک چین را اجرا می کنند. این یک اکوسیستم پر جنب و جوش از برنامه های کاربردی بی نیاز از اعتماد و غیرمتمرکز ایجاد کرده است که مزایای زیادی را نسبت به سیستم های قدیمی ارائه می دهد. آنها همچنین فرصتهایی را برای مهاجمانی که به دنبال سودجویی از طریق سوءاستفاده از آسیبپذیریها در قراردادهای هوشمند هستند، نشان میدهند.
-
-بلاک چین های عمومی، مانند اتریوم، مسئله ایمنسازی قراردادهای هوشمند را پیچیدهتر و سختتر می کند. _معمولا_ پس از استقرار کد قرارداد در شبکه، نمیتوان آن را به منظور رفع نقص های امنیتی را تغییر داد، در حالی که ردیابی دارایی های دزدیده شده از قراردادهای هوشمند بسیار دشوار است و عمدتاً به دلیل تغییر ناپذیری قابل بازیابی نیستند.
-
-اگرچه اعداد و ارقام متفاوت است، تخمین زده می شود که کل ارزش سرقت شده یا از دست رفته به دلیل نقص امنیتی در قراردادهای هوشمند به راحتی بیش از یک میلیارد دلار است. این شامل حوادث پرمخاطب، مانند [هک DAO](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3.6M اتریوم دزدیده شده، به ارزش بیش از 1 میلیارد دلار در قیمت های امروزی)، [هک کیف پول چند علامتی Parity ](https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach) (30 میلیون دلار از دست هکرها) و [ مشکل کیف پول منجمد شده](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (بیش از 300 میلیون دلار ETH برای همیشه قفل شده است).
-
-مسائل ذکر شده، توسعه دهندگان را مجبور میکند تا تلاش کنند قراردادهای هوشمند ایمن، نبوغ آمیز و منعطف بسازند. امنیت قراردادهای هوشمند یک تجارت جدی است و هر توسعهدهندهای باید آن را یاد بگیرد. این راهنما ملاحظات امنیتی برای توسعه دهندگان اتریوم را پوشش می دهد و منابعی را برای بهبود امنیت قراردادهای هوشمند بررسی می کند.
-
-## پیشنیازها {#prerequisites}
-
-قبل از پرداختن به امنیت، مطمئن شوید که با [مبانی توسعه قرارداد هوشمند](/developers/docs/smart-contracts/) آشنا هستید.
-
-## دستورالعمل هایی برای ساخت قراردادهای هوشمند ایمن در اتریوم {#smart-contract-security-guidelines}
-
-### 1. کنترل های دسترسی طراحی مناسب {#design-proper-access-controls}
-
-در قراردادهای هوشمند، عملکردهایی که `public` یا `external` علامتگذاری شدهاند، میتوانند توسط هر حساب تحت مالکیت خارجی (EOA) یا حساب قراردادی فراخوانی شوند. اگر میخواهید دیگران با قرارداد شما در تعامل باشند، مشخص کردن نمای عمومی برای عملکردها ضروری است. با این حال، عملکردهایی که با `private` علامتگذاری شدهاند، فقط توسط توابع داخل قرارداد هوشمند فراخوانی میشوند و در حسابهای خارجی مورد استفاده قرار نمی گیرند. دادن دسترسی به هر یک از شرکتکنندگان شبکه به توابع قرارداد میتواند باعث ایجاد مشکلاتی شود، بهویژه اگر به این معنی باشد که هر کسی بتواند عملیات حساس را انجام دهد (به عنوان مثال، استخراج توکنهای جدید).
-
-برای جلوگیری از استفاده غیرمجاز از توابع قرارداد هوشمند، لازم است کنترل های دسترسی ایمن را اجرا کنید. مکانیسمهای کنترل دسترسی، توانایی استفاده از عملکردهای خاص در یک قرارداد هوشمند را به نهادهای تایید شده، مانند حسابهای مسئول مدیریت قرارداد، محدود میکند. **الگوی مالکیت** و **کنترل مبتنی بر نقش** دو الگوی مفید برای اجرای کنترل دسترسی در قراردادهای هوشمند هستند:
-
-#### الگوی قابل مالکیت {#ownable-pattern}
-
-در الگویل قابل مالکیت، یک آدرس به عنوان "مالک" قرارداد در طول فرآیند ایجاد قرارداد تنظیم می شود. به توابع محافظت شده یک اصلاحکننده `OnlyOwner` اختصاص داده میشود، که تضمین میکند قرارداد قبل از اجرای تابع، هویت آدرس تماس را تأیید میکند. تماسهای توابع محافظتشده از آدرسهای دیگر به غیر از مالک قرارداد، همیشه برمیگردند و از دسترسی ناخواسته جلوگیری میکنند.
-
-#### کنترل دسترسی مبتنی بر نقش {#role-based-access-control}
-
-ثبت یک آدرس واحد بهعنوان `Owner` در یک قرارداد هوشمند، خطر تمرکز را معرفی میکند و نشاندهنده یک نقطه شکست واحد است. اگر کلیدهای حساب مالک به خطر بیفتد، مهاجمان می توانند به قرارداد مالکیت حمله کنند. به همین دلیل است که استفاده از الگوی کنترل دسترسی مبتنی بر نقش با چندین حساب اداری ممکن است گزینه بهتری باشد.
-
-در کنترل دسترسی مبتنی بر نقش، دسترسی به عملکردهای حساس بین مجموعه ای از شرکت کنندگان قابل اعتماد توزیع می شود. به عنوان مثال، یک حساب ممکن است مسئول ضرب توکن ها باشد، در حالی که حساب دیگری ارتقاء داده یا قرارداد را متوقف می کند. غیرمتمرکز کردن کنترل دسترسی به این روش، نقاط منفرد شکست را از بین می برد و مفروضات اعتماد را برای کاربران کاهش می دهد.
-
-##### استفاده از کیف پولهای چند امضایی
-
-روش دیگر برای اجرای کنترل دسترسی ایمن استفاده از [حساب چند امضایی](/developers/docs/smart-contracts/#multisig) برای مدیریت قرارداد است. برخلاف یک EOA معمولی، حسابهای چند امضایی متعلق به چندین نهاد هستند و برای انجام تراکنشها به امضای حداقل تعداد حسابها (مثلاً 3 از 5) نیاز دارند.
-
-استفاده از مالتی سیگ برای کنترل دسترسی، یک لایه امنیتی اضافی را معرفی میکند زیرا اقدامات روی قرارداد هدف مستلزم رضایت چندین طرف است. این مورد به ویژه در صورتی مفید است که استفاده از الگوی اونبل (Ownable) ضروری باشد، زیرا دستکاری عملکردهای حساس قرارداد برای اهداف مخرب را برای مهاجم دشوارتر میکند.
-
-### 2. برای محافظت از عملیات قرارداد از عبارات require() و assert() و revert() استفاده کنید {#use-require-assert-revert}
-
-همانطور که گفته شد، هر کسی میتواند توابع عمومی را در قرارداد هوشمند شما پس از استقرار در بلاکچین فراخوانی کند. از آنجایی که نمیتوانید از قبل بدانید حسابهای خارجی چگونه با یک قرارداد تعامل خواهند داشت، بهتراست که قبل از استقرار، حفاظتهای داخلی در برابر عملیات مشکلساز را اجرا کنید. میتوانید با استفاده از دستورات `require()`، `assert()` و `revert()` رفتار صحیح را در قراردادهای هوشمند برای راهاندازی استثناها و برگرداندن تغییرات حالت اعمال کنید، در صورتی که اجرا نتواند الزامات خاصی را برآورده کند.
-
-**`require()`**: دستورها `require` در شروع توابع تعریف میشوند و اطمینان میدهند که شرایط از پیش تعریف شده قبل از اجرای تابع فراخوانی شده برآورده میشوند. یک عبارت `require` را میتوان برای اعتبارسنجی ورودی های کاربر، بررسی متغیرهای حالت، یا احراز هویت حساب فراخوان قبل از پیشرفت با یک تابع استفاده کرد.
-
-**`assert()`**: دستور `assert()` برای شناسایی خطاهای داخلی و بررسی نقض "invariants" در کد شما استفاده می شود. یک invariant یک ادعای منطقی در مورد وضعیت قرارداد است که باید برای اجرای همه توابع صادق باشد. یک مثال ثابت، حداکثر عرضه یا موجودی یک قرارداد توکن است. استفاده از `assert()` تضمین میکند که قرارداد شما هرگز به یک وضعیت آسیبپذیر نمیرسد، و در صورت رسیدن، همه تغییرات در متغیرهای حالت برگردانده میشوند.
-
-**`revert()`**: دستور `revert()` را می توان در یک عبارت if-else استفاده کرد که در صورت عدم رعایت شرایط مورد نیاز، یک استثنا ایجاد می کند. قرارداد نمونه زیر از `revert()` برای محافظت از اجرای توابع استفاده می کند:
-
-```
-pragma solidity ^0.8.4;
-
-contract VendingMachine {
- address owner;
- error Unauthorized();
- function buy(uint amount) public payable {
- if (amount > msg.value / 2 ether)
- revert("Not enough Ether provided.");
- // Perform the purchase.
- }
- function withdraw() public {
- if (msg.sender != owner)
- revert Unauthorized();
-
- payable(msg.sender).transfer(address(this).balance);
- }
-}
-```
-
-### 3. قراردادهای هوشمند را تست کنید و صحت کد را تأیید کنید {#test-smart-contracts-and-verify-code-correctness}
-
-تغییرناپذیری کدهای در حال اجرا در [ماشین مجازی اتریوم](/developers/docs/evm/) به این معنی است که قراردادهای هوشمند سطح بالاتری از ارزیابی کیفیت را در مرحله توسعه می طلبد. تست قرارداد خود به طور گسترده و مشاهده آن برای نتایج غیرمنتظره امنیت را تا حد زیادی بهبود میبخشد و در دراز مدت از کاربران شما محافظت میکند.
-
-روش معمول نوشتن تستهای واحد کوچک با استفاده از دادههای ساختگی است که انتظار میرود قرارداد را از کاربران دریافت کند. [آزمایش Unit ](/developers/docs/smart-contracts/testing/#unit-testing) برای آزمایش عملکرد عملکردهای خاص و اطمینان از اینکه قرارداد هوشمند مطابق انتظار عمل می کند خوب است.
-
-متأسفانه، تست واحد برای بهبود امنیت قراردادهای هوشمند زمانی که به صورت مجزا مورد استفاده قرار میگیرد، حداقل مؤثر است. یک تست واحد ممکن است ثابت کند که یک تابع برای دادههای ساختگی به درستی اجرا میشود، اما تستهای واحد فقط به اندازه تستهای نوشته شده مؤثر هستند. این امر تشخیص موارد لبه از دست رفته و آسیب پذیری هایی را که می تواند ایمنی قرارداد هوشمند شما را به هم بزند، دشوار می کند.
-
-یک رویکرد بهتر ترکیب آزمایش واحد با آزمایش مبتنی بر ویژگی است که با استفاده از [تحلیل استاتیک و پویا](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) انجام میشود. تجزیه و تحلیل استاتیک بر نمایشهای سطح پایین، مانند [گرافهای جریان کنترل](https://en.wikipedia.org/wiki/Control-flow_graph) و [درختهای نحو انتزاعی](https:// deepsource.io/glossary/ast/) برای تجزیه و تحلیل وضعیتهای قابل دسترسی برنامه و مسیرهای اجرا. در همین حال، تکنیکهای تحلیل پویا، مانند [فازی قرارداد هوشمند](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)، قرارداد را اجرا میکنند. کد با مقادیر ورودی تصادفی برای شناسایی عملیاتی که ویژگیهای امنیتی را نقض میکند.
-
-[تأیید رسمی](/developers/docs/smart-contracts/formal-verification) تکنیک دیگری برای تأیید ویژگیهای امنیتی در قراردادهای هوشمند است. برخلاف تستهای معمولی، تأیید رسمی میتواند به طور قطعی عدم وجود خطا در یک قرارداد هوشمند را ثابت کند. این امر با ایجاد یک مشخصات رسمی که ویژگیهای امنیتی مورد نظر را نشان میدهد و اثبات اینکه مدل رسمی قراردادها به این مشخصات پایبند است، به دست میآید.
-
-### 4. درخواست بررسی مستقل کد خود را داشته باشید {#get-independent-code-reviews}
-
-پس از تست قرارداد خود، بهتر است از دیگران بخواهید که کد منبع را برای هرگونه مشکل امنیتی بررسی کنند. تست تمام ایرادات یک قرارداد هوشمند را آشکار نمیکند، اما دریافت یک بررسی مستقل امکان شناسایی آسیب پذیریها را افزایش میدهد.
-
-#### حسابرسیهای امنیتی {#audits}
-
-راهاندازی آدیت قرارداد هوشمند یکی از راههای انجام بررسی مستقل کد است. حسابرسان یا آدیتورها نقش مهمی در حصول اطمینان از ایمن بودن قراردادهای هوشمند و عاری از نقص کیفی و خطاهای طراحی دارند.
-
-با وجود همهی این موارد، شما نباید با حسابرسی امنیتی مانند پاسخی برای تمام مشکلات برخورد کنید. آدیت قراردادهای هوشمند هر اشکالی را شناسایی نمیکند و عمدتاً برای ارائه یک سری بررسی اضافی طراحی شده است که میتواند به شناسایی مشکلاتی که توسعه دهندگان در طول توسعه و تست اولیه از قلم انداختهاند کمک کند. همچنین باید بهترین روشها را برای کار با حسابرسان، مانند مستندسازی کد به درستی و افزودن نظرات درون خطی، دنبال کنید تا از مزایای حسابرسی قرارداد هوشمند به حداکثر برسانید.
-
-- [نکات حسابرسی قرارداد هوشمند و amp; ترفندها](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_
-- [از حسابرسی خود حداکثر استفاده را ببرید](https://inference.ag/blog/2023-08-14-tips/) - _ em>
-
-#### پاداشهای باگ {#bug-bounties}
-
-راه اندازی یک برنامه باگ بانتی روش دیگری برای اجرای بررسی کدهای خارجی است. جایزه باگ یک پاداش مالی است که به افرادی (معمولاً هکرهای کلاه سفید) که آسیبپذیریهای یک برنامه را کشف میکنند، داده میشود.
-
-هنگامی که به درستی استفاده میشود، پاداشهای باگ به اعضای جامعه هکر انگیزه میدهد تا کد شما را از نظر نقصهای مهم بررسی کنند. یک مثال واقعی "باگ پول بینهایت" است که به مهاجم اجازه میدهد مقدار نامحدودی اتر را در [آپتیمیزم](https://www.optimism.io/) ایجاد کند، یک < یک پروتکل href="/layer-2/">لایه 2 که روی اتریوم اجرا میشود. خوشبختانه، یک هکر whitehat [این نقص را کشف کرد](https://www.saurik.com/optimism.html) و به تیم اطلاع داد، [کسب پرداختی بزرگ در این فرآیند انجام شد](https://cryptoslate.com/ بحرانی-اشکال-in-ethereum-l2-optimism-2m-bounty-paid/).
-
-یک استراتژی مفید این است که پرداخت برنامه پاداش اشکال را متناسب با مقدار وجوه مورد نظر تنظیم کنید. این رویکرد بهعنوان «[اشکال مقیاسگذاری](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) توصیف میشود. انگیزههای مالی برای افراد برای افشای مسئولانه آسیب پذیریها به جای سوء استفاده از آنها را ایجاد میکند.
-
-### 5. در هنگام توسعه قراردادهای هوشمند بهترین رویه های موجود را دنبال کنید {#follow-smart-contract-development-best-practices}
-
-وجود آدیت و پاداش باگ مسئولیت شما را برای نوشتن کد با کیفیت بالا توجیه نمیکند. امنیت قرارداد هوشمند خوب با فرآیندهای طراحی و توسعه مناسب زیر شروع میشود:
-
-- همه کدها را در یک سیستم کنترل نسخه مانند git ذخیره کنید
-
-- تمام تغییرات کد را از طریق درخواستهای pull انجام دهید
-
-- اطمینان حاصل کنید که درخواستهای pull حداقل یک بازبین مستقل دارند—اگر به تنهایی روی پروژهای کار میکنید، توسعهدهندگان دیگر و بررسیهای کد تجاری را پیدا کنید
-
-- از یک [محیط توسعه](/developers/docs/فریم ورک/) برای آزمایش، کامپایل، استقرار قراردادهای هوشمند استفاده کنید
-
-- کد خود را از طریق ابزارهای اصلی تجزیه و تحلیل کد، مانند [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn)، Mythril و Slither اجرا کنید. در حالت ایدهآل، باید این کار را قبل از ادغام هر درخواست pull انجام دهید و تفاوتها را در خروجی مقایسه کنید
-
-- مطمئن شوید که کد شما بدون خطا کامپایل شده است و کامپایلر سالیدیتی هیچ هشداری صادر نمیکند
-
-- کد خود را به درستی مستند کنید (با استفاده از [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)) و جزئیات مربوط به معماری قرارداد را به آسانی شرح دهید. این کار بررسی و بازبینی کد شما را برای دیگران آسانتر میکند.
-
-### 6. اجرای طرحهای قوی بازیابی حوادث {#implement-disaster-recovery-plans}
-
-طراحی کنترلهای دسترسی ایمن، اجرای اصلاحکنندههای عملکرد و سایر پیشنهادها میتواند امنیت قرارداد هوشمند را بهبود بخشد، اما نمیتواند احتمال سوء استفادههای مخرب را رد کند. ایجاد قراردادهای هوشمند ایمن مستلزم «آماده شدن برای شکست» و داشتن یک برنامه بازگشتی برای پاسخگویی مؤثر به حملات است. یک طرح مناسب برای بازیابی حوادث شامل برخی یا همه اجزای زیر است:
-
-#### ارتقاهای قرارداد {#contract-upgrades}
-
-در حالی که قراردادهای هوشمند اتریوم به طور پیش فرض تغییر ناپذیر هستند، میتوان با استفاده از الگوهای ارتقا به درجاتی از تغییرپذیری دست یافت. به روز رسانی قراردادها در مواردی ضروری است که یک نقص مهم قرارداد قدیمی شما را غیرقابل استفاده میکند و به کارگیری منطق جدید امکان پذیرترین گزینه است.
-
-مکانیسمهای ارتقای قرارداد متفاوت عمل میکنند، اما «الگوی پروکسی» یکی از محبوبترین رویکردها برای ارتقای قراردادهای هوشمند است. [الگوهای پراکسی](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) منطق اجرائی و فضای ذخیرهسازی دادهها را بین _دو_ قرارداد تقسیم میکند. قرارداد اول (که "قرارداد پراکسی" نامیده میشود) متغیرهای حالت را ذخیره میکند (به عنوان مثال، موجودی کاربر)، در حالی که قرارداد دوم (که "منطق قرارداد" نامیده میشود) کد اجرای توابع قرارداد را نگه میدارد.
-
-حسابها با قرارداد پروکسی تعامل دارند، که همه فراخوانیهای تابع را با استفاده از [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight به قرارداد منطقی ارسال میکند. =delegatecall#delegatecall-callcode-and-libraries) تماس سطح پایین. برخلاف یک تماس پیامی معمولی، `delegatecall()` تضمین میکند که کد در حال اجرا در آدرس قرارداد منطقی در متن قرارداد فراخوانی اجرا میشود. یک تماس پیامی معمولی، `delegatecall()` تضمین میکند که کد در حال اجرا در آدرس قرارداد منطقی در متن قرارداد فراخوانی اجرا میشود.
-
-واگذاری تماسها به قرارداد منطقی مستلزم ذخیره آدرس آن در فضای ذخیرهسازی قرارداد پروکسی است. از این رو، ارتقاء منطق قرارداد فقط به استقرار یک قرارداد منطقی دیگر و ذخیره آدرس جدید در قرارداد پروکسی بستگی دارد. از آنجایی که فراخوانی یا تماسهای بعدی به قرارداد پروکسی به طور خودکار به قرارداد منطقی جدید هدایت میشوند، میتوانید قرارداد را بدون تغییر واقعی کد «ارتقاء» میدادید.
-
-[اطلاعات بیشتر در مورد ارتقاء قراردادها](/developers/docs/smart-contracts/upgrading/).
-
-#### توقفهای اضطراری {#emergency-stops}
-
-همانطور که گفته شد، آدیت و آزمایش گسترده نمیتواند تمام اشکالات یک قرارداد هوشمند را کشف کند. اگر پس از استقرار یک آسیبپذیری در کد شما ظاهر شد، اصلاح آن غیرممکن است، زیرا نمیتوانید کد در حال اجرا در آدرس قرارداد را تغییر دهید. همچنین، مکانیسمهای ارتقا (مثلاً الگوهای پروکسی) ممکن است برای پیادهسازی زمان ببرد (اغلب به تأیید طرفهای مختلف نیاز دارند)، که تنها به مهاجمان زمان بیشتری برای ایجاد آسیب بیشتر میدهد.
-
-گزینه هستهای اجرای یک تابع "توقف اضطراری" است که تماسهای عملکردهای آسیب پذیر را در یک قرارداد مسدود میکند. توقفهای اضطراری معمولاً شامل اجزای زیر است:
-
-1. یک متغیر جهانی بولی (Boolean) که نشان میدهد قرارداد هوشمند در حالت توقف است یا خیر. این متغیر هنگام تنظیم قرارداد روی `false` تنظیم میشود، اما پس از توقف قرارداد به `true` برمیگردد.
-
-2. توابعی که در اجرای خود به متغیر بولی (Boolean) اشاره میکنند. زمانی که قرارداد هوشمند متوقف نشده باشد، چنین عملکردهایی قابل دسترسی هستند و با فعال شدن ویژگی توقف اضطراری، غیرقابل دسترس میشوند.
-
-3. موجودی که به تابع توقف اضطراری دسترسی دارد، که متغیر Boolean را روی `true` تنظیم میکند. برای جلوگیری از اعمال مخرب، تماسهای این تابع را میتوان به یک آدرس مطمئن محدود کرد (به عنوان مثال، مالک قرارداد).
-
-هنگامی که قرارداد توقف اضطراری را فعال کرد، عملکردهای خاصی قابل فراخوانی نخواهند بود. این مورد با قرار دادن توابع انتخابی در یک اصلاح کننده که به متغیر سراسری ارجاع میدهد، به دست میآید. در زیر [نمونهای](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) وجود دارد که اجرای این الگو را در قراردادها شرح میدهد:
-
-```solidity
-// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk.
-
-contract EmergencyStop {
-
- bool isStopped = false;
-
- modifier stoppedInEmergency {
- require(!isStopped);
- _;
- }
-
- modifier onlyWhenStopped {
- require(isStopped);
- _;
- }
-
- modifier onlyAuthorized {
- // Check for authorization of msg.sender here
- _;
- }
-
- function stopContract() public onlyAuthorized {
- isStopped = true;
- }
-
- function resumeContract() public onlyAuthorized {
- isStopped = false;
- }
-
- function deposit() public payable stoppedInEmergency {
- // Deposit logic happening here
- }
-
- function emergencyWithdraw() public onlyWhenStopped {
- // Emergency withdraw happening here
- }
-}
-```
-
-این مثال ویژگیهای اساسی توقفهای اضطراری را نشان میدهد:
-
-- `isStopped` یک بولین است که در ابتدا به `false` و هنگامی که قرارداد وارد حالت اضطراری میشود `true` ارزیابی میشود.
-
-- تغییردهنده تابع `onlyWhenStopped` و `stoppedInEmergency` متغیر `isStopped` را بررسی میکنند. `stoppedInEmergency` برای کنترل توابعی استفاده میشود که در صورت آسیبپذیر بودن قرارداد، غیرقابل دسترسی هستند (به عنوان مثال، `deposit()`). تماسهای این توابع به سادگی برمیگردند.
-
-`onlyWhenStopped` برای توابعی استفاده میشود که باید در مواقع اضطراری قابل فراخوانی باشند (مانند `emergencyWithdraw()`). چنین توابعی میتوانند به حل وضعیت کمک کنند، از این رو آنها را از لیست "عملکردهای محدود" حذف میکنند.
-
-استفاده از عملکرد توقف اضطراری یک توقف مؤثر برای مقابله با آسیب پذیریهای جدی در قرارداد هوشمند شما فراهم میکند. با این حال، نیاز کاربران به اعتماد به توسعهدهندگان را افزایش میدهد تا آن را به دلایل خود خدمتی فعال نکنند. برای این منظور، غیرمتمرکز کردن کنترل توقف اضطراری یا با قرار دادن آن در معرض مکانیزم رایگیری زنجیرهای، قفل زمانی یا تایید از یک کیف پول مالتی سیگ راهحلهای ممکن است.
-
-#### نظارت بر رویداد {#event-monitoring}
-
-[رویدادها](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) به شما امکان میدهد تماسهای مربوط به عملکردهای قرارداد هوشمند را ردیابی و تغییرات متغیرهای حالت را نظارت کنید. بهتر است که قرارداد هوشمند خود را طوری برنامهریزی کنید که هر زمان که یکی از طرفین یک اقدام مهم ایمنی (مثلاً برداشت وجه) انجام میدهد، رویدادی را منتشر کند.
-
-ثبت رویدادها و نظارت بر آنها به صورت غیر زنجیرهای بینشهایی در مورد عملیات قرارداد ارائه میدهد و به کشف سریعتر اقدامات مخرب کمک میکند. این بدان معناست که تیم شما میتواند سریعتر به هکها پاسخ دهد و برای کاهش تأثیر روی کاربران، مانند توقف موقت عملکردها یا انجام ارتقا، اقدام کند.
-
-همچنین میتوانید ابزار نظارتی خارج از قفسه را انتخاب کنید که به طور خودکار هشدارها را هر زمان که کسی با قراردادهای شما تعامل دارد، ارسال میکند. این ابزارها به شما این امکان را میدهند که بر اساس محرکهای مختلف، مانند حجم تراکنش، فرکانس فراخوانی عملکرد، یا عملکردهای خاص، هشدارهای سفارشی ایجاد کنید. برای مثال، میتوانید هشداری را برنامهریزی کنید که زمانی که مبلغ برداشت شده در یک تراکنش از یک آستانه خاص عبور میکند، وارد میشود.
-
-### 7. طراحی سیستمهای حاکمیت ایمن {#design-secure-governance-systems}
-
-ممکن است بخواهید با سپردن کنترل قراردادهای هوشمند اصلی به اعضای جامعه، برنامه خود را غیرمتمرکز کنید. در این مورد، سیستم قرارداد هوشمند شامل یک ماژول حاکمیتی خواهد بود – مکانیزمی که به اعضای جامعه اجازه میدهد تا اقدامات اداری را از طریق یک سیستم حاکمیت زنجیرهای تأیید کنند. برای مثال، پیشنهادی برای ارتقاء قرارداد پروکسی به یک پیادهسازی جدید ممکن است توسط دارندگان توکن به رأی گذاشته شود.
-
-حاکمیت غیرمتمرکز می تواند سودمند باشد، به ویژه به این دلیل که منافع توسعه دهندگان و کاربران نهایی را همسو می کند. با این وجود، مکانیسمهای حکمرانی قراردادهای هوشمند ممکن است در صورت اجرای نادرست، خطرات جدیدی را ایجاد کنند. یک سناریوی قابل قبول این است که مهاجم با گرفتن [وام فوری](/defi/#flash-loans) قدرت رای عظیمی (که بر حسب تعداد توکنهای نگهداری شده اندازهگیری میشود) به دستآورد و یک پیشنهاد مخرب را انجام دهد.
-
-یکی از راه های جلوگیری از مشکلات مربوط به حاکمیت زنجیره ای، [استفاده از قفل زمانی](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/) است. قفل زمانی مانع از اجرای یک قرارداد هوشمند تا زمان مشخصی می شود. راهبردهای دیگر عبارتند از اختصاص یک "وزن رای" به هر توکن بر اساس مدت زمانی که قفل شده است، یا اندازه گیری قدرت رای دادن یک آدرس در یک دوره تاریخی (مثلاً 2-3 بلوک در گذشته) به جای بلوک فعلی. هر دو روش امکان جمعآوری سریع قدرت رای برای تغییر آرای زنجیره ای را کاهش می دهند.
-
-اطلاعات بیشتر در مورد [طراحی سیستمهای حاکمیت ایمن](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)، [مکانیسمهای رایگیری مختلف در DAOها](https://hackernoon.com/governance-is-the-holy-grail-for-daos)، و [بردارهای رایج حمله DAO با استفاده از دیفای](https://dacian.me/dao-governance-defi-attacks) در لینکهای مشترک.
-
-### 8. کاهش پیچیدگی کد به حداقل {#reduce-code-complexity}
-
-توسعه دهندگان نرمافزار سنتی با اصل KISS ("ساده نگهش دار، احمقانه") آشنا هستند، که توصیه می کند از وارد کردن پیچیدگی های غیر ضروری در طراحی نرمافزار خودداری کنید. این امر متعاقب این تفکر دیرینه است که "سیستم های پیچیده به روش های پیچیده شکست می خورند" و بیشتر مستعد خطاهای پرهزینه هستند.
-
-با توجه به اینکه قراردادهای هوشمند به طور بالقوه مقادیر زیادی از ارزش را کنترل می کنند، ساده نگه داشتن چیزها هنگام نوشتن قراردادهای هوشمند از اهمیت ویژه ای برخوردار است. نکته ای برای دستیابی به سادگی هنگام نوشتن قراردادهای هوشمند، استفاده مجدد از کتابخانه های موجود، مانند [قراردادهای OpenZeppelin](https://docs.openzeppelin.com/contracts/4.x/)، در صورت امکان است. از آنجایی که این کتابخانه ها به طور گسترده توسط توسعه دهندگان ممیزی و آزمایش شده اند، استفاده از آنها با نوشتن عملکردهای جدید از ابتدا، شانس معرفی اشکالات را کاهش می دهد.
-
-توصیه رایج دیگر نوشتن توابع کوچک و مدولار نگه داشتن قراردادها با تقسیم منطق تجاری در چندین قرارداد است. نه تنها نوشتن کد سادهتر سطح حمله را در یک قرارداد هوشمند کاهش میدهد، بلکه استدلال درباره درستی سیستم کلی و تشخیص زودهنگام خطاهای احتمالی طراحی را آسانتر میکند.
-
-### 9. دفاع در برابر آسیبپذیریهای رایج قرارداد هوشمند {#mitigate-common-smart-contract-vulnerabilities}
-
-#### ورود دوباره {#reentrancy}
-
-EVM اجازه همزمانی را نمی دهد، به این معنی که دو قرارداد درگیر در یک تماس پیام نمی توانند به طور همزمان اجرا شوند. یک فراخوانی خارجی، اجرای قرارداد و حافظه فراخوان را تا زمانی که تماس برگردد، متوقف میکند، در این مرحله اجرا به طور معمول ادامه مییابد. این فرآیند را می توان به طور رسمی به عنوان انتقال [جریان کنترل](https://www.computerhope.com/jargon/c/contflow.htm) به قرارداد دیگری توصیف کرد.
-
-اگرچه اغلب بی ضرر هستند، اما انتقال جریان کنترل به قراردادهای غیرقابل اعتماد می تواند مشکلاتی مانند ورود دوباره ایجاد کند. یک حمله ورود دوباره زمانی اتفاق میافتد که یک قرارداد مخرب قبل از تکمیل فراخوانی عملکرد اصلی، یک قرارداد آسیبپذیر را دوباره فراخوانی کند. این نوع حمله به بهترین شکل با یک مثال توضیح داده می شود.
-
-یک قرارداد هوشمند ساده ("قربانی") را در نظر بگیرید که به هر کسی اجازه می دهد اتر را واریز و برداشت کند:
-
-```solidity
-// This contract is vulnerable. Do not use in production
-
-contract Victim {
- mapping (address => uint256) public balances;
-
- function deposit() external payable {
- balances[msg.sender] += msg.value;
- }
-
- function withdraw() external {
- uint256 amount = balances[msg.sender];
- (bool success, ) = msg.sender.call.value(amount)("");
- require(success);
- balances[msg.sender] = 0;
- }
-}
-```
-
-این قرارداد یک تابع `withdraw()` را نشان میدهد تا به کاربران امکان میدهد ETH را که قبلاً در قرارداد سپرده شده برداشت کنند. هنگام پردازش یک برداشت، قرارداد عملیات زیر را انجام میدهد:
-
-1. تعادل اتر کاربر را بررسی میکند
-2. وجوه را به آدرس تماس ارسال میکند
-3. موجودی آنها را به 0 بازنشانی میکند و از برداشت اضافی از کاربر جلوگیری میکند
-
-تابع `withdraw()` در قرارداد ` قربانی` از الگوی "بررسی-تعامل-اثرات" پیروی می کند. که _بررسی میکند_ آیا شرایط لازم برای اجرا برآورده شده است (یعنی کاربر دارای موجودی ETH مثبت است) و قبل از اعمال _اثرات_ تراکنش (یعنی کاهش موجودی کاربر) _تعامل_ را با ارسال ETH به آدرس تماسگیرنده انجام میدهد.
-
-اگر `withdraw()` از یک حساب تحت مالکیت خارجی (EOA) فراخوانی شود، تابع همانطور که انتظار می رود اجرا می شود: `msg.sender.call.value()` ETH را برای تماس گیرنده ارسال می کند. با این حال، اگر `msg.sender` یک حساب قرارداد هوشمند باشد، `withdraw()` را فراخوانی میکند، ارسال وجوه با استفاده از `msg.sender.call.value()` انجام میشود. همچنین کدهای ذخیره شده در آن آدرس را برای اجرا راه اندازی کنید.
-
-تصور کنید این کدی است که در آدرس قرارداد مستقر شده است:
-
-```solidity
- contract Attacker {
- function beginAttack() external payable {
- Victim(victim_address).deposit.value(1 ether)();
- Victim(victim_address).withdraw();
- }
-
- function() external payable {
- if (gasleft() > 40000) {
- Victim(victim_address).withdraw();
- }
- }
-}
-```
-
-این قرارداد برای انجام سه کار طراحی شده است:
-
-1. پذیرش سپرده از حساب دیگری (احتمالاً EOA مهاجم)
-2. واریز یک سکه ETH به قرارداد قربانی
-3. برداشت یک سکه ETH ذخیره شده در قرارداد هوشمند
-
-هیچ مشکلی در اینجا وجود ندارد، به جز اینکه `مهاجم` تابع دیگری دارد که اگر گس باقی مانده از `msg.sender.call.value` ورودی بیش از 40،000 باشد.ده باشد، تابع دیگری دارد که `withdraw()` را در ` قربانی` دوباره فراخوانی میکند. این به `مهاجم` این امکان را میدهد تا `قربانی` را دوباره وارد کرده و وجوه بیشتری را _قبل از_ تکمیل اولین فراخوان `خروج` برداشت کند. چرخه به این صورت است:
-
-```solidity
-- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH
-- `Attacker.beginAttack()` deposits 1 ETH into `Victim`
-- `Attacker` calls `withdraw() in `Victim`
-- `Victim` checks `Attacker`’s balance (1 ETH)
-- `Victim` sends 1 ETH to `Attacker` (which triggers the default function)
-- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal)
-- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call)
-- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function)
-- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals
-- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0
-```
-
-خلاصه موضوع این است که چون موجودی تماسگیرنده تا زمانی که اجرای تابع کامل نشود روی 0 تنظیم نمیشود، فراخوانیهای بعدی موفق خواهند شد و به تماسگیرنده اجازه میدهند تا موجودی خود را چندین بار برداشت کند. از این نوع حمله می توان برای تخلیه یک قرارداد هوشمند از وجوه آن استفاده کرد، مانند آنچه در [هک DAO سال 2016](https://www.coindesk.com/learn/2016/06/25/understanding-the-dao-attack/) اتفاق افتاد. همانطور که [فهرستهای عمومی اکسپلویتهای reentrancy](https://github.com/pcaversaccio/reentrancy-attacks) نشان میدهند، حملات reentrancy امروزه همچنان یک موضوع حیاتی برای قراردادهای هوشمند است.
-
-##### چگونه از حملات بازگشت مجدد جلوگیری کنیم
-
-یک رویکرد برای مقابله با reentrancy، پیروی از [الگوی بررسی-اثرات-تعامل](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) است. این الگو دستور اجرای توابع را میدهد به گونهای که کدی که بررسیهای لازم را قبل از پیشرفت در اجرا انجام میدهد، ابتدا میآید، به دنبال آن کدی که وضعیت قرارداد را دستکاری میکند، کدی که با قراردادهای دیگر تعامل دارد یا EOAها در آخر میآیند.
-
-الگوی بررسی-اثرات-تعامل در نسخه اصلاح شده قرارداد `قربانی` که در زیر نشان داده شده است استفاده می شود:
-
-```solidity
-contract NoLongerAVictim {
- function withdraw() external {
- uint256 amount = balances[msg.sender];
- balances[msg.sender] = 0;
- (bool success, ) = msg.sender.call.value(amount)("");
- require(success);
- }
-}
-```
-
-این قرارداد یک _بررسی_ در موجودی کاربر انجام می دهد، _اثرات_ تابع `withdraw()` را اعمال می کند (با تنظیم مجدد موجودی کاربر به 0)، و به انجام _تعامل_ (ارسال ETH به آدرس کاربر) ادامه می دهد. این مورد تضمین میکند که قرارداد قبل از تماس خارجی، فضای ذخیرهسازی خود را بهروزرسانی میکند و شرایط ورود مجدد را که اولین حمله را فعال میکرد، حذف میکند. قرارداد `مهاجم` همچنان میتواند به `NoLongerAVictim` برگردد، اما از آنجایی که `balances[msg.sender]` روی 0 تنظیم شده است، برداشتهای اضافی با خطا مواجه میشوند.
-
-گزینه دیگر استفاده از یک قفل محرومیت متقابل (که معمولاً به عنوان "mutex" توصیف می شود) است که بخشی از وضعیت قرارداد را تا زمانی که فراخوانی عملکرد کامل شود قفل می کند. این امر با استفاده از یک متغیر بولین که قبل از اجرای تابع روی `true` تنظیم شده است و پس از انجام فراخوانی به `false` برمیگردد پیادهسازی میشود. همانطور که در مثال زیر مشاهده میشود، استفاده از میوتکس از یک تابع در برابر تماسهای بازگشتی محافظت میکند در حالی که فراخوان اصلی هنوز در حال پردازش است، و به طور مؤثر ورود مجدد را متوقف میکند.
-
-```solidity
-pragma solidity ^0.7.0;
-
-contract MutexPattern {
- bool locked = false;
- mapping(address => uint256) public balances;
-
- modifier noReentrancy() {
- require(!locked, "Blocked from reentrancy.");
- locked = true;
- _;
- locked = false;
- }
- // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again.
- // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier
- function withdraw(uint _amount) public payable noReentrancy returns(bool) {
- require(balances[msg.sender] >= _amount, "No balance to withdraw.");
-
- balances[msg.sender] -= _amount;
- bool (success, ) = msg.sender.call{value: _amount}("");
- require(success);
-
- return true;
- }
-}
-```
-
-همچنین میتوانید به جای سیستم «پرداخت فشاری» که وجوه را به حسابها ارسال میکند، از سیستم [برگشت پرداختها](https://docs.openzeppelin.com/contracts/4.x/api/security#PullPayment) استفاده کنید که کاربران را ملزم به برداشت وجه از قراردادهای هوشمند میکند. با این کار امکان راهاندازی ناخواسته کد در آدرسهای ناشناس حذف میشود (و همچنین میتواند از برخی حملات انکار سرویس جلوگیری کند).
-
-#### پاریز و سرریز اعداد صحیح {#integer-underflows-and-overflows}
-
-سرریز یا اورفلو اعداد صحیح زمانی اتفاق میافتد که نتایج یک عملیات حسابی خارج از محدوده قابل قبول مقادیر قرار میگیرد و باعث میشود که آن را به پایینترین مقدار قابل نمایش تبدیل کند. برای مثال، یک `uint8` فقط میتواند مقادیر تا 2^8-1=255 را ذخیره کند. عملیات حسابی که به مقادیر بالاتر از `255` منجر میشود، سرریز یا اورفلو میشوند و `uint` را به `0` بازنشانی میکنند، مشابه اینکه کیلومترشمار ماشین بعد از به حداکثر رسیدن مسافت پیموده شده (999999) به 0 بازنشانی شود.
-
-جریانهای آندرفلو صحیح به دلایل مشابهی اتفاق میافتد: نتایج یک عملیات حسابی کمتر از محدوده قابل قبول است. فرض کنید سعی کردهاید `0` را در `uint8` کاهش دهید، نتیجه به سادگی به حداکثر مقدار قابل نمایش (`255`) میرسد.
-
-هم اورفلو و هم آندرفلو اعداد صحیح میتواند منجر به تغییرات غیرمنتظره در متغیرهای حالت قرارداد شود و منجر به اجرای برنامه ریزی نشده شود. در زیر مثالی وجود دارد که نشان میدهد چگونه یک مهاجم میتواند از سرریز حسابی در یک قرارداد هوشمند برای انجام یک عملیات نامعتبر سوء استفاده کند:
-
-```
-pragma solidity ^0.7.6;
-
-// This contract is designed to act as a time vault.
-// User can deposit into this contract but cannot withdraw for at least a week.
-// User can also extend the wait time beyond the 1 week waiting period.
-
-/*
-1. Deploy TimeLock
-2. Deploy Attack with address of TimeLock
-3. Call Attack.attack sending 1 ether. You will immediately be able to
- withdraw your ether.
-
-What happened?
-Attack caused the TimeLock.lockTime to overflow and was able to withdraw
-before the 1 week waiting period.
-*/
-
-contract TimeLock {
- mapping(address => uint) public balances;
- mapping(address => uint) public lockTime;
-
- function deposit() external payable {
- balances[msg.sender] += msg.value;
- lockTime[msg.sender] = block.timestamp + 1 weeks;
- }
-
- function increaseLockTime(uint _secondsToIncrease) public {
- lockTime[msg.sender] += _secondsToIncrease;
- }
-
- function withdraw() public {
- require(balances[msg.sender] > 0, "Insufficient funds");
- require(block.timestamp > lockTime[msg.sender], "Lock time not expired");
-
- uint amount = balances[msg.sender];
- balances[msg.sender] = 0;
-
- (bool sent, ) = msg.sender.call{value: amount}("");
- require(sent, "Failed to send Ether");
- }
-}
-
-contract Attack {
- TimeLock timeLock;
-
- constructor(TimeLock _timeLock) {
- timeLock = TimeLock(_timeLock);
- }
-
- fallback() external payable {}
-
- function attack() public payable {
- timeLock.deposit{value: msg.value}();
- /*
- if t = current lock time then we need to find x such that
- x + t = 2**256 = 0
- so x = -t
- 2**256 = type(uint).max + 1
- so x = type(uint).max + 1 - t
- */
- timeLock.increaseLockTime(
- type(uint).max + 1 - timeLock.lockTime(address(this))
- );
- timeLock.withdraw();
- }
-}
-```
-
-##### چگونه از سرریز و آندرفلو اعداد صحیح جلوگیری کنیم
-
-از نسخه 0.8.0، کامپایلر سالیدیتی کدهایی را که منجر به سرریز و زیر جریان یا همان آندر فلو اعداد صحیح میشود، رد میکند. با این حال، قراردادهایی که با یک نسخه کامپایلر پایینتر کامپایل میشوند باید یا باید توابع مربوط به عملیات حسابی را بررسی یا از یک کتابخانه استفاده کنند (به عنوان مثال، [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) که اورفلو یا آندرفلو را بررسی میکند.
-
-#### دستکاری اوراکل {#oracle-manipulation}
-
-[اوراکلها](/developers/docs/oracles/) اطلاعات خارج از زنجیره را منبع قرار میدهند و آنها را به صورت زنجیرهای برای استفاده از قراردادهای هوشمند ارسال میکند. با اوراکلها، میتوانید قراردادهای هوشمندی را طراحی کنید که با سیستمهای خارج از زنجیره، مانند بازارهای سرمایه، همکاری میکنند و کاربرد آنها را تا حد زیادی گسترش میدهند.
-
-اما اگر اوراکل خراب شود و اطلاعات نادرست را روی زنجیره ارسال کند، قراردادهای هوشمند بر اساس ورودیهای اشتباه اجرا میشوند که میتواند مشکلاتی را ایجاد کند. این اساس "مشکل اوراکل" است که به وظیفه اطمینان از دقیق، به روز و به موقع بودن اطلاعات یک اوراکل بلاک چین مربوط میشود.
-
-یک نگرانی امنیتی مرتبط، استفاده از یک اوراکل زنجیرهای، مانند یک صرافی غیرمتمرکز، برای دریافت قیمت ای یک دارایی است. پلتفرمهای وامدهی در صنعت [مالی غیرمتمرکز (DeFi)](/defi/) اغلب این کار را برای تعیین ارزش وثیقه کاربر انجام میدهند تا تعیین کنند چقدر میتوانند وام بگیرند.
-
-قیمتهای صرافیهای غیرمتمرکز اغلب دقیق هستند، که عمدتاً به دلیل بازیابی برابری توسط آربیتراژها در بازارها است. با این حال، آنها در معرض دستکاری هستند، به ویژه اگر اوراکل روی زنجیره قیمت داراییها را بر اساس الگوهای معاملاتی تاریخی محاسبه کند (همانطور که معمولاً اتفاق میافتد).
-
-به عنوان مثال، یک مهاجم میتواند بهطور مصنوعی قیمت نقدی یک دارایی را با گرفتن وام فوری یا همان فلش لون درست قبل از تعامل با قرارداد وام شما، افزایش دهد. پرس و جو از دکس برای قیمت دارایی، ارزشی بالاتر از حد معمول را به دست میآورد (به دلیل تقاضای انحرافی «سفارش خرید» مهاجم برای دارایی)، به آنها اجازه میدهد بیشتر از آنچه باید وام بگیرند. چنین "حملات وام فلش یا همان فلش لون" برای بهرهبرداری از اتکا به اوراکلهای قیمت در میان برنامههای کاربردی دیفای استفاده شده است که میلیونها وجوه از دست رفته پروتکلها ایجاد کرده است.
-
-##### چگونه از دستکاری اوراکل جلوگیری کنیم؟
-
-حداقل نیاز برای [جلوگیری از دستکاری اوراکل](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) استفاده از یک شبکه اوراکل غیرمتمرکز است که پرس و جو یا اطلاعات از چندین منبع برای جلوگیری از نقاط شکست کوئری میکند. در بیشتر موارد، اوراکلهای غیرمتمرکز دارای انگیزههای اقتصادی رمزارزی شدهاند تا نود یا گرههای اوراکل را تشویق کرده تا اطلاعات صحیح را گزارش کنند و آنها را از اوراکلهای متمرکز ایمنتر میکند.
-
-اگر قصد دارید از یک اوراکل زنجیرهای یا آنچین برای قیمت داراییها پرس و جو کنید، از یکی استفاده کنید که مکانیزم قیمت میانگین وزن شده با زمان (TWAP) را پیادهسازی میکند. یک [اوراکل TWAP](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) قیمت یک دارایی را در دو مقطع زمانی مختلف (که شما میتوانید اصلاح کنید) و قیمت لحظهای را بر اساس میانگین به دست آمده محاسبه میکند. انتخاب دورههای زمانی طولانیتر از پروتکل شما در برابر دستکاری قیمت محافظت میکند، زیرا سفارشهای بزرگی که اخیراً اجرا شدهاند نمیتوانند بر قیمت دارایی تأثیر بگذارند.
-
-## منابع امنیتی قرارداد هوشمند برای توسعهدهندگان {#smart-contract-security-resources-for-developers}
-
-### ابزارهایی برای تجزیه و تحلیل قراردادهای هوشمند و تأیید صحت کد {#code-analysis-tools}
-
-- **[ابزارها و کتابخانههای تست](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - < em x-id="4">مجموعه ای از ابزارها و کتابخانههای استاندارد صنعتی برای انجام تستهای واحد، تجزیه و تحلیل استاتیک و تجزیه و تحلیل پویا در قراردادهای هوشمند است
-
-- **[ابزارهای تأیید رسمی](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _ابزارهایی برای تأیید صحت عملکرد در قراردادهای هوشمند و بررسی متغیرها هستند._
-
-- **[خدمات حسابرسی قراردادهای هوشمند](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - < em x-id="4">فهرست هایی که خدمات حسابرسی قرارداد هوشمند برای پروژههای توسعه اتریوم ارائه میکنند.
-
-- **[پلتفرمهای پاداش باگ](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _پلتفرمهایی برای هماهنگی پاداشهای اشکال و پاداش افشای مسئولانه آسیبپذیریهای مهم در قراردادهای هوشمند هستند_
-
-- **[فورک چکر](https://forkchecker.hashex.org/)** - _رایگان بوده و ابزار آنلاین برای بررسی تمام اطلاعات موجود در مورد قرارداد منشعب شده است._
-
-- **[رمزگذار ABI](https://abi.hashex.org/)** - _یک رمزگذار رایگان سرویس آنلاین برای رمزگذاری توابع قرارداد سالیدیتی و آرگومانهای سازنده (constructor) شما است._
-
-- **[آدرین](https://github.com/Cyfrin/aderyn)** - _ تحلیلگر استاتیک سالیدیتی ، از درختان نحو انتزاعی (AST) عبور میکند تا آسیبپذیریهای مشکوک را مشخص کرده و مسائل را در قالب علامتگذاری آسان برای مصرف چاپ کند._
-
-### ابزارهای نظارت بر قراردادهای هوشمند {#smart-contract-monitoring-tools}
-
-- **[OpenZeppelin Defender Sentinels](https://docs.openzeppelin.com/defender/v1/sentinel)** - _ابزاری برای نظارت و پاسخگویی خودکار به رویدادها، عملکردها و پارامترهای تراکنش در قراردادهای هوشمند شما است._
-
-- **[هشدار همزمان با ملایمت](https://tenderly.co/alerting/)** - _ابزاری برای دریافت اعلانهای همزمان هنگامی که رویدادهای غیرمنتظره در قراردادهای هوشمند یا کیف پولهای شما اتفاق میافتد._
-
-### ابزارهایی برای مدیریت امن قراردادهای هوشمند {#smart-contract-administration-tools}
-
-- **[OpenZeppelin Defender Admin](https://docs.openzeppelin.com/defender/v1/admin)** - _رابطی برای مدیریت قراردادهای هوشمند، از جمله کنترلهای دسترسی، ارتقاء و توقف است._
-
-- **[ایمن](https://safe.global/)** - _کیف پول قرارداد هوشمند در حال اجرا اتریوم که به حداقل تعداد افراد نیاز دارد تا تراکنش را قبل از انجام آن تأیید کنند (M-of-N)._
-
-- **[قراردادهای اوپن زپلین](https://docs.openzeppelin.com/contracts/4.x/)** - _کتابخانهها را برای اجرای ویژگیهای اداری، از جمله مالکیت قرارداد، ارتقاء، کنترلهای دسترسی، حاکمیت، قابلیت توقف موقت و موارد دیگر مدیریت میکند._
-
-### خدمات حسابرسی قرارداد هوشمند {#smart-contract-auditing-services}
-
-- **[ConsenSys Diligence](https://consensys.net/diligence/)** - _خدمات آدیت قرارداد هوشمند که به پروژهها در سراسر اکوسیستم بلاک چین کمک میکند مطمئن شوند که پروتکلهای آنها برای راهاندازی آماده هستند و برای محافظت از کاربران ساخته شدهاند._
-
-- **[CertiK](https://www.certik.com/)** - _شرکت امنیت بلاک چین پیشگام در استفاده از فناوری تایید رسمی پیشرفته در قراردادهای هوشمند و شبکههای بلاک چین است._
-
-- **[رد بیت](https://www.trailofbits.com/)** - _امنیت سایبری شرکتی که تحقیقات امنیتی را با ذهنیت مهاجم برای کاهش ریسک و تقویت کد ترکیب میکند._
-
-- **[PeckShield](https://peckshield.com/)** - _شرکت امنیت بلاک چین که محصولات و خدماتی برای امنیت، حریم خصوصی و قابلیت استفاده کل اکوسیستم بلاک چین ارائه میکند._
-
-- **[QuantStamp](https://quantstamp.com/)** - _سرویس حسابرسی تسهیل کننده جریان اصلی پذیرش فناوری بلاک چین از طریق خدمات امنیت و ارزیابی ریسک است._
-
-- **[اوپن زپلین](https://www.openzeppelin.com/security-audits)** - _ شرکت امنیتی قرارداد هوشمند که حسابرسیهای امنیتی سیستمهای توزیع شده را ارائه میدهد._
-
-- **[تأیید زمان اجرا](https://runtimeverification.com/)** - _شرکت امنیتی متخصص در مدل سازی رسمی و تأیید قراردادهای هوشمند است_
-
-- **[هک](https://hacken.io)** - _حسابرس امنیت سایبری Web3 که ارائه دهنده 360 رویکرد درجه به امنیت بلاک چین است._
-
-- **[Nethermind](https://nethermind.io/smart-contracts-audits)** - _ خدمات حسابرسی سالیدیتی و کایرو، تضمین یکپارچگی قراردادهای هوشمند و ایمنی کاربران در سراسر اتریوم و استارک نت را ارائه میدهد._
-
-- **[HashEx](https://hashex.org/)** - _HashEx بر روی بلاکین و حسابرسی قراردادهای هوشمند برای اطمینان از امنیت ارزهای دیجیتال، ارائه خدماتی مانند توسعه قرارداد هوشمند، تست نفوذ، مشاوره بلاکچین تمرکز دارد. 2>
-
-- **[Code4rena](https://code4rena.com/)** - _پلتفرم حسابرسی رقابتی که کارشناسان امنیت قراردادهای هوشمند را تشویق میکند تا آسیبپذیریها را بیابند و به ایمنتر شدن Web3 کمک کنند._
-
-- **[CodeHawks](https://codehawks.com/)** - _پلتفرم حسابرسی رقابتی میزبان مسابقات حسابرسی قراردادهای هوشمند برای محققان امنیتی._
-
-- **[Cyfrin](https://cyfrin.io)** - _ نیروگاه امنیتی وب3، انکوباتور امنیت رمزارز از طریق محصولات و خدمات حسابرسی قرارداد هوشمند._
-
-- **[ImmuneBytes](https://www.immunebytes.com//smart-contract-audit/)** - _شرکت امنیتی وب3 که ممیزی های امنیتی سیستم های بلاکچین را از طریق تیمی از حسابرسان مجرب و بهترین ابزارها ارائه می کند._
-
-- **[Oxorio](https://oxor.io/)** - _ممیزی قراردادهای هوشمند و خدمات امنیتی بلاکین با تخصص در EVM، سالیدیتی، ZK، فناوری زنجیرهای متقابل برای شرکتهای رمزنگاری و پروژههای دیفای._
-
-- **[Inference](https://inference.ag/)** - _شرکت حسابرسی امنیتی، متخصص در حسابرسی قراردادهای هوشمند برای بلاکچینهای مبتنی بر EVM. با تشکر از حسابرسان متخصص آن، آنها مشکلات بالقوه را شناسایی کرده و راهحلهای عملی را برای رفع آنها قبل از استقرار پیشنهاد میکنند._
-
-### پلتفرمهای باگبانتی {#bug-bounty-platforms}
-
-- **[Immunefi](https://immunefi.com/)** - _پلتفرم باگبانتی برای قراردادهای هوشمند و پروژههای دیفای، که در آن محققان امنیتی کد را بررسی میکنند، آسیبپذیریها را فاش میکنند، پاداش دریافت میکنند و دنیای رمزارز را ایمنتر میکنند._
-
-- **[HackerOne](https://www.hackerone.com/)** - _پلتفرم هماهنگی آسیبپذیری و باگبانتی که کسبوکارها را با کارشناسان تست نفوذ و محققان امنیت سایبری مرتبط میکند._
-
-- **[HackenProof](https://hackenproof.com/)** - _پلتفرم باگبانتی متخصص برای پروژههای رمزارزی (دیفای، قراردادهای هوشمند، کیف پولها، CEX و موارد دیگر)، جایی که متخصصان امنیتی خدمات تریاژ را ارائه می دهند و محققان برای گزارش های مربوط به باگ هایتأیید شده پاداش دریافت می کنند._
-
-- **[Sherlock](https://www.sherlock.xyz/)** - _ عریضهنویس در وب3 برای امنیت قراردادهای هوشمند، با پرداختهایی برای حسابرسان که از طریق قراردادهای هوشمند مدیریت میشوند تا از پرداخت عادلانه باگ های مربوطه اطمینان حاصل شود._
-
-- **[CodeHawks](https://www.codehawks.com/)** - _پلتفرم باگبانتی رقابتی که در آن حسابرسان در مسابقات و چالشهای امنیتی و (به زودی) در ممیزیهای خصوصی خودشان شرکت میکنند._
-
-### رسانه های آسیب پذیری ها و اکسپلویت های شناخته شده قرارداد هوشمند {#common-smart-contract-vulnerabilities-and-exploits}
-
-- قماله **[کانسنسیس: حملات شناخته شده قرارداد هوشمند](https://consensys.github.io/smart-contract-best-practices/attacks/)** - _توضیحات مبتدی مهم ترین آسیب پذیری های قرارداد، با کد نمونه برای اکثر موارد._
-
-- **[SWC Registry](https://swcregistry.io/)** - _فهرست تنظیمشده از موارد سرشماری ضعف مشترک (CWE) که در قراردادهای هوشمند اتریوم اعمال میشود._
-
-- **[Rekt](https://rekt.news/)** - _ انتشار منظم هکها و سوء استفادههای رمزنگاری با مشخصات بالا، همراه با کالبدشکافی._
-
-### چالشهای یادگیری امنیت قراردادهای هوشمند {#challenges-for-learning-smart-contract-security}
-
-- **[Awesome BlockSec CTF ](https://github.com/blockthreat/blocksec-ctfs)** - _فهرست تنظیمشده بازیهای امنیتی بلاکچین، چالشها و مسابقات [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) و نوشتههای راهحل._
-
-- **[DeFi آسیب پذیر لعنتی](https://www.damnvulnerabledefi.xyz/)** - _بازی برای یادگیری امنیت تهاجمی قراردادهای هوشمند دیفای و ایجاد مهارت در شکار باگ و ممیزی امنیتی._
-
-- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _بازی جنگی مبتنی بر وب3/سالیدیتی که در آن هر سطح یک قرارداد هوشمند است که باید "هک" شود._
-
-- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _چالش هک قرارداد هوشمند، در یک ماجراجویی فانتزی. تکمیل موفقیتآمیز چالش به یک برنامه باگبانتی خصوصی نیز دسترسی پیدا میکند._
-
-### بهترین روش ها برای ایمن سازی قراردادهای هوشمند {#smart-contract-security-best-practices}
-
-- **[کانسنسیس: بهترین روشهای امنیتی قراردادهای هوشمند اتریوم](https://consensys.github.io/smart-contract-best-practices/)** - _فهرست جامع دستورالعملها برای ایمن کردن قراردادهای هوشمند اتریوم._
-
-- **[Nascent: ابزار ساده امنیتی](https://github.com/nascentxyz/simple-security-toolkit)** - _مجموعه راهنماها و چک لیست های عملی مبتنی بر امنیت برای توسعه قراردادهای هوشمند._
-
-- **[Solidity Patterns](https://fravoll.github.io/solidity-patterns/)** - _تلفیقی مفید از الگوهای امن و بهترین شیوه ها برای زبان برنامه نویسی قرارداد هوشمند سالیدیتی._
-
-- **[اسناد سالیدیتی: ملاحظات امنیتی](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _دستورالعملهایی برای نوشتن قراردادهای هوشمند ایمن با سالیدیتی._
-
-- **[استاندارد تأیید امنیت قراردادهای هوشمند](https://github.com/securing/SCSVS)** - _چک لیست چهارده قسمتی ایجاد شده برای استانداردسازی امنیت قراردادهای هوشمند برای توسعه دهندگان، معماران، بازبینان امنیتی و فروشندگان._
-
-- **[امنیت و حسابرسی قرارداد هوشمند را بیاموزید](https://updraft.cyfrin.io/courses/security) - _دوره ممیزی و امنیت قراردادهای هوشمند نهایی، ایجاد شده برای توسعه دهندگان قراردادهای هوشمند که به دنبال ارتقای بهترین شیوه های امنیتی خود و تبدیل شدن به محققین امنیتی هستند._
-
-### آموزش امنیت قراردادهای هوشمند {#tutorials-on-smart-contract-security}
-
-- [نحوه نوشتن قراردادهای هوشمند امن](/developers/tutorials/secure-development-workflow/)
-
-- [نحوه استفاده از Slither برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
-
-- [نحوه استفاده از Manticore برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
-
-- [راهنمای امنیتی قراردادهای هوشمند](/developers/tutorials/smart-contract-security-guidelines/)
-
-- [چگونه به طور ایمن قرارداد توکن خود را با توکنهای دلخواه ادغام کنیم](/developers/tutorials/token-integration-checklist/)
-
-- [Cyfrin Updraft - امنیت قراردادهای هوشمند و دوره کامل ممیزی](https://updraft.cyfrin.io/courses/security)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
deleted file mode 100644
index 3e0b74870d6..00000000000
--- "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md"
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: ترکیب پذیری قراردادهای هوشمند
-description:
-lang: fa
-incomplete: true
----
-
-## معرفی مختصر {#a-brief-introduction}
-
-قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. برای تبدیل شدن به یک توسعه دهنده dapp نیازی به نوشتن قرارداد هوشمند خود ندارید، فقط باید بدانید که چگونه با آنها تعامل داشته باشید. برای مثال، میتوانید از قراردادهای هوشمند موجود در [Uniswap](https://uniswap.exchange/swap)، یک صرافی غیرمتمرکز، برای مدیریت همه منطق مبادله توکن ها در برنامه خود استفاده کنید - لازم نیست از صفر شروع کنید. برخی از قراردادهای [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) و v3 را بررسی کنید.
-
-## ترکیبپذیری چیست؟ {#what-is-composability}
-
-ترکیب پذیری به معنای ترکیب کامپوننت های مجزا، با یکدیگر، به منظور ساخت یک سیستم و یا خروجی جدید می باشد. در توسعه نرمافزار، مبحث ترکیب پذیری به این معناست که توسعه دهنده می توانند با استفاده مجدد از کامپوننت های نرم افزاری موجود، یک اپلیکیشن جدید مد نظر خود را بسازند. یک راه خوب برای درک ترکیب پذیری این است که قطعات ترکیب پذیر را به صور قطعات لگو در نظر بگیریم. هر یک از قطعات لگو، می تواند با سایر قطعات تلفیق شده و با این تلفیق هایی که انجام میشود، قابلیت ساخت سازه های پیچیده ای را فراهم کند.
-
-در اتریوم، قراردادهای هوشمند را میتوان به نوعی مشابه یک پازل یا لگو داست که می توانید با کنار هم قراردادن پروژه های مختلف در قرارداد هوشمندتان، پروژه خود را بسازید. این موضوع به این معناست که نیاز نیست چرخ را دوباره اختراع کنید و یا ساخت پروژه خود را از صفر شروع کنید.
-
-## ترکیب پذیری چگونه عمل میکند؟ {#how-does-composability-work}
-
-قراردادهای هوشمند اتریومی، مشابه API های عمومی هستند که هر کسی می تواند با آنها ارتباط برقرار کرده و یا اپلیکیشن غیر متمرکز خود را با ویژگی های مد نظر، با آن تطبیق داده و یکپارچه کند. به عبارت کلی در خصوص ترکیب پذیری در قراردادهای هوشمند میتوان به سه اصل اساسی و مهم اشاره کرد: ماژولاریتی، خود اجرا بودن، و قابلیت دسترسی:
-
-**1. ماژولاریتی**: به معنای ویژگی هر کامپوننت برای انجام یک عملیات خاص و مشخص می باشد. هر کدام از قراردادهای هوشمند در اتریوم، یک مورد استفاده مخصوص به خود دارد. (همانطور که در مثال Uniswap نمایش داده شده است).
-
-**2. استقلال یا خوداجرایی**: کامپوننت هایی که قابل ترکیب هستند باید بتوانند به صورت مجزا از یکدیگر عمل کنند. هر قرارداد هوشمند در اتریوم، به صورت خودمختار اجرا میشود و میتواند بدون نیاز به بقیه المان های سیستم کار کند.
-
-**3. قابلیت دسترسی**: در صورتی که کتابخانه ها و یا قراردادهای هوشمندی که توسعه دهنده ها بخواهند از آنها در اپلیکیشن های خود استفاده کنند، به صورت عمومی در دسترس نباشند، توسعه دهنده ها نمیتوانند آنها را فراخوانی کرده و از آنها استفاده کنند. با توجه به نوع طراحی پیش فرض در شبکه اتریوم، قراردادهای هوشمند کد باز بوده و هر کسی میتواند این قراردادها را فراخوانی و استفاده نموده و یا کدهای مورد نظر خود را از یک مخزن منشعب نموده و از آن استفاده کند.
-
-## مزایای ترکیب پذیری {#benefits-of-composability}
-
-### چرخه توسعه کوتاه تر {#shorter-development-cycle}
-
-در زمان تولید [اپلیکیشن های غیرمتمرکز](/dapps/#what-are-dapps) (یا dapp ها) ترکیب پذیری می تواند باعث کاهش حجم کار توسعه دهنده های نرمافزار شود. [همانطور که Naval Ravikant می گوید: ](https://twitter.com/naval/status/1444366754650656770) "متن باز یعنی هر مشکلی فقط باید یکبار حل شود."
-
-اگر یک قرارداد هوشمند میتواند یک مشکل را حل کند، سایر توسعه دهنده ها می توانند از آن استفاده کنند و نیازی نیست که یک مشکل یکسان را دوباره حل کنند. بدین ترتیب توسعه دهنده ها میتوانند با استفاده از کتابخانه های موجود و اضافه کردن قابلیت های اضافی به آنها، اپلیکیشن های غیر متمرکز جدیدی را بسازند.
-
-### نوآوری بیشتر {#greater-innovation}
-
-ترکیب پذیری، مشوقی برای نوآوری و تجربه های بیشتر است، به این خاطر که توسعه دهنده ها می توانند به راحتی و آزادانه از کدهای موجود استفاده مجدد کنند، آنها را تغییر دهند، کپی کنند، و یا به هر ترتیب دیگری جهت رسیدن به نتیجه مطلوب خود بهره ببرند. در نتیجه، تیم های نرم افزاری زمان کمتری را برای پیادهسازی قابلیت های ابتدایی و ساده سپری خواهند کرد و میتوانند زمان خود را صرف ویژگی های بهتر و تجربه موارد جدیدتر کنند.
-
-### تجربه کاربری بهتر {#better-user-experience}
-
-ارتباط بین کامپوننت ها در اکوسیستم اتریوم باعث افزایش تجربه کاربری می شود. در اکوسیستمی که اپلیکیشن های غیرمتمرکز با سایر قراردادهای هوشمند مورد نیاز یکپارچه شده باشند، دست کاربر برای دسترسی به امکانات و قابلیت های بیشتر، نسبت به زمانی که در یک اکوسیستم، اپلیکیشن ها نتوانند با یکدیگر ارتباط برقرار کنند، بازتر است.
-
-به منظور نمایش مزایای قابلیت های ارتباط گیری بین اجزای مختلف، مثالی از یک آربیتراژ را استفاده خواهیم کرد:
-
-اگر توکنی در `صرافی A` قیمتی بیش از `صرافی B` داشته باشد، از این تفاوت قیمت میتوان برای کسب سود استفاده کرد. با این حال، تنها در زمانی میتوانید این کار رانجام دهید که سرمایه لازم برای اجرای تراکنش مورد نیاز را داشته باشید ( خرید توکن از `صرافی B` و فروش در `صرافی A`).
-
-در زمانی که سرمایه لازم برای انجام این ترید را نداشته باشید، استفاده از وام سریع یا همان flash loan گزینه ای ایده آل به حساب می آید. [وام های سریع](/defi/#flash-loans) مفهومی بسیار تکنیکال دارند، اما اگر بخواهیم به صورت ساده بگوئیم، ایده کلی به این صورت است که بدون نیاز به هیچ گونه گروگذاری یا داشتن سرمایه اولیه، می توان دارایی مورد نظر را قرض گرفت و البته که باید بازگشت وام، <0>در همان تراکنش0> صورت بگیرد.
-
-به مثال ابتدایی خود بر میگردیم، یک تریدر آربیتراژ می تواند با دریافت حجم زیادی وام سریع، توکن ها را از `صرافی B` خریده، آنها را در `صرافی A` بفروشد، وام گرفته شده را به همراه بهره آن بپردازد، و در نهایت سود باقیمانده را برای خود نگه دارد، و همه این اتفاقات تنها در همان یک تراکنش رخ می دهد. این منطق پیچیده نیاز به فراخوانی و استفاده ترکیبی از چندین قرارداد مختلف دارد، که در صورت نبود قابلیت ارتباط گیری بین قراردادهای هوشمند، امکانپذیر نبود.
-
-## مثالهایی از ترکیب پذیری در اتریوم {#composability-in-ethereum}
-
-### معاوضه توکنها {#token-swaps}
-
-اگر اپلیکیشن غیر متمرکزی بسازید که نیازمند پرداخت به تراکنش ها با اتر باشد، میتوانید از طریق یکپارچه سازی آن با منطق معاوضه توکن ها، قابلیت پرداخت با سایر توکن های ERC20 را برای کاربران فراهم کنید. این کد، پیش از اینکه تابع مورد نظر را اجرا کند، توکن کاربر را به صورت خودکار به اتر (ETH) تبدیل میکند.
-
-### حکومت {#governance}
-
-ساخت یک سیستم حاکمیتی سفارشی برای یک [DAO](/dao/) می تواند بسیار هزینه و زمان بر باشد. به جای آن، می توانید از یک تولکیت یا مجموعه ابزار متن باز حاکمیتی، مثل [Aragon Client](https://client.aragon.org/) استفاده کنید تا DAO خود را گسترش داده و به سرعت هر چه تمامتر یک چارچوب حاکمیتی بسازید.
-
-### مدیریت هویت {#identity-management}
-
-به جای ساختن یک سیستم احراز هویت و یا تکیه بر سرویس دهنده های متمرکز، می توانید ابزارهای هویت غیرمتمرکز (DID) را برای مدیریت احراز هویت کاربران با سیستم خود یکپارچه سازی و استفاده کنید. نمونه ای از این ابزارها، [SpruceID](https://www.spruceid.com/) است که قابلیت "ورود با اتریوم" را ارئه میدهد که با استفاده از آن کاربران میتوانند عملیات احراز هویت خود را با کیف پول اتریومی انجام دهند.
-
-## آموزش های مرتبط {#related-tutorials}
-
-- [رابط کاربری اپلیکیشن غیرمتمرکز خود را به سرعت با create-eth-app ایجاد کنید](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/)_- نمای کلی نحوه استفاده از create-eth-app برای ساخت اپلیکیشن ها که قراردادهای هوشمند نیز در آنها قابل استفاده هستند._
-
-## اطلاعات بیشتر {#further-reading}
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
-
-- [ترکیب پذیری، نوآوری است](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/)
-- [علت اهمیت ترکیب پذیری برای Web3](https://hackernoon.com/why-composability-matters-for-web3)
-- [ترکیب پذیری چیست؟](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
deleted file mode 100644
index ac046a229b2..00000000000
--- "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md"
+++ /dev/null
@@ -1,310 +0,0 @@
----
-title: تایید رسمی قراردادهای هوشمند
-description: مروری بر تایید رسمی قراردادهای هوشمند اتریوم
-lang: fa
----
-
-[قراردادهای هوشمند](/developers/docs/smart-contracts/) امکان ایجاد برنامههای غیرمتمرکز، بدون نیاز به اعتماد و قوی را فراهم میکنند که موارد استفاده جدیدی را معرفی کرده و ارزش را برای کاربران آزاد میکنند. از آنجایی که قراردادهای هوشمند مقادیر زیادی از ارزش را مدیریت میکنند، امنیت یک ملاحظهی حیاتی برای توسعهدهندگان است.
-
-تأیید رسمی یکی از تکنیک های توصیه شده برای بهبود [امنیت قرارداد هوشمند](/developers/docs/smart-contracts/security/) است. تأیید رسمی، که از [روشهای رسمی](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) برای تعیین، طراحی و تأیید برنامهها استفاده میکند، سالهاست که برای اطمینان از صحت سیستمهای سختافزاری و نرمافزاری حیاتی استفاده میشود.
-
-هنگامی که در قراردادهای هوشمند پیادهسازی می شود، تأیید رسمی می تواند ثابت کند که منطق تجاری یک قرارداد با مشخصات از پیش تعریف شده مطابقت دارد. در مقایسه با روشهای دیگر برای ارزیابی صحت کد قرارداد، مانند آزمایش، تأیید رسمی تضمینهای قویتری برای صحیح بودن قرارداد هوشمند میدهد.
-
-## تایید رسمی چیست؟ {#what-is-formal-verification}
-
-تأیید رسمی به فرآیند ارزیابی صحت یک سیستم با توجه به مشخصات رسمی اشاره دارد. به عبارت سادهتر، تأیید رسمی به ما امکان می دهد بررسی کنیم که آیا رفتار یک سیستم برخی از الزامات را برآورده می کند (یعنی آنچه را که ما می خواهیم انجام می دهد).
-
-رفتارهای مورد انتظار سیستم (در این مورد یک قرارداد هوشمند) با استفاده از مدلسازی رسمی توصیف میشوند، در حالی که زبانهای مشخصات امکان ایجاد خواص رسمی را فراهم میکنند. سپس تکنیکهای تأیید رسمی میتوانند تأیید کنند که اجرای یک قرارداد با مشخصات آن مطابقت دارد و اثبات ریاضی صحت قرارداد اول را به دست میآورد. زمانی که یک قرارداد با مشخصات خود مطابقت داشته باشد، به عنوان "صحیح عملکردی"، "درست بر اساس طراحی" یا "درست بر اساس ساخت" توصیف می شود.
-
-### مدل رسمی چیست؟ {#what-is-a-formal-model}
-
-در علوم کامپیوتر، [مدل رسمی](https://en.wikipedia.org/wiki/Model_of_computation) توصیفی ریاضی از یک فرآیند محاسباتی است. برنامهها به توابع ریاضی (معادلات) انتزاعی میشوند، و مدل نحوه محاسبه خروجیهای توابع را با توجه به ورودی توصیف میکند.
-
-مدلهای رسمی سطحی از انتزاع را فراهم میکنند که در آن تحلیل رفتار یک برنامه قابل ارزیابی است. وجود مدلهای رسمی امکان ایجاد یک _مشخصات رسمی_ را فراهم میکند که ویژگیهای مورد نظر مدل مورد نظر را توصیف میکند.
-
-تکنیکهای مختلفی برای مدلسازی قراردادهای هوشمند برای تأیید رسمی استفاده میشود. به عنوان مثال، برخی از مدل ها برای استدلال در مورد رفتار سطح بالای یک قرارداد هوشمند استفاده می شوند. این تکنیکهای مدلسازی یک نمای جعبه سیاه را برای قراردادهای هوشمند اعمال میکنند و آنها را به عنوان سیستمهایی میبینند که ورودیها را میپذیرند و محاسبات را بر اساس آن ورودیها اجرا میکنند.
-
-مدلهای سطح بالا بر رابطه بین قراردادهای هوشمند و عوامل خارجی، مانند حسابهای تحت مالکیت خارجی (EOAs)، حسابهای قراردادی و محیط بلاک چین تمرکز دارند. چنین مدل هایی برای تعریف ویژگی هایی مفید هستند که مشخص می کنند یک قرارداد چگونه باید در پاسخ به تعاملات خاص کاربر رفتار کند.
-
-برعکس، سایر مدلهای رسمی بر رفتار سطح پایین قرارداد هوشمند تمرکز دارند. در حالی که مدلهای سطح بالا میتوانند به استدلال در مورد عملکرد قرارداد کمک کنند، ممکن است نتوانند جزئیات مربوط به عملکرد داخلی پیادهسازی را ثبت کنند. مدلهای سطح پایین از نمای جعبه سفید برای تجزیه و تحلیل برنامه استفاده میکنند و برای استدلال در مورد ویژگیهای مربوط به اجرای قرارداد، به نمایشهای سطح پایینتر برنامههای قرارداد هوشمند، مانند ردیابی برنامه و [گرافهای جریان کنترل](https://en.wikipedia.org/wiki/Control-flow_graph) تکیه میکنند.
-
-مدلهای سطح پایین ایدهآل در نظر گرفته میشوند زیرا نشاندهنده اجرای واقعی یک قرارداد هوشمند در محیط اجرای اتریوم هستند (یعنی [EVM](/developers/docs/evm/)). تکنیکهای مدلسازی سطح پایین بهویژه در ایجاد ویژگیهای ایمنی حیاتی در قراردادهای هوشمند و شناسایی آسیبپذیریهای بالقوه مفید هستند.
-
-### مشخصات رسمی چیست؟ {#what-is-a-formal-specification}
-
-یک مشخصات به سادگی یک الزام فنی است که یک سیستم خاص باید برآورده کند. در برنامه نویسی، مشخصات، ایده های کلی در مورد اجرای یک برنامه (یعنی آنچه برنامه باید انجام دهد) را نشان می دهد.
-
-در زمینه قراردادهای هوشمند، مشخصات رسمی به _ویژگیها_ اشاره میکند—توضیحات رسمی الزاماتی که یک قرارداد باید برآورده کند. چنین ویژگی هایی به عنوان "غیر متغیر" توصیف می شوند و بیانگر ادعاهای منطقی در مورد اجرای یک قرارداد هستند که باید تحت هر شرایط ممکن، بدون هیچ استثنایی صادق باقی بماند.
-
-بنابراین، ما می توانیم مشخصات رسمی را به عنوان مجموعه ای از اظهارات نوشته شده به زبان رسمی در نظر بگیریم که اجرای مورد نظر یک قرارداد هوشمند را توصیف می کند. مشخصات، ویژگی های قرارداد را پوشش می دهد و نحوه رفتار قرارداد را در شرایط مختلف تعریف می کند. هدف از تأیید رسمی این است که مشخص شود آیا قرارداد هوشمند دارای این ویژگیها (غیر متغیرها) است یا خیر و اینکه این ویژگیها در طول اجرا نقض نمیشوند.
-
-مشخصات رسمی در توسعه پیادهسازی ایمن قراردادهای هوشمند حیاتی هستند. قراردادهایی که در اجرای خود موفق به پیادهسازی ثابتها نمیشوند یا خواص آنها نقض میشود، مستعد آسیبپذیریهایی هستند که میتوانند به عملکرد آسیب برسانند یا باعث سوء استفادههای مخرب شوند.
-
-## انواع مشخصات رسمی قراردادهای هوشمند {#formal-specifications-for-smart-contracts}
-
-مشخصات رسمی استدلال ریاضی در مورد صحت اجرای برنامه را امکانپذیر می کند. همانند مدلهای رسمی، مشخصات رسمی میتوانند ویژگیهای سطح بالا یا رفتار سطح پایین اجرای قرارداد را نشان دهند.
-
-مشخصات رسمی با استفاده از عناصر [منطق برنامه](https://en.wikipedia.org/wiki/Logic_programming) به دست میآیند که امکان استدلال رسمی در مورد ویژگیهای یک برنامه را فراهم میکند. یک منطق برنامه دارای قوانین رسمی است که رفتار مورد انتظار یک برنامه را (به زبان ریاضی) بیان میکند. منطق برنامه های مختلف در ایجاد مشخصات رسمی استفاده می شود، از جمله [منطق دسترسی پذیری](https://en.wikipedia.org/wiki/Reachability_problem)، [منطق زمانی](https://en.wikipedia.org/wiki/Temporal_logic)، و [منطق هوآر](https://en.wikipedia.org/wiki/Hoare_logic).
-
-مشخصات رسمی قراردادهای هوشمند را می توان به طور کلی به عنوان مشخصات **سطح بالا** یا **سطح پایین** طبقه بندی کرد. صرف نظر از اینکه یک مشخصات به چه دسته ای تعلق دارد، باید به طور کافی و بدون ابهام ویژگی سیستم مورد تجزیه و تحلیل را توصیف کند.
-
-### مشخصات سطح بالا {#high-level-specifications}
-
-همانطور که از نام آن پیداست، یک مشخصات سطح بالا (که "مشخصات مدل گرا" نیز نامیده می شود) رفتار سطح بالای یک برنامه را توصیف می کند. مشخصات سطح بالا یک قرارداد هوشمند را به عنوان یک [ماشین حالت متناهی](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) مدلسازی میکند که میتواند با انجام عملیات بین حالتها جابهجا شود، و از منطق زمانی برای تعریف خواص رسمی برای مدل FSM استفاده میشود.
-
-[منطقهای زمانی](https://en.wikipedia.org/wiki/Temporal_logic) "قوانینی برای استدلال درباره گزارههایی هستند که از نظر زمانی واجد شرایط هستند (مثلاً "من _همیشه_ گرسنه هستم" یا "من _در نهایت_ گرسنه خواهم شد.")" هنگامی که برای تأیید رسمی اعمال می شود، از منطق های زمانی برای بیان ادعاهای مربوط به رفتار صحیح سیستم های مدل سازی شده به عنوان ماشین های حالت استفاده می شود. به طور خاص، یک منطق زمانی وضعیتهای آیندهای را که یک قرارداد هوشمند میتواند در آن قرار گیرد و نحوه انتقال آن بین حالتها را توصیف میکند.
-
-مشخصات سطح بالا به طور کلی دو ویژگی مهم زمانی را برای قراردادهای هوشمند نشان می دهد: **ایمنی** و **زندهمانی**. ویژگی های ایمنی بیانگر این ایده است که "هیچ چیز بدی اتفاق نمی افتد" و معمولاً بیانگر تغییر ناپذیری است. یک ویژگی ایمنی ممکن است الزامات کلی نرمافزار را تعریف کند، مانند آزادی از [قفل شدن](https://www.techtarget.com/whatis/definition/deadlock)، یا خواص خاص دامنه را برای قراردادها بیان کند (به عنوان مثال، ثابتهای کنترل دسترسی برای توابع، مقادیر مجاز متغیرهای حالت یا شرایط برای انتقال توکن).
-
-به عنوان مثال این الزام ایمنی را در نظر بگیرید که شرایط استفاده از `transfer()` یا `transferFrom()` در قراردادهای توکن ERC-20 را پوشش می دهد: _"باقیمانده حساب فرستنده هرگز کمتر از مقدار درخواستی توکنهای ارسال شده نیست."_. این توصیف به زبان طبیعی از یک قرارداد ثابت را می توان به یک مشخصات رسمی (ریاضی) ترجمه کرد، که سپس می توان آن را به شدت از نظر اعتبار بررسی کرد.
-
-خواص زنده بودن تأکید میکنند که "بالاخره اتفاق خوبی میافتد" و مربوط به توانایی یک قرارداد برای پیشرفت از طریق حالات مختلف است. یک مثال از ویژگی زنده بودن "نقدینگی" است که به توانایی یک قرارداد برای انتقال موجودی خود به کاربران در صورت درخواست اشاره دارد. اگر این ویژگی نقض شود، کاربران نمیتوانند داراییهای ذخیرهشده در قرارداد را برداشت کنند، مانند آنچه در [حادثه کیف پول Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) اتفاق افتاد.
-
-### مشخصات سطح پایین {#low-level-specifications}
-
-مشخصات سطح بالا به عنوان نقطه شروع یک مدل حالت محدود از یک قرارداد را در نظر گرفته و ویژگی های مورد نظر این مدل را تعریف می کند. در مقابل، مشخصات سطح پایین (که همچنین به عنوان "مشخصات گرا به ویژگی" شناخته میشوند) اغلب برنامهها (قراردادهای هوشمند) را به عنوان سیستمهایی متشکل از مجموعهای از توابع ریاضی مدلسازی میکنند و رفتار صحیح چنین سیستمهایی را توصیف میکنند.
-
-به عبارت سادهتر، مشخصات سطح پایین _ردهای برنامه_ را تجزیه و تحلیل می کنند و سعی می کنند ویژگی های یک قرارداد هوشمند را بر روی این ردیابی ها تعریف کنند. ردیابیها به توالیهای اجرای توابع اشاره دارند که حالت یک قرارداد هوشمند را تغییر میدهند؛ از این رو، مشخصات سطح پایین به مشخص کردن الزامات برای اجرای داخلی یک قرارداد کمک میکنند.
-
-مشخصات رسمی سطح پایین را می توان به عنوان ویژگی های سبک هوآر یا به صورت ثابت در مسیرهای اجرا ارائه کرد.
-
-### خواص سبک هوآر {#hoare-style-properties}
-
-[منطق هوآر](https://en.wikipedia.org/wiki/Hoare_logic) مجموعهای از قوانین رسمی را برای استدلال در مورد صحت برنامهها، از جمله قراردادهای هوشمند، ارائه میکند. یک ویژگی به سبک هوآر با یک سهگانه هوآر {_P_}_c_{_Q_} نشان داده میشود، که در آن _c_ یک برنامه است و _P_ و _Q_ گزارههایی در مورد حالت c (یعنی برنامه) هستند که به ترتیب به صورت _پیش شرطها_ و _پس شرطها_ توصیف میشوند.
-
-پیش شرط یک گزاره است که شرایط لازم برای اجرای صحیح یک تابع را توصیف می کند. کاربرانی که قرارداد را امضا می کنند باید این شرط را برآورده کنند. پیش شرط یک گزاره است که شرایط لازم برای اجرای صحیح یک تابع را توصیف می کند. کاربرانی که قرارداد را امضا کنند باید این شرط را تعیین کنند. یک _ثابت_ در منطق هوآر یک گزاره است که توسط اجرای یک تابع حفظ میشود (یعنی تغییر نمیکند).
-
-مشخصات سبک هوآر می تواند _صحت جزئی_ یا _صحت کامل_ را تضمین کند. اگر پیش شرط قبل از اجرای تابع صادق باشد، اجرای یک تابع قرارداد "تا حدی صحیح" است، و اگر اجرا خاتمه یابد، پس شرط نیز صادق است. اگر یک پیش شرط قبل از اجرای تابع درست باشد، اثبات صحت کلی به دست میآید، اجرا تضمین میشود که پایان یابد و زمانی که انجام شد، شرط پسشرط صادق است.
-
-کسب اثبات صحت کامل دشوار است زیرا برخی از اجراها ممکن است قبل از خاتمه به تأخیر بیفتند یا اصلاً هرگز خاتمه نیابند. با این حال، این سؤال که آیا اجرا خاتمه مییابد یا خیر، قابل بحث است، زیرا مکانیسم گس اتریوم از حلقههای بینهایت برنامه جلوگیری میکند (اجرا یا با موفقیت خاتمه مییابد یا به دلیل خطای "تمام شدن گس" پایان مییابد).
-
-مشخصات قرارداد هوشمند ایجاد شده با استفاده از منطق هوآر دارای پیششرطها، پسشرطها و متغیرهایی هستند که برای اجرای توابع و حلقهها در یک قرارداد تعریف شدهاند. پیششرطها اغلب شامل امکان ورودیهای اشتباه به یک تابع هستند، با شرایط پسشرطی که پاسخ مورد انتظار به این ورودیها را توصیف میکنند (به عنوان مثال، ایجاد یک استثنا خاص). به این ترتیب ویژگی های سبک هوآر برای اطمینان از صحت اجرای قرارداد مؤثر است.
-
-بسیاری از چارچوبهای تأیید رسمی از مشخصات سبک هوآر برای اثبات صحت معنایی توابع استفاده میکنند. همچنین میتوان خواص به سبک هوآر (به عنوان ادعاها) را به طور مستقیم با استفاده از عبارات `require` و `assert` در سالیدیتی به کد قرارداد اضافه کرد.
-
-عبارات `require` بیانگر یک پیش شرط یا ثابت هستند و اغلب برای اعتبارسنجی ورودی های کاربر استفاده می شوند، در حالی که `assert` یک شرط پسین لازم برای ایمنی را نشان می دهد. به عنوان مثال، کنترل دسترسی مناسب برای توابع (مثالی از یک ویژگی ایمنی) را میتوان با استفاده از `require` به عنوان یک بررسی پیش شرط بر روی هویت حساب فراخوانی کننده به دستآورد. به طور مشابه، یک ثابت بر روی مقادیر مجاز متغیرهای حالت در یک قرارداد (به عنوان مثال، کل تعداد توکنهای در گردش) را میتوان از نقض با استفاده از `assert` برای تأیید وضعیت قرارداد پس از اجرای تابع محافظت کرد.
-
-### ویژگیهای سطح ردیابی {#trace-level-properties}
-
-مشخصات مبتنی بر ردیابی عملیاتهایی را توصیف میکنند که یک قرارداد را بین حالتهای مختلف انتقال میدهند و روابط بین این عملیاتها را مشخص میکنند. همانطور که قبلا توضیح داده شد، ردیابی ها دنباله ای از عملیات هستند که وضعیت یک قرارداد را به روشی خاص تغییر می دهند.
-
-این رویکرد بر مدل قراردادهای هوشمند به عنوان سیستمهای انتقال حالت با برخی حالتهای از پیش تعریفشده (توصیفشده توسط متغیرهای حالت) به همراه مجموعهای از انتقالهای از پیش تعریفشده (توصیفشده توسط توابع قرارداد) متکی است. علاوه بر این، یک [گراف جریان کنترل](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG)، که یک نمایش گرافیکی از جریان اجرای یک برنامه است، اغلب برای توصیف معنایی عملیاتی یک قرارداد استفاده میشود. در اینجا، هر ردیابی به عنوان یک مسیر در نمودار جریان کنترل نشان داده می شود.
-
-در درجه اول، مشخصات سطح ردیابی برای استدلال در مورد الگوهای اجرای داخلی در قراردادهای هوشمند استفاده می شود. با ایجاد مشخصات سطح ردیابی، ما مسیرهای اجرایی قابل قبول (به عنوان مثال، انتقال حالت) را برای یک قرارداد هوشمند اعلام می کنیم. با استفاده از تکنیک هایی مانند اجرای نمادین، می توانیم به طور رسمی تأیید کنیم که اجرا هرگز از مسیری پیروی نمی کند که در مدل رسمی تعریف نشده است.
-
-بیایید از نمونه ای از قرارداد [DAO](/dao/) استفاده کنیم که دارای برخی از توابع در دسترس عموم برای توصیف ویژگی های سطح ردیابی است. در اینجا، ما فرض می کنیم که قرارداد DAO به کاربران اجازه می دهد تا عملیات زیر را انجام دهند:
-
-- واریز وجه
-
-- رای دادن به یک پیشنهاد پس از واریز وجوه
-
-- درخواست بازپرداخت در صورت عدم رای دادن به یک پیشنهاد
-
-نمونهای از ویژگیهای سطح ردیابی میتواند _"کاربرانی که وجوهی را واریز نمیکنند نمیتوانند به پیشنهادی رای دهند"_ یا _"کاربرانی که به پیشنهادی رای نمیدهند همیشه باید بتوانند ادعای بازپرداخت داشته باشند" _. هر دو ویژگی ترتیب ترجیحی اجرا را بیان میکنند (رایگیری نمیتواند _قبل از_ واریز وجوه انجام شود و ادعای بازپرداخت نمیتواند _پس از_ رای دادن به یک پیشنهاد انجام شود).
-
-## تکنیکهایی برای تأیید رسمی قراردادهای هوشمند {#formal-verification-techniques}
-
-### بررسی مدل {#model-checking}
-
-بررسی مدل یک تکنیک تأیید رسمی است که در آن یک الگوریتم مدل رسمی یک قرارداد هوشمند را در برابر مشخصات آن بررسی میکند. در بررسی مدل، قراردادهای هوشمند اغلب به عنوان سیستمهای انتقال حالت نشان داده میشوند، در حالی که ویژگیهای روی حالتهای قرارداد مجاز با استفاده از منطق زمانی تعریف میشوند.
-
-بررسی مدل مستلزم ایجاد یک نمایش ریاضی انتزاعی از یک سیستم (به عنوان مثال، یک قرارداد) و بیان ویژگیهای این سیستم با استفاده از فرمولهایی است که ریشه در [منطق گزارهای](https://www.baeldung.com/cs/propositional-logic) دارند. این کار الگوریتم بررسی مدل را ساده می کند، یعنی ثابت کند که یک مدل ریاضی یک فرمول منطقی معین را برآورده می کند.
-
-بررسی مدل در راستیآزمایی رسمی عمدتاً برای ارزیابی ویژگیهای زمانی استفاده میشود که رفتار یک قرارداد را در طول زمان توصیف میکنند. ویژگی های موقت قراردادهای هوشمند شامل _ایمنی_ و _زندگی_ است که قبلا توضیح دادیم.
-
-به عنوان مثال، یک ویژگی امنیتی مربوط به کنترل دسترسی (به عنوان مثال، _فقط مالک قرارداد می تواند `selfdestruct`_ را فراخوانی کند) می تواند در منطق رسمی نوشته شود. پس از آن، الگوریتم بررسی مدل می تواند تأیید کند که آیا قرارداد با این مشخصات رسمی مطابقت دارد یا خیر.
-
-بررسی مدل از کاوش فضای حالت استفاده میکند، که شامل ساخت همه حالتهای ممکن یک قرارداد هوشمند و تلاش برای یافتن حالتهای قابل دسترسی است که منجر به نقض مالکیت میشود. با این حال، این می تواند به تعداد نامحدودی از حالت ها منجر شود (معروف به "مشکل انفجار حالت")، از این رو بررسی کنندگان مدل برای امکان تحلیل کارآمد قراردادهای هوشمند به تکنیک های انتزاعی تکیه می کنند.
-
-### اثبات قضیه {#theorem-proving}
-
-اثبات قضیه روشی برای استدلال ریاضی درباره صحت برنامه ها از جمله قراردادهای هوشمند است. این شامل تبدیل مدل سیستم قرارداد و مشخصات آن به فرمول های ریاضی (گزاره های منطقی) است.
-
-هدف از اثبات قضیه، تأیید هم ارزی منطقی بین این گزاره ها است. "تعادل منطقی" (که "منطقی دو مفهومی" نیز نامیده می شود) نوعی رابطه بین دو عبارت است به طوری که گزاره اول درست است _اگر و فقط اگر_ گزاره دوم درست باشد.
-
-رابطه مورد نیاز (تعادل منطقی) بین گزارههای مربوط به مدل قرارداد و ویژگیهای آن به عنوان یک گزاره قابل اثبات (به نام قضیه) فرموله میشود. با استفاده از یک سیستم رسمی استنتاج، اثبات کننده قضیه خودکار می تواند اعتبار قضیه را تأیید کند. به عبارت دیگر، یک اثبات کننده قضیه می تواند به طور قطعی ثابت کند که مدل قرارداد هوشمند دقیقاً با مشخصات آن مطابقت دارد.
-
-در حالی که مدلهای بررسی مدل به عنوان سیستمهای انتقالی با حالتهای محدود منقبض میشوند، اثبات قضیه میتواند تجزیه و تحلیل سیستمهای حالت نامتناهی را انجام دهد. با این حال، این بدان معناست که یک اثبات کننده قضیه خودکار همیشه نمی تواند بفهمد که آیا یک مسئله منطقی "قابل تصمیم گیری" است یا خیر.
-
-در نتیجه، کمک های انسانی اغلب برای راهنمایی اثبات کننده قضیه در استخراج براهین صحت مورد نیاز است. استفاده از تلاش انسانی در اثبات قضیه، استفاده از آن را نسبت به بررسی مدل که کاملاً خودکار است، گرانتر میکند.
-
-### اجرای نمادین {#symbolic-execution}
-
-اجرای نمادین روشی برای تجزیه و تحلیل قرارداد هوشمند با اجرای توابع با استفاده از _مقادیر نمادین_ (به عنوان مثال، `x > 5`) به جای _مقادیر مشخص_ ( به عنوان مثال، `x == 5`). به عنوان یک تکنیک تأیید رسمی، اجرای نمادین برای استدلال رسمی در مورد ویژگیهای سطح ردیابی در کد قرارداد استفاده میشود.
-
-اجرای نمادین یک رد اجرا را به عنوان یک فرمول ریاضی بر روی مقادیر ورودی نمادین نشان می دهد که در غیر این صورت _گزاره مسیر_ نامیده می شود. یک [حلکننده SMT](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) برای بررسی اینکه آیا یک گزاره مسیر "رضایتپذیر" است یا نه استفاده میشود (یعنی مقداری وجود دارد که میتواند فرمول را برآورده کند). اگر یک مسیر آسیب پذیر قابل رضایت باشد، حل کننده SMT یک مقدار مشخص ایجاد می کند که اجرای آن را به سمت آن مسیر هدایت می کند.
-
-فرض کنید تابع قرارداد هوشمند یک مقدار `uint` (`x`) را به عنوان ورودی می گیرد و زمانی که `x` بزرگتر از `5` باشد برمی گردد. و همچنین کمتر از `10`. یافتن مقداری برای `x` که خطا را با استفاده از یک روش آزمایش معمولی ایجاد میکند، مستلزم اجرای دهها تست (یا بیشتر) بدون اطمینان از یافتن ورودی محرک خطا است.
-
-برعکس، یک ابزار اجرای نمادین تابع را با مقدار نمادین اجرا می کند: `X > 5 ∧ X < 10` (یعنی `x` بزرگتر از 5 است و `x` کمتر از 10 است). گزاره مسیر مرتبط `x = X > 5 ∧ X < 10` سپس به حل کننده SMT داده می شود تا حل کند. اگر مقدار خاصی با فرمول `x = X > 5 ∧ X < 10`، حلکننده SMT آن را محاسبه میکند - برای مثال، حلکننده ممکن است `7` را به عنوان مقدار `x` تولید کند.
-
-از آنجایی که اجرای نمادین به ورودی های یک برنامه متکی است و مجموعه ورودی ها برای کاوش همه حالت های قابل دسترسی به طور بالقوه نامحدود است، هنوز هم نوعی آزمایش است. با این حال، همانطور که در مثال نشان داده شده است، اجرای نمادین کارآمدتر از آزمایش معمولی برای یافتن ورودی هایی است که باعث نقض مالکیت می شود.
-
-علاوه بر این، اجرای نمادین نسبت به سایر تکنیکهای مبتنی بر ویژگی (مثلاً فازی) که بهطور تصادفی ورودیهای یک تابع را تولید میکنند، نکات مثبت کاذب کمتری تولید میکند. اگر یک حالت خطا در طول اجرای نمادین ایجاد شود، می توان یک مقدار مشخص ایجاد کرد که باعث ایجاد خطا و بازتولید مسئله می شود.
-
-اجرای نمادین همچنین می تواند درجاتی از اثبات ریاضی درستی را ارائه دهد. مثال زیر از یک تابع قرارداد با حفاظت از سرریز را در نظر بگیرید:
-
-```
-function safe_add(uint x, uint y) returns(uint z){
-
- z = x + y;
- require(z>=x);
- require(z>=y);
-
- return z;
-```
-
-یک ردیابی اجرا که منجر به سرریز اعداد صحیح می شود باید این فرمول را برآورده کند: `z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)` بعید است چنین فرمولی حل شود، از این رو یک اثبات ریاضی است که تابع `safe_add` هرگز سرریز نمی شود.
-
-### چرا از تأیید رسمی برای قراردادهای هوشمند استفاده کنیم؟ {#benefits-of-formal-verification}
-
-#### نیاز به قابلیت اطمینان {#need-for-reliability}
-
-راستیآزمایی رسمی برای ارزیابی درستی سیستمهای حیاتی ایمنی استفاده میشود که خرابی آنها میتواند عواقب مخربی مانند مرگ، جراحت یا خرابی مالی داشته باشد. قراردادهای هوشمند، برنامههای کاربردی با ارزشی هستند که مقادیر زیادی از ارزش را کنترل میکنند و خطاهای ساده در طراحی میتواند منجر به
-خسارت جبرانناپذیر برای کاربران شود. با این حال، تأیید رسمی یک قرارداد قبل از استقرار، میتواند تضمینهایی را افزایش دهد که پس از اجرا بر روی بلاکچین، مطابق انتظار عمل میکند.
-
-قابلیت اطمینان یک کیفیت بسیار مطلوب در هر قرارداد هوشمند است، به خصوص به این دلیل که کد مستقر شده در ماشین مجازی اتریوم (EVM) معمولاً تغییرناپذیر است. از آنجایی که بروزرسانیهای پس از راهاندازی به راحتی قابل دسترسی نیستند، نیاز به تضمین قابلیت اطمینان قراردادها تأیید رسمی را ضروری میکند. راستیآزمایی رسمی میتواند مسائل پیچیدهای مانند سرریز و سرریز اعداد صحیح، ورود مجدد و بهینهسازی ضعیف گاز را شناسایی کند که ممکن است از دست حسابرسان و آزمایشکنندگان خارج شود.
-
-
-
-#### اثبات صحت عملکرد {#prove-functional-correctness}
-
-تست برنامه رایج ترین روش برای اثبات اینکه یک قرارداد هوشمند برخی از الزامات را برآورده می کند. این شامل اجرای یک قرارداد با نمونهای از دادههایی است که انتظار میرود مدیریت کند و رفتار آن را تحلیل کند. اگر قرارداد نتایج مورد انتظار را برای داده های نمونه برگرداند، توسعه دهندگان اثبات عینی برای صحت آن دارند.
-
-با این حال، این رویکرد نمی تواند اجرای صحیح را برای مقادیر ورودی که بخشی از نمونه نیستند ثابت کند. بنابراین، آزمایش یک قرارداد ممکن است به شناسایی اشکالات کمک کند (به عنوان مثال، اگر برخی از مسیرهای کد نتوانند نتایج دلخواه را در طول اجرا برگردانند)، اما **نمیتواند به طور قطعی عدم وجود اشکالات را ثابت کند**.
-
-برعکس، راستیآزمایی رسمی میتواند به طور رسمی ثابت کند که یک قرارداد هوشمند نیازمندیهای دامنه بینهایتی از اجراها را _بدون_ اجرای قرارداد برآورده میکند. این امر مستلزم ایجاد یک مشخصات رسمی است که دقیقاً رفتارهای صحیح قرارداد را توصیف می کند و یک مدل رسمی (ریاضی) از سیستم قرارداد را توسعه می دهد. سپس میتوانیم یک روش اثبات رسمی را برای بررسی سازگاری بین مدل قرارداد و مشخصات آن دنبال کنیم.
-
-با تأیید رسمی، سؤال تأیید اینکه آیا منطق تجاری یک قرارداد الزامات را برآورده می کند یک گزاره ریاضی است که می تواند اثبات یا رد شود. با اثبات رسمی یک گزاره، میتوانیم تعداد نامتناهی از موارد آزمایشی را با تعداد مراحل محدود تأیید کنیم. به این ترتیب تأیید رسمی چشم اندازهای بهتری برای اثبات صحت عملکرد قرارداد با توجه به مشخصات دارد.
-
-
-
-#### اهداف تأیید ایده آل {#ideal-verification-targets}
-
-هدف راستیآزمایی، سیستمی را که باید بهطور رسمی تأیید شود، توصیف میکند. تأیید رسمی به بهترین وجه در «سیستمهای تعبیهشده» (نرمافزارهای کوچک و ساده که بخشی از یک سیستم بزرگتر را تشکیل میدهند) استفاده میشود. آنها همچنین برای دامنه های تخصصی که قوانین کمی دارند ایده آل هستند، زیرا این کار تغییر ابزارها را برای تأیید ویژگی های خاص دامنه آسان تر می کند.
-
-قراردادهای هوشمند - حداقل تا حدی - هر دو الزام را برآورده می کنند. به عنوان مثال، اندازه کوچک قراردادهای اتریوم باعث می شود که آنها را به تأیید رسمی برساند. به طور مشابه، EVM از قوانین ساده پیروی می کند، که تعیین و تأیید ویژگی های معنایی را برای برنامه های در حال اجرا در EVM آسان تر می کند.
-
-
-
-### چرخه توسعه سریعتر {#faster-development-cycle}
-
-تکنیکهای تأیید رسمی، مانند بررسی مدل و اجرای نمادین، معمولاً کارآمدتر از تجزیه و تحلیل منظم کد قرارداد هوشمند (که در طول آزمایش یا ممیزی انجام میشود) هستند. این به این دلیل است که تأیید رسمی برای آزمایش ادعاها به مقادیر نمادین متکی است ("اگر کاربر سعی کند _n_ اتر را خارج کند چه؟" برخلاف آزمایشی که از مقادیر مشخصی استفاده می کند ("اگر کاربر بخواهد 5 اتر را خارج کند چه؟".
-
-متغیرهای ورودی نمادین میتوانند چندین کلاس از مقادیر بتن را پوشش دهند، بنابراین رویکردهای تأیید رسمی پوشش کد بیشتری را در بازه زمانی کوتاهتر وعده میدهند. هنگامی که به طور موثر استفاده می شود، تأیید رسمی می تواند چرخه توسعه را برای توسعه دهندگان تسریع کند.
-
-تأیید رسمی همچنین فرآیند ساخت دپها (dapps) را با کاهش خطاهای طراحی پرهزینه بهبود می بخشد. ارتقاء قراردادها (در صورت امکان) برای رفع آسیب پذیری ها مستلزم بازنویسی گسترده پایگاه های کد و تلاش بیشتر برای توسعه است. راستیآزمایی رسمی میتواند بسیاری از خطاها را در اجرای قرارداد شناسایی کند که ممکن است آزمایشکنندگان و حسابرسان را پشت سر بگذارد و فرصت کافی برای رفع آن مشکلات قبل از استقرار قرارداد فراهم میکند.
-
-
-
-## معایب تأیید رسمی {#drawbacks-of-formal-verification}
-
-
-
-### هزینه نیروی کار {#cost-of-manual-labor}
-
-راستیآزمایی رسمی، بهویژه تأیید نیمه خودکار که در آن یک انسان اثباتکننده را برای به دست آوردن اثبات صحت راهنمایی میکند، به کار دستی قابلتوجهی نیاز دارد. علاوه بر این، ایجاد مشخصات رسمی یک فعالیت پیچیده است که به سطح بالایی از مهارت نیاز دارد.
-
-این عوامل (تلاش و مهارت) تأیید رسمی را در مقایسه با روشهای معمول ارزیابی صحت قراردادها، مانند آزمایش و ممیزی، پرهزینهتر و پرهزینهتر میسازد. با این وجود، با توجه به هزینه خطاها در اجرای قراردادهای هوشمند، پرداخت هزینه برای ممیزی تأیید کامل عملی است.
-
-
-
-### منفی های کاذب {#false-negatives}
-
-تأیید رسمی فقط می تواند بررسی کند که آیا اجرای قرارداد هوشمند با مشخصات رسمی مطابقت دارد یا خیر. به این ترتیب، مهم است که مطمئن شوید مشخصات به درستی رفتارهای مورد انتظار یک قرارداد هوشمند را توصیف می کند.
-
-اگر مشخصات ضعیف نوشته شده باشند، نقض ویژگیها - که به اعدامهای آسیبپذیر اشاره دارد - توسط ممیزی تأیید رسمی قابل شناسایی نیست. در این مورد، یک توسعه دهنده ممکن است به اشتباه فرض کند که قرارداد بدون اشکال است.
-
-
-
-### مسائل مربوط به عملکرد {#performance-issues}
-
-تأیید رسمی با تعدادی از مشکلات عملکرد مواجه می شود. برای مثال، مشکلات انفجار حالت و مسیر که به ترتیب در حین بررسی مدل و بررسی نمادین با آن مواجه میشوند، میتوانند بر رویههای تأیید تأثیر بگذارند. همچنین، ابزارهای تأیید رسمی اغلب از حل کننده های SMT و سایر حل کننده های محدودیت در لایه زیرین خود استفاده می کنند و این حل کننده ها بر رویه های محاسباتی فشرده تکیه می کنند.
-
-همچنین، تعیین اینکه آیا یک ویژگی (که به عنوان یک فرمول منطقی توصیف میشود) میتواند برآورده شود یا خیر، برای تأییدکنندگان برنامه همیشه امکانپذیر نیست («[مشکل تصمیمپذیری](https://en.wikipedia.org/wiki/Decision_problem)») زیرا ممکن است یک برنامه هرگز خاتمه یابد. به این ترتیب، ممکن است اثبات برخی از خواص برای یک قرارداد، حتی اگر به خوبی مشخص شده باشد، غیرممکن باشد.
-
-
-
-## ابزارهای تأیید رسمی قراردادهای هوشمند اتریوم {#formal-verification-tools}
-
-
-
-### زبان های مشخصات برای ایجاد مشخصات رسمی {#specification-languages}
-
-**Act**: _*Act اجازه میدهد تا مشخصات بهروزرسانیهای ذخیرهسازی، شرایط قبل/پست و متغیرهای قرارداد را مشخص کنید. مجموعه ابزار آن همچنین دارای پشتیبانهای اثباتی است که میتوانند ویژگیهای زیادی را از طریق Coq، حلکنندههای SMT یا hevm اثبات کنند.**
-
-- [گیتهاب](https://github.com/ethereum/act)
-- [اسناد](https://ethereum.github.io/act/)
-
-**Scribble** - _*Scribble حاشیه نویسی کد در زبان مشخصات Scribble را به ادعاهای مشخصی تبدیل می کند که مشخصات را بررسی می کند.**
-
-- [مستندات](https://docs.scribble.codes/)
-
-**Dafny** - _*Dafny یک زبان برنامه نویسی آماده تأیید است که برای استدلال و اثبات درستی کد به حاشیه نویسی های سطح بالا متکی است.**
-
-- [گیتهاب](https://github.com/dafny-lang/dafny)
-
-
-
-### تأیید کننده های برنامه برای بررسی صحت {#program-verifiers}
-
-**Certora Prover** - _Certora Prover یک ابزار تأیید رسمی خودکار برای بررسی صحت کد در قراردادهای هوشمند است. مشخصات به زبان CVL (زبان تأیید Certora) نوشته شده است، با استفاده از ترکیبی از تجزیه و تحلیل استاتیک و حل محدودیت، نقض مالکیت شناسایی میشود._
-
-- [وبسایت](https://www.certora.com/)
-- [اسناد](https://docs.certora.com/en/latest/index.html)
-
-**Solidity SMTCchecker** - _*Solidity's SMTCchecker یک مدل بررسی کننده داخلی است که بر اساس SMT (تئوری های مدول رضایت پذیری) و حل شاخ است. تأیید می کند که کد منبع قرارداد با مشخصات در طول تدوین مطابقت دارد یا خیر و به طور ایستا نقض ویژگی های ایمنی را بررسی می کند.**
-
-- [گیتهاب](https://github.com/ethereum/solidity)
-
-**solc-verify** - _*solc-verify نسخه توسعه یافته کامپایلر سالیدیتی است که می تواند با استفاده از حاشیه نویسی و تأیید برنامه مدولار، تأیید رسمی خودکار را روی کد سالیدیتی انجام دهد.**
-
-- [گیتهاب](https://github.com/SRI-CSL/solidity)
-
-**KEVM** - _*KEVM یک معناشناسی رسمی از ماشین مجازی اتریوم (EVM) است که در چارچوب K نوشته شده است. KEVM قابل اجرا است و میتواند برخی ادعاهای مربوط به ویژگی را با استفاده از منطق دسترسپذیری اثبات کند.**
-
-- [گیتهاب](https://github.com/runtimeverification/evm-semantics)
-- [مستندات](https://jellopaper.org/)
-
-
-
-### چارچوب های منطقی برای اثبات قضیه {#theorem-provers}
-
-**Isabelle** - _Isabelle/HOL یک دستیار اثبات است که به فرمول های ریاضی اجازه می دهد تا به زبان رسمی بیان شوند و ابزارهایی برای اثبات آن فرمول ها فراهم می کند. کاربرد اصلی، رسمیسازی اثباتهای ریاضی و بهویژه تأیید رسمی است که شامل اثبات صحت سختافزار یا نرمافزار رایانه و اثبات ویژگیهای زبانها و پروتکلهای رایانه میشود._
-
-- [گیتهاب](https://github.com/isabelle-prover)
-- [مستندات](https://isabelle.in.tum.de/documentation.html)
-
-**Coq** - _Coq یک اثبات کننده قضیه تعاملی است که به شما امکان می دهد برنامه ها را با استفاده از قضایا تعریف کنید و به طور تعاملی اثبات صحت بررسی شده توسط ماشین را ایجاد کنید._
-
-- [گیتهاب](https://github.com/coq/coq)
-- [اسناد](https://coq.github.io/doc/v8.13/refman/index.html)
-
-
-
-### ابزارهای مبتنی بر اجرای نمادین برای تشخیص الگوهای آسیب پذیر در قراردادهای هوشمند {#symbolic-execution-tools}
-
-**Manticore** - _*ابزاری برای تجزیه و تحلیل ابزار تجزیه و تحلیل بایت کد EVM بر اساس اجرای نمادین*.*
-
-- [گیتهاب](https://github.com/trailofbits/manticore)
-- [مستندات](https://github.com/trailofbits/manticore/wiki)
-
-**hevm** - _*hevm یک موتور اجرای نمادین و جستجوگر معادل برای بایت کد EVM است.**
-
-- [گیت هاب](https://github.com/dapphub/dapptools/tree/master/src/hevm)
-
-**Mythil** - _ابزار اجرای نمادین برای شناسایی آسیبپذیریها در قراردادهای هوشمند اتریوم_
-
-- [گیتهاب](https://github.com/ConsenSys/mythril-classic)
-- [مستندات](https://mythril-classic.readthedocs.io/en/develop/)
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [چگونه تأیید رسمی قراردادهای هوشمند کار می کند؟](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/)
-- [چگونه تأیید رسمی می تواند قراردادهای هوشمند بی عیب و نقص را تضمین کند؟](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1)
-- [مروری بر پروژه های تایید رسمی در اکوسیستم اتریوم](https://github.com/leonardoalt/ethereum_formal_verification_overview)
-- [تایید رسمی اند تو اند قرارداد هوشمند سپرده گذاری اتریوم 2.0](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/)
-- [تایید رسمی محبوب ترین قرارداد هوشمند جهان](https://www.zellic.io/blog/formal-verification-weth)
-- [SMTCchecker و تأیید رسمی](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
deleted file mode 100644
index beb008abc76..00000000000
--- "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md"
+++ /dev/null
@@ -1,372 +0,0 @@
----
-title: آزمایش قرارداد هوشمند
-description: نمای کلی تکنیک ها و ملاحظات تست کردن قراردادهای هوشمند سالیدیتی.
-lang: fa
----
-
-بلاک چین های عمومی مانند اتریوم تغییر ناپذیر هستند و تغییر کد قراردادهای هوشمند پس از استقرار را دشوار می کند. الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر این، یک ارتقا فقط میتواند یک خطا را پس از کشف آن برطرف کند - اگر مهاجم ابتدا آسیبپذیری را کشف کند، قرارداد هوشمند شما در معرض خطر سوء استفاده قرار میگیرد.
-الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر آن، بروزرسانی، فقط میتواند خطا را_پس از _ کشف شدن آن تصحیح کند - اگر یک مهاجم، زودتر از تصحیح آن خطا، خطا را پیدا کند، قرارداد هوشمند مربوطه در معرض سوء استفاده واقع میشود.
-
-به همین علت است که تست کردن قراردادهای هوشمند پیش از [دیپلوی](/developers/docs/smart-contracts/deploying/) بر روی شبکه اصلی، به عنوان حداقل میزان رعایت [ایمنی](/developers/docs/smart-contracts/security/) تلقی می شود. برای تست و ارزیابی میزان صحت کدهای قراردادهای هوشمند، تکنیک های مختلفی وجود دارد؛ این که انتخاب شما کدام تکنیک و به چه صورت باشد به نیازمندی و خواست خود شما بر میگردد. ضمناً، مجموعه های تستی که متشکل از ابزارها و نگرش های مختلف باشند به عنوان گزینه ای ایدهآل برای کشف و عیب یابی نواقص امنیتی کم اهمیت و پر اهمیت در کد کانترکت می باشند.
-
-
-
-## پیشنیازها {#prerequisites}
-
-در این صفحه به بررسی چگونگه تست قراردادهای هوشمند پیش از دیپلوی روی شبکه اتریوم می پردازیم. فرض بر این است که با [قراردادهای هوشمند](/developers/docs/smart-contracts/) آشنا هستید.
-
-
-
-## تست کردن قرارداد هوشمند چیست؟ {#what-is-smart-contract-testing}
-
-تست کردن قرارداد هوشمند پروسه ای است که با استفاده از آن می توانیم از صحت عملکرد کد قرارداد هوشمند به نسبت نحوه عملکرد آن کد اطمینان حاصل کنیم. در زمانی که بخواهیم از قابل اطمینان بودن، قابل استفاده بودن، و ایمنی قرارداد هوشمند مطمئن شویم، تست کردن بسیار کاربردی و مفید است.
-
-اگرچه که رویکردهای مختلفی وجود دارند، بیشتر روش های تست کردن مبنی بر اجرای یک قراردادهای هوشمند با نمونه کوچکی از داده هایی که انتظار اجرا شدن کدها با آن را داریم، میباشد. اگر کانترکت در ازای این داده های نمونه، جواب صحیح برگرداند، به معنای صحت عملکرد کد مربوطه است. بیشتر ابزارهای تست کردن، به منظور چک کردن تطابق نتایج حاصله با نتایج عملیاتی کانترکت، منابعی را به منظور نوشتن و اجرا کردن [موارد تست](https://en.m.wikipedia.org/wiki/Test_case) فراهم می کنند.
-
-
-
-### علت اهمیت تست قراردادهای هوشمند چیست؟ {#importance-of-testing-smart-contracts}
-
-قراردادهای هوشمند به طور معمول حجم زیادی از دارایی های مالی را مدیریت میکنند، کوچکترین اشتباه برنامه نویسی می تواند باعث [خسارت هنگفت به کاربران](https://rekt.news/leaderboard/) شود. تست دقیق، می تواند در یافتن عیب ها و مشکلات کد یک قرارداد هوشمند در مراحل اولیه، و تصحیح آنها پیش از عرضه کانترکت مربوطه، به شما کمک کند.
-
-اگرچه در صورتی که یک خطا یا باگ در قرارداد هوشمند کشف شود، امکان آپدیت و ارتقای آن وجود دارد، اما آپدیت کردن آن می تواند امری پیچیده بوده و در صورتی که به خطای مربوطه به درستی رسیدگی نشود، خود باعث [خطاهای دیگر](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) شود. علاوه بر آن، بروزرسانی یک کانترکت ناقض اصل تغییرناپذیری بوده و مفروضات اعتمادی اضافه ای را بر کاربران تحمیل می کند. برعکس، یک برنامه جامع برای آزمایش و تست قرارداد شما خطرات امنیتی قرارداد هوشمند را کاهش میدهد و نیاز به انجام ارتقاء منطقی پیچیده پس از استقرار یا دپلوی را کاهش میدهد.
-
-
-
-## روشهای تست قراردادهای هوشمند {#methods-for-testing-smart-contracts}
-
-روشهای تست قراردادهای هوشمند اتریوم در دو دسته کلی قرار میگیرند: **تست خودکار** و **تست دستی**. تست خودکار و تست دستی مزایا و بخشهای منحصر به فردی را ارائه میدهند، اما میتوانید هر دو را برای ایجاد یک برنامه قوی برای تجزیه و تحلیل قراردادهای خود ترکیب کنید.
-
-
-
-### تست خودکار {#automated-testing}
-
-تست خودکار از ابزارهایی استفاده میکند که به طور خودکار کد قراردادهای هوشمند را برای خطا در اجرا بررسی میکند. مزیت تست خودکار برای استفاده از [اسکریپتها](https://www.techtarget.com/whatis/definition/script?amp=1) برای راهنمایی ارزیابی عملکردهای قرارداد ناشی میشود. تست اسکریپتشده را میتوان برای اجرای مکرر با حداقل مداخله انسانی برنامهریزی کرد و تست خودکار را کارآمدتر از روشهای دستی برای تست کردن میکند.
-
-تست خودکار به ویژه زمانی مفید است که تستها تکراری و وقت گیر باشند. انجام تست دستی دشوار است؛ مستعد خطای انسانی؛ یا شامل ارزیابی عملکردهای مهم قرارداد میشود. اما ابزارهای تست خودکار میتوانند اشکالاتی داشته باشند—ممکن است برخی از اشکالات را از دست بدهند و [فضای مثبت کاذب](https://www.contrastsecurity.com/glossary/false-positive) زیادی ایجاد کنند. از این رو، جفت کردن تست خودکار با تست دستی برای قراردادهای هوشمند ایدهآل است.
-
-
-
-### تست دستی {#manual-testing}
-
-تست دستی به کمک انسان است و شامل اجرای هر یک از موارد تستی در مجموعه آزمایشی شما هنگام تجزیه و تحلیل صحت قراردادهای هوشمند است. این مورد برخلاف تست خودکار است که در آن میتوانید به طور همزمان چندین تست مجزا را روی یک قرارداد اجرا کرده و گزارشی دریافت کنید که تمام تستهای شکست خورده و قبولی را نشان میدهد.
-
-تست دستی میتواند توسط یک فرد به دنبال یک برنامه آزمون کتبی که سناریوهای مختلف آزمون را پوشش میدهد، انجام شود. همچنین میتوانید چندین فرد یا گروه را به عنوان بخشی از تست دستی و تعامل با یک قرارداد هوشمند در یک دوره مشخص بخواهید. تستکنندگان رفتار واقعی قرارداد را با رفتار مورد انتظار مقایسه کرده و هر تفاوتی را بهعنوان یک اشکال یا باگ علامتگذاری میکنند.
-
-تست دستی مؤثر به منابع قابلتوجهی (مهارت، زمان، پول و تلاش) نیاز دارد و ممکن است - به دلیل خطای انسانی - خطاهای خاصی را در حین اجرای تستها از دست داد. اما تست دستی نیز میتواند سودمند باشد - برای مثال، یک تستکننده انسانی (مثلاً یک حسابرس یا آدیتور) ممکن است از شهود برای تشخیص موارد که ابزار تست خودکار از دست میدهد استفاده کند.
-
-
-
-## تست خودکار برای قراردادهای هوشمند {#automated-testing-for-smart-contracts}
-
-
-
-### تست واحد {#unit-testing-for-smart-contracts}
-
-تست واحد عملکردهای قرارداد را به طور جداگانه ارزیابی و بررسی کرده که هر جزء به درستی کار میکند. تستهای واحد مطلوب باید ساده، سریع اجرا شوند و ایده روشنی از اینکه در صورت شکست تستها چه اشتباهی رخ داده است، ارائه دهند.
-
-تستهای واحد برای بررسی اینکه آیا توابع مقادیر مورد انتظار را برمیگردانند و اینکه ذخیرهسازی قرارداد بهدرستی پس از اجرای تابع بهروز شده است مفید هستند. علاوه بر این، اجرای تستهای واحد پس از ایجاد تغییرات در پایگاه کد قراردادها، تضمین میکند که افزودن منطق جدید باعث ایجاد خطا نمیشود. در زیر چند دستورالعمل برای اجرای تستهای واحد مؤثر آورده شده است:
-
-
-
-#### راهنماهایی برای تست واحد قراردادهای هوشمند {#unit-testing-guidelines}
-
-
-
-##### 1. منطق تجاری و گردش کار قراردادهای خود را درک کنید
-
-قبل از نوشتن تستهای واحد، دانستن اینکه یک قرارداد هوشمند چه ویژگیهایی را ارائه میدهد و کاربران چگونه به آن عملکردها دسترسی خواهند داشت و از آنها استفاده میکنند، کمک میکند. این مورد به ویژه برای اجرای [تستهای مسیر درست](https://en.m.wikipedia.org/wiki/Happy_path) مفید است که تعیین میکند آیا توابع در قرارداد، خروجی صحیح را برای ورودیهای معتبر کاربر برمیگردانند یا خیر. ما این مفهوم را با استفاده از این مثال (مختلف) از [یک قرارداد مزایده](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple- توضیح خواهیم داد. open-auction)
-
-
-
-```
-constructor(
- uint biddingTime,
- address payable beneficiaryAddress
- ) {
- beneficiary = beneficiaryAddress;
- auctionEndTime = block.timestamp + biddingTime;
- }
-
-function bid() external payable {
-
- if (block.timestamp > auctionEndTime)
- revert AuctionAlreadyEnded();
-
- if (msg.value <= highestBid)
- revert BidNotHighEnough(highestBid);
-
- if (highestBid != 0) {
- pendingReturns[highestBidder] += highestBid;
- }
- highestBidder = msg.sender;
- highestBid = msg.value;
- emit HighestBidIncreased(msg.sender, msg.value);
- }
-
- function withdraw() external returns (bool) {
- uint amount = pendingReturns[msg.sender];
- if (amount > 0) {
- pendingReturns[msg.sender] = 0;
-
- if (!payable(msg.sender).send(amount)) {
- pendingReturns[msg.sender] = amount;
- return false;
- }
- }
- return true;
- }
-
-function auctionEnd() external {
- if (block.timestamp < auctionEndTime)
- revert AuctionNotYetEnded();
- if (ended)
- revert AuctionEndAlreadyCalled();
-
- ended = true;
- emit AuctionEnded(highestBidder, highestBid);
-
- beneficiary.transfer(highestBid);
- }
-}
-```
-
-
-این یک قرارداد مزایده ساده است که برای دریافت پیشنهادها در طول دوره مناقصه طراحی شده است. اگر این مورد `highestBid` افزایش یابد، بالاترین پیشنهاد قبلی پول خود را دریافت میکند. پس از پایان دوره مناقصه، `ذینفع` قرارداد را فراخوانی میکند تا پول خود را دریافت کند.
-
-تستهای واحد برای قراردادی مانند این، عملکردهای مختلفی را که کاربر ممکن است هنگام تعامل با قرارداد فراخوانی کند، پوشش میدهد. یک مثال برای تست واحد این است که بررسی میکند آیا کاربر میتواند در حین انجام مزایده پیشنهادی ارائه دهد (یعنی تماسهای `قیمتگذاری()` موفقیتآمیز است) یا آزمایشی که بررسی میکند آیا کاربر میتواند پیشنهاد بالاتری از پیشنهاد فعلی ارائه دهد یا خیر. `highestBid`.
-
-همچنین درک گردش کار عملیاتی قراردادها به نوشتن تستهای واحد کمک میکند تا بررسی کند که آیا اجرا با الزامات مطابقت دارد یا خیر. برای مثال، قرارداد مزایده مشخص میکند که کاربران نمیتوانند پس از پایان حراج، پیشنهاد بدهند (یعنی زمانی که `زمان مزایده یا حراج تمام شود` کمتر از `block.timestamp` است). بنابراین، یک توسعهدهنده ممکن است تست واحدی را اجرا کند که بررسی میکند آیا فراخوانیهای تابع `bid()` موفق میشوند یا شکست میخورند پس از پایان حراج (یعنی وقتی `auctionEndTime` > `block.timestamp`).
-
-
-
-##### 2. کلیه مفروضات مربوط به اجرای قرارداد را ارزیابی کنید
-
-ثبت هرگونه فرضی در مورد اجرای قرارداد و نوشتن تستهای واحد برای تأیید صحت آن مفروضات مهم است. جدا از ارائه محافظت در برابر اجرای غیرمنتظره، اظهارات تست شما را مجبور میکند به عملیاتی فکر کنید که میتواند مدل امنیتی قراردادهای هوشمند را شکست دهد. یک نکته مفید این است که فراتر از "تستهای کاربر" بروید و تستهای منفی بنویسید که بررسی میکند آیا یک تابع برای ورودیهای اشتباه ناموفق است یا خیر.
-
-بسیاری از فریم ورکهای تست واحد به شما اجازه میدهند تا اظهارات را ایجاد کنید - عبارتهای سادهای که بیان میکند قرارداد چه کاری میتواند انجام دهد و چه کاری نمیتواند انجام دهد - و تستهایی را برای مشاهده اینکه آیا این ادعاها در حال اجرا هستند یا خیر، اجرا کنید. توسعهدهندهای که روی قرارداد حراج که قبلاً توضیح داده شد کار میکند، میتواند پیش از اجرای تستهای منفی، در مورد رفتار خود اظهارات زیر را بیان کند:
-
-- وقتی مزایده تمام شده یا شروع نشده است، کاربران نمیتوانند پیشنهاد دهند.
-
-- اگر پیشنهادی کمتر از آستانه قابل قبول باشد، قرارداد مزایده لغو میشود.
-
-- کاربرانی که موفق به برنده شدن در مناقصه نشوند با وجوه خود اعتبار داده میشوند
-
-**نکته**: روش دیگری برای تست مفروضات، نوشتن تستهایی است که [مادیفایر یا اصلاحکننده تابع](https://docs.soliditylang.org/en/v0.8.16/contracts را راهاندازی میکنند. html#function-modifiers) در یک قرارداد، به خصوص عبارتهای `require`، `assert` و `if…else`.
-
-
-
-##### 3. پوشش کد را اندازهگیری کنید (code coverage)
-
-[پوشش کد](https://en.m.wikipedia.org/wiki/Code_coverage) یک معیار آزمایشی است که تعداد شاخهها، خطوط و عبارات کد شما را که در طول تستها اجرا میشوند، ردیابی میکند. تستها باید پوشش کد خوبی داشته باشند، در غیر این صورت ممکن است "منفی کاذب" دریافت کنید و زمانی اتفاق میافتد که یک قرارداد همه تستها را با موفقیت پشت سر میگذارد، اما آسیب پذیریها همچنان در کد وجود دارد. با این حال، ثبت پوشش بالای کد این اطمینان را به شما میدهد که تمام عبارات/عملکردهای یک قرارداد هوشمند به اندازه کافی برای صحت تست شدهاند.
-
-
-
-##### 4. از فریم ورکهای آزمایشی توسعه یافته استفاده کنید
-
-کیفیت ابزارهای مورد استفاده در اجرای تستهای واحد برای قراردادهای هوشمند شما بسیار مهم است. یک فریم ورک تست ایده آل، فریم ورکی است که به طور منظم نگهداری شود. ویژگیهای مفیدی را ارائه میدهد (به عنوان مثال، قابلیتهای ثبت و گزارش). و باید به طور گسترده توسط توسعه دهندگان دیگر مورد استفاده و بررسی قرار گرفته باشد.
-
-فریم ورکهای تست واحد برای قراردادهای هوشمند سالیدیتی به زبانهای مختلف (عمدتاً جاوا اسکریپت، پایتون و Rust) ارائه میشوند. برخی از راهنماهای زیر را برای اطلاع از نحوه شروع اجرای تستهای واحد با فریم ورکهای تست مختلف مشاهده کنید:
-
-- **[اجرای تست واحد با Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
-- **[اجرای تست واحد با فوندری](https://book.getfoundry.sh/forge/writing-tests)**
-- **[اجرای تست واحد با وافل](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
-- **[اجرای تست واحد با ریمیکس](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
-- **[اجرای تست واحد با ایپ](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
-- **[اجرای تستهای واحد با هاردهات](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
-- **[اجرای تستهای واحد با Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
-
-
-
-### تست یکپارچهسازی {#integration-testing-for-smart-contracts}
-
-در حالی که تست واحد عملکردهای قرارداد را به صورت مجزا اشکال زدایی میکند، تستهای یکپارچهسازی اجزای یک قرارداد هوشمند را به عنوان یک کل ارزیابی میکنند. تست یکپارچه سازی میتواند مشکلات ناشی از فراخوانیهای قراردادی متقابل یا تعامل بین عملکردهای مختلف در یک قرارداد هوشمند را شناسایی کند. به عنوان مثال، تستهای یکپارچهسازی میتوانند به بررسی اینکه آیا مواردی مانند [ارثبری](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) و وابستگی به درستی کار میکنند یا خیر کمک میکند.
-
-تست یکپارچهسازی در صورتی مفید است که قرارداد شما در طول اجرا از معماری مدولار استفاده کند یا با سایر قراردادهای زنجیرهای ارتباط برقرار کند. یکی از راههای اجرای تستهای یکپارچهسازی این است که [بلاک چین](/glossary/#fork) را در یک ارتفاع خاص (با استفاده از ابزاری مانند [Forge](https://book.getfoundry.sh فورک کنید. /forge/fork-testing) یا [هاردهت](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) و تعاملات بین قرارداد شما و قراردادهای مستقر را شبیهسازی کنید.
-
-بلاک چین فورک شده مشابه شبکه اصلی رفتار خواهد کرد و دارای حسابهایی با وضعیتها و موجودیهای مرتبط است. اما فقط به عنوان یک محیط توسعه محلی سندباکس شده عمل میکند، به این معنی که برای تراکنشها به ETH واقعی نیاز نخواهید داشت، همچنین تغییرات شما بر پروتکل واقعی اتریوم تأثیر نمیگذارد.
-
-
-
-### تست مبتنی بر مشخصات {#property-based-testing-for-smart-contracts}
-
-تست مبتنی بر دارایی فرآیند بررسی این است که آیا قرارداد هوشمند برخی از ویژگیهای تعریف شده را برآورده میکند یا خیر. ویژگیها حقایقی را در مورد رفتار قرارداد بیان میکنند که انتظار میرود در سناریوهای مختلف درست باقی بماند - نمونهای از ویژگی قرارداد هوشمند میتواند "عملیات حسابی در قرارداد هرگز اورفلو یا آندرفلو" نباشد
-
-**تحلیل استاتیک** و **تحلیل دینامیکی** دو تکنیک رایج برای اجرای تست مبتنی بر ویژگی هستند و هر دو میتوانند تأیید کنند که کد یک برنامه (یک قرارداد هوشمند در این مورد) برخی از ویژگیهای از پیش تعریف شده را برآورده میکند. برخی از ابزارهای تست مبتنی بر دارایی با قوانین از پیش تعریف شده در مورد ویژگیهای قرارداد مورد انتظار ارائه میشوند و کد را در برابر آن قوانین بررسی میکنند، در حالی که برخی دیگر به شما امکان میدهند ویژگیهای سفارشی را برای یک قرارداد هوشمند ایجاد کنید.
-
-
-
-#### تجزیه و تحلیل استاتیک {#static-analysis}
-
-یک آنالایزر استاتیک کد منبع یک قرارداد هوشمند را به عنوان ورودی دریافت کرده و نتایج را با اعلام اینکه آیا قرارداد یک ویژگی را برآورده میکند یا نه، خروجی میگیرد. بر خلاف تحلیل پویا، تحلیل استاتیک شامل اجرای قرارداد برای تجزیه و تحلیل آن برای صحت نیست. تجزیه و تحلیل استاتیک در عوض درباره تمام مسیرهای احتمالی که یک قرارداد هوشمند میتواند در طول اجرا طی کند (به عنوان مثال، با بررسی ساختار کد منبع برای تعیین معنای آن برای عملیات قراردادها در زمان اجرا) استدلال میکند.
-
-[Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) و [تست استاتیک](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) روشهای رایج برای اجرای تحلیل استاتیک در قراردادها هستند. هر دو نیازمند تجزیه و تحلیل نمایشهای سطح پایین اجرای قرارداد هستند، مانند [درخت نحو انتزاعی](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) و [کنترل نمودارهای جریان](https: //www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) خروجی توسط کامپایلر.
-
-در بیشتر موارد، تجزیه و تحلیل استاتیک برای تشخیص مسائل ایمنی مانند استفاده از ساختارهای ناامن، خطاهای نحوی یا نقض استانداردهای کدگذاری در کد قرارداد مفید است. با این حال، آنالایزرهای استاتیک به طور کلی در تشخیص آسیبپذیریهای عمیقتر نامطلوب هستند و ممکن است مثبت کاذب بیش از حد تولید کنند.
-
-
-
-#### تحلیل دینامیک {#dynamic-analysis}
-
-تحلیل پویا ورودیهای نمادین (مثلاً در [اجرای نمادین](https://en.m.wikipedia.org/wiki/Symbolic_execution)) یا ورودیهای مشخص (مثلاً در [fuzzing](https://owasp.org/www-community/Fuzzing)) به یک قرارداد هوشمند عمل میکند تا ببیند آیا هر رد یا تریس(های) اجرایی خاصیت خاصی را نقض میکند یا خیر. این شکل از تست مبتنی بر ویژگی با تستهای واحد متفاوت است، زیرا موارد تست سناریوهای متعددی را پوشش میدهند و یک برنامه تولید موارد تست را انجام میدهد.
-
-[Fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) نمونهای از تکنیک تحلیل پویا برای تأیید ویژگیهای دلخواه در قراردادهای هوشمند است. یک فازر توابع را در یک قرارداد هدف با تغییرات تصادفی یا به شکل نادرست یک مقدار ورودی تعریف شده فراخوانی میکند. اگر قرارداد هوشمند وارد یک حالت خطا شود (به عنوان مثال، وضعیتی که یک ادعا با شکست مواجه شود)، مشکل علامتگذاری میشود و ورودیهایی که اجرا را به سمت مسیر آسیبپذیر هدایت میکند در یک گزارش تولید میشود.
-
-فازینگ برای ارزیابی مکانیزم اعتبارسنجی ورودی قراردادهای هوشمند مفید است زیرا مدیریت نادرست ورودیهای غیرمنتظره ممکن است منجر به اجرای ناخواسته و ایجاد اثرات خطرناک شود. این شکل از تست مبتنی بر ویژگی میتواند به دلایل زیادی ایدهآل باشد:
-
-1. **نوشتن موارد تست برای پوشش دادن بسیاری از سناریوها دشوار است.** تست ویژگی فقط مستلزم آن است که یک رفتار و طیف وسیعی از دادهها را برای تست رفتار تعریف کنید—برنامه به طور خودکار تست را تولید میکند و موارد بر اساس ویژگی تعریف شده است.
-
-2. **مجموعه تست شما ممکن است به اندازه کافی تمام مسیرهای ممکن در برنامه را پوشش ندهد.** حتی با پوشش ۱۰۰٪، ممکن است موارد حیاتی را از دست بدهید.
-
-3. **تستهای واحد ثابت میکنند که یک قرارداد برای دادههای نمونه به درستی اجرا میشود، اما اینکه آیا قرارداد برای ورودیهای خارج از نمونه به درستی اجرا میشود یا خیر، ناشناخته باقی میماند.** تستهای ویژگی، یک قرارداد هدف را با تغییرات چندگانه یک قرارداد اجرا میکنند. مقدار ورودی داده شده برای یافتن آثار اجرایی که باعث شکست ادعا میشوند. بنابراین، یک تست ویژگی تضمینهای بیشتری برای اجرای صحیح قرارداد برای یک کلاس وسیع از دادههای ورودی ارائه میدهد.
-
-
-
-### دستورالعملهایی برای اجرای تست مبتنی بر اموال برای قراردادهای هوشمند {#running-property-based-tests}
-
-اجرای تست مبتنی بر ویژگی معمولاً با تعریف یک ویژگی (به عنوان مثال، عدم وجود [اورفلو عدد صحیح](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) یا مجموعهای از ویژگیهایی که میخواهید در یک قرارداد هوشمند تأیید کنید، میباشد. همچنین ممکن است لازم باشد محدودهای از مقادیر را تعریف کنید که در آن برنامه میتواند دادههایی را برای ورودیهای تراکنش هنگام نوشتن تستهای ویژگی تولید کند.
-
-هنگامی که به درستی پیکربندی شد، ابزار تست، توابع قراردادهای هوشمند شما را با ورودیهای تولید شده بهطور تصادفی اجرا میکند. در صورت وجود هرگونه تخلف ادعایی، باید گزارشی با دادههای ورودی مشخص دریافت کنید که دارایی تحت ارزیابی را نقض میکند. برای شروع تست مبتنی بر ویژگی با ابزارهای مختلف، برخی از راهنماهای زیر را ببینید:
-
-- **[تجزیه و تحلیل استاتیک قراردادهای هوشمند با اسلیتر (Slither)](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)**
-- **[تجزیه و تحلیل استاتیک قراردادهای هوشمند با Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
-- **[تست مبتنی بر ویژگی با Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
-- **[قراردادهای فازی با فاندری (Foundry)](https://book.getfoundry.sh/forge/fuzz-testing)**
-- **[قراردادهای فازی با Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
-- **[قراردادهای فازی با ویک](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
-- **[اجرای نمادین قراردادهای هوشمند با مانتیکر (Manticore)](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
-- **[اجرای نمادین قراردادهای هوشمند با Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
-
-
-
-## تست دستی برای قراردادهای هوشمند {#manual-testing-for-smart-contracts}
-
-تست دستی قراردادهای هوشمند اغلب بعد از اجرای تستهای خودکار در چرخه توسعه انجام میشود. این شکل از تست قرارداد هوشمند را به عنوان یک محصول کاملاً یکپارچه ارزیابی میکند تا ببیند آیا مطابق با الزامات فنی مشخص شده است یا خیر.
-
-
-
-### تست قراردادها بر روی یک بلاک چین لوکال {#testing-on-local-blockchain}
-
-در حالی که تست خودکار انجام شده در یک محیط توسعه محلی یا لوکال میتواند اطلاعات مفیدی برای اشکال زدایی یا دیباگ کردن ارائه دهد، شما باید بدانید که قرارداد هوشمند شما در یک محیط تولید چگونه رفتار میکند. با این حال، استقرار یا دپلوی در زنجیره اصلی اتریوم مستلزم هزینههای گس است – ناگفته نماند که اگر قرارداد هوشمند شما همچنان دارای اشکال یا باگ باشد، شما یا کاربرانتان میتوانید پول واقعی خود را از دست بدهید.
-
-تست قرارداد خود بر روی یک بلاک چین محلی (همچنین به عنوان [شبکه توسعه](/developers/docs/development-networks/) نیز شناخته می شود) جایگزین توصیه شده برای آزمایش در شبکه اصلی است. یک بلاک چین محلی یک کپی از بلاک چین اتریوم است که به صورت محلی روی رایانه شما اجرا میشود و رفتار لایه اجرایی اتریوم را شبیهسازی میکند. به این ترتیب، میتوانید تراکنشها را طوری برنامهریزی کنید که با یک قرارداد تعامل داشته باشند، بدون اینکه هزینههای بیشتر قابلتوجهی را متحمل شوند.
-
-اجرای قراردادها بر روی یک بلاک چین محلی میتواند به عنوان نوعی تست ادغام دستی مفید باشد. [قراردادهای هوشمند بسیار قابل ترکیب هستند](/developers/docs/smart-contracts/composability/)، به شما امکان میدهد با پروتکلهای موجود ادغام کنید—اما همچنان باید اطمینان حاصل کنید که چنین بخش پیچیدهای در زنجیره فعل و انفعالات نتایج صحیح را ایجاد میکند.
-
-[اطلاعات بیشتر در مورد شبکههای توسعه.](/developers/docs/development-networks/)
-
-
-
-### تست قراردادها بر روی تست نتها یا شبکه آزمایشی {#testing-contracts-on-testnets}
-
-یک شبکه آزمایشی دقیقاً مانند شبکه اصلی اتریوم کار میکند، با این تفاوت که از اتر (ETH) بدون ارزش واقعی استفاده میکند. استقرار قرارداد خود در یک [شبکه آزمایشی](/developers/docs/networks/#ethereum-testnets) به این معنی است که هر کسی میتواند با آن تعامل داشته باشد (مثلاً از طریق فرانتاند برنامه غیرمتمرکز) بدون اینکه سرمایهای را در معرض خطر قرار دهد.
-
-این شکل از تست دستی برای ارزیابی جریان انتها به انتها برنامه شما از دیدگاه کاربر مفید است. در اینجا، آزمایشکنندههای بتا میتوانند اجرای آزمایشی را نیز انجام دهند و هرگونه مشکل در منطق تجاری و عملکرد کلی قرارداد را گزارش کنند.
-
-استقرار یا دپلوی در یک شبکه آزمایشی پس از تست بر روی یک بلاک چین محلی ایدهآل است زیرا مورد اول به رفتار ماشین مجازی اتریوم نزدیکتر است. بنابراین، برای بسیاری از پروژههای بومی اتریوم، استفاده از برنامههای غیرمتمرکز در شبکههای آزمایشی برای ارزیابی عملیات قراردادهای هوشمند در شرایط دنیای واقعی رایج است.
-
-[اطلاعات بیشتر در مورد شبکههای آزمایشی اتریوم.](/developers/docs/development-networks/#public-beacon-testchains)
-
-
-
-## تست در مقابل تأیید رسمی {#testing-vs-formal-verification}
-
-در حالی که تست کمک میکند تا تأیید شود که یک قرارداد نتایج مورد انتظار را برای برخی از ورودیهای داده برمیگرداند یا خیر، ولی نمیتواند به طور قطعی همان را برای ورودیهایی که در طول تست استفاده نشدهاند ثابت کند. بنابراین، تست یک قرارداد هوشمند نمیتواند «صحت عملکردی» را تضمین کند (یعنی نمیتواند نشان دهد که یک برنامه برای _همه_ مجموعههای مقادیر ورودی، آنطور که لازم است رفتار میکند).
-
-تأیید رسمی رویکردی برای ارزیابی صحت نرمافزار با بررسی اینکه آیا مدل رسمی برنامه با مشخصات رسمی مطابقت دارد یا خیر. یک مدل رسمی یک نمایش ریاضی انتزاعی از یک برنامه است، در حالی که یک مشخصات رسمی ویژگیهای یک برنامه را تعریف میکند (یعنی ادعاهای منطقی در مورد اجرای برنامه).
-
-از آنجایی که ویژگیها به صورت ریاضی نوشته شدهاند، میتوان تأیید کرد که یک مدل رسمی (ریاضی) سیستم با استفاده از قوانین منطقی استنتاج، مشخصاتی را برآورده میکند یا خیر. بنابراین، گفته میشود که ابزارهای تأیید رسمی «اثبات ریاضی» درستی یک سیستم را ارائه میدهند.
-
-برخلاف تست، تأیید رسمی میتواند برای تأیید اینکه اجرای قراردادهای هوشمند دارای مشخصات رسمی برای _همه_ اجراها است (یعنی بدون باگ) بدون نیاز به اجرای آن با نمونه دادهها استفاده شود. این مورد نه تنها زمان صرف شده برای اجرای دهها تست واحد را کاهش میدهد، بلکه در شناسایی آسیبپذیریهای پنهان نیز موثرتر است. گفتنی است، تکنیکهای تأیید رسمی بسته به دشواری اجرا و مفید بودنشان در طیفی قرار دارند.
-
-[بیشتر در مورد تأیید رسمی برای قراردادهای هوشمند.](/developers/docs/smart-contracts/formal-verification)
-
-
-
-## تست در مقابل ممیزی یا آدیت و پاداش باگ {#testing-vs-audits-bug-bounties}
-
-همانطور که ذکر شد، تست دقیق به ندرت میتواند عدم وجود اشکال یا باگ در قرارداد را تضمین کند. رویکردهای تأیید رسمی میتوانند تضمینهای قویتری از صحت ارائه دهند، اما در حال حاضر استفاده از آنها دشوار است و هزینههای قابل توجهی را متحمل میشود.
-
-با این وجود، میتوانید با بررسی کد مستقل، امکان شناسایی آسیبپذیریهای قرارداد را بیشتر کنید. [ممیزی یا آدیت قراردادهای هوشمند](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) و [پاداشهای باگ](https://medium. com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) دو راه برای ترغیب دیگران به تجزیه و تحلیل قراردادهای شما هستند.
-
-ممیزیها توسط حسابرسان با تجربه در یافتن موارد نقص امنیتی و شیوههای توسعه ضعیف در قراردادهای هوشمند انجام میشود. ممیزی معمولاً شامل تست (و احتمالاً تأیید رسمی) و همچنین بررسی دستی کل پایگاه کد است.
-
-برعکس، برنامه پاداش باگ معمولاً شامل ارائه پاداش مالی به یک فرد است (که معمولاً به عنوان [هکرهای کلاه سفید](https://en.wikipedia.org/wiki/White_hat_(computer_security)) توصیف میشود) یک آسیبپذیری را در یک قرارداد هوشمند کشف کرده و آن را برای توسعهدهندگان فاش میکند. پاداش باگ مشابه ممیزی یا آدیت است زیرا شامل درخواست از دیگران برای کمک به یافتن نقص در قراردادهای هوشمند است.
-
-تفاوت عمده این است که برنامههای پاداش باگ برای جامعه توسعهدهندگان/هکرهای گستردهتر باز است و طبقه وسیعی از هکرهای اخلاقی و متخصصان امنیتی مستقل را با مهارتها و تجربههای منحصربهفرد جذب میکنند. این مورد ممکن است یک مزیت نسبت به ممیزی یا آدیت قراردادهای هوشمند باشد که عمدتاً به تیمهایی متکی است که ممکن است تخصص محدودی داشته باشند.
-
-
-
-## کتابخانهها و ابزارهای آزمایش {#testing-tools-and-libraries}
-
-
-
-### ابزار تست واحد {#unit-testing-tools}
-
-- **[کاورج یا پوشش سالیدیتی](https://github.com/sc-forks/solidity-coverage)** - _ابزار پوشش کد برای قراردادهای هوشمند نوشته شده در سالیدیتی است._
-
-- **[وافل](https://ethereum-waffle.readthedocs.io/en/latest/)** - *چارچوبی برای توسعه و تست قراردادهای هوشمند پیشرفته (بر اساس ethers.js) است*.
-
-- **[تستهای ریمیکس](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _ابزاری برای آزمایش قراردادهای هوشمند سالیدیتی است. در زیر پلاگین ریمیکس "Solidity Unit Testing" کار میکند که برای نوشتن و اجرای موارد تست برای قرارداد استفاده میشود._
-
-- **[کمککننده تست اوپن زپلین](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _کتابخانه ازرشن برای تست قرارداد هوشمند اتریوم. مطمئن شوید که قراردادهای شما مطابق انتظار عمل می کند!_
-
-- **[فریم ورک تست واحد براونی](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _براونی از Pytest استفاده میکند، یک فریم ورک تستی غنی از ویژگیها که به شما امکان میدهد تستهای کوچک را با حداقل کد بنویسید و برای پروژههای بزرگ مقیاسپذیری خوبی دارد و بسیار قابل توسعه است._
-
-- **[تستهای فاندری ](https://github.com/foundry-rs/foundry/tree/master/forge)** - _Foundry Forge را ارائه میکند، یک فریم ورک آزمایشی سریع و انعطافپذیر اتریوم که قادر به اجرای آزمایشهای واحد ساده، بررسیهای بهینهسازی گس و فازبندی قرارداد است._
-
-- **[تستهای هاردهت](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _چارچوبی برای آزمایش قراردادهای هوشمند مبتنی بر ethers.js، موکا و چای است._
-
-- **[ایپ ورکس](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _چارچوب توسعه و آزمایش مبتنی بر پایتون برای قراردادهای هوشمند با هدف قرار دادن ماشین مجازی اتریوم است._
-
-- **[ویک](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _چارچوب مبتنی بر پایتون برای آزمایش واحد و فازی کردن با قابلیتهای اشکالزدایی قوی و پشتیبانی از آزمایش زنجیرهای متقابل، استفاده از pytest و Anvil برای بهترین تجربه و عملکرد کاربر است._
-
-
-
-### ابزارهای تست مبتنی بر ویژگی {#property-based-testing-tools}
-
-
-
-#### ابزارهای تحلیل استاتیکی {#static-analysis-tools}
-
-- **[Slither](https://github.com/crytic/slither)** - _Python- فریم ورک تجزیه و تحلیل استاتیک سالیدیتی برای یافتن آسیبپذیریها، بهبود درک کد و نوشتن تحلیلهای سفارشی برای قراردادهای هوشمند._
-
-- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _دریچهای برای اعمال بهترین شیوهها و شیوههای امنیتی برای زبان برنامه نویسی قرارداد هوشمند سالیدیتی است._
-
-- **[سایفرین آدرین](https://cyfrin.io/tools/aderyn)** - _تحلیلگر استاتیک مبتنی بر استاتیک که به طور خاص برای امنیت و توسعه قراردادهای هوشمند وب3 طراحی شده است._
-
-- **[ویک](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - < em x-id="4">چارچوب تحلیل استاتیک مبتنی بر پایتون با آشکارسازهای آسیبپذیری و کیفیت کد، چاپگرهایی برای استخراج اطلاعات مفید از کد و پشتیبانی برای نوشتن زیرماژولهای سفارشی.
-
-
-
-#### ابزارهای تحلیل پویا {#dynamic-analysis-tools}
-
-- **[اکیدنا](https://github.com/crytic/echidna/)** - _فازر سریع قرارداد برای شناسایی آسیبپذیریها در قراردادهای هوشمند از طریق تست مبتنی بر دارایی است._
-
-- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _ابزار فازینگ خودکار برای تشخیص تخلفات دارایی در کد قرارداد هوشمند مفید است._
-
-- **[مانتیکر](https://manticore.readthedocs.io/en/latest/index.html)** - _فریم ورک اجرای نمادین پویا برای تجزیه و تحلیل بایت کد ماشین مجازی اتریوم است._
-
-- **[میثریل (Mythril)](https://github.com/ConsenSys/mythril-classic)** - _ ابزار ارزیابی بایت کد ماشین مجازی اتریوم برای شناسایی آسیبپذیریهای قرارداد با استفاده از تجزیه و تحلیل تینت، تجزیه و تحلیل کونکولیک، و بررسی جریان کنترل است._
-
-- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _ Scribble یک زبان مشخصات و ابزار تأیید زمان اجرا است که به شما امکان میدهد قراردادهای هوشمند را با ویژگیهایی حاشیه نویسی کنید که به شما امکان میدهد به طور خودکار قراردادها را با ابزارهایی مانند Diligence Fuzzing یا MythX تست کنید._
-
-
-
-## آموزشهای مرتبط {#related-tutorials}
-
-- [نمای کلی و مقایسه محصولات تست مختلف](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
-- [نحوه استفاده از Echidna برای آزمایش قراردادهای هوشمند](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
-- [نحوه استفاده از Manticore برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
-- [نحوه استفاده از Slither برای یافتن اشکالات قرارداد هوشمند](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
-- [چگونه قراردادهای Solidity را برای آزمایش شبیه سازی کنیم](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
-- [نحوه اجرای تست های واحد در سالیدیتی با استفاده از Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [راهنمای عمیق برای تست قراردادهای هوشمند اتریوم](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
-- [نحوه تست قراردادهای هوشمند اتریوم](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
-- [راهنمای تست واحد مولوک دائو (MolochDAO) برای توسعه دهندگان](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
-- [نحوه تست قراردادهای هوشمند مانند یک حرفهای](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
deleted file mode 100644
index 0e913098cac..00000000000
--- "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md"
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: ارتقای قراردادهای هوشمند
-description: نگاهی کلی به الگوهای ارتقا برای قراردادهای هوشمند اتریوم
-lang: fa
----
-
-قراردادهای هوشمند در اتریوم برنامههای خودکاری هستند که در ماشین مجازی اتریوم (EVM) اجرا میشوند. این برنامه ها از نظر طراحی تغییر ناپذیر هستند که از هرگونه بهروز رسانی منطق تجاری پس از پیادهسازی و استقرار قرارداد جلوگیری می کند.
-
-در حالی که این تغییرناپذیری برای حداقل سازی اعتماد، عدم تمرکز و امنیت قراردادهای هوشمند ضروریاند، ممکن است در برخی موارد مشکلاتی ایجاد کنند. برای مثال، کد تغییرناپذیر باعث میشود تا اصلاح کد قرارداد هوشمندی که دارای نقص امنیتی است امکانناپذیر شود.
-
-با این حال، افزایش تحقیقات در مورد بهبود قراردادهای هوشمند منجر به معرفی چندین الگوی ارتقاء شده است. این الگوهای ارتقاء به توسعه دهندگان این امکان را می دهد تا با قرار دادن منطق تجاری در قراردادهای مختلف، قراردادهای هوشمند را (در عین حفظ تغییر ناپذیری) ارتقا دهند.
-
-## پیشنیازها {#prerequisites}
-
-شما باید درک خوبی از [قراردادهای هوشمند](/developers/docs/smart-contracts/)، [آناتومی قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/) و [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) داشته باشید. این راهنما همچنین فرض میکند که خوانندگان درک درستی از برنامهنویسی قراردادهای هوشمند دارند.
-
-## ارتقاء قرارداد هوشمند چیست؟ {#what-is-a-smart-contract-upgrade}
-
-ارتقای قرارداد هوشمند شامل تغییر منطق تجاری یک قرارداد هوشمند و در عین حال حفظ وضعیت قرارداد است. واضح است که قابلیت ارتقا و تغییرپذیری یکسان نیستند، به خصوص در زمینه قراردادهای هوشمند.
-
-شما هنوز نمی توانید یک برنامه مستقر شده را به آدرسی در شبکه اتریوم تغییر دهید. اما میتوانید کدی را که هنگام تعامل کاربران با یک قرارداد هوشمند اجرا میشود، تغییر دهید.
-
-این کار از طریق روش های زیر قابل انجام است:
-
-1. ایجاد چندین نسخه از یک قرارداد هوشمند و انتقال حالت (یعنی داده ها) از قرارداد قدیمی به نمونه جدیدی از قرارداد.
-
-2. ایجاد قراردادهای جداگانه برای ذخیره کردن منطق تجاری و حالت.
-
-3. استفاده از الگوهای پراکسی برای واگذاری فراخوانی های تابع از یک قرارداد پروکسی تغییرناپذیر به یک قرارداد منطقی قابل تغییر.
-
-4. ایجاد یک قرارداد اصلی تغییر ناپذیر که با قراردادهای ماهواره ای انعطاف پذیر برای اجرای عملکردهای خاص ارتباط برقرار می کند و به آنها متکی است.
-
-5. استفاده از الگوی الماس برای واگذاری فراخوانی های تابع از یک قرارداد پراکسی به قراردادهای منطقی.
-
-### مکانیسم ارتقا شماره 1: انتقال قرارداد {#contract-migration}
-
-انتقال قرارداد مبتنی بر نسخه سازی است - ایده ایجاد و مدیریت حالت های منحصر به فرد یک نرم افزار. انتقال قرارداد شامل استقرار یک نمونه جدید از یک قرارداد هوشمند موجود و انتقال ذخیره و موجودی به قرارداد جدید است.
-
-قراردادی که به تازگی مستقر شده است یک فضای ذخیره خالی خواهد داشت که به شما امکان می دهد داده ها را از قرارداد قدیمی بازیابی کنید و آن را در پیاده سازی جدید بنویسید. پس از آن، باید همه قراردادهایی را که با قرارداد قدیمی در تعامل بودند، بهروزرسانی کنید تا نشانی جدید را منعکس کنند.
-
-آخرین مرحله در انتقال قرارداد متقاعد کردن کاربران برای تغییر استفاده از قرارداد جدید است. نسخه جدید قرارداد تعادل و آدرس های کاربر را حفظ می کند که تغییر ناپذیری را حفظ می کند. اگر این قرارداد مبتنی بر توکن است، همچنین باید با صرافیها تماس بگیرید تا قرارداد قدیمی را کنار بگذارید و از قرارداد جدید استفاده کنید.
-
-انتقال قرارداد یک اقدام نسبتاً ساده و ایمن برای ارتقاء قراردادهای هوشمند بدون ایجاد اختلال در تعاملات کاربر است. با این حال، انتقال دستی ذخیره سازی و موجودی کاربر به قرارداد جدید زمان بر است و می تواند کارمزد گس زیادی را به همراه داشته باشد.
-
-[اطلاعات بیشتر در مورد انتقال قرارداد.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
-
-### مکانیسم ارتقاء شماره 2: جداسازی داده ها {#data-separation}
-
-روش دیگر برای ارتقای قراردادهای هوشمند، تفکیک منطق تجاری و ذخیره داده ها به قراردادهای جداگانه است. این بدان معنی است که کاربران با قرارداد منطقی تعامل دارند، در حالی که داده ها در قرارداد ذخیره سازی ذخیره می شوند.
-
-قرارداد منطقی شامل کدی است که هنگام تعامل کاربران با برنامه اجرا می شود. همچنین آدرس قرارداد ذخیره سازی را نگه می دارد و برای دریافت و تنظیم داده ها با آن تعامل دارد.
-
-در همین حال، قرارداد ذخیره سازی وضعیت مرتبط با قرارداد هوشمند، مانند موجودی ها و آدرس های کاربر را حفظ می کند. توجه داشته باشید که قرارداد ذخیره سازی متعلق به قرارداد منطقی است و با آدرس دومی در هنگام استقرار پیکربندی شده است. این امر از تماس قراردادهای غیرمجاز با قرارداد ذخیره سازی یا به روز رسانی داده های آن جلوگیری می کند.
-
-بهطور پیشفرض، قرارداد ذخیرهسازی تغییر ناپذیر است، اما میتوانید قرارداد منطقی را که به آن اشاره میکند با یک پیادهسازی جدید جایگزین کنید. با این کار کدی که در EVM اجرا میشود، تغییر میکند، در حالی که فضای ذخیرهسازی و تعادل را دست نخورده نگه میدارد.
-
-استفاده از این روش ارتقا مستلزم بروز رسانی آدرس قرارداد منطقی در قرارداد ذخیره سازی است. همچنین به دلایلی که قبلا توضیح داده شد، باید قرارداد منطقی جدید را با آدرس قرارداد ذخیره سازی پیکربندی کنید.
-
-پیاده سازی الگوی جداسازی داده ها در مقایسه با انتقال قرارداد ساده تر است. با این حال، باید چندین قرارداد را مدیریت کنید و طرحهای مجوز پیچیده را برای محافظت از قراردادهای هوشمند در برابر ارتقاهای مخرب اجرا کنید.
-
-### مکانیسم ارتقاء شماره 3: الگوهای پراکسی {#proxy-patterns}
-
-الگوی پراکسی همچنین از جداسازی داده ها برای حفظ منطق تجاری و داده ها در قراردادهای جداگانه استفاده می کند. با این حال، در یک الگوی پراکسی، قرارداد ذخیرهسازی (به نام پراکسی) قرارداد منطقی را در طول اجرای کد فراخوانی می کند. این روش برعکس روش جداسازی داده است، که در آن قرارداد منطقی قرارداد ذخیره سازی را فرامیخواند.
-
-این چیزی است که در یک الگوی پراکسی اتفاق می افتد:
-
-1. کاربران با قرارداد پراکسی تعامل دارند، که دادهها را ذخیره میکند، اما منطق تجاری را حفظ نمیکند.
-
-2. قرارداد پراکسی آدرس قرارداد منطقی را ذخیره می کند و تمام فراخوانی های تابع را با استفاده از تابع `delegatecall` به قرارداد منطقی (که منطق تجاری را نگه می دارد) واگذار می کند.
-
-3. پس از ارسال فراخوانی به قرارداد منطقی، داده های برگشتی از قرارداد منطقی بازیابی شده و به کاربر بازگردانده می شود.
-
-استفاده از الگوهای پراکسی نیاز به درک عملکرد **delegatecall** دارد. اساساً، `delegatecall` یک کد عملیاتی است که به یک قرارداد اجازه میدهد قرارداد دیگری را فراخوانی کند، در حالی که اجرای کد واقعی در متن قرارداد فراخوانی اتفاق میافتد. مفهوم استفاده از `delegatecall` در الگوهای پراکسی این است که قرارداد پراکسی در حافظه خود می خواند و می نویسد و منطق ذخیره شده در قرارداد منطقی را اجرا می کند که گویی در حال فراخوانی یک تابع داخلی است.
-
-از [اسناد سالیدیتی](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries):
-
-> _نوع خاصی از تماس پیام وجود دارد، به نام **delegatecall** که با فراخوانی پیام یکسان است، صرف نظر از این که کد در آدرس مورد نظر در متن (یعنی در آدرس) اجرا می شود قرارداد فراخوانی و `msg.sender` و `msg.value` مقادیر خود را تغییر نمی دهند._ _این بدان معناست که یک قرارداد می تواند به صورت پویا کد را از آدرسی متفاوت در زمان اجرا بارگیری کند. محل ذخیره، آدرس فعلی و موجودی همچنان به قرارداد فراخوانی استناد میکنند، فقط کد از آدرس فراخوانی گرفته میشود._
-
-قرارداد پراکسی میداند که هر زمان که کاربر تابعی را فراخوانی میکند، `delegatecall` را فراخوانی میکند زیرا یک تابع `fallback` در آن تعبیه شده است. در برنامه نویسی سالیدیتی، [تابع fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) زمانی اجرا می شود که یک فراخوانی تابع با توابع مشخص شده در قرارداد مطابقت نداشته باشد.
-
-برای کارکرد الگوی پراکسی نیاز به نوشتن یک تابع بازگشتی سفارشی است که مشخص میکند قرارداد پراکسی چگونه باید فراخوانیهای تابعی را که پشتیبانی نمیکند مدیریت کند. در این مورد، تابع fallback پراکسی برای شروع یک فراخوانی واگذاری و تغییر مسیر درخواست کاربر به اجرای قرارداد منطقی فعلی برنامه ریزی شده است.
-
-قرارداد پراکسی به طور پیش فرض تغییر ناپذیر است، اما قراردادهای منطقی جدید با منطق تجاری به روز شده می توانند ایجاد شوند. در این صورت انجام ارتقاء به تغییر آدرس قرارداد منطقی اشاره شده در قرارداد پراکسی بستگی دارد.
-
-با اشاره قرارداد پراکسی به یک قرارداد منطقی جدید، کد اجرا شده هنگام فراخوانی تابع قرارداد پراکسی تغییر می کند. این به ما امکان میدهد تا منطق قرارداد را بدون درخواست از کاربران برای تعامل با یک قرارداد جدید ارتقا دهیم.
-
-الگوهای پراکسی روشی محبوب برای ارتقای قراردادهای هوشمند هستند زیرا مشکلات مربوط به انتقال قرارداد را از بین می برند. با این حال، استفاده از الگوهای پراکسی پیچیدهتر است و در صورت استفاده نادرست، میتواند نقصهای مهمی مانند [برخورد انتخابگر تابع](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) ایجاد کند.
-
-[اطلاعات بیشتر در مورد الگوهای پراکسی](https://blog.openzeppelin.com/proxy-patterns/).
-
-### مکانیسم ارتقاء شماره 4: الگوی استراتژی {#strategy-pattern}
-
-این تکنیک تحت تأثیر [الگوی استراتژی](https://en.wikipedia.org/wiki/Strategy_pattern) است، که ایجاد برنامههای نرمافزاری را تشویق میکند که با برنامههای دیگر برای پیادهسازی ویژگیهای خاص ارتباط برقرار کنند. اعمال الگوی استراتژی برای توسعه اتریوم به معنای ساخت یک قرارداد هوشمند است که توابع قراردادهای دیگر را فراخوانی می کند.
-
-قرارداد اصلی در این مورد حاوی منطق اصلی تجارت است، اما با سایر قراردادهای هوشمند ("قراردادهای ماهواره ای") برای اجرای عملکردهای خاص ارتباط برقرار می کند. این قرارداد اصلی همچنین آدرس هر قرارداد اقماری را ذخیره می کند و می تواند بین پیاده سازی های مختلف قرارداد اقماری جابجا شود.
-
-می توانید یک قرارداد اقماری جدید بسازید و قرارداد اصلی را با آدرس جدید پیکربندی کنید. این به شما امکان میدهد _استراتژیها_ (یعنی اجرای منطق جدید) را برای یک قرارداد هوشمند تغییر دهید.
-
-اگرچه شبیه به الگوی پراکسی که قبلاً مورد بحث قرار گرفت، الگوی استراتژی متفاوت است زیرا قرارداد اصلی که کاربران با آن تعامل دارند، منطق تجاری را حفظ می کند. استفاده از این الگو به شما این فرصت را می دهد که تغییرات محدودی را در یک قرارداد هوشمند بدون تأثیر بر زیرساخت اصلی ایجاد کنید.
-
-اشکال اصلی این است که این الگو بیشتر برای بهروزرسانیهای جزئی مفید است. همچنین، اگر قرارداد اصلی به خطر بیفتد (به عنوان مثال، از طریق هک)، نمی توانید از این روش ارتقا استفاده کنید.
-
-### مکانیسم ارتقاء شماره 5: الگوی الماس {#diamond-pattern}
-
-الگوی الماس را می توان بهبود در الگوی پروکسی در نظر گرفت. الگوهای الماس با الگوهای پراکسی متفاوت هستند زیرا قرارداد پروکسی الماس می تواند فراخوانی های تابع را به بیش از یک قرارداد منطقی واگذار کند.
-
-قراردادهای منطقی در الگوی الماس به عنوان _فاست_ شناخته می شوند. برای اینکه الگوی الماس کار کند، باید در قرارداد پراکسی یک نقشه برداری ایجاد کنید که [انتخابگرهای تابع](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) را به آدرسهای جنبههای مختلف نگاشت میکند.
-
-هنگامی که یک کاربر یک تابع را فراخوانی می کند، قرارداد پراکسی نگاشت را بررسی می کند تا فاست مسئول اجرای آن تابع را پیدا کند. سپس `delegatecall` را فراخوانی میکند (با استفاده از تابع fallback) و فراخوانی را به قرارداد منطقی مناسب هدایت میکند.
-
-الگوی ارتقاء الماس دارای مزایایی نسبت به الگوهای ارتقاء پراکسی سنتی است:
-
-1. این به شما امکان می دهد بخش کوچکی از قرارداد را بدون تغییر تمام کد ارتقا دهید. استفاده از الگوی پراکسی برای ارتقاء مستلزم ایجاد یک قرارداد منطقی کاملاً جدید است، حتی برای ارتقاهای جزئی.
-
-2. همه قراردادهای هوشمند (از جمله قراردادهای منطقی مورد استفاده در الگوهای پراکسی) دارای محدودیت اندازه 24 کیلوبایت هستند که می تواند یک محدودیت باشد – به خصوص برای قراردادهای پیچیده که به عملکردهای بیشتری نیاز دارند. الگوی الماس حل این مشکل را با تقسیم توابع در چندین قرارداد منطقی آسان می کند.
-
-3. الگوهای پراکسی یک رویکرد همه جانبه را برای کنترل های دسترسی اتخاذ می کنند. یک نهاد با دسترسی به توابع ارتقا میتواند قرارداد _کل_ را تغییر دهد. اما الگوی الماس یک رویکرد مجوزهای مدولار را فعال می کند، که در آن می توانید موجودیت ها را به ارتقاء عملکردهای خاص در یک قرارداد هوشمند محدود کنید.
-
-[اطلاعات بیشتر در مورد الگوی الماس](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
-
-## مزایا و معایب ارتقای قراردادهای هوشمند {#pros-and-cons-of-upgrading-smart-contracts}
-
-| نقاط مثبت | نقاط منفی |
-| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| ارتقای قرارداد هوشمند میتواند رفع آسیبپذیریهای کشف شده در مرحله پس از استقرار را آسانتر کند. | ارتقای قراردادهای هوشمند، ایده تغییرناپذیری کد را که پیامدهایی برای تمرکززدایی و امنیت دارد، نفی میکند. |
-| توسعه دهندگان می توانند از ارتقاء منطقی برای افزودن ویژگی های جدید به برنامه های غیرمتمرکز استفاده کنند. | کاربران باید به توسعه دهندگان اعتماد کنند که قراردادهای هوشمند را خودسرانه تغییر ندهند. |
-| ارتقاء قراردادهای هوشمند می تواند ایمنی را برای کاربران نهایی بهبود بخشد زیرا باگ ها را می توان به سرعت برطرف کرد. | برنامه نویسی عملکرد ارتقاء به قراردادهای هوشمند لایه دیگری از پیچیدگی را اضافه می کند و احتمال نقص های مهم را افزایش می دهد. |
-| ارتقاء قرارداد به توسعه دهندگان فضای بیشتری برای آزمایش ویژگی های مختلف و بهبود دپ ها در طول زمان می دهد. | فرصت ارتقای قراردادهای هوشمند ممکن است توسعهدهندگان را تشویق کند پروژهها را سریعتر راهاندازی کنند بدون اینکه در مرحله توسعه دقت لازم را انجام دهند. |
-| | کنترل دسترسی ناامن یا متمرکز شدن در قراردادهای هوشمند میتواند بهروزرسانیهای غیرمجاز را برای عوامل مخرب آسانتر کند. |
-
-## ملاحظات ارتقای قراردادهای هوشمند {#considerations-for-upgrading-smart-contracts}
-
-1. برای جلوگیری از ارتقاء قراردادهای هوشمند غیرمجاز، به ویژه اگر از الگوهای پراکسی، الگوهای استراتژی یا جداسازی داده ها استفاده می شود، از مکانیسم های کنترل دسترسی/مجوز دسترسی ایمن استفاده کنید. یک مثال محدود کردن دسترسی به عملکرد ارتقاء است، طوری که فقط مالک قرارداد می تواند آن را فراخوانی کند.
-
-2. ارتقای قراردادهای هوشمند یک فعالیت پیچیده است و برای جلوگیری از معرفی آسیبپذیریها نیاز به دقت بالایی دارد.
-
-3. کاهش مفروضات اعتماد با تمرکززدایی از فرآیند اجرای ارتقاء. استراتژیهای احتمالی شامل استفاده از [قرارداد کیف پول چند امضایی](/developers/docs/smart-contracts/#multisig) برای کنترل ارتقاء، یا الزام [اعضای DAO](/dao/) برای رای دادن به تایید ارتقاء است.
-
-4. از هزینه های مربوط به ارتقاء قراردادها آگاه باشید. به عنوان مثال، کپی کردن حالت (به عنوان مثال، موجودی کاربر) از یک قرارداد قدیمی به یک قرارداد جدید در طول انتقال قرارداد ممکن است به بیش از یک تراکنش نیاز داشته باشد، به این معنی که کارمزدهای گس بیشتر است.
-
-5. برای محافظت از کاربران، **قفل های زمانی** را در نظر بگیرید. قفل زمانی به تاخیر اعمال شده در تغییرات یک سیستم اشاره دارد. قفلهای زمانی را میتوان با یک سیستم حاکمیت چند امضایی برای کنترل ارتقاها ترکیب کرد: اگر یک اقدام پیشنهادی به آستانه تأیید لازم برسد، تا زمانی که دوره تاخیر از پیش تعریفشده سپری نشود، اجرا نمیشود.
-
-قفلهای زمانی به کاربران در صورت مخالفت با تغییر پیشنهادی (مثلاً ارتقاء منطقی یا طرحهای هزینه جدید) مدتی زمان میدهند تا از سیستم خارج شوند. بدون قفل زمانی، کاربران باید به توسعه دهندگان اعتماد کنند تا بدون اطلاع قبلی تغییرات دلخواه را در یک قرارداد هوشمند اعمال نکنند. اشکال در اینجا این است که قفل های زمانی توانایی اصلاح سریع آسیب پذیری ها را محدود می کنند.
-
-## منابع {#resources}
-
-**پلاگین های ارتقاء OpenZeppelin - _مجموعه ای از ابزارها برای استقرار و ایمنسازی قراردادهای هوشمند قابل ارتقا._**
-
-- [گیت هاب](https://github.com/OpenZeppelin/openzeppelin-upgrades)
-- [اسناد](https://docs.openzeppelin.com/upgrades)
-
-## آموزشها {#tutorials}
-
-- [به روز رسانی قراردادهای هوشمند | آموزش یوتیوب](https://www.youtube.com/watch?v=bdXJmWajZRY) از پاتریک کالینز
-- [آموزش انتقال قرارداد هوشمند اتریوم](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) توسط آستین گریفیث
-- [استفاده از الگوی پراکسی UUPS برای ارتقاء قراردادهای هوشمند](https://blog.logrocket.com/author/praneshas/) از Pranesh A.S
-- [آموزش Web3: نوشتن قرارداد هوشمند قابل ارتقا (پراکسی) با استفاده از OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) از fangjun.eth
-
-## بیشتر بخوانید {#further-reading}
-
-- [حالت ارتقاهای قرارداد هوشمند](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) از سانتیاگو پالادینو
-- [روش های متعدد برای ارتقاء قرارداد هوشمند سالیدیتی](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - وبلاگ Crypto Market Pool
-- [بیاموزید: ارتقای قراردادهای هوشمند](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - در اسناد OpenZeppelin
-- [الگوهای پراکسی برای ارتقای قراردادهای سالیدیتی: شفاف در مقابل پروکسی های UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) از نوین ساهو
-- [ ارتقاء الماس چگونه کار می کند](https://dev.to/mudgen/how-diamond-upgrades-work-417j) از نیک ماج
diff --git "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" "b/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
deleted file mode 100644
index b88037cb5e7..00000000000
--- "a/public/content/translations/fa/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md"
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: تأیید کردن قراردادهای هوشمند
-description: نگاهی بر تائید کردن کد قراردادهای هوشمند اتریوم
-lang: fa
----
-
-[قراردادهای هوشمند](/developers/docs/smart-contracts/) به گونه ای طراحی شده اند که بی نیاز از اطمینان باشند، به این معنی که کاربرها پیش از برقراری ارتباط با یک کانترکت، نیازی نباشد به شخص یا اشخاص سوم شخص(خواه توسعه دهنده و خواه شرکت ها) اعتماد کنند. به عنوان یکی از نیازمندی های بی نیازی از اعتماد، کاربران و همینطور سایر توسعه دهنده باید بتوانند به راحتی به کدهای قراردادهای هوشمند دسترسی داشته باشند تا عملکرد آنها را بررسی و تائید کنند. وریفای یا تائید کد قرارداد هوشمند، این اطمینان خاطر را به کاربران و توسعه دهندگان میدهد که کد منتشر شده از قرارداد هوشمند، دقیقاً همان کدی است که در آدرس آن قرارداد بر بستر بلاکچین اتریوم وجود دارد.
-
-نکته مهمی که وجود دارد این است که باید بین تائید کردن کد و [تائید رسمی](/developers/docs/smart-contracts/formal-verification/) تمایز قائل شد. تائید کردن کد، که در ادامه به تفصیل آن را شرح خواهیم داد، به عملیاتی اطلاق میشود که کدهای یک قرارداد هوشمند در یک زبان سطح بالا (مثل سالیدیتی) دقیقاً به همان بایت کد اجرایی قرارداد هوشمند کامپایل شود. ولی تائید رسمی به توضیح صحیح بودن قرارداد هوشمند مطابق با عملکرد مورد انتظار میپردازد. اگرچه در مفاهیمی که در حال صحبت از آن هستیم، وریفای یا تائید کردن قرارداد عموماً به تائید کدها اطلاق میشود.
-
-## تائید کد چیست؟ {#what-is-source-code-verification}
-
-پیش از دیپلوی یک قرارداد هوشمند در [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/)، توسعه دهنده ها کد قرارداد-دستورالعملهای [نوشته شده به زبان سالیدیتی](/developers/docs/smart-contracts/compiling/) یا سایر زبان های سطح بالا- را به بایت کد [کامپایل](/developers/docs/smart-contracts/languages/) می کنند. از آنجایی که EVM توانایی تفسیر دستورات سطح بالا را ندارد، به منظور اجرای منطق قرارداد بر روی EVM، کامپایل کردن کدها به بایت کد(دستورات سطح پایین و قابل درک برای ماشین) ضروری است.
-
-تائید کردن کد به معنای مقایسه ی کد قرارداد هوشمند و بایت کد کامپایل شده ای که در زمان ساخته شدن قرارداد استفاده میشود، و به منظور شناسایی هرگونه تفاوت می باشد. تائید کردن قرارداد هوشمند از این جهت حائز اهمیت است که کد قرارداد تبلیغ شده، ممکن است با آنچه که در حال اجرا بر روی بلاکچین است متفاوت باشد.
-
-تائید قرارداد هوشمند امکان بررسی و تحقیق کاری که قرارداد انجام می دهد را از طریق خواندن کدهای سطح بالا و بدون نیاز به خواندن کدهای ماشین فراهم می سازد. توابع، مقادیر، و عموماً اسامی متغیرها و کامنت ها عیناً مطابق کد اصلی ای هستند که قرارداد با آنها کامپایل و دیپلوی شده است. این موضوع، خواندن کد را بسیار راحت تر می کند. تائید کد، همچنین مستندات کد را فراهم آوری می کند و باعث میشود تا کاربران نهایی بتوانند متوجه شوند که قرارداد هوشمند مربوطه برای چه کاری طراحی شده است.
-
-### تائید کامل چیست؟ {#full-verification}
-
-بخش هایی از قرارداد هوشمند، از جمله کامنت ها یا اسامی متغیرها بر روی بایت کدهای کامپایل شده تاثیری ندارند. این موضوع بدین معناست که دو کد مختلف، با اسامی متغیر و همینطور کامنت های متفاوت، می توانند توسط یک قرارداد یکسان تائید شوند. با استفاده از این مسئله، یک کاربر بداندیش، می تواند با افزودن کامنت های فریبنده و یا نام گذاری گمراه کننده نام متغیرها در کد، کدی متفاوت از کد اصلی را تائید کند.
-
-به منظور جلوگیری از این اتفاق، می توان با افزودن یک داده اضافه به بایت کد که در حکم یک _تضمین رمزنگاری_ و به عنوان _ اثر انگشت_ عملیات کامپایل برای همسان بودن کد می باشد اقدام نمود. اطلاعات ضروری در [داده های متای قرارداد سالیدیتی](https://docs.soliditylang.org/en/v0.8.15/metadata.html) قابل دستیابی است، همچنین هش این فایل نیز به بایت کد قرارداد الحاق میشود. این مورد را می توانید به طور عملیاتی در [فضای بازی داده های متا](https://playground.sourcify.dev) مشاهده کنید
-
-فایل داده های متا یا متادیتا، حاوی اطلاعاتی در خصوص کامپایل شدن قرارداد هوشمند و شامل کدها و هش آنها می باشد. این بدین معناست که در صورت رخ دادن کوچکترین تغییری در تنظیمات کامپایل و یا حتی تغییر در یک بایت از کدها، فایل متادیتا تغییر خواهد کرد. همچنین متعاقباً، هش فایل متادیتا که به بایت کد الحاق شده است نیز تغییر خواهد کرد. این بدین معناست که اگر بایت کد یک قرارداد + هش متادیتای الحاص شده به آن، با کد داده شده و تنظیمات کامپایل یکسان باشد، می توانیم کاملاً مطمئن باشیم که حتی یک بایت نیز تغییری نکرده و این کد، کد اصلی کامپایل شده می باشد.
-
-به این نوع از تائید که از هش متادیتا بهره می برد، اصطلاحاً **[تائید کامل](https://docs.sourcify.dev/docs/full-vs-partial-match/)** (همچنین "تائید بی نقص") گفته می شود. اگر هش های متادیتا یکسان نبوده و یا به عنوان تائید شده نباشند، به آن "تطابق جزئی" گفته می شود، که در حال حاضر رایج ترین شیوه در تائید قراردادهاست. در صورتی که عملیات تائید کردن به صورت کامل نباشد، این امکان وجود دارد که [کد مخربی به قرارداد وارد شود](https://samczsun.com/hiding-in-plain-sight/) که در کد تائید شده قابل مشاهده نباشد. بیشتر توسعه دهنده ها از وجود تائیدیه کامل بی اطلاع اند و فایل متادیتای کامپایل خود را نگهداری نمی کنند، از این رو، عملاً تاکنون تائید جزئی به عنوان روش تائید قراردادها مورد استفاده قرار میگیرد.
-
-## چرا تائید کد مهم است؟ {#importance-of-source-code-verification}
-
-### بی نیازی از اعتماد {#trustlessness}
-
-بدون شک، بی نیازی از اعتماد یکی از بزرگترین وعده های قراردادهای هوشمند و [اپلیکیشن های غیرمتمرکز(dappها)](/developers/docs/dapps/) است. قراردادهای هوشمند "تغییر ناپذیر" بوده و امکان عوض کردن ندارند؛ یک قرارداد، تنها مسئول اجرای منطق کاری است که در زمان دیپلوی شدن، در کدش تعریف شده است. این موضوع به این معناست که توسعه دهندهها و شرکتها(و البته قابل بسط به سایر افراد نیز می باشد)، پس از دیپلوی(استقرار) بر روی شبکه اتریوم، نمیتوانند تغییری در کد قرارداد ایجاد کنند.
-
-به منظور بی نیاز بودن از اعتماد در یک قرارداد هوشمند، کد قرارداد باید جهت تائید شدن به صورت مستقل، قابل دسترس باشد. اگرچه بایتکد کامپایل شده ی قراردادهای هوشمند بهصورت عمومی بر روی بلاکچین قابل دسترسی است، اما درک زبان سطح پایین، هم برای توسعه دهنده ها و هم کاربران عادی سخت است.
-
-به منظور کاهش گمانه زنی ها در خصوص اعتمادپذیری، پروژه ها کد قراردادهای خود را منتشر می کنند. اما همین موضوع، باعث ایجاد یک مشکل دیگر می شود: تائید همسان بودن کد منتشر شده با بایت کدهای قرارداد مربوطه، سخت است. در این سناریو، بدلیل اینکه کاربران باید به توسعه دهنده اعتماد کنند که منطق کاری قرارداد (با تغییر دادن بایتکد) را پیش از دیپلوی بر روی بلاکچین تغییر نمیدهد، ارزش بی نیازی از اعتماد، در عمل از بین می رود.
-
-ابزارهای تائید کد، ضمانت می کنند که کد قرارداد هوشمند دقیقاً منطبق بر کد اسمبلی آن قرارداد باشد. نتیجه این امر، پدید آمدن یک اکوسیستم بی نیاز از اعتماد است، جایی که کاربران، چشم و گوش بسته به افراد یا نهادهای سوم شخص اعتماد نکرده و به جای آن، پیش از انجام هرگونه واریز دارایی به یک قرارداد، کدهای آن قرارداد را تائید می کنند.
-
-### امنیت کاربر {#user-safety}
-
-معمولاً هر جا که قراردادهای هوشمند باشند، پول زیادی نیز سپرده گذاری شده است. به همین خاطر پیش از استفاده از قراردادهای هوشمند، نیاز بیشتری به تضمین امنیت و تائید بودن منطق آن قرارداد بوجود می آید. مشکلی که در اینجا وجود دارد این است که توسعه دهنده های بی اخلاق و شرور، می توانند کاربران را با وارد کردن کدهای مخرب به قرارداد هوشمند، فریب دهند. بدون انجام تائیدیه، قراردادهای هوشمند مخرب میتوانند شامل کدهای مخربی از جمله: [در پشتی](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)، مکانیزمهای کنترل دسترسی ناجور، آسیبپذیریهای قابل سوء استفاده، و سایر مخاطراتی که امنیت کاربر را به خطر می اندازند بوده که این کدها قابل شناسایی نباشند.
-
-انتشار فایل کدهای قرارداد هوشمند، دسترسی به نواحی ای از قرارداد که پتانسیل مورد حمله واقع شدن را دارند را برای علاقه مندانی مثل حسابرسان کد تسهیل می کند. وجود اشخاص مستقل از هم که عملیات تائید قرارداد هوشمند را انجام دهند، تضمینی قوی تر برای امنیت کاربران به حساب می آید.
-
-## نحوه تائید کد قراردادهای هوشمند اتریومی {#source-code-verification-for-ethereum-smart-contracts}
-
-[استقرار قرارداد هوشمند بر روی اتریوم](/developers/docs/smart-contracts/deploying/) نیازمند ارسال یک تراکنش با پی لود حاوی داده(بایت کد کامپایل شده) به یک آدرس خاص است. پی لود داده، با کامپایل شدن کد قرارداد، به علاوه ی [آرگومانهای کانستراکتور](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) قرارداد که به پی لود داده در تراکنش الحاق شده است ساخته می شود. عملیات کامپایل قطعی است، به این معنا که اگر فایل کدها و تنظیمات کامپایل(از جمله نسخه کامپایلر، اپتیمایز، و ...) یکسان باشند، همیشه یک خروجی یکسان(بایتکد قرارداد) ایجاد خواهد شد.
-
-![دیاگرامی که نمایش دهنده کد وریفای شده قرارداد هوشمند میباشد](./source-code-verification.png)
-
-وریفای کردن یک قرارداد هوشمند اساساً شامل مراحل زیر می باشد:
-
-1. وارد کردن فایل کدها و تنظیمات کامپایل به یک کامپایلر.
-
-2. کامپایلر، بایتکد قرارداد را به عنوان خروجی بر میگرداند
-
-3. بایتکد قرارداد دیپلوی شده در یک آدرس مشخص شده قابل دستیابی است
-
-4. بایتکد دیپلوی شده با بایتکد حاصله از دیپلوی مجدد مقایسه می شود. در صورت تصاطبق کدها، قرارداد با کد داده شده و تنظیمات کامپایل مشخص شده تائید و وریفای می شود.
-
-5. علاوه بر این، در صورتی که هش داده های اضافی یا همان متا دیتای در انتهای بایتکد، منطبق باشند، یک تطابق کامل خواهیم داشت.
-
-توجه داشته باشید که در اینجا توضیح ساده ای از تائید کردن را به میان آورده ایم، و در این پروسه استثناهای بسیاری وجود دارند که ممکن است توضیحات متفاوتی با آنچه که در حال صحبت در اینجا هستیم داشته باشند، مثلاً در زمانی که
-
-متغیرهای از نوع immutable" داشته باشیم.
-
-
-
-## ابزارهای وریفای کد {#source-code-verification-tools}
-
-پروسه مرسوم وریفای کردن قراردادها می توانند پیچیده باشند. به همین علت است که ابزارهایی برای وریفای کد قراردادهای هوشمند مستفر شده بر روی اتریوم داریم. این ابزارها بهطور اتوماتیک بخش های بزرگی از کد را تائید و وریفای کرده و همچنین می توانند کدهای وریفای شده را برای انتفاع کاربرها گلچین کنند.
-
-
-
-### Etherscan {#etherscan}
-
-اگرچه اکثراً آنرا به عنوان [مرورگر بلاکچین اتریوم](/developers/docs/data-and-analytics/block-explorers/) می شناسند، اتراسکن همچنین [سرویس تائید کد](https://etherscan.io/verifyContract) برای توسعه دهندههای قراردادهای هوشمند و کاربران عادی را ارائه می دهد.
-
-اتراسکن اجازه کامپایل مجدد بایتکد قرارداد از پی لود داده اصلی (کد، آدرس کتابخانه، تنظیمات کامپایلر، آدرس قرارداد، و ...) را به شما می دهد در صورتی که بایتکد مجدد کامپایل شده، با بایتکد (و پارامترهای کانستراکتور) قراردادی بر روی بلاکچین (آن-چین) منطبق باشد، سپس [قرارداد وریفای می شود](https://info.etherscan.com/types-of-contract-verification/).
-
-هنگامی که قرارداد وریفای شود، کد قرارداد شما برچسب "verified" دریافت کرده و به منظور حسابرسی و آدیت شدن سایرین، بر روی اتراسکن منتشر می شود. همچنین به قسمت قراردادهای وریفای شده0> یا همان verified contracts -که مخزنی از قراردادهای هوشمند با کدهای وریفای شده است- اضافه می شود.
-
-اتر اسکن، پر استفاده ترین ابزار وریفای و تائید قراردادهای هوشمند است. هرچند، سرویس وریفای قراردادهای اتراسکن نواقصی نیز دارد: از جمله این نواقص می توان به ناتوانی در مقایسه **هش متادیتا**ی بایتکد آن-چین و بایتکد مجدد کامپایل شده اشاره کرد. بنابراین می توان گفت که تطابقهای اتراسکن از نوع تطابق جزئی است.
-
-[مطالب بیشتر در خصوص وریفای قراردادهای هوشمند در اتراسکن](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
-
-
-
-### Sourcify {#sourcify}
-
-ابزار دیگری که متن باز و غیرمتمرکز بوده و برای وریفای قراردادهای هوشمند به کار میرود، [Sourcify](https://sourcify.dev/#/verifier) میباشد. این ابزار، مرورگر بلاک ها نیست و فقط قراردادها را بر روی [انواع شبکه های منطبق بر ماشین مجازی اتریوم](https://docs.sourcify.dev/docs/chains) وریفای می کند. این ابزار به عنوان یک زیرساخت عمومی برای سایر ابزارها عمل می کند، و هدفش این است که ارتباط گیری با قراردادهای هوشمند را با استفاده از [ABI](/developers/docs/smart-contracts/compiling/#web-applications) و کامنتهای از نوع [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) که در فایل متادیتا یافت می شود، کاربر پسند تر کند.
-
-بر خلاف اتراسکن، Sourcify از تطابق کامل با هش متادیتا پشتیبانی می کند. قراردادهای تائید شده، در [مخزن عمومی](https://docs.sourcify.dev/docs/repository/) یا HTTP و [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) که یک فضای ذخیرهسازی غیر متمرکز [مبتنی بر آدرس](https://web3.storage/docs/concepts/content-addressing/) است قرار میگیرند. از آنجایی که هش متادیتای الحاق شده، یک هش IPFS است، این امر اجازه ی واکشی فایل متادیتای یک قرارداد از بستر IPFS را فراهم میآورد.
-
-به علاوه، از آنجایی که هش IPFS این فایلها همچنین در متادیتا نیز یافت میشود، هر کسی این امکان را دارد که فایل کد را از طریق IPFS دریافت کند. با فراهمسازی فایل متادیتا و فایل کدها از طریق API و یا [رابط کاربری](https://sourcify.dev/#/verifier)، و یا استفاده از پلاگینهای آن، می توان قرارداد را وریفای کرد. همچنین ابزار مانیتورینگ و رصد Sourcify گوش به زنگ ساخته شدن قراردادها در بلوکهای جدید بوده و اگر متادیتا و فایل کد قراردادی در IPFS منتشر شده است، سعی میکند آنرا وریفای کند.
-
-[مطالب بیشتر در خصوص وریفای قراردادها بر روی Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/).
-
-
-
-### Tenderly {#tenderly}
-
-پلتفرم [Tenderly](https://tenderly.co/) به توسعهدهندههای وب3 قابلیت ساخت، تست، مانیتور کردن، و اجرای قراردادهای هوشمند را میدهد. تندرلی، با مجموعه ای از ابزارهای اشکالزدایی، با ابزارهای قابل مشاهده پذیری و زیرساخت ساخته شدن بلوکها، در مسیر توسعه قرارداد هوشمند، به توسعه دهنده ها سرعت میبخشد. به منظور بهرهمندی از تمامی امکانات تندرلی، توسعهدهندهها نیاز به [وریفای کردن کدقرارداد](https://docs.tenderly.co/monitoring/contract-verification) دارند.
-
-امکان وریفای عمومی یا خصوصی یک قرارداد وجود دارد. در صورت وریفای بهصورت خصوصی، قرارداد هوشمند فقط برای شما (و افراد تیم پروژهی شما) قابل مشاهده است. وریفای کردن عمومی قرارداد، آنرا برای تمامی کاربران پلتفرم تندرلی قرار میدهد.
-
-شما می توانید با استفاده از [داشبورد کاربری](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract)، [پلاگین هاردهت تندرلی](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin)، و یا [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) قراردادهای خود را وریفای کنید.
-
-در صورتی که قرارداد خود را از طریق داشبورد کاربری وریفای کنید نیاز دارید که فایل کد یا فایل متادیتای ساخته شده توسط کامپایلر سالیدیتی، آدرس/شبکه، و تنظیمات کامپایلر را ایمپورت کنید.
-
-با استفاده از پلاگین هاردهت تندرلی، می توانید دسترسی های بیشتر با سختی کمتری در خلال پروسه وریفای کردن داشته باشید، و این باعث فعالسازی امکان انتخاب وریفای بین روش اتوماتیک (بدون کد) و دستی (نیازمند کدنویسی) میشود.
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [وریفای کردن کد منبع قرارداد](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/fa/21) Whitepaper/whitepaper/index.md b/public/content/translations/fa/21) Whitepaper/whitepaper/index.md
deleted file mode 100644
index 42e678b2a6f..00000000000
--- a/public/content/translations/fa/21) Whitepaper/whitepaper/index.md
+++ /dev/null
@@ -1,610 +0,0 @@
----
-title: برگه سفید اتریوم
-description: مقاله مقدماتی اتریوم که در سال 2013 قبل از راهاندازی آن منتشر شد.
-lang: fa
-sidebarDepth: 2
-hideEditButton: true
----
-
-# برگه سفید اتریوم {#ethereum-whitepaper}
-
-_این مقاله مقدماتی در ابتدا در سال ۲۰۱۳ توسط ویتالیک بوترین، بنیانگذار [اتریوم](/what-is-ethereum/)، پیش از راهاندازی پروژه در سال ۲۰۱۵ منتشر شد. شایان ذکر است که اتریوم، مانند بسیاری از پروژه های جامعه محور، پروژه های نرم افزاری منبع باز، از زمان نقطه آغازینش تکامل پیدا کرده است._
-
-_با وجود عمری چندین ساله، ما این مقاله را حفظ میکنیم چون میتواند به عنوان مرجعی مفید و نمودی دقیق از اتریوم و چشم اندازش عمل کند. برای اطلاع از آخرین پیشرفتهای اتریوم و اینکه تغییرات در پروتکل چگونه اعمال میشوند، [این راهنما](/learn/) را توصیه میکنیم._
-
-[محققان و دانشگاهیان که به دنبال یک نسخه تاریخی یا متعارف از وایت پیپر [از دسامبر 2014] هستند، باید از این PDF استفاده کنند.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf)
-
-## یک پلتفرم قرارداد هوشمند و برنامهی غیرمتمرکز نسل بعدی {#a-next-generation-smart-contract-and-decentralized-application-platform}
-
-توسعه بیت کوین توسط ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب به عنوان یک تحول اساسی درصنعت پول و رمزارز مورد استقبال قرار گرفته است، اولین نمونه یک دارایی دیجیتال که به طور همزمان نه هیچ پشتوانه یا "[ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" دارد و نه هیچ مرجع عرضه متمرکز یا کنترل کننده. با این حال، یکی از بخشهای - شاید مهم تر - تجربه بیت کوین زیربنای فناوری زنجیره بلوکی آن به عنوان ابزاری برای اجماع توزیع شده است، و توجهات به سرعت در حال شروع به تغییر به این جنبه دیگر بیت کوین است. کاربردهای جایگزین رایج فناوری بلاک چین شامل استفاده از دارایی های دیجیتال درون بلاک چین برای نشان دادن ارزهای سفارشی و ابزارهای مالی ("[سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lBEoW2T ویرایش)")، مالکیت یک دستگاه فیزیکی زیربنایی ("[اموال هوشمند](https://en.bitcoin.it/wiki/Smart_Property)")، داراییهای غیرقابل تعویض مانند نامهای دامنه ("[Namecoin](http://namecoin.org)")، و همچنین برنامههای پیچیدهتر شامل داشتن داراییهای دیجیتال که مستقیماً توسط یک قطعه کد کنترل میشوند. اجرای قوانین دلخواه ("[هوشمند قراردادها](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") یا حتی "
-
-سازمان های مستقل غیرمتمرکز" (DAOs). آنچه اتریوم قصدش را دارد فراهمسازی یک زنجیره بلوکی با یک زبان برنامه نویسی توکار تورینگ-کامل تمام عیار است که بتوان از آن برای ساخت "قرارداد" هایی که میتوانند برای کد کردن توابع انتقال وضعیت دلخواه مورد استفاده قرار بگیرند بهره برد، که به کاربرها اجازه ساخت هر کدام از سیستم های پیشتر ذکر شده را و همچنین بسیاری از انواع دیگری که حتی تصورشان را هم هنوز نکرده ایم میدهد، صرفاً با به نوشته در آوردن منطق آن در چند خط کد.
-
-
-
-## مقدمه ای بر بیت کوین و مفاهیم موجود {#introduction-to-bitcoin-and-existing-concepts}
-
-
-
-### تاریخچه {#history}
-
-مفهوم ارز دیجیتال نامتمرکز و همچنین برنامه های جایگزین مانند ثبت اموال، برای دهه ها وجود داشته است. پروتکلهای پول نقد الکترونیکی ناشناس در دهههای 1980 و 1990، عمدتاً متکی به یک رمزنگاری بدوی به نام کورکننده چاومین، ارزی با درجه بالایی از حریم خصوصی ارائه می شدند، اما پروتکلها عمدتاً به دلیل اتکا به یک واسطه متمرکز نتوانستند مورد توجه قرار گیرند. در سال 1998، [b-money](http://www.weidai.com/bmoney.txt) از Wei Dai نخستین طرحی شد که ایده ساخت پول از طریق حل معما های محاسباتی و نیز اجماع نامتمرکز را معرفی میکرد، اما جزئیات طرح پیرامون اینکه اجماع نامتمرکز در واقع چگونه میتوانست تعبیه شود ناچیز بود. در سال 2005، هال فینی مفهوم [اثبات کار قابل استفاده مجدد](https://nakamotoinstitute.org/finney/rpow/) را معرفی کرد، سیستمی که از ایدههایی از b-money به همراه پازلهای سخت محاسباتی Hashcash آدام بک برای ایجاد مفهومی برای یک ارز دیجیتال بهره میبرد، اما بار دیگر به دلیل تکیه بر محاسبات قابل اعتماد به عنوان یک بکاند، دور از ایدهآل قرار گرفت. در سال 2009، یک ارز غیرمتمرکز برای اولین بار در عمل توسط ساتوشی ناکاموتو پیادهسازی شد، که ترکیبی از اصول اولیه برای مدیریت مالکیت از طریق رمزنگاری کلید عمومی همچنین الگوریتم اجماع برای پیگیری صاحبان سکهها، معروف به "اثبات کار" اجرا شد.
-
-سازوکار پشت اثبات کار پیشرفت شگفت انگیزی بود چون به طور همزمان دو مشکل را حل میکرد. در وهله اول يك الگوريتم اجماع و ساده و موثر را ارائه مي كرد و به گره ها در شبكه اجازه مي دهد كه بصورت جامع و متمركز بر حالت به روز شده دفتر حساب بيتكوين توافق كنند. دوماً، مکانیسمی را برای ورود آزادانه به فرآیند اجماع ارائه داد که مشکل تصمیم گیری برای اینکه چه کسی هم بر اجماع تاثیر بگذارد و هم از حملات sybil جلوگیری کند. این کار را با جایگزین کردن یک مانع رسمی برای مشارکت، مانند الزام به ثبت نام به عنوان یک موجودیت منحصر به فرد در یک لیست خاص، با یک مانع اقتصادی انجام می دهد - وزن یک گره واحد در فرآیند رای گیری اجماع مستقیماً با قدرت محاسباتی که گره به ارمغان می آورد، متناسب است. از آن زمان، یک رویکرد جایگزین به نام _اثبات سهام_ پیشنهاد شده است که وزن یک گره را متناسب با دارایی های ارز آن محاسبه می کند و نه منابع محاسباتی. بحث در مورد مزایای نسبی دو رویکرد خارج از محدوده این مقاله است، اما باید توجه داشت که هر دو رویکرد می توانند به عنوان ستون فقرات یک رمزارز مورد استفاده قرار گیرند.
-
-
-
-### بیت کوین به عنوان یک سیستم انتقال حالت {#bitcoin-as-a-state-transition-system}
-
-![انتقال حالت اتریوم](./ethereum-state-transition.png)
-
-از نقطه نظر فنی، دفتر کل رمزارزهایی مانند بیتکوین را می توان به عنوان یک سیستم انتقال حالت در نظر گرفت، که در آن یک "حالت" متشکل از وضعیت مالکیت تمام بیتکوین های موجود و یک "تابع انتقال حالت" که یک حالت و یک تراکنش را می گیرد و یک حالت جدید را که نتیجه آن است، خروجی می دهد. به عنوان مثال، در یک سیستم بانکی استاندارد، حالت یک صفحهی موجودی است، تراکنش یک درخواست برای انتقال x ریال از آ به ب، و تابع انتقال حالت از حساب آ مقدار x ریال را کسر میکند و به حساب ب مقدار x ریال را میافزاید. اگر حساب آ از پیش کمتر از $X داشته باشد، تابع انتقال حالت یک خطا بازمیگرداند. سرآخر میتوان به شکل استاندارد تعریف کرد:
-
-
-
-```
-APPLY(S,TX) -> S' or ERROR
-```
-
-
-در سیستم بانکی که بالا تعریف شد:
-
-
-
-```js
-APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
-```
-
-
-اما:
-
-
-
-```js
-APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
-```
-
-
-"وضعیت" در بیت کوین مجموعه ای از تمام کوین ها (از لحاظ فنی، "خروجی های تراکنش خرج نشده" یا UTXO) است که ضرب شده اند و هنوز خرج نشده اند، با هر UTXO دارای یک اسم و یک مالک (که با یک آدرس 20 بایتی تعریف می شود. اساسا یک کلید عمومی رمزنگاری است[fn1](#notes)). یک تراکنش شامل یک یا چند ورودی است که هر ورودی حاوی ارجاع به یک UTXO موجود و یک امضای رمزنگاری شده توسط کلید خصوصی مرتبط با آدرس مالک است و یک یا چند خروجی که هر خروجی حاوی یک UTXO جدید است که باید به آن حالت اضافه شود.
-
-تابع انتقال حالت `APPLY(S,TX) -> S'` را می توان تقریباً به صورت زیر تعریف کرد:
-
-
- -
- برای هر ورودی در
TX
:
-
- -
- اگر UTXOی ارجاعی در
S
نیست، خطا را برگردان.
-
- -
- اگر امضای ارائه شده با صاحب UTXO مطابقت ندارد، خطا را برگردان.
-
-
-
- -
- اگر مجموع نامهای تمام UTXO ورودی کمتر از مجموع نامهای همه UTXO خروجی باشد، خطا را برگردان.
-
- -
-
S
را با حذف تمام ورودی UTXO و اضافه شدن تمام خروجی UTXO برگردان.
-
-
-
-نیمهی اول از گام اول مانع از این میشود که فرستندهها کوینهایی که وجود ندارند را خرج کنند، نیمهی دوم از گام اول مانع از این میشود که فرستندهها کوینهای دیگر افراد را خرج نکنند، و گام دوم فرستنده را مجبور میکند که ارزش را حفظ کند. برای این که از این برای پرداخت استفاده کنیم، پروتکل به شکل زیر است. فرض کنید که آلیس میخواهد ۱۱٬۷ BTC را به باب بفرستد. ابتدا آلیس به دنبال یک مجموعه از UTXO از آنهایی که خود مالک آنهاست میگردد که مجموعشان حداقل ۱۱٬۷ BTC شود. واقعبینانه، آلیس نخواهد توانست که دقیقا ۱۱٬۷ BTC را بیابد؛ فرض کنید کمترین میزانی که آلیس میتواند بسازد ۶+۴+۲=۱۲ باشد. در گام بعدی او یک تراکنش با سه ورودی گفتهشده و دو خروجی میسازد. اولین خروجی ۱۱٬۷ BTC به آدرس باب خواهد بود و دومین خروجی مقدار ۰٬۳ BTC باقیمانده به عنوان «پول خرد»، به آدرس خود آلیس است.
-
-
-
-### استخراج {#mining}
-
-![بلوک های اتریوم](./ethereum-blocks.png)
-
-اگر ما به یک سرویس متمرکز قابل اعتماد دسترسی داشتیم، ساخت این سیستم بدیهی بود و میتوانست دقیقا به صورتی که توصیف شد با استفاده از سختافزار سرور متمرکز برای نگهداری حالتها برنامهنویسی شود. هر چند، با بیتکوین ما میخواهیم یک ارز غیرمتمرکز بسازیم، در نتیجه نیاز داریم که سیستم انتقال حالت را با یکی سیستم اجماع بسازیم که همه بر روی ترتیب تراکنشها توافق داشتهباشند. پروسهی اجماع غیرمتمرکز بیتکوین نیاز به گرههایی در شبکه دارد که به طور مرتب پکیجهایی به نام «بلوک» را بسازند. این شبکه قرار است تقریبا هر ۱۰ دقیقه یک بلوک بسازد که در هر بلوک یک برچسب زمان (Timestamp)، یک نانس و یک ارجاع (هش) به بلاک قبلی و لیستی از همهی تراکنشهایی که از بلوک قبلی تا به حال اتفاق افتادهاند، وجود دارد. در طی زمان، این موضوع یک «زنجیرهی بلوکی» پایدار و رشدکننده میسازد که به طور مرتب بروز میشود تا آخرین حالت دفترکل بیتکوین را نمایش دهد.
-
-الگوریتمی که نشان میدهد یک بلوک معتبر است به صورت زیر توضیح داده میشود:
-
-1. بررسی کنید که آیا بلوک قبلی که توسط بلوک به آن ارجاع داده شده وجود دارد و معتبر است یا خیر.
-2. بررسی کنید که مُهر زمانی بلوک بزرگتر از بلوک قبلی باشد[fn2](#notes) و کمتر از 2 ساعت در آینده باشد
-3. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
-4. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
-5. فرض کن `TX` لیست تراکنشهای بلوک با تعداد `n` تراکنش است. برای همه `i` در `0...n-1`، `S[i+1] = APPLY(S[i], TX[i]) را تنظیم کنید /code> اگر هر برنامه ای خطا را برمیگرداند، از آن خارج شوید و false را برگردانید.
-True را برگردانید و S[n]` را به عنوان وضعیت در انتهای این بلوک ثبت کنید.
-
-در واقع هر تراکنش در بلوک باید یک انتقال حالت معتبر را از حالت قبل از انجام تراکنش به حالت جدید انجام دهد. باید توجه کرد که حالت به هیچ صورتی در بلوک ثبت نمیشود؛ این یک موضوع تماما انتزاعی است برای این که توسط گرههای اعتبارسنج به خاطر سپرده شود و تنها میتوان (به صورت ایمن) با شروع از حالت بلوک پیدایش و حرکت بر روی تراکنشهای هر بلوک، حالت بلوک فعلی را به دست آورد. علاوه بر این، توجه کنید که ترتیبی که استخراجگر تراکنشها را در بلوک ثبت میکند مهم است؛ اگر دو تراکنش آ و ب وجود داشته باشند به طوری که ب یک UTXOی ساختهشده از آ را خرج کند، در این صورت بلوک معتبر است اگر آ قبل از ب ثبت شود و نه برعکس.
-
-شرط صحتی که در دیگر سیستمها دیده نمیشود و در لیست بالا به آن اشاره شد، لازمهی «اثبات کار» است. شرط دقیق به این شکل است که هش double-SHA256 هر بلوک، به عنوان یک عدد ۲۵۶ بیتی، باید کمتر از یک هدف به شکل پویا متغیر باشد، که در زمان نوشتن این مقاله ۲۱۸۷ است. هدف از این امر "سخت کردن" ساخت بلوک از لحاظ محاسباتی و در نتیجه باز داشتن مهاجمان sybil از بازسازی کل زنجیره بلوکی به نفع خودشان است. چون SHA256 طراحی شده تا یک تابع کاملا شبه تصادفی غیرقابل پیشبینی باشد، تنها راه ساخت یک بلوک معتبر صرفا آزمون و خطا، اضافه کردن نانس و دیدن این است که آیا هش جدید تطابق میکند یا خیر.
-
-در هدف کنونی \~۲۱۸۷، شبکه باید به طور میانگین اقدام به \~۲۶۹ آزمون پیش از یافتن یک بلوک معتبر بکند; به طور کلی، هدف به ازای هر ۲۰۱۶ بلوک توسط شبکه بازتنظیم میشود به شکلی که به طور میانگین هر ۱۰ دقیقه یک بلوک جدید توسط یک گره در شبکه تولید شود. به منظور جبران کار ماینرها برای این محاسبات ، استخراجگر هر بلوک حق دارد یک تراکنش را شامل شود که به خودشان 12.5 بیت کوین می دهد. بهعلاوه، اگر هر تراکنشی در ورودیهای خود ارزش کل بالاتری نسبت به خروجیهای خود داشته باشد، تفاوت نیز به عنوان «کارمزد تراکنش» به ماینر میرسد. اتفاقاً این تنها مکانیزمی است که توسط آن BTC صادر می شود. در اول ایجاد این شبکه هیچ سکه ای وجود نداشت.
-
-برای درک بهتر هدف استخراج، اجازه دهید بررسی کنیم که در صورت بروز یک هجوم مخرب چه اتفاقی می افتد. از آنجایی که رمزنگاری زیربنایی بیت کوین امن است، مهاجم قسمتی از سیستم بیت کوین را که مستقیماً توسط رمزنگاری محافظت نمی شود، هدف قرار می دهد: ترتیب تراکنش ها. استراتژی مهاجم ساده است:
-
-1. تعداد 100 بیتکوین را به یک صرافی در ازای مقداری محصول بفرستید (ترجیحاً کالای دیجیتالی با تحویل سریع)
-2. منتظر تحویل محصول میماند
-3. یک تراکنش دیگر ایجاد کرده و همان 100 بیت کوین را برای خودش ارسال میکند
-4. سعی کنید شبکه را متقاعد کنید که تراکنش او با خودش اولین معامله بوده است.
-
-هنگامی که مرحله (1) انجام شد، پس از چند دقیقه برخی از ماینرها تراکنش را در یک بلوک، مثلاً بلوک شماره 270000، وارد می کنند. بعد از حدود یک ساعت، پنج بلوک دیگر به زنجیره پس از آن بلوک، اضافه میشود که هر کدام از این بلوک ها به طور غیر مستقیم به تراکنش اشاره کرده و بنابراین آن را تایید میکنند. در این نقطه، تاجر پرداخت را نهایی تلقی میکند و محصول را تحویل میدهد. همچنان که فرض کردیم این کالا دیجیتال است و تحویل آن فوری است. حال مهاجم تراکنش دیگری را ایجاد میکند و 100 بیت کوین را به خودش ارسال میکند. اگر مهاجم به سادگی آن را رها کند، تراکنش پردازش نخواهد شد. استخراج کنندگان تلاش میکنند که `APPLY(S, TX)` را اعمال کنند و متوجه میشوند که `TX` یک UTXO را مصرف میکند که دیگر در آن حالت نیست. بنابراین در عوض آن، مهاجم یک انشعاب (فورک) از زنجیره بلوکی را ایجاد میکند که با استخراج نسخه دیگری از بلوک 270 شروع میشود که به همان بلوک 269، به عنوان بلوک مادر اشاره میکند، اما با معرفی تراکنش جدید در جای تراکنش قدیمی. از آنجا که داده های بلوک متفاوت است، این مستلزم انجام مجدد اثبات کار است. علاوه بر این، نسخه جدید بلوک 270 مهاجم دارای هش متفاوتی است، بنابراین بلوک های اصلی 271 تا 275 به آن اشاره نمی کنند. بنابراین، زنجیره اصلی و زنجیره جدید مهاجم کاملاً جدا هستند. قانون این است که در یک فورک طولانیترین زنجیره بلوکی حقیقی در نظر گرفته میشود، و بنابراین ماینرهای قانونی روی زنجیره ۲۷۵ کار میکنند در حالی که مهاجم به تنهایی روی زنجیره ۲۷۰ کار میکند. برای اینکه مهاجم بتواند زنجیره بلوکی خود را تبدیل به طولانیترین رنجیره کند، باید قدرت محاسباتی بیشتری نسبت به مجموع سایر شبکهها داشته باشد تا بتواند به آنها برسد (یعنی، "حمله 51٪").
-
-
-
-### درختان Merkle {#merkle-trees}
-
-![SPV در بیتکوین](./spv-bitcoin.png)
-
-_طرف چپ: کافی است که فقط تعداد کمی از گره ها را در یک درخت Merkle ارائه داد تا اثبات اعتبار شاخه ایجاد شود._
-
-_طرف راست: هر تلاشی برای تغییر هر بخشی از درخت Merkle سرانجام منجر به عدم سازگاری در جایی در بالای زنجیره میشود._
-
-یک ویژگی مقیاس پذیری مهم بیت کوین این است که بلوک مورد نظر در یک ساختار دادهی چند لایه ذخیره میشود. هش یک بلوک در واقع تنها هش بلوک اصلی است، تقریبا 200 بایت اطالعات شامل ثبت زمان، نانس، هش بلوک قبلی و هش ریشه ساختار داده که درخت Merkle نامیده میشود و همه تراکنش ها را در بلوک ذخیره میکند. درخت Merkle نوعی درخت باینری است که متشکل از مجموعه ای گره است که همراه با تعداد زیادی گره برگی در پایین درخت میباشد که شامل داده های زیربنایی میشوند. یک مجموعه از گره های میانجی هم هستند که هر کدام از آنها هش دو بچه خود میباشند و بخش بالایی درخت را ارائه میدهند. مقصود از درخت Merkle، مجوز دادن به داده های یک بلوک برای تحویل تدریجی است. یک گره از یک منبع، فقط هدر (header) بلوک را دانلود میکند. بخش کوچک درخت از طریق منبع دیگری به آنها مربوط میشود و با این وجود اطمینان حاصل میشود که همه داده ها صحیح هستند. دلیل این کار این است که هش ها به سمت بالا منتشر می شوند: اگر یک کاربر بداندیش تلاش کند که در یک تراکنش جعلی به پایین درخت Merkle تغییر وضعیت دهد، این تغییر منجر به تغییر در گره بالا میشود و سپس تغییر در گره بالاتر آن و سرانجام ریشه درخت را تغییر میدهد و بنابراین هش بلوک، سبب میشود که پروتکل آن را به عنوان یک بلوک کامل متفاوت ثبت کند (با احتمال قریب به یقین به عنوان یک اثبات کار غیر معتبر).
-
-پروتکل درخت Merkle به طور قابل دفاعی در ماندگاری دراز مدت نقش اساسی دارد. یک گره کامل در شبکه بیت کوین، گره ای است که کلیت یک بلوک را ذخیره و پردازش میکند و حدود 15 گیگابایت از فضای دیسک شبکه بیت کوین را در آپریل 2014 اشغال میکرد و هر ماه حدود یک گیگابایت به این مقدار اضافه میشد. در حال حاضر، این برای برخی از رایانههای دسکتاپ و نه تلفنها قابل اجرا است و بعداً در آینده فقط مشاغل و علاقهمندان میتوانند در آن شرکت کنند. پروتکلی به نام "تأیید پرداخت ساده" (SPV) اجازه می دهد تا کلاس دیگری از گره ها به نام "گره های سبک" وجود داشته باشد که هدرهای بلوک را دانلود می کنند، اثبات کار روی هدرهای بلوک را تأیید می کنند و سپس فقط "شاخه ها"ی مرتبط با تراکنش هایی که به آنها مربوط است را دانلود می کنند. این به گرههای سبک اجازه میدهد تا با ضمانت امنیتی قوی، وضعیت هر تراکنش بیتکوین و موجودی فعلی آنها را تعیین کنند، در حالی که تنها بخش بسیار کوچکی از کل زنجیره بلوکی را دانلود میکنند.
-
-
-
-### کاربردهای جایگزین زنجیره بلوکی {#alternative-blockchain-applications}
-
-ایده گرفتن ایده اصلی زنجیره بلوکی و اعمال آن در مفاهیم دیگر نیز سابقه طولانی دارد. در سال 2005، نیک زابو به مفهوم [عناوین ملکی ایمن با اختیار مالک](https://nakamotoinstitute.org/secure-property-titles/)، سندی که چگونگی "پیشرفت های جدید در فناوری پایگاه داده تکراری" را توضیح می دهد اشاره کرد. یک سیستم مبتنی بر بلاکچین برای ذخیره یک رجیستری از اینکه چه کسی امکانپذیر است که مالک چه زمینی است و یک چارچوب مفصل از جمله مفاهیمی از این قبیل ایجاد می کند به عنوان خانه داری، مالکیت نامناسب و مالیات زمین میلادی ایجاد می کند. با این حال، متأسفانه هیچ سیستم پایگاه داده تکثیر شده مؤثری در آن زمان موجود نبود، و بنابراین این پروتکل هرگز در عمل اجرا نشد. با این حال، پس از سال 2009، هنگامی که اجماع غیرمتمرکز بیت کوین توسعه یافت، تعدادی از برنامه های کاربردی جایگزین به سرعت شروع به ظهور کردند.
-
-- **Namecoin** - ایجاد شده در سال 2010، [Namecoin](https://namecoin.org/) به بهترین وجه به عنوان یک پایگاه داده ثبت نام غیرمتمرکز توصیف می شود. در پروتکل های غیرمتمرکز مانند Tor، Bitcoin و BitMessage، باید راهی برای شناسایی حساب ها وجود داشته باشد تا افراد دیگر بتوانند با آنها تعامل داشته باشند، اما در همه راه حل های موجود، تنها نوع شناسه موجود یک هش شبه تصادفی مانند `1LW79wp5ZBqaHW1jL5TCiBCrhWQYHagUt` است. در حالت ایده آل، شخصی ممکن است دوست داشته باشد که بتواند یک حساب کاربری با نامی مانند "جورج" داشته باشد. با این حال، مشکل این است که اگر یک نفر بتواند یک حساب کاربری به نام "جورج" ایجاد کند، شخص دیگری نیز می تواند از همین فرآیند برای ثبت "جورج" برای خود و جعل هویت آنها استفاده کند. تنها راه حل یک پارادایم اول به فایل است که در آن ثبت کننده اول موفق می شود و دومی شکست می خورد - مشکلی که کاملاً برای پروتکل اجماع بیتکوین متناسب است. Namecoin قدیمی ترین و موفق ترین مدل پیاده سازی شده سیستم ثبت نام با استفاده از چنین ایده ای است.
-- **سکه های رنگی** - هدف [سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) این است که به عنوان پروتکلی عمل کند تا به مردم اجازه دهد رمزارزهای خود را ایجاد کنند - یا در مورد مهم پیش پا افتاده ارز با یک واحد، توکن های دیجیتال، در بلاکچین بیت کوین. در پروتکل کوینهای رنگی، یک ارز جدید با اختصاص دادن یک رنگ به یک بیت کوین UTXO خاص به صورت عمومی یک ارز جدید صادر میکند و پروتکل به صورت بازگشتی رنگ سایر UTXOها را با رنگ ورودیهایی که تراکنش ایجاد میکند، مشخص میکند. (برخی قوانین خاص در مورد ورودیهای رنگی مخلوط اعمال میشود). این مورد به کاربران اجازه میدهد تا کیف پولهایی را که فقط حاوی UTXO با یک رنگ خاص هستند نگهداری کنند و آنها را مانند بیتکوینهای معمولی به اطراف بفرستند و از طریق بلاکچین به عقب برگردند تا رنگ هر UTXO دریافتی را تعیین کنند.
-- **Metacoins** - ایده پشت متاکوین داشتن پروتکلی است که بر روی بستر بیتکوین زندگی می کند، از تراکنش های بیتکوین برای ذخیره تراکنش های متاکوین استفاده می کند، اما دارای یک تابع انتقال حالت متفاوت یعنی `APPLY'` است،. از آنجایی که پروتکل متاکوین نمی تواند از نمایش تراکنش های متاکوین نامعتبر در بلاکچین بیتکوین جلوگیری کند، قانونی اضافه می شود که اگر `APPLY'(S,TX)` خطایی را برگرداند، پروتکل به طور پیش فرض به `APPLY'( S,TX) = S` بر می گردد. این مورد یک مکانیسم آسان برای ایجاد یک پروتکل ارز دیجیتال دلخواه، با ویژگیهای پیشرفته است که نمیتواند در داخل بیتکوین با هزینه توسعه بسیار پایین پیادهسازی شود، زیرا پیچیدگیهای استخراج و شبکهسازی قبلاً توسط پروتکل بیتکوین مدیریت میشود. متاکوینها برای اجرای برخی از کلاسهای قراردادهای مالی، ثبت نام و مبادلات غیرمتمرکز استفاده شدهاند.
-
-بنابراین، به طور کلی، دو رویکرد برای ایجاد یک پروتکل اجماع وجود دارد: ایجاد یک شبکه مستقل، و ساخت یک پروتکل در بالای بیت کوین. رویکرد قبلی، اگرچه در مورد برنامههایی مانند Namecoin به طور معقولی موفق بود، اما پیادهسازی آن دشوار است. هر پیادهسازی جداگانه نیاز به راهاندازی یک زنجیره بلوکی مستقل و همچنین ساخت و آزمایش تمام انتقال وضعیت و کد شبکه دارد. علاوه بر این، ما پیشبینی میکنیم که مجموعه برنامههای کاربردی برای فناوری اجماع غیرمتمرکز از یک توزیع قانون قدرت پیروی میکنند که در آن اکثریت قریب به اتفاق برنامهها برای تضمین زنجیره بلوکی خود بسیار کوچک هستند، و توجه داریم که کلاسهای بزرگی از برنامههای غیرمتمرکز، بهویژه مستقل غیرمتمرکز وجود دارد، سازمان هایی که نیاز به تعامل با یکدیگر دارند.
-
-از سوی دیگر، رویکرد مبتنی بر بیتکوین دارای این نقص است که ویژگیهای تأیید پرداخت ساده بیتکوین را به ارث نمیبرد. SPV برای بیت کوین کار می کند زیرا می تواند از عمق بلاک چین به عنوان یک پروکسی برای اعتبار استفاده کند. زمانی که پیشینههای یک تراکنش به اندازه کافی به عقب بروند، می توان با اطمینان گفت که آنها به طور قانونی بخشی از وضعیت بودند. از سوی دیگر، فراپروتکلهای مبتنی بر زنجیرهی بلوکی نمیتوانند زنجیرهی بلوکی را مجبور کنند که تراکنشهایی را که در چارچوب پروتکلهای خود معتبر نیستند، در بر نگیرد. از این رو، اجرای فراپروتکل SPV کاملاً ایمن باید تا ابتدای زنجیرهی بلوکی بیت کوین را به عقب اسکن کند تا مشخص شود که آیا تراکنش های خاصی معتبر هستند یا خیر. در حال حاضر، تمام پیادهسازیهای «سبک» فراپروتکلهای مبتنی بر بیتکوین برای ارائهی دادهها به یک سرور قابل اعتماد متکی هستند، که مسلماً نتیجهای بسیار نابهینه است، بهویژه زمانی که یکی از اهداف اصلی یک ارز دیجیتال حذف نیاز به اعتماد باشد.
-
-
-
-### اسکریپت نویسی {#scripting}
-
-درواقع پروتکل بیت کوین حتی بدون هیچ گونه افزونهای، نسخه ضعیفی از قرارداد های هوشمند را تسهیل میکند. UTXO در بیت کوین فقط با یک کلید عمومی مالکیت پیدا نمیکند، بلکه همچنین اسکریپت پیچیده تری در زبان برنامه نویسی بر پایهی پشتهی ساده ابراز میشود. در این الگو، تراکنشی که آن UTXO را خرج میکند، باید داده هایی را فراهم کند که اسکریپت را قانع کند. در واقع حتی مکانیزم مالکیت کلید عمومی اصلی، از طریق یک اسکریپت پیاده میشود. این اسکریپت یک امضای منحنی بیضوی را به عنوان ورودی اعمال میکند که آن را در برابر تراکنش و آدرسی که مالک UTXO است، تایید میکند و اگر تایید موفق باشد، 1 و در غیر این صورت 0 ارجاع داده میشود. اسکریپت های پیچیدهتر دیگری برای موارد استفاده اضافی متعددی موجود هستند. به عنوان مثال فرد میتواند اسکریپتی بسازد که نیازمند امضاهایی شامل دو از سه کلید خصوصی باشد تا اعتبارسنجی انجام شود. (multisig) این چیدمان برای اکانت های سازمانی، اکانت های پس انداز ایمن و موقعیت های شخص ثالث بازرگان، مفید است. اسکریپت ها همچنین میتوانند برای پرداخت جایزه هایی که برای راه حل های محاسباتی داده میشوند، استفاده شوند و فرد میتواند حتی اسکریپتی بسازد که چیزی مانند این که UTXO بیت کوین متعلق به چه کسی است، نشان داده شود. اگر بتوان یک مدرک SPV فراهم کرد که فرد یک تراکنش دوجکوین را فرستاده است، در اساس این امر مجوز یک تراکنش متقابل غیر متمرکز رمزارز را میدهد.
-
-اما زبان اسکریپت، آنچنان که در بیت کوین پیاده شده، محدودیت های مهمی هم دارد:
-
-- **عدم کامل بودن تورینگ** - یعنی در حالی که زیرمجموعه بزرگی از محاسبات وجود دارد که زبان برنامه نویسی بیتکوین از آن پشتیبانی می کند، تقریباً همه چیز را پشتیبانی نمی کند. دسته اصلی که گم شده است حلقه ها هستند. این کار برای جلوگیری از حلقه های بی نهایت در حین تأیید تراکنش انجام می شود. از نظر تئوری، این یک مانع قابل عبور برای برنامه نویسان اسکریپت است، زیرا هر حلقه را می توان با تکرار چندین بار کد اصلی با یک دستور if شبیه سازی کرد، اما منجر به اسکریپت هایی می شود که بسیار کم فضا هستند. به عنوان مثال، اجرای یک الگوریتم امضای منحنی بیضوی جایگزین احتمالاً به 256 دور ضرب مکرر نیاز دارد که همه به صورت جداگانه در کد گنجانده شده است.
-- **کوری مقدار** - هیچ راهی برای اسکریپت UTXO وجود ندارد که بتواند کنترل دقیقی بر مقدار قابل برداشت ارائه دهد. به عنوان مثال، یکی از موارد استفاده قدرتمند از یک قرارداد اوراکل، قرارداد پوشش ریسک است، که در آن A و B مقدار 1000 دلار بیتوین وارد می کنند و پس از 30 روز، اسکریپت 1000 دلار بیتکوین را به A و بقیه را به B ارسال می کند. اوراکل برای تعیین ارزش 1 بیتکوین به دلار آمریکا، اما حتی در آن زمان نیز از نظر اعتماد و نیاز به زیرساخت نسبت به راه حل های کاملاً متمرکزی که در حال حاضر در دسترس هستند، یک پیشرفت عظیم است. با این حال، از آنجایی که UTXO همه یا هیچ هستند، تنها راه برای دستیابی به این هدف از طریق هک بسیار ناکارآمد داشتن تعداد زیادی UTXO با ارزشهای مختلف است (مثلاً یک UTXO از 2k برای هر k تا 30) و اوراکل انتخاب کنید که کدام UTXO به A و کدام به B ارسال شود.
-- **عدم وضعیت** - UTXO می تواند خرج شود یا خرج نشده باشد. هیچ فرصتی برای قراردادها یا قراردادهای چند امضایی وجود ندارد که هر حالت داخلی دیگری را فراتر از آن حفظ کند. این امر بستن قراردادهای گزینههای چند مرحلهای، پیشنهادها مبادله غیرمتمرکز یا پروتکلهای تعهد رمزنگاری دو مرحلهای (ضروری برای پاداشهای محاسباتی ایمن) را دشوار میکند. همچنین به این معنی است که UTXO فقط میتواند برای ایجاد قراردادهای ساده و یکبار استفاده شود و نه قراردادهای پیچیدهتر مانند سازمانهای غیرمتمرکز، و اجرای فراپروتکلها را دشوار میکند. حالت دودویی همراه با ارزش کوری همچنین به این معنی است که یک برنامه مهم دیگر، محدودیتهای برداشت، غیرممکن است.
-- **کوری بلاکچین** - UTXO نسبت به داده هایبلاک چین مانند نانس، مهر زمانی و هش بلوک قبلی کور است. این امر با محروم کردن زبان برنامهنویسی از منبع بالقوه با ارزش تصادفی، برنامههای کاربردی در قمار و چندین دسته دیگر را به شدت محدود میکند.
-
-بنابراین، ما سه رویکرد برای ایجاد برنامه های کاربردی پیشرفته در بالای آن می بینیم ارز دیجیتال: ساخت یک بلاکچین جدید، استفاده از اسکریپت در بالای بیت کوین و ساخت یک فرا پروتکل در بالای بیت کوین. ساخت یک زنجیرهی بلوکی جدید آزادی نامحدودی را در ساخت مجموعه ویژگیها امکانپذیر میکند، اما به قیمت زمان توسعه، تلاش و امنیت راهاندازی. استفاده از اسکریپت برای پیادهسازی و استانداردسازی آسان است، اما در قابلیت های آن بسیار محدود است و فرا پروتکل ها، در عین سادگی، از اشکالاتی در مقیاس پذیری رنج می برند. با اتریوم، ما قصد داریم یک چارچوب جایگزین بسازیم که دستاوردهای بزرگتری را در سهولت توسعه و همچنین ویژگیهای کلاینت سبک حتی قویتر فراهم میکند و در عین حال به برنامهها اجازه میدهد محیط اقتصادی و امنیت زنجیرهی بلوکی را به اشتراک بگذارند.
-
-
-
-## اتریوم {#ethereum}
-
-هدف اتریوم ایجاد یک پروتکل جایگزین برای ساخت برنامههای غیرمتمرکز است که مجموعهای متفاوت از معاوضهها را ارائه میکند که معتقدیم برای کلاس بزرگی از برنامههای غیرمتمرکز بسیار مفید خواهد بود، با تاکید ویژه بر موقعیتهایی که زمان توسعه سریع، امنیت برای کوچک و برنامههایی که به ندرت استفاده میشوند و توانایی برنامههای مختلف برای تعامل بسیار کارآمد، مهم هستند. اتریوم این کار را با ساختن لایه اساسی انتزاعی نهایی انجام می دهد: یک بلاک چین با زبان برنامه نویسی داخلی کامل تورینگ، که به هر کسی اجازه می دهد قراردادهای هوشمند و برنامه های غیرمتمرکز بنویسد که در آن می توانند قوانین دلخواه خود را برای مالکیت، فرمت های تراکنش و توابع انتقال حالت ایجاد کنند. توابع انتقال حالت یک نسخه بدون استخوان Namecoin را می توان در دو خط کد نوشت و سایر پروتکل ها مانند ارزها و سیستم های شهرت را می توان در کمتر از بیست خط ایجاد کرد. قراردادهای هوشمند، "جعبه های" رمزنگاری که حاوی مقدار باشد و فقط در صورت رعایت شرایط خاص، می تواند قفل آن را باز کند در بالای پلت فرم ساخته شود، با قدرت بسیار بیشتر از آن ارائه شده توسط اسکریپت بیت کوین به دلیل قدرت های اضافه شده تورینگ-کامل بودن، آگاهی از ارزش، آگاهی از بلاک چین و وضعیت.
-
-
-
-### حساب های اتریوم {#ethereum-accounts}
-
-در اتریوم، حالت از اشیایی به نام «حسابها» تشکیل میشود که هر حساب دارای یک آدرس 20 بایتی است و انتقال حالت، انتقال مستقیم ارزش و اطلاعات بین حسابها است. یک حساب اتریوم شامل چهار فیلد است:
-
-- **نانس**، یک شمارنده برای اطمینان از اینکه هر تراکنش فقط یک بار قابل پردازش است استفاده می شود
-- میزان اتریوم فعلی موجود در کیف پول
-- **کد قرارداد** کیف پول، در صورت موجود بودن
-- **فضای ذخیرهسازی** حساب (به طور پیش فرض خالی است)
-
-"اتر" اصلی ترین سوخت رمزارزی داخلی اتریوم است و برای پرداخت هزینه تراکنش استفاده می شود. به طور کلی، دو نوع حساب وجود دارد: **حسابهای متعلق به خارجی** که توسط کلیدهای خصوصی کنترل میشوند، و **حسابهای قرارداد** که توسط کد قرارداد آنها کنترل میشود. یک حساب دارای مالکیت خارجی هیچ کدی ندارد و می توان با ایجاد و امضای یک تراکنش، از یک حساب دارای مالکیت خارجی پیام ارسال کرد. در یک حساب قراردادی، هر بار که حساب قرارداد پیامی دریافت میکند، کد آن فعال میشود و به آن اجازه میدهد در حافظه داخلی بخواند و بنویسد و پیامهای دیگری ارسال کند یا به نوبه خود قرارداد ایجاد کند.
-
-توجه داشته باشید که "قراردادها" در اتریوم نباید به عنوان چیزی که باید "پر شده" یا "منطبق با" تلقی شود. در عوض، آنها بیشتر شبیه «عاملهای مستقل» هستند که در محیط اجرای اتریوم زندگی میکنند، همیشه یک قطعه کد خاص را هنگام «صدا زدن» توسط یک پیام یا تراکنش اجرا میکنند و کنترل مستقیم بر تعادل اتر خود و ذخیره کلید/مقدار خود برای پیگیری متغیرهای پایدار دارند.
-
-
-
-### پیغام ها و تراکنش ها {#messages-and-transactions}
-
-واژه "تراکنش" در اتریوم برای اشاره به بسته داده امضا شده ای استفاده می شود که پیغامی را ذخیره می کند تا از یک حساب مالکیت خارجی ارسال شود. معاملات شامل:
-
-- گیرنده پیام
-- امضایی برای شناسایی فرستنده
-- مقدار اتر برای انتقال از فرستنده به گیرنده
-- یک فیلد داده اختیاری
-- یک مقدار `STARTGAS`، نشان دهنده حداکثر تعداد مراحل محاسباتی است که اجرای تراکنش مجاز به انجام آن است
-- مقدار `GASPRICE`، نشان دهنده هزینه ای است که فرستنده در هر مرحله محاسباتی می پردازد
-
-سه مورد اول، فیلدهای استاندارد مورد انتظار در هر ارز دیجیتال هستند. فیلد داده به طور پیش فرض عملکردی ندارد، اما ماشین مجازی دارای یک کد عملیاتی است که با استفاده از آن قرارداد می تواند به داده ها دسترسی داشته باشد. به عنوان مثال، اگر قراردادی به عنوان یک سرویس ثبت دامنه روی بلاکچین عمل می کند، ممکن است بخواهد داده های ارسال شده به آن را به عنوان حاوی دو "فیلد" تفسیر کند. فیلد اول دامنه ای برای ثبت نام و فیلد دوم آدرس IP برای ثبت آن است. قرارداد این مقادیر را از داده های پیام خوانده و به طور مناسب آنها را در فضای ذخیرهسازی قرار می دهد.
-
-فیلدهای `STARTGAS` و `GASPRICE` برای مدل ضد انکار خدمات اتریوم بسیار مهم هستند. به منظور جلوگیری از حلقههای نامحدود تصادفی یا متخاصم یا سایر اتلافهای محاسباتی در کد، هر تراکنش باید محدودیتی برای تعداد مراحل محاسباتی اجرای کد تعیین کند. واحد اساسی محاسبات "گس" است. معمولاً، یک مرحله محاسباتی 1 گس هزینه دارد، اما برخی از عملیات ها به دلیل اینکه از نظر محاسباتی گرانتر هستند یا مقدار داده هایی را که باید به عنوان بخشی از حالت ذخیره شوند افزایش می دهند، مقدار گس بیشتری را هزینه می کنند. همچنین برای هر بایت در داده های تراکنش 5 گس کارمزد دریافت می شود. هدف سیستم کارمزد این است که از مهاجم بخواهد به ازای هر منبعی که مصرف میکند، از جمله محاسبات، پهنای باند و ذخیرهسازی، به نسبت هزینه پرداخت کند. از این رو، هر تراکنشی که منجر به مصرف شبکه مقدار بیشتری از هر یک از این منابع شود، باید هزینه گس تقریباً متناسب با افزایش داشته باشد.
-
-
-
-### پیامها {#messages}
-
-قراردادها قابلیت ارسال «پیام» به سایر قراردادها را دارند. پیام ها اشیای مجازی هستند که هرگز سریالی نمی شوند و فقط در محیط اجرای اتریوم وجود دارند. یک پیام شامل موارد زیر است:
-
-- فرستنده پیام (ضمنی)
-- گیرنده پیام
-- مقدار اتر برای انتقال در کنار پیام
-- یک فیلد داده اختیاری
-- یک مقدار `STARTGAS`
-
-اساساً یک پیام مانند یک معامله است، با این تفاوت که توسط یک قرارداد تولید می شود نه یک عامل خارجی. یک پیام زمانی تولید می شود که قراردادی که در حال حاضر کد را اجرا می کند، اپکد `CALL` را اجرا می کند، که پیامی را تولید و اجرا می کند. مانند یک تراکنش، یک پیام به حساب گیرنده منتهی می شود که کد آن را اجرا می کند. بنابراین، قراردادها می توانند دقیقاً به همان شکلی که بازیگران خارجی می توانند با سایر قراردادها رابطه داشته باشند.
-
-توجه داشته باشید که کمک هزینه گس تعیین شده توسط یک معامله یا قرارداد برای کل گس مصرف شده توسط آن معامله و کلیه اجراهای فرعی اعمال می شود. به عنوان مثال، اگر یک بازیگر خارجی A یک تراکنش را با 1000 گس به B ارسال کند، و B قبل از ارسال پیام به C، مقدار 600 گس مصرف کند، و اجرای داخلی C قبل از بازگشت، 300 گس مصرف کند، B می تواند قبل از تمام شدن گس 100 گس دیگر خرج کند.
-
-
-
-### تابع انتقال حالت اتریوم {#ethereum-state-transition-function}
-
-![انتقال حالت اتر](./ether-state-transition.png)
-
-تابع انتقال حالت اتریوم، `APPLY(S,TX) -> S'` را می توان به صورت زیر تعریف کرد:
-
-1. بررسی کنید که آیا تراکنش به خوبی شکل گرفته است (یعنی تعداد مقادیر مناسبی دارد)، امضا معتبر است، و نانس با نانس در حساب فرستنده مطابقت دارد. اگر اینطور نیست، یک خطا بازگردان.
-2. کارمزد تراکنش را به صورت `STARTGAS * GASPRICE` محاسبه کنید و آدرس ارسال را از روی امضا تعیین کنید. کارمزد را از موجودی حساب فرستنده کم کنید و نانس فرستنده را افزایش دهید. اگر موجودی کافی برای خرج کردن وجود ندارد، یک خطا را برگردان.
-3. `GAS = STARTGAS` را راهاندازی کنید و مقدار مشخصی گس را در هر بایت بردارید تا هزینه بایتهای موجود در تراکنش را بپردازید.
-4. انتقال ارزش تراکنش از حساب فرستنده به حساب دریافت کننده. اگر حساب دریافت کننده هنوز وجود ندارد، آن را ایجاد کنید. اگر اکانت دریافت کننده قراردادی است، کد قرارداد را تا پایان یا تا زمانی که گس موجود است اجرا کن.
-5. اگر انتقال ارزش به دلیل نداشتن پول کافی فرستنده انجام نشد، یا بنزین اجرای کد تمام شد، همه تغییرات حالت به جز پرداخت هزینه ها را برگردان و هزینه ها را به حساب ماینر اضافه کن.
-6. در غیر این صورت، هزینه تمام گس باقیمانده را به فرستنده بازپرداخت کن و هزینه های پرداخت شده برای گس مصرف شده را برای ماینر ارسال کن.
-
-به عنوان مثال، فرض کنید که کد قرارداد این است:
-
-
-
-```py
-if !self.storage[calldataload(0)]:
- self.storage[calldataload(0)] = calldataload(32)
-```
-
-
-توجه داشته باشید که در واقع کد قرارداد در کد EVM سطح پایین نوشته شده است. این مثال برای وضوح در Serpent، یکی از زبان های سطح بالای ما، نوشته شده است و می توان آن را به کد EVM کامپایل کرد. فرض کنید ذخیرهسازی قرارداد خالی شروع میشود و تراکنشی با 10 مقدار اتر، 2000 گس، 0.001 اتر قیمت گس و 64 بایت داده ارسال میشود، با بایتهای 0-31 نشان دهنده عدد `2` و بایت است. 32-63 نشان دهنده رشته `CHARLIE` است. فرآیند تابع انتقال حالت در این مورد به شرح زیر است:
-
-1. بررسی کنید که تراکنش معتبر و به خوبی شکل گرفته است.
-2. بررسی کنید که فرستنده تراکنش حداقل 2000 \* 0.001 = 2 اتر داشته باشد. اگر اینطور است، 2 اتر از حساب فرستنده کم کنید.
-3. گس اولیه = 2000; با فرض اینکه تراکنش 170 بایت و هزینه بایت 5 باشد، 850 را کم کنید تا 1150 گس باقی بماند.
-4. مقدار 10 اتر دیگر از حساب فرستنده کم کنید و آن را به حساب قرارداد اضافه کنید.
-5. کد را اجرا کنید. `GAS = STARTGAS` را راهاندازی کنید و مقدار مشخصی از گس را در هر بایت برداشت تا هزینه بایتهای موجود در تراکنش را بپردازید. فرض کنید این 187 گس می گیرد، بنابراین مقدار گس باقیمانده 1150 - 187 = 963 است
-6. 963 \* 0.001 = 0.963 اتر را دوباره به حساب فرستنده اضافه کنید و حالت حاصل را برگردانید.
-
-اگر قراردادی در پایان تراکنش وجود نداشت، کل کارمزد تراکنش به سادگی برابر با `GASPRICE` ارائه شده ضرب در طول تراکنش بر حسب بایت و داده های ارسال شده در کنار تراکنش بی ربط خواهد بود.
-
-توجه داشته باشید که پیامها از نظر بازگردانیها مانند تراکنشها کار میکنند: اگر گس اجرای پیام تمام شود، اجرای آن پیام و همه اجرایهای دیگر که توسط آن اجرا آغاز میشوند، برمیگردند، اما اجرای والد نیازی به برگرداندن ندارد. این بدان معناست که برای قراردادی "ایمن" است که قرارداد دیگری را فراخوانی کند، زیرا اگر A با گس G برود B را صدا کند، اجرای A تضمین شده است که حداکثر گس G را از دست می دهد. در نهایت، توجه داشته باشید که یک opcode وجود دارد، `CREATE`، که یک قرارداد ایجاد می کند. مکانیک اجرای آن به طور کلی شبیه `CALL` است، با این استثنا که خروجی اجرا کد یک قرارداد جدیدآً ایجاد شده را تعیین می کند.
-
-
-
-### اجرای کد {#code-execution}
-
-کد در قراردادهای اتریوم به زبان بایت کد مبتنی بر پشته، سطح پایین نوشته می شود که به آن «کد ماشین مجازی اتریوم» یا «کد EVM» گفته می شود. کد شامل یک سری بایت است که هر بایت نشان دهنده یک عملیات است. به طور کلی، اجرای کد یک حلقه بی نهایت است که شامل انجام مکرر عملیات در شمارنده برنامه فعلی (که از صفر شروع می شود) و سپس افزایش شمارنده برنامه به یک اندازه، تا رسیدن به انتهای کد یا یک خطا یا < دستورالعمل 0>STOP
یا `RETURN` شناسایی شد. عملیات به سه نوع فضای ذخیرهسازی دادهها دسترسی دارند:
-
-- این **پشته**، محفظهای که میتوان آنها را به بیرون فرستاد و مقادیر را به آن منتقل کرد
-- **Memory**، یک آرایه بایت بی نهایت قابل گسترش است
-- **ذخیره** طولانی مدت قرارداد، یک ذخیره از کلید/ارزش. برخلاف پشته و حافظه که پس از پایان محاسبات بازنشانی میشوند، ذخیرهسازی برای طولانی مدت باقی میماند.
-
-این کد همچنین میتواند به مقدار، فرستنده و دادههای پیام دریافتی و همچنین دادههای هدر بلوک دسترسی داشته باشد و کد همچنین میتواند یک آرایه بایتی از دادهها را به عنوان خروجی برگرداند.
-
-مدل اجرای رسمی کد EVM به طرز شگفت آوری ساده است. در حالی که ماشین مجازی اتریوم در حال اجرا است، حالت محاسباتی کامل آن را میتوان با چند `(block_state، تراکنش، پیام، کد، حافظه، پشته، کامپیوتر، گس)` تعریف کرد، جایی که `block_state 0> حالت جهانی است که شامل تمام حساب ها و شامل موجودی ها و ذخیرهسازی است. در شروع هر دور اجرا، دستورالعمل فعلی با گرفتن pc`امین بایت `کد` (یا 0 اگر `pc >= len(code)`)، و هر دستورالعمل از نظر نحوه تأثیرگذاری بر تاپل، تعریف خاص خود را دارد. برای مثال، `ADD` دو مورد را از پشته بیرون میآورد و مجموع آنها را فشار میدهد، `گس` را به 1 کاهش میدهد و `pc` را به 1 افزایش میدهد و ` SSTORE` دو مورد بالا را از پشته بیرون میآورد و مورد دوم را در فهرستی که مورد اول مشخص کرده است در محل ذخیره قرارداد قرار میدهد. اگرچه راههای زیادی برای بهینهسازی اجرای ماشین مجازی اتریوم از طریق کامپایلسازی بهموقع وجود دارد، پیادهسازی اولیه اتریوم را میتوان در چند صد خط کد انجام داد.
-
-
-
-### بلاکچین و ماینینگ {#blockchain-and-mining}
-
-![بلوک دیاگرام اتریوم اعمال میشود](./ethereum-apply-block-diagram.png)
-
-بلاکچین اتریوم از بسیاری جهات شبیه بلاکچین بیتکوین است، اگرچه تفاوتهایی نیز دارد. تفاوت اصلی بین اتریوم و بیتکوین در معماری بلاکچین این است که بر خلاف بیتکوین، بلاکهای اتریوم شامل یک کپی از لیست تراکنشها و آخرین وضعیت هستند. به غیر از آن، دو مقدار دیگر، شماره بلوک و سختی نیز در بلوک ذخیره میشوند. الگوریتم اصلی اعتبارسنجی بلوک در اتریوم به شرح زیر است:
-
-1. بررسی کنید که آیا بلوک قبلی ارجاع شده وجود دارد و معتبر است.
-2. بررسی کنید که مهر زمانی بلوک بزرگتر از بلوک قبلی ارجاع شده و کمتر از 15 دقیقه در آینده باشد
-3. بررسی کنید که شماره بلوک، سختی، ریشه تراکنش، ریشه عمو و محدودیت گس (مفاهیم مختلف سطح پایین ویژه اتریوم) معتبر هستند.
-4. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
-5. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
-6. اجازه دهید `TX` لیست تراکنش بلوک با `n` تراکنش باشد. برای همه `iها` در `0...n-1`، `S[i+1] = APPLY(S[i],TX[i]) را تنظیم کنید /0>. اگر هر برنامهای خطایی را برمیگرداند، یا اگر کل گس مصرفشده در بلوک تا این نقطه از GASLIMIT` بیشتر شود، یک خطا را برگردانید.
-7. بگذارید `S_FINAL` `S[n]` باشد، اما پاداش بلوک پرداختی به ماینر را اضافه کنید.
-8. بررسی کنید که آیا ریشه درخت مرکل حالت `S_FINAL` با ریشه حالت نهایی ارائه شده در هدر بلوک برابر است یا خیر. اگر چنین باشد، بلوک معتبر است. در غیر این صورت معتبر نیست.
-
-این رویکرد ممکن است در نگاه اول بسیار ناکارآمد به نظر برسد، زیرا باید کل حالت را با هر بلوک ذخیره کند، اما در واقع کارایی باید با بیتکوین قابل مقایسه باشد. دلیل آن این است که حالت در ساختار درختی ذخیره می شود و بعد از هر بلوک فقط قسمت کوچکی از درخت باید تغییر کند. بنابراین، به طور کلی، بین دو بلوک مجاور، اکثریت قریب به اتفاق درخت باید یکسان باشد، و بنابراین داده ها را می توان یک بار ذخیره کرد و دو بار با استفاده از نشانگرها (به عنوان مثال هش درختان فرعی) ارجاع داد. نوع خاصی از درخت که به نام "درخت پاتریشیا" شناخته می شود برای انجام این کار استفاده می شود، از جمله اصلاح مفهوم درخت مرکل که به گره ها اجازه می دهد تا درج و حذف شوند، و نه تنها به طور مؤثر تغییر کنند. علاوه بر این، از آنجایی که تمام اطلاعات وضعیت بخشی از آخرین بلوک است، نیازی به ذخیره کل تاریخچه بلاکچین نیست - استراتژی که اگر بتوان آن را در بیتکوین اعمال کرد، میتوان آن را محاسبه کرد تا 5 تا 20 برابر در فضا صرفهجویی کند.
-
-یک سوال متداول این است که کد قرارداد از نظر سخت افزار فیزیکی "کجا" اجرا می شود. جواب هم ساده است: فرآیند اجرای کد قرارداد بخشی از تعریف تابع انتقال حالت است که بخشی از الگوریتم اعتبارسنج بلوک است، بنابراین اگر تراکنش به بلوک `B` اضافه شود، کد اجرای ایجاد شده توسط آن تراکنش توسط همه گرهها، در حال حاضر و در آینده، که بلوک `B` دانلود و اعتبارسنج میکنند، اجرا خواهد شد.
-
-
-
-## برنامههای کاربردی {#applications}
-
-به طور کلی، سه نوع برنامه سوار بر اتریوم هستند: دسته اول برنامه های مالی هستند که روش های قدرتمندتری را برای مدیریت و عقد قراردادها با استفاده از پول در اختیار کاربران قرار می دهند. این شامل ارزهای فرعی، مشتقات مالی، قراردادهای پوشش ریسک، کیف پول های پس انداز، وصیت نامه و در نهایت حتی برخی از کلاس های قراردادهای کار در مقیاس کامل است. دسته دوم برنامه های نیمه مالی است که در آن پول درگیر است، اما جنبه غیر پولی سنگینی نیز برای کاری که انجام می شود وجود دارد. یک مثال عالی، پاداش های خود-اجباری برای راه حل های مسائل محاسباتی است. در نهایت، برنامه هایی مانند رای گیری آنلاین و حاکمیت غیرمتمرکز وجود دارند که اصلاً مالی نیستند.
-
-
-
-### سیستمهای توکن {#token-systems}
-
-سیستمهای توکن درون بلاکچین کاربردهای زیادی دارند، از ارزهای فرعی که داراییهایی مانند دلار یا طلا را نشان میدهند تا سهام شرکت، توکنهای فردی که نشان دهنده دارایی هوشمند، کوپنهای غیرقابل جعل امن و حتی سیستمهای رمزی بدون هیچ ارتباطی با ارزش متعارف، به عنوان سیستمهای نقطهای برای ایجاد انگیزه استفاده میشوند. پیاده سازی سیستم های توکن در اتریوم به طرز شگفت انگیزی آسان است. نکته کلیدی برای درک این است که تمام یک ارز یا سیستم توکن، اساساً یک پایگاه داده با یک عملیات است: X واحدها را از A کم کنید و واحدهای X را به B بدهید، با این شرط که (i) A حداقل X واحد داشته باشد. قبل از تراکنش و (2) تراکنش توسط A تأیید شود. تمام آنچه برای پیاده سازی یک سیستم توکن نیاز است، پیاده سازی این منطق در یک قرارداد است.
-
-کد اصلی برای پیاده سازی یک سیستم توکن در Serpent به صورت زیر است:
-
-
-
-```py
-def send(to, value):
- if self.storage[msg.sender] >= value:
- self.storage[msg.sender] = self.storage[msg.sender] - value
- self.storage[to] = self.storage[to] + value
-```
-
-
-این اساساً اجرای تحت اللفظی تابع انتقال حالت "سیستم بانکی" است که در بالا در این سند شرح داده شد. چند خط کد اضافی باید اضافه شود تا مرحله اولیه توزیع واحدهای ارزی در وهله اول و چند مورد لبه دیگر فراهم شود، و در حالت ایدهآل تابعی اضافه میشود که به قراردادهای دیگر اجازه میدهد تا تعادل یک آدرس را جستجو کنند. اما این تمام چیزی است که وجود دارد. از نظر تئوری، سیستمهای توکن مبتنی بر اتریوم که بهعنوان ارزهای فرعی عمل میکنند، میتوانند به طور بالقوه ویژگی مهم دیگری را داشته باشند که متا ارزهای مبتنی بر بیتکوین روی زنجیره فاقد آن هستند: توانایی پرداخت مستقیم هزینههای تراکنش در آن ارز. روش اجرای این امر به این صورت است که قرارداد دارای تعادل اتری است که با آن اتری که برای پرداخت هزینهها به فرستنده استفاده میشود بازپرداخت میکند، و این موجودی را با جمعآوری واحدهای ارز داخلی که کارمزد دریافت میکند و فروش مجدد آنها در یک حراج دائمی دوباره پر میکند. بنابراین کاربران باید حساب های خود را با اتر "فعال کنند"، اما زمانی که اتر وجود دارد، قابل استفاده مجدد خواهد بود زیرا قرارداد هر بار آن را بازپرداخت می کند.
-
-
-
-### مشتقات مالی و ارزهای با ارزش ثابت {#financial-derivatives-and-stable-value-currencies}
-
-مشتقات مالی رایج ترین کاربرد "قرارداد هوشمند" و یکی از سادهترین آنها برای پیادهسازی در کد هستند. چالش اصلی در اجرای قراردادهای مالی این است که اکثر آنها نیاز به ارجاع به شاخص قیمت خارجی دارند. به عنوان مثال، یک برنامه بسیار مطلوب، یک قرارداد هوشمند است که در برابر نوسانات اتر (یا یک رمزارز دیگر) با توجه به دلار آمریکا محافظت می کند، اما انجام این کار مستلزم آن است که قرارداد بداند ارزش ETH/USD چقدر است. ساده ترین راه برای انجام این کار، از طریق قرارداد «فید داده» است که توسط یک طرف خاص (مثلاً NASDAQ) نگهداری می شود که به گونه ای طراحی شده است که آن طرف توانایی بهروزرسانی قرارداد را در صورت نیاز داشته باشد، و ارائه رابطی که به سایر قراردادها اجازه می دهد تا یک پیام ارسال کنند. به آن قرارداد پیام دهید و پاسخی دریافت کنید که قیمت را ارائه می دهد.
-
-با توجه به آن عنصر حیاتی، قرارداد پوشش ریسک به شرح زیر است:
-
-1. منتظر بمانید تا طرف اول 1000 اتر را وارد کند.
-2. منتظر بمانید تا طرف دوم 1000 اتر را وارد کند.
-3. ارزش دلاری 1000 اتر را که با کوئری زدن به قرارداد خوراک داده محاسبه می شود، در فضای ذخیرهسازی ثبت کنید، بگویید این مقدار $x است.
-4. پس از 30 روز، به طرف اول و دوم اجازه دهید تا قرارداد را "دوباره فعال کنند" تا اتر به ارزش $x (که با کوئری زدن مجدد به قرارداد خوراک داده برای دریافت قیمت جدید محاسبه می شود) به طرف اول و بقیه به طرف دوم ارسال شود.
-
-چنین قراردادی پتانسیل قابل توجهی در تجارت کریپتویی خواهد داشت. یکی از اصلیترین مشکلاتی که در مورد رمزارزها به آن اشاره میشود، فرِار بودن آن است. اگرچه بسیاری از کاربران و بازرگانان ممکن است امنیت و راحتی کار با دارایی های رمزنگاری شده را بخواهند، اما بسیاری از آنها نمی خواهند با این چشم انداز از دست دادن 23٪ از ارزش سرمایه خود در یک روز روبرو شوند. تا کنون، متداولترین راهحل پیشنهادی، داراییهای دارای پشتوانه صادرکننده بوده است. ایده این است که یک ناشر یک ارز فرعی ایجاد می کند که در آن حق صدور و ابطال واحدها را دارد و یک واحد ارز را به هر کسی که (آفلاین) یک واحد از یک دارایی اساسی مشخص (مثلاً طلا، دلار) را در اختیار آنها قرار می دهد، ارائه دهید. سپس صادرکننده قول میدهد که یک واحد از دارایی پایه را به هر کسی که یک واحد از دارایی رمزنگاری شده را پس میفرستد، ارائه دهد. این مکانیزم به هر دارایی رمزنگارینشده اجازه می دهد تا به یک دارایی رمزنگاری "سربلند" تبدیل شود، مشروط بر اینکه بتوان به صادرکننده اعتماد کرد.
-
-با این حال، در عمل، ناشران همیشه قابل اعتماد نیستند و در برخی موارد زیرساخت بانکی برای وجود چنین خدماتی بسیار ضعیف یا بسیار خصمانه است. مشتقات مالی یک جایگزین را ارائه می دهند. در اینجا، به جای اینکه یک صادرکننده واحد پولی را برای پشتیبانگیری از یک دارایی فراهم کند، یک بازار غیرمتمرکز از سفتهبازان که شرط میبندند قیمت یک دارایی مرجع رمزنگاری (مثلا اتر) بالا خواهد رفت، این نقش را ایفا میکند. بر خلاف صادرکننده، سفته بازان هیچ گزینه ای برای نکول در معامله خود ندارند زیرا قرارداد پوشش ریسک وجوه آنها را در امان نگه می دارد. توجه داشته باشید که این رویکرد کاملاً غیرمتمرکز نیست، زیرا هنوز یک منبع قابل اعتماد برای ارائه شاخص قیمت مورد نیاز است، اگرچه احتمالاً حتی هنوز هم این یک پیشرفت بزرگ از نظر کاهش الزامات زیرساختی است (برخلاف صادرکننده بودن، صدور خوراک قیمت نیازی به مجوز ندارد. و احتمالاً می تواند به عنوان آزادی بیان طبقه بندی شود) و پتانسیل تقلب را کاهش می دهد.
-
-
-
-### سیستم های هویت و شهرت {#identity-and-reputation-systems}
-
-اولین رمزارز جایگزین، [Namecoin](http://namecoin.org/)، تلاش کرد از یک بلاکچین مانند بیتکوین برای ارائه یک سیستم ثبت نام استفاده کند، جایی که کاربران می توانند نام خود را در یک پایگاه داده عمومی در کنار سایر داده ها ثبت کنند. مورد استفاده عمده ذکر شده متعلق به یک سیستم [DNS](https://wikipedia.org/wiki/Domain_Name_System) است که نام های دامنه مانند "bitcoin.org" (یا در مورد Namecoin، "bitcoin.bit") را به یک آدرس IP نگاشت می کند. موارد استفاده دیگر عبارتند از احراز هویت ایمیل و سیستم های شهرت بالقوه پیشرفتهتر. در اینجا قرارداد اصلی برای ارائه یک سیستم ثبت نام مشابه Namecoin در اتریوم است:
-
-
-
-```py
-def register(name, value):
- if !self.storage[name]:
- self.storage[name] = value
-```
-
-
-قرارداد بسیار ساده است. همه اینها یک پایگاه داده در داخل شبکه اتریوم است که می توان به آن اضافه کرد، اما نمی توان آن را تغییر داد یا حذف کرد. هر کسی می تواند نامی با مقداری را ثبت کند و آن ثبت نام برای همیشه باقی می ماند. یک قرارداد پیچیدهتر ثبت نام همچنین دارای یک «بند عملکرد» است که به سایر قراردادها امکان میدهد آن را پرس و جو کنند، و همچنین مکانیزمی برای «مالک» (یعنی اولین ثبتکننده) نام برای تغییر داده یا انتقال مالکیت. حتی می توان شهرت و قابلیت های شبکه ای از اعتماد را در بالای آن اضافه کرد.
-
-
-
-### ذخیره سازی غیرمتمرکز فایل {#decentralized-file-storage}
-
-در چند سال گذشته، تعدادی راهانداز ذخیرهسازی فایل آنلاین، معروفترین آنها Dropbox به وجود آمدهاند که به دنبال اجازه دادن به کاربران برای آپلود یک نسخه پشتیبان از هارد دیسک خود و اینکه سرویس پشتیبان را ذخیره کند و به کاربر اجازه دهد در ازای پرداخت هزینه ماهانه به آن دسترسی داشته باشد هستند. با این حال، در این مرحله، بازار ذخیرهسازی فایل در زمانهایی نسبتاً ناکارآمد است. نگاهی گذرا به راهحلهای مختلف موجود نشان میدهد که، بهویژه در سطح 20-200 گیگابایتی «دره غیرعادی» که نه سهمیههای رایگان و نه تخفیفهای سطح سازمانی آغاز میشود، قیمت های ماهانه هزینه های ذخیره سازی فایل اصلی به گونه ای است که شما بیش از هزینه کل هارد دیسک در یک ماه پرداخت می کنید. قراردادهای اتریوم میتوانند به توسعه یک اکوسیستم ذخیرهسازی فایل غیرمتمرکز اجازه دهند، که در آن کاربران فردی میتوانند با اجاره هارد دیسکهای خود مقادیر کمی پول به دست آورند و از فضای بلااستفاده برای کاهش بیشتر هزینههای ذخیرهسازی فایل استفاده شود.
-
-بخش کلیدی زیربنای چنین دستگاهی همان چیزی است که ما آن را "قرارداد غیرمتمرکز Dropbox" نامیده ایم. این قرارداد به شرح زیر عمل می کند. ابتدا، دادههای مورد نظر را به بلوکها تقسیم میکند، هر بلوک را برای حفظ حریم خصوصی رمزگذاری میکند و درخت مرکل را از آن میسازد. سپس یک قرارداد با این قانون منعقد میکند که، هر N بلوک، قرارداد یک شاخص تصادفی در درخت مرکل انتخاب میکند (با استفاده از هش بلوک قبلی، قابل دسترسی از کد قرارداد، به عنوان منبع تصادفی)، و X اتر را به اولین نهادی که یک تراکنش را با یک سند تأیید پرداخت ساده شده مبنی بر مالکیت بلوک در آن شاخص خاص در درخت ارائه می کند، می دهد. هنگامی که کاربر می خواهد فایل خود را دوباره دانلود کند، می تواند از پروتکل کانال پرداخت خرد (مثلاً پرداخت 1 زابو در هر 32 کیلوبایت) برای بازیابی فایل استفاده کند. کارآمدترین رویکرد این است که پرداخت کننده تراکنش را تا پایان منتشر نکند، در عوض تراکنش را با تراکنش کمی سودآورتر با همان نانس پس از هر 32 کیلوبایت جایگزین کند.
-
-یکی از ویژگی های مهم پروتکل این است که، اگرچه ممکن است به نظر برسد که یک نفر به بسیاری از گره های تصادفی اعتماد دارد تا تصمیم به فراموش کردن فایل نداشته باشد، و یک نفر میتواند با تقسیم کردن فایل به قطعات متعدد از طریق اشتراکگذاری مخفی، این ریسک را به نزدیک به صفر کاهش دهد و تماشای قراردادها برای دیدن هر قطعه هنوز در اختیار برخی از گرهها است. اگر یک قرارداد همچنان پولی را پرداخت میکند، این یک مدرک رمزنگاری شده است که نشان میدهد یک نفر هنوز در آنجا دارد فایل را ذخیره میکند.
-
-
-
-### سازمان خودمختار غیرمتمرکز {#decentralized-autonomous-organizations}
-
-مفهوم کلی "سازمان خودمختار غیرمتمرکز" عبارت است از یک نهاد مجازی که دارای مجموعه معینی از اعضا یا سهامداران است که شاید با اکثریت 67 درصدی، حق دارند وجوه آن واحد را خرج کرده و کد آن را اصلاح کنند. اعضا به طور جمعی در مورد نحوه تخصیص بودجه توسط سازمان تصمیم می گیرند. روشهای تخصیص وجوه یک DAO میتواند از جوایز، حقوق گرفته تا مکانیسمهای عجیبتری مانند ارز داخلی برای پاداش دادن به کار متغیر باشد. این اساساً موارد قانونی یک شرکت سنتی یا غیرانتفاعی را تکرار می کند، اما تنها از فناوری بلاکچین رمزنگاری شده برای اجرا استفاده می کند. تاکنون بسیاری از صحبتها در مورد DAOها حول مدل «سرمایهداری» یک «شرکت مستقل غیرمتمرکز» (DAC) با سهامداران دریافتکننده سود سهام و سهام قابل معامله بوده است. یک جایگزین، که شاید به عنوان «جامعه خودمختار غیرمتمرکز» توصیف شود، این است که همه اعضا سهم برابری در تصمیمگیری دارند و 67 درصد از اعضای موجود باید با اضافه کردن یا حذف یک عضو موافقت کنند. این شرط که یک نفر فقط می تواند یک عضویت داشته باشد باید به طور جمعی توسط گروه اجرا شود.
-
-یک طرح کلی برای نحوه کدنویسی یک DAO به شرح زیر است. سادهترین طرح صرفاً یک قطعه کد خود اصلاحکننده است که در صورت توافق دو سوم اعضا بر روی تغییرات تغییر میکند. اگرچه کد از نظر تئوری تغییرناپذیر است، اما با داشتن تکههایی از کد در قراردادهای جداگانه، و ذخیره آدرس قراردادهای فراخوانی ذخیره شده در ذخیرهسازی قابل تغییر، میتوان به راحتی از این موضوع عبور کرد و تغییرپذیری واقعی داشت. در اجرای ساده چنین قرارداد DAO، سه نوع تراکنش وجود دارد که با داده های ارائه شده در تراکنش متمایز می شوند:
-
-- `[0,i,K,V]` برای ثبت پیشنهاد با نمایه `i` برای تغییر آدرس در فهرست ذخیرهسازی `K` به مقدار ` V`
-- برای ثبت رای به نفع پیشنهاد `[1,i]` `i`
-- `[2,i]` برای نهایی کردن پیشنهاد `i` اگر رای کافی داده شده باشد
-
-سپس قرارداد برای هر یک از اینها بندهایی خواهد داشت. این یک رکورد از همه تغییرات فضای باز را به همراه فهرستی از افرادی که به آنها رای داده اند حفظ می کند. همچنین فهرستی از همه اعضا را خواهد داشت. هنگامی که هر تغییر فضای ذخیرهسازی به دو سوم اعضا می رسد که به آن رأی می دهند، یک تراکنش نهایی می تواند تغییر را اجرا کند. یک اسکلت پیچیدهتر همچنین میتواند قابلیت رایگیری داخلی برای ویژگیهایی مانند ارسال تراکنش، افزودن اعضا و حذف اعضا داشته باشد، و حتی ممکن است امکان تفویض رأی به سبک [دموکراسی نقد](https://wikipedia.org/wiki/Liquid_democracy) را فراهم کند (یعنی هرکسی میتواند شخصی را به رای دادن به او اختصاص دهد، و انتساب انتقالی است، بنابراین اگر A به B و B به C اختصاص دهد، C رای A را تعیین میکند). این طراحی به DAO اجازه می دهد تا به صورت ارگانیک به عنوان یک جامعه غیرمتمرکز رشد کند، و به مردم این امکان را می دهد تا در نهایت وظیفه فیلتر کردن اعضای آن را به متخصصان محول کنند، اگرچه برخلاف «سیستم فعلی»، متخصصان به راحتی می توانند در طول زمان وارد و خارج شوند همانطور که افراد جامعه صف بندی خود را تغییر می دهند.
-
-یک مدل جایگزین برای یک شرکت غیرمتمرکز است، که در آن هر حسابی میتواند دارای سهام صفر یا بیشتر باشد و دو سوم سهام برای تصمیمگیری لازم است. یک اسکلت کامل شامل عملکرد مدیریت دارایی، توانایی ارائه پیشنهاد برای خرید یا فروش سهام، و توانایی پذیرش پیشنهادها (ترجیحا با مکانیزم تطبیق سفارش در داخل قرارداد) است. تفویض اختیار نیز به سبک دموکراسی مایع وجود خواهد داشت که مفهوم "هیئت مدیره" را تعمیم می دهد.
-
-
-
-### برنامههای کاربردهای بیشتر {#further-applications}
-
-**1. کیفهای پول پسانداز**. فرض کنید که آلیس (Alice) میخواهد سرمایه خود را ایمن نگه دارد، اما نگران است که از دست بدهد یا کسی کلید خصوصی او را هک کند. او اتر را در یک قرارداد با باب، یک بانک، به شرح زیر قرار می دهد:
-
-- آلیس به تنهایی میتواند حداکثر 1 درصد از وجوه را در روز برداشت کند.
-- باب به تنهایی میتواند حداکثر 1 درصد از وجوه را در روز برداشت کند، اما آلیس این توانایی را دارد که با کلید خود معامله کند و این توانایی را خاموش کند.
-- آلیس و باب با هم میتوانند هر چیزی را پس بگیرند.
-
-به طور معمول، 1 درصد در روز برای آلیس کافی است، و اگر آلیس بخواهد بیشتر برداشت کند، میتواند برای کمک با باب تماس بگیرد. اگر کلید آلیس هک شود، او به سراغ باب میرود تا سرمایه را به یک قرارداد جدید منتقل کند. اگر او کلید خود را گم کند، باب در نهایت وجوه را بیرون خواهد آورد. اگر معلوم شود که باب بدخواه است، او می تواند دسترسی باب را برای برداشت خاموش کند.
-
-**2. بیمه محصول**. می توان به راحتی قرارداد مشتقات مالی منعقد کرد، اما به جای هر شاخص قیمت، از داده های آب و هوا استفاده کرد. اگر یک کشاورز در آیووا مشتقی را خریداری کند که بر اساس بارندگی در آیووا به طور معکوس پرداخت می کند، اگر خشکسالی وجود داشته باشد، کشاورز به طور خودکار پول دریافت می کند و اگر باران کافی باشد، کشاورز خوشحال خواهد شد زیرا محصولات آنها به خوبی انجام می شود. این را می توان به طور کلی به بیمه بلایای طبیعی گسترش داد.
-
-**3. یک خوراک دیتای غیرمتمرکز**. برای قراردادهای مالی برای تفاوت، ممکن است واقعاً بتوان فید داده را از طریق پروتکلی به نام "[SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) غیرمتمرکز کرد". شلینگ کوین (SchellingCoin) اساساً به این صورت عمل میکند: N طرف همه ارزش یک داده معین (مثلاً قیمت اتر/USD) را در سیستم قرار میدهند، مقادیر مرتب میشوند، و هر کس بین صدک 25 و 75 یک توکن به عنوان پاداش دریافت میکند. همه انگیزه ای برای ارائه پاسخی دارند که دیگران ارائه خواهند کرد، و تنها ارزشی که تعداد زیادی از بازیکنان می توانند به طور واقع بینانه روی آن توافق کنند، پیش فرض آشکار است: حقیقت. این مورد یک پروتکل غیرمتمرکز ایجاد میکند که از نظر تئوری میتواند مقادیر زیادی از جمله قیمت اتر/USD، دمای برلین یا حتی نتیجه یک محاسبه سخت خاص را ارائه دهد.
-
-**4. ضمانت چند امضایی هوشمند**. بیتکوین به قراردادهای تراکنش چند امضایی اجازه میدهد که برای مثال، سه کلید از پنج کلید معین میتوانند وجوه را خرج کنند. اتریوم به جزئیات بیشتر اجازه میدهد. به عنوان مثال، از هر پنج نفر چهار نفر میتوانند همه چیز را خرج کنند، از هر پنج نفر سه نفر میتوانند تا 10 درصد در روز و از هر پنج نفر دو نفر میتوانند تا 0.5 درصد در روز خرج کنند. علاوه بر این، اتریوم مالتی سیگ ناهمزمان است - دو طرف میتوانند امضاهای خود را در زمانهای مختلف روی بلاکچین ثبت کنند و آخرین امضا به طور خودکار تراکنش را ارسال میکند.
-
-**5. پردازش ابری**. فناوری EVM همچنین میتواند برای ایجاد یک محیط محاسباتی قابل تأیید استفاده شود و به کاربران این امکان را میدهد که از دیگران بخواهند محاسبات را انجام دهند و سپس بهصورت اختیاری، مدارکی بخواهند که محاسبات در نقاط بازرسی بهطور تصادفی انتخاب شده به درستی انجام شده است. این مورد امکان ایجاد یک بازار رایانش ابری را فراهم میکند که در آن هر کاربر میتواند با دسکتاپ، لپتاپ یا سرور تخصصی خود در آن شرکت کند و از چک کردن اسپات همراه با سپردههای امنیتی میتوان برای اطمینان از قابل اعتماد بودن سیستم استفاده کرد (یعنی گرهها یا نودها نمیتوانند به طور سودآوری تقلب کنند). اگرچه چنین سیستمی ممکن است برای همه کارها مناسب نباشد. به عنوان مثال، کارهایی که به سطح بالایی از ارتباطات بین فرآیندی نیاز دارند، نمیتوانند به راحتی بر روی یک ابر بزرگ از گرهها یا نودها انجام شوند. با این حال، موازی سازی سایر وظایف بسیار آسان تر است. پروژه هایی مانند SETI@home، folding@home و الگوریتم های ژنتیک را می توان به راحتی بر روی چنین پلتفرمی پیادهسازی کرد.
-
-**6. قمار همتا به همتا**. هر تعداد پروتکل قمار همتا به همتا مانند [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Frank Stajano و Richard Clayton را می توان در بلاکچین اتریوم پیادهسازی کرد. سادهترین پروتکل قمار در واقع صرفاً یک قرارداد برای تفاوت در هش بلوک بعدی است و پروتکلهای پیشرفتهتری را میتوان از آنجا ایجاد کرد و خدمات قمار با هزینههای تقریباً صفر ایجاد کرد که توانایی تقلب ندارند.
-
-**7. بازارهای پیش بینی**. به شرط یک اوراکل یا شلینگ کوین، پیادهسازی بازارهای پیشبینی نیز آسان است، و بازارهای پیشبینی همراه با شلینگ کوین ممکن است اولین کاربرد جریان اصلی [futarchy](http://hanson.gmu.edu/futarchy.html) به عنوان پروتکل حاکمیتی برای سازمانهای غیرمتمرکز باشد.
-
-**8. بازارهای غیرمتمرکز زنجیرهای**، با استفاده از سیستم هویت و شهرت به عنوان پایگاه.
-
-
-
-## مسائل متفرقه و نگرانیها {#miscellanea-and-concerns}
-
-
-
-### پروتکل اصلاح شده ی GHOST {#modified-ghost-implementation}
-
-پروتکل "طماعترین زیردرخت مشاهده شده" (GHOST) یک نوآوری است که برای اولین بار توسط Yonatan Sompolinsky و Aviv Zohar در [دسامبر 2013](https://eprint.iacr.org/2013/881.pdf) معرفی شد. انگیزه پشت GHOST این است که بلاک چینهایی با زمان تایید سریع در حال حاضر به دلیل نرخ قدیمی بالا از امنیت کمتری رنج میبرند - زیرا بلوکها زمان مشخصی را برای انتشار در شبکه میطلبند، اگر ماینر A یک بلوک را استخراج کند و سپس ماینر B بلوک دیگری را استخراج کند. قبل از انتشار بلوک ماینر A به B، بلوک ماینر B به هدر می رود و به امنیت شبکه کمک نمی کند. علاوه بر این، یک مشکل متمرکز وجود دارد: اگر ماینر A یک استخر استخراج با 30٪ قدرت هش و B دارای 10٪ قدرت هش باشد، A در 70٪ مواقع (از 30٪ بقیه مواقع) خطر تولید یک بلوک قدیمی را خواهد داشت. A آخرین بلوک را تولید می کند و بنابراین بلافاصله داده های استخراج را دریافت می کند) در حالی که B در 90٪ مواقع خطر تولید یک بلوک قدیمی را دارد. بنابراین، اگر فاصله بلوک به اندازهای کوتاه باشد که نرخ بیات بالا باشد، A بهدلیل اندازهاش به طور قابلتوجهی کارآمدتر خواهد بود. با ترکیب این دو اثر، بلاکچینهایی که بلوکها را به سرعت تولید میکنند، به احتمال زیاد منجر به یک استخر ماینینگ میشوند که درصد زیادی از قدرت هش شبکه را داشته باشد تا بتواند بالفعل بر فرآیند استخراج کنترل داشته باشد.
-
-همانطور که توسط Sompolinsky و Zohar توضیح داده شد، GHOST اولین مشکل از دست دادن امنیت شبکه را با گنجاندن بلوک های قدیمی در محاسبه اینکه کدام زنجیره "طولانی ترین" است را حل می کند. به این معنا که نه تنها والدین و اجداد بعدی یک بلوک، بلکه نوادگان قدیمی اجداد بلوک (در اصطلاح اتریومی، "عمو ها") به محاسباتی اضافه می شوند که کدام بلوک دارای بزرگترین اثبات کار است. برای حل مسئله دوم سوگیری متمرکزسازی، ما فراتر از پروتکل توصیف شده توسط Sompolinsky و Zohar میرویم، و همچنین پاداشهای بلوک را برای قدیمیها ارائه میکنیم: یک بلوک قدیمی 87.5٪ از پاداش پایه خود را دریافت میکند و برادرزاده که شامل بلوک قدیمی است، 12.5 درصد بقیه را دریافت میکند. با این حال، کارمزد تراکنش به عموها تعلق نمی گیرد.
-
-اتریوم نسخه ساده شده GHOST را پیاده سازی می کند که تنها در هفت سطح پایین می آید. به طور مشخص به صورت زیر تعریف می شود:
-
-- یک بلوک باید یک والد را مشخص کند و باید 0 یا چند عمو را مشخص کند
-- عموی موجود در بلوک B باید دارای ویژگی های زیر باشد:
- - این باید یک فرزند مستقیم از اجداد نسل k ام B باشد که در آن `2 <= k <= 7`.
- - نمی تواند جد B باشد
- - عمو باید یک هدر بلوک معتبر باشد، اما نیازی نیست که قبلاً یک بلوک تأیید شده یا حتی معتبر باشد
- - یک عمو باید با همه عموهای موجود در بلوک های قبلی و سایر عموهای موجود در همان بلوک متفاوت باشد (غیر شامل دوگانه)
-- به ازای هر عموی U در بلوک B، ماینر B 3.125٪ اضافی به پاداش کوینبیس خود اضافه می کند و ماینر U 93.75٪ از پاداش استاندارد کوینبیس را دریافت می کند.
-
-این نسخه محدود GHOST، با عموهایی که فقط تا 7 نسل را شامل می شود، به دو دلیل استفاده شد. اولاً، GHOST نامحدود شامل پیچیدگی های بسیار زیادی در محاسبه است که عموهای یک بلوک معین معتبر هستند. دوم، GHOST نامحدود با جبرانی که در اتریوم استفاده میشود، انگیزه استخراجکننده را برای استخراج از زنجیره اصلی و نه زنجیره مهاجم عمومی را از بین میبرد.
-
-
-
-### کارمزدها {#fees}
-
-از آنجایی که هر تراکنش منتشر شده در بلاکچین، هزینه دانلود و تأیید آن را بر شبکه تحمیل میکند، برای جلوگیری از سوء استفاده، نیاز به مکانیزمی نظارتی وجود دارد که معمولاً شامل کارمزد تراکنش است. رویکرد پیشفرض، که در بیتکوین استفاده میشود، داشتن هزینههای کاملاً داوطلبانه است، با تکیه بر ماینرها که به عنوان دروازهبان عمل میکنند و حداقلهای پویا را تعیین میکنند. این رویکرد در جامعه بیتکوین با استقبال بسیار خوبی مواجه شده است، بهویژه به این دلیل که «مبتنی بر بازار» است و به عرضه و تقاضای بین ماینرها و فرستندگان تراکنش اجازه میدهد تا قیمت را تعیین کنند. با این حال، مشکل این خط استدلال این است که پردازش معاملات یک بازار نیست. اگرچه به طور شهودی درک پردازش تراکنش به عنوان خدماتی که ماینر به فرستنده ارائه میدهد جذاب است، در واقع هر تراکنشی که توسط ماینر شامل میشود باید توسط هر گره یا نود در شبکه پردازش شود، بنابراین اکثریت قریب به اتفاق هزینه تراکنش پردازش به عهده اشخاص ثالث است و نه ماینری که تصمیم می گیرد که آن را شامل شود یا نه. از این رو، مشکلات تراژدی رایج بسیار محتمل است.
-
-با این حال، همانطور که مشخص است این نقص در مکانیسم مبتنی بر بازار، زمانی که یک فرض سادهسازی نادرست خاص داده میشود، به طور جادویی خود را خنثی میکند. استدلال به شرح زیر است. فرض کنید که:
-
-1. یک تراکنش به عملیات `k` منتهی میشود، و پاداش `kR` را به هر استخراجکنندهای که شامل آن میشود، ارائه میکند، جایی که `R` توسط فرستنده و `k تنظیم شده است. ` و `R` از قبل (تقریبا) برای ماینر قابل مشاهده هستند.
-2. یک عملیات دارای هزینه پردازش `C` برای هر گره است (یعنی همه گره ها کارایی یکسانی دارند)
-3. تعداد `N` گره ماینینگ وجود دارد که هر کدام دقیقاً قدرت پردازشی برابری دارند (یعنی `1/N` از کل)
-4. هیچ گره کامل غیر ماینینگی وجود ندارد.
-
-اگر پاداش مورد انتظار بیشتر از هزینه باشد، یک ماینر مایل به پردازش یک تراکنش است. بنابراین، پاداش مورد انتظار `kR/N` است زیرا ماینر شانس `1/N` برای پردازش بلوک بعدی را دارد و هزینه پردازش برای ماینر به سادگی ` است. kC`. بنابراین، ماینرها شامل تراکنشهایی میشوند که در آنها `kR/N > kC`، یا `R > NC` باشد. توجه داشته باشید که `R` کارمزد هر عملیات ارائه شده توسط فرستنده است، و بنابراین یک حد پایینتر برای سودی است که فرستنده از تراکنش کسب میکند،و `NC` هزینه کل شبکه برای پردازش یک عملیات است. از این رو، ماینرها این انگیزه را دارند که فقط آن دسته از تراکنشهایی را بگنجانند که کل سود از هزینه آن بیشتر باشد.
-
-با این حال، چندین انحراف مهم از این فرضیات در واقعیت وجود دارد:
-
-1. ماینر هزینه بیشتری را برای پردازش تراکنش نسبت به سایر گرهها یا نودهای تأیید کننده پرداخت میکند، زیرا زمان تأیید اضافی انتشار بلوک را به تأخیر میاندازد و در نتیجه احتمال بسته شدن بلوک را افزایش میدهد.
-2. گره یا نودهای کامل غیر ماینینگ وجود دارد.
-3. توزیع نیروی استخراج ممکن است در عمل به شدت نابرابر شود.
-4. دلالان، دشمنان سیاسی و دیوانههایی که عملکرد مفید آنها شامل ایجاد آسیب به شبکه است، وجود دارند، و میتوانند هوشمندانه قراردادهایی را تنظیم کنند که هزینه آنها بسیار کمتر از هزینه پرداخت شده توسط سایر گرهها یا نودهای تأیید کننده باشد.
-
-(1) تمایلی را برای ماینر فراهم می کند که تراکنش های کمتری را شامل شود، و (2) `NC` را افزایش می دهد. بنابراین، این دو اثر حداقل تا حدی یکدیگر را خنثی می کنند.[چگونه؟] https://github.com/ethereum/wiki/issues/447#issuecomment-316972260) (3) و (4) موضوع اصلی هستند. برای حل آنها به سادگی یک سرمایه شناور ایجاد می کنیم: هیچ بلوکی نمی تواند بیش از `BLK_LIMIT_FACTOR` برابر میانگین متحرک نمایی بلندمدت عملیات داشته باشد. به خصوص:
-
-
-
-```js
-blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
-floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)
-```
-
-
-`BLK_LIMIT_FACTOR` و `EMA_FACTOR` ثابتهایی هستند که فعلاً روی 65536 و 1.5 تنظیم میشوند، اما احتمالاً پس از تجزیه و تحلیل بیشتر تغییر خواهند کرد.
-
-عامل دیگری نیز وجود دارد که اندازه بلوکهای بزرگ را در بیتکوین از بین میبرد: بلوکهایی که بزرگ هستند زمان بیشتری طول میکشد تا انتشار پیدا کنند و در نتیجه احتمال بیات شدن آنها بیشتر است. در اتریوم، انتشار بلوکهای بسیار مصرفکننده گس هم به دلیل بزرگتر بودن و هم به دلیل اینکه پردازش انتقالهای حالت تراکنش برای تأیید اعتبار بیشتر طول میکشد، ممکن است بیشتر طول بکشد. این بازدارنده تاخیر در بیتکوین مورد توجه قرار می گیرد، اما در اتریوم به دلیل پروتکل GHOST کمتر مورد توجه قرار می گیرد. از این رو، تکیه بر محدودیت های بلوک تنظیم شده، پایه پایدارتری را فراهم می کند.
-
-
-
-### محاسبات و تورینگ کامل بودن {#computation-and-turing-completeness}
-
-یک نکته مهم این است که ماشین مجازی اتریوم تورینگ کامل است. این بدان معنی است که کد EVM می تواند هر محاسباتی را که می توان انجام داد، از جمله حلقه های بی نهایت، رمزگذاری کند. کد EVM به دو صورت امکان حلقه زدن را می دهد. اول، یک دستورالعمل `JUMP` وجود دارد که به برنامه اجازه می دهد به نقطه قبلی در کد بازگردد، و یک دستور `JUMPI` برای انجام پرش شرطی، اجازه می دهد تا عباراتی مانند `در حالی که x < 27: x = x * 2` است. دوم، قراردادها میتوانند قراردادهای دیگری را فراخوانی کنند، که امکان چرخش از طریق بازگشت را فراهم میکند. این مورد به طور طبیعی منجر به یک مشکل میشود: آیا کاربران مخرب اساساً میتوانند ماینرها و گره یا نودهای کامل را با مجبور کردن آنها برای ورود به یک لوپ (loop) بینهایت ببندند؟ این موضوع به دلیل مشکلی در علم کامپیوتر به نام مشکل توقف به وجود میآید: در حالت کلی، هیچ راهی برای تشخیص اینکه آیا یک برنامه مشخص هرگز متوقف میشود یا خیر وجود ندارد.
-
-همانطور که در بخش انتقال وضعیت توضیح داده شد، راهحل ما با نیاز به یک تراکنش برای تنظیم حداکثر تعداد مراحل محاسباتی که مجاز به انجام آن هستند، کار میکند، و اگر اجرا طول بکشد، محاسبات برگردانده میشود اما هنوز هزینهها پرداخت میشود. پیامها به همین صورت عمل میکنند. برای نشان دادن انگیزه راه حل ما، مثالهای زیر را در نظر بگیرید:
-
-- یک مهاجم قراردادی ایجاد میکند که یک حلقه بینهایت اجرا میکند، و سپس یک تراکنش فعالسازی آن حلقه را برای ماینر ارسال میکند. ماینر تراکنش را پردازش می کند، حلقه بی نهایت را اجرا می کند و منتظر می ماند تا گس آن تمام شود. حتی اگر گس اجرا تمام شود و در نیمه راه متوقف شود، تراکنش هنوز معتبر است و ماینر همچنان هزینه هر مرحله محاسباتی را از مهاجم مطالبه می کند.
-- یک مهاجم یک حلقه بینهایت بسیار طولانی ایجاد می کند که قصد دارد ماینر را مجبور کند که محاسبات را برای مدت طولانی ادامه دهد تا زمانی که محاسبات به پایان برسد، چند بلوک دیگر بیرون آمده و برای ماینر امکان گنجاندن تراکنش برای مطالبه کارمزد وجود نخواهد داشت. با این حال، مهاجم باید مقداری را برای `STARTGAS` ارسال کند که تعداد مراحل محاسباتی را که اجرا میتواند انجام دهد محدود میکند. بنابراین ماینر از قبل میداند که محاسبه تعداد بسیار زیادی از مراحل را طی میکند.
-- مهاجم قراردادی را با کدهایی مانند `send(A,contract.storage[A]) می بیند. contract.storage[A] = 0`، و تراکنش را با گس کافی برای اجرای مرحله اول ارسال می کند اما مرحله دوم را نه (یعنی برداشت انجام می دهد اما اجازه نمی دهد موجودی پایین بیاید). نویسنده قرارداد نیازی به نگرانی در مورد محافظت در برابر چنین حملاتی ندارد، زیرا اگر اجرا در نیمه راه متوقف شود، تغییرات برگردانده می شوند.
-- یک قرارداد مالی با استفاده از میانه 9 خوراک دیتای اختصاصی به منظور به حداقل رساندن ریسک کار می کند. مهاجم یکی از فیدهای داده را در اختیار می گیرد که به گونه ای طراحی شده است که از طریق مکانیسم متغیر-آدرس-فراخوانی توضیح داده شده در بخش DAO قابل تغییر باشد، و آن را به یک حلقه بی نهایت تبدیل می کند، در نتیجه تلاش می کند هر گونه تلاش برای مطالبه وجوه از قرارداد مالی را مجبور به تمام شدن گاز کند. با این حال، قرارداد مالی می تواند برای جلوگیری از این مشکل محدودیتی برای پیام تعیین کند.
-
-تورینگ کامل نبودن جایگزین تورینگ کامل بودن است، که در آن `JUMP` و `JUMPI` وجود ندارند و فقط یک نسخه از هر قرارداد مجاز است در هر زمان معین در پشته تماس وجود داشته باشد. با این سیستم، سیستم کارمزد توصیف شده و عدم اطمینان در مورد اثربخشی راه حل ما ممکن است ضروری نباشد، زیرا هزینه اجرای یک قرارداد به اندازه آن محدود می شود. علاوه بر این، ناقص بودن تورینگ حتی یک محدودیت بزرگ هم نیست. از بین تمام نمونههای قراردادی که به صورت داخلی تصور کردهایم، تا کنون تنها یک مورد نیاز به یک حلقه داشت، و حتی آن حلقه را می توان با ایجاد 26 تکرار از یک قطعه کد یک خطی حذف کرد. با توجه به پیامدهای جدی تورینگ کامل بودن و مزایای محدود، چرا به سادگی یک زبان تورینگ ناکامل نداشته باشیم؟ با این حال، در واقعیت، تورینگ ناکامل به دور از یک راه حل ساده برای مشکل است. برای اینکه بفهمید چرا، قراردادهای زیر را در نظر بگیرید:
-
-
-
-```sh
-C0: call(C1); call(C1);
-C1: call(C2); call(C2);
-C2: call(C3); call(C3);
-...
-C49: call(C50); call(C50);
-C50: (run one step of a program and record the change in storage)
-```
-
-
-اکنون یک تراکنش به A ارسال کنید. بنابراین، در 51 تراکنش، قراردادی داریم که 250 مرحله محاسباتی را طی می کند. ماینرها میتوانند با حفظ مقداری در کنار هر قرارداد که حداکثر تعداد مراحل محاسباتی را که میتواند انجام دهد، این بمبهای منطقی را پیش از موعد شناسایی کنند، و محاسبه این برای قراردادهایی که قراردادهای دیگر را به صورت بازگشتی فراخوانی میکنند، اما این امر مستلزم آن است که ماینرها قراردادهایی را که قراردادهای دیگری ایجاد میکنند ممنوع کنند (از آنجایی که ایجاد و اجرای تمام 26 قرارداد فوق به راحتی می تواند در یک قرارداد واحد تبدیل شود). نکته مشکلساز دیگر این است که فیلد آدرس یک پیام یک متغیر است، بنابراین به طور کلی ممکن است حتی نتوان گفت که یک قرارداد معین با کدام قراردادهای دیگر پیش از موعد تماس خواهد گرفت. بنابراین، در مجموع، ما یک نتیجه شگفتانگیز داریم: مدیریت کامل بودن تورینگ بهطور شگفتانگیزی آسان است، و مدیریت عدم وجود تورینگ کامل بودن به همان اندازه دشوار است، مگر اینکه دقیقاً همان کنترلها وجود داشته باشد - اما در این مورد چرا نه فقط اجازه دهید پروتکل تورینگ کامل باشد?
-
-
-
-### ارز و صدور {#currency-and-issuance}
-
-شبکه اتریوم شامل ارز داخلی خود به نام اتر است که هدف دوگانه ارائه یک لایه نقدینگی اولیه را برای تبادل کارآمد بین انواع مختلف داراییهای دیجیتال و مهمتر از آن، ارائه مکانیزمی برای پرداخت هزینه تراکنشها دارد. برای سهولت و اجتناب از استدلال های آینده (به بحث فعلی mBTC/uBTC/satoshi در بیتکوین مراجعه کنید)، مقادیر ارزش از قبل نامگذاری گذاری خواهند شد:
-
-- 1: wei
-- 1012: szabo
-- 1015: finney
-- 1018: ether
-
-این باید به عنوان یک نسخه توسعه یافته از مفهوم "دلار" و "سنت" یا "بیتکوین" و "ساتوشی" در نظر گرفته شود. در آینده نزدیک، ما انتظار داریم که "اتر" برای تراکنش های معمولی، "finney" برای تراکنش های خرد و "szabo" و "wei" برای بحث های فنی در مورد هزینه ها و اجرای پروتکل استفاده شود. ارزشهای باقیمانده ممکن است بعداً مفید باشند و در این مرحله نباید در مشتریان گنجانده شوند.
-
-مدل صدور به صورت زیر خواهد بود:
-
-- اتر در فروش ارزی با قیمت 1000 تا 2000 اتر در هر بیتکوین عرضه خواهد شد، مکانیزمی که برای تامین مالی سازمان اتریوم و پرداخت هزینه توسعه در نظر گرفته شده است که با موفقیت توسط پلتفرمهای دیگری مانند مسترکوین (Mastercoin) و NXT استفاده شده است. خریداران اولیه از تخفیفهای بیشتری بهرهمند خواهند شد. بیت کوین دریافتی از فروش کامل برای پرداخت حقوق و جوایز به توسعهدهندگان و سرمایهگذاری در پروژههای مختلف انتفاعی و غیرانتفاعی در اتریوم و اکوسیستم ارزهای دیجیتال استفاده میشود.
-- 0.099 برابر کل مبلغ فروخته شده (60102216 اتر) برای جبران خسارت مشارکتکنندگان اولیه و پرداخت هزینههای اتر قبل از بلوک پیدایش به سازمان تخصیص داده میشود.
-- 0.099 برابر کل مبلغ فروخته شده به عنوان ذخیره بلند مدت نگهداری میشود.
-- 0.26 برابر کل مبلغ فروخته شده برای همیشه پس از آن نقطه به ماینرها در سال اختصاص می یابد.
-
-| گروه | در زمان راهاندازی | بعد از 1 سال | بعد از 5 سال |
-| ------------------------ | ------------------ | ------------ | ------------ |
-| واحدهای ارزی | 1.198X | 1.458X | 2.498X |
-| خریداران | 83.5% | 68.6% | 40.0% |
-| رزرو صرف شده در پیش فروش | 8.26% | 6.79% | 3.96% |
-| رزرو صرف شده پس از فروش | 8.26% | 6.79% | 3.96% |
-| ماینرها | 0% | 17.8% | 52.0% |
-
-
-
-
-#### نرخ رشد عرضه بلندمدت (درصد)
-
-![تورم اتریوم](./ethereum-inflation.png)
-
-_با وجود انتشار ارز خطی، درست مانند بیتکوین در طول زمان، نرخ رشد عرضه با این وجود به صفر میرسد._
-
-دو انتخاب اصلی در مدل فوق عبارتند از (1) وجود و اندازه یک استخر وقف، و (2) وجود یک عرضه خطی دائما در حال رشد، در مقابل عرضه سقفی مانند بیتکوین. توجیه استخر وقف به شرح زیر است. اگر استخر وقف وجود نداشت، و انتشار خطی به 0.217 برابر کاهش می یافت تا نرخ تورم یکسانی ارائه شود، آنگاه مقدار کل اتر 16.5٪ کمتر می شد و بنابراین هر واحد 19.8٪ ارزش بیشتری داشت. بنابراین، در حالت تعادل 19.8٪ اتر بیشتر در فروش خریداری می شود، بنابراین هر واحد دوباره دقیقاً به اندازه قبل ارزشمند خواهد بود. این سازمان همچنین 1.198 برابر همان بیتکوین خواهد داشت که می توان آن را به دو بخش تقسیم کرد: بیتکوین اصلی و 0.198 برابر دیگر. از این رو، این وضعیت _دقیقاً معادل_ با وقف است، اما با یک تفاوت مهم: سازمان صرفاً BTC را در اختیار دارد، و بنابراین انگیزه ای برای حمایت از ارزش واحد اتر ندارد.
-
-مدل رشد عرضه خطی دائمی خطر آنچه را که برخی به عنوان تمرکز بیش از حد ثروت در بیتکوین می دانند، کاهش می دهد. و به افرادی که در دوران کنونی و آینده زندگی می کنند فرصت مناسبی برای بدست آوردن واحدهای ارزی می دهد، در حالی که در عین حال انگیزه قوی برای به دست آوردن و نگهداری اتر حفظ می شود زیرا "نرخ رشد عرضه" به عنوان درصد همچنان در طول زمان به صفر تمایل دارد. ما همچنین این نظریه را مطرح می کنیم که چون سکه ها همیشه در طول زمان به دلیل بی احتیاطی، مرگ و غیره گم می شوند، و زیان سکه را می توان به صورت درصدی از کل عرضه در سال مدل کرد، که در واقع عرضه کل ارز در گردش در نهایت در ارزشی برابر با انتشار سالانه تقسیم بر نرخ ضرر تثبیت می شود. (به عنوان مثال، با نرخ ضرر 1٪، هنگامی که عرضه به 26X رسید، 0.26X استخراج می شود و 0.26X هر سال از دست می رود و تعادل ایجاد می کند).
-
-توجه داشته باشید که در آینده، این احتمال وجود دارد که اتریوم برای امنیت به مدل اثبات سهام روی بیاورد و نیاز صدور را بین صفر تا 0.05 برابر در سال کاهش دهد. در صورتی که سازمان اتریوم بودجه خود را از دست بدهد یا به هر دلیل دیگری ناپدید شود، یک "قرارداد اجتماعی" را باز می گذاریم: هر کسی حق دارد یک نسخه کاندید آینده اتریوم ایجاد کند، تنها شرط این است که مقدار اتر باید حداکثر برابر با `60102216 * (1.198 + 0.26 * n)` باشد که در آن `n` تعداد سالهای پس از بلوک پیدایش است. سازندگان مختارند که به صورت انبوه بفروشند یا برخی یا تمام تفاوت بین گسترش عرضه مبتنی بر PoS و حداکثر گسترش عرضه مجاز را برای پرداخت هزینه توسعه اختصاص دهند. نامزدهای ارتقا که با قرارداد اجتماعی مطابقت ندارند، ممکن است به طور موجه در نسخه های سازگار تقسیم شوند.
-
-
-
-### تمرکزگرایی ماینینگ {#mining-centralization}
-
-الگوریتم استخراج بیتکوین به این صورت کار می کند که ماینرها SHA256 را بر روی نسخه های کمی تغییر یافته هدر بلوک میلیون ها بار و بارها محاسبه کنند تا اینکه در نهایت یک گره نسخه ای را ارائه می دهد که هش آن کمتر از هدف است (در حال حاضر حدود 2192 ). با این حال، این الگوریتم استخراج در برابر دو شکل از تمرکزگرایی آسیب پذیر است. اول، اکوسیستم ماینینگ تحت تسلط ASIC ها (مدارهای مجتمع ویژه برنامه)، تراشه های کامپیوتری طراحی شده و در نتیجه هزاران بار کارآمدتر در وظایف خاص استخراج بیتکوین قرار گرفته است. این به این معنی است که استخراج بیتکوین دیگر یک پیگیری بسیار غیرمتمرکز و برابری طلبانه نیست و برای مشارکت موثر در آن به میلیون ها دلار سرمایه نیاز دارد. دوم، اکثر ماینرهای بیتکوین در واقع اعتبارسنج بلوک را به صورت محلی انجام نمی دهند. در عوض، آنها به یک استخر استخراج متمرکز برای ارائه هدرهای بلوک متکی هستند. این مشکل مسلماً بدتر است: تا زمان نگارش این مقاله، سه استخر استخراج برتر به طور غیرمستقیم تقریباً 50 درصد از قدرت پردازش در شبکه بیتکوین را کنترل میکنند، اگر چه اگر یک استخر یا ائتلاف حمله ای 51 درصدی انجام دهد، این امر با این واقعیت کاهش می یابد که ماینرها می توانند به استخرهای استخراج دیگر روی آورند.
-
-هدف فعلی اتریوم استفاده از یک الگوریتم استخراج است که در آن ماینرها باید دادههای تصادفی را از حالت واکشی کنند، برخی از تراکنشهای انتخابی تصادفی را از آخرین N بلوک در بلاکچین محاسبه کنند و هش نتیجه را برگردانند. این امر دو فایده مهم دارد. اول، قراردادهای اتریوم می توانند شامل هر نوع محاسباتی باشند، بنابراین یک ASIC اتریوم اساساً یک ASIC برای محاسبات عمومی خواهد بود - یعنی CPU بهتر. دوم، ماینینگ نیاز به دسترسی به کل بلاک چین دارد و ماینرها را مجبور می کند کل بلاکچین را ذخیره کنند و حداقل بتوانند هر تراکنش را تأیید کنند. این امر نیاز به استخرهای استخراج متمرکز را از بین می برد. اگرچه استخرهای ماینینگ همچنان میتوانند نقش مشروع توزیع تصادفی پاداش را ایفا کنند، این عملکرد میتواند به همان اندازه توسط استخرهای همتا به همتا و بدون کنترل مرکزی انجام شود.
-
-این مدل آزمایش نشده است و ممکن است هنگام استفاده از اجرای قرارداد به عنوان یک الگوریتم استخراج، مشکلاتی در اجتناب از بهینهسازی های هوشمندانه وجود داشته باشد. با این حال، یکی از ویژگیهای جالب توجه این الگوریتم این است که به هر کسی اجازه میدهد «در چاه آب سم بریزد»، با وارد کردن تعداد زیادی قرارداد به بلاکچینی که بهطور خاص برای جلوگیری از ASICهای خاص طراحی شدهاند. انگیزه های اقتصادی برای سازندگان ASIC وجود دارد تا از چنین ترفندی برای حمله به یکدیگر استفاده کنند. بنابراین، راه حلی که ما در حال توسعه آن هستیم، در نهایت یک راه حل اقتصادی سازگار انسانی است تا صرفاً فنی.
-
-
-
-### قابل مقیاس {#scalability}
-
-یکی از نگرانیهای رایج در مورد اتریوم مسئله مقیاسپذیری است. مانند بیتکوین، اتریوم نیز از این نقص رنج میبرد که هر تراکنش باید توسط هر گره یا نود در شبکه پردازش شود. با بیتکوین، اندازه بلاکچین فعلی در حدود 15 گیگابایت است که حدود 1 مگابایت در ساعت افزایش مییابد. اگر شبکه بیتکوین 2000 تراکنش ویزا را در ثانیه پردازش کند، 1 مگابایت در هر سه ثانیه (1 گیگابایت در ساعت، 8 ترابایت در سال) رشد میکند. اتریوم احتمالاً از الگوی رشد مشابهی رنج میبرد، که با این واقعیت بدتر شده است که برنامههای کاربردی زیادی بر روی بستر بلاکچین اتریوم به جای ارز مانند بیتکوین وجود خواهد داشت، اما با این واقعیت که گره های کامل اتریوم به جای کل تاریخچه بلاکچین، فقط وضعیت را ذخیره می کنند، بهبود یافته است.
-
-مشکل چنین اندازه بلاکچین بزرگی، ریسک تمرکزگرایی است. اگر اندازه بلاکچین به مثلاً 100 ترابایت افزایش یابد، سناریوی محتمل این خواهد بود که تنها تعداد بسیار کمی از کسبوکارهای بزرگ گرههای کامل را اجرا کنند و همه کاربران عادی از گرههای SPV سبک استفاده کنند. در چنین شرایطی، این نگرانی وجود دارد که گره یا نودهای کامل میتوانند به یکدیگر متصل شوند و همه توافق کنند که به شیوهای سودآور تقلب کنند (مثلاً پاداش بلوک را تغییر دهند، به خود بیتکوین بدهند). گره های سبک هیچ راهی برای تشخیص فوری این موضوع ندارند. البته، حداقل یک گره کامل صادقانه احتمالا وجود خواهد داشت، و پس از چند ساعت اطلاعات مربوط به کلاهبرداری از طریق کانالهایی مانند ردیت منتشر میشود، اما در آن مرحله دیگر خیلی دیر شده است: این ساماندهی بر عهده کاربران عادی است که تلاشی را برای فهرست سیاه بلوک های داده شده سازماندهی کنند، یک مشکل هماهنگی عظیم و احتمالا غیرقابل اجرا در مقیاسی مشابه با انجام یک حمله موفق 51 درصدی. در مورد بیتکوین، این در حال حاضر یک مشکل است، اما یک اصلاح بلاکچینی [پیشنهاد شده توسط پیتر تاد](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) وجود دارد که این مشکل را کاهش می دهد.
-
-در کوتاه مدت، اتریوم از دو استراتژی اضافی برای مقابله با این مشکل استفاده خواهد کرد. اولاً، به دلیل الگوریتمهای استخراج مبتنی بر بلاکچین، حداقل هر ماینر مجبور میشود که یک گره کامل باشد و یک حد پایینتر برای تعداد گرههای کامل ایجاد کند. دوم و مهمتر، با این حال، ما پس از پردازش هر تراکنش، یک ریشه درخت حالت میانی را در بلاکچین قرار می دهیم. حتی اگر اعتبار سنجی بلوک متمرکز باشد، تا زمانی که یک گره یا نود راستیآزمایی صادقانه وجود داشته باشد، مشکل متمرکزسازی را میتوان از طریق یک پروتکل تأیید دور زد. اگر یک ماینر یک بلوک نامعتبر منتشر کند، آن بلوک یا باید بد قالب باشد یا وضعیت `S[n]` نادرست است. از آنجایی که `S[0]` به عنوان صحیح شناخته شده است، باید اولین حالت `S[i]` وجود داشته باشد که در جایی که `S[i-1]> نادرست است 0> صحیح است. گره تأیید کننده شاخص i` را به همراه یک "اثبات عدم اعتبار" شامل زیرمجموعه گره های درخت پاتریشیا که نیاز به پردازش `APPLY(S[i-1],TX[i) را ارائه می کند.]) -> S[i]`. گره ها می توانند از آن گره ها برای اجرای آن قسمت از محاسبات استفاده کنند و ببینند که `S[i]` تولید شده با `S[i]` ارائه شده مطابقت ندارد.
-
-حمله دیگر، پیچیدهتر، شامل ماینرهای مخرب است که بلوکهای ناقص را منتشر میکنند، بنابراین اطلاعات کامل حتی برای تعیین معتبر بودن یا نبودن بلوکها وجود ندارد. راهحل این یک پروتکل پاسخ به چالش است: گرههای تأیید «چالشها» را در قالب شاخصهای تراکنش هدف ایجاد میکنند. و با دریافت یک گره، یک گره نوری، بلوک را تا زمانی که گره دیگری غیرقابل اعتماد است، در نظر می گیرد. چه ماینر یا تایید کننده دیگر، زیرمجموعه ای از گره های پاتریشیا را به عنوان اثبات اعتبار ارائه می دهد.
-
-
-
-## نتيجه گيری {#conclusion}
-
-پروتکل اتریوم در ابتدا به عنوان یک نسخه ارتقا یافته از یک ارز رمزنگاری شده در نظر گرفته شد که ویژگیهای پیشرفتهای مانند سپرده روی بلاکچین، محدودیتهای برداشت، قراردادهای مالی، بازارهای شرط بندی و موارد مشابه را از طریق یک زبان برنامهنویسی بسیار تعمیمیافته ارائه میدهد. پروتکل اتریوم مستقیماً از هیچ یک از برنامهها پشتیبانی نمیکند، اما وجود یک زبان برنامهنویسی کامل تورینگ به این معنی است که از نظر تئوری میتوان قراردادهای دلخواه را برای هر نوع تراکنش یا برنامهای ایجاد کرد. اما آنچه در مورد اتریوم جالبتر است این است که پروتکل اتریوم بسیار فراتر از ارز است. پروتکلهای حول ذخیرهسازی غیرمتمرکز فایل، محاسبات غیرمتمرکز و بازارهای پیشبینی غیرمتمرکز، در میان دهها مفهوم دیگر، پتانسیل افزایش قابلتوجهی کارایی صنعت محاسبات را دارند، و با افزودن برای اولین بار یک لایه اقتصادی، تقویت گسترده ای برای سایر پروتکل های همتا به همتا فراهم می کند. در نهایت، مجموعهای از برنامههای کاربردی نیز وجود دارد که اصلاً ربطی به پول ندارند.
-
-مفهوم یک تابع انتقال حالت دلخواه که توسط پروتکل اتریوم پیاده سازی شده است، یک پلتفرم با پتانسیل منحصر به فرد را فراهم می کند. به جای اینکه اتریوم یک پروتکل بسته و تک منظوره باشد که برای مجموعه ای از برنامه های کاربردی در ذخیره سازی داده ها، قمار یا امور مالی در نظر گرفته شده است، اتریوم از نظر طراحی دارای پایان باز است. و ما معتقدیم که برای خدمت به عنوان یک لایه اساسی برای تعداد بسیار زیادی از پروتکل های مالی و غیر مالی در سال های آینده بسیار مناسب است.
-
-
-
-## یادداشت ها و مطالعه بیشتر {#notes-and-further-reading}
-
-
-
-### یادداشت ها {#notes}
-
-1. یک خواننده آگاه ممکن است متوجه شود که در واقع یک آدرس بیتکوین هش کلید عمومی منحنی بیضوی است و نه خود کلید عمومی. با این حال، در واقع اصطلاحات رمزنگاری کاملاً قانونی است که به هش پابکی (pubkey) به عنوان خود کلید عمومی اشاره شود. این به این دلیل است که رمزنگاری بیتکوین را می توان یک الگوریتم امضای دیجیتال سفارشی در نظر گرفت، که در آن کلید عمومی از هش کلید pubkey ECC تشکیل شده است، امضا شامل کلید pubkey ECC است که با امضای ECC پیوند خورده است. و الگوریتم تأیید شامل بررسی ECC pubkey در امضا در برابر هش ECC pubkey ارائه شده به عنوان کلید عمومی و سپس تأیید امضای ECC در برابر کلید pubkey ECC است.
-2. از نظر فنی، میانه 11 بلوک قبلی.
-3. از نظر داخلی، 2 و "CHARLIE" هر دو اعداد هستند[fn3](#notes)، که دومی در نمایش پایه 256 بیگ ایندین قرار دارد. اعداد می توانند حداقل 0 و حداکثر 2256-1 باشند.
-
-
-
-### اطلاعات بیشتر {#further-reading}
-
-1. [ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)
-2. [دارایی هوشمند](https://en.bitcoin.it/wiki/Smart_Property)
-3. [قراردادهای هوشمند](https://en.bitcoin.it/wiki/Contracts)
-4. [B-money](http://www.weidai.com/bmoney.txt)
-5. [شواهد کار قابل استفاده مجدد](https://nakamotoinstitute.org/finney/rpow/)
-6. [عناوین ملکی را با اختیار مالک تضمین کنید](https://nakamotoinstitute.org/secure-property-titles/)
-7. [برگه سفید بیت کوین](http://bitcoin.org/bitcoin.pdf)
-8. [Namecoin](https://namecoin.org/)
-9. [مثلت زوکو](https://wikipedia.org/wiki/Zooko's_triangle)
-10. [وایت پیپر سکههای رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)
-11. [وایت پیپر مسترکوین](https://github.com/mastercoin-MSC/spec)
-12. [شرکت های مستقل غیرمتمرکز، مجله بیت کوین](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)
-13. [تأیید پرداخت ساده](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)
-14. [درختان مرکل](https://wikipedia.org/wiki/Merkle_tree)
-15. [درختان پاتریشیا](https://wikipedia.org/wiki/Patricia_tree)
-16. [GHOST](https://eprint.iacr.org/2013/881.pdf)
-17. [StorJ و ایجنت های خودمختار، جف گارزیک](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html)
-18. [مایک هرن در مورد املاک هوشمند در جشنواره تورینگ](https://www.youtube.com/watch?v=MVyv4t0OKe4)
-19. [Ethereum RLP](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP)
-20. [درخت مرکل پاتریشیا اتریوم](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree)
-21. [پیتر تاد درباره درختان مرکل](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/)
-
-_برای تاریخچه وایت پیپر، [این ویکی](https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md) را ببینید._
-
-_اتریوم، مانند بسیاری از پروژههای نرمافزاری متنباز و مبتنی بر کامیونیتی، از زمان شروع اولیه خود تکامل یافته است. برای اطلاع از آخرین پیشرفتهای اتریوم و اینکه تغییرات در پروتکل چگونه اعمال میشوند، [این راهنما](/learn/) را توصیه میکنیم._
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md
deleted file mode 100644
index 2b8a0853c56..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/bridges/index.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: پلها
-description: مروری بر پل زدن برای توسعهدهندگان
-lang: fa
----
-
-با گسترش بلاکچین های L1 و راه حل های [مقیاس پذیری](/developers/docs/scaling/) L2، در کنار تعداد روزافزون برنامه های غیرمتمرکز که به صورت زنجیره ای متقابل انجام می شوند، نیاز به ارتباطات و جابجایی دارایی ها در میان زنجیره ها به بخشی ضروری از زیرساخت شبکه تبدیل شده است. انواع مختلفی از پل ها برای کمک به این وضعیت وجود دارد.
-
-## نیاز به پل ها {#need-for-bridges}
-
-پل هایی برای اتصال شبکه های بلاکچین وجود دارند. آنها اتصال و قابلیت همکاری بین بلاکچین ها را امکانپذیر می کنند.
-
-بلاکچین ها در محیط های سیلو وجود دارند، به این معنی که هیچ راهی برای تجارت و ارتباط طبیعی با بلاکچین های دیگر وجود ندارد. در نتیجه، در حالی که می تواند فعالیت و نوآوری قابل توجهی در یک اکوسیستم وجود داشته باشد، به دلیل عدم اتصال و قابلیت همکاری با سایر اکوسیستم ها محدود شده است.
-
-پل ها راهی برای ارتباط محیط های بلاکچین ایزوله با یکدیگر ارائه می دهند. آنها یک مسیر حمل و نقل بین بلاکچین ایجاد می کنند که در آن توکن ها، پیام ها، داده های دلخواه و حتی تماس های [قرارداد هوشمند](/developers/docs/smart-contracts/) می توانند از یک زنجیره به زنجیره دیگر منتقل شوند.
-
-## مزایای پل ها {#benefits-of-bridges}
-
-به زبان ساده، پل ها با اجازه دادن به شبکه های بلاکچین برای تبادل داده ها و جابجایی دارایی ها بین آنها، موارد استفاده متعدد را باز می کنند.
-
-بلاکچین ها دارای نقاط قوت، ضعف و رویکردهای منحصر به فردی برای ساخت برنامه های کاربردی هستند (مانند سرعت، توان عملیاتی، هزینه و غیره). پلها به توسعه اکوسیستم رمزنگاری کلی کمک میکنند و بلاکچینها را قادر میسازند تا از نوآوریهای یکدیگر استفاده کنند.
-
-برای توسعه دهندگان، پل ها موارد زیر را فعال می کنند:
-
-- انتقال هر گونه داده، اطلاعات و دارایی در زنجیره ها.
-- باز کردن قفل ویژگی های جدید و موارد استفاده برای پروتکل ها به عنوان پل، فضای طراحی را برای آنچه پروتکل ها می توانند ارائه دهند گسترش می دهند. به عنوان مثال، یک پروتکل برای فارمینگ بهره که در اصل در شبکه اصلی اتریوم مستقر شده است، میتواند استخرهای نقدینگی را در تمام زنجیرههای سازگار با EVM ارائه دهد.
-- فرصتی برای استفاده از نقاط قوت بلاکچین های مختلف. به عنوان مثال، توسعهدهندگان میتوانند از هزینههای کمتری که راهحلهای L2 مختلف ارائه میکنند، با استقرار دپ های خود در سرتاسر مجموعهها، بهرهمند شوند، و زنجیرههای جانبی و کاربران میتوانند روی آنها پل بزنند.
-- همکاری بین توسعه دهندگان از اکوسیستم های مختلف بلاکچین برای ساخت محصولات جدید.
-- جذب کاربران و جوامع از اکوسیستم های مختلف به برنامه های خود.
-
-## پل ها چگونه کار می کنند؟ {#how-do-bridges-work}
-
-در حالی که [انواع زیادی از طرح های پل](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) وجود دارد، سه راه برای تسهیل انتقال زنجیره ای متقابل دارایی ها برجسته است:
-
-- **قفل و ضرب کردن-** داراییها را در زنجیره مبدا قفل کنید و داراییها را در زنجیره مقصد ضرب کنید.
-- **سوزاندن و ضرب کردن –** سوزاندن دارایی ها در زنجیره مبدا و ضرب دارایی ها در زنجیره مقصد.
-- **سوآپهای اتمی –** داراییهای موجود در زنجیره مبدا را با داراییهای زنجیره مقصد با طرف دیگر مبادله کنید.
-
-## اواع پل ها {#bridge-types}
-
-پل ها را معمولاً می توان به یکی از سبد های زیر طبقه بندی کرد:
-
-- **پلهای بومی –** این پلها معمولاً برای راهاندازی نقدینگی در یک بلاکچین خاص ساخته میشوند و انتقال وجوه به اکوسیستم را برای کاربران آسانتر میکنند. به عنوان مثال، [پل آربیتروم](https://bridge.arbitrum.io/) به گونهای ساخته شده است که اتصال از شبکه اصلی اتریوم به آربیتروم را برای کاربران راحت کند. از دیگر پل های این چنینی می توان به پل Polygon PoS Bridge، [Optimism Gateway](https://app.optimism.io/bridge) و غیره اشاره کرد.
-- **پلهای مبتنی بر اعتبارسنج یا اوراکل -** این پلها برای اعتبارسنجی انتقالهای بین زنجیرهای به مجموعه یا اوراکلهای اعتبارسنج خارجی متکی هستند. مثال: Multichain و Across.
-- **پلهای ارسال پیام عمومی -** این پلها میتوانند داراییها را همراه با پیامها و دادههای دلخواه در زنجیرهها انتقال دهند. نمونه: Axelar و LayerZero و Nomad.
-- **شبکه های نقدینگی -** این پل ها در درجه اول بر انتقال دارایی ها از یک زنجیره به زنجیره دیگر از طریق سوآپ اتمی تمرکز دارند. به طور کلی، آنها از ارسال پیام بین زنجیره ای پشتیبانی نمی کنند. نمونه: Connext و Hop.
-
-## مبادلات قابل تامل {#trade-offs}
-
-با پل ها، هیچ راه حل کاملی وجود ندارد. در عوض، فقط مبادلاتی برای تحقق یک هدف وجود دارد. توسعه دهندگان و کاربران می توانند پل ها را بر اساس عوامل زیر ارزیابی کنند:
-
-- **امنیت -** چه کسی سیستم را تأیید می کند؟ پل هایی که توسط اعتبارسنجهای خارجی ایمن می شوند، معمولاً نسبت به پل هایی که به صورت محلی یا بومی توسط اعتبارسنج های بلاکچین ایمن شده اند، امنیت کمتری دارند.
-- **راحتی -** چه مدت طول می کشد تا یک تراکنش کامل شود و یک کاربر به چند تراکنش نیاز داشت تا امضا کند؟ برای یک توسعه دهنده، چقدر طول می کشد تا یک پل یکپارچه شود، و این فرآیند چقدر پیچیده است؟
-- **اتصال -** زنجیرههای مختلف مقصد که یک پل میتواند به یکدیگر متصل کند (به عنوان مثال، زنجیرههای جانبی، سایر بلاکچینهای لایه 1 و غیره) چیست و ادغام یک بلاکچین جدید چقدر سخت است؟
-- **قابلیت انتقال دادههای پیچیدهتر –** آیا پل میتواند انتقال پیامها و دادههای دلخواه پیچیدهتر را در زنجیرهها فعال کند یا فقط از انتقال داراییهای بین زنجیرهای پشتیبانی میکند؟
-- **مقرون به صرفه بودن -** هزینه انتقال دارایی ها در بین زنجیره ها از طریق یک پل چقدر است؟ به طور معمول، پل ها بسته به هزینه های گس و نقدینگی مسیرهای خاص، هزینه ثابت یا متغیری را دریافت می کنند. همچنین ارزیابی مقرون به صرفه بودن یک پل بر اساس سرمایه مورد نیاز برای اطمینان از امنیت آن بسیار مهم است.
-
-در سطح بالا، پل ها را می توان به عنوان قابل اعتماد و غیر قابل اعتماد طبقه بندی کرد.
-
-- **قابل اعتماد–** پل های قابل اعتماد به صورت خارجی تأیید می شوند. آنها از مجموعهای خارجی از تأییدکنندهها (فدراسیونهایی با سیستمهای محاسباتی چندگانه، چند حزبی، شبکه اوراکل) برای ارسال دادهها در زنجیرهها استفاده میکنند. در نتیجه، آنها می توانند اتصال عالی را ارائه دهند و امکان ارسال پیام کاملاً تعمیم یافته را از طریق زنجیره ها فراهم کنند. آنها همچنین تمایل دارند با سرعت و مقرون به صرفه عملکرد خوبی داشته باشند. این به قیمت امنیت تمام می شود، زیرا کاربران باید به امنیت پل اتکا کنند.
-- **غیر قابل اعتماد –** این پلها برای انتقال پیامها و توکن ها، به بلاکچین هایی که وصل میکنند و اعتبارسنجهای آنها متکی هستند. آنها «عیر قابل اعتماد» هستند زیرا فرضیات اعتماد جدیدی را اضافه نمی کنند (علاوه بر بلاکچین). در نتیجه، پلهای غیرقابل اعتماد نسبت به پلهای قابل اعتماد از امنیت بیشتری برخوردار هستند.
-
-برای ارزیابی پلهای غیرقابل اعتماد بر اساس عوامل دیگر، باید آنها را به پلهای انتقال پیام عمومی و شبکههای نقدینگی تقسیم کنیم.
-
-- **پل های ارسال پیام عمومی –** این پل ها از نظر امنیت و توانایی انتقال داده های پیچیده تر در زنجیره ها عالی هستند. به طور معمول، آنها همچنین از نظر مقرون به صرفه بودن خوب هستند. با این حال، این نقاط قوت عموماً با کاهش اتصال برای پلهای کلاینت سبک (مثلاً IBC) و معایب سرعت برای پلهای خوشبینانه (مثلاً: Nomad) است که از اثبات تقلب استفاده میکنند.
-- **شبکههای نقدینگی -** این پلها از مبادله اتمی برای انتقال داراییها استفاده میکنند و سیستمهای تأیید شده محلی هستند (یعنی از اعتبارسنج های بلاکچین برای تأیید تراکنشها استفاده میکنند). در نتیجه، از نظر امنیت و سرعت برتری دارند. علاوه بر این، نسبتاً مقرون به صرفه در نظر گرفته می شوند و اتصال خوبی را ارائه می دهند. با این حال، ایراد اصلی ناتوانی آنها در انتقال داده های پیچیده تر است - زیرا از ارسال پیام زنجیره ای پشتیبانی نمی کنند.
-
-## خطر استفاده از پلها {#risk-with-bridges}
-
-پل ها سه مورد از [بزرگترین هک ها در دیفای](https://rekt.news/leaderboard/) را تشکیل می دهند و هنوز در مراحل اولیه توسعه است. استفاده از هر پل خطرات زیر را به همراه دارد:
-
-- **خطر قرارداد هوشمند -** در حالی که بسیاری از پلها با موفقیت ممیزی را پشت سر گذاشتهاند، تنها یک نقص در قرارداد هوشمند لازم است تا داراییها در معرض هک قرار گیرند (مثلاً: [پل Wormhole سولانا](https://rekt.news/wormhole-rekt/)).
-- **ریسکهای مالی سیستمی** - بسیاری از پلها از داراییهای رپ شده برای ضرب کردن نسخههای متعارف دارایی اصلی در یک زنجیره جدید استفاده میکنند. این امر اکوسیستم را در معرض خطر سیستماتیک قرار می دهد، زیرا شاهد بهره برداری از نسخه های رپ شده توکن ها بودیم.
-- **خطر طرف مقابل -** برخی از پلها از طراحی قابل اعتمادی استفاده میکنند که کاربران را ملزم میکند بر این فرض تکیه کنند که اعتبارسنج ها برای سرقت وجوه کاربران تبانی نمیکنند. نیاز کاربران به اعتماد به این بازیگران طرف ثالث، آنها را در معرض خطراتی مانند راگ پول، سانسور و سایر فعالیتهای مخرب قرار میدهد.
-- **مسئلههای باز -** با توجه به اینکه پل ها در مراحل اولیه توسعه هستند، سوالات بی پاسخ بسیاری در رابطه با نحوه عملکرد پل ها در شرایط مختلف بازار وجود دارد. مانند زمان ازدحام شبکه و در طول رویدادهای پیش بینی نشده مانند حملات در سطح شبکه یا رولبکهای حالت. این عدم قطعیت خطرات خاصی را به همراه دارد که درجه آن هنوز مشخص نیست.
-
-## چگونه dapp ها می توانند از پل ها استفاده کنند؟ {#how-can-dapps-use-bridges}
-
-در اینجا چند برنامه کاربردی وجود دارد که توسعه دهندگان می توانند در مورد پل ها و استفاده از زنجیره متقابل dapp خود در نظر بگیرند:
-
-### یکپارچه سازی پل ها {#integrating-bridges}
-
-برای توسعه دهندگان، راه های زیادی برای اضافه کردن پشتیبانی برای پل ها وجود دارد:
-
-1. **ساختن پل خودتان -** ساختن پل ایمن و قابل اعتماد آسان نیست، به خصوص اگر مسیری را انتخاب کنید که اعتماد به حداقل برسد. علاوه بر این، به سالها تجربه و تخصص فنی مرتبط با مطالعات مقیاس پذیری و قابلیت همکاری نیاز دارد. علاوه بر این، به یک تیم عملی برای حفظ یک پل و جذب نقدینگی کافی برای امکانپذیر کردن آن نیاز دارد.
-
-2. **نمایش چندین گزینه پل به کاربران -** بسیاری از [دپ ها](/developers/docs/dapps/) از کاربران میخواهند توکن بومی خود را داشته باشند تا با آنها تعامل داشته باشند. برای اینکه کاربران بتوانند به توکن های خود دسترسی داشته باشند، گزینه های پل متفاوتی را در وب سایت خود ارائه می دهند. با این حال، این روش یک راه حل سریع برای این مشکل است، زیرا کاربر را از رابط dapp دور می کند و همچنان نیاز به تعامل با دیگر dapp ها و پل ها دارد. این یک تجربه حضوری دست و پا گیر با دامنه افزایش اشتباهات است.
-
-3. **یکپارچه سازی یک پل –** این راه حل نیازی به ارسال کاربران به پل خارجی و رابط های DEX ندارد. این به dapp ها اجازه می دهد تا تجربه ورود کاربر را بهبود بخشند. با این حال، این رویکرد دارای محدودیت هایی است:
-
- - ارزیابی و نگهداری پل ها سخت و زمان بر است.
- - انتخاب یک پل یک نقطه شکست و وابستگی ایجاد می کند.
- - دپ، با قابلیت های پل محدود می شود.
- - پل ها به تنهایی ممکن است کافی نباشند. Dapp ها ممکن است برای ارائه عملکردهای بیشتری مانند تبادل زنجیره ای به DEX نیاز داشته باشند.
-
-4. **یکپارچه سازی چندین پل –** این راه حل بسیاری از مشکلات مربوط به یکپارچه سازی یک پل را حل می کند. با این حال، محدودیتهایی نیز دارد، زیرا یکپارچهسازی پلهای متعدد منابع را مصرف میکند و هزینههای فنی و ارتباطی را برای توسعهدهندگان ایجاد میکند – کمیابترین منبع در دنیای رمزارز.
-
-5. **یکپارچه سازی یک پل جمع کننده –** گزینه دیگر برای dapp ها یکپارچه سازی راه حل تجمیع پل است که به آنها امکان دسترسی به پل های متعدد را می دهد. جمعکنندههای پل، نقاط قوت همه پلها را به ارث میبرند و بنابراین با قابلیتهای هیچ پل محدود نمیشوند. نکته قابل توجه، جمعکنندههای پل معمولاً ادغامهای پل را حفظ میکنند، که باعث میشود دپ از دردسر ماندن در بالای جنبههای فنی و عملیاتی یکپارچهسازی پل نجات یابد.
-
-همانطور که گفته شد، جمع کننده های پل نیز محدودیت های خود را دارند. به عنوان مثال، در حالی که آنها می توانند گزینه های پل بیشتری را ارائه دهند، پل های بسیار بیشتری به غیر از پلتفرم های ارائه شده در پلت فرم جمع کننده معمولاً در بازار موجود است. علاوه بر این، درست مانند پلها، جمعکنندههای پل نیز در معرض خطرات قرارداد هوشمند و فناوری هستند (قراردادهای هوشمند بیشتر = خطرات بیشتر).
-
-اگر یک dapp مسیر ادغام یک پل یا یک تجمیع کننده را طی کند، گزینه های مختلفی بر اساس عمق ادغام وجود دارد. به عنوان مثال، اگر این فقط یک ادغام جلویی برای بهبود تجربه ورود کاربر باشد، یک dapp ویجت را ادغام می کند. با این حال، اگر ادغام برای کاوش استراتژیهای بین زنجیرهای متقابل عمیقتر مانند سهامگذاری، ییلد فارمینگ و غیره باشد، دپ اقدام به ادغام SDK یا API میکند.
-
-### استقرار یک dapp در چندین زنجیره {#deploying-a-dapp-on-multiple-chains}
-
-برای استقرار یک dapp در چندین زنجیره، توسعهدهندگان میتوانند از پلتفرمهای توسعه مانند [Alchemy](https://www.alchemy.com/)، [Hardhat](https://hardhat.org/)، [Truffle](https://trufflesuite.com/)، [Moralis](https://moralis.io/) ، و غیره استفاده کنند. به طور معمول، این پلتفرمها با پلاگینهای قابل ترکیبی عرضه میشوند که میتوانند dappها را قادر به انجام فعالیت بین زنجیرهای کنند. به عنوان مثال، توسعه دهندگان می توانند از یک پراکسی استقرار قطعی ارائه شده توسط [افزونه hardhat-deploy](https://github.com/wighawag/hardhat-deploy) استفاده کنند.
-
-#### مثال ها:
-
-- [نحوه ساخت دپ های بین زنجیره ای](https://moralis.io/how-to-build-cross-chain-dapps/)
-- [ساختن یک مارکتپلیس NFT بین زنجیره ای](https://youtu.be/WZWCzsB1xUE)
-- [Moralis: ساختن دپ های NFT بین زنجیره ای](https://www.youtube.com/watch?v=ehv70kE1QYo)
-
-### نظارت بر فعالیت قرارداد در سراسر زنجیره {#monitoring-contract-activity-across-chains}
-
-برای نظارت بر فعالیت قرارداد بین زنجیرهای، توسعهدهندگان میتوانند از زیرگرافها و پلتفرمهای توسعهدهنده مانند Tenderly برای مشاهده قراردادهای هوشمند در زمان واقعی استفاده کنند. چنین پلتفرمهایی همچنین دارای ابزارهایی هستند که عملکرد نظارت بیشتری بر دادهها را برای فعالیتهای زنجیرهای متقابل ارائه میکنند، مانند بررسی [رویدادهای منتشر شده توسط قراردادها](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) و غیره.
-
-#### ابزارها
-
-- [The Graph](https://thegraph.com/en/)
-- [Tenderly](https://tenderly.co/)
-
-## بیشتر بخوانید {#further-reading}
-
-- [پلهای بلاکچین](/bridges/) – ethereum.org
-- [پلهای بلاکچین: ساختن شبکههای رمزنگاری](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 8 سپتامبر 2021 – Dmitriy Berenzon
-- [قابلیت عملیات متقابل Trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 1 اکتبر 2021 – Arjun Bhuptani
-- [خوشهها: پلهای قابل اعتماد و & دارای اعتماد حداقل چگونه دورنمای مالتیچین را شکل میدهند](https://blog.celestia.org/clusters/)4 اکتبر 2021 – Mustafa Al-Bassam
-- [LI.FI: با پلها، اعتماد یک طیف است](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 28 آوریل 2022 – Arjun Chand
-
-همچنین، اینجا بعضی تعاریف پرمعنی از [James Prestwich](https://twitter.com/_prestwich) وجود دارد که میتوانند به درک عمیقتر از پلها کمک کنند:
-
-- [ساختن پلها، نه باغهای دیواردار](https://youtu.be/ZQJWMiX4hT0)
-- [فرو ریختن پلها](https://youtu.be/b0mC-ZqN8Oo)
-- [چرا پلها میسوزند](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
deleted file mode 100644
index 31d737eb12a..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: راهکار های ذخیرهسازی داده در بلاکچین
-description: چندین راه مختلف برای ذخیرهسازی داده با استفاده از بلاکچین وجود دارد. این مقاله به مقایسه استراتژیهای مختلف، مزایا و معایب هرکدام و پیشنیازهای استفاده امن آنها میپردازد.
-lang: fa
----
-
-راههای مختلفی وجود دارد تا دادهها را چه بهصورت مستقیم در بلاکچین و چه با روشی که امنیت آن از طریق بلاکچین تأمین شود، ذخیرهسازی کرد:
-
-- بلابهای EIP-4844
-- دادهی فراخوانی (calldata)
-- خارج از زنجیره ولی بهره گرفته از مکانیزم بلاکچین لایه 1
-- "کد" قرارداد
-- رویدادها
-- حافظه ابدی ماشین مجازی اتریوم (EVM storage)
-
-انتخاب روش مورد استفاده بر اساس چندین معیار است:
-
-- منبع اطلاعات. اطلاعات موجود در دادهی فراخوانی (calldata) مستقیماً از خود بلاکچین نشأت نمیگیرند.
-- مقصد اطلاعات. Calldata فقط در تراکنشی که شروع می کند در دسترس است. رویدادها به هیچ وجه به صورت زنجیره ای قابل دسترسی نیستند.
-- چقدر دردسر قابل قبول است؟ رایانههایی که یک گره در مقیاس کامل اجرا میکنند میتوانند پردازش بیشتری نسبت به یک کلاینت سبک در برنامهای که در مرورگر اجرا میشود انجام دهند.
-- آیا تسهیل دسترسی آسان به اطلاعات از هر گره ضروری است؟
-- الزامات امنیتی.
-
-## الزامات امنیتی {#security-requirements}
-
-به طور کلی امنیت اطلاعات شامل سه ویژگی است:
-
-- _محرمانگی، اشخاص غیر مجاز، مجاز به خواندن اطلاعات نیستند. این در بسیاری از موارد مهم است، اما در اینجا نه. _ هیچ رازی در بلاکچین وجود ندارد _. بلاک چینها کار می کنند زیرا هر کسی می تواند انتقال حالت را تأیید کند، بنابراین استفاده از آنها برای ذخیره مستقیم اسرار غیرممکن است. راههایی برای ذخیره اطلاعات محرمانه در بلاکچین وجود دارد، اما همه آنها برای ذخیره حداقل یک کلید به برخی اجزای خارج از زنجیره متکی هستند.
-
-- _یکپارچگی_، اطلاعات صحیح است، نمی توان آن را توسط نهادهای غیرمجاز یا به روش های غیرمجاز تغییر داد (به عنوان مثال، انتقال [توکن های ERC-20] (https://eips.ethereum.org/EIPS/eip-20#events) بدون یک رویداد "انتقال"). در بلاکچین، هر گره هر تغییر حالت را تأیید می کند که یکپارچگی را تضمین می کند.
-
-- _در دسترس بودن_، اطلاعات در دسترس هر نهاد مجاز است. در بلاکچین، این امر معمولاً با داشتن اطلاعات در دسترس در هر [گره کامل] (https://ethereum.org/developers/docs/nodes-and-clients#full-node) به دست می آید.
-
-راه حل های مختلف در اینجا همه یکپارچگی عالی دارند، زیرا هش ها در L1 ارسال می شوند. با این حال، آنها دارای ضمانت های مختلف در دسترس بودن هستند.
-
-## پیش نیازها {#prerequisites}
-
-شما باید درک خوبی از [اصول بلاکچین] (/developers/docs/intro-to-ethereum/) داشته باشید. این صفحه همچنین فرض میکند که خواننده با [blocks](/developers/docs/blocks/)، [تراکنش ها](/developers/docs/transactions/) و سایر موضوعات مرتبط آشنا است.
-
-## حباب های EIP-4844 {#eip-4844-blobs}
-
-در شروع با [هاردفورک دنکان] (https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md)، بلاک چین اتریوم شامل [EIP-4844] است (https:// eips.ethereum.org/EIPS/eip-4844)، که به حباب های داده اتریوم با طول عمر محدود (در ابتدا حدود [18 روز]) اضافه می کند (https://github.com/ethereum/consensus-specs/blob/dev/specs) /deneb/p2p-interface.md#configuration)). این حباب ها جدا از [گس اجرا](/developers/docs/gas) قیمت گذاری می شوند، اگرچه از مکانیزم مشابهی استفاده می کنند. آنها یک راه ارزان برای ارسال داده های موقت هستند.
-
-مورد استفاده اصلی برای حباب های EIP-4844 این است که رولآپ ها تراکنش های خود را منتشر کنند. [رولآپهای خوشبینانه](/developers/docs/scaling/optimistic-rollups) باید تراکنشها را روی بلاکچینهای خود منتشر کنند. این تراکنشها باید در طول [دوره چالش](https://docs.optimism.io/connect/resources/glossary#challenge-period) در دسترس همه باشند تا اگر [ترتیبدهنده](https://docs.optimism.io/connect/resources/glossary#sequencer) رولآپ یک ریشه وضعیت نادرست را ارسال کند، [اعتبارسنجها](https://docs.optimism.io/connect/resources/glossary#validator) را قادر میسازد تا اشتباه را برطرف کنند.
-
-با این حال، هنگامی که دوره چالش سپری شد و ریشه حالت نهایی شد، هدف باقی مانده برای دانستن این تراکنش ها تکرار وضعیت فعلی زنجیره است. این حالت از گره های زنجیره ای نیز در دسترس است و به پردازش بسیار کمتری نیاز است. بنابراین، اطلاعات تراکنش همچنان باید در چند مکان، مانند [کاوشگران بلوک] (/developers/docs/data-and-analytics/block-explorers) حفظ شود، اما نیازی به پرداخت هزینه برای سطح مقاومت سانسوری که اتریوم ارائه می کند نیست.
-
-[رولآپهای دانش-صفر](/developers/docs/scaling/zk-rollups/#data-availability) همچنین دادههای تراکنش خود را ارسال میکنند تا دیگر گرهها بتوانند وضعیت موجود را تکرار کنند و اثبات اعتبار را تأیید کنند، اما باز هم این یک نیاز کوتاه مدت است.
-
-هنگام نوشتن پست در EIP-4844 یک وی (10-18 ETH) در هر بایت هزینه دارد، که در مقایسه با [21000 گس اجرا که هر تراکنش، از جمله تراکنشی که حبابها را پست میکند، هزینه دارد، ناچیز است](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). میتوانید قیمت فعلی EIP-4844 را در [blobscan.com] (https://blobscan.com/blocks) ببینید.
-
-در اینجا آدرس هایی برای مشاهده حباب های ارسال شده توسط برخی از مجموعه های معروف وجود دارد.
-
-| رولآپ | آدرس Mailbox |
-| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
-| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) |
-| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
-| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) |
-
-## کالدیتا {#calldata}
-
-Calldata به بایت های ارسال شده به عنوان بخشی از تراکنش اشاره دارد. به عنوان بخشی از رکورد دائمی بلاکچین در بلوک که شامل آن تراکنش است، ذخیره می شود.
-
-این ارزانترین روش برای قرار دادن دائمی داده ها در بلاکچین است. هزینه هر بایت یا 4 گس اجرا (اگر بایت صفر باشد) یا 16 گس (هر مقدار دیگر) است. اگر داده ها فشرده شوند، که یک روش استاندارد است، هر مقدار بایت به یک اندازه محتمل است، بنابراین میانگین هزینه تقریباً 15.95 گس در هر بایت است.
-
-در نوشتن قیمت ها 12 جیوی/گس و 2300 دلار/اتر است، که به این معنی است که هزینه تقریباً 45 سنت در هر کیلوبایت است. از آنجایی که این ارزانترین روش قبل از EIP-4844 بود، این روشی است که برای ذخیره اطلاعات تراکنش استفاده میشود، که باید برای [چالشهای خطا] در دسترس باشد (https://docs.optimism.io/stack/protocol/overview# اثبات عیب)، اما نیازی به دسترسی مستقیم روی زنجیره نیست.
-
-در اینجا آدرس هایی برای مشاهده تراکنش های ارسال شده توسط چند مجموعه معروف وجود دارد.
-
-| رولآپ | آدرس Mailbox |
-| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
-| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) |
-| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) |
-| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) |
-
-## خارج از زنجیره با مکانیسم های لایه 1 {#offchain-with-l1-mechs}
-
-بسته به دوراهی های امنیتی شما، ممکن است قابل قبول باشد که اطلاعات را در جای دیگری قرار دهید و از مکانیزمی استفاده کنید که تضمین کند داده ها در صورت نیاز در دسترس هستند. دو شرط برای این کار وجود دارد:
-
-1. یک [هش] (https://en.wikipedia.org/wiki/Cryptographic_hash_function) از دادهها را روی بلاکین پست کنید، که به آن _input commitment_ میگویند. این می تواند یک کلمه 32 بایتی باشد، بنابراین گران نیست. تا زمانی که تعهد ورودی در دسترس باشد، یکپارچگی تضمین میشود، زیرا یافتن دادههای دیگری که به همان مقدار هش شوند امکانپذیر نیست. بنابراین اگر داده های نادرست ارائه شود، می توان آن را شناسایی کرد.
-
-2. مکانیزمی داشته باشید که در دسترس بودن را تضمین کند. برای مثال، در [Redstone](https://redstone.xyz/docs/what-is-redstone) هر گرهی می تواند یک چالش در دسترس بودن ارسال کند. اگر ترتیبدهنده در مهلت مقرر به زنجیره پاسخ ندهد، تعهد ورودی کنار گذاشته میشود، بنابراین در نظر گرفته میشود که اطلاعات هرگز پست نشده است.
-
-این برای یک رولآپ خوشبینانه قابل قبول است زیرا ما در حال حاضر به داشتن حداقل یک تأیید کننده صادق برای ریشه حالت تکیه می کنیم. چنین تأیید کننده صادقی همچنین مطمئن می شود که داده هایی برای پردازش بلوک ها دارد و اگر اطلاعات در خارج از زنجیره در دسترس نباشد، چالش در دسترس بودن را صادر می کند. این نوع رولآپ خوشبینانه، [پلاسما](/developers/docs/scaling/plasma/) نامیده میشود.
-
-## کد قرارداد {#contract-code}
-
-اطلاعاتی که فقط باید یک بار نوشته شوند، هرگز بازنویسی نمی شوند و باید در زنجیره در دسترس باشند، می توانند به عنوان کد قرارداد ذخیره شوند. این بدان معنی است که ما یک "قرارداد هوشمند" با داده ها ایجاد می کنیم و سپس از [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) برای خواندن اطلاعات استفاده می کنیم. مزیت این است که کپی کردن کد نسبتاً ارزان است.
-
-به غیر از هزینه گسترش حافظه، «EXTCODECOPY» برای اولین دسترسی به قرارداد 2600 گس و برای نسخه های بعدی از همان قرارداد 100 گس به همراه 3 گس در هر کلمه 32 بایتی هزینه دارد. در مقایسه با calldata که 15.95 در هر بایت هزینه دارد، در آغاز حدود 200 بایت ارزانتر است. بر اساس [فرمول هزینه های گسترش حافظه] (https://www.evm.codes/about#memoryexpansion)، تا زمانی که به بیش از 4 مگابایت حافظه نیاز ندارید، هزینه گسترش حافظه کمتر از هزینه افزودن calldata است.
-
-البته این فقط هزینه _خواندن_ داده هاست. برای ایجاد قرارداد تقریباً 32000 گس + 200 گس برای هر بایت هزینه می شود. این روش تنها زمانی مقرون به صرفه است که اطلاعات یکسان در معاملات مختلف بارها خوانده شود.
-
-کد قرارداد تا زمانی که با '0xEF' شروع نشود می تواند بی معنی باشد. قراردادهایی که با «0xEF» شروع میشوند به عنوان [فرمت شی اتریوم] (https://notes.ethereum.org/@ipsilon/evm-object-format-overview) تفسیر میشوند که الزامات بسیار سختتری دارد.
-
-## رویدادها {#events}
-
-[رویدادها] (https://docs.alchemy.com/docs/solidity-events) توسط قراردادهای هوشمند منتشر میشوند و توسط نرمافزار خارج از زنجیره خوانده میشوند.
-مزیت آنها این است که کدهای آفلاین می توانند به رویدادها گوش دهند. هزینه [گس] (https://www.evm.codes/#a0?fork=cancun)، 375 به اضافه 8 گس در هر بایت داده است. در 12 گیگاوی/گس و 2300 دلار/اتر، این به یک سنت به اضافه 22 سنت در هر کیلوبایت ترجمه میشود.
-
-## ذخیرهسازی {#storage}
-
-قراردادهای هوشمند به [حافظه های دائمی] (https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) دسترسی دارند. با این حال، بسیار گران است. نوشتن یک کلمه 32 بایتی در یک اسلات از حافظه که قبلاً خالی بود، میتواند [22100 گس هزینه داشته باشد] (https://www.evm.codes/#55?fork=cancun). در 12 گیگاوی/گس و 2300 دلار/اتر،این حدود 61 سنت در هر عملیات نوشتن یا 19.5 دلار در هر کیلوبایت است.
-
-این گرانترین شکل ذخیرهسازی در اتریوم است.
-
-## خلاصه {#summary}
-
-این جدول تفاوت گزینه ها، مزایا و معایب آنها را خلاصه می کند.
-
-| نوع ذخیرهسازی | منبع دیتا | تضمین دسترسیپذیری | دسترسیپذیری آنچین | محدودیتهای دیگر |
-| -------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
-| بلابهای EIP-4844 | آفچین | ضمانت اتریوم برای [حدود 18 روز](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | فقط هش موجود است | |
-| دادهی فراخوانی (calldata) | آفچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | فقط در صورت نوشته شدن در قرارداد و در آن معامله در دسترس است | |
-| خارج از زنجیره ولی بهره گرفته از مکانیزم بلاکچین لایه 1 | آفچین | تضمین "یک تایید کننده صادق" در طول دوره چالش | فقط هش | تضمین شده توسط مکانیسم چالش، فقط در طول دوره چالش |
-| کد قرارداد | آنچین یا آفچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | بله | نوشته شده در یک آدرس "تصادفی"، نمی تواند با "0xEF" شروع شود |
-| رویدادها | آنچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین) | خیر | |
-| ذخیرهسازی | آنچین | تضمین اتریوم برای همیشه (بخشی از بلاکچین و وضعیت فعلی تا زمانی که بازنویسی شود) | بله | |
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md
deleted file mode 100644
index ca4f63135b8..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/data-availability/index.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: دسترسی به دادهها
-description: مروری بر مشکلات و راه حل های مربوط به در دسترس بودن داده ها در اتریوم
-lang: fa
----
-
-«اعتماد نکن، تایید کن» یک اصل رایج در اتریوم است. ایده این است که گره شما میتواند به طور مستقل صحت اطلاعاتی را که دریافت میکند با اجرای تمام تراکنشهای موجود در بلوکهایی که از همتایان دریافت میکنند تأیید کند تا اطمینان حاصل شود که تغییرات پیشنهادی دقیقاً با تغییرات محاسبهشده مستقل توسط گره مطابقت دارند. این بدان معناست که گرهها نباید به صادق بودن فرستندگان بلوک اعتماد کنند. در صورت عدم وجود داده، این امکان پذیر نیست.
-
-**در دسترس بودن داده** به اطمینان کاربر از اینکه داده های مورد نیاز برای تأیید یک بلوک واقعاً در دسترس همه شرکت کنندگان شبکه است، اشاره دارد. برای گرههای کامل در لایه 1 اتریوم، این کار نسبتاً ساده است. گره کامل یک کپی از تمام دادههای هر بلوک را دانلود میکند - دادهها _باید_ در دسترس باشند تا امکان دانلود وجود داشته باشد. بلوکی با داده های از دست رفته به جای اضافه شدن به بلاکچین، دور انداخته می شود. این "در دسترس بودن داده های زنجیره ای" است و یکی از ویژگی های بلاک چین های یکپارچه است. گره های کامل را نمی توان فریب داد تا تراکنش های نامعتبر را بپذیرند زیرا آنها هر تراکنش را برای خود دانلود و اجرا می کنند. با این حال، برای بلاک چینهای مدولار، رولآپ های لایه 2 و کلاینت های سبک، چشمانداز در دسترس بودن دادهها پیچیدهتر است و به برخی روشهای تأیید پیچیدهتر نیاز دارد.
-
-## پیشنیازها {#prerequisites}
-
-شما باید درک خوبی از [اصول بلاک چین](/developers/docs/intro-to-ethereum/)، به خصوص [مکانیسم های اجماع](/developers/docs/consensus-mechanisms/) داشته باشید. این صفحه همچنین فرض میکند که خواننده با [بلوکها](/developers/docs/blocks/)، [تراکنش ها](/developers/docs/transactions/)، [گرهها](/developers/docs/nodes-and-clients/)، [راهحلهای مقیاسبندی](/developers/docs/scaling/) و سایر موضوعات مرتبط آشنا است.
-
-## مشکل در دسترس بودن داده ها {#the-data-availability-problem}
-
-مشکل در دسترس بودن داده ها این است که باید به کل شبکه ثابت شود که شکل خلاصه شده برخی از داده های تراکنش که به بلاک چین اضافه می شود، واقعاً مجموعه ای از تراکنش های معتبر را نشان می دهد، اما بدون نیاز به همه گره ها برای دانلود همه داده ها. دادههای کامل تراکنش برای تأیید مستقل بلوکها ضروری است، اما نیاز به تمام گرهها برای دانلود همه دادههای تراکنش، مانعی برای مقیاسپذیری است. هدف راهحلهای مشکل در دسترس بودن داده، ارائه تضمینهای کافی مبنی بر این است که دادههای کامل تراکنش برای تأیید در دسترس شرکتکنندگانی از شبکه قرار گرفته است که دادهها را برای خود دانلود و ذخیره نمیکنند.
-
-[گرههای سبک](/developers/docs/nodes-and-clients/light-clients) و [رولآپ های لایه 2](/developers/docs/scaling) نمونههای مهمی از شرکتکنندگان در شبکه هستند که به تضمینهای قوی در دسترس بودن داده نیاز دارند اما نمیتوانند دادههای تراکنش را برای خود دانلود و پردازش کنند. اجتناب از دانلود دادههای تراکنش چیزی است که گرههای سبک را سبک میکند و به رولآپ ها امکان میدهد راهحلهای مقیاسپذیری مؤثری باشند.
-
-در دسترس بودن داده ها همچنین یک نگرانی مهم برای کلاینت های [«بی حالت»](/roadmap/statelessness) اتریوم در آینده است که برای تأیید بلوک ها نیازی به دانلود و ذخیره داده های حالت ندارند. کلاینت های بی حالت هنوز باید مطمئن باشند که دادهها _جایی_ در دسترس هستند و به درستی پردازش شدهاند.
-
-## راه حل های در دسترس بودن داده ها {#data-availability-solutions}
-
-### نمونهگیری در دسترس بودن داده (DAS) {#data-availability-sampling}
-
-نمونهگیری در دسترس بودن داده (DAS) روشی برای شبکه برای بررسی در دسترس بودن دادهها بدون اعمال فشار زیاد بر هر گره منفرد است. هر گره (از جمله گرههای بدون شرطبندی) تعدادی زیرمجموعه کوچک و تصادفی انتخاب شده از کل دادهها را دانلود میکند. دانلود موفقیت آمیز نمونه ها با اطمینان بالا تأیید می کند که همه داده ها در دسترس هستند. این به کدگذاری پاک کردن دادهها متکی است، که یک مجموعه داده معین را با اطلاعات اضافی گسترش میدهد (روش انجام این کار به این صورت است که تابعی به نام _چند جملهای_ را بر روی دادهها قرار میدهد و آن چند جملهای را در نقاط اضافی ارزیابی میکند). این اجازه می دهد تا داده های اصلی در صورت لزوم از داده های اضافی بازیابی شوند. نتیجه این ایجاد داده این است که اگر _هیچ_ کدام از دادههای اصلی در دسترس نباشد، _نیمی_ از دادههای توسعهیافته از دست خواهند رفت! مقدار نمونه های داده دانلود شده توسط هر گره را می توان تنظیم کرد به طوری که _به شدت_ احتمال دارد که حداقل یکی از قطعات داده نمونه برداری شده توسط هر مشتری وجود نداشته باشد _اگر_ کمتر از نیمی از داده ها واقعاً در دسترس باشد.
-
-DAS برای اطمینان از اینکه اپراتورهای رولآپ دادههای تراکنش خود را پس از اجرای [دنکشاردینگ کامل](/roadmap/danksharding/#what-is-danksharding) در دسترس قرار میدهند، استفاده میشود. گره های اتریوم به صورت تصادفی از داده های تراکنش ارائه شده در حباب ها با استفاده از طرح افزونگی که در بالا توضیح داده شد نمونه برداری می کنند تا اطمینان حاصل شود که همه داده ها وجود دارند. همین تکنیک همچنین میتواند برای اطمینان از اینکه تولیدکنندگان بلوک تمام دادههای خود را برای ایمن کردن کلاینت های سبک در دسترس قرار میدهند، استفاده شود. به طور مشابه، تحت [جداسازی پیشنهاددهنده-سازنده](/roadmap/pbs) بلوک، فقط سازنده بلوک باید کل یک بلوک را پردازش کند - اعتبارسنج های دیگر با استفاده از نمونه گیری در دسترس بودن داده ها را تأیید می کنند.
-
-### کمیته های در دسترس بودن داده ها {#data-availability-committees}
-
-کمیته های در دسترس بودن داده ها (DACها) طرف های مورد اعتمادی هستند که در دسترس بودن داده ها را ارائه می دهند یا آن را تأیید می کنند. DAC ها را می توان به جای [یا در ترکیب با](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS استفاده کرد. ضمانتهای امنیتی که با کمیتهها ارائه میشوند به تشکیلات خاص بستگی دارد. برای مثال، اتریوم از زیرمجموعههای نمونهبرداری تصادفی اعتبارسنج ها برای تأیید در دسترس بودن دادهها برای گرههای سبک استفاده میکند.
-
-DAC ها نیز توسط برخی از ولیدیومها استفاده می شوند. DAC مجموعه ای از گره های قابل اعتماد است که نسخه هایی از داده ها را به صورت آفلاین ذخیره می کند. DAC موظف است در صورت بروز اختلاف، داده ها را در دسترس قرار دهد. اعضای DAC همچنین امضاهای آنچین را منتشر میکنند تا ثابت کنند که دادههای مذکور واقعاً در دسترس هستند. برخی ولیدیومها را با یک سیستم اعتبارسنج اثبات سهام (PoS) جایگزین می کنند. در اینجا، هر کسی میتواند اعتبارسنج شود و دادهها را خارج از زنجیره ذخیره کند. با این حال، آنها باید یک "مسیر" ارائه کنند که در یک قرارداد هوشمند سپرده می شود. در صورت رفتار مخرب، مانند مخفی نگه داشتن اطلاعات توسط اعتبارسنج، پیوند را می توان کاهش داد. کمیته های در دسترس بودن داده های اثبات سهام به طور قابل توجهی از DAC های معمولی ایمن تر هستند زیرا مستقیماً رفتار صادقانه را تشویق می کنند.
-
-## در دسترس بودن داده ها و گره های سبک {#data-availability-and-light-nodes}
-
-[گره های سبک](/developers/docs/nodes-and-clients/light-clients) باید صحت هدرهای بلوکی را که دریافت می کنند بدون بارگیری داده های بلوک تأیید کنند. هزینه این سَبُکی نیز ناتوانی در تأیید مستقل هدرهای بلوک با اجرای مجدد تراکنش ها به صورت محلی به روشی است که گره های کامل انجام می دهند.
-
-گره های سبک اتریوم به مجموعه های تصادفی 512 اعتبارسنج که به _کمیته همگام سازی_ اختصاص داده شده اند اعتماد دارند. کمیته همگامسازی بهعنوان یک DAC عمل میکند که با استفاده از یک امضای رمزنگاری به کلاینت های سبک میگوید که دادههای سر صحیح هستند. هر روز، کمیته همگام سازی رفرش می شود. هر سرصفحه بلوک به گرههای سیک هشدار میدهد که کدام اعتبارسنج ها باید بلوک _بعدی_ را امضا کنند، بنابراین نمیتوان آنها را فریب داد تا به یک گروه مخرب که وانمود میکنند کمیته همگامسازی واقعی هستند، اعتماد کنند.
-
-با این حال، چه اتفاقی میافتد اگر یک مهاجم به نحوی _موفق_ شود هدر بلوک مخرب را به کلاینت سبک ارسال کند و آنها را متقاعد کند که توسط یک کمیته همگامسازی صادقانه امضا شده است؟ در آن صورت، مهاجم میتواند تراکنشهای نامعتبر را شامل شود و کلاینت سبک کورکورانه آنها را میپذیرد، زیرا آنها بهطور مستقل تمام تغییرات حالت خلاصهشده در هدر بلوک را بررسی نمیکنند. برای محافظت در برابر این، کلاینت سبک می تواند از اثبات های تقلب استفاده کند.
-
-روش کار این اثبات های تقلب به این صورت است که یک گره کامل، با مشاهده یک انتقال حالت نامعتبر که در اطراف شبکه شایعه می شود، می تواند به سرعت یک قطعه کوچک از داده را تولید کند که نشان دهد یک انتقال حالت پیشنهادی احتمالاً نمی تواند از مجموعه معینی از تراکنش ها ناشی شود و آن داده ها را برای همتایان پخش کند. گرههای سبک میتوانند آن موارد اثبات تقلب را انتخاب کرده و از آنها برای حذف هدرهای بلوک بد استفاده کنند، و اطمینان حاصل کنند که در زنجیره صادقانه مشابه گرههای کامل باقی میمانند.
-
-این متکی بر گره های کامل است که به داده های تراکنش کامل دسترسی دارند. مهاجمی که یک هدر بلوک بد پخش میکند و همچنین نمیتواند دادههای تراکنش را در دسترس قرار دهد، میتواند از ایجاد اثبات تقلب توسط گرههای کامل جلوگیری کند. گرههای کامل ممکن است بتوانند هشداری درباره یک بلوک بد ارسال کنند، اما نمیتوانند از هشدار خود با اثبات پشتیبان بگیرند، زیرا دادهها برای تولید اثبات در دسترس نبودند!
-
-راه حل این مشکل در دسترس بودن داده ها DAS است. گره های سبک، تکه های تصادفی بسیار کوچکی از داده های حالت کامل را دانلود می کنند و از نمونه ها برای تأیید اینکه مجموعه داده کامل در دسترس است استفاده می کنند. احتمال واقعی فرض نادرست در دسترس بودن کامل داده ها پس از دانلود N قطعه تصادفی را می توان محاسبه کرد ([برای 100 تکه این شانس 10^-30 است](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)، یعنی فوقالعاده بعید است).
-
-حتی در این سناریو، حملاتی که تنها چند بایت را در خود نگه میدارند، میتوانند توسط کلاینت هایی که درخواستهای داده تصادفی میکنند مورد توجه قرار نگیرند. کدگذاری پاک کردن این مشکل را با بازسازی قطعات کوچک از دست رفته داده که می تواند برای بررسی تغییرات حالت پیشنهادی مورد استفاده قرار گیرد، برطرف می کند. سپس میتوان با استفاده از دادههای بازسازیشده، یک اثبات تقلب ایجاد کرد و از پذیرش هدرهای بد توسط گرههای سبک جلوگیری کرد.
-
-**توجه:** DAS و اثبات تقلب هنوز برای کلاینت های سبک اتریوم اثبات سهام اجرا نشده اند، اما در نقشه راه هستند و به احتمال زیاد به شکل اثبات های مبتنی بر ZK-SNARK هستند. کلاینت های سبک امروزی به شکلی از DAC متکی هستند: آنها هویت کمیته همگامسازی را تأیید میکنند و سپس به هدرهای بلوک امضا شدهای که دریافت میکنند اعتماد میکنند.
-
-## در دسترس بودن داده ها و رولآپ های لایه2 {#data-availability-and-layer-2-rollups}
-
-[راهحلهای مقیاسبندی لایه2](/layer-2/)، مانند [رولآپ ها](/glossary/#rollups)، هزینههای تراکنش را کاهش میدهند و با پردازش تراکنشهای خارج از زنجیره، توان عملیاتی اتریوم را افزایش میدهند. تراکنشهای رولآپ فشرده می شوند و به صورت دستهای در اتریوم پست میشوند. دسته ها هزاران تراکنش خارج از زنجیره فردی را در یک تراکنش در اتریوم نشان می دهند. این باعث کاهش تراکم در لایه پایه و کاهش هزینه ها برای کاربران می شود.
-
-با این حال، تنها زمانی میتوان به تراکنشهای «خلاصه» ارسالشده در اتریوم اعتماد کرد که تغییر حالت پیشنهادی بهطور مستقل تأیید شود که نتیجه اعمال همه تراکنشهای خارج از زنجیره است. اگر اپراتورهای رولآپ دادههای تراکنش را برای این راستیآزمایی در دسترس قرار ندهند، ممکن است دادههای نادرستی را به اتریوم ارسال کنند.
-
-[رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/) دادههای تراکنش فشرده را به اتریوم ارسال میکنند و برای مدتی (معمولاً 7 روز) منتظر میمانند تا به تأییدکنندگان مستقل اجازه بررسی دادهها را بدهد. اگر کسی مشکلی را شناسایی کند، می تواند یک اثبات تقلب ایجاد کند و از آن برای به چالش کشیدن رولآپ استفاده کند. این باعث می شود زنجیره به عقب برگردد و بلوک نامعتبر را حذف کند. این تنها در صورتی امکان پذیر است که داده ها در دسترس باشند. در حال حاضر، دو راه وجود دارد که رولآپ های خوشبینانه داده های تراکنش را به L1 ارسال کنند. برخی رولآپ ها دادهها را بهصورت دائمی بهعنوان `CALLDATA` در دسترس قرار میدهند که بهطور دائم در زنجیره زندگی میکنند. با اجرای EIP-4844، برخی از رولآپ ها دادههای تراکنش خود را به جای ذخیرهسازی حباب های ارزانتر ارسال میکنند. این ذخیره سازی دائمی نیست. تأییدکنندگان مستقل باید در عرض 18 روز قبل از حذف داده ها از لایه 1 اتریوم، حباب ها را استعلام کنند و چالش های خود را مطرح کنند. در دسترس بودن داده ها فقط توسط پروتکل اتریوم برای آن پنجره کوتاه ثابت تضمین شده است. پس از آن، مسئولیت سایر موجودات در اکوسیستم اتریوم می شود. هر گره می تواند در دسترس بودن داده ها را با استفاده از DAS تأیید کند، یعنی با دانلود نمونه های کوچک و تصادفی از داده های حباب.
-
-[رولآپ های دانش صفر (ZK)](/developers/docs/scaling/zk-rollups) نیازی به ارسال دادههای تراکنش ندارند زیرا [شواهد اعتبار دانش صفر](/glossary/#zk-proof) صحت انتقال حالت را تضمین میکند. با این حال، در دسترس بودن داده ها هنوز یک مشکل است زیرا ما نمی توانیم عملکرد رولآپ دانش صفر (یا تعامل با آن) را بدون دسترسی به داده های وضعیت آن تضمین کنیم. به عنوان مثال، اگر اپراتور جزئیاتی را درباره حالت رولآپ مخفی کند، کاربران نمیتوانند موجودی خود را بدانند. همچنین، آنها نمی توانند با استفاده از اطلاعات موجود در یک بلوک جدید اضافه شده، به روز رسانی حالت را انجام دهند.
-
-## در دسترس بودن داده در مقابل قابلیت بازیابی داده ها {#data-availability-vs-data-retrievability}
-
-در دسترس بودن داده ها با قابلیت بازیابی داده ها متفاوت است. در دست داشتن داده ها با قابلیت بازیابی ها متفاوت است. لزوماً به این معنی نیست که داده ها برای همیشه قابل دسترسی هستند.
-
-قابلیت بازیابی داده ها توانایی گره ها برای بازیابی _اطلاعات تاریخی_ از بلاک چین است. این داده تاریخی برای تأیید بلوک های جدید مورد نیاز نیست، فقط برای همگام سازی گره های کامل از بلوک پیدایش یا ارائه درخواست های تاریخی خاص مورد نیاز است.
-
-پروتکل اصلی اتریوم در درجه اول مربوط به در دسترس بودن داده ها است، نه قابلیت بازیابی داده ها. قابلیت بازیابی دادهها را میتوان توسط جمعیت کوچکی از گرههای بایگانی که توسط اشخاص ثالث اجرا میشوند فراهم کرد، یا میتوان آن را با استفاده از ذخیرهسازی فایل غیرمتمرکز مانند [شبکه پورتال](https://www.ethportal.net/) در سراسر شبکه توزیع کرد.
-
-## اطلاعات بیشتر {#further-reading}
-
-- [WTF قابلیت دسترسی داده است؟](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f)
-- [قابلیت دسترسی داده چیست؟](https://coinmarketcap.com/alexandria/article/what-is-data-availability)
-- [دورنمای قابلیت دسترسی داده اتریوم خارج زنجیره](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/)
-- [مقدمهای بر بررسیهای قابلیت دسترسی داده](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html)
-- [شرحی بر شاردینگ + پیشنهاد DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
-- [یادداشتی بر قابلیت دسترسی داده و کدگذاری پاک شدن](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them)
-- [کمیته های در دسترس بودن داده ها.](https://medium.com/starkware/data-availability-e5564c416424)
-- [کمیته های در دسترس بودن داده های اثبات سهام.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)
-- [راه حل هایی برای مشکل بازیابی داده ها](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding)
-- [قابلیت دسترسی داده ها یا: رولآپها چطور یاد گرفتند دیگر نگران نباشند و اتریوم را دوست داشته باشند](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md
deleted file mode 100644
index 7efb9db6d65..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-title: بهترین شیوههای طراحی صرافی غیرمتمرکز (DEX)
-description: راهنمائی برای توضیح تصمیمات گرفته شده درمورد رابط کاربری و تجربه کاربری حین مبادله توکنها.
-lang: fa
----
-
-از زمان راهاندازی یونی سواپ در سال 2018، صدها صرافی غیرمتمرکز در شبکههای مختلف راهاندازی شده است.
-بسیاری از این صرافیها یک عنصر جدید یا شیوهی مختص به خود را معرفی کردند، اما رابط کاربری بهصورت کلی به همان شکل مانده است.
-
-یکی از دلایل آن [قانون جیکوب](https://lawsofux.com/jakobs-law/) است:
-
-> کاربران بیشتر وقت خود را در وب سایتهای دیگر صرف میکنند. این بدان معناست که کاربران ترجیح میدهند تا سایت شما مشابه سایتهایی عمل کند که در حال حاضر با آنها آشنا هستند.
-
-به لطف نوآورانی همچون یونی سواپ، پنکیک سواپ و سوشی سواپ، کاربران حوزه دیفای یک ایده کلی از این دارند که صرافی غیرمتمرکز چگونه باید به نظر برسد.
-به همین دلیل، چیزهایی مثل "بهترین شیوه" هم اکنون در حال ظهور هستند. میتوان مشاهده کرد که تصمیمات طراحی در میان سایتهای مختلف بیشتر و بیشتر استانداردسازی میشود. تکامل صرافیهای غیرمتمرکز یک مثال بزرگ از تست کردن پروژه با استفاده از اجرا و انتشار آن میباشد. چیزهایی که کار کردند همانطور ماندند و چیزهایی که کار نکردند، دور انداخته شدند. هنوز جا برای شخصی سازی وجود دارد، اما استانداردهای خاصی وجود دارند که یک صرافی غیرمتمرکز باید به آنها پایبند باشد.
-
-این مقاله خلاصه ای است از:
-
-- چه چیزی را شامل شود
-- چگونه آن را تا حد امکان قابل استفاده کنیم
-- راه های اصلی برای سفارشی سازی طراحی
-
-همه وایرفریمهای نمونه بهطور خاص برای این مقاله ساخته شدهاند، اگرچه همه آنها بر اساس پروژههای واقعی هستند.
-
-کیت Figma نیز در پایین موجود است - از آن استفاده کنید و سرعت وایرفریم های خود را افزایش دهید!
-
-## آناتومی ساده یک صرافی غیرمتمرکز {#basic-anatomy-of-a-dex}
-
-رابط کاربری معمولا شامل 3 چیز است:
-
-1. فرم اصلی
-2. دکمه
-3. پنل جزئیات
-
-![Generic DEX UI، نمایش سه عنصر اصلی](./1.png)
-
-## تغییرات {#variations}
-
-این یک موضوع رایج در این مقاله خواهد بود، اما روشهای مختلفی برای سازماندهی این عناصر وجود دارد. "پنل جزئیات" می تواند بدین شکل باشد:
-
-- بالای دکمه
-- زیر دکمه
-- مخفی در پنل آکاردئونی
-- و/یا در حالت "پیش نمایش"
-
-نکته حالت "پیش نمایش" اختیاری است، اما اگر جزئیات بسیار کمی را در رابط کاربری اصلی نشان می دهید، ضروری می شود.
-
-## ساختار فرم اصلی {#structure-of-the-main-form}
-
-این کادری است که در واقع انتخاب میکنید کدام توکن را میخواهید تعویض کنید. کامپوننت شامل یک فیلد ورودی و یک دکمه کوچک در یک ردیف است.
-
-DEX ها معمولاً جزئیات اضافی را در یک ردیف بالا و یک ردیف پایین نمایش می دهند، اگرچه می توان آن را به طور متفاوت پیکربندی کرد.
-
-![ردیف ورودی، با ردیف جزئیات بالا و پایین](./2.png)
-
-## تغییرات {#variations2}
-
-دو تغییر رابط کاربری در اینجا نشان داده شده است. یکی بدون هیچ حاشیه ای، یک طرح بسیار باز ایجاد می کند، و دیگری که در آن ردیف ورودی دارای یک حاشیه است که تمرکز روی آن عنصر ایجاد می کند.
-
-![دو تغییر رابط کاربری فرم اصلی](./3.png)
-
-این ساختار اساسی به **چهار اطلاعات کلیدی** اجازه می دهد تا در طراحی نشان داده شوند: یکی در هر گوشه. اگر فقط یک ردیف بالا/پایین وجود داشته باشد، تنها دو نقطه وجود دارد.
-
-در طول تکامل دیفای، موارد مختلف زیادی در اینجا گنجانده شده است.
-
-## اطلاعات کلیدی برای درج {#key-info-to-include}
-
-- موجودی در کیف پول
-- دکمه Max
-- معادل قیمت به فیات
-- تاثیر قیمت بر مبلغ "دریافت شده"
-
-در روزهای اولیه دیفای، معادل فیات اغلب گم می شد. اگر در حال ساخت هر نوع پروژه Web3 هستید، ضروری است که معادل فیات نشان داده شود. کاربران هنوز بر حسب ارزهای محلی فکر می کنند، بنابراین برای مطابقت با مدل های ذهنی دنیای واقعی، باید این مورد لحاظ شود.
-
-در فیلد دوم (محلی که توکنی را انتخاب میکنید که با آن مبادله میکنید) میتوانید با محاسبه تفاوت بین مقدار ورودی و مقدار خروجی تخمینی، تأثیر قیمت را در کنار مقدار ارز فیات لحاظ کنید. این جزئیات کاملا مفیدی برای گنجاندن است.
-
-دکمه های درصد (مثلاً 25٪، 50٪، 75٪) می توانند یک ویژگی مفید باشند، اما فضای بیشتری را اشغال می کنند، تماس بیشتری را به اقدامات اضافه می کنند و بار ذهنی بیشتری را اضافه می کنند. در مورد لغزنده های درصد نیز همینطور است. برخی از این تصمیمات UI به برند و نوع کاربری شما بستگی دارد.
-
-جزئیات اضافی را می توان در زیر فرم اصلی نشان داد. از آنجایی که این نوع اطلاعات بیشتر برای کاربران حرفه ای است، منطقی است که:
-
-- آن را تا حد امکان مینیمال نگه دارید، یا؛
-- آن را در پنل آکاردئونی پنهان کنید
-
-![جزئیات در گوشه های آن فرم اصلی نشان داده شده است](./4.png)
-
-## اطلاعات اضافی برای درج {#extra-info-to-include}
-
-- قیمت توکن
-- افت
-- حداقل دریافتی
-- خروجی مدنظر
-- اثر قیمت
-- تخمین هزینه گس
-- باقی کارمزدها
-- مسیردهی سفارش
-
-مسلماً برخی از این جزئیات می توانند اختیاری باشند.
-
-مسیریابی سفارش جالب است، اما برای اکثر کاربران تفاوت چندانی ایجاد نمی کند.
-
-برخی جزئیات دیگر به سادگی یک چیز را به روش های مختلف بازگو می کنند. برای مثال «حداقل دریافتی» و «افت قیمت» دو روی یک سکه هستند. اگر افت قیمت را روی 1% تنظیم کردهاید، حداقل مقداری که میتوانید دریافت کنید = خروجی مدنظر - 1%. برخی از رابطهای کاربری مقدار مورد انتظار، حداقل مقدار و افت را نشان میدهند… که مفید است اما احتمالاً بیش از حد است.
-
-اکثر کاربران به هر حال افت قیمت پیش فرض را خالی می گذارند.
-
-"تأثیر قیمت" اغلب در پرانتز در کنار معادل فیات در قسمت "به" نشان داده می شود. این اطلاعات عالی درباره ux برای افزودن است، اما اگر در اینجا نشان داده شود، آیا واقعاً باید دوباره در زیر نشان داده شود؟ و سپس دوباره در یک صفحه پیش نمایش بیاید؟
-
-بسیاری از کاربران (مخصوصاً آنهایی که مقادیر کم را مبادله می کنند) به این جزئیات اهمیت نمی دهند. آنها به سادگی یک عدد وارد می کنند و swap را می زنند.
-
-![برخی جزئیات همین را نشان میدهد](./5.png)
-
-اینکه دقیقاً چه جزئیاتی نشان داده می شود به مخاطبان شما و احساسی که می خواهید برنامه داشته باشد بستگی دارد.
-
-اگر آستانه تحمل افت را در پنل جزئیات لحاظ کنید، باید آن را مستقیماً از اینجا نیز قابل ویرایش کنید. این مثال خوبی از "شتاب دهنده" است. یک ترفند ساده UX که میتواند جریان کاربران با تجربه را سرعت بخشد، بدون اینکه بر قابلیت استفاده عمومی برنامه تأثیر بگذارد.
-
-![افت قیمت را می توان از پنل جزئیات کنترل کرد](./6.png)
-
-این ایده خوبی است که نه تنها در مورد یک قطعه خاص از اطلاعات در یک صفحه، بلکه در مورد کل جریان از طریق آن به دقت فکر کنید:
-وارد کردن اعداد در فرم اصلی ← جزئیات اسکن ← کلیک کردن برای پیش نمایش صفحه (اگر صفحه پیش نمایش دارید).
-آیا پنل جزئیات باید همیشه قابل مشاهده باشد یا کاربر برای بزرگ شدن باید روی آن کلیک کند؟
-آیا باید با افزودن یک صفحه پیش نمایش اصطکاک ایجاد کنید؟ این امر کاربر را مجبور می کند تا سرعت خود را کاهش دهد و مبادله خود را در نظر بگیرد که می تواند مفید باشد. اما آیا آنها می خواهند همه همان اطلاعات را دوباره ببینند؟ چه چیزی در این مرحله برای آنها مفیدتر است؟
-
-## گزینه های طراحی {#design-options}
-
-همانطور که گفته شد، بسیاری از این موارد به سبک شخصی شما برمی گردد
-کاربر شما کیست؟
-برند شما چیست؟
-آیا یک رابط حرفه ای می خواهید که تمام جزئیات را نشان دهد یا می خواهید مینیمالیستی باشید؟
-حتی اگر به دنبال کاربران حرفهای هستید که همه اطلاعات را میخواهند، باز هم باید سخنان حکیمانه آلن کوپر را به خاطر بسپارید:
-
-> هر چقدر هم که رابط کاربری شما زیبا باشد، بهتر است کمتر از آن استفاده کنید.
-
-### ساختار {#structure}
-
-- توکن ها در سمت چپ یا توکن ها در سمت راست
-- 2 ردیف از 3
-- جزئیات بالا یا زیر دکمه
-- جزئیات گسترش یافته، حداقل شود یا نشان داده نشود
-
-### استایل کامپوننت {#component-style}
-
-- خالی
-- تاکید شده
-- پر شده
-
-از نقطه نظر UX خالص، سبک UI کمتر از آنچه فکر می کنید اهمیت دارد. روندهای بصری در چرخه می آیند و می روند و بسیاری از اولویت ها ذهنی است.
-
-ساده ترین راه برای درک این موضوع - و فکر کردن به پیکربندی های مختلف - این است که به چند نمونه نگاه کنید و سپس خودتان آزمایش کنید.
-
-کیت Figma شامل اجزای خالی، پیشفرض و پر شده است.
-
-به مثال های زیر نگاهی بیندازید تا روش های مختلفی را مشاهده کنید که می توانید همه آن ها را کنار هم قرار دهید:
-
-![3 ردیف به سبک پر شده](./7.png)
-
-![3 ردیف به سبک متن تاکید شده](./8.png)
-
-![2 ردیف به سبک خالی](./9.png)
-
-![3 ردیف به سبک متن پیشفرض، با پنل جزئیات](./10.png)
-
-![3 ردیف با ردیف ورودی به سبک متن تاکید شده](./11.png)
-
-![2 ردیف به سبک پر شده](./12.png)
-
-## اما توکن باید به کدام سمت برود؟ {#but-which-side-should-the-token-go-on}
-
-نکته اصلی این است که احتمالاً تفاوت زیادی در قابلیت استفاده ایجاد نمی کند. با این حال، چند نکته وجود دارد که باید به خاطر داشته باشید، که ممکن است شما را به یک جهت تحت تاثیر قرار دهد.
-
-دیدن تغییر مد با گذشت زمان کمی جالب است. Uniswap در ابتدا توکن را در سمت چپ داشت، اما از آن زمان آن را به سمت راست منتقل کرده است. Sushiswap نیز این تغییر را طی یک ارتقاء طراحی ایجاد کرد. بیشتر پروتکلها، اما نه همه، از همین روند پیروی کردهاند.
-
-قوانین مالی به طور سنتی نماد ارز را قبل از عدد قرار می دهد، به عنوان مثال. $50، €50، £50، اما ما _می گوییم_ 50 دلار، 50 یورو، 50 پوند.
-
-برای کاربر عمومی - به خصوص کسی که از چپ به راست، از بالا به پایین می خواند - نشانه سمت راست احتمالا طبیعی تر است.
-
-![یک رابط کاربری با توکن ها در سمت چپ](./13.png)
-
-قرار دادن توکن در سمت چپ و همه اعداد در سمت راست به طرز خوشایندی متقارن به نظر می رسند، که یک امتیاز مثبت است، اما یک نقطه ضعف دیگر در این طرح وجود دارد.
-
-قانون مجاورت بیان می کند که مواردی که نزدیک به هم هستند به عنوان مرتبط تلقی می شوند. بر همین اساس می خواهیم موارد مرتبط را در کنار یکدیگر قرار دهیم. موجودی توکن مستقیماً با خود توکن مرتبط است و هر زمان که یک توکن جدید انتخاب شود تغییر خواهد کرد. بنابراین کمی منطقی تر است که موجودی توکن در کنار دکمه انتخاب نشانه باشد. میتوان آن را به زیر نشانه منتقل کرد، اما این تقارن طرحبندی را میشکند.
-
-در نهایت، نکات مثبت و منفی برای هر دو گزینه وجود دارد، اما جالب است که به نظر می رسد چگونه روند به سمت توکن سمت راست است.
-
-# رفتار دکمه {#button-behavior}
-
-دکمه جداگانه ای برای تأیید نداشته باشید. همچنین یک کلیک جداگانه برای تأیید نداشته باشید. کاربر میخواهد Swap را انجام دهد، بنابراین فقط روی دکمه بگویید «swap» و تأیید را به عنوان اولین مرحله آغاز کنید. یک مودال میتواند پیشرفت را با یک استپر یا یک اعلان ساده "tx 1 of 2 - تایید" نشان دهد.
-
-![یک رابط کاربری با دکمههای جداگانه برای تأیید و swap](./14.png)
-
-![یک رابط کاربری با یک دکمه که تأیید میکند](./15.png)
-
-## دکمه به عنوان راهنمای متنی {#button-as-contextual-help}
-
-این دکمه می تواند به عنوان یک هشدار، وظیفه ای مضاعف را انجام دهد!
-
-این در واقع یک الگوی طراحی نسبتاً غیرعادی در خارج از Web3 است، اما در داخل آن استاندارد شده است. این یک نوآوری خوب است زیرا باعث صرفه جویی در فضا می شود و توجه را متمرکز نگه می دارد.
-
-اگر عمل اصلی - SWAP - به دلیل خطا در دسترس نیست، دلیل آن را می توان با دکمه توضیح داد، به عنوان مثال.:
-
-- تعویض شبکه
-- اتصال کیف پول
-- خطاهای متعدد
-
-این دکمه همچنین می تواند **به عملکرد** که باید انجام شود نگاشت شود. به عنوان مثال، اگر کاربر نمی تواند به دلیل اینکه در شبکه اشتباهی قرار دارد، مبادله کند، دکمه باید بگوید “switch to Ethereum” و زمانی که کاربر روی دکمه کلیک می کند، باید شبکه را به اتریوم تغییر دهد. این سرعت جریان کاربر را به میزان قابل توجهی افزایش می دهد.
-
-![عملکردهای کلیدی از CTA اصلی شروع میشوند](./16.png)
-
-![پیام خطا در CTA اصلی نشان داده میشود](./17.png)
-
-## مال خودتان را با این فایل فیگما بسازید {#build-your-own-with-this-figma-file}
-
-به لطف کار سخت پروتکل های متعدد، طراحی DEX بسیار بهبود یافته است. ما می دانیم که کاربر به چه اطلاعاتی نیاز دارد، چگونه باید آن را نشان دهیم و چگونه جریان را تا حد امکان روان کنیم.
-امیدواریم این مقاله یک نمای کلی از اصول UX ارائه دهد.
-
-اگر میخواهید آزمایش کنید، لطفاً از کیت وایرفریم فیگما استفاده کنید. تا حد امکان ساده نگه داشته می شود، اما انعطاف کافی برای ساختن ساختار اصلی به روش های مختلف دارد.
-
-[کیت وایرفریم فیگما](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
-
-دیفای به تکامل خود ادامه خواهد داد و همیشه جایی برای بهبود وجود دارد.
-
-موفق باشید!
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md
deleted file mode 100644
index 5cf74c4ece5..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-title: 7 اکتشاف برای طراحی رابط Web3
-description: اصولی برای بهبود قابلیت استفاده از Web3
-lang: fa
----
-
-اکتشاف قابلیت استفاده "قوانین سرانگشتی" گسترده ای هستند که می توانید برای اندازه گیری قابلیت استفاده سایت خود از آنها استفاده کنید.
-این اکتشاف ها به طور خاص برای Web3 طراحی شده اند و باید در کنار Jakob Nielsen [10 اصل کلی برای طراحی تعامل] (https://www.nngroup.com/articles/ten-usability-heuristics/) استفاده شوند.
-
-## هفت اکتشاف قابلیت استفاده برای web3 {#seven-usability-heuristics-for-web3}
-
-1. بازخورد در ادامه عمل میآید
-2. امنیت و اعتماد
-3. مهمترین اطلاعات واضح است
-4. اصطلاحات قابل درک
-5. اقدامات تا حد امکان کوتاه است
-6. اتصالات شبکه قابل مشاهده و انعطاف پذیر هستند
-7. از برنامه کنترل کنید، نه کیف پول
-
-## تعاریف و مثالها {#definitions-and-examples}
-
-### 1. بازخورد به دنبال عمل میآید {#feedback-follows-action}
-
-**وقتی اتفاقی افتاده یا در حال وقوع است باید واضح باشد.**
-
-کاربران بر اساس نتیجه گام های قبلی خود در مورد مراحل بعدی خود تصمیم می گیرند. بنابراین ضروری است که آنها از وضعیت سیستم مطلع شوند. این امر به ویژه در Web3 بسیار مهم است زیرا تراکنشها گاهی اوقات ممکن است زمان کوتاهی طول بکشد تا به بلاک چین متعهد شوند. اگر بازخوردی وجود نداشته باشد که به آنها اطلاع دهد که منتظر بمانند، کاربران مطمئن نیستند که آیا اتفاقی افتاده یا خیر.
-
-**نکات:**
-
-- از طریق پیام رسانی، اعلان ها و سایر هشدارها به کاربر اطلاع دهید.
-- زمان های انتظار را به وضوح در میان بگذارید.
-- اگر قرار است عملی بیش از چند ثانیه طول بکشد، با استفاده از یک تایمر یا یک انیمیشن به کاربر اطمینان دهید تا احساس کند چیزی در حال رخ دادن است.
-- اگر چندین مرحله برای یک فرآیند وجود دارد، هر مرحله را نشان دهید.
-
-**مثال:**
-نمایش هر مرحله درگیر در یک تراکنش به کاربران کمک می کند تا بدانند در کجای فرآیند قرار دارند. آیکون های مناسب به کاربر امکان می دهند از وضعیت اقدامات خود مطلع شود.
-
-![اطلاع رسانی به کاربر در مورد هر مرحله هنگام تعویض نشانه](./Image1.png)
-
-### 2. امنیت و اعتماد ایجاد میشوند {#security-and-trust-are-backed-in}
-
-امنیت باید در اولویت قرار گیرد و این باید برای کاربر تاکید شود.
-افراد عمیقاً به داده های خود اهمیت می دهند. ایمنی اغلب یک نگرانی اولیه برای کاربران است، بنابراین باید در تمام سطوح طراحی در نظر گرفته شود. همیشه باید به دنبال جلب اعتماد کاربران خود باشید، اما روشی که این کار را انجام میدهید میتواند در اپلیکیشنهای مختلف معنای متفاوت داشته باشد. این نباید یک فکر ثانوی باشد، بلکه باید آگاهانه طراحی شود. در طول تجربه کاربر، از جمله کانالهای اجتماعی و اسناد، و همچنین رابط کاربری نهایی، اعتماد ایجاد کنید. مواردی مانند سطح غیرمتمرکز، وضعیت چند علامت خزانه، و اینکه آیا تیم از کار افتاده است یا نه، همگی بر اعتماد کاربران تأثیر میگذارند
-
-**نکات:**
-
-- ممیزی های خود را با افتخار فهرست کنید
-- ممیزی های متعدد دریافت کنید
-- هر ویژگی ایمنی که طراحی کرده اید را تبلیغ کنید
-- خطرات احتمالی، از جمله ادغام های اساسی را برجسته کنید
-- پیچیدگی استراتژی ها را به اشتراک بگذارید
-- مسائل غیر UI را در نظر بگیرید که ممکن است بر درک کاربران شما از ایمنی تأثیر بگذارد
-
-**مثال:**
-ممیزیهای خود را در پاورقی، در اندازههای برجسته بگنجانید.
-
-![به ممیزی ها در پاورقی وب سایت استناد شده است](./Image2.png)
-
-### 3. مهمترین اطلاعات واضح است {#the-most-important-info-is-obvious}
-
-برای سیستم های پیچیده، فقط مرتبط ترین داده ها را نشان دهید. تعیین کنید چه چیزی مهم است و نمایش آن را اولویت بندی کنید.
-اطلاعات بیش از حد طاقت فرسا است و کاربران معمولاً هنگام تصمیم گیری بر روی یک قطعه اطلاعات تمرکز میکنند. در DeFi، این احتمالاً APR برای برنامههای بازدهی و LTV در برنامههای وامدهی خواهد بود.
-
-**نکات:**
-
-- تحقیقات کاربر مهمترین معیار را آشکار می کند
-- اطلاعات کلیدی را بزرگ و سایر جزئیات را کوچک و محجوب کنید
-- افراد نمی خوانند، اسکن می کنند. اطمینان حاصل کنید که طرح شما قابل اسکن است
-
-**مثال:** نشانه های بزرگ به صورت تمام رنگی هنگام اسکن به راحتی پیدا می شوند. APR بزرگ است و با رنگ برجسته برجسته شده است.
-
-![یافتن نشانه و APR آسان است](./Image3.png)
-
-### 4. اصطلاحات واضح {#clear-terminology}
-
-اصطلاحات باید قابل فهم و مناسب باشند.
-اصطلاحات فنی می تواند یک مانع بزرگ باشد، زیرا نیاز به ساخت یک مدل ذهنی کاملاً جدید دارد. کاربران نمی توانند طراحی را با کلمات، عبارات و مفاهیمی که از قبل می دانند مرتبط کنند. همه چیز گیج کننده و ناآشنا به نظر می رسد، و قبل از اینکه آنها حتی بتوانند از آن استفاده کنند، یک منحنی یادگیری شیب دار وجود دارد. کاربرانی که میخواهند مقداری پول پسانداز کنند، ممکن است به DeFi نزدیک شوند، و چیزی که پیدا میکنند این است: استخراج، فارمینگ، سهامگذاری، انتشار گازهای گلخانهای، رشوه، گاوصندوق ها، قفسهها، توکنهای vetoken، واگذاری، ایپوک ها، الگوریتمهای غیرمتمرکز، نقدینگی متعلق به پروتکل…
-سعی کنید از اصطلاحات ساده ای استفاده کنید که برای گسترده ترین گروه مردم قابل درک باشد. اصطلاحات جدید را فقط برای پروژه خود اختراع نکنید.
-
-**نکات:**
-
-- از اصطلاحات ساده و ثابت استفاده کنید
-- تا حد امکان از زبان موجود استفاده کنید
-- شرایط خود را مطرح نکنید
-- قراردادها را همانطور که ظاهر می شوند دنبال کنید
-- تا حد امکان به کاربران آموزش دهید
-
-**مثال:**
-"پاداش شما" اصطلاحی است که به طور گسترده درک میشود و خنثی است و کلمه جدیدی برای این پروژه ساخته نشده است. جوایز به USD تعلق میگیرد تا با مدلهای ذهنی دنیای واقعی مطابقت داشته باشد، حتی اگر خود پاداشها با توکن دیگری باشند.
-
-![جوایز توکنی، نمایش داده شده به دلار آمریکا](./Image4.png)
-
-### 5. اقدامات تا حد امکان کوتاه هستند {#actions-are-as-short-as-possible}
-
-با گروهبندی کنشهای فرعی، تعاملات کاربر را تسریع کنید.
-این ممکن است در سطح قرارداد هوشمند و همچنین رابط کاربری انجام شود. کاربر نباید مجبور باشد از یک قسمت سیستم به قسمت دیگر حرکت کند - یا سیستم را به طور کامل ترک کند تا یک اقدام مشترک را انجام دهد.
-
-**نکات:**
-
-- در صورت امکان، «تأیید» را با سایر اقدامات ترکیب کنید
-- مراحل امضا را تا حد امکان به هم نزدیک کنید
-
-**مثال:** ترکیب «افزودن نقدینگی» و «سهام» یک مثال ساده از شتابدهندهای است که در زمان و گس کاربر صرفهجویی میکند.
-
-![Modal نشان دادن سوئیچ برای ترکیب اقدامات سپرده و سهام](./Image5.png)
-
-### 6. اتصالات شبکه قابل مشاهده و انعطاف پذیر هستند {#network-connections-are-visible-and-flexible}
-
-به کاربر اطلاع دهید که به چه شبکه ای متصل است و میانبرهای واضحی برای تغییر شبکه ارائه دهید.
-این به ویژه در برنامه های چند زنجیره ای مهم است. عملکردهای اصلی برنامه همچنان باید هنگام قطع یا اتصال به یک شبکه غیر پشتیبانی قابل مشاهده باشند.
-
-**نکات:**
-
-- تا آنجا که ممکن است برنامه را هنگام قطع ارتباط نشان دهید
-- نشان دهید که کاربر در حال حاضر به کدام شبکه متصل است
-- کاربر را مجبور نکنید برای تغییر شبکه به کیف پول مراجعه کند
-- اگر برنامه از کاربر میخواهد که شبکه را تغییر دهد، این عمل را از تماس اصلی برای اقدام درخواست کنید
-- اگر برنامه حاوی بازارها یا انبارهایی برای چندین شبکه است، به وضوح مشخص کنید که کاربر در حال حاضر به کدام مجموعه نگاه می کند
-
-**مثال:** به کاربر نشان دهید که به کدام شبکه متصل است و به او اجازه دهید آن را در نوار برنامه تغییر دهد.
-
-![دکمه کشویی شبکه متصل را نشان می دهد](./Image6.png)
-
-### 7. کنترل از برنامه، نه کیف پول {#control-from-the-app-not-the-wallet}
-
-رابط کاربری باید همه چیزهایی که کاربر باید بداند را بگوید و کنترل همه چیزهایی که باید انجام دهد را به او بدهد.
-در Web3، اقداماتی هستند که در رابط کاربری انجام می دهید و اقداماتی که در کیف پول انجام می دهید. به طور کلی، شما یک عمل را در UI آغاز می کنید و سپس آن را در کیف پول تأیید می کنید. اگر این دو رشته به دقت ادغام نشوند، کاربران ممکن است احساس ناراحتی کنند.
-
-**نکات:**
-
-- وضعیت سیستم را از طریق بازخورد در UI اعلام کنید
-- تاریخچه آنها را ثبت کنید
-- پیوندهایی برای مسدود کردن کاوشگرها برای تراکنش های قدیمی ارائه دهید
-- میانبرهایی برای تغییر شبکه ها ارائه دهید.
-
-**مثال:** یک ظرف ظریف به کاربر نشان می دهد که چه توکن های مرتبطی در کیف پول خود دارد و CTA اصلی میانبری برای تغییر شبکه ارائه می دهد.
-
-![CTA اصلی از کاربر میخواهد شبکه را تغییر دهد](./Image7.png)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md
deleted file mode 100644
index d5d609a3ded..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/design-and-ux/index.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: طراحی و UX در web3
-description: مقدمه ای بر طراحی و تحقیق UX در فضای Web3 و اتریوم
-lang: fa
----
-
-آیا در طراحی با اتریوم تازه کار هستید؟ اینجا مکان مناسب شماست. جامعه اتریوم منابع مکتوبی برای آشنایی شما با اصول طراحی Web3 و تحقیق دارد. در مورد مفاهیم اصلی که ممکن است با سایر طرح های برنامه ای که با آنها آشنا هستید متفاوت باشد، آشنا خواهید شد.
-
-ابتدا به درک پایهای تری از web3 نیاز دارید؟ [**مرکز یادگیری**](/learn/) ما را بررسی کنید.
-
-## با تحقیقات کاربر شروع کنید {#start-with-user-research}
-
-طراحی موثر فراتر از ایجاد رابط های کاربری جذاب بصری است. این شامل کسب درک عمیق از نیازها، اهداف و عوامل محرک کاربر است. بنابراین، به شدت توصیه می کنیم که همه طراحان، یک فرآیند طراحی مانند [**فرایند الماس دوگانه**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)) را اتخاذ کنند تا اطمینان حاصل کنند که کار آنها هدفمند و آگاهانه است.
-
-- [Web3 به محققان و طراحان UX بیشتری نیاز دارد](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - مروری بر بلوغ طراحی فعلی
-- [راهنمای ساده برای تحقیقات UX در Web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - راهنمای ساده نحوه انجام تحقیق
-- [نحوه رویکرد به تصمیمات UX در Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - مروری کوتاه بر تحقیقات کمی و کیفی و تفاوتهای بین این دو (ویدئو، 6 دقیقه)
-- [محقق ux بودن در web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - دیدگاه شخصی در مورد اینکه یک محقق UX در web3 چگونه است
-
-## مطالعات پژوهشی در Web3 {#research-in-web3}
-
-این لیستی از تحقیقات کاربر انجام شده در Web3 است که ممکن است به تصمیم گیری در مورد طراحی و محصول کمک کند یا به عنوان الهام بخش برای انجام مطالعه شخصی باشد.
-
-| حوزه تمرکز | نام |
-|:------------------------------------------------------ |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| ورود به رمزنگاری | [CRADL: UX رمز از](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
-| ورود به رمزنگاری | [CRADL: ورود به رمزارز](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
-| ورود به رمزنگاری | [بیت کوین در گزارش UX](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
-| ورود به رمزنگاری | [ConSensys: حالت درک Web3 درباره دنیا 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
-| ورود به رمزنگاری | [NEAR: شتاب دادن به تجربه به سوی پذیرش](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
-| سهام گذاری | [سهام گذاری: گرایش های کلیدی، و پیشبینیها - سهام گذار اتر](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
-| سهام گذاری | [سهام گذاری چندبرنامه ای](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
-| DAO | [به روز رسانی تحقیقات DAO در 2022: سازندگان DAO چه چیز لازم دارند؟](https://blog.aragon.org/2022-dao-research-update/) |
-| DeFi | [حالت Defi 2024](https://stateofdefi.org/) (نظرسنجی در حال انجام) |
-| DeFi | [استخرهای پوشش](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
-| DeFi | [ConSensys: گزارش تحقیقات کاربران DeFi در 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
-| متاورس | [Metaverse: گزارش تحقیقات کاربر](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
-| متاورس | [رفتن در سفری: تحقیق درباره کاربران در Metaverse](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (ویدیو، 27 دقیقه) |
-| آمار Ethereum.org UX | [داشبورد نظرسنجی قابلیت استفاده و رضایت کاربران - Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) |
-
-## طراحی برای web3 {#design-for-web3}
-
-- [راهنمای طراحی Web3 UX](https://web3ux.design/) - راهنمای عملی برای طراحی برنامه های Web3
-- [اصول طراحی وب 3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - چارچوبی از قوانین UX برای برنامه های مبتنی بر بلاک چین
-- [اصول طراحی بلاکچین](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - درسهایی که تیم طراحی بلاک چین در IBM آموخته است
-- [الگوهای طراحی Web3](https://www.web3designpatterns.io/) - یک کتابخانه انتخاب شده از الگوهای طراحی از محصولات واقعی Web3
-- [W3design.io](https://w3design.io/) - یک کتابخانه مدیریتشده از جریانهای رابط کاربری پروژههای مختلف در اکوسیستم
-- [Neueux.com](https://neueux.com/apps) - کتابخانه UI از جریان های کاربر با گزینه های مختلف فیلتر
-- [بحران قابلیت استفاده Web3: آنچه شما باید بدانید!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - بحث میزگرد در مورد مشکلات ساخت پروژه متمرکز بر توسعه دهنده (ویدئو، 34 دقیقه)
-
-## مطالعات موردی طراحی Web3 {#design-case-studies}
-
-- [Deep Work Studio](https://deepwork.studio/case-studies/)
-- [راهنمای Crypto UX](https://www.cryptouxhandbook.com/)
-- [فروش یک NFT در OpenSea](https://builtformars.com/case-studies/opensea)
-- [کنار گذاشتن کیف پول UX چگونه کیفهای پول باید عوض شوند](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (ویدیو، 20 دقیقه)
-
-## پاداشهای طراحی {#bounties}
-
-- [Dework](https://app.dework.xyz/bounties)
-- [گردهمآیی Buildbox](https://app.buidlbox.io/)
-- [گردهمآیی ETHGlobal](https://ethglobal.com/)
-
-## طراحی DAOها و جوامع {#design-daos-and-communities}
-
-در سازمان های حرفه ای جامعه محور شرکت کنید یا به گروه های طراحی بپیوندید تا درباره موضوعات و گرایش های مربوط به طراحی و تحقیق با سایر اعضا بحث کنید.
-
-- [Vectordao.com](https://vectordao.com/)
-- [Deepwork.studio](https://www.deepwork.studio/)
-- [Designer-dao.xyz](https://www.designer-dao.xyz/)
-- [We3.co](https://we3.co/)
-- [Openux.xyz](https://openux.xyz/)
-- [Open Source Web3Design](https://www.web3designers.org/)
-
-## سیستم طراحی {#design-systems}
-
-- [Optimism Design](https://www.figma.com/@optimism) (Figma)
-- [سیستم طراحی Ethereum.org Design](https://www.figma.com/@ethdotorg) (Figma)
-- [Finity، یک سیستم طراحی توسط پالیگان](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (فیگما)
-- [Kleros Design System](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
-- [Safe Design System](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
-- [سیستم طراحی ENS](https://thorin.ens.domains/)
-- [سیستم طراحی Mirror](https://degen-xyz.vercel.app/)
-
-**مقالات و پروژه های فهرست شده در این صفحه تاییدیه رسمی نیستند** و فقط برای اهداف اطلاع رسانی ارائه شده اند. ما لینک ها را بر اساس معیارهای [خطمشی لیستینگ](/contributing/design/adding-design-resources) خود به این صفحه اضافه میکنیم. اگر میخواهید پروژه/مقالهای اضافه کنیم، این صفحه را در [گیتهاب](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md) ویرایش کنید.
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md
deleted file mode 100644
index 33ef8da3222..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/mev/index.md
+++ /dev/null
@@ -1,221 +0,0 @@
----
-title: حداکثر ارزش قابل استخراج (MEV)
-description: مقدمهای بر حداکثر ارزش قابل استخراج (MEV)
-lang: fa
----
-
-حداکثر ارزش قابل استخراج (MEV) به بیشترین ارزش قابل استخراج از تولید بلاک اشاره دارد که علاوه بر پاداش استاندارد بلاک شامل کارمزد تراکنشها است و این کارمزدها با وارد کردن، خارج کردن و تغییر در ترتیب تراکنشهای موجود در بلاک میتواند تغییر کند.
-
-## حداکثر ارزش قابل استخراج {#maximal-extractable-value}
-
-حداکثر ارزش قابل استخراج اولین بار در زمینه [اثبات کار](/developers/docs/consensus-mechanisms/pow/)استفاده شد و اوایل به "ارزش قابل استخراج استخراجگر" اشاره میکرد. این به این دلیل است که در اثبات کار استخراجگرها شمول، عدم شمول و ترتیب تراکنشها در بلاک را کنترل میکنند. با این حال، پس از تغییر الگوریتم اجماع به اثبات سهام با [ادغام](/roadmap/merge) اعتبارسنجها این وظایف را بر عهده دارند و استخراج دیگر بخشی از پروتکل اتریوم نیست. روشهای استخراج ارزش همچنان وجود دارند و به همین دلیل عبارت حداکثر ارزش قابل استخراج استفاده میشود.
-
-## پیشنیازها {#prerequisites}
-
-مطمئن شوید که با مفاهیم زیر آشنا هستید.[تراکنشها](/developers/docs/transactions/)، [بلاکها](/developers/docs/blocks/)، [اثبات سهام](/developers/docs/consensus-mechanisms/pos) و [گاز](/developers/docs/gas/). آشنایی با [اپلیکیشنهای غیرمتمرکز](/dapps/) و [امور مالی غیرمتمرکز](/defi/) نیز میتواند مفید باشد.
-
-## استخراج حداکثر ارزش قابل استخراج {#mev-extraction}
-
-در تئوری MEV به طور کامل به اعتبارسنجها تعلق میگیرد زیرا آنها تنها کسانی هستند که میتوانند اجرای یک فرصت سودآور MEV را تضمین کنند. اما در عمل،بیشترین نسبت MEV استخراج شده مربوط به فعالان مستقل شبکه است که با نام «جستجوگرها» (Searcher) شناخته میشوند. جستجوگرها الگوریتمهای پیچیده را بر روی داده بلاک چین اعمال میکنند تا موقعیتهای سودآور MEV را شناسایی کنند و رباتهایی دارند که به صورت خودکار تراکنشهای سودآور را به شبکه ارسال میکند.
-
-به هر حال اعتبارسنجها نیز بخشی از کل MEV را به دست میآورند زیرا جستجوگرها برای اینکه احتمال شمول تراکنش سودآور خود را در بلاک افزایش دهند کارمزد تراکنش بالاتری پرداخت میکنند (که این مبلغ به اعتبارسنج داده میشود). اگر فرض کنیم که جستجوگرها از نظر اقتصادی منطقی هستند، کارمزد تراکنشی که یک جستجوگر مایل است پرداخت کند نهایتا به اندازه 100 درصد MEV محاسبه شده است (زیرا اگر کارمزد تراکنش بالاتر باشد، جستجوگر ضرر میکند).
-
-به همین دلیل، برای برخی از موقعیتهای رقابتی MEV مثل [آربیتراژ در صرافی غیرمتمرکز](#mev-examples-dex-arbitrage)، جستجوگرها مجبورند تا 90 درصد و حتی بیشتر درآمد MEV را به صورت کارمزد تراکنش به اعتبارسنج بدهند زیرا تعداد زیادی از افراد میخواهند همان معامله سودآور آربیتراژ را اجرا کنند. این به این دلیل است که تنها راه تضمین اینکه تراکنش آربیتراژ آنها اجرایی میشود این است که آنها تراکنش را با بالاترین هزینه کارمزد ثبت کرده باشند.
-
-### بهینهسازی گاز {#mev-extraction-gas-golfing}
-
-این پدیده باعث به وجود آمدن یک مزیت رقابتی به نام خوب بودن در "مسابقه گاز" شده است - که به معنای برنامه نویسی تراکنشها به گونهای که کمترین مقدار گاز را مصرف کنند، میباشد - و چون این به جستجوگران اجازه میدهد قیمت گاز بالاتری را تعیین و پرداخت نمایند و در عین حال هزینههای کل مقدار گاز خود را ثابت نگه دارند (از آنجایی که هزینه گاز = قیمت گاز \* گاز مصرف شده میباشد).
-
-چند تکنیک معروف بهینهسازی گاز عبارتند از: استفاده از آدرسهایی که با یک رشته طولانی صفر شروع میشوند (به عنوان مثال [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)) زیرا فضای (و در نتیجه گاز) کمتری برای ذخیره میگیرند. و باقی ماندن توکن های کوچک [ERC-20](/developers/docs/standards/tokens/erc-20/) در قراردادها، از آنجا که برای مقداردهی اولیه یک اسلات ذخیره سازی گاز بیشتری نسبت به به روز رسانی اسلات ذخیره سازی دارد. یافتن تکنیکهای بیشتر برای کاهش مصرف گاز، یک حوزه تحقیقاتی فعال در میان جستجوگران است.
-
-### پیشتازان عمومی {#mev-extraction-generalized-frontrunners}
-
-به جای برنامهریزی الگوریتمهای پیچیده برای شناسایی فرصتهای سودآور MEV، برخی از جستجوگران از پیشتازان عمومی استفاده میکنند. پیشتازان عمومی، ربات هایی هستند که برای شناسایی تراکنش های سودآور، استخر حافظه را تماشا می کنند. پیشتاز کد تراکنش بالقوه سودآور را کپی میکند، آدرسها را با آدرس پیشتاز جایگزین میکند و تراکنش را به صورت محلی اجرا میکند تا دوباره بررسی کند که تراکنش اصلاحشده منجر به سود در آدرس پیشتاز شود. اگر تراکنش واقعاً سودآور باشد، پیشتاز تراکنش اصلاح شده را با آدرس جایگزین شده و گاز بالاتر ارسال میکند و تراکنش اصلی را «پیشآزمایی» میکند و MEV جستجوگر اصلی را دریافت میکند.
-
-### Flashbotها {#mev-extraction-flashbots}
-
-Flashbots یک پروژه مستقل است که کلاینت های اجرا را با سرویسی گسترش میدهد که به جستجوگران اجازه میدهد تا تراکنشهای MEV را بدون افشای آنها برای اعتبارسنج ها ارسال کنند. این کار مانع از پیشروی تراکنش ها توسط پیشتازان عمومی می شود.
-
-## نمونه های MEV {#mev-examples}
-
-MEV به چند روش در بلاک چین ظاهر می شود.
-
-### آربیتراژ DEX {#mev-examples-dex-arbitrage}
-
-آربیتراژ [صرافی غیرمتمرکز](/glossary/#dex) (DEX) ساده ترین و شناخته شده ترین فرصت MEV است. در نتیجه رقابتی ترین هم هست.
-
-این کار به این صورت است: اگر دو DEX یک توکن را با دو قیمت متفاوت ارائه دهند، یک نفر می تواند توکن را در DEX با قیمت پایین تر بخرد و آن را در DEX با قیمت بالاتر در یک تراکنش اتمی بفروشد. به لطف مکانیزم بلاک چین، این آربیتراژ واقعی و بدون ریسک است.
-
-[در اینجا مثالی است](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) از تراکنش آربیتراژ سودآور که در آن جستجوگر با استفاده از قیمتهای متفاوت جفت ETH/DAI در Uniswap در مقابل Sushiswap، 1000 ETH را به 1045 ETH تبدیل کرد.
-
-### نقد شدن ها {#mev-examples-liquidations}
-
-انحلال پروتکل وام دهی فرصت شناخته شده دیگری برای MEV است.
-
-پروتکلهای وام دهی مانند Maker و Aave از کاربران میخواهند که وثیقهای (مانند ETH) را واریز کنند. سپس این وثیقه سپرده شده برای وام دادن به سایر کاربران استفاده می شود.
-
-سپس کاربران میتوانند بسته به نیازشان داراییها و نشانهها را از دیگران قرض بگیرند (مثلاً اگر میخواهید در یک پیشنهاد حاکمیتی MakerDAO رای دهید، ممکن است MKR قرض بگیرید) تا درصد معینی از وثیقه سپردهشدهشان. به عنوان مثال، اگر مبلغ وام حداکثر 30٪ باشد، کاربری که 100 DAI را به پروتکل واریز می کند، می تواند تا 30 DAI دارایی دیگر را وام بگیرد. پروتکل درصد قدرت وام گیری دقیق را تعیین می کند.
-
-همچنان که ارزش وثیقه وام گیرنده نوسان پیدا می کند، قدرت استقراض آنها نیز تغییر می کند. اگر به دلیل نوسانات بازار، ارزش دارایی های قرض گرفته شده بیش از 30٪ ارزش وثیقه آنها باشد (باز هم، درصد دقیق آن توسط پروتکل تعیین می شود)، پروتکل معمولاً به هر کسی اجازه می دهد وثیقه را نقد کند و بلافاصله بدهی وام دهندگان را پرداخت کند (این شبیه نحوه عملکرد [مارجین کال](https://www.investopedia.com/terms/m/margincall.asp) در امور مالی سنتی است). در صورت انحلال، وام گیرنده معمولاً باید هزینه انحلال سنگینی را بپردازد، که بخشی از آن به مدیر تصفیه می رود - جایی که فرصت MEV به وجود می آید.
-
-جستجوگران برای تجزیه و تحلیل داده های بلاک چین در سریع ترین زمان ممکن رقابت می کنند تا تعیین کنند کدام وام گیرندگان می توانند منحل شوند و اولین کسانی باشند که تراکنش انحلال را ارسال می کنند و هزینه انحلال را برای خود دریافت می کنند.
-
-### معامله ساندویچی {#mev-examples-sandwich-trading}
-
-معامله ساندویچی یکی دیگر از روش های رایج استخراج MEV است.
-
-برای ساندویچ کردن، یک جستجوگر استخر حافظه را برای معاملات بزرگ DEX تماشا می کند. به عنوان مثال، فرض کنید شخصی می خواهد 10000 UNI با DAI در Uniswap بخرد. معامله ای به این بزرگی تأثیر مهمی بر جفت UNI/DAI خواهد داشت و به طور بالقوه قیمت UNI را نسبت به DAI افزایش می دهد.
-
-یک جستجوگر می تواند اثر قیمت تقریبی این معامله بزرگ را روی جفت UNI/DAI محاسبه کند و بلافاصله _قبل از_ معامله بزرگ، سفارش خرید بهینه را اجرا کند، UNI را ارزان بخرد، سپس دستور فروش را فوراً _ پس از_ تجارت بزرگ اجرا کند و آن را به قیمت بالاتر ناشی از سفارش بزرگ بفروشد.
-
-با این حال، ساندویچ کردن خطرناک تر است زیرا اتمی نیست (برخلاف آربیتراژ DEX، همانطور که در بالا توضیح داده شد) و مستعد [حمله salmonella ](https://github.com/Defi-Cartel/salmonella) است.
-
-### MEV در NFT {#mev-examples-nfts}
-
-MEV در فضای NFT یک پدیده نوظهور است و لزوماً سودآور نیست.
-
-با این حال، از آنجایی که تراکنشهای NFT روی همان بلاک چین مشترک سایر تراکنشهای اتریوم انجام میشوند، جستجوگران میتوانند از تکنیکهای مشابهی که در فرصتهای سنتی MEV در بازار NFT استفاده میشود، استفاده کنند.
-
-به عنوان مثال، اگر یک افت NFT محبوب وجود داشته باشد و یک جستجوگر یک NFT خاص یا مجموعه ای از NFT ها را بخواهد، می تواند یک تراکنش را طوری برنامه ریزی کند که اولین نفر در صف خرید NFT باشد، یا می تواند کل مجموعه NFT ها را در یک تراکنش خریداری کند. یا اگر یک NFT [به اشتباه با قیمت پایین فهرست شده باشد](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent)، جستجوگر می تواند از سایر خریداران پیشی گرفته و آن را با قیمت ارزان خریداری کند.
-
-یکی از نمونههای برجسته MEV در NFT زمانی رخ داد که یک جستجوگر 7 میلیون دلار برای [خرید](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) هر Cryptopunk در کف قیمت هزینه کرد. یک محقق بلاک چین [در توییتر توضیح داد](https://twitter.com/IvanBogatyy/status/1422232184493121538) چگونه خریدار با یک ارائه دهنده MEV کار می کرد تا خرید خود را مخفی نگه دارد.
-
-### قصه طولانی {#mev-examples-long-tail}
-
-آربیتراژ DEX، انحلال، و معامله ساندویچی همگی فرصت های MEV بسیار شناخته شده ای هستند و بعید است که برای جستجوگران جدید سودآور باشند. با این حال، قصه درازی از فرصت های کمتر شناخته شده MEV وجود دارد (MEV در NFT مسلماً یکی از این فرصت ها است).
-
-جستجوگرانی که به تازگی شروع به کار کرده اند ممکن است بتوانند با جستجوی MEV در این دقصه طولانی موفقیت بیشتری پیدا کنند. بورد کار MEV متعلق به Flashbot برخی از فرصتهای نوظهور را فهرست میکند.
-
-## اثرات MEV {#effects-of-mev}
-
-MEV کلا بد نیست - پیامدهای مثبت و منفی برای MEV روی اتریوم وجود دارد.
-
-### خوب {#effects-of-mev-the-good}
-
-بسیاری از پروژههای DeFi برای اطمینان از سودمندی و پایداری پروتکلهای خود به عوامل منطقی اقتصادی متکی هستند. به عنوان مثال، آربیتراژ DEX تضمین میکند که کاربران بهترین و صحیحترین قیمتها را برای توکنهای خود دریافت میکنند و پروتکلهای وامدهی به انحلال سریع متکی هستند، زمانی که وامگیرندگان کمتر از نسبت وثیقهگذاری میشوند تا اطمینان حاصل شود که وامدهندگان بازپرداخت میکنند.
-
-بدون جستجوگران منطقی که به دنبال و رفع ناکارآمدیهای اقتصادی باشند و از انگیزههای اقتصادی پروتکلها بهره ببرند، پروتکلهای DeFi و به طور کلی ممکن است مانند امروز قوی نباشند.
-
-### بد {#effects-of-mev-the-bad}
-
-در لایه برنامه، برخی از اشکال MEV، مانند معامله ساندویچی، منجر به یک تجربه بدتر برای کاربران می شود. کاربرانی که ساندویچ می شوند با افزایش افت قیمت و اجرای بدتر در معاملات خود مواجه می شوند.
-
-در لایه شبکه، پیشتازان تعمیم یافته و حراج های قیمت گس که اغلب در آن شرکت می کنند (زمانی که دو یا چند نفر پیشتاز برای گنجاندن تراکنش در بلوک بعدی با افزایش تدریجی قیمت گس تراکنش های خود رقابت می کنند) منجر به تراکم شبکه و قیمت بالای گس برای هر کس دیگری میشود که سعی در انجام معاملات منظم دارد.
-
-فراتر از آنچه در _در_ بلوکها اتفاق میافتد، MEV میتواند اثرات مضر _ما بین_ بلوکها داشته باشد. اگر MEV موجود در یک بلوک بهطور قابلتوجهی از پاداش بلوک استاندارد فراتر رود، اعتبارسنج ها ممکن است تشویق شوند تا بلوکها را مجددا سازماندهی کنند و MEV را برای خود بگیرند، که باعث سازماندهی مجدد بلاک چین و بیثباتی اجماع می شود.
-
-این امکان سازماندهی مجدد بلاکچین [قبلاً در بلاک چین بیتکوین بررسی شده است](https://dl.acm.org/doi/10.1145/2976749.2978408). از آنجایی که پاداش بلاک بیتکوین به نصف میرسد و کارمزد تراکنشها بخش بزرگتر و بیشتری از پاداش بلوک را تشکیل میدهند، شرایطی پیش میآید که از نظر اقتصادی منطقی میشود که استخراجکنندگان از پاداش بلوک بعدی صرفنظر کنند و در عوض بلوکهای گذشته را با کارمزد بالاتر یادآوری کنند. با رشد MEV، وضعیت مشابهی ممکن است در اتریوم رخ دهد و یکپارچگی بلاک چین را تهدید کند.
-
-## حالت MEV {#state-of-mev}
-
-استخراج MEV در اوایل سال 2021 افزایش یافت و منجر به قیمت بسیار بالای گس در چند ماه اول سال شد. ظهور رله MEV متعلق به Flashbots اثربخشی پیشتازان عمومی را کاهش داده و حراج قیمت گس را از زنجیره خارج کرده و قیمت گس را برای کاربران عادی کاهش داده است.
-
-در حالی که بسیاری از جستجوگران هنوز از MEV درآمد خوبی کسب می کنند، با شناخته شدن فرصت ها و رقابت جستجوگران بیشتر و بیشتر برای فرصت های مشابه، اعتبار سنج ها درآمد کل MEV بیشتری را به دست خواهند آورد (زیرا همان نوع حراج گس که در ابتدا در بالا توضیح داده شد. در Flashbots نیز اتفاق می افتد، البته به صورت خصوصی، و اعتبار سنج ها درآمد حاصل از گس را دریافت می کنند). MEV نیز منحصر به اتریوم نیست و با رقابتی شدن فرصت ها در اتریوم، جستجوگران به سمت بلاک چین های جایگزین مانند زنجیره هوشمند بایننس حرکت می کنند، جایی که فرصت های MEV مشابه با اتریوم با رقابت کمتری وجود دارد.
-
-از سوی دیگر، انتقال از اثبات کار به اثبات سهام و تلاش مداوم برای مقیاسبندی اتریوم با استفاده از جمعآوریها، همگی چشمانداز MEV را به روشهایی تغییر میدهند که هنوز تا حدودی نامشخص است. هنوز به خوبی شناخته نشده است که چگونه داشتن پیشنهاد دهندگان بلوک تضمین شده که از قبل کمی شناخته شده اند، دینامیک استخراج MEV را در مقایسه با مدل احتمالی در اثبات کار تغییر می دهد یا چگونه این امر هنگام [انتخاب رهبر مخفی منفرد0 مختل می شود ](https://ethresear.ch/t/secret-non-single-leader-election/11789) و [فناوری اعتبارسنج توزیع شده](/staking/dvt/) پیاده سازی می شود. به طور مشابه، باید دید چه فرصتهای MEV زمانی وجود دارد که بیشتر فعالیتهای کاربر از اتریوم خارج میشوند و روی رولآپ های لایه 2 و شاردهای آن منتقل میشوند.
-
-## MEV در اثبات سهام اتریوم (PoS) {#mev-in-ethereum-proof-of-stake}
-
-همانطور که توضیح داده شد، MEV پیامدهای منفی برای تجربه کلی کاربر و امنیت لایه اجماع دارد. اما انتقال اتریوم به اجماع اثبات سهام (معروف به "ادغام") به طور بالقوه خطرات جدید مرتبط با MEV را معرفی می کند:
-
-### تمرکزگرایی اعتبارسنج {#validator-centralization}
-
-در اتریوم پس از ادغام، اعتبارسنج ها (با سپرده گذاری امنیتی 32 اتریوم) در مورد اعتبار بلوک های اضافه شده به زنجیره بیکن اتفاق نظر دارند. از آنجایی که 32 ETH ممکن است از دسترس بسیاری خارج باشد، [پیوستن به یک استخر سهام](/staking/pools/) ممکن است گزینه عملی تری باشد. با این وجود، توزیع سالم [سهامگذاران انفرادی](/staking/solo/) ایده آل است، زیرا تمرکز اعتبارسنج ها را کاهش می دهد و امنیت اتریوم را بهبود می بخشد.
-
-با این حال، اعتقاد بر این است که استخراج MEV قادر به تسریع تمرکز اعتبارسنج است. این تا حدی به این دلیل است که اعتبارسنج ها [درآمد کمتری برای پیشنهاد بلوکها ](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) نسبت به ماینرهای قبلی دارند، استخراج MEV از زمان ادغام تا حد زیادی [درآمد اعتبارسنج ها را تحت تأثیر قرار میدهد](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb).
-
-استخرهای بزرگتر سهامگذاری احتمالاً منابع بیشتری برای سرمایه گذاری در بهینه سازی های لازم برای جذب فرصت های MEV خواهند داشت. هرچه این استخرها MEV بیشتری استخراج کنند، منابع بیشتری برای بهبود قابلیتهای استخراج MEV (و افزایش درآمد کلی) دارند، که اساساً [اقتصاد مقیاس](https://www.investopedia.com/terms/e/economiesofscale.asp#) ایجاد میکند.
-
-با منابع کمتری که در اختیار دارند، سهامداران انفرادی ممکن است نتوانند از فرصت های MEV سود ببرند. این ممکن است فشار را بر اعتبارسنج های مستقل برای پیوستن به استخرهای قدرتمند برای افزایش درآمدشان افزایش دهد و تمرکززدایی در اتریوم را کاهش دهد.
-
-### استخرهای حافظه دارای مجوز {#permissioned-mempools}
-
-در پاسخ به حملات ساندویچ و پیشتاز، معامله گران ممکن است شروع به انجام معاملات خارج از زنجیره با اعتبارسنج ها برای حفظ حریم خصوصی تراکنش کنند. معاملهگر به جای ارسال یک تراکنش بالقوه MEV به استخر حافظه عمومی، آن را مستقیماً برای اعتبارسنج ارسال میکند که آن را در یک بلوک قرار میدهد و سود را با معاملهگر تقسیم میکند.
-
-«استخرهای تاریک» نسخه بزرگتری از این ترتیب است و بهعنوان استخرهای حافظه مجاز و فقط قابل دسترسی برای کاربرانی که مایل به پرداخت هزینههای خاصی هستند، عمل میکنند. این روند بی مجوز بودن و عدم اعتماد اتریوم را کاهش می دهد و به طور بالقوه بلاک چین را به مکانیزم «پرداخت برای بازی» تبدیل می کند که به نفع بالاترین پیشنهاد دهنده است.
-
-استخرهای حافظه دارای مجوز همچنین خطرات متمرکزسازی که در بخش قبل توضیح داده شد را تسریع می کنند. استخرهای بزرگی که دارای اعتبارسنج های متعدد هستند، احتمالاً از ارائه حریم خصوصی تراکنش به معامله گران و کاربران سود می برند و درآمد MEV آنها را افزایش می دهند.
-
-مبارزه با این مشکلات مرتبط با MEV در اتریوم پس از ادغام، یک حوزه اصلی تحقیق است. تا به امروز، دو راه حل پیشنهادی برای کاهش تأثیر منفی MEV بر تمرکززدایی و امنیت اتریوم پس از ادغام، **جداسازی پیشنهاد دهنده-سازنده (PBS)** و **API Builder** هستند.
-
-### تفکیک پیشنهاد دهنده و سازنده {#proposer-builder-separation}
-
-هم در اثبات کار و هم در اثبات سهام، گرهی که یک بلوک می سازد، آن را برای اضافه کردن به زنجیره به گره های دیگر شرکت کننده در اجماع پیشنهاد می کند. یک بلوک جدید پس از ساختن یک استخراجگر دیگر در بالای آن (در PoW) یا دریافت تاییدیه از اکثر اعتبارسنج ها (در PoS) بخشی از زنجیره متعارف می شود.
-
-ترکیبی از نقش های سازنده بلوک و پیشنهاد دهنده بلوک چیزی است که بیشتر مشکلات مربوط به MEV را که قبلاً توضیح داده شد معرفی می کند. برای مثال، گرههای اجماع انگیزه ایجاد سازماندهی مجدد زنجیرهای در حملات طولانی برای به حداکثر رساندن درآمد MEV دارند.
-
-[تفکیک پیشنهاد دهنده-سازنده](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) برای کاهش تأثیر MEV، به ویژه در لایه اجماع، طراحی شده است. ویژگی اصلی PBS جداسازی قوانین سازنده بلوک و پیشنهاد دهنده بلوک است. اعتبارسنج ها همچنان مسئول پیشنهاد و رایگیری در مورد بلوکها هستند، اما دسته جدیدی از نهادهای تخصصی به نام **بلوک سازان**، وظیفه سفارش تراکنشها و ساخت بلوکها را بر عهده دارند.
-
-تحت PBS، یک سازنده بلوک یک بسته تراکنش ایجاد می کند و پیشنهادی را برای گنجاندن آن در یک بلوک بیکن چین (به عنوان "بار اجرایی") قرار می دهد. اعتبارسنج انتخاب شده برای پیشنهاد بلوک بعدی، پیشنهادات مختلف را بررسی میکند و بستهای را با بالاترین هزینه انتخاب میکند. PBS اساساً یک بازار حراج ایجاد می کند، جایی که سازندگان با اعتبارسنج هایی که فضای بلوک را می فروشند، مذاکره می کنند.
-
-طرحهای فعلی PBS از یک [طرح آشکارسازی تعهد](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) استفاده میکنند که در آن سازندگان فقط یک تعهد رمزنگاری به محتویات یک بلوک (سر بلوک) را همراه با پیشنهادات خود منتشر میکنند. پس از پذیرش پیشنهاد برنده، پیشنهاد دهنده یک پیشنهاد بلوک امضا شده ایجاد می کند که شامل سر بلوک است. انتظار میرود سازنده بلوک پس از مشاهده طرح بلوک امضاشده، متن کامل بلوک را منتشر کند، و همچنین باید قبل از نهایی شدن، [تأییدکنندههای](/glossary/#attestation) کافی از اعتبارسنج ها دریافت کند.
-
-#### چگونه جداسازی پیشنهاد دهنده و سازنده تأثیر MEV را کاهش می دهد؟ {#how-does-pbs-curb-mev-impact}
-
-جداسازی پیشنهاد دهنده-سازنده درون پروتکل، با حذف استخراج MEV از حوزه اعتبارسنج ها، اثر MEV بر اجماع را کاهش میدهد. در عوض، سازندگان بلوک که سختافزار تخصصی را اجرا میکنند، فرصتهای MEV را در آینده به دست خواهند آورد.
-
-این امر اعتبارسنج ها را بهطور کامل از درآمد مرتبط با MEV مستثنی نمیکند، زیرا سازندگان باید برای پذیرش بلوکهایشان توسط اعتبارسنج ها، قیمت بالایی داشته باشند. با این وجود، با توجه به اینکه اعتبارسنج ها دیگر مستقیماً بر روی بهینهسازی درآمد MEV تمرکز نمیکنند، تهدید حملات طولانی کاهش مییابد.
-
-جداسازی پیشنهاد دهنده-سازنده همچنین خطرات متمرکزسازی MEV را کاهش می دهد. به عنوان مثال، استفاده از یک طرح تعهد-افشا، نیاز سازندگان را به اعتماد به اعتبارسنج ها برای ربودن فرصت MEV یا افشای آن در معرض سایر سازندگان از بین میبرد. این امر مانع سود سهامداران انفرادی از MEV را کاهش می دهد، در غیر این صورت، سازندگان به طرفداری از استخرهای بزرگ با شهرت خارج از زنجیره و انجام معاملات خارج از زنجیره با آنها گرایش پیدا می کنند.
-
-به طور مشابه، اعتبارسنج ها مجبور نیستند به سازندگان بلوک اعتماد کنند که بدنه های بلوک را پس نمیکشند یا بلوک های نامعتبر را منتشر نمی کنند زیرا پرداخت بدون قید و شرط است. حتی اگر بلوک پیشنهادی در دسترس نباشد یا توسط اعتبارسنجی دیگر نامعتبر اعلام شود، هزینه اعتبارسنج همچنان پردازش میکند. در مورد دوم، بلوک به سادگی دور ریخته می شود و سازنده بلوک را مجبور می کند که تمام هزینه های تراکنش و درآمد MEV را از دست بدهد.
-
-### API سازندهی بلوک {#builder-api}
-
-در حالی که جداسازی پیشنهاد دهنده و سازنده وعده کاهش اثرات استخراج MEV را می دهد، اجرای آن نیازمند تغییراتی در پروتکل اجماع است. به طور خاص، قانون [انتخاب فورک](/developers/docs/consensus-mechanisms/pos/#fork-choice) در بیکن چین باید به روز شود. [API سازنده بلوک](https://github.com/ethereum/builder-specs) یک راه حل موقت است که با هدف ارائه پیاده سازی کاری جداسازی پیشنهاد دهنده-سازنده، البته با مفروضات اعتماد بالاتر است.
-
-API سازنده بلوک نسخه اصلاح شده [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) است که توسط کلاینت های لایه اجماع برای درخواست بارهای اجرایی از کلاینت های لایه اجرا استفاده می شود. همانطور که در [مشخصات اعتبارسنج صادق](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) مشخص شده است، اعتبارسنجی هایی که برای وظایف پیشنهادی بلوک انتخاب میشوند، یک بسته تراکنش را از یک کلاینت اجرا که متصل است درخواست میکنند که آن را در بلوک پیشنهادی بیکن چین قرار میدهند.
-
-API سازنده بلوک همچنین به عنوان یک میان افزار بین اعتبارسنج و کلاینت های لایه اجرا عمل می کند. اما متفاوت است زیرا به اعتبارسنج های موجود در بیکن چین اجازه میدهد تا بلوکها را از موجودیتهای خارجی تهیه کنند (بهجای ساختن یک بلوک به صورت محلی با استفاده از یک کلاینت اجرا).
-
-در زیر یک نمای کلی از نحوه عملکرد API سازنده بلوک آورده شده است:
-
-1. Builder API اعتبارسنج را به شبکه ای از سازنده های بلوک که کلاینت های لایه اجرا را اجرا می کنند متصل می کند. مانند PBS، سازندگان بلوک نیز طرف های تخصصی هستند که در بلوکسازی با منابع فشرده سرمایهگذاری میکنند و از استراتژیهای مختلف برای به حداکثر رساندن درآمد حاصل از MEV به علاوه ترفند های اولویت بندی استفاده میکنند.
-
-2. یک اعتبارسنج (که یک کلاینت لایه اجماع را اجرا می کند) بارهای اجرایی را به همراه پیشنهادات از شبکه سازندگان درخواست می کند. پیشنهادهای سازنده شامل سرفصل بار اجرایی - تعهد رمزنگاری به محتویات بار - و هزینه ای است که باید به اعتبارسنج پرداخت شود.
-
-3. اعتبارسنج پیشنهادهای دریافتی را بررسی میکند و بار اجرایی را با بالاترین هزینه انتخاب میکند. با استفاده از API سازنده، اعتبارسنج یک پیشنهاد بلوک "کور" در بیکن ایجاد می کند که فقط شامل امضای آنها و سر پرداخت اجرا می شود و آن را برای سازنده ارسال می کند.
-
-4. سازندهای که API سازنده را اجرا میکند، انتظار میرود که با مشاهده پیشنهاد بلوک کور، با بار اجرایی کامل پاسخ دهد. این به اعتبارسنج اجازه می دهد تا یک بلوک بیکن "امضا" شده ایجاد کند که در سراسر شبکه منتشر می شود.
-
-5. هنوز انتظار میرود که اعتبارسنج با استفاده از API سازنده، در صورتی که سازنده بلوک به سرعت پاسخ ندهد، یک بلوک را به صورت محلی بسازد، بنابراین پاداشهای پیشنهاد بلوک را از دست نمیدهند. با این حال، اعتبارسنج نمیتواند بلوک دیگری را با استفاده از تراکنشهای آشکار شده یا مجموعهای دیگر ایجاد کند، زیرا به معنای _مبهم سازی_ (امضا کردن دو بلوک در یک اسلات) است، که یک جرم قابل جریمه شدن است.
-
-یک نمونه از پیادهسازی API سازنده همین [MEV Boost](https://github.com/flashbots/mev-boost) است، یک بهینه سازی در [مکانیسم حراج فلشباتها](https://docs.flashbots.net/Flashbots-auction/overview/) که برای مهار اثرات جانبی منفی MEV در اتریوم طراحی شده است. حراج Flashbots به اعتبارسنج ها در اثبات سهام اجازه می دهد تا کار ساخت بلوک های سودآور را به طرف های تخصصی به نام **جستجوگرها** برون سپاری کنند.
-
-جستجوگران به دنبال فرصتهای سودآور MEV میگردند و بستههای تراکنش را برای مسدود کردن پیشنهادکنندگان همراه با [مناقصه با قیمت مهر و موم شده](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) برای درج در بلوک ارسال میکنند. اعتباردهندهای که mev-geth را اجرا میکند، یک نسخه فورک شده از کلاینت go-ethereum (Geth) فقط باید بستهای را انتخاب کند که بیشترین سود را دارد و آن را به عنوان بخشی از بلوک جدید قرار دهد. برای محافظت از پیشنهاد دهندگان بلوک (اعتبارسنج ها) در برابر هرزنامه و تراکنشهای نامعتبر، بستههای تراکنش قبل از رسیدن به پیشنهاددهنده از **relayerها** برای اعتبارسنجی عبور میکنند.
-
-MEV Boost همان حراج Flashbots اصلی را حفظ می کند، البته با ویژگی های جدیدی که برای تغییر اتریوم به اثبات سهام طراحی شده است. جستجوگران هنوز تراکنشهای سودآور MEV را برای گنجاندن در بلوکها پیدا میکنند، اما دسته جدیدی از طرفهای تخصصی به نام **سازندگان بلوک** مسئول جمعآوری تراکنشها و بستهها در بلوکها هستند. سازنده پیشنهادات قیمت مهر و موم شده را از جستجوگران می پذیرد و بهینه سازی هایی را برای یافتن سودآورترین سفارش اجرا می کند.
-
-رله همچنان مسئول اعتبارسنجی بسته های تراکنش قبل از ارسال آنها به پیشنهاد دهنده است. با این حال، MEV Boost در این حین **scrows** را معرفی میکند که مسئول ارائه [در دسترس بودن دادهها](/developers/docs/data-availability/) با ذخیره بدنههای بلوک ارسال شده توسط سازندهها و سرهای بلوک ارسال شده توسط اعتبارسنج ها هستند. در اینجا، یک اعتبارسنج متصل به یک رله، بارهای اجرایی موجود را میپرسد و از الگوریتم سفارش MEV Boost برای انتخاب سر بار پرداخت با بالاترین پیشنهاد + نکات MEV استفاده میکند.
-
-#### چگونه API سازنده تأثیر MEV را کاهش می دهد؟ {#how-does-builder-api-curb-mev-impact}
-
-مزیت اصلی API سازنده پتانسیل آن برای دموکراتیک کردن دسترسی به فرصت های MEV است. استفاده از طرحهای commit-reveal مفروضات اعتماد را حذف میکند و موانع ورود را برای اعتبارسنج ها که به دنبال بهرهمندی از MEV هستند کاهش میدهد. این باید فشار روی سهامگذاران انفرادی را برای ادغام با استخرهای بزرگ به منظور افزایش سود MEV کاهش دهد.
-
-اجرای گسترده API سازنده رقابت بیشتر بین سازندگان بلوک را تشویق می کند که مقاومت در برابر سانسور را افزایش می دهد. از آنجایی که اعتبارسنج ها پیشنهادهای سازندههای متعدد را بررسی میکنند، سازندهای که قصد سانسور یک یا چند تراکنش کاربر را دارد باید از همه سازندگان غیرسانسورکننده دیگر پیشی بگیرد تا موفق شود. این به طور چشمگیری هزینه سانسور کاربران را افزایش می دهد و این عمل را دلسرد می کند.
-
-برخی از پروژهها، مانند MEV Boost، از API سازنده به عنوان بخشی از ساختار کلی استفاده میکنند که برای ارائه حریم خصوصی تراکنشها به برخی از طرفها طراحی شده است، مانند معاملهگرانی که سعی میکنند از حملات پیشتازی/ ساندویچ اجتناب کنند. این با ارائه یک کانال ارتباطی خصوصی بین کاربران و سازندگان بلوک به دست می آید. برخلاف استخرهای حافظه دارای مجوز که قبلا توضیح داده شد، این رویکرد به دلایل زیر سودمند است:
-
-1. وجود سازنده های متعدد در بازار سانسور را غیرعملی می کند که به نفع کاربران است. در مقابل، وجود استخرهای تاریک متمرکز و مبتنی بر اعتماد، قدرت را در دستان معدود سازندگان بلوک متمرکز میکند و امکان سانسور را افزایش میدهد.
-
-2. نرم افزار API سازنده منبع باز است که به هر کسی اجازه می دهد خدمات سازنده بلوک را ارائه دهد. این بدان معناست که کاربران مجبور به استفاده از بلوکساز خاصی نیستند و بیطرفی و عدم مجوزمحوری اتریوم را بهبود میبخشد. علاوه بر این، معاملهگرانی که به دنبال MEV هستند، سهواً با استفاده از کانالهای تراکنش خصوصی، به متمرکزسازی کمک نمیکنند.
-
-## منابع مرتبط {#related-resources}
-
-- [اسناد Flashbotها](https://docs.flashbots.net/)
-- [گیتهاب Flashbotها](https://github.com/flashbots/pm)
-- [MEV-Explore](https://explore.flashbots.net/) - _داشبورد و کاوشگر تراکنش زنده برای تراکنشهای MEV_
-- [mevboost.org](https://www.mevboost.org/) - _ردیاب با آمار بیدرنگ برای رلههای MEV-Boost و سازندگان بلوک_
-
-## بیشتر بخوانید {#further-reading}
-
-- [ارزش قابل استخراج استخراجگر (MEV) چیست؟](https://blog.chain.link/what-is-miner-extractable-value-mev/)
-- [MEV و Me](https://www.paradigm.xyz/2021/02/mev-and-me)
-- [اتریوم یک جنگل تاریک است](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/)
-- [فرار از جنگل تاریک](https://samczsun.com/escaping-the-dark-forest/)
-- [Flashbotها: فرار رو به جلو در بحران MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752)
-- [@bertcmiller's MEV Threads](https://twitter.com/bertcmiller/status/1402665992422047747)
-- [MEV-Boost: معماری Flashbots آماده ادغام](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
-- [MEV Boost چیست؟](https://www.alchemy.com/overviews/mev-boost)
-- [چرا mev-boost را اجرا کنید؟](https://writings.flashbots.net/writings/why-run-mevboost/)
-- [راهنمای سفر به اتریوم](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md
deleted file mode 100644
index 64c34080230..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/oracles/index.md
+++ /dev/null
@@ -1,433 +0,0 @@
----
-title: Oracles
-description: اوراکلها قراردادهای هوشمند اتریوم را با دسترسی به دادههای دنیای واقعی، باز کردن موارد استفاده بیشتر و ارزش بیشتر برای کاربران فراهم میکند.
-lang: fa
----
-
-اوراکلها برنامههایی هستند که فیدهای داده تولید میکنند که منابع داده خارج از زنجیره را برای قراردادهای هوشمند در دسترس بلاکچین قرار میدهند. این امر ضروری است زیرا قراردادهای هوشمند مبتنی بر اتریوم به طور پیش فرض نمیتوانند به اطلاعات ذخیره شده خارج از شبکه بلاکچین دسترسی داشته باشند.
-
-دادن قابلیت اجرای قراردادهای هوشمند با استفاده از دادههای خارج از زنجیره، کاربرد و ارزش برنامههای غیرمتمرکز را گسترش میدهد. به عنوان مثال، بازارهای پیشبینی زنجیرهای به اوراکلها برای ارائه اطلاعاتی درباره نتایجی که برای اعتبارسنجی پیشبینیهای کاربر استفاده میکنند، متکی هستند. فرض کنید آلیس 20 ETH بر روی این که چه کسی رئیس جمهور آینده ایالات متحده آمریکا خواهد شد، شرط ببندد. در آن صورت، پیشبینی بازار به یک اوراکل برای تأیید نتایج انتخابات و تعیین اینکه آیا آلیس (Alice) واجد شرایط پرداخت است یا خیر، نیاز دارد.
-
-## موارد مورد نیاز {#prerequisites}
-
-این صفحه فرض میکند که خواننده با مفاهیم پایه اتریوم از جمله [گرهها](/developers/docs/nodes-and-clients/)، [مکانیزم اجماع](/developers/docs/consensus-mechanisms/) و [ماشین مجازی اتریوم یا EVM](/developers/docs/evm/) آشنا میباشد. همچنین شما باید درک خوبی از [قراردادهای هوشمند](/developers/docs/smart-contracts/) و [ساختار قراردادهای هوشمند](/developers/docs/smart-contracts/anatomy/)، مخصوصاً [رویدادها](/glossary/#events) داشته باشید.
-
-## اوراکل بلاکچین چیست؟ {#what-is-a-blockchain-oracle}
-
-اوراکلها برنامههایی هستند که اطلاعات خارجی (یعنی اطلاعات ذخیره شده خارج از زنجیره) را به قراردادهای هوشمند در حال اجرا بر روی بلاکچین منبع، تأیید و انتقال میدهند. علاوه بر «پول کردن» دادههای خارج از زنجیره و پخش آن در اتریوم، اوراکلها همچنین میتوانند اطلاعات را از بلاکچین به سیستمهای خارجی «پوش» کنند، بهعنوان مثال، زمانی که کاربر هزینهای را از طریق تراکنش اتریوم ارسال میکند، قفل هوشمند را باز کند.
-
-بدون اوراکل، یک قرارداد هوشمند به طور کامل به دادههای زنجیرهای محدود میشود.
-
-اوراکلها بر اساس منبع دادهها (یک یا چند منبع)، مدلهای قابل اعتماد (متمرکز یا غیرمتمرکز)، و معماری سیستم (خواندن فوری، انتشار، اشتراک، و درخواست-پاسخ) متفاوت هستند. ما همچنین میتوانیم بین اوراکلها تمایز قائل شویم که آیا آنها دادههای خارجی را برای استفاده توسط قراردادهای روی زنجیره (اوراکلهای ورودی) بازیابی میکنند، اطلاعات را از زنجیره بلاک به برنامههای خارج از زنجیره (اوراکلهای خروجی) ارسال میکنند یا وظایف محاسباتی را خارج از زنجیره انجام میدهند (اوراکلهای محاسباتی).
-
-## چرا قراردادهای هوشمند به اوراکل نیاز دارند؟ {#why-do-smart-contracts-need-oracles}
-
-بسیاری از توسعه دهندگان قراردادهای هوشمند را به عنوان کدی می بینند که در آدرسهای خاصی در بلاکچین اجرا میشود. با این حال، [دیدگاه کلیتر قراردادهای هوشمند](/smart-contracts/) این است که آنها برنامههای نرمافزاری خود-اجرای هستند که قادر به اجرای توافقات بین طرفین پس از برآورده شدن شرایط خاص هستند - از این رو به این اصطلاح قراردادهای هوشمند میگوییم.»
-
-اما استفاده از قراردادهای هوشمند برای اجرای توافقات بین افراد، با توجه به اینکه اتریوم قطعی است، ساده نیست. یک [سیستم قطعی](https://en.wikipedia.org/wiki/Deterministic_algorithm) سیستمی است که همیشه نتایج یکسانی را با توجه به وضعیت اولیه و یک ورودی خاص تولید میکند، به این معنی که تصادفی یا تغییر در فرآیند محاسبه خروجیها از ورودی ها وجود ندارد.
-
-برای دستیابی به اجرای قطعی، بلاک چینها گرهها را به اجماع در مورد سؤالات باینری ساده (درست/نادرست) با استفاده از _فقط_ دادههای ذخیره شده در خود بلاک چین محدود میکنند. نمونههایی از این گونه سوالات عبارتند از:
-
-- "آیا مالک حساب (که با یک کلید عمومی مشخص میشود) این تراکنش را با کلید خصوصی جفت شده امضا کرده است؟"
-- "آیا این حساب دارای وجوه کافی برای پوشش تراکنش است؟"
-- «آیا این معامله در چارچوب این قرارداد هوشمند معتبر است؟» و غیره.
-
-اگر بلاکچینها اطلاعاتی را از منابع خارجی (یعنی از دنیای واقعی) دریافت میکردند، دستیابی به جبر غیرممکن خواهد بود و از توافق گرهها در مورد اعتبار تغییرات در وضعیت بلاک چین جلوگیری میکند. به عنوان مثال یک قرارداد هوشمند را در نظر بگیرید که یک تراکنش را بر اساس نرخ ارز فعلی اتر-USD به دست آمده از یک API قیمت سنتی انجام میدهد. این رقم احتمالاً اغلب تغییر میکند (غیر از اینکه API ممکن است منسوخ یا هک شود)، به این معنی که گره یا همان نودهایی که کد قرارداد یکسانی را اجرا میکنند به نتایج متفاوتی میرسند.
-
-برای یک بلاک چین عمومی مانند اتریوم، با هزاران گره در سراسر جهان که تراکنشها را پردازش میکنند، جبرگرایی بسیار مهم است. بدون هیچ مرجع مرکزی به عنوان منبع حقیقت، گرهها به مکانیزمهایی برای رسیدن به همان حالت پس از اعمال همان تراکنشها نیاز دارند. موردی که به موجب آن گره یا نود A کد قرارداد هوشمند را اجرا میکند و در نتیجه "3" دریافت میکند، در حالی که گره یا نود B پس از اجرای همان تراکنش، "7" را دریافت میکند، باعث میشود اجماع از بین برود و ارزش اتریوم به عنوان یک پلتفرم محاسباتی غیرمتمرکز را حذف کند.
-
-این سناریو همچنین مشکل طراحی بلاکچین برای استخراج اطلاعات از منابع خارجی را مطرح میکند. با این حال، اوراکل این مشکل را با گرفتن اطلاعات از منابع خارج از زنجیره و ذخیره آن در بلاکچین برای مصرف قراردادهای هوشمند حل میکند. از آنجایی که اطلاعات ذخیره شده در زنجیره غیرقابل تغییر و در دسترس عموم است، گره یا نودهای اتریوم میتوانند با خیال راحت از دادههای خارج از زنجیره وارد شده اوراکل برای محاسبه تغییرات حالت بدون اجماع استفاده کنند.
-
-برای انجام این کار، اوراکل معمولاً از یک قرارداد هوشمند در حال اجرا بر روی زنجیره و برخی از اجزای خارج از زنجیره تشکیل شده است. قرارداد روی زنجیره درخواستهایی برای دادهها از سایر قراردادهای هوشمند دریافت میکند، که آنها را به جزء خارج از زنجیره (به نام گره اوراکل) ارسال میکند. این گره یا نود اوراکل میتواند منابع داده را جستجو کند - برای مثال با استفاده از رابطهای برنامهنویسی کاربردی (API) - و تراکنشهایی را برای ذخیره دادههای درخواستی در فضای ذخیرهسازی قرارداد هوشمند ارسال کند.
-
-اساساً یک اوراکل بلاک چین، شکاف اطلاعاتی بین بلاک چین و محیط خارجی را پر کرده و "قراردادهای هوشمند ترکیبی" ایجاد میکند. قرارداد هوشمند ترکیبی قراردادی است که بر اساس ترکیبی از کد قرارداد درون زنجیرهای و زیرساخت خارج از زنجیره عمل میکند. بازارهای پیشبینی غیرمتمرکز نمونهای عالی از قراردادهای هوشمند ترکیبی هستند. نمونههای دیگر ممکن است شامل قراردادهای هوشمند بیمه محصولات باشد که زمانی پرداخت میشوند که مجموعهای از اوراکلها تشخیص دهند که پدیدههای آب و هوایی خاصی رخ داده است.
-
-## مشکل اوراکل چیست؟ {#the-oracle-problem}
-
-اوراکلها یک مشکل مهم را حل میکنند، اما برخی از عوارض را نیز معرفی میکنند، به عنوان مثال:
-
-- چگونه بررسی کنیم که اطلاعات وارد شده از منبع صحیح استخراج شده یا دستکاری نشده است؟
-
-- چگونه اطمینان حاصل کنیم که این دادهها همیشه در دسترس هستند و به طور منظم به روز میشوند؟
-
-به اصطلاح "مشکل اوراکل" مشکلاتی را که با استفاده از اوراکلهای بلاک چین برای ارسال ورودی به قراردادهای هوشمند به وجود میآید را نشان میدهد. برای اجرای صحیح قرارداد هوشمند، دادههای اوراکل باید صحیح باشد. علاوه بر این، نیاز به «اعتماد» به اپراتورهای اوراکل برای ارائه اطلاعات دقیق، جنبه «بدون نیاز به اعتماد» قراردادهای هوشمند را تضعیف میکند.
-
-اوراکلهای مختلف راهحلهای متفاوتی برای مشکل اوراکل ارائه میکنند که در ادامه به بررسی آنها میپردازیم. اوراکلها معمولاً بر این اساس ارزیابی میشوند که چگونه میتوانند چالشهای زیر را مدیریت کنند:
-
-1. **صحت**: اوراکل نباید باعث شود که قراردادهای هوشمند تغییرات حالت را بر اساس دادههای خارج از زنجیره نامعتبر ایجاد کنند. اوراکل باید _اصالت_ و _یکپارچگی_ دادهها را تضمین کند. اصالت به این معنی است که دادهها از منبع صحیح دریافت شدهاند، در حالی که یکپارچگی به این معنی است که دادهها قبل از ارسال روی زنجیره دست نخورده باقی ماندهاند (یعنی تغییر نکردهاند).
-
-2. **در دسترس بودن**: اوراکل نباید قراردادهای هوشمند را از اجرای اقدامات و ایجاد تغییرات حالت به تاخیر بیاندازد یا از آن جلوگیری کند. این بدان معناست که دادههای یک اوراکل باید بدون وقفه _در صورت درخواست در دسترس باشد_.
-
-3. **سازگاری انگیزه**: اوراکل باید ارائه دهندگان دادههای خارج از زنجیره را تشویق کند تا اطلاعات صحیح را به قراردادهای هوشمند ارسال کنند. سازگاری انگیزه شامل _قابلیت انتساب_ و _پاسخگویی_ است. قابلیت انتساب امکان پیوند بخشی از اطلاعات خارجی را به ارائهدهنده آن فراهم میکند، در حالی که مسئولیتپذیری ارائهدهندگان دادهها را به اطلاعاتی که میدهند پیوند میدهد، بنابراین میتوانند بر اساس کیفیت اطلاعات ارائهشده پاداش یا جریمه شوند.
-
-## سرویس اوراکل بلاک چین چگونه کار میکند؟ {#how-does-a-blockchain-oracle-service-work}
-
-### کاربران {#users}
-
-کاربران موجودیتهایی (یعنی قراردادهای هوشمند) هستند که برای انجام اقدامات خاص به اطلاعات خارج از بلاک چین نیاز دارند. گردش کار اصلی یک سرویس اوراکل با ارسال درخواست داده توسط کاربر به قرارداد اوراکل شروع میشود. درخواستهای داده معمولاً به برخی یا همه سؤالات زیر پاسخ میدهند:
-
-1. گرههای خارج از زنجیره میتوانند برای اطلاعات درخواستی از چه منابعی استفاده کنند؟
-
-2. گزارشگران چگونه اطلاعات را از منابع داده پردازش میکنند و نقاط داده مفید را استخراج میکنند؟
-
-3. چه تعداد گره یا نود اوراکل میتوانند در بازیابی دادهها شرکت کنند؟
-
-4. چگونه باید مغایرتهای گزارشهای اوراکل را مدیریت کرد؟
-
-5. چه روشی باید در فیلتر کردن مطالب ارسالی و تجمیع گزارشها در یک مقدار واحد اجرا شود؟
-
-### قرارداد اوراکل {#oracle-contract}
-
-قرارداد اوراکل جزء زنجیرهای برای سرویس اوراکل است. به درخواستهای داده از قراردادهای دیگر گوش میدهد، پرس و جوهای داده را به گرههای اوراکل رله کرده و دادههای برگشتی را به قراردادهای کلاینت پخش میکند. این قرارداد همچنین ممکن است برخی از محاسبات را روی نقاط داده برگشتی انجام دهد تا یک مقدار مجموع برای ارسال به قرارداد درخواست کننده ایجاد کند.
-
-قرارداد اوراکل برخی از توابع را نشان میدهد که قراردادهای کلاینت هنگام درخواست داده آنها را فراخوانی میکنند. پس از دریافت یک درخواست جدید، قرارداد هوشمند یک [رویداد گزارش یا همان ایونت لاگ](/developers/docs/smart-contracts/anatomy/#events-and-logs) را با جزئیات درخواست داده ارسال میکند. این مورد به گرههای خارج از زنجیره مشترک در گزارش (معمولاً از چیزی مانند دستور JSON-RPC `eth_subscribe` استفاده میکند)، که به بازیابی دادههای تعریفشده در رویداد لاگ میپردازند.
-
-در زیر یک [نمونه قرارداد اوراکل](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) توسط پدرو کاستا آمده است. این یک سرویس اوراکل ساده است که میتواند در صورت درخواست سایر قراردادهای هوشمند، APIهای خارج از زنجیره را جستجو کند و اطلاعات درخواستی را در زنجیره بلوکی ذخیره کند:
-
-```solidity
-pragma solidity >=0.4.21 <0.6.0;
-
-contract Oracle {
- Request[] requests; //list of requests made to the contract
- uint currentId = 0; //increasing request id
- uint minQuorum = 2; //minimum number of responses to receive before declaring final result
- uint totalOracleCount = 3; // Hardcoded oracle count
-
- // defines a general api request
- struct Request {
- uint id; //request id
- string urlToQuery; //API url
- string attributeToFetch; //json attribute (key) to retrieve in the response
- string agreedValue; //value from key
- mapping(uint => string) answers; //answers provided by the oracles
- mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted)
- }
-
- //event that triggers oracle outside of the blockchain
- event NewRequest (
- uint id,
- string urlToQuery,
- string attributeToFetch
- );
-
- //triggered when there's a consensus on the final result
- event UpdatedRequest (
- uint id,
- string urlToQuery,
- string attributeToFetch,
- string agreedValue
- );
-
- function createRequest (
- string memory _urlToQuery,
- string memory _attributeToFetch
- )
- public
- {
- uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
- Request storage r = requests[length-1];
-
- // Hardcoded oracles address
- r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
- r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
- r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
-
- // launch an event to be detected by oracle outside of blockchain
- emit NewRequest (
- currentId,
- _urlToQuery,
- _attributeToFetch
- );
-
- // increase request id
- currentId++;
- }
-
- //called by the oracle to record its answer
- function updateRequest (
- uint _id,
- string memory _valueRetrieved
- ) public {
-
- Request storage currRequest = requests[_id];
-
- //check if oracle is in the list of trusted oracles
- //and if the oracle hasn't voted yet
- if(currRequest.quorum[address(msg.sender)] == 1){
-
- //marking that this address has voted
- currRequest.quorum[msg.sender] = 2;
-
- //iterate through "array" of answers until a position if free and save the retrieved value
- uint tmpI = 0;
- bool found = false;
- while(!found) {
- //find first empty slot
- if(bytes(currRequest.answers[tmpI]).length == 0){
- found = true;
- currRequest.answers[tmpI] = _valueRetrieved;
- }
- tmpI++;
- }
-
- uint currentQuorum = 0;
-
- //iterate through oracle list and check if enough oracles(minimum quorum)
- //have voted the same answer as the current one
- for(uint i = 0; i < totalOracleCount; i++){
- bytes memory a = bytes(currRequest.answers[i]);
- bytes memory b = bytes(_valueRetrieved);
-
- if(keccak256(a) == keccak256(b)){
- currentQuorum++;
- if(currentQuorum >= minQuorum){
- currRequest.agreedValue = _valueRetrieved;
- emit UpdatedRequest (
- currRequest.id,
- currRequest.urlToQuery,
- currRequest.attributeToFetch,
- currRequest.agreedValue
- );
- }
- }
- }
- }
- }
-}
-```
-
-### گره یا نودهای اوراکل {#oracle-nodes}
-
-گره یا نود اوراکل جزء خارج از زنجیره سرویس اوراکل است. این اطلاعات را از منابع خارجی، مانند APIهای میزبانی شده در سرورهای شخص ثالث استخراج میکند و آن را برای مصرف قراردادهای هوشمند در زنجیره قرار میدهد. گره یا نودهای اوراکل به رویدادهای قرارداد اوراکل روی زنجیره گوش میدهند و به تکمیل کار توضیح داده شده در گزارش ادامه میدهند.
-
-یک کار رایج برای نودهای اوراکل ارسال یک درخواست [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) به یک سرویس API، تجزیه پاسخ برای استخراج دادههای مرتبط است. فرمت کردن به یک خروجی قابل خواندن از طریق بلاک چین و ارسال آن در زنجیره (آنچین) با گنجاندن آن در تراکنش به قرارداد اوراکل است. همچنین ممکن است به گره یا نود اوراکل نیاز باشد تا اعتبار و یکپارچگی اطلاعات ارسالی را با استفاده از «اثبات اصالت» تأیید کند، که بعداً بررسی خواهیم کرد.
-
-اوراکلهای محاسباتی همچنین به گره یا نودهای خارج از زنجیره برای انجام وظایف محاسباتی متکی هستند که با توجه به هزینههای گس و محدودیت اندازه بلوک، اجرای آنها در زنجیره غیرعملی است. به عنوان مثال، گره یا نود اوراکل ممکن است وظیفه تولید یک رقم تصادفی قابل تأیید را داشته باشد (به عنوان مثال، برای بازیهای مبتنی بر بلاکچین).
-
-## الگوهای طراحی اوراکل {#oracle-design-patterns}
-
-اوراکلها انواع مختلفی دارند، از جمله _خواندن فوری_، _publish-subscribe_، و _Request-Response_، که دو مورد اخیر محبوبترین در میان قراردادهای هوشمند اتریوم هستند. در اینجا به طور خلاصه مدلهای انتشار-اشتراک و درخواست-پاسخ را توضیح میدهیم.
-
-### اوراکلهای انتشار و اشتراک {#publish-subscribe-oracles}
-
-این نوع اوراکل یک "فید داده" را در معرض دید قرار میدهد که سایر قراردادها میتوانند به طور منظم برای اطلاعات بخوانند. انتظار میرود که دادهها در این مورد به طور مکرر تغییر کنند، بنابراین قراردادهای مشتری باید برای بهروزرسانی دادههای ذخیرهسازی اوراکل گوش (listen) (نوعی از اصطلاحات در خصوص برنامه نویسی) دهند. به عنوان مثال اوراکلی است که آخرین اطلاعات قیمت ETH-USD را در اختیار کاربران قرار میدهد.
-
-### اوراکلهای درخواست-پاسخ {#request-response-oracles}
-
-تنظیم درخواست-پاسخ به قرارداد مشتری یا کلاینت اجازه میدهد تا دادههای دلخواه را غیر از آنچه توسط یک اوراکل انتشار-اشتراک ارائه میشود، درخواست کند. اوراکلهای درخواست-پاسخ زمانی ایدهآل هستند که مجموعه داده آنقدر بزرگ است که نمیتوان آنها را در فضای ذخیرهسازی قرارداد هوشمند ذخیره کرد و/یا کاربران تنها به بخش کوچکی از دادهها در هر مقطع زمانی نیاز خواهند داشت.
-
-اگرچه پیچیدهتر از مدلهای انتشار-اشتراک است، اما اوراکلهای درخواست پاسخ اساساً همان چیزی است که در بخش قبل توضیح دادیم. اوراکل دارای یک جزء روی زنجیره خواهد بود که درخواست داده را دریافت کرده و آن را برای پردازش به یک گره یا نود خارج از زنجیره ارسال میکند.
-
-کاربرانی که درخواستهای داده را آغاز میکنند باید هزینه بازیابی اطلاعات از منبع خارج از زنجیره را پوشش دهند. همچنین قرارداد کلاینت باید وجوهی را برای پوشش هزینههای گس متحمل شده توسط قرارداد اوراکل در بازگرداندن پاسخ از طریق تابع کالبک به تماس مشخص شده در درخواست فراهم کند.
-
-## اوراکلهای متمرکز در مقابل غیرمتمرکز {#types-of-oracles}
-
-### اوراکلهای متمرکز {#centralized-oracles}
-
-یک اوراکل متمرکز توسط یک نهاد واحد کنترل میشود که مسئول جمعآوری اطلاعات خارج از زنجیره و به روز رسانی دادههای قرارداد اوراکل در صورت درخواست است. اوراکلهای متمرکز کارآمد هستند زیرا بر یک منبع حقیقی تکیه دارند. آنها ممکن است در مواردی که مجموعه دادههای اختصاصی مستقیماً توسط مالک با امضای پذیرفته شده منتشر میشود بهتر عمل کنند. با این حال، آنها جنبههای منفی نیز دارند:
-
-#### صحت کم را تضمین میکند {#low-correctness-guarantees}
-
-با اوراکلهای متمرکز، هیچ راهی برای تأیید صحت یا عدم صحت اطلاعات ارائه شده وجود ندارد. حتی ارائه دهندگان "معتبر" میتوانند سرکش یا هک شوند. اگر اوراکل فاسد شود، قراردادهای هوشمند بر اساس دادههای نامناسب اجرا میشوند.
-
-#### در دسترس بودن ضعیف {#poor-availability}
-
-اوراکلهای متمرکز تضمین نمیکنند که همیشه دادههای خارج از زنجیره را در اختیار سایر قراردادهای هوشمند قرار دهند. اگر ارائهدهنده تصمیم بگیرد سرویس را خاموش کند یا هکری مؤلفه خارج از زنجیره اوراکل را ربود، قرارداد هوشمند شما در معرض خطر حمله انکار سرویس (DoS) قرار دارد.
-
-#### سازگاری انگیزشی ضعیف {#poor-incentive-compatibility}
-
-اوراکلهای متمرکز اغلب با انگیزههای ضعیفی طراحی شده یا برای ارائهدهنده داده برای ارسال اطلاعات دقیق/بدون تغییر وجود ندارند. پرداخت به اوراکل برای صحت، صداقت را تضمین نمیکند. این مشکل با افزایش مقدار ارزش کنترل شده توسط قراردادهای هوشمند بزرگتر میشود.
-
-### اوراکلهای غیرمتمرکز {#decentralized-oracles}
-
-اوراکلهای غیرمتمرکز برای غلبه بر محدودیتهای اوراکلهای متمرکز با حذف نقاط شکست منفرد طراحی شدهاند. یک سرویس غیرمتمرکز اوراکل شامل چندین شرکتکننده در یک شبکه همتا به همتا است که قبل از ارسال آن به یک قرارداد هوشمند، روی دادههای خارج از زنجیره یا آفچین اتفاق نظر دارند.
-
-یک اوراکل غیرمتمرکز (در حالت ایده آل) باید بدون مجوز، بدون اعتماد و عاری از اداره یک حزب مرکزی باشد؛ در واقعیت، تمرکززدایی در میان اوراکل ها در یک طیف است. شبکههای اوراکل نیمه غیرمتمرکز وجود دارد که هر کسی میتواند در آن شرکت کند، اما با یک «مالک» که گرهها را بر اساس عملکرد تاریخی تأیید و حذف میکند باشد. شبکههای اوراکل کاملاً غیرمتمرکز نیز وجود دارند: این شبکهها معمولاً بهعنوان زنجیرههای بلوکی یا همان بلاکچین مستقل اجرا میشوند و مکانیزمهای اجماع مشخصی برای هماهنگ کردن گرهها و مجازات رفتارهای نادرست دارند.
-
-استفاده از اوراکلهای غیرمتمرکز دارای مزایای زیر است:
-
-### صحت بالا را تضمین میکند {#high-correctness-guarantees}
-
-اوراکلهای غیرمتمرکز تلاش میکنند تا با استفاده از رویکردهای مختلف به صحت دادهها دست یابند. این مورد شامل استفاده از شواهدی است که صحت و یکپارچگی اطلاعات بازگردانده شده را تأیید میکند و لازم است چندین نهاد به طور جمعی در مورد اعتبار دادههای خارج از زنجیره به توافق برسند.
-
-#### اثبات اصالت {#authenticity-proofs}
-
-اثبات اصالت مکانیزمهای رمزنگاری هستند که امکان تأیید مستقل اطلاعات بازیابی شده از منابع خارجی را فراهم میکنند. این شواهد میتوانند منبع اطلاعات را تایید و تغییرات احتمالی دادهها را پس از بازیابی شناسایی کنند.
-
-نمونههایی از اثبات اصالت عبارتند از:
-
-**اثبات امنیت لایه انتقال (TLS)**: گرههای اوراکل اغلب دادهها را با استفاده از یک اتصال HTTP ایمن بر اساس پروتکل امنیت لایه انتقال (TLS) از منابع خارجی بازیابی میکنند. برخی از اوراکلهای غیرمتمرکز برای تأیید جلسات TLS (یعنی تأیید تبادل اطلاعات بین یک گره و یک سرور خاص) و تأیید عدم تغییر محتویات جلسه، از اثباتهای اعتبار یا اصالت استفاده میکنند.
-
-**تأییدات محیط اجرای مورد اعتماد (TEE)**: یک [محیط اجرای مورد اعتماد](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) یک محیط محاسباتی سندباکس شده است که از فرآیندهای عملیاتی سیستم میزبان خود جدا شده است. TEEها اطمینان حاصل میکنند که هر کد برنامه یا دادهای که در محیط محاسباتی ذخیره/استفاده میشود، یکپارچگی، محرمانه بودن و تغییرناپذیری را حفظ میکند. همچنین کاربران میتوانند یک گواهی برای اثبات اینکه یک نمونه برنامه در محیط اجرای مورد اعتماد اجرا میشود، ایجاد کنند.
-
-کلاسهای خاصی از اوراکلهای غیرمتمرکز به اپراتورهای گره اوراکل برای ارائه گواهی TEE نیاز دارند. این مورد به کاربر تأیید میکند که اپراتور گره نمونهای از سرویس گیرنده اوراکل را در یک محیط اجرای مطمئن اجرا میکند. TEEها از تغییر یا خواندن کد و دادههای برنامه توسط فرآیندهای خارجی جلوگیری میکنند، از این رو، این گواهیها ثابت میکنند که گره اوراکل اطلاعات را دست نخورده و محرمانه نگه داشته است.
-
-#### اعتبارسنجی مبتنی بر اجماع اطلاعات {#consensus-based-validation-of-information}
-
-اوراکلهای متمرکز هنگام ارائه دادهها به قراردادهای هوشمند به یک منبع حقیقت تکیه میکنند که امکان انتشار اطلاعات نادرست وجود دارد. اوراکلهای غیرمتمرکز این مشکل را با تکیه بر چندین گره اوراکل برای جستجوی اطلاعات خارج از زنجیره حل میکنند. با مقایسه دادههای چند منبع، اوراکلهای غیرمتمرکز خطر انتقال اطلاعات نامعتبر به قراردادهای زنجیرهای را کاهش میدهند.
-
-با این حال، اوراکلهای غیرمتمرکز باید با اختلافات در اطلاعات بازیابی شده از چندین منبع خارج از زنجیره مقابله کنند. برای به حداقل رساندن تفاوتها در اطلاعات و اطمینان از اینکه دادههای ارسال شده به قرارداد اوراکل منعکسکننده نظر جمعی گرههای اوراکل است، اوراکلهای غیرمتمرکز از مکانیزمهای زیر استفاده میکنند:
-
-##### رای دادن/استیک کردن در مورد صحت دادهها
-
-برخی از شبکههای اوراکل غیرمتمرکز از شرکتکنندگان میخواهند که در صحت پاسخهای پرسشهای داده رای دهند یا در مورد صحت پاسخها استیک کنند (به عنوان مثال، "چه کسی در انتخابات 2020 ایالات متحده پیروز شد؟") با استفاده از توکن بومی شبکه. سپس یک پروتکل تجمیع آرا و سهام را جمع میکند و پاسخی را که اکثریت پشتیبانی میکند به عنوان پاسخ معتبر میگیرد.
-
-گرههایی که پاسخ آنها از پاسخ اکثریت منحرف میشود، با توزیع توکنهایشان به دیگرانی که مقادیر صحیحتری ارائه میدهند، جریمه میشوند. اجبار گره یا نودها برای ایجاد پیوند قبل از ارائه دادهها، انگیزه پاسخهای صادقانه را فراهم میکند، زیرا فرض میشود که آنها افراد اقتصادی منطقی هستند که قصد دارند بازده را به حداکثر برسانند.
-
-استیک/رایگیری همچنین از اوراکلهای غیرمتمرکز در برابر [حملات سبیل](/glossary/#sybil-attack) محافظت میکند که در آن عوامل مخرب چندین هویت را برای بازی با سیستم اجماع ایجاد میکنند. با این حال، استیک نمیتواند از "بارگذاری رایگان" (گرههای اوراکل که اطلاعات را از دیگران کپی میکنند) و "اعتبارسنجی تنبل" (گرههای اوراکل اکثریت را بدون تأیید اطلاعات خود دنبال میکنند) جلوگیری کند.
-
-##### مکانیزمهای نقطه هدف
-
-[نقطه هدف](https://en.wikipedia.org/wiki/Focal_point_(game_theory)) یک مفهوم تئوری است که فرض میکند چندین موجودیت همیشه به طور پیشفرض به یک راهحل مشترک برای یک مشکل در عدم وجود هرگونه ارتباط میرسند. مکانیسمهای شلینگ پوینت (Schelling-point) اغلب در شبکههای اوراکل غیرمتمرکز استفاده میشوند تا گره یا نودها را قادر میسازد در مورد پاسخ به درخواستهای داده به توافق برسند.
-
-ایده اولیه برای این [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) بود، فید داده پیشنهادی که در آن شرکتکنندگان پاسخهایی را به سؤالات «اسکالر» (سوالاتی که پاسخهای آنها با بزرگی توصیف میشود، بهعنوان مثال، «قیمت اتریوم چقدر است؟») همراه با سپرده ارسال میکنند. کاربرانی که مقادیری را بین 25 و 75 [درصد](https://en.wikipedia.org/wiki/Percentile) ارائه میکنند، پاداش میگیرند، در حالی که آنهایی که مقادیرشان تا حد زیادی از مقدار متوسط انحراف دارد، جریمه میشوند.
-
-در حالی که SchellingCoin امروزه وجود ندارد، تعدادی اوراکل غیرمتمرکز—به ویژه [پروتکل سازندگان اوراکلها](https://docs.makerdao.com/smart-contract-modules/oracle-module)—از مکانیزم نقطه هدف برای بهبود دقت دادههای اوراکل استفاده میکردند. هر Maker Oracle متشکل از یک شبکه P2P خارج از زنجیره از گرهها ("relayers" و "feed") است که قیمتهای بازار را برای داراییهای وثیقه ارسال کرده و یک قرارداد "Medianizer" درون زنجیرهای که میانگین تمام ارزشهای ارائهشده را محاسبه میکند. پس از پایان دوره تاخیر مشخص شده، این مقدار متوسط به قیمت مرجع جدید برای دارایی مرتبط تبدیل میشود.
-
-نمونههای دیگر اوراکلهایی که از مکانیزمهای نقطه هدف استفاده میکنند عبارتند از [گزارشدهی خارج از زنجیره چین لینک](https://docs.chain.link/docs/off-chain-reporting/) و [Witnet](https://witnet.io/). در هر دو سیستم، پاسخهای گره یا نودهای اوراکل در شبکه همتا به همتا در یک مقدار مجموع، مانند میانگین یا میانه، تجمیع میشوند. گره یا نودها با توجه به میزانی که پاسخ هایشان با مقدار کل همسو یا انحراف دارد، پاداش یا مجازات میشوند.
-
-مکانیسمهای شلینگ پوینت (Schelling point) جذاب هستند زیرا ردپای روی زنجیره را به حداقل میرسانند (فقط یک تراکنش باید ارسال شود) در حالی که تمرکززدایی را تضمین میکند. مورد دوم امکانپذیر است زیرا گرهها باید قبل از وارد شدن به الگوریتمی که مقدار میانگین/میانگین را تولید میکند، در لیست پاسخهای ارسالی امضا کنند.
-
-### در دسترس بودن {#availability}
-
-خدمات غیرمتمرکز اوراکل در دسترس بودن بالای دادههای خارج از زنجیره را برای قراردادهای هوشمند تضمین میکند. این امر با غیرمتمرکز کردن منبع اطلاعات خارج از زنجیره و گره یا نودهای مسئول انتقال اطلاعات در زنجیره به دست میآید.
-
-این امر تحمل خطا را تضمین میکند زیرا قرارداد اوراکل میتواند به چندین گره یا نود (که همچنین به چندین منبع داده متکی هستند) برای اجرای پرسوجو از قراردادهای دیگر متکی باشد. تمرکززدایی در سطح منبع _و_ گره-اپراتور بسیار مهم است—شبکه ای از گرههای اوراکل که اطلاعات بازیابی شده از یک منبع را ارائه میدهند، با مشکل مشابه یک اوراکل متمرکز مواجه خواهند شد.
-
-همچنین برای اوراکلهای مبتنی بر سهام میتواند اپراتورهای گره یا نودی را که نمیتوانند به سرعت به درخواستهای داده پاسخ دهند، کاهش دهند. این به طور قابل توجهی گره یا نودهای اوراکل را برای سرمایهگذاری در زیرساختهای مقاوم در برابر خطا و ارائه به موقع دادهها تشویق میکند.
-
-### سازگاری انگیزشی خوب {#good-incentive-compatibility}
-
-اوراکلهای غیرمتمرکز طرحهای تشویقی مختلفی را برای جلوگیری از رفتار [بیزانس](https://en.wikipedia.org/wiki/Byzantine_fault) در میان گرههای اوراکل اجرا میکنند. به طور خاص، آنها به _قابلیت انتساب_ و _پاسخگویی_ دست مییابند:
-
-1. گره یا نودهای اوراکل غیرمتمرکز اغلب برای امضای دادههایی که در پاسخ به درخواستهای داده ارائه میکنند مورد نیاز است. این اطلاعات به ارزیابی عملکرد تاریخی گره یا نودهای اوراکل کمک میکند، به طوری که کاربران میتوانند هنگام درخواست داده، گره یا نودهای اوراکل غیرقابل اعتماد را فیلتر کنند. یک مثال [سیستم شهرت الگوریتمی](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) Witnet است.
-
-2. اوراکلهای غیرمتمرکز - همانطور که قبلاً توضیح داده شد - ممکن است به گره یا نودهایی نیاز داشته باشند که در مورد اطمینان خود نسبت به صحت دادههایی که ارسال میکنند، سهمی داشته باشند. در صورت بررسی ادعا، این سهام میتواند همراه با پاداش برای خدمات صادقانه بازگردانده شود. اما در صورت نادرست بودن اطلاعات نیز میتوان آن را کاهش داد، که مقداری از پاسخگویی را فراهم میکند.
-
-## کاربردهای اوراکل در قراردادهای هوشمند {#applications-of-oracles-in-smart-contracts}
-
-موارد زیر موارد استفاده رایج برای اوراکلها در اتریوم است:
-
-### بازیابی اطلاعات مالی {#retrieving-financial-data}
-
-برنامههای [مالی غیرمتمرکز](/defi/) (DeFi) امکان وامدهی، استقراض و معامله داراییها را به صورت همتا به همتا فراهم میکنند. این مورد اغلب مستلزم دریافت اطلاعات مالی مختلف، از جمله دادههای نرخ مبادله (برای محاسبه ارزش فیات ارزهای دیجیتال یا مقایسه قیمتهای توکن) و دادههای بازار سرمایه (برای محاسبه ارزش داراییهای توکنشده، مانند طلا یا دلار آمریکا) است.
-
-به عنوان مثال، یک پروتکل وام دهی دیفای، نیاز به استعلام قیمتهای فعلی بازار برای داراییها (به عنوان مثال، اتر) دارد که به عنوان وثیقه سپرده شده است. این به قرارداد اجازه میدهد تا ارزش داراییهای وثیقه را تعیین کند و تعیین کند که چقدر میتواند از سیستم وام بگیرد.
-
-«اوراکلهای قیمت» محبوب (که معمولاً به آنها گفته میشود) در دیفای شامل فیدهای قیمت زنجیرهای، پروتکل ترکیبی [فید قیمت باز](https://compound.finance/docs/prices) یونی سواپ است. href="https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles">قیمتهای میانگین وزندار زمانی (TWAP) و [میکر اوراکل](https://docs.makerdao.com/smart-contract-modules/oracle-module).
-
-سازندگان باید قبل از ادغام آنها در پروژه خود، اخطارهایی را که با این اوراکلهای قیمت همراه است، درک کنند. این [مقاله](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) تجزیه و تحلیل دقیقی از مواردی که باید در برنامه ریزی برای استفاده از هر یک از اوراکلهای قیمت ذکر شده در نظر بگیرید ارائه میدهد.
-
-در زیر مثالی از نحوه بازیابی آخرین قیمت اتر در قرارداد هوشمند خود با استفاده از فید قیمت زنجیرهای آورده شده است:
-
-```solidity
-pragma solidity ^0.6.7;
-
-import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
-
-contract PriceConsumerV3 {
-
- AggregatorV3Interface internal priceFeed;
-
- /**
- * Network: Kovan
- * Aggregator: ETH/USD
- * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
- */
- constructor() public {
- priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
- }
-
- /**
- * Returns the latest price
- */
- function getLatestPrice() public view returns (int) {
- (
- uint80 roundID,
- int price,
- uint startedAt,
- uint timeStamp,
- uint80 answeredInRound
- ) = priceFeed.latestRoundData();
- return price;
- }
-}
-```
-
-### ایجاد تصادفی قابل تأیید {#generating-verifiable-randomness}
-
-برخی از برنامههای بلاکچین، مانند بازیهای مبتنی بر بلاکچین یا طرحهای بختآزمایی، به سطح بالایی از غیرقابل پیشبینی و تصادفی بودن نیاز دارند تا به طور مؤثر کار کنند. با این حال، اجرای قطعی بلاکچینها تصادفی بودن را از بین میبرد.
-
-رویکرد اولیه استفاده از توابع رمزنگاری شبه تصادفی، مانند `بلاک هش` بود، اما اینها ممکن [توسط ماینرها](https://ethereum.stackexchange.com/questions/3140/risk-of-using- blockhash-other-miners-preventing-attack#:~:text=است%20که%20the%20miners%20can,to%20one%20of%20the%20players.) برای حل مشکل الگوریتم اثبات کار دستکاری شوند. همچنین، [تغییر به اثبات سهام](/roadmap/merge/) اتریوم به این معنی است که توسعهدهندگان دیگر نمیتوانند برای تصادفی بودن روی زنجیره به `بلاک هش` اعتماد کنند. در عوض، [مکانیزم RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) بیکون چین یک منبع جایگزین برای تصادفی بودن فراهم میکند.
-
-امکان تولید ارزش تصادفی خارج از زنجیره و ارسال آن در زنجیره وجود دارد، اما انجام این کار الزامات اعتماد بالایی را به کاربران تحمیل میکند. آنها باید باور داشته باشند که ارزش واقعی از طریق مکانیسمهای غیرقابل پیشبینی ایجاد شده است و در حمل و نقل تغییر نکرده است.
-
-اوراکلهایی که برای محاسبات خارج از زنجیره طراحی شدهاند، این مشکل را با تولید ایمن نتایج تصادفی خارج از زنجیره که روی زنجیره پخش میکنند همراه با اثباتهای رمزنگاری که غیرقابل پیشبینی بودن فرآیند را تأیید میکنند، حل میکنند. یک مثال [چین لینک VRF](https://docs.chain.link/docs/chainlink-vrf/) (عملکرد تصادفی قابل تأیید) است که یک تولید کننده اعداد تصادفی منصفانه و بدون دستکاری است. (RNG) برای ساخت قراردادهای هوشمند قابل اعتماد برای برنامههایی که بر نتایج غیرقابل پیشبینی تکیه دارند مفید است. مثال دیگر [API3 QRNG](https://docs.api3.org/explore/qrng/) است که تولید اعداد تصادفی کوانتومی (QRNG) را ارائه میکند، یک روش عمومی وب 3 RNG مبتنی بر پدیدههای کوانتومی با هدف ارائه شده توسط دانشگاه ملی استرالیا (ANU) است.
-
-### به دست آوردن نتایج برای رویدادها {#getting-outcomes-for-events}
-
-با اوراکلها، ایجاد قراردادهای هوشمند که به رویدادهای دنیای واقعی پاسخ میدهند، آسان است. خدمات اوراکل با اجازه دادن به قراردادها برای اتصال به APIهای خارجی از طریق اجزای خارج از زنجیره و مصرف اطلاعات از آن منابع داده، این امکان را فراهم میکند. به عنوان مثال، برنامه پیشبینی که قبلاً ذکر شد ممکن است از اوراکل درخواست کند که نتایج انتخابات را از یک منبع معتبر خارج از زنجیره (مثلاً آسوشیتد پرس) بازگرداند.
-
-استفاده از اوراکلها برای بازیابی دادهها بر اساس نتایج دنیای واقعی، سایر موارد استفاده جدید را امکانپذیر میکند. به عنوان مثال، یک محصول بیمه غیرمتمرکز به اطلاعات دقیق در مورد آب و هوا، بلایا و غیره نیاز دارد تا به طور مؤثر کار کند.
-
-### خودکارسازی قراردادهای هوشمند {#automating-smart-contracts}
-
-قراردادهای هوشمند به طور خودکار اجرا نمیشوند. بلکه یک حساب متعلق به خارجی (EOA)، یا یک حساب قرارداد دیگر، باید عملکردهای مناسب را برای اجرای کد قرارداد راه اندازی کند. در بیشتر موارد، بخش عمدهای از وظایف قرارداد عمومی است و میتواند توسط EOA و سایر قراردادها مورد استناد قرار گیرد.
-
-اما همچنین _عملکردهای خصوصی_ در قرارداد وجود دارد که برای دیگران غیرقابل دسترسی است؛ اما برای عملکرد کلی یک برنامه غیرمتمرکز بسیار مهم است. مثالها عبارتند از یک تابع `mintERC721Token()` که به صورت دورهای NFTهای جدید را برای کاربران مینت میکند، تابعی برای اعطای پرداختها در بازار پیشبینی، یا تابعی برای باز کردن قفل توکنهای استیک شده در یک دکس است.
-
-توسعه دهندگان باید چنین عملکردهایی را در فواصل زمانی فعال کنند تا برنامه به خوبی اجرا شود. با این حال، این مورد ممکن است منجر به از دست دادن ساعات بیشتری در انجام کارهای روزمره برای توسعه دهندگان شود، به همین دلیل است که اجرای خودکار قراردادهای هوشمند جذاب است.
-
-برخی از شبکههای اوراکل غیرمتمرکز خدمات اتوماسیون را ارائه میکنند که به گرههای اوراکل خارج از زنجیره اجازه میدهد تا عملکردهای قرارداد هوشمند را بر اساس پارامترهای تعریف شده توسط کاربر فعال کنند. به طور معمول، این امر مستلزم «ثبت» قرارداد هدف با سرویس اوراکل، تأمین بودجه برای پرداخت به اپراتور اوراکل و مشخص کردن شرایط یا زمانهای شروع قرارداد است.
-
-[شبکه کیپر](https://chain.link/keepers) چین لینک گزینههایی را برای قراردادهای هوشمند برای برونسپاری وظایف تعمیر و نگهداری منظم به روشی به حداقل رسیده و غیرمتمرکز ارائه میدهد. [داکیومنت کیپر ](https://docs.chain.link/docs/chainlink-keepers/introduction/) را برای اطلاعات در مورد سازگار کردن قرارداد خود با کیپر و استفاده از سرویس Upkeep بخوانید.
-
-## نحوه استفاده از اوراکلهای بلاک چین {#use-blockchain-oracles}
-
-چندین برنامه اوراکل وجود دارد که میتوانید آنها را در برنامه اتریوم خود ادغام کنید:
-
-**[چین لینک](https://chain.link/)** - _شبکههای غیرمتمرکز اوراکل چین لینک ارائه میکنند ورودیها، خروجیها و محاسبات ضد دستکاری برای پشتیبانی از قراردادهای هوشمند پیشرفته در هر بلاک چین را اعمال میکند._
-
-**[کرونیکل](https://chroniclelabs.org/)** - _کرونیکل بر محدودیتهای فعلی غلبه میکند انتقال دادهها در زنجیره با توسعه اوراکلهای واقعا مقیاس پذیر، مقرون به صرفه، غیرمتمرکز و قابل تأیید را پیادهسازی میکند._
-
-**[Witnet](https://witnet.io/)** - _ویت نت بدون مجوز است، اوراکل غیرمتمرکز و مقاوم در برابر سانسور به قراردادهای هوشمند کمک میکند تا با ضمانتهای ارزی-اقتصادی قوی به رویدادهای دنیای واقعی واکنش نشان دهند._
-
-**[UMA Oracle](https://uma.xyz)** - _اوراکل آپتیمیستیک UMA به قراردادهای هوشمند اجازه میدهد قراردادهایی برای دریافت سریع و دریافت هر نوع داده برای برنامههای مختلف، از جمله بیمه، مشتقات مالی و بازارهای پیش بینی انجام دهند._
-
-**[تلور](https://tellor.io/)** - _تلور شفاف و پروتکل اوراکل بدون مجوز برای قرارداد هوشمند شما است تا به راحتی هر دادهای را هر زمان که به آن نیاز داشتید دریافت کنید._
-
-**[پروتکل باند](https://bandprotocol.com/)** - _پروتکل باند یک پلتفرم اوراکل داده متقابل زنجیرهای که دادهها و APIهای دنیای واقعی را جمعآوری و به قراردادهای هوشمند متصل میکند._
-
-**[Paralink](https://paralink.network/)** - _پارالینک یک برنامه منبع باز ارائه میکند و پلتفرم اوراکل غیرمتمرکز برای قراردادهای هوشمند در حال اجرا بر روی اتریوم و سایر بلاک چینهای محبوب است._
-
-**[شبکه Pyth](https://pyth.network/)** - _شبکه Pyth یک شبکه اوراکل مالی شخص اول که برای انتشار دادههای مستمر دنیای واقعی روی زنجیره در محیطی مقاوم در برابر دستکاری، غیرمتمرکز و خودپایدار طراحی شده است._
-
-**[API3 DAO](https://www.api3.org/)** - _API3 DAO در حال ارائه راه حلهای اوراکل شخص اول است که شفافیت منبع، امنیت و مقیاس پذیری بیشتری را در یک راه حل غیرمتمرکز برای قراردادهای هوشمند ارائه میکند_
-
-**[Supra](https://supra.com/)** - یک جعبه ابزار یکپارچه از راهحلهای زنجیرهای متقابل که همه بلاک چینها را به هم متصل میکند. (L1ها و L2ها) یا خصوصی (تشکیلات)، ارائه فیدهای غیرمتمرکز قیمت اوراکل که میتواند برای موارد استفاده در زنجیره و خارج از زنجیره استفاده شود.
-
-## بیشتر بخوانید {#further-reading}
-
-**مقالات**
-
-- [اوراکل بلاک چین چیست؟](https://chain.link/education/blockchain-oracles) — _چین لینک_
-- [اوراکل بلاک چین چیست؟](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _پاتریک کالینز< /em>
-- [اوراکلهای غیرمتمرکز: مروری جامع](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _ژولین تیونارد_
-- [اجرای اوراکل بلاک چین در اتریوم](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) - *پدرو کاستا*
-- [چرا قراردادهای هوشمند نمیتوانند تماسهای API برقرار کنند؟](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
-- [چرا به اوراکلهای غیرمتمرکز نیاز داریم](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) — _Bankless< /em>
-- [پس میخواهید از اوراکل قیمت استفاده کنید](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
-
-**ویدیوها**
-
-- [Oracles و گسترش ابزار بلاک چین](https://youtu.be/BVUZpWa8vpw) — _بخش مالی ریل ویژن_
-- [تفاوتهای اوراکلهای شخص اول و شخص ثالث](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/) - _Blockchain Oracle Summit_
-
-**آموزشها**
-
-- [نحوه واکشی قیمت فعلی اتریوم در سالیدیتی](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _چین لینک_
-- [مصرف دادههای اوراکل](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _کرونیکل_
-
-**نمونه پروژهها**
-
-- [پروژه شروع کامل چین لینک برای اتریوم در سالیدیتی](https://github.com/hackbg/chainlink-fullstack) — _HackBG_
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md
deleted file mode 100644
index 8e2c02ef379..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/index.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: استانداردهای توسعه اتریوم
-description:
-lang: fa
-incomplete: true
----
-
-## مروری بر استانداردها {#standards-overview}
-
-جامعه اتریوم استانداردهای زیادی را اتخاذ کرده است تا کمک کند پروژه ها (همچون [کلاینت های اتریوم](/developers/docs/nodes-and-clients/) و کیف پول های دیجیتالی) در هنگام پیاده سازی، قابلیت اجرا داشته باشند و همچنین اطمینان حاصل می کند تا قراردادهای هوشمند و dapp ها هچنان ترکیب پذیر باقی بمانند.
-
-استانداردها عموما به صورت [پیشنهادات بهبود اتریوم](/eips/) (EIPها) معرفی می گردند که توسط اعضای جامعه از طریق یک [فرآیند استاندارد](https://eips.ethereum.org/EIPS/eip-1) مورد بحث قرار می گیرند.
-
-- [مقدمه ای بر EIPها](/eips/)
-- [لیست EIPها](https://eips.ethereum.org/)
-- [مخزن گیتهاب EIP](https://github.com/ethereum/EIPs)
-- [صفحه گفتگوی EIP](https://ethereum-magicians.org/c/eips)
-- [مقدمهای بر حاکمیت اتریوم](/governance/)
-- [مروری بر حاکمیت اتریوم](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _March 31, 2019 - Boris Mann_
-- [هماهنگسازی پروتکل توسعه پروتکل و ارتقا شبکه](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 مارس 2020 - هودسون جیمزسون_
-- [فهرست پخش تمامی جلسات توسعه هسته اتریوم](https://www.youtube.com/@EthereumProtocol) _(فهرست پخش در یوتیوب)_
-
-## انواع استانداردها {#types-of-standards}
-
-3 نوع EIP وجود دارد:
-
-- مسیر استانداردها: هر تغییری را توصیف میکند که بر اکثر یا همه نسخه های اتریوم تأثیر میگذارد
-- [مسیر ابرداده ها (Meta)](https://eips.ethereum.org/meta): پروسه های حول محور اتریوم را توصیف می کند یا تغییری را در یک پروسه پیشنهاد میکند
-- [مسیر اطلاعات](https://eips.ethereum.org/informational): یک مشکل طراحی اتریوم را شرح میدهد یا دستورالعملها یا اطلاعات کلی را در اختیار جامعه اتریوم قرار میدهد
-
-علاوه بر این، مسیر استانداردها به 4 دسته تقسیم میشود:
-
-- [هسته](https://eips.ethereum.org/core): بهبودهایی که نیاز به فورک اجماع دارند
-- [شبکهسازی](https://eips.ethereum.org/networking): بهبودهای حول محور devp2p و پروتکل های فرعی اتریوم رقیق و همچنین بهبودهای پیشنهادی برای مشخصات پروتکل شبکه whisper و swarm است.
-- [رابط](https://eips.ethereum.org/interface): بهبودهایی در مورد مشخصات و استانداردهای API/RPC کلاینت و استانداردهای خاص در سطح زبان مانند نام روشها و قراردادهای ABI است.
-- [ERC](https://eips.ethereum.org/erc): استانداردها و کنوانسیونهای سطح برنامه
-
-اطلاعات دقیقتر در مورد انواع و دستههای مختلف را میتوانید در [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) پیدا کنید
-
-### استانداردهای توکن {#token-standards}
-
-- [ERC-20](/developers/docs/standards/tokens/erc-20/) - یک رابط استاندارد برای توکنهای تعویضپذیر (قابل تعویض)، مانند توکنهای رایگیری، توکنهای شرطبندی یا ارزهای مجازی می باشد.
- - [ERC-223](/developers/docs/standards/tokens/erc-223/) - نوعی استاندارد توکن تعویض پذیر است که رفتاری مشابه اتر دارد و از انتقال توکن هایی که در سمت گیرنده مدیریت می شوند، پشتیبانی می کند.
- - [ERC-1363](https://eips.ethereum.org/EIPS/eip-1363) - یک رابط برقراری ارتباط با توکن، برای توکنهای ERC-20 توصیف میکند که از اجرای کد گیرنده پس از اجرای انتقال یا «انتقال از» و یا اجرای کد ارسال کننده پس از تایید، پشتیبانی میکند.
-- [ERC-721](/developers/docs/standards/tokens/erc-721/) - یک رابط استاندارد برای توکنهای تعویض ناپذیر، مانند یک سند برای اثر هنری یا یک آهنگ است.
- - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - یک رویداد استاندارد شده که هنگام ساخت یا انتقال یک یا چندین توکن تعویض ناپذیر، با استفاده از IDهای متوالی، اجرا و اطلاع رسانی میشود.
- - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - افزونهای برای نقش مصرف کننده در رابط EIP-721.
- - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - یک نقش دارای محدودیتهای دسترسی و زمانی را به توکنهای ERC-721 اضافه میکند.
-- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(توصیه نمیشود)** یک استاندارد توکن برای بهبود ERC-20.
-- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - یک استاندارد توکنی است که میتواند دارای داراییهای تعویض پذیر و تعویض ناپذیر باشد.
-- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - یک استاندارد خزانه توکنیزه شده که برای بهینهسازی و یکسانسازی پارامترهای فنی خزانه های سودده طراحی شده است.
-
-درباره [استانداردهای توکن](/developers/docs/standards/tokens/) بیشتر بدانید.
-
-## بیشتر بخوانید {#further-reading}
-
-- [پیشنهادهای بهبود اتریوم (EIP)](/eips/)
-
-_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md
deleted file mode 100644
index 54a9d121fc9..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: استاندارد چند توکنی ERC-1155
-description:
-lang: fa
----
-
-## معرفی {#introduction}
-
-یک رابط استاندارد برای قراردادهایی است که چندین نوع توکن را مدیریت می کنند. یک تک قرارداد هوشمند مستقر ممکن است شامل هر ترکیبی از توکنهای تعویض پذیر، توکنهای تعویض ناپذیر یا سایر پیکربندیها (مانند توکنهای نیمه تعویض پذیر) باشد.
-
-**منظور از استاندارد چند توکنی چیست؟**
-
-این ایده ساده است و به دنبال ایجاد یک رابط برنامه نویسی قرارداد هوشمند میباشد که می تواند هر تعداد توکن تعویض پذیر و تعویض ناپذیر را نشان دهد و کنترل کند. به این ترتیب، توکن ERC-1155 می تواند همان عملکردهای یک توکن [ERC-20](/developers/docs/standards/tokens/erc-20/) و [ERC-721](/developers/docs/standards/tokens/erc-721/) و حتی هر دو را به طور همزمان انجام دهد. این امر باعث بهبود عملکرد و کارآیی هر دو استاندارد ERC-20 و ERC-721 میشود و خطاهای واضح پیادهسازی را اصلاح میکند.
-
-توکن ERC-1155 به طور کامل در [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) توضیح داده شده است.
-
-## پیش نیاز ها {#prerequisites}
-
-برای درک بهتر این صفحه، توصیه می کنیم ابتدا در مورد [استانداردهای توکن](/developers/docs/standards/tokens/)، [ERC-20](/developers/docs/standards/tokens/erc-20/) و [ERC-721](/developers/docs/standards/tokens/erc-721/) مطالعه کنید.
-
-## توابع و ویژگی های ERC-1155: {#body}
-
-- [انتقال دستهای](#batch_transfers): چندین دارایی را در یک فراخوانی منتقل کنید.
-- [تراز دسته ای](#batch_balance): موجودی چندین دارایی را در یک فراخوانی دریافت کنید.
-- [تأیید دستهای](#batch_approval): همه توکن ها را برای یک آدرس تأیید کنید.
-- [قلابها](#receive_hook): قلاب توکنها را دریافت کنید.
-- [پشتیبانی NFT](#nft_support): اگر عرضه تنها ۱ باشد، با آن به عنوان NFT رفتار کنید.
-- [قوانین انتقال ایمن](#safe_transfer_rule): مجموعه قوانین برای انتقال ایمن.
-
-### انتقال دسته ای {#batch-transfers}
-
-عملیات انتقال دسته ای بسیار شبیه به انتقال معمولی ERC-20 است. بیایید نگاهی به تابع `transferFrom` استاندارد ERC-20 بیاندازیم:
-
-```solidity
-// ERC-20
-function transferFrom(address from, address to, uint256 value) external returns (bool);
-
-// ERC-1155
-function safeBatchTransferFrom(
- address _from,
- address _to,
- uint256[] calldata _ids,
- uint256[] calldata _values,
- bytes calldata _data
-) external;
-```
-
-تنها تفاوت ERC-1155 در این است که مقادیر را به عنوان یک آرایه ارسال می کنیم و همچنین یک آرایه از id را نیز ارسال می کنیم. به عنوان مثال با توجه به `ids=[3, 6, 13]` و `values=[100, 200, 5]`، انتقالهای حاصل به صورت زیر می باشد
-
-1. 100 توکن با شناسه 3 را از `from_` به `to_` منتقل کنید.
-2. 200 توکن با شناسه 6 را از `from_` به `to_` منتقل کنید.
-3. 5 توکن با شناسه 13 را از `from_` به `to_` منتقل کنید.
-
-در ERC-1155 تنها تابع `transferFrom` را داریم و تابع `transfer` نداریم. برای استفاده از آن مانند یک `انتقال` معمولی، کافی است آدرس from را به آدرسی که تابع را فراخوانی میکند، تنظیم کنید.
-
-### موجودی دسته ای {#batch-balance}
-
-فراخوانی مربوط به ERC-20 `balanceOf` نیز به همین ترتیب تابع شریک خود را با پشتیبانی دسته ای دارد. به عنوان یک یادآوری، این نسخه ERC-20 است:
-
-```solidity
-// ERC-20
-function balanceOf(address owner) external view returns (uint256);
-
-// ERC-1155
-function balanceOfBatch(
- address[] calldata _owners,
- uint256[] calldata _ids
-) external view returns (uint256[] memory);
-```
-
-حتی سادهتر از فراخوانی موجودی، میتوانیم چندین موجودی را در یک فراخوانی بدست آوریم. آرایه از دارندگان حساب و به دنبال آن آرایه ای از شناسه های توکن را ارسال می کنیم.
-
-به عنوان مثال، با توجه به `_ids=[3, 6, 13]` و `_owners=[0xbeef..., 0x1337..., 0x1111...]`، مقدار بازگشتی برابر خواهد شد با
-
-```solidity
-[
- balanceOf(0xbeef...),
- balanceOf(0x1337...),
- balanceOf(0x1111...)
-]
-```
-
-### تایید دسته ای {#batch-approval}
-
-```solidity
-// ERC-1155
-function setApprovalForAll(
- address _operator,
- bool _approved
-) external;
-
-function isApprovedForAll(
- address _owner,
- address _operator
-) external view returns (bool);
-```
-
-تاییدیه ها کمی با ERC-20 تفاوت دارند. به جای تأیید مبالغ خاص، یک اپراتور را از طریق `setApprovalForAll` روی تایید یا تایید نشده تنظیم می کنیم.
-
-خواندن وضعیت فعلی را می توان از طریق `isApprovedForAll` انجام داد. همانطور که مشاهده میکنید، این یک پاسخ صفر و یک است. شما نمی توانید تعیین کنید که چه تعداد توکن باید تایید شود یا حتی کدام کلاس توکن باید تایید شود.
-
-این مقوله عمدا با در نظر گرفتن سادگی طراحی شده است. شما فقط می توانید همه چیز را برای یک آدرس تایید کنید.
-
-### قلاب دریافت {#receive-hook}
-
-```solidity
-function onERC1155BatchReceived(
- address _operator,
- address _from,
- uint256[] calldata _ids,
- uint256[] calldata _values,
- bytes calldata _data
-) external returns(bytes4);
-```
-
-با توجه به پشتیبانی [EIP-165](https://eips.ethereum.org/EIPS/eip-165)، پشتیبانی ERC-1155 تنها از قلابهای دریافت برای قرارداد هوشمند پشتیبانی میکند. تابع قلاب می بایست مقدار bytes4 از پیش تعریف شده جادویی را برگرداند که به صورت زیر داده می شود:
-
-```solidity
-bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
-```
-
-وقتی قرارداد دریافتکننده این مقدار را برمیگرداند، فرض بر این است که قرارداد انتقال را میپذیرد و میداند چگونه با توکنهای ERC-1155 کار کند. عالی است، دیگر هیچ توکنی در یک قرارداد گیر نمیکند!
-
-### پشتیبانی از NFT {#nft-support}
-
-وقتی عرضه فقط یک باشد، توکن اساساً یک توکن تعویض ناپذیر (NFT) است. و همانطور که برای ERC-721 استاندارد است، میتوانید یک URL اَبَرداده ای را تعریف کنید. URL را می توان توسط کلاینت ها خواند و تغییر داد، [اینجا](https://eips.ethereum.org/EIPS/eip-1155#metadata) را ببینید.
-
-### قانون انتقال ایمن {#safe-transfer-rule}
-
-ما قبلاً در توضیحات قبلی به چند قانون انتقال ایمن اشاره کردیم. اما بیایید مهم ترین قوانین را بررسی کنیم:
-
-1. تماسگیرنده می بایست برای خرج کردن توکن ها برای آدرس `from_` تأیید شود یا تماسگیرنده باید برابر با `from_` باشد.
-2. فراخوانی انتقال باید برگردانده شود اگر
- 1. آدرس `to_` باشد.
- 2. طول `_ids` با طول `_values` یکسان نباشد.
- 3. هر یک از موجودی(های) دارنده(های) توکن(ها) در `_ids` کمتر از مقدار(های) مربوطه در `_values` ارسال شده به گیرنده باشد.
- 4. هر خطای دیگری رخ دهد.
-
-_توجه_: همه توابع دستهای از جمله قلاب در نسخههای بدون دسته نیز وجود دارند. با توجه به اینکه انتقال تنها یک دارایی احتمالاً همچنان رایج ترین راه مورد استفاده خواهد بود، این کار به منظور بهره وری گاز انجام می شود. ما همگی آنها، از جمله قوانین انتقال ایمن را به خاطر سادگی در توضیحات کنار گذاشتیم. نام ها یکسان هستند، فقط "دسته ای" را حذف کنید.
-
-## بیشتر بخوانید {#further-reading}
-
-- [EIP-1155: استاندارد چند توکنی](https://eips.ethereum.org/EIPS/eip-1155)
-- [ERC-1155: مستندات Openzeppelin](https://docs.openzeppelin.com/contracts/3.x/erc1155)
-- [ERC-1155: در Repo گیت هاب](https://github.com/enjin/erc-1155)
-- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md
deleted file mode 100644
index d8e06f7dc6a..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md
+++ /dev/null
@@ -1,172 +0,0 @@
----
-title: استاندارد توکن ERC-20
-description:
-lang: fa
----
-
-## معرفی {#introduction}
-
-**توکن چیست؟**
-
-توکن ها میتوانند هرچیزی را بصورت مجازی در اتریوم ارائه دهند:
-
-- امتیاز شهرت در یک پلتفرم آنلاین
-- مهارت های یک کاراکتر در یک بازی
-- دارایی های اقتصادی مانند سهام یک شرکت
-- یک ارز فیات مانند دلار
-- یک اونس طلا
-- و موارد دیگر...
-
-این نوع ویژگی قدرتمند اتریوم باید با یک استاندارد قوی اداره شود، اینطور نیست؟ این دقیقا همان جایی است که ERC-20 نقش خودش را اجرا میکند! این استانداردها به توسعه دهندگان این امکان را می دهد تا توکن اپلیکیشن هایی که با سایر محصولات و خدمات سازگار هستند را بسازند. همچنین این استاندارد عملکرد اضافهتری را برای اتر (واحد ارز داخلی اتریم یا ETH) فراهم میکند.
-
-**ERC-20 چیست؟**
-
-ERC-20 استانداردی را برای توکنهای تعویض پذیر معرفی می کند، به عبارت دیگر، آنها دارای خاصیتی هستند که باعث می شود هر توکن دقیقاً مشابه (از نظر نوع و مقدار) با توکن دیگر باشد. برای مثال توکن های ERC-20 دقیقا مثل اتر رفتار میکنند. به این معنی که 1 توکن همیشه با دیگر توکن ها برابر بوده و خواهد بود.
-
-## پیش نیاز ها {#prerequisites}
-
-- [حساب ها](/developers/docs/accounts)
-- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
-- [استانداردهای توکن](/developers/docs/standards/tokens/)
-
-## ساختار {#body}
-
-مفهوم توکن ERC-20 یا درخواست اتریوم برای نظرات 20 توسط فابیان ووگلستلر در نوامبر 2015 به عنوان استاندارد توکنی بیان شد که یک API برای توکن های قراردادهای هوشمند ارایه میکند.
-
-نمونه هایی از عملکردهای ERC-20 عبارتند از:
-
-- انتقال توکن ها از یک حساب به حساب دیگر
-- دریافت موجودی توکن یک حساب
-- دریافت کل عرضه توکن موجود در شبکه
-- تایید این که آیا مقداری توکن از یک حساب میتواند توسط یک حساب شخص ثالث خرج شود یا خیر
-
-اگر یک قرارداد هوشمند روشها و رویدادهای زیر را اجرا کند، میتوان آن را یک قرارداد توکن تعویض ناپذیر ERC-20 نامید و پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
-
-از [EIP-20](https://eips.ethereum.org/EIPS/eip-20):
-
-### روشها {#methods}
-
-```solidity
-function name() public view returns (string)
-function symbol() public view returns (string)
-function decimals() public view returns (uint8)
-function totalSupply() public view returns (uint256)
-function balanceOf(address _owner) public view returns (uint256 balance)
-function transfer(address _to, uint256 _value) public returns (bool success)
-function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
-function approve(address _spender, uint256 _value) public returns (bool success)
-function allowance(address _owner, address _spender) public view returns (uint256 remaining)
-```
-
-### رویدادها {#events}
-
-```solidity
-event Transfer(address indexed _from, address indexed _to, uint256 _value)
-event Approval(address indexed _owner, address indexed _spender, uint256 _value)
-```
-
-### مثالها {#web3py-example}
-
-بیایید ببینیم سادگی یک استاندارد چقدر مهم است تا باعث شود هر گونه قرارداد توکن ERC-20 را در اتریوم بازرسی کنیم. ما برای ایجاد یک رابط در هر توکن ERC-20، فقط به رابط دوتایی برنامه قرارداد (ABI) نیاز داریم. همانطور که در زیر می بینید ما از یک ABI ساده شده استفاده می کنیم تا آن را به مثال قابل هضمی تبدیل کنیم.
-
-#### مثال Web3.py {#web3py-example}
-
-ابتدا مطمئن شوید که کتابخانه پایتون [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) را نصب کرده اید:
-
-```
-pip install web3
-```
-
-```python
-from web3 import Web3
-
-
-w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
-
-dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
-weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
-
-acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
-
-# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract.
-# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply()
-simplified_abi = [
- {
- 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
- 'name': 'balanceOf',
- 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [],
- 'name': 'decimals',
- 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [],
- 'name': 'symbol',
- 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [],
- 'name': 'totalSupply',
- 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- }
-]
-
-dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi)
-symbol = dai_contract.functions.symbol().call()
-decimals = dai_contract.functions.decimals().call()
-totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
-addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals
-
-# DAI
-print("===== %s =====" % symbol)
-print("Total Supply:", totalSupply)
-print("Addr Balance:", addr_balance)
-
-weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi)
-symbol = weth_contract.functions.symbol().call()
-decimals = weth_contract.functions.decimals().call()
-totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
-addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals
-
-# WETH
-print("===== %s =====" % symbol)
-print("Total Supply:", totalSupply)
-print("Addr Balance:", addr_balance)
-```
-
-## مشکلات شناخته شده {#erc20-issues}
-
-### مشکل دریافت توکن ERC-20 {#reception-issue}
-
-هنگامی که توکنهای ERC-20 به یک قرارداد هوشمند ارسال میشوند که برای مدیریت توکنهای ERC-20 طراحی نشده است، توکنها برای همیشه از دست خواهند رفت. این زمانی اتفاق میافتد که قرارداد هوشمند گیرنده، عملکرد لازم برای شناسایی یا پاسخ به توکنهای دریافتی را ندارد و هیچ مکانیزمی در استاندارد ERC-20 وجود ندارد که قرارداد دریافت کننده را از توکنهای دریافتی مطلع کند. راههای اصلی شکلگیری این موضوع:
-
-1. مکانیسم انتقال توکن
- - توکنهای ERC-20 با استفاده از تابع transfer یا transferFrom انتقال مییابند
- - هنگامی که کاربر با استفاده از این توابع، توکنها را به آدرس یک قرارداد هوشمند ارسال میکند، توکنها بدون در نظر گرفتن این که آیا قرارداد دریافت کننده برای رسیدگی به آنها طراحی شده است یا خیر، انتقال خواهند یافت
-2. عدم اطلاع رسانی
- - قرارداد دریافتکننده اعلان یا تماسی مبنی بر ارسال توکن به آن دریافت نمیکند
- - اگر قرارداد دریافتکننده مکانیزمی برای مدیریت توکنها نداشته باشد (به عنوان مثال، یک تابع بازگشتی یا یک تابع اختصاصی برای مدیریت دریافت توکن)، توکنها به طور مؤثر در آدرس قرارداد گیر میکنند
-3. بدون مدیریت داخلی
- - استاندارد ERC-20 دارای یک تابع اجباری برای اجرای دریافت قراردادها نیست، که این امر منجر به وضعیتی میشود که بسیاری از قراردادها قادر به مدیریت صحیح توکنهای دریافتی نیستند
-
-برخی استانداردهای جایگزین بر این مشکل فائق آمدهاند، مانند [ERC-223](/developers/docs/standards/tokens/erc-223)
-
-## اطلاعات بیشتر {#further-reading}
-
-- [EIP-20: استاندارد توکن ERC-20](https://eips.ethereum.org/EIPS/eip-20)
-- [OpenZeppelin - توکن ها](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
-- [OpenZeppelin - پیادهسازی ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
-- [Alchemy - راهنمایی برای توکنهای ERC-20 نوشته شده با Solidity](https://www.alchemy.com/overviews/erc20-solidity)
-
-
-## سایر استانداردهای توکن قابل تعویض {#fungible-token-standards}
-
-- [ERC-223](/developers/docs/standards/tokens/erc-223)
-- [ERC-777](/developers/docs/standards/tokens/erc-777)
-- [ERC-4626 - خزانههای توکنیزه شده](/developers/docs/standards/tokens/erc-4626)
\ No newline at end of file
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md
deleted file mode 100644
index 5bfacb62270..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md
+++ /dev/null
@@ -1,209 +0,0 @@
----
-title: استاندارد توکن ERC-223
-description: مروری بر استاندارد توکن تعویض پذیر ERC-223، طرز کار آن و مقایسه آن با ERC-20.
-lang: fa
----
-
-## مقدمه {#introduction}
-
-### ERC-223 چیست؟ {#what-is-erc223}
-
-استاندارد ERC-223 همانند ERC-20، برای توکنهای تعویض پذیر است. تفاوت کلیدی آنها این است که ERC-223 علاوه بر API (رابط کاربری برنامه نویسی)، منطق انتقال توکنها از فرستنده به گیرنده را نیز تعریف مینماید. این استاندارد یک مدل ارتباطی را معرفی میکند که اجازه میدهد انتقال توکنها در طرف گیرنده انجام شود.
-
-### تفاوتها با ERC-20{#erc20-differences}
-
-ERC-223 به یک سری از محدودیتهای استاندارد ERC-20 پاسخ میدهد و شیوهی جدیدی از ارتباط بین قرارداد هوشمند منبع توکن و قرارداد هوشمندی که ممکن است دریافت کننده توکنها باشد را معرفی میکند. اینها برخی از مواردی هستند که با ERC-223 امکان پذیرند ولی با ERC-20 نه:
-
-- انجام و پردازش انتقال توکن در سمت گیرنده: گیرندهها میتوانند تشخیص دهند که یک توکن ERC-223 برای آنها واریز میشود.
-- رد کردن توکنهایی که به درستی ارسال نشدهاند: اگر کاربری توکنهای ERC-223 را به قرارداد اشتباهی واریز نماید، آن قرارداد میتواند تراکنش را رد کند و باعث جلوگیری از دست رفتن توکنها شود.
-- ابرداده در تراکنش ها: توکنهای ERC-223 میتوانند شامل ابرداده باشند و اجازه دهند تا اطلاعات دلخواه به تراکنش توکنها الصاق شود.
-
-## پیش نیازها {#prerequisites}
-
-- [حسابها](/توسعهدهندهها/اسناد/حساب)
-- [قراردادهای هوشمند](/توسعهدهندهها/اسناد/قراردادهای هوشمند/)
-- [Token standards](/developers/docs/standards/tokens/)
-- [ERC-20](/توسعهدهندهها/اسناد/استانداردها/توکنها/erc-20/)
-
-## ساختار{#body}
-
-ERC-223 یک استاندارد مخصوص توکن است که یک API برای توکنها در داخل قراردادهای هوشمند پیادهسازی میکند. همچنین یک API هم برای قراردادهایی که قرار است توکنهای ERC-223 دریافت کنند، تعریف میکند. قراردادهایی که از API گیرندهی ERC-223 پشتیبانی نمیکنند، قادر نخواهند بود توکنهای ERC-223 دریافت کنند و این باعث جلوگیری از خطای کاربر میشود.
-
-اگر یک قرارداد هوشمند توابع و رویدادهایی که قرار است مطرح شوند را پیادهسازی نماید، میتواند بهعنوان یک قرارداد توکن سازگار با ERC-223 شناخته شود. پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
-
-قرارداد ملزم نیست فقط توابع و عملکرد زیر را داشته باشد و یک توسعه دهنده میتواند هر قابلیت دیگری را از سایر استانداردهای توکن متفاوت به این قرارداد اضافه کند. برای مثال توابع `approve` (تائید) و `transferFrom` (انتقال از) جزئی از استاندارد ERC-223 نیستند، بلکه این توابع میتوانند در صورت نیاز پیادهسازی شوند.
-
-از [EIP-223](https://eips.ethereum.org/EIPS/eip-223):
-
-### روشها {#methods}
-
-توکن ERC-223 باید روشهای زیر را پیادهسازی کند:
-
-```solidity
-// تابع اسم
-function name() public view returns (string)
-// تابع سمبل
-function symbol() public view returns (string)
-// تابع اعشار
-function decimals() public view returns (uint8)
-// تابع عرضه کل
-function totalSupply() public view returns (uint256)
-// تابع موجودی (آدرس دلخواه)
-function balanceOf(address _owner) public view returns (uint256 balance)
-// تابع انتقال توکن
-function transfer(address _to, uint256 _value) public returns (bool success)
-// تابع انتقال توکن (همراه با متغیر اضافه برای انتقال داده)
-function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
-```
-
-قراردادی که قصد دارد توکنهای ERC-223 دریافت کند، باید روش زیر را پیادهسازی کند:
-
-```solidity
-// تابع قلاب دریافت توکن برای پیادهسازی توسط قرارداد هوشمند
-function tokenReceived(address _from, uint _value, bytes calldata _data)
-```
-
-اگر توکنهای ERC-223 به قراردادی ارسال شوند که تابع `tokenReceived(..)` را پیادهسازی نکرده باشد، تراکنش باید شکست بخورد و توکنها نباید از موجودی فرستنده منتقل شوند.
-
-### رویدادها {#events}
-
-```solidity
-// رویداد انتقال
-event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data)
-```
-
-### مثالها {#examples}
-
-رابط برنامهنویسی (API) توکن ERC-223 مشابه ERC-20 میباشد، بنابراین از نظر توسعه فرانت-اند هیچ تفاوتی ایجاد نمیشود. تنها تفاوت این است که احتمال دارد توکن ERC-223 توابع `approve` + `transferFrom` را نداشته باشد، چرا که آنها در این استاندارد اختیاری هستند.
-
-#### مثالهای Solidity{#solidity-example}
-
-مثالهای زیر نشان میدهد که چگونه یک قرارداد ساده و اولیه توکن ERC-223 عمل میکند:
-
-```solidity
-pragma solidity ^0.8.19;
-abstract contract IERC223Recipient {
- function tokenReceived(address _from, uint _value, bytes memory _data) public virtual;
-}
-contract VeryBasicERC223Token {
- event Transfer(address indexed from, address indexed to, uint value, bytes data);
- string private _name;
- string private _symbol;
- uint8 private _decimals;
- uint256 private _totalSupply;
- mapping(address => uint256) private balances;
- function name() public view returns (string memory) { return _name; }
- function symbol() public view returns (string memory) {return _symbol; }
- function decimals() public view returns (uint8) { return _decimals; }
- function totalSupply() public view returns (uint256) { return _totalSupply; }
- function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; }
- function isContract(address account) internal view returns (bool) {
- uint256 size;
- assembly { size := extcodesize(account) }
- return size > 0;
- }
- function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){
- balances[msg.sender] = balances[msg.sender] - _value;
- balances[_to] = balances[_to] + _value;
- if(isContract(_to)) {
- IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);
- }
- emit Transfer(msg.sender, _to, _value, _data);
- return true;
- }
- function transfer(address _to, uint _value) public returns (bool success){
- bytes memory _empty = hex"00000000";
- balances[msg.sender] = balances[msg.sender] - _value;
- balances[_to] = balances[_to] + _value;
- if(isContract(_to)) {
- IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);
- }
- emit Transfer(msg.sender, _to, _value, _empty);
- return true;
- }
-}
-```
-
-حال ما به یک قرارداد دیگر نیاز داریم تا واریز `tokenA` را بپذیرد، با فرض اینکه توکن A یک توکن ERC-223 است. این قرارداد باید فقط توکن A را بپذیرد و هر توکن دیگری را رد کند. زمانی که قرارداد توکن A را دریافت میکند، باید یک رویداد `Deposit()` را اطلاع رسانی کند و مقدار متغیر داخلی `deposits` را افزایش دهد.
-
-کد مذکور به این شکل است:
-
-```solidity
-contract RecipientContract is IERC223Recipient {
- event Deposit(address whoSentTheTokens);
- uint256 deposits = 0;
- address tokenA; // The only token that we want to accept.
- function tokenReceived(address _from, uint _value, bytes memory _data) public override
- {
- // It is important to understand that within this function
- // msg.sender is the address of a token that is being received,
- // msg.value is always 0 as the token contract does not own or send Ether in most cases,
- // _from is the sender of the token transfer,
- // _value is the amount of tokens that was deposited.
- require(msg.sender == tokenA);
- deposits += _value;
- emit Deposit(_from);
- }
-}
-```
-
-## سوالات متداول {#faq}
-
-### اگر مقداری از توکن B به قرارداد بفرستیم، چه اتفاقی خواهد افتاد؟ {#sending-tokens}
-
-تراکنش شکست خواهد خورد و انتقال توکنها انجام نخواهد شد. توکنها به آدرس فرستنده بازگشت داده خواهند شد.
-
-### چگونه میتوانیم به این قرارداد واریز انجام دهیم؟ {#contract-deposits}
-
-تابع `transfer(address,uint256)` یا `transfer(address,uint256,bytes)` از توکن ERC-223 را با مشخص کردن آدرس `RecipientContract`، فراخوانی کنید.
-
-### اگر یک توکن ERC-20 را به این قرارداد ارسال کنیم، چه اتفاقی خواهد افتاد؟ {#erc-20-transfers}
-
-اگر یک توکن ERC-20 به `RecipientContract` ارسال کنیم، توکنها انتقال خواهند یافت اما این انتقال شناسایی نخواهد شد (هیچ رویداد `Deposit()` اجرا نخواهد شد و مقدار واریزیها تغییر نخواهد کرد). از واریزهای ERC-20 ناخواسته نمیتوان جلوگیری کرد.
-
-### چه میشود اگر بخواهیم پس از تکمیل انتقال توکن، تابع دیگری را اجرا کنیم؟ {#function-execution}
-
-برای انجام دادن این کار راههای مختلف وجود دارد. در این مثال ما روشی را دنبال خواهیم کرد که باعث میشود انتقال ERC-223 مشابه انتقال اتر شود:
-
-```solidity
-contract RecipientContract is IERC223Recipient {
- event Foo();
- event Bar(uint256 someNumber);
- address tokenA; // The only token that we want to accept.
- function tokenReceived(address _from, uint _value, bytes memory _data) public override
- {
- require(msg.sender == tokenA);
- address(this).call(_data); // Handle incoming transaction and perform a subsequent function call.
- }
- function foo() public
- {
- emit Foo();
- }
- function bar(uint256 _someNumber) public
- {
- emit Bar(_someNumber);
- }
-}
-```
-
-هنگامی که `RecipientContract` یک توکن ERC-223 را دریافت میکند، درست همانطور که تراکنشهای ارسال اتر فراخوانی توابع را بعنوان `data` در تراکنش کدنگاری میکنند، قرارداد نیز تابعی را که به عنوان متغیر `_data` در تراکنش توکن کدنگاری شده است اجرا خواهد کرد. برای اطلاعات بیشتر [دیتا فیلد](https://ethereum.org/en/developers/docs/transactions/#the-data-field) را مطالعه فرمائید.
-
-در مثال بالا، توکن ERC-223 باید با استفاده از تابع `transfer(address,uin256,bytes calldata _data)` به آدرس `RecipientContract` انتقال یابد. اگر مقدار پارامتر دیتا `0xc2985578` باشد (معادل امضاء تابع `foo()`)، بعد از دریافت توکن واریزی و اجراء رویداد Foo()، تابع foo() اجرا خواهد شد.
-
-پارامترها (متغیرهای ورودی) نیز میتوانند در `data` انتقال توکن کدنگاری شوند، برای مثال ما میتوانیم تابع bar() را با مقدار 12345 برای `_someNumber` اجرا کنیم. در این حالت مقدار `data` باید
-`0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` باشد به شکلی که
-`0x0423a132` امضاء تابع `bar(uint256)` است و
-`00000000000000000000000000000000000000000000000000000000000004d2` همان 12345 است در قالب uint256.
-
-## محدودیتها {#limitations}
-
-در حالی که ERC-223 به چندین مشکل پیدا شده در استاندارد ERC-20 میپردازد، خودش محدودیتهای خاص خود را دارد:
-
-- پذیرش و سازگاری: ERC-223 هنوز به صورت فراگیر پذیرفته و پیادهسازی نشده است که باعث محدود شدن سازگاری آن با ابزارها و پلتفرمهای موجود میشود.
-- پیش سازگاری: ERC-223 با ERC-20 پیش سازگار نیست، یعنی قراردادها و ابزارهای موجود برای ERC-20، باید برای کار کردن با ERC-223 اصلاح شوند.
-- هزینه گاز: بررسیها و عملکردهای اضافه در تراکنشهای انتقال ERC-223 میتوانند منجر به هزینههای گاز بیشتر در مقایسه با تراکنشهای ERC-20 شوند.
-
-## ادامه مطلب {#further-reading}
-
-- [EIP-223: استاندارد توکن ERC-223](https://eips.ethereum.org/EIPS/eip-223)
-- [پیشنهاد اولیه ERC-223](https://github.com/ethereum/eips/issues/223)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md
deleted file mode 100644
index d63e8389c47..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md
+++ /dev/null
@@ -1,211 +0,0 @@
----
-title: ERC-4626 استاندارد خزانه توکنیزه شده
-description: استانداری برای خزانههای سودده.
-lang: fa
----
-
-## مقدمه {#introduction}
-
-ERC-4626 استانداردی برای بهینهسازی و یکپارچهسازی متغیرهای فنی خزانههای سودده میباشد. این الگو یک API (وبسرویس) استاندارد را برای ارتباط با خزانههای سودده توکنیزه شده که نشانگر ارزش سهمی یک توکن ERC-20 پایه هستند، فراهم میکند. ERC-4626 همچنین یک افزونهی اختیاری را برای خزانههای توکنیزه شدهای که از توکنهای ERC-20 استفاده میکنند، ترسیم میکند که شامل عملکرد حداقلی برای سپردهگذاری، برداشت و نمایش موجودی توکنها است.
-
-**نقش استاندارد ERC-4626 در خزانههای سودده**
-
-بازارهای وامدهی، گردآورندگان و توکنهایی که ذاتا سودده هستند، به کاربران کمک میکنند تا با اجرای استراتژیهای متخلف، بهترین سود را برای توکنهای رمزارز پیدا کنند. این استراتژیها در انواع کم تفاوتی پیادهسازی میشوند که میتواند منجر به خطا یا هدر رفت منابع توسعه شود.
-
-استاندارد ERC-4626 با ایجاد الگوهای پیادهسازی پایدار و نبوغ آمیز، باعث کاهش زحمت یکپارچهسازی خزانههای سودده خواهد شد و امکان دسترسی به قابلیت کسب سود در اپلیکیشنهای مختلف را، با صرف کمترین دانش فنی از سوی برنامه نویسان فراهم میکند.
-
-توکن ERC-4626 به طور کامل در [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) توضیح داده شده است.
-
-## پیش نیاز ها {#prerequisites}
-
-برای درک بهتر مطالب این صفحه، به شما پیشنهاد میکنیم تا ابتدا دربارهی [استانداردهای توکن](/developers/docs/standards/tokens/) و [ERC-20](/developers/docs/standards/tokens/erc-20/) مطالعه بفرمائید.
-
-## توابع و ویژگی های ERC-4626: {#body}
-
-### روشها {#methods}
-
-#### asset {#asset}
-
-```solidity
-function asset() public view returns (address assetTokenAddress)
-```
-
-این تابع، آدرس توکن پایه را که در خزانه برای واریز، برداشت و حسابداری مورد استفاده قرار میگیرد، فراخوانی میکند.
-
-#### totalAssets {#totalassets}
-
-```solidity
-function totalAssets() public view returns (uint256)
-```
-
-این تابع، مجموع مقدار توکن پایه را که در خزانه نگهداری میشود نشان میدهد.
-
-#### convertToShares {#convertoshares}
-
-```solidity
-function convertToShares(uint256 assets) public view returns (uint256 shares)
-```
-
-این تابع مقدار `سهمی` که خزانه در ازای مقدار `دارایی` معاوضه خواهد کرد را نشان میدهد.
-
-#### convertToAssets {#convertoassets}
-
-```solidity
-function convertToAssets(uint256 shares) public view returns (uint256 assets)
-```
-
-این تابع مقدار `سهمی` که خزانه در ازای مقدار `دارایی (توکن پایه)` معاوضه خواهد کرد را نشان میدهد.
-
-#### maxDeposit {#maxdeposit}
-
-```solidity
-function maxDeposit(address receiver) public view returns (uint256 maxAssets)
-```
-
-این تابع حداکثر مقدار توکن پایه قابل واریز را که میتواند در یک تراکنش [`deposit`](#deposit) توسط `receiver` اجرا شود، نمایش میدهد.
-
-#### previewDeposit {#previewdeposit}
-
-```solidity
-function previewDeposit(uint256 assets) public view returns (uint256 shares)
-```
-
-این تابع به کاربران اجازه میدهد تاثیر تراکنش واریز خود را بر بلوک فعلی شبیهسازی کنند.
-
-#### deposit {#deposit}
-
-```solidity
-function deposit(uint256 assets, address receiver) public returns (uint256 shares)
-```
-
-این تابع `دارایی` یا همان توکن پایه را به خزانه واریز میکند و حق مالکیت `سهام (shares)` را به `گیرنده (receiver)` اعطا میکند.
-
-#### maxMint {#maxmint}
-
-```solidity
-function maxMint(address receiver) public view returns (uint256 maxShares)
-```
-
-این تابع حداکثر مقدار سهامی که در یک تراکنش [`mint`](#mint) توسط `receiver` میتواند ضرب شود را نمایش میدهد.
-
-#### previewMint {#previewmint}
-
-```solidity
-function previewMint(uint256 shares) public view returns (uint256 assets)
-```
-
-این تابع به کاربران اجازه میدهد تا تاثیر تراکنش ضرب دارایی خود را بر بلوک فعلی شبیهسازی کنند.
-
-#### ضرب سکه {#mint}
-
-```solidity
-function mint(uint256 shares, address receiver) public returns (uint256 assets)
-```
-
-این تابع با واریز مقدار `assets` از توکن پایه، دقیقاً به مقدار `shares` از سهام خزانه را برای آدرس `receiver` صادر میکند.
-
-#### maxWithdraw {#maxwithdraw}
-
-```solidity
-function maxWithdraw(address owner) public view returns (uint256 maxAssets)
-```
-
-این تابع حداکثر مقدار توکن پایه که در یک تراکنش برداشت یا [`withdraw`](#withdraw) توسط `owner` میتواند برداشت شود را نمایش میدهد.
-
-#### previewWithdraw {#previewwithdraw}
-
-```solidity
-function previewWithdraw(uint256 assets) public view returns (uint256 shares)
-```
-
-این تابع به کاربران اجازه میدهد تا تاثیر تراکنش برداشت دارایی (توکن پایه) خود را بر بلوک فعلی شبیهسازی کنند.
-
-#### عقب نشینی {#withdraw}
-
-```solidity
-function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
-```
-
-این تابع مقدار `shares` یا سهام را از آدرس `owner` میسوزاند و دقیقاً به مقدار `assets`، توکن پایه را از خزانه به آدرس `receiver` ارسال میکند.
-
-#### maxRedeem {#maxredeem}
-
-```solidity
-function maxRedeem(address owner) public view returns (uint256 maxShares)
-```
-
-این تابع حداکثر مقدار سهام را که از موجودی `owner`، از طریق اجرای تابع [`redeem`](#redeem) میتوان برداشت کرد، نشان میدهد.
-
-#### previewRedeem {#previewredeem}
-
-```solidity
-function previewRedeem(uint256 shares) public view returns (uint256 assets)
-```
-
-این تابع به کاربران اجازه میدهد تا تأثیر تراکنش بازخرید سهام (redeem) خود را بر روی بلوک فعلی شبیه سازی نمایند.
-
-#### redeem {#redeem}
-
-```solidity
-function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
-```
-
-این تابع مقدار مشخصی از `shares` را از جانب `owner` بازخرید میکند و به مقدار `assets`، توکن پایه از خزانه به آدرس `receiver` ارسال میکند.
-
-#### totalSupply {#totalsupply}
-
-```solidity
-function totalSupply() public view returns (uint256)
-```
-
-مقدار مجموع سهمهای خزانه بازخرید نشده که در گردش هستند را نشان میدهد.
-
-#### balanceOf {#balanceof}
-
-```solidity
-function balanceOf(address owner) public view returns (uint256)
-```
-
-مقدار مجموع سهمهای خزانه ای که `owner` در حال حاضر مالک آنها میباشد را نشان میدهد.
-
-### نقشه رابط برنامه نویسی {#mapOfTheInterface}
-
-![نقشه رابط برنامه نویسی ERC-4626](./map-of-erc-4626.png)
-
-### رویدادها {#events}
-
-#### رویداد واریز
-
-**باید** زمانی که توکنها از طریق توابع [`mint`](#mint) و [`deposit`](#deposit) به درون خزانه واریز میشوند، اجرا شود
-
-```solidity
-event Deposit(
- address indexed sender,
- address indexed owner,
- uint256 assets,
- uint256 shares
-)
-```
-
-`sender` کاربری میباشد که مقدار `assets` را در ازای مقدار `shares` مبادله کرده و مقدار `shares` را به آدرس `owner` انتقال داده است.
-
-#### رویداد برداشت
-
-**باید** زمانی که سهمها توسط یک سپرده گذار با استفاده از توابع [`redeem`](#redeem) یا [`withdraw`](#withdraw) برداشت میشوند، اجرا شود.
-
-```solidity
-event Withdraw(
- address indexed sender,
- address indexed receiver,
- address indexed owner,
- uint256 assets,
- uint256 shares
-)
-```
-
-`sender` کاربری میباشد که تراکنش برداشت را اجرا نموده و مقدار `shares` را که `owner` مالک آن بوده، در ازای مقدار `assets` مبادله کرده است. `receiver` آدرس کاربری میباشد که مقدار `asset` را دریافت کرده است.
-
-## بیشتر بخوانید {#further-reading}
-
-- [ERC-4626 استاندارد خزانه توکنیزه شده](https://eips.ethereum.org/EIPS/eip-4626)
-- [ERC-4626: در Repo گیت هاب](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md
deleted file mode 100644
index 64dda3bab51..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: ERC-721 استاندارد توکن تعویض ناپذیر
-description:
-lang: fa
----
-
-## معرفی {#introduction}
-
-**توکن تعویض ناپذیر چیست؟**
-
-از یک توکن تعویض ناپذیر (NFT) برای شناسایی چیزی یا شخصی به روشی منحصر به فرد استفاده می شود. این نوع توکن برای استفاده در پلتفرم هایی که آیتم های کلکسیونی، کلیدهای دسترسی، بلیط های بخت آزمایی، صندلی های شماره دار دارند و همچنین برای کنسرت ها و مسابقات ورزشی و غیره مناسب می باشد. این نوع خاص از توکن دارای امکانات شگفت انگیزی است، بنابراین سزاوار استانداردی مناسب است، بنابراین ERC-721 برای حل آن آمده است!
-
-**ERC-721 چیست؟**
-
-ERC-721 استانداردی را برای NFT معرفی می کند، به عبارت دیگر، شاید به دلیل قدمت، کمیاب بودن یا حتی چیز دیگری همچون ظاهر آن، این نوع توکن منحصر به فرد است و می تواند ارزش متفاوتی نسبت به توکن دیگری از همان قرارداد هوشمند را داشته باشد. صبر کنید، ظاهر؟
-
-بله! همه NFT ها دارای یک متغیر `uint256` به نام `tokenId` هستند، بنابراین برای هر قرارداد ERC-721، جفت `contract address، uint256 tokenId` باید در سطح جهانی یکتا باشد. گفته می شود، یک dapp می تواند یک "مبدل" داشته باشد که از `tokenId` به عنوان ورودی استفاده می کند و تصویری از چیز جالبی مانند زامبی ها، سلاح ها، مهارت ها یا بچه گربه های شگفت انگیز را خروجی می دهد!
-
-## پیش نیاز ها {#prerequisites}
-
-- [حساب ها](/developers/docs/accounts/)
-- [↳ قراردادهای هوشمند](/developers/docs/smart-contracts/)
-- [استانداردهای توکن](/developers/docs/standards/tokens/)
-
-## Body {#body}
-
-ERC-721 (درخواست اتریوم برای نظرات 721)، که توسط ویلیام انتریکن، دیتر شرلی، جیکوب ایوانز، ناستاسیا ساکس در ژانویه 2018 پیشنهاد شد، یک استاندارد توکن تعویض ناپذیر است که یک API برای توکنها در قراردادهای هوشمند پیادهسازی میکند.
-
-این ویژگی عملکردهایی مانند انتقال توکن ها از یک حساب به حساب دیگر، دریافت موجودی رمز فعلی یک حساب، به دست آوردن صاحب یک توکن خاص و نیز کل عرضه توکن موجود در شبکه را ارائه می دهد. علاوه بر اینها، عملکردهای دیگری همچون تأیید مقدار توکنی که از یک حساب می تواند توسط یک حساب شخص ثالث منتقل شود، را نیز در خود دارد.
-
-اگر یک قرارداد هوشمند، توابع و رویدادهای زیر را پیادهسازی کند، میتوان آن را یک قرارداد توکن تعویض ناپذیر ERC-721 نامید و پس از استقرار، مسئولیت پیگیری توکنهای ایجاد شده در اتریوم را بر عهده خواهد داشت.
-
-از [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
-
-### روشها {#methods}
-
-```solidity
- function balanceOf(address _owner) external view returns (uint256);
- function ownerOf(uint256 _tokenId) external view returns (address);
- function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
- function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
- function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
- function approve(address _approved, uint256 _tokenId) external payable;
- function setApprovalForAll(address _operator, bool _approved) external;
- function getApproved(uint256 _tokenId) external view returns (address);
- function isApprovedForAll(address _owner, address _operator) external view returns (bool);
-```
-
-### رویدادها {#events}
-
-```solidity
- event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
- event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
- event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
-```
-
-### مثالها {#web3py-example}
-
-بیایید ببینیم یک استاندارد چقدر مهم است که کار ما را برای بررسی قراردادهای هوشمند ERC-721 آسان میکند. ما فقط به رابط دوتایی برنامه قرارداد (ABI) برای ایجاد یک رابط برای هر توکن ERC-721 نیاز داریم. همانطور که در زیر می بینید ما از یک ABI ساده شده استفاده می کنیم تا آن را به عنوان مثالی با اصطکاک کم تبدیل کنیم.
-
-#### مثال Web3.py {#web3py-example}
-
-ابتدا مطمئن شوید که کتابخانه پایتون [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) را نصب کرده اید:
-
-```
-pip install web3
-```
-
-```python
-from web3 import Web3
-from web3._utils.events import get_event_data
-
-
-w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
-
-ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract
-
-acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction
-
-# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract.
-# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
-simplified_abi = [
- {
- 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
- 'name': 'balanceOf',
- 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
- 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [],
- 'name': 'name',
- 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}],
- 'name': 'ownerOf',
- 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}],
- 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [],
- 'name': 'symbol',
- 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [],
- 'name': 'totalSupply',
- 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}],
- 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
-]
-
-ck_extra_abi = [
- {
- 'inputs': [],
- 'name': 'pregnantKitties',
- 'outputs': [{'name': '', 'type': 'uint256'}],
- 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
- },
- {
- 'inputs': [{'name': '_kittyId', 'type': 'uint256'}],
- 'name': 'isPregnant',
- 'outputs': [{'name': '', 'type': 'bool'}],
- 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True
- }
-]
-
-ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
-name = ck_contract.functions.name().call()
-symbol = ck_contract.functions.symbol().call()
-kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
-print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}")
-
-pregnant_kitties = ck_contract.functions.pregnantKitties().call()
-print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}")
-
-# Using the Transfer Event ABI to get info about transferred Kitties.
-tx_event_abi = {
- 'anonymous': False,
- 'inputs': [
- {'indexed': False, 'name': 'from', 'type': 'address'},
- {'indexed': False, 'name': 'to', 'type': 'address'},
- {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}],
- 'name': 'Transfer',
- 'type': 'event'
-}
-
-# We need the event's signature to filter the logs
-event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
-
-logs = w3.eth.get_logs({
- "fromBlock": w3.eth.block_number - 120,
- "address": w3.to_checksum_address(ck_token_addr),
- "topics": [event_signature]
-})
-
-# Notes:
-# - Increase the number of blocks up from 120 if no Transfer event is returned.
-# - If you didn't find any Transfer event you can also try to get a tokenId at:
-# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
-# Click to expand the event's logs and copy its "tokenId" argument
-recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
-
-if recent_tx:
- kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above
- is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
- print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}")
-```
-
-قرارداد CryptoKitties دارای رویدادهای جالبی به غیر از موارد استاندارد است.
-
-بیایید دو مورد از آنها، `حامله` و `تولد` را بررسی کنیم.
-
-```python
-# Using the Pregnant and Birth Events ABI to get info about new Kitties.
-ck_extra_events_abi = [
- {
- 'anonymous': False,
- 'inputs': [
- {'indexed': False, 'name': 'owner', 'type': 'address'},
- {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
- {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
- {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}],
- 'name': 'Pregnant',
- 'type': 'event'
- },
- {
- 'anonymous': False,
- 'inputs': [
- {'indexed': False, 'name': 'owner', 'type': 'address'},
- {'indexed': False, 'name': 'kittyId', 'type': 'uint256'},
- {'indexed': False, 'name': 'matronId', 'type': 'uint256'},
- {'indexed': False, 'name': 'sireId', 'type': 'uint256'},
- {'indexed': False, 'name': 'genes', 'type': 'uint256'}],
- 'name': 'Birth',
- 'type': 'event'
- }]
-
-# We need the event's signature to filter the logs
-ck_event_signatures = [
- w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
- w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
-]
-
-# Here is a Pregnant Event:
-# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
-pregnant_logs = w3.eth.get_logs({
- "fromBlock": w3.eth.block_number - 120,
- "address": w3.to_checksum_address(ck_token_addr),
- "topics": [ck_event_signatures[0]]
-})
-
-recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
-
-# Here is a Birth Event:
-# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
-birth_logs = w3.eth.get_logs({
- "fromBlock": w3.eth.block_number - 120,
- "address": w3.to_checksum_address(ck_token_addr),
- "topics": [ck_event_signatures[1]]
-})
-
-recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
-```
-
-## NFT های محبوب {#popular-nfts}
-
-- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) برترین NFT در اتریوم را بر اساس حجم نقل و انتقالات فهرست می کند.
-- [CryptoKitties](https://www.cryptokitties.co/) یک بازی حول موجودات قابل پرورش، کلکسیونی و بسیار شایان ستایش است که به آنها CryptoKitties می گوییم.
-- [Sorare](https://sorare.com/) یک بازی فوتبال فانتزی جهانی است که در آن میتوانید کلکسیونهای نسخههای محدودی را جمعآوری کنید، تیمهای خود را مدیریت کنید و برای کسب جوایز به رقابت بپردازید.
-- [سرویس نام اتریوم (ENS)](https://ens.domains/) یک & روش غیرمتمرکز برای آدرسدهی منابع هم در داخل و هم خارج از بلاک چین با استفاده از نامهای ساده و قابل خواندن برای انسان می باشد.
-- [POAP](https://poap.xyz) NFTهای رایگان را به افرادی که در رویدادها شرکت می کنند یا اقدامات خاصی را انجام می دهند ارائه می دهد. ایجاد و توزیع POAP ها رایگان است.
-- [Unstoppable Domains](https://unstoppabledomains.com/) یک شرکت مستقر در سانفرانسیسکو است که دامنههای خود را بر روی بلاک چین ها می سازد. دامنههای بلاک چین آدرسهای ارزهای دیجیتال را با نامهای قابل خواندن برای انسان جایگزین میکنند و میتوان از آنها برای فعال کردن وبسایتهای مقاوم در برابر سانسور استفاده کرد.
-- [Gods Unchained Cards](https://godsunchained.com/) یک TCG در بلاک چین اتریوم است که از NFT برای ایجاد مالکیت واقعی بر داراییهای درون بازی استفاده میکند.
-- [Bored Ape Yacht Club](https://boredapeyachtclub.com) مجموعه ای از 10000 NFT منحصر به فرد است که علاوه بر اینکه یک اثر هنری نادر است، به عنوان نماد عضویت در باشگاه عمل می کند و امتیازات و مزایایی را برای اعضا فراهم می کند که در نتیجه تلاش های جامعه در طول زمان افزایش می یابد.
-
-## بیشتر بخوانید {#further-reading}
-
-- [EIP-721: استاندارد توکن تعویض ناپذیر ERC-721](https://eips.ethereum.org/EIPS/eip-721)
-- [OpenZeppelin - مستندات ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721)
-- [OpenZeppelin - پیاده سازی ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
-- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md
deleted file mode 100644
index e9e07e78e33..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: 'EIP-: استاندارد توکن ERC-777'
-description:
-lang: fa
----
-
-## {#introduction}
-
-****
-
-****
-
-قلاب ها تابعی هستند که در کد یک قرارداد هوشمند توضیح داده شده است. هنگامی که توکن ها از طریق یک قرارداد ارسال یا دریافت می شوند، قلاب ها فراخوانی می شوند. این به یک قرارداد هوشمند اجازه می دهد تا به توکن های ورودی یا خروجی واکنش نشان دهد.
-
-## {#prerequisites}
-
-- []()
-- []()
-- []()
-
-## {#body}
-
-قلاب ها با استفاده از استاندارد [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)ثبت و کشف میشوند.
-
-این استاندارد همچنین ابهامی را که در مورد `اعشار` ایجاد شده در ERC-20 وجود دارد حل می کند. این شفافیت باعث بهبود تجربه توسعه دهنده می شود.
-
-می توان با قراردادهای ERC-777 به گونه ای تعامل کرد که انگار قراردادهای ERC-20 هستند.
-
-### {#methods}
-
-```solidity
-
-```
-
-### {#events}
-
-```solidity
-
-```
-
-### {#web3py-example}
-
-#### {#web3py-example}
-
-```
-
-```
-
-```python
-
-
-
-
-```
-
-```python
-
-
-```
-
-## {#popular-nfts}
-
--
--
--
--
--
--
--
--
-
-## اطلاعات بیشتر {#further-reading}
-
-- []()
-- []()
-- []()
-- []()
diff --git a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md b/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md
deleted file mode 100644
index ac7c811e1a5..00000000000
--- a/public/content/translations/fa/23) Advanced Docs/developers/docs/standards/tokens/index.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: استانداردهای توکن
-description:
-lang: fa
-incomplete: true
----
-
-## معرفی {#introduction}
-
-بسیاری از استانداردهای توسعه اتریوم بر روی رابط های توکن تمرکز دارند. این استانداردها کمک میکنند تا اطمینان حاصل شود که قراردادهای هوشمند قابل تنظیم باقی میمانند، بهعنوان مثال، زمانی که یک پروژه جدید یک توکن صادر میکند که با صرافیهای غیرمتمرکز موجود سازگار باقی بماند.
-
-## پیش نیاز ها {#prerequisites}
-
-- [استانداردهای توسعه اتریوم](/developers/docs/standards/)
-- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
-
-## استانداردهای توکن {#token-standards}
-
-در اینجا برخی از محبوب ترین استانداردهای توکن در اتریوم آمده است:
-
-- [ERC-20](/developers/docs/standards/tokens/erc-20/) - یک رابط استاندارد برای توکنهای تعویضپذیر (قابل تعویض)، مانند توکنهای رایگیری، توکنهای شرطبندی یا ارزهای مجازی می باشد.
-
-### استانداردهای NFT {#nft-standards}
-
-- [ERC-721](/developers/docs/standards/tokens/erc-721/) - یک رابط استاندارد برای توکنهای تعویض ناپذیر، مانند یک سند برای اثر هنری یا یک آهنگ است.
-- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 امکان معاملات کارآمدتر و بستهبندی تراکنشها را فراهم میکند - بنابراین در هزینهها صرفهجویی میشود. این استاندارد توکن امکان ایجاد توکن های کاربردی (مانند $BNB یا $BAT) و توکن های تعویض ناپذیر مانند CryptoPunks را فراهم می کند.
-
-فهرست کامل پیشنهادهای [ERC](https://eips.ethereum.org/erc).
-
-## بیشتر بخوانید {#further-reading}
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-## آموزش های مرتبط {#related-tutorials}
-
-- [چک لیست ادغام توکن ها](/developers/tutorials/token-integration-checklist/) _– چک لیستی از مواردی که باید هنگام تعامل با توکن ها در نظر بگیرید._
-- [با قرارداد هوشمند توکن ERC20 آشنا شوید](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– مقدمه ای برای استقرار اولین قرارداد هوشمندتان بر روی یک شبکه آزمایشی اتریوم._
-- [انتقال و تایید توکن های ERC20 از یک قرارداد هوشمند Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– نحوه استفاده از قرارداد هوشمند برای تعامل با توکن با استفاده از زبان Solidity._
-- [پیاده سازی یک بازار ERC721 [راهنمای نحوه انجام]](/developers/tutorials/how-to-implement-an-erc721-market/) _– چگونه اقلام توکن دار را برای فروش بر روی یک تابلوی طبقه بندی غیرمتمرکز قرار دهیم._
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md"
deleted file mode 100644
index 01bbb6a1bfa..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md"
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: مقیاسپذیری
-description: مقدمهای بر گزینههای مختلف مقیاسپذیری که در حال حاضر توسط انجمن اتریوم در حال توسعه هستند.
-lang: fa
-sidebarDepth: 3
----
-
-## نمای کلی مقیاسبندی {#scaling-overview}
-
-با افزایش تعداد افرادی که از اتریوم استفاده میکنند، بلاک چین به محدودیتهای ظرفیت خاصی رسیده است. این امر هزینه استفاده از شبکه را بالا برده و نیاز به "راهحلهای مقیاسبندی" را ایجاد کرده است راهحلهای متعددی در حال تحقیق، آزمایش و پیادهسازی هستند که رویکردهای متفاوتی برای دستیابی به اهداف مشابه دارند.
-
-هدف اصلی مقیاسپذیری افزایش سرعت تراکنش (پایانپذیری سریعتر) و توان عملیاتی تراکنش (تعداد تراکنشهای بیشتر در ثانیه) بدون به خطر انداختن تمرکززدایی یا امنیت است (اطلاعات بیشتر درباره [دورنمای اتریوم](/roadmap/vision/) الف>). در لایه 1 بلاک چین اتریوم، تقاضای بالا منجر به معاملات کندتر و [قیمتهای گس](/developers/docs/gas/) بسیار زیاد میشود. افزایش ظرفیت شبکه از نظر سرعت و توان عملیاتی برای پذیرش معنادار و انبوه اتریوم اساسی است.
-
-در حالی که سرعت و توان عملیاتی مهم هستند، ضروری است که راه حلهای مقیاسبندی که این اهداف را قادر میسازند، غیرمتمرکز و ایمن باقی بمانند. برداشتن مانع ورود برای اپراتورهای گره برای جلوگیری از پیشرفت به سمت قدرت محاسباتی متمرکز و ناامن بسیار مهم است.
-
-از لحاظ مفهومی، ما ابتدا مقیاسبندی را به عنوان مقیاسبندی روی زنجیره یا مقیاسبندی خارج از زنجیره طبقهبندی میکنیم.
-
-## پیش نیاز ها {#prerequisites}
-
-شما باید درک خوبی از تمام موضوعات اساسی داشته باشید. اجرای راهحلهای مقیاسبندی، پیشرفته است زیرا این فناوری کمتر آزمایش شده و همچنان به تحقیق و توسعه ادامه میدهد.
-
-## مقیاسبندی روی زنجیره {#on-chain-scaling}
-
-مقیاسبندی روی زنجیره به تغییراتی در پروتکل اتریوم نیاز دارد (لایه 1 [میننت یا شبکه اصلی](/glossary/#mainnet)). برای مدت طولانی انتظار میرفت که خرد یا شارد کردن، بلاک چین اتریوم را مقیاسپذیر کند. این مورد شامل تقسیم بلاک چین به قطعات گسسته (شاردها) بود تا توسط زیرمجموعههای اعتبارسنج تأیید شود. با این حال، مقیاسبندی توسط لایههای ۲ به عنوان تکنیک مقیاسبندی اولیه انتخاب شده است. این مورد با افزودن شکل ارزانتری از دادههای متصل به بلوکهای اتریوم پشتیبانی میشود که بهویژه برای ارزانتر کردن رولآپها برای کاربران طراحی شده است.
-
-### زنجیره ای سازی {#sharding}
-
-زنجیرهایسازی فرآیند تقسیم یک پایگاه داده است. زیرمجموعههای اعتبارسنجها به جای پیگیری کل اتریوم، مسئول شارد هستند. زنجیرهایسازی برای مدت طولانی در [نقشه راه](/roadmap/) اتریوم بود و زمانی قرار بود قبل از ارتقاء ادغام برای اثبات سهام انجام شود. با این حال، توسعه سریع [مجموعههای لایه 2](#layer-2-scaling) و اختراع [دنک شاردینگ](/roadmap/danksharding) (افزودن حبابهای رولآپ دادهها به بلوکهای اتریوم که میتوانند بهطور کارآمدی توسط اعتبارسنجها تأیید شوند) باعث شده که جامعه اتریوم به جای مقیاسبندی با شاردینگ، از مقیاسبندی رولآپ محور حمایت کند. این مورد همچنین به سادهتر ماندن منطق اجماع اتریوم کمک میکند.
-
-## مقیاسبندی آفچین یا خارج زنجیره {#off-chain-scaling}
-
-راه حلهای خارج از زنجیره به طور جداگانه از لایه 1 میننت یا همان شبکه اصلی پیادهسازی میشوند - آنها نیازی به تغییر در پروتکل موجود اتریوم ندارند. برخی راهحلها، که به عنوان راهحلهای "لایه 2" شناخته میشوند، امنیت خود را مستقیماً از اجماع لایه 1 اتریوم به دست میآورند، مانند [آپتیمیستیک رولآپها](/developers/docs/scaling/optimistic-rollups/)، [مجموعههای دانش صفر](/developers/docs/scaling/zk-rollups/) یا [کانالهای حالت یا استیت](/developers/docs/scaling/state-channels/). راه حلهای دیگر شامل ایجاد زنجیرههای جدید به اشکال مختلف است که امنیت خود را جدا از شبکه اصلی یا همان شبکه اصلی میگیرند، مانند [زنجیرههای جانبی](#sidechains)، [ولیدیومها](#validium) ، یا [زنجیرههای پلاسما](#plasma). این راه حلها با شبکه اصلی ارتباط برقرار میکنند، اما امنیت خود را به گونهای متفاوت برای دستیابی به اهداف مختلف دریافت میکنند.
-
-### مقیاسبندی لایه 2 {#layer-2-scaling}
-
-این دسته از راه حلهای خارج از زنجیره یا آفچین امنیت خود را از شبکه اصلی اتریوم میگیرند.
-
-لایه ۲ یک اصطلاح جمعی برای راهحلهایی است که برای کمک به مقیاسپذیری برنامه شما با مدیریت تراکنشهای خارج از شبکه اصلی اتریوم (لایه ۱) و در عین حال بهرهگیری از مدل امنیتی غیرمتمرکز قوی شبکه اصلی طراحی شدهاند. هنگامی که شبکه مشغول است، سرعت تراکنش کاهش مییابد و تجربه کاربر را برای انواع خاصی از برنامههای غیرمتمرکز ضعیف میکند. و با شلوغ شدن شبکه، قیمت گس افزایش مییابد زیرا فرستندگان تراکنش قصد دارند از یکدیگر پیشی بگیرند. این مورد میتواند استفاده از اتریوم را بسیار گران کند.
-
-اکثر راه حلهای لایه 2 حول یک سرور یا خوشهای از سرورها متمرکز شدهاند که هر یک از آنها ممکن است به عنوان یک گره، اعتبارسنج، اپراتور، ترتیبدهنده، تولید کننده بلوک یا اصطلاح مشابه نامیده شود. بسته به پیادهسازی، این گرههای لایه 2 ممکن است توسط افراد، شرکتها یا نهادهایی که از آنها استفاده میکنند، یا توسط یک اپراتور شخص ثالث، یا توسط گروه بزرگی از افراد (مشابه شبکه اصلی) اجرا شوند. به طور کلی، تراکنشها به جای ارسال مستقیم به لایه 1 (شبکه اصلی) به این گرههای لایه 2 ارسال میشوند. برای برخی از راه حلها، قبل از اینکه آنها را به لایه 1 متصل کند، نمونه لایه 2 سپس آنها را به گروهها تقسیم میکند، پس از آن توسط لایه 1 ایمن میشوند و نمیتوان آنها را تغییر داد. جزئیات نحوه انجام این کار بین فناوریها و پیادهسازیهای لایه 2 متفاوت است.
-
-یک نمونه لایه 2 خاص ممکن است باز باشد و توسط بسیاری از برنامهها به اشتراک گذاشته شود، یا ممکن است توسط یک پروژه مستقر شده و تنها به پشتیبانی از برنامه آنها اختصاص داده شود.
-
-#### چرا لایه 2 مورد نیاز است؟ {#why-is-layer-2-needed}
-
-- افزایش تراکنش در ثانیه تجربه کاربر را تا حد زیادی بهبود میبخشد و ازدحام شبکه را در شبکه اصلی اتریوم کاهش میدهد.
-- تراکنشها در یک تراکنش به شبکه اصلی اتریوم جمع میشوند و هزینههای گس را برای کاربران کاهش میدهند و اتریوم را درهرجا برای مردم فراگیرتر و در دسترستر میسازد.
-- هر گونه به روزرسانی مقیاسپذیری نباید به قیمت تمرکززدایی یا امنیت باشد - لایه 2 در بالای اتریوم ساخته میشود.
-- شبکههای لایه 2 ویژه برنامه وجود دارند که هنگام کار با داراییها در مقیاس، مجموعهای از کاراییهای خاص خود را دارند.
-
-[اطلاعات بیشتر در مورد لایه 2](/layer-2/).
-
-#### رولآپ ها {#rollups}
-
-رولآپها اجرای تراکنش را در خارج از لایه 1 انجام میدهند و سپس دادهها در لایه 1 ارسال میشوند که در آن اجماع حاصل میشود. از آنجایی که دادههای تراکنش در بلوکهای لایه 1 گنجانده شدهاند، این امکان را فراهم میکند تا رولآپها توسط امنیت بومی اتریوم ایمن شوند.
-
-دو نوع رولآپ با مدلهای امنیتی مختلف وجود دارد:
-
-- **رولآپهای آپتیمیستیک**: فرض میکند که تراکنشها به طور پیشفرض معتبر هستند و فقط محاسبات را در صورت چالش از طریق [](/glossary/#fraud-proof) اجرا میکند. [اطلاعات بیشتر در مورد آپتیمیستیک رولآپها](/developers/docs/scaling/optimistic-rollups/).
-- **رولآپ دانش-صفر**: محاسبات را خارج از زنجیره اجرا میکند و یک [ ](/glossary/#validity-proof) به زنجیره ارسال میکند. .
-
-#### عملیاتهای برون زنجیرهای {#channels}
-
-کانالهای استیت (State channels) از قراردادهای چند امضایی استفاده میکنند تا شرکتکنندگان را قادر سازد به سرعت و آزادانه خارج از زنجیره تراکنش انجام دهند، سپس نهایی شدن را با شبکه اصلی حل کنند. این کار شلوغی شبکه، هزینهها و تاخیرها را به حداقل میرساند. در حال حاضر دو نوع کانال وجود دارد که کانالهای استیت و کانالهای پرداخت هستند.
-
-.
-
-### زنجیرههای جانبی {#sidechains}
-
-زنجیره جانبی (Sidechain) یک بلاک چین مستقل سازگار با ماشین مجازی اتریوم است که به موازات شبکه اصلی اجرا میشود. این موارد از طریق پلهای دو طرفه با اتریوم سازگار هستند و تحت قوانین اجماع و پارامترهای بلوک انتخابی خودشان اجرا میشوند.
-
-درباره [زنجیرههای جانبی](/developers/docs/scaling/sidechains/) بیشتر بیاموزید.
-
-### پلاسما {#plasma}
-
-زنجیره پلاسما یک بلاک چین جداگانه است که به زنجیره اصلی اتریوم متصل است و از شواهد تقلب (مانند [آپتیمیستیک رولآپها](/developers/docs/scaling/optimistic-rollups/)) برای داوری اختلافات استفاده میکند.
-
-درباره [پلاسما](/developers/docs/scaling/plasma/) بیشتر بیاموزید.
-
-### والیدیوم (Validium) {#validium}
-
-زنجیره ولیدیوم (Validium) از اثبات اعتبار مانند رولآپهای دانش صفر استفاده میکند، اما دادهها در زنجیره اصلی لایه 1 اتریوم ذخیره نمیشوند. این مورد میتواند منجر به 10 هزار تراکنش در ثانیه در هر زنجیره ولیدیوم شود و چندین زنجیره میتوانند به صورت موازی اجرا شوند.
-
-درباره [ولیدیوم](/developers/docs/scaling/validium/) بیشتر بیاموزید.
-
-## چرا این همه راهحلهای مقیاسبندی مورد نیاز است؟ {#why-do-we-need-these}
-
-- راهحلهای متعدد میتوانند به کاهش ازدحام کلی در هر قسمت از شبکه کمک کرده و همچنین از نقاط شکست منفرد جلوگیری کنند.
-- کل، بزرگتر از مجموع اجزای آن است. راهحلهای مختلف میتوانند وجود داشته باشند و با هماهنگی کار کنند که اجازه میدهند اثری تصاعدی بر سرعت و توان عملیات آتی داشته باشند.
-- همه راهحلها به استفاده مستقیم از الگوریتم اجماع اتریوم نیاز ندارند و جایگزینها میتوانند مزایایی را ارائه دهند که اگر اینطور نباشد بهدست آوردن آنها دشوار خواهد بود.
-- برای تحقق [چشمانداز اتریوم](/roadmap/vision/)، تنها یک راهحل مقیاسپذیری کافی نیست.
-
-## با توضیحات تصویری راحتترید؟ {#visual-learner}
-
-
-
-_توجه داشته باشید که توضیح ویدیو از عبارت "لایه 2" برای اشاره به تمام راهحلهای مقیاسپذیری خارج از زنجیره استفاده میکند، در حالی که ما "لایه 2" را به عنوان یک راهحل خارج از زنجیره که امنیت خود را از طریق اجماع اصلی لایه 1 به دست میآورد متمایز میکنیم._
-
-
-
-## بیشتر بخوانید {#further-reading}
-
-- [نقشه راه اتریوم با محوریت رولآپ](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _ ویتالیک بوترین_
-- [تجزیه و تحلیل به روز راهحلهای مقیاسپذیری لایه 2 برای اتریوم](https://www.l2beat.com/)
-- [ارزیابی راهحلهای مقیاسپذیری لایه 2 اتریوم: یک چارچوب مقایسه](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955)
-- [راهنمای ناقص رولآپ ها](https://vitalik.eth.limo/general/2021/01/05/rollup.html)
-- [رولآپهای دانش صفر مبتنی بر اتریوم: رقبای جهانی](https://hackmd.io/@canti/rkUT0BD8K)
-- [رولآپهای آپتیمیستیک در مقابل رولآپهای دانش صفر](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/)
-- [مقیاسپذیری بلاک چین با دانش صفر](https://ethworks.io/assets/download/zero-knowledge-blockchain-scaling-ethworks.pdf)
-- [چرا رولآپ + دادههای شارد شده تنها راهحل پایدار برای مقیاسپذیری بالا هستند](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48)
-- [چه نوع لایه 3 بهتر است؟](https://vitalik.eth.limo/general/2022/09/17/layer_3.html)
-- [قابلیت دسترسی داده ها یا: رولآپها چطور یاد گرفتند دیگر نگران نباشند و اتریوم را دوست داشته باشند](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups)
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md"
deleted file mode 100644
index dabf7e143fe..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md"
+++ /dev/null
@@ -1,269 +0,0 @@
----
-title: رول آپ های خوش بینانه
-description: مقدمه ای بر رول آپهای خوش بینانه، یک راه حل مقیاس پذیری که توسط جامعه اتریوم استفاده میشود.
-lang: fa
----
-
-رول آپهای خوش بینانه، پروتکلهای لایه دومی (L2) هستند که برای افزایش تعداد داده های ورودی لایه اصلی اتریوم طراحی شده اند. آنها محاسبات زنجیره اصلی اتریوم را با پردازش تراکنشها در خارج از زنجیره کاهش میدهند که باعث افزایش چشمگیر در سرعت پردازش میشوند. برخلاف سایر روشهای مقیاس پذیری مانند [زنجیرههای جانبی](/developers/docs/scaling/sidechains/)، رول آپهای خوش بینانه امنیت خود را از شبکه اصلی تأمین میکنند که این کار به وسیله انتشار نتیجه تراکنشها بر روی شبکه اصلی یا [زنجیرههای پلاسما](/developers/docs/scaling/plasma/) که تراکنشها را با استفاده از مکانیسم اثبات تقلب، تائید میکنند اما تراکنش را در جایی دیگر ذخیره میکنند، انجام میگیرد.
-
-از آنجایی که محسابات آهسته و پرهزینه ترین بخش از اتریوم میباشد، رول آپهای خوش بینانه میتوانند بهبود 10 الی 100 برابری را برای مقیاس پذیری ارائه دهند. همچنین رولآپ خوشبینانه تراکنشها را به صورت `calldata` یا [بلاب](/roadmap/danksharding/) در اتریوم وارد میکنند که باعث کاهش هزینه گاز مصرفی توسط کاربران میشود.
-
-## موارد مورد نیاز {#prerequisites}
-
-شما باید صفحات ما دربارهی [مقیاس پذیری اتریوم](/developers/docs/scaling/) و [لایه 2](/layer-2/) را خوانده باشید.
-
-## رولآپ خوشبینانه چیست؟ {#what-is-an-optimistic-rollup}
-
-رولآپ خوشبینانه رویکردی برای مقیاس پذیری اتریوم است که شامل انتقال محاسبات و ذخیره حالت (اطلاعات) به خارج از شبکه میشود. رولآپ خوشبینانه تراکنشها را خارج از اتریوم اجرا میکنند اما اطلاعات تراکنش را به صورت `calldata` یا [بلاب](/roadmap/danksharding/) به اتریوم ارسال میکنند.
-
-اپراتورهای رولآپ خوشبینانه، چندین تراکنش خارج زنجیرهای را در دستههای بزرگ دسته بندی میکند و سپس آنها را به اتریوم ارسال میکنند. این رویکرد باعث میشود تا هزینههای ثابت در چندین تراکنش در هر دسته توزیع شود و هزینهها برای کاربران کاهش یابد. همچنین رولآپ خوشبینانه از تکنیکهای فشرده سازی برای کاهش حجم داده ارسالی به اتریوم استفاده میکند.
-
-دلیل "خوشبین" رولآپ خوشبینانه این است که آنها فرض را بر این میگذارند که تراکنشهای خارج از زنجیره معتبر هستند و اثباتی را برای معتبر بودن دستههای تراکنش ارسالی بر روی شبکه منتشر نمیکنند. این امر باعث تمایز رولآپ خوشبینانه از [رولآپ دانش-صفر](/developers/docs/scaling/zk-rollups) که [اثبات اعتبار](/glossary/#validity-proof) را برای تراکنشهای خارج شبکه به صورت رمزنگاری شده منتشر میکند، میشود.
-
-در عوض، رولآپ خوشبینانه برای شناسائی مواردی که تراکنشها به درستی محاسبه نشدهاند، به یک طرح اثبات تقلب متکی است. پس از ارسال یک دسته رولآپ به اتریوم، یک بازه زمانی (به نام دوره چالش) وجود دارد که طی آن هرکسی میتواند با محاسبه [اثبات تقلب](/glossary/#fraud-proof)، نتایج یک رولآپ تراکنشها را به چالش بکشد.
-
-اگر اثبات تقلب با موفقیت انجام شود، پروتکل رولآپ، تراکنش(ها) را دوباره اجرا میکند و حالت رولآپهای مربوطه را بروز رسانی میکند. اثر دیگر موفقیت اثبات تقلب این میباشد که ترتیبدهندهای که مسئول گنجاندن تراکنش نادرست اجرا شده در یک بلوک است، جریمه خواهد شد.
-
-اگر یک رولآپ بدون چالش باقی بماند (برای مثال تمامی تراکنشها به درستی اجرا شده باشند)، پس گذشت دوره چالش، معتبر محسوب میشود و در اتریوم پذیرفته میشود. دیگران میتوانند بر روی یک بلوک رولآپ تائید نشده ادامه دهند اما باید این هشدار را در نظر بگیرند که: اگر براساس تراکنش نادرست اجرا شده از قبل منتشر شده باشند، نتایج آنها معکوس خواهد شد.
-
-## چگونه رولآپ خوشبینانه با اتریوم تعامل دارند؟ {#optimistic-rollups-and-Ethereum}
-
-رولآپ خوشبینانه، [راه حلهای مقیاس پذیری خارج زنجیرهای](/developers/docs/scaling/#off-chain-scaling) هستند که برای انجام عملیات در اتریوم ساخته شدند. هر رولآپ خوشبینانه توسط مجموعهای از قراردادهای هوشمند مستقر در شبکه اتریوم مدیریت میشود. رولآپ های خوشبینانه تراکنشها را خارج از شبکه اصلی اتریوم پردازش میکنند ولی این تراکنشهای خارج شبکهای را (به طور دستهای) به یک قرارداد رولآپ بر روی شبکه ارسال میکنند. همانند زنجیره اتریوم، این نتیجه ذخیره شده از تراکنش تغییرناپذیر است و "زنجیره رولآپ خوشبینانه" را شکل میدهد.
-
-ساختار یک رولآپ خوشبینانه متشکل از بخشهای زیر است:
-
-**قراردادهای هوشمند روی زنجیره**: عملیاتهای رولآپ های خوشبینانه توسط قراردادهای هوشمندی که بر روی اتریوم در حال اجرا هستند، کنترل میشوند. این شامل قراردادهایی میشود که بلوک رولآپ را ذخیره میکنند، بهروزرسانیهای حالت را در رولآپ نظارت میکنند و سپردههای کاربران را ردیابی میکنند. به این شکل، اتریوم نقش لایه پایه یا "لایه 1" را برای رولآپ های خوشبینانه دارد.
-
-**ماشین مجازی خارج از زنجیره (VM)**: اگرچه که قراردادهایی که پروتکل رولآپ خوشبینانه را مدیریت میکنند بر روی اتریوم اجرا میشوند، پروتکل رولآپ محاسبات و ذخیرهسازی حالت را در ماشین مجازی دیگری جدا از [ماشین مجازی اتریوم](/developers/docs/evm/) انجام میدهد. ماشین مجازی خارج از زنجیره جایی است که برنامهها در حال اجرا هستند و تغییرات حالت در آنجا رخ میدهند و این به عنوان لایه بالایی یا "لایه 2" برای یک رولآپ خوشبینانه عمل میکند.
-
-از آنجایی که رولآپ های خوشبینانه برای اجرای برنامههای نوشته شده یا کامپایل شده مخصوص EVM طراحی شدهاند، ماشین مجازی خارج زنجیره بسیاری از ارکان طراحی EVM را در خود به کار گرفته است. علاوه بر این، اجرا شدن مکانیسم اثبات تقلب بر روی شبکه به اتریوم اجازه میدهد تا موثق بودن تغییرات حالت محاسبه شده را در ماشین مجازی خارج از زنجیره اعمال کند.
-
-رولآپ خوشبینانه به عنوان "راه حلهای مقیاس پذیری ترکیبی" توصیف میشوند، زیرا در حالی که به عنوان پروتکلهای جداگانه وجود دارند، ویژگیهای امنیتی آنها از اتریوم مشتق شده است. از جمله موارد دیگر، اتریوم صحت محاسبات خارج از زنجیره رولآپ و در دسترس بودن داده های پشت محاسبات را تضمین میکند. این امر باعث میشود که رولآپ های خوشبینانه نسبت به پروتکلهای مقیاس پذیری کاملاً خارج از زنجیره (برای مثال [زنجیرههای جانبی](/developers/docs/scaling/sidechains/)) که برای امنیت به اتریوم متکی نیستند، امنتر باشند.
-
-رولآپ های خوشبینانه برای موارد زیر به پروتکل اصلی اتریوم متکی هستند:
-
-### دسترسی به دادهها {#data-availability}
-
-همانگونه که گفته شد، رولآپ های خوشبینانه دادههای تراکنش را به عنوان `calldata` یا [blobs](/roadmap/danksharding/) به اتریوم میفرستند. از آنجایی که اجرای زنجیرهی رولآپ براساس تراکنشهای ارسالی میباشد، هرکسی میتواند از این اطلاعات - که بر لایه پایه اتریوم لینک شده است - برای اجرای وضعیت جمعآوری و تایید صحت انتقال حالت استفاده کند.
-
-[در دسترس بودن اطلاعات](/developers/docs/data-availability/) بسیار مهم است زیرا بدون دسترسی به دادههای حالت، به چالش کشندگان نمیتوانند اثبات تقلب را برای مخالفت با عملیات رولآپ نامعتبر ایجاد نمایند. با فراهم کردن دسترسی به اطلاعات توسط اتریوم، ریسک قسر در رفتن اپراتورهای رولآپ با اعمال کثیف (مانند ارسال بلوکهای نامعتبر) کاهش میابد.
-
-### مقاومت در برابر سانسور {#censorship-resistance}
-
-همچنین، رولآپ های خوشبینانه برای مقاومت در برابر سانسور به اتریوم نیازمند هستند. در یک رولآپ خوشبینانه، یک نهاد متمرکز (اپراتور) مسئول پردازش تراکنشها و ارسال بلوکهای رولآپ به اتریوم است. این چندین پیامد احتمالی دارد:
-
-- اپراتورهای رولآپ میتوانند کاربران را با کاملاً آفلاین شدن یا با امتناع از تولید بلوکهایی که شامل تراکنشهای خاصی در آنها هستند، سانسور کنند.
-
-- اپراتورهای رولآپ میتوانند کاربران را از برداشتن وجوهی که در قرارداد رولآپ واریز کرده اند، با استفاده از نگه داشتن دادههای لازم جهت تغییر حالت درخت مرکل مالکیت، جلوگیری کنند. نگه داشتن دادههای حالت همچنین میتواند وضعیت رولآپ را از کاربران پنهان کند و مانع از تعامل آنان با رولآپ شود.
-
-رولآپ های خوشبینانه این مشکل را با مجبور کردن اپراتورها به انتشار دادههای مرتبط با بروز رسانیهای حالت در اتریوم حل میکند. انتشار اطلاعات رولآپ بر روی زنجیره اتریوم مزایای زیر را دارد:
-
-- اگر یک اپراتور رولآپ خوشبینانه آفلاین شود یا تولید دستههای تراکنش را متوقف کند، گره دیگری میتواند از دادههای موجود برای بازتولید آخرین وضعیت رولآپ برای ادامه تولید بلوک استفاده کند.
-
-- کاربران میتوانند از دادههای تراکنش برای ایجاد اثبات مالکیت دارایی در قالب درخت مرکل استفاده نمایند و داراییهای خود را از رولآپ برداشت کنند.
-
-- کاربران همچنین میتوانند تراکنشهای خود را در لایه پایه یا L1، به جای ترتیب دهنده ارسال کنند که در این صورت ترتیب دهنده باید تراکنش را در یک محدوده زمانی مشخص برای ادامه تولید بلوکهای معتبر لحاظ کند.
-
-### توافق {#settlement}
-
-نقش دیگری که اتریوم در زمینه گردآوری رولآپ های خوشبینانه ایفا میکند، لایه توافق است. لایه توافق تمامی اکوسیستم بلاکچین را به هم لینک میکند، امنیت را برقرار میکند و در صورت بروز تعارض در زنجیرهای دیگر (در این مورد رولآپ خوشبینانه) که نیاز به داوری دارد، رأی نهائی بی طرفانه را صادر میکند.
-
-شبکه اصلی اتریوم مرکزی را برای رولآپ های خوشبینانه فراهم میکند تا اثباتهای تقلب را تائید نمایند و تعارضها را حل کنند. علاوه بر این، تراکنشهای انجام شده در رولآپ، تنها _پس از_ پذیرش بلوک رولآپ در اتریوم نهائی میشوند. هنگامی که یک تراکنش رولآپ به لایه پایه اتریوم ارسال و متعهد شد، نمیتوان آن را به عقب بازگرداند (به جز در مورد بسیار غیرمحتمل سازماندهی مجدد زنجیره).
-
-## طرز کار رول آپهای خوش بینانه چگونه است؟ {#how-optimistic-rollups-work}
-
-### اجرای تراکنش وگردآوری {#transaction-execution-and-aggregation}
-
-کاربران تراکنشها را به "اپراتورها" ارسال میکنند، که گرههایی مسئول پردازش تراکنشها در جمعبندی خوشبینانه هستند. همچنین این اپراتور که بهعنوان "اعتبارسنج" یا "گردآورنده" نیز شناخته میشود، تراکنشها را گردآوری میکند، دادههای زیربنایی را فشرده سازی میکند و بلوک را در اتریوم منتشر میکند.
-
-اگرچه که هر کسی میتواند اعتبارسنج شود، اعتبارسنجهای رولآپ خوشبینانه، باید قبل از تولید بلوکها مانند [سیستم اثبات سهام](/developers/docs/consensus-mechanisms/pos/)، وثیقه ای ارائه دهند. اگر اعتبارسنج یک بلوک نامعتبر ارسال کند یا روی یک بلوک قدیمی اما نامعتبر ساخته شود (حتی اگر بلوک آنها معتبر باشد)، این وثیقه میتواند کاهش یابد یا به اصطلاح slashed شود. بدین شکل رولآپ های خوشبینانه از مشوقهای اقتصاد رمزارزی بهره میبرند تا اطمینان حاصل شود که اعتبارسنجیها صادقانه عمل میکنند.
-
-انتظار میرود سایر اعتبارسنجها در زنجیره رولآپ خوشبینانه، تراکنشهای ارائه شده را با استفاده از کپی حالت (اطلاعات/داده) رولآپ خود اجرا کنند. اگر حالت نهائی اعتبارسنجی با حالت پیشنهادی اپراتور متفاوت باشد، آنها میتوانند یک چالش را شروع کنند و یک اثبات تقلب را محاسبه نمایند.
-
-برخی رولآپ های خوشبینانه ممکن است از یک سیستم اعتبارسنجی بدون نیاز به اجازه صرف نظر کنند و از یک "ترتیب دهنده" واحد برای اجرای زنجیره استفاده کنند. مانند یک اعتبارسنج، ترتیب دهنده تراکنشها را پردازش مینماید، بلوکهای رولآپ را تولید میکند و تراکنشهای رولآپ را به شبکه L1 (اتریوم) میفرستد.
-
-ترتیب دهنده با یک اپراتور رولآپ معمولی تفاوت دارد، زیرا آنها کنترل بیشتری بر ترتیب تراکنشها دارند. همچنین، ترتیب دهنده اولویت دسترسی به زنجیره رولآپ را داراست و تنها نهاد مجاز برای ارسال تراکنشها به قرارداد روی زنجیره اصلی اتریوم میباشد. تراکنشهایی که از طرف گرههای غیر ترتیب دهنده یا کاربران عادی هستند، به سادگی در یک صندوق ورودی جداگانه در صف قرار میگیرند تا زمانی که ترتیب دهنده آنها را در یک دسته جدید قرار دهد.
-
-#### ثبت بلوکهای رولآپ در اتریوم {#submitting-blocks-to-ethereum}
-
-همان گونه که ذکر شد، اپراتور یک رولآپ خوشبینانه تراکنشهای خارج از زنجیره را در یک دسته جمع میکند و آن را برای تائید نهائی به اتریوم میفرستد. این پروسه شامل فشردهسازی دادههای مربوط به تراکنش و انتشار آن در اتریوم به عنوان `calldata` یا در داخل blobها میباشد.
-
-`calldata`یک محل تغییر ناپذیر و غیر دائمی در یک قرارداد هوشمند است که بیشتر شبیه به [حافظه مموری](/developers/docs/smart-contracts/anatomy/#memory) عمل میکند. در حالی که `calldata` در زنجیره به عنوان بخشی از [گزارشهای تاریخچه](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) بلاکچین باقی میماند، به عنوان بخشی از حافظه حالت اتریوم ذخیره نمیشود. چون که `calldata` هیچ بخشی از حالت اتریوم را لمس نمیکند، برای ذخیره دادهها در زنجیره، ارزانتر از حافظه حالت است.
-
-کلمه کلیدی `calldata` همچنین در زبان برنامه نویسی Solidity به منظور ارسال پارامترهای ورودی به یک تابع قرارداد هوشمند، در زمان آغاز اجرا، استفاده میشود. `calldata` تابعی را که در حین تراکنش فراخوانی میشود، شناسائی میکند و ورودیهای تابع را به شکل یک دنباله دلخواه در قالب Bytes نگه میدارد.
-
-در مبحث رولآپ های خوشبینانه، `calldata` برای ارسال دادههای فشرده شده تراکنش به قرارداد مستقر در شبکه اصلی، استفاده میشود. اپراتور رولآپ با فراخوانی تابع مورد نیاز در قرارداد رولآپ و ارسال دادههای فشرده شده به عنوان پارامتر ورودی تابع، یک دسته جدید تراکنش اضافه میکند. استفاده از `calldata` هزینههای کاربر را کاهش میدهد زیرا بیشتر هزینههایی که رولآپ ها متحمل میشوند از ذخیره کردن داده در شبکه اصلی اتریوم میباشد.
-
-این هم [یک مثال](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) از ارسال دسته جمعی رولآپ برای نشان دادن نحوه عملکرد این مفهوم. ترتیب دهنده، تابع `appendSequencerBatch()` را فراخوانی کرد و دادههای فشرده تراکنش را با استفاده از `calldata` به عنوان ورودی ارسال کرد.
-
-برخی رولآپها اکنون از blobها برای دسته ای ارسال کردن تراکنشها به اتریوم استفاده میکنند.
-
-blobها تغییرناپذیر و موقت اند (درست مانند `calldata`) اما پس از حدود 18 روز از تاریخچه حذف میشوند. جهت کسب اطلاعات بیشتر دربارهی blobها، [Danksharding](/roadmap/danksharding) را ببینید.
-
-### ثبت تعهد حالت {#state-commitments}
-
-در هر مقطع زمانی، حالت رولآپ خوشبینانه (حسابها، موجودیها، کد قرارداد و غیره) در قالب [درخت مرکل](/whitepaper/#merkle-trees) مرتب میشود که به آن "درخت حالت" میگویند. ریشه این درخت مرکل (ریشه حالت)، که به آخرین و بروزترین حالت رولآپ اشاره میکند، هش شده و در قرارداد رولآپ ذخیره میشود. هر تغییر حالت در زنجیره، یک حالت رولآپ جدید ایجاد میکند، که اپراتور با محاسبه یک ریشه حالت جدید به آن متعهد میشود.
-
-اپراتور موظف است که در هنگام ارسال دستهها، هم ریشههای حالت قدیمی و هم ریشههای حالت جدید را ارسال کند. اگر ریشه حالت قدیمی با ریشه حالت موجود در قرارداد روی زنجیره مطابقت داشته باشد، ریشه موجود کنار گذاشته شده و با ریشه حالت جدید جایگزین میشود.
-
-اپراتور رولآپ همچنین ملزم است که یک ریشه مرکل را برای خود دسته تراکنش تعهد دهد. این به هرکسی اجازه میدهد تا با ارائه [اثبات مرکل](/developers/tutorials/merkle-proofs-for-offline-data-integrity/)، گنجانده شده بودن یک تراکنش در دسته (در L1) را ثابت کند.
-
-تعهدات حالت، به ویژه ریشههای حالت، برای اثبات صحیح بودن تغییرات حالت در یک رولآپ خوشبینانه ضروری است. قرارداد رولآپ، ریشههای حالت جدید را از اپراتورها بلافاصله پس از ارسال میپذیرد، اما بعداً میتواند ریشههای حالت نامعتبر را حذف کند تا رولآپ به حالت صحیح خود بازگردد.
-
-### اثبات کلاه برداری {#fraud-proving}
-
-همانگونه که توضیح دادیم هر کسی اجازه دارد که بلاک را پخش کند بدون اینکه ارزش ان را اثبات کند. هر چند، برای اطمینان از ایمن ماندن زنجیره، رولآپ خوشبینانه یک بازه زمانی را تعریف میکنند که طی آن هر کسی میتواند در مورد انتقال حالت اعتراض کند و آن را به چالش بکشد. از این رو، بلوکهای رولآپ "ادعا" نامیده میشوند، زیرا هر کسی میتواند ادعای آنها را مورد مناقشه قرار دهد.
-
-اگر کسی ادعایی را رد کند، پروتکل رولآپ محاسبات اثبات تقلب را آغاز میکند. هر نوع اثبات تقلبی تعاملی است - یک نفر باید قبل از اینکه شخص دیگری آن را به چالش بکشد، یک ادعا را ارسال کند. تفاوت در تعداد مرتبه تعامل برای محاسبه اثبات تقلب مورد نیاز نهفته است.
-
-طرحهای اثبات تعاملی تک مرتبهای، تراکنشهای مورد مناقشه را در L1 دوباره منتشر میکنند تا ادعاهای نامعتبر را شناسائی نمایند. پروتکل رولآپ اجرای مجدد تراکنش مورد مناقشه در L1 (اتریوم) را با استفاده از یک قرارداد تائید کننده، شبیهسازی میکند و ریشه حالت محاسبه شده تعیین میکند که چه کسی برنده چالش است. اگر ادعای رقیب در مورد وضعیت صحیح رول آپ درست باشد، اپراتور با قطع کردن باند خود جریمه میشود.
-
-با این حال، اجرای مجدد تراکنشها در لایه اول برای شناسایی تقلب مستلزم انتشار تعهدات استیت برای تراکنشهای فردی است و رول آپ دادهها را افزایش میدهد که باید در زنجیره منتشر شوند. بازپخش تراکنشها همچنین هزینههای گس قابل توجهی را به همراه دارد. به این دلایل، رول آپهای آپتیمیستیک به اثبات تعاملی چند دوره تغییر میکنند، که به همان هدف (یعنی تشخیص عملیات رول آپ نامعتبر) با کارایی بیشتر دست مییابد.
-
-#### اثبات چند مسیره فعال {#multi-round-interactive-proving}
-
-اثبات تعاملی چند دوره شامل یک پروتکل رفت و برگشت بین ادعا کننده و رقیب تحت نظارت یک قرارداد تأییدکننده لایه 1 است که در نهایت طرف دروغگو را تعیین میکند. پس از اینکه یک گره لایه دوم یک ادعا را به چالش میکشد، ادعا کننده باید ادعای مورد مناقشه را به دو نیمه مساوی تقسیم کند. هر ادعای منفرد در این مورد به اندازه دیگری شامل مراحل محاسباتی خواهد بود.
-
-سپس رقیب انتخاب خواهد کرد که چه ادعایی را میخواهد به چالش بکشد. فرآیند تقسیم (که "پروتکل دوگانه" نامیده میشود) ادامه مییابد تا زمانی که هر دو طرف در مورد ادعایی در مورد یک مرحله _تک_ اجرا بحث کنند. در این مرحله، قرارداد لایه اول با ارزیابی دستورالعمل (و نتیجه آن) برای دستگیری طرف متقلب، اختلاف را حل میکند.
-
-ادعاکننده ملزم به ارائه "اثبات یک مرحلهای" است که اعتبار محاسبات تک مرحلهای مورد مناقشه را تأیید میکند. اگر ادعاکننده نتواند اثبات یک مرحلهای را ارائه کند، یا تأییدکننده لایه اول اثبات را نامعتبر بداند، چالش را از دست میدهد.
-
-چند نکته در مورد این نوع اثبات تقلب:
-
-1. اثبات تقلب تعاملی چند دور کارآمد در نظر گرفته میشود زیرا کاری که زنجیره لایه اول باید در داوری اختلاف انجام دهد را به حداقل میرساند. به جای پخش مجدد کل تراکنش، زنجیره لایه اول فقط باید یک مرحله از اجرای مجموعه را دوباره اجرا کند.
-
-2. پروتکل های Bisection یا همان دو بخشی مقدار دادههای ارسال شده در زنجیره را کاهش میدهند (نیازی به انتشار commitهای حالت برای هر تراکنش نیست). همچنین، تراکنشهای رول آپ آپتیمیستیک با محدودیت گس اتریوم محدود نمیشوند. برعکس، رول آپهای آپتیمیستیک برای اجرای مجدد تراکنشها باید اطمینان حاصل کنند که تراکنش لایه دو دارای محدودیت گس کمتری برای تقلید اجرای آن در یک تراکنش واحد اتریوم است.
-
-3. بخشی از ضمانتکننده مخرب به رقیب تعلق میگیرد، در حالی که بخشی دیگر سوزانده میشود. سوزاندن از تبانی بین اعتبارسنجها جلوگیری میکند. اگر دو اعتبارسنجها با هم تبانی کنند تا چالشهای جعلی را آغاز کنند، باز هم بخش قابل توجهی از کل استیک را از دست خواهند داد.
-
-4. اثبات تعاملی چند دور به هر دو طرف (مدعیکننده و رقیب) نیاز دارد که در پنجره زمانی مشخص شده حرکت کنند. عدم اقدام قبل از انقضای مهلت مقرر باعث میشود که طرف متخلف از چالش منصرف شود.
-
-#### چرا اثبات تبهکار برای رول اپهای بهینه مهم است {#fraud-proof-benefits}
-
-اثبات تقلب مهم است، زیرا آنها _نهاییسازی بدون نیاز به اعتماد_ را در رول آپهای آپتیمیستیک تسهیل میکنند. نهاییبودن بدون اعتماد، کیفیتی از رول آپهای آپتیمیستیک است که تضمین میکند که یک تراکنش - تا زمانی که معتبر است - در نهایت تأیید شود.
-
-گرههای مخرب میتوانند با شروع چالشهای نادرست، تأیید یک بلوک رول آپ معتبر را به تأخیر بیندازند. با این حال، اثبات تقلب در نهایت اعتبار بلوک رول آپ را ثابت میکند و باعث تایید آن میشود.
-
-این همچنین به یکی دیگر از ویژگی های امنیتی رولآپ خوشبینانه مربوط می شود: اعتبار زنجیره به وجود _یک_ گره صادق بستگی دارد. گره صادق می تواند با ارسال ادعاهای معتبر یا مخالفت با ادعاهای نامعتبر، زنجیره را به درستی پیش ببرد. در هر صورت، گرههای مخربی که با گره صادق وارد اختلاف میشوند، در طول فرآیند اثبات تقلب، سهام خود را از دست خواهند داد.
-
-### نسبت L1 به L2 ، عملیات داخلی {#l1-l2-interoperability}
-
-رولآپ خوشبینانه برای قابلیت همکاری با شبکه اصلی اتریوم طراحی شدهاند و به کاربران اجازه میدهند پیامها و دادههای دلخواه را بین L1 و L2 ارسال کنند. آنها همچنین با EVM سازگار هستند، بنابراین میتوانید [دپ های](/developers/docs/dapps/) موجود را به رولآپ های خوشبینانه پورت کنید یا با استفاده از ابزارهای توسعه اتریوم، دپ های جدید ایجاد کنید.
-
-#### 1. انتقال دارایی {#asset-movement}
-
-##### ورود به رول اپ
-
-To use an optimistic rollup, users deposit ETH, ERC-20 tokens, and other accepted assets in the rollup’s [bridge](/developers/docs/bridges/) contract on L1. The bridge contract will relay the transaction to L2, where an equivalent amount of assets is minted and sent to the user’s chosen address on the optimistic rollup.
-
-User-generated transactions (like an L1 > L2 deposit) are usually queued until the sequencer re-submits them to the rollup contract. However, to preserve censorship resistance, optimistic rollups allow users to submit a transaction directly to the on-chain rollup contract if it has been delayed past the maximum time allowed.
-
-Some optimistic rollups adopt a more straightforward approach to prevent sequencers from censoring users. Here, a block is defined by all transactions submitted to the L1 contract since the previous block (e.g., deposits) in addition to the transactions processed on the rollup chain. If a sequencer ignores an L1 transaction, it will publish the (provably) wrong state root; therefore, sequencers cannot delay user-generated messages once posted on L1.
-
-##### خروج از رول اپ
-
-Withdrawing from an optimistic rollup to Ethereum is more difficult owing to the fraud proving scheme. If a user initiates an L2 > L1 transaction to withdraw funds escrowed on L1, they must wait until the challenge period—lasting roughly seven days—elapses. Nevertheless, the withdrawal process itself is fairly straightforward.
-
-After the withdrawal request is initiated on the L2 rollup, the transaction is included in the next batch, while the user’s assets on the rollup are burned. Once the batch is published on Ethereum, the user can compute a Merkle proof verifying the inclusion of their exit transaction in the block. Then it is a matter of waiting through the delay period to finalize the transaction on L1 and withdraw funds to Mainnet.
-
-To avoid waiting a week before withdrawing funds to Ethereum, optimistic rollup users can employ a **liquidity provider** (LP). A liquidity provider assumes ownership of a pending L2 withdrawal and pays the user on L1 (in exchange for a fee).
-
-Liquidity providers can check the validity of the user’s withdrawal request (by executing the chain themselves) before releasing funds. This way they have assurances that the transaction will be confirmed eventually (i.e., trustless finality).
-
-#### 2. سازگاری با EVM {#evm-compatibility}
-
-For developers, the advantage of optimistic rollups is their compatibility—or, better still, equivalence—with the [Ethereum Virtual Machine (EVM)](/developers/docs/evm/). EVM-compatible rollups comply with specifications in the [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) and support the EVM at the bytecode level.
-
-EVM-compatibility in optimistic rollups has the following benefits:
-
-i. Developers can migrate existing smart contracts on Ethereum to optimistic rollup chains without having to modify codebases extensively. This can save development teams time when deploying Ethereum smart contracts on L2.
-
-ii. Developers and project teams using optimistic rollups can take advantage of Ethereum's infrastructure. This includes programming languages, code libraries, testing tools, client software, deployment infrastructure, and so on.
-
-Using existing tooling is important because these tools have been extensively audited, debugged, and improved over the years. It also removes the need for Ethereum developers to learn how to build with an entirely new development stack.
-
-#### 3. صدا زدن قرارداد از روی زنجیره های متقاطع {#cross-chain-contract-calls}
-
-Users (externally owned accounts) interact with L2 contracts by submitting a transaction to the rollup contract or having a sequencer or validator do it for them. Optimistic rollups also allow contract accounts on Ethereum to interact with L2 contracts using bridging contracts to relay messages and pass data between L1 and L2. This means you can program an L1 contract on Ethereum Mainnet to invoke functions belonging to contracts on an L2 optimistic rollup.
-
-Cross-chain contract calls happen asynchronously—meaning the call is initiated first, then executed at a later time. This is different from calls between the two contracts on Ethereum, where the call produces results immediately.
-
-An example of a cross-chain contract call is the token deposit described earlier. A contract on L1 escrows the user's tokens and sends a message to a paired L2 contract to mint an equal amount of tokens on the rollup.
-
-As cross-chain message calls result in contract execution, the sender is usually required to cover [gas costs](/developers/docs/gas/) for computation. It is advisable to set a high gas limit to prevent the transaction from failing on the target chain. The token bridging scenario is a good example; if the L1 side of the transaction (depositing the tokens) works, but the L2 side (minting new tokens) fails due to low gas, the deposit becomes irrecoverable.
-
-Finally, we should note that L2 > L1 message calls between contracts need to account for delays (L1 > L2 calls are typically executed after some minutes). This is because messages sent to Mainnet from the optimistic rollup cannot be executed until the challenge window expires.
-
-## هزینه رولاپ های بهینه چگونه کار می کند؟ {#how-do-optimistic-rollup-fees-work}
-
-Optimistic rollups use a gas fee scheme, much like Ethereum, to denote how much users pay per transaction. Fees charged on optimistic rollups depends on the following components:
-
-1. **State write**: Optimistic rollups publish transaction data and block headers (consisting of the previous block header hash, state root, batch root) to Ethereum as a `blob`, or "binary large object". [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduced a cost-effective solution for including data on-chain. A `blob` is a new transaction field that allows rollups to post compressed state transition data to Ethereum L1. Unlike `calldata`, which remains permanently on-chain, blobs are short-lived and can be pruned from clients after [4096 epochs](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (approximately 18 days). By using blobs to post batches of compressed transactions, optimistic rollups can significantly reduce the cost of writing transactions to L1.
-
-2. **Blob gas used**: Blob-carrying transactions employ a dynamic fee mechanism similar to the one introduced by [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). The gas fee for type-3 transactions takes into account the base fee for blobs, which is determined by the network based on blob-space demand and the blob-space usage of the transaction being sent.
-
-3. **L2 operator fees**: This is the amount paid to the rollup nodes as compensation for computational costs incurred in processing transactions, much like gas fees on Ethereum. Rollup nodes charge lower transaction fees since L2s have higher processing capacities and aren't faced with the network congestions that force validators on Ethereum to prioritize transactions with higher fees.
-
-Optimistic rollups apply several mechanisms to reducing fees for users, including batching transactions and compressing `calldata` to reduce data publication costs. You can check the [L2 fee tracker](https://l2fees.info/) for a real-time overview of how much it costs to use Ethereum-based optimistic rollups.
-
-## چگونه رول اپهای بهینه سرعت و مقیاسپذیری را در اتریوم افزایش می دهند؟ {#scaling-ethereum-with-optimistic-rollups}
-
-As explained, optimistic rollups publish compressed transaction data on Ethereum to guarantee data availability. The ability to compress data published on-chain is crucial to scaling throughput on Ethereum with optimistic rollups.
-
-The main Ethereum chain places limits on how much data blocks can hold, denominated in gas units (the [average block size](/developers/docs/blocks/#block-size) is 15 million gas). While this restricts how much gas each transaction can use, it also means we can increase transactions processed per block by reducing transaction-related data—directly improving scalability.
-
-Optimistic rollups use several techniques to achieve transaction data compression and improve TPS rates. For example, this [article](https://vitalik.eth.limo/general/2021/01/05/rollup.html) compares the data a basic user transaction (sending ether) generates on Mainnet vs how much data the same transaction generates on a rollup:
-
-| پارامتر | Ethereum (L1) | Rollup (L2) |
-| -------- | ---------------------- | ---------------- |
-| Nonce | ~3 | 0 |
-| Gasprice | ~8 | 0-0.5 |
-| گاز | 3 | 0-0.5 |
-| To | 21 | 4 |
-| Value | 9 | ~3 |
-| امضا | ~68 (2 + 33 + 33) | ~0.5 |
-| From | 0 (recovered from sig) | 4 |
-| **جمع** | **حدود 112 بایت** | **حدود 12 بایت** |
-
-Doing some rough calculations on these figures can help show the scalability improvements afforded by an optimistic rollup:
-
-1. The target size for every block is 15 million gas and it costs 16 gas to verify one byte of data. Dividing the average block size by 16 gas (15,000,000/16) shows the average block can hold **937,500 bytes of data**.
-2. If a basic rollup transaction uses 12 bytes, then the average Ethereum block can process **78,125 rollup transactions** (937,5000/12) or **39 rollup batches** (if each batch holds an average of 2,000 transactions).
-3. If a new block is produced on Ethereum every 15 seconds, then the rollup's processing speeds would amount to roughly **5,208 transactions per second**. This is done by dividing the number of basic rollup transactions an Ethereum block can hold (**78,125**) by the average block time (**15 seconds**).
-
-This is a fairly optimistic estimate, given that optimistic rollup transactions cannot possibly comprise an entire block on Ethereum. However, it can give a rough idea of how much scalability gains that optimistic rollups can afford Ethereum users (current implementations offer up to 2,000 TPS).
-
-The introduction of [data sharding](/roadmap/danksharding/) on Ethereum is expected to improve scalability in optimistic rollups. Because rollup transactions must share blockspace with other non-rollup transactions, their processing capacity is limited by data throughput on the main Ethereum chain. Danksharding will increase the space available to L2 chains to publish data per block, using cheaper, impermanent "blob" storage instead of expensive, permanent `CALLDATA`.
-
-### مزایا و معایب رول اپ های بهینه {#optimistic-rollups-pros-and-cons}
-
-| مزایا | معایب |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Offers massive improvements in scalability without sacrificing security or trustlessness. | Delays in transaction finality due to potential fraud challenges. |
-| Transaction data is stored on the layer 1 chain, improving transparency, security, censorship-resistance, and decentralization. | Centralized rollup operators (sequencers) can influence transaction ordering. |
-| Fraud proving guarantees trustless finality and allows honest minorities to secure the chain. | If there are no honest nodes a malicious operator can steal funds by posting invalid blocks and state commitments. |
-| Computing fraud proofs is open to regular L2 node, unlike validity proofs (used in ZK-rollups) that require special hardware. | Security model relies on at least one honest node executing rollup transactions and submitting fraud proofs to challenge invalid state transitions. |
-| Rollups benefit from "trustless liveness" (anyone can force the chain to advance by executing transactions and posting assertions) | Users must wait for the one-week challenge period to expire before withdrawing funds back to Ethereum. |
-| Optimistic rollups rely on well-designed cryptoeconomic incentives to increase security on the chain. | Rollups must post all transaction data on-chain, which can increase costs. |
-| Compatibility with EVM and Solidity allows developers to port Ethereum-native smart contracts to rollups or use existing tooling to create new dapps. | |
-
-### یک توضیح تصویری از رول اپهای بهینه {#optimistic-video}
-
-با تصویر راحتتر یاد میگیرید؟ Watch Finematics explain optimistic rollups:
-
-
-
-### استفاده ار رول اپهای بهینه {#use-optimistic-rollups}
-
-Multiple implementations of Optimistic rollups exist that you can integrate into your dapps:
-
-
-
-## مطالعات تکمیلی در خصوص رول اپهای بهینه
-
-- [How do optimistic rollups work (The Complete guide)](https://www.alchemy.com/overviews/optimistic-rollups)
-- [What is a Blockchain Rollup? A Technical Introduction](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction)
-- [The Essential Guide to Arbitrum](https://newsletter.banklesshq.com/p/the-essential-guide-to-arbitrum)
-- [How does Optimism's Rollup really work?](https://www.paradigm.xyz/2021/01/how-does-optimisms-rollup-really-work)
-- [OVM Deep Dive](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52)
-- [What is the Optimistic Virtual Machine?](https://www.alchemy.com/overviews/optimistic-virtual-machine)
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md"
deleted file mode 100644
index 8de0998e26e..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md"
+++ /dev/null
@@ -1,175 +0,0 @@
----
-title: زنجیره های پلاسما
-description: مقدمهای بر زنجیرههای پلاسما بهعنوان یک راهحل مقیاسپذیر که در حال حاضر توسط جامعه اتریوم استفاده میشود.
-lang: fa
-incomplete: true
-sidebarDepth: 3
----
-
-زنجیره پلاسما یک بلاک چین مجزا است که به شبکه اصلی اتریوم متصل است، اما تراکنشهای خارج از زنجیره را با مکانیزم خاص خود برای اعتبارسنجی بلوک اجرا میکند. زنجیرههای پلاسما گاهی اوقات به عنوان زنجیرههای «کودک» شناخته میشوند که اساساً کپیهای کوچکتری از شبکه اصلی اتریوم هستند. زنجیره های پلاسما از [اثبات تقلب](/glossary/#fraud-proof) (مانند [رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)) برای داوری اختلافات استفاده می کنند.
-
-درختان مرکل ایجاد یک پشته بی پایان از این زنجیرهها را امکانپذیر میسازند که میتوانند پهنای باند را از زنجیرههای مادر (از جمله شبکه اصلی اتریوم) تخلیه کنند. با این حال، در حالی که این زنجیرهها مقداری امنیت را از اتریوم (از طریق اثبات تقلب) میگیرند، امنیت و کارایی آنها تحت تأثیر چندین محدودیت طراحی قرار میگیرد.
-
-## موارد مورد نیاز {#prerequisites}
-
-شما باید درک خوبی از همه موضوعات اساسی و درک سطح بالایی از [مقیاسسازی اتریوم](/developers/docs/scaling/) داشته باشید.
-
-## پلاسما چیست؟
-
-پلاسما چارچوبی برای بهبود مقیاس پذیری در بلاک چین های عمومی مانند اتریوم است. همانطور که در [وایت پیپر پلاسما](http://plasma.io/plasma.pdf) اصلی توضیح داده شد، زنجیره های پلاسما بر روی زنجیره بلوکی دیگری (به نام "زنجیره ریشه") ساخته شده اند. هر "زنجیره کودک" از زنجیره ریشه گسترش می یابد و به طور کلی توسط یک قرارداد هوشمند مستقر در زنجیره والد مدیریت می شود.
-
-قرارداد پلاسما، در میان چیزهای دیگر، به عنوان یک [پل](/developers/docs/bridges/) عمل می کند که به کاربران اجازه می دهد دارایی ها را بین شبکه اصلی اتریوم و زنجیره پلاسما جابجا کنند. اگرچه این امر آنها را شبیه به [زنجیره های جانبی](/developers/docs/scaling/sidechains/) می کند، زنجیره های پلاسما حداقل تا حدی از امنیت شبکه اصلی اتریوم بهره می برند. این برخلاف زنجیرهای جانبی است که تنها مسئول امنیت آنها هستند.
-
-## پلاسما چگونه کار می کند؟
-
-اجزای اصلی چارچوب پلاسما عبارتند از:
-
-### محاسبات خارج از زنجیره {#off-chain-computation}
-
-سرعت پردازش کنونی اتریوم به 15 تا 20 تراکنش در ثانیه محدود شده است که امکان کوتاهمدت مقیاسپذیری برای رسیدگی به کاربران بیشتر را کاهش میدهد. این مشکل عمدتاً به این دلیل وجود دارد که [مکانیسم اجماع اتریوم](/developers/docs/consensus-mechanisms/) به بسیاری از گرههای همتا به همتا برای تأیید هر بهروزرسانی در وضعیت بلاک چین نیاز دارد.
-
-اگرچه مکانیسم اجماع اتریوم برای امنیت ضروری است، اما ممکن است برای همه موارد استفاده اعمال نشود. به عنوان مثال، آلیس ممکن است برای یک فنجان قهوه تأیید شده توسط کل شبکه اتریوم نیازی به پرداخت روزانه خود به باب نداشته باشد زیرا اعتماد بین هر دو طرف وجود دارد.
-
-پلاسما فرض می کند که شبکه اصلی اتریوم نیازی به تأیید همه تراکنش ها ندارد. در عوض، میتوانیم تراکنشها را خارج از شبکه اصلی پردازش کنیم و گرهها را از تأیید اعتبار هر تراکنش رها کنیم.
-
-محاسبات خارج از زنجیره ضروری است زیرا زنجیره های پلاسما می توانند برای سرعت و هزینه بهینهسازی شوند. به عنوان مثال، یک زنجیره پلاسما ممکن است - و اغلب این کار را می کند - از یک "اپراتور" واحد برای مدیریت سفارش و اجرای تراکنش ها استفاده کند. تنها با یک نهاد که تراکنشها را تأیید میکند، زمان پردازش در زنجیره پلاسما سریعتر از شبکه اصلی اتریوم است.
-
-### ثبت تعهد حالت {#state-commitments}
-
-در حالی که پلاسما تراکنشهای خارج از زنجیره را انجام میدهد، آنها در لایه اصلی اجرای اتریوم مستقر میشوند – در غیر این صورت، زنجیرههای پلاسما نمیتوانند از تضمینهای امنیتی اتریوم بهرهمند شوند. اما نهایی کردن تراکنشهای خارج از زنجیره بدون اطلاع از وضعیت زنجیره پلاسما، مدل امنیتی را شکسته و امکان گسترش تراکنشهای نامعتبر را فراهم میکند. به همین دلیل است که اپراتور، نهادی که مسئول تولید بلوکها در زنجیره پلاسما است، ملزم به انتشار دورهای «تعهدات حالت» در اتریوم است.
-
-[طرح تعهد](https://en.wikipedia.org/wiki/Commitment_scheme) یک تکنیک رمزنگاری برای تعهد به یک مقدار یا بیانیه بدون افشای آن برای طرف دیگر است. تعهدات "الزام آور" هستند به این معنا که شما نمی توانید ارزش یا بیانیه را پس از تعهد به آن تغییر دهید. تعهدات حالت در پلاسما به شکل "ریشه های مرکل" (برگرفته از [درخت مرکل](/whitepaper/#merkle-trees)) است که اپراتور در فواصل زمانی آن را به قرارداد پلاسما در زنجیره اتریوم ارسال می کند.
-
-ریشههای مرکل، مبانی رمزنگاری هستند که امکان فشردهسازی حجم زیادی از اطلاعات را فراهم میکنند. یک ریشه مرکل (که در این مورد "ریشه بلوک" نیز نامیده می شود) می تواند تمام تراکنش های یک بلوک را نشان دهد. ریشه های مرکل همچنین تأیید اینکه یک قطعه کوچک از داده بخشی از مجموعه داده بزرگتر است را آسان تر می کند. به عنوان مثال، یک کاربر می تواند یک [اثبات مرکل](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) برای اثبات گنجاندن تراکنش در یک بلوک خاص تولید کند.
-
-ریشه های مرکل برای ارائه اطلاعات در مورد وضعیت خارج از زنجیره به اتریوم مهم هستند. میتوانید ریشههای مرکل را بهعنوان «نقاط ذخیره» در نظر بگیرید: اپراتور میگوید: «این وضعیت زنجیره پلاسما در نقطه x در زمان است، و این ریشه مرکل بهعنوان اثبات است» اپراتور به _حالت فعلی_ زنجیره پلاسما با ریشه مرکل متعهد است، به همین دلیل است که به آن "تعهد حالت" میگویند.
-
-### ورودی ها و خروجی ها {#entries-and-exits}
-
-برای اینکه کاربران اتریوم از مزیت پلاسما استفاده کنند، باید مکانیزمی برای جابجایی وجوه بین زنجیره اصلی و پلاسما وجود داشته باشد. ما نمیتوانیم خودسرانه اتر را به آدرسی در زنجیره پلاسما بفرستیم - این زنجیرهها ناسازگار هستند، بنابراین تراکنش یا شکست میخورد یا منجر به از دست رفتن وجوه میشود.
-
-پلاسما از یک قرارداد اصلی در حال اجرا بر روی اتریوم برای پردازش ورودی ها و خروجی های کاربر استفاده می کند. این قرارداد اصلی همچنین مسئول ردیابی تعهدات حالت (که قبلا توضیح داده شد) و مجازات رفتار غیرصادقانه از طریق اثبات تقلب است (در ادامه در این مورد بیشتر خواهد شد).
-
-#### ورود به زنجیره پلاسما {#entering-the-plasma-chain}
-
-برای ورود به زنجیره پلاسما، آلیس (کاربر) باید ETH یا هر توکن ERC-20 را در قرارداد پلاسما واریز کند. اپراتور پلاسما، که سپردههای قراردادی را تماشا میکند، مبلغی برابر با سپرده اولیه آلیس را دوباره ایجاد میکند و آن را به آدرس او در زنجیره پلاسما میفرستد. آلیس ملزم به دریافت وجوه در زنجیره فرزند است و سپس می تواند از این وجوه برای تراکنش ها استفاده کند.
-
-#### خروج از زنجیره پلاسما {#exiting-the-plasma-chain}
-
-خروج از زنجیره پلاسما به چند دلیل پیچیده تر از ورود به آن است. بزرگترین مورد این است که در حالی که اتریوم اطلاعاتی در مورد حالت زنجیره پلاسما دارد، نمی تواند صحت یا عدم صحت این اطلاعات را تأیید کند. یک کاربر مخرب می تواند ادعای نادرستی داشته باشد (مثلا بگوید "من 1000 اتر دارم") و از ارائه شواهد جعلی برای پشتیبان گیری از ادعا خودداری کند.
-
-برای جلوگیری از برداشت های مخرب، یک "دوره چالش" معرفی شده است. در طول دوره چالش (معمولاً یک هفته)، هر کسی می تواند با استفاده از یک اثبات تقلب، درخواست برداشت را به چالش بکشد. اگر چالش با موفقیت انجام شود، درخواست برداشت رد می شود.
-
-با این حال، معمولاً اینطور است که کاربران صادق هستند و ادعاهای درستی در مورد وجوه خود دارند. در این سناریو، آلیس با ارسال یک تراکنش به قرارداد پلاسما، درخواست برداشت از زنجیره ریشه (اتریوم) را آغاز می کند.
-
-او همچنین باید یک اثبات مرکل ارائه دهد که تأیید کند تراکنشی که وجوه او را در زنجیره پلاسما ایجاد می کند در یک بلوک گنجانده شده است. این برای تکرارهای پلاسما، مانند [MVP پلاسما](https://www.learnplasma.org/en/learn/mvp.html)، که از مدل [خروجی تراکنش خرج نشده (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output) استفاده میکند، ضروری است.
-
-دیگران، مانند [وجه نقد پلاسما](https://www.learnplasma.org/en/learn/cash.html)، وجوه را بهجای UTXO به عنوان [توکنهای غیرقابل تعویض](/developers/docs/standards/tokens/erc-721/) نشان میدهند. برداشت، در این مورد، مستلزم اثبات مالکیت توکن ها در زنجیره پلاسما است. این کار با ارسال دو آخرین تراکنش شامل توکن و ارائه یک اثبات Merkle برای تأیید گنجاندن آن تراکنشها در یک بلوک انجام میشود.
-
-کاربر همچنین باید به درخواست انصراف به عنوان تضمین رفتار صادقانه یک باند اضافه کند. اگر یک رقیب ثابت کند درخواست انصراف آلیس نامعتبر است، وثیقه او قطع می شود و مقداری از آن به عنوان پاداش به رقیب می رسد.
-
-اگر دوره چالش بدون ارائه مدرک ضد تقلب بگذرد، درخواست برداشت آلیس معتبر تلقی میشود و به او اجازه میدهد تا سپردههای قرارداد پلاسما روی اتریوم را بازیابی کند.
-
-### داوری اختلاف {#dispute-arbitration}
-
-مانند هر بلاک چین، زنجیرههای پلاسما به مکانیزمی برای اعمال یکپارچگی تراکنشها در مواردی که شرکتکنندگان بهطور مخرب عمل میکنند (مثلاً بازخرج وجوه) نیاز دارند. برای این منظور، زنجیره های پلاسما از شواهد تقلب برای داوری اختلافات مربوط به اعتبار انتقال حالت و مجازات رفتار بد استفاده می کنند. اثبات تقلب بهعنوان مکانیزمی استفاده میشود که از طریق آن یک زنجیره کودک پلاسما شکایتی را به زنجیره والدین خود یا به زنجیره ریشه ارسال میکند.
-
-اثبات تقلب صرفاً ادعایی است مبنی بر اینکه یک انتقال حالت خاص نامعتبر است. به عنوان مثال، اگر یک کاربر (آلیس) سعی کند دو بار همان سرمایه را خرج کند. شاید او UTXO را در تراکنش با باب خرج کرده باشد و بخواهد همان UTXO (که اکنون باب است) را در تراکنش دیگری خرج کند.
-
-برای جلوگیری از انصراف، باب با ارائه شواهدی مبنی بر خرج کردن UTXO مذکور در تراکنش قبلی توسط آلیس و اثبات مرکل مبنی بر گنجاندن تراکنش در یک بلوک، یک اثبات تقلب ایجاد خواهد کرد. همین فرآیند در Plasma Cash نیز کار میکند. باب باید مدرکی ارائه دهد که نشان دهد آلیس قبلاً توکنهایی را که میخواهد برداشت کند، منتقل کرده است.
-
-اگر چالش باب موفقیت آمیز باشد، درخواست خروج آلیس لغو می شود. با این حال، این رویکرد بر توانایی باب برای تماشای زنجیره درخواستهای برداشت متکی است. اگر باب آفلاین باشد، آلیس می تواند پس از سپری شدن دوره چالش، برداشت مخرب را پردازش کند.
-
-## مشکل خروج جرم در پلاسما {#the-mass-exit-problem-in-plasma}
-
-مشکل خروج انبوه زمانی رخ می دهد که تعداد زیادی از کاربران همزمان سعی می کنند از زنجیره پلاسما خارج شوند. علت وجود این مشکل به یکی از بزرگترین مشکلات پلاسما مربوط می شود: **در دسترس نبودن داده ها**.
-
-در دسترس بودن داده، توانایی تأیید این است که اطلاعات یک بلوک پیشنهادی واقعاً در شبکه بلاک چین منتشر شده است. یک بلوک "در دسترس نیست" اگر سازنده خود بلوک را منتشر کند اما دادههای استفاده شده برای ایجاد بلوک را مخفی کند.
-
-اگر گرهها میخواهند بلوک را دانلود و اعتبار تراکنشها را تأیید کنند، باید بلوکها در دسترس باشند. بلاک چین ها با وادار کردن تولیدکنندگان بلاک به ارسال تمام دادههای تراکنش در زنجیره، در دسترس بودن دادهها را تضمین میکنند.
-
-در دسترس بودن دادهها همچنین به ایمنسازی پروتکلهای مقیاسپذیری خارج از زنجیره که بر روی لایه پایه اتریوم ساخته شدهاند کمک میکند. با وادار کردن اپراتورهای این زنجیرهها به انتشار دادههای تراکنش در اتریوم، هر کسی میتواند با ایجاد مدارک تقلب که به وضعیت صحیح زنجیره ارجاع میدهد، بلوکهای نامعتبر را به چالش بکشد.
-
-زنجیرههای پلاسما عمدتاً دادههای تراکنش را با اپراتور ذخیره میکنند و **هیچ دادهای را در شبکه اصلی منتشر نمیکنند** (یعنی علاوه بر تعهدات دورهای استیت). این بدان معناست که اگر کاربران نیاز به ایجاد مدارک تقلب برای به چالش کشیدن تراکنشهای نامعتبر دارند، باید به اپراتور برای ارائه دادههای بلوک اعتماد کنند. اگر این سیستم کار کند، کاربران همیشه میتوانند از شواهد تقلب برای تضمین وجوه استفاده کنند.
-
-مشکل زمانی شروع میشود که اپراتور، نه هر کاربر، طرفی باشد که به طور مخرب عمل میکند. از آنجایی که اپراتور تنها کنترل بلاک چین را در دست دارد، آنها انگیزه بیشتری برای پیشبرد انتقال حالت نامعتبر در مقیاس بزرگتر مانند سرقت وجوه متعلق به کاربران در زنجیره پلاسما دارند.
-
-در این مورد، استفاده از سیستم کلاسیک ضد تقلب کار نمیکند. اپراتور به راحتی میتواند یک تراکنش نامعتبر را انجام دهد و وجوه آلیس و باب را به کیف پول خود منتقل و دادههای لازم برای ایجاد ضد تقلب را پنهان کند. این امکانپذیر است زیرا اپراتور لازم نیست دادهها را در دسترس کاربران یا شبکه اصلی قرار دهد.
-
-بنابراین، خوش بینانه ترین راه حل تلاش برای "خروج انبوه" کاربران از زنجیره پلاسما است. خروج انبوه برنامه اپراتور مخرب برای سرقت وجوه را کند کرده و مقداری محافظت برای کاربران فراهم میکند. درخواستهای برداشت بر اساس زمان ایجاد هر UTXO (یا توکن) سفارش داده میشوند و از اپراتورهای مخرب جلوگیری میکنند که کاربران صادق پیشرو باشند.
-
-با این وجود، ما هنوز به راهی برای تأیید صحت درخواستهای برداشت برای جلوگیری از پول نقد افراد فرصتطلب از خروجهای نامعتبر پردازش نامناسب در طول یک خروج انبوه نیاز داریم. راه حل ساده است: از کاربران بخواهید که آخرین **حالت معتبر زنجیره** را برای خروج از پول خود ارسال کنند.
-
-اما این رویکرد همچنان مشکلاتی دارد. به عنوان مثال، اگر همه کاربران در یک زنجیره پلاسما نیاز به خروج داشته باشند (که در مورد یک اپراتور مخرب امکانپذیر است)، کل وضعیت معتبر زنجیره پلاسما باید به یکباره روی لایه پایه اتریوم ارسال شود. با توجه به اندازه دلخواه زنجیرههای پلاسما (بازده بالا = داده بیشتر) و محدودیت در سرعت پردازش اتریوم، این یک راه حل ایده آل نیست.
-
-اگرچه بازیهای خروج از نظر تئوری خوب به نظر میرسند، خروجهای انبوه واقعی احتمالاً باعث ازدحام شبکه در خود اتریوم میشوند. علاوه بر آسیب رساندن به عملکرد اتریوم، یک خروج انبوه با هماهنگی ضعیف به این معنی است که کاربران ممکن است نتوانند قبل از تخلیه هر حساب در زنجیره پلاسما توسط اپراتور، وجوه خود را برداشت کنند.
-
-## مزایا و معایب پلاسما {#pros-and-cons-of-plasma}
-
-| نقاط مثبت | نقاط ضعف |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| توان عملیاتی بالا و هزینه کم در هر تراکنش را ارائه میدهد. | از محاسبات عمومی پشتیبانی نمیکند (نمیتوان قراردادهای هوشمند را اجرا کرد. فقط انتقال توکنهای اولیه، سواپها و چند نوع تراکنش دیگر از طریق منطق محمول پشتیبانی میشوند. |
-| مناسب برای تراکنش بین کاربران دلخواه (اگر هر دو در زنجیره پلاسما ایجاد شده باشند بدون سربار برای هر جفت کاربر) | برای اطمینان از امنیت وجوه خود، باید به طور دوره ای شبکه را تماشا کنید (الزام زندگی) یا این مسئولیت را به شخص دیگری محول کنید. |
-| زنجیرههای پلاسما را میتوان با موارد استفاده خاص که به زنجیره اصلی مرتبط نیستند، تطبیق داد. هر کسی، از جمله مشاغل، میتواند قراردادهای هوشمند پلاسما را برای ارائه زیرساخت مقیاسپذیر که در زمینههای مختلف کار میکند، سفارشی کند. | به یک یا چند اپراتور برای ذخیره داده و ارائه آن در صورت درخواست متکی است. |
-| با انتقال محاسبات و ذخیره سازی خارج از زنجیره، بار روی شبکه اصلی اتریوم را کاهش می دهد. | برداشتها چند روز به تأخیر میافتد تا چالشها وجود داشته باشد. برای دارایی های قابل تعویض، این می تواند توسط ارائه دهندگان نقدینگی کاهش یابد، اما هزینه سرمایه مرتبطی وجود دارد. |
-| | اگر تعداد زیادی از کاربران به طور همزمان سعی کنند از آن خارج شوند، شبکه اصلی اتریوم ممکن است شلوغ شود. |
-
-## پلاسما در مقابل پروتکل های مقیاس پذیری لایه 2 {#plasma-vs-layer-2}
-
-در حالی که زمانی پلاسما به عنوان یک راه حل مقیاس پذیر مفید برای اتریوم در نظر گرفته می شد، از آن زمان به نفع [پروتکل های مقیاس پذیری لایه (L2)](/layer-2/) کنار گذاشته شد. راهکار های مقیاس پذیری L2 چندین مشکل پلاسما را برطرف می کنند:
-
-### کارایی {#efficiency}
-
-[مجموعههای دانش صفر](/developers/docs/scaling/zk-rollups) شواهد رمزنگاری از اعتبار هر دسته از تراکنشهای خارج از زنجیره پردازش میشوند. این مانع از پیشبرد انتقال وضعیت نامعتبر توسط کاربران (و اپراتورها) می شود و نیاز به دوره های چالش و بازی های خروج را از بین می برد. همچنین به این معنی است که کاربران مجبور نیستند به صورت دوره ای زنجیره را تماشا کنند تا سرمایه خود را تضمین کنند.
-
-### پشتیبانی از قراردادهای هوشمند {#support-for-smart-contracts}
-
-مشکل دیگر در چارچوب پلاسما [ناتوانی در پشتیبانی از اجرای قراردادهای هوشمند اتریوم](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4) بود. در نتیجه، بیشتر پیادهسازیهای پلاسما عمدتاً برای پرداختهای ساده یا مبادله توکنهای ERC-20 ساخته شدهاند.
-
-برعکس، مجموعههای خوشبینانه با [ماشین مجازی اتریوم](/developers/docs/evm/) سازگار هستند و میتوانند [قراردادهای هوشمند](/developers/docs/smart-contracts/) بومی اتریوم را اجرا کنند، و آنها را به یک راهحل مفید و _ایمن_ برای مقیاس بندی [برنامه های غیرمتمرکز](/developers/docs/dapps/). به طور مشابه، برنامههایی برای [ایجاد یک پیادهسازی دانش صفر از EVM (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) در حال انجام است که به رول آپ های دانش صفر اجازه میدهد منطق دلخواه را پردازش کرده و قراردادهای هوشمند را اجرا کنند.
-
-### در دسترس نبودن داده ها {#data-unavailability}
-
-همانطور که قبلا توضیح داده شد، پلاسما از مشکل در دسترس بودن داده رنج می برد. اگر یک اپراتور مخرب یک انتقال نامعتبر را در زنجیره پلاسما ایجاد کند، کاربران نمی توانند آن را به چالش بکشند زیرا اپراتور می تواند داده های مورد نیاز برای ایجاد اثبات تقلب را مخفی کند. رولآپ ها این مشکل را با مجبور کردن اپراتورها برای ارسال دادههای تراکنش در اتریوم حل میکنند و به هر کسی اجازه میدهد وضعیت زنجیره را تأیید کند و در صورت لزوم، اثبات تقلب ایجاد کند.
-
-### مشکل خروج انبوه {#mass-exit-problem}
-
-ZK-rollup ها و رول آپ های خوش بینانه هر دو مشکل خروج انبوه پلاسما را به طرق مختلف حل می کنند. برای مثال، یک رول آپ دانش صفر بر مکانیزمهای رمزنگاری تکیه میکند که تضمین میکند اپراتورها تحت هیچ سناریویی نمیتوانند وجوه کاربران را سرقت کنند.
-
-به طور مشابه، رولآپ های خوشبینانه یک دوره تاخیر را برای برداشتها تحمیل میکند که طی آن هر کسی میتواند یک چالش را آغاز کند و از درخواستهای برداشت مخرب جلوگیری کند. در حالی که این شبیه به پلاسما است، تفاوت این است که تأییدکنندگان به داده های مورد نیاز برای ایجاد اثبات تقلب دسترسی دارند. بنابراین، نیازی نیست که کاربران رول آپ در یک مهاجرت دیوانهوار و «اول به خروج» به شبکه اصلی اتریوم شرکت کنند.
-
-## پلاسما چه تفاوتی با زنجیره جانبی و شاردینگ دارد؟ {#plasma-sidechains-sharding}
-
-پلاسما، زنجیرههای جانبی و شاردینگ تقریباً شبیه به هم هستند زیرا همگی به نوعی به شبکه اصلی اتریوم متصل میشوند. با این حال، سطح و قدرت این اتصالات متفاوت است، که بر ویژگیهای امنیتی هر محلول مقیاسبندی تأثیر میگذارد.
-
-### پلاسما در مقابل زنجیره های جانبی {#plasma-vs-sidechains}
-
-یک [سایدچین](/developers/docs/scaling/sidechains/) یک بلاک چین مستقل است که از طریق یک پل دو طرفه به شبکه اصلی اتریوم متصل است. [پلها](/bridges/) به کاربران اجازه میدهد تا توکنهایی را بین دو بلاک چین مبادله کنند تا در زنجیره جانبی تراکنش کنند، ازدحام در شبکه اصلی اتریوم کاهش مییابد و مقیاسپذیری را بهبود میبخشد. زنجیره های جانبی از مکانیزم اجماع جداگانه استفاده می کنند و معمولاً بسیار کوچکتر از شبکه اصلی اتریوم هستند. در نتیجه، پل زدن دارایی ها به این زنجیره ها مستلزم افزایش ریسک است. با توجه به فقدان ضمانتهای امنیتی به ارث رسیده از شبکه اصلی اتریوم در مدل زنجیره جانبی، کاربران در حمله به زنجیره جانبی، سرمایه خود را از دست میدهند.
-
-برعکس، زنجیره های پلاسما امنیت خود را از شبکه اصلی می گیرند. این باعث می شود که آنها به طور قابل توجهی ایمن تر از زنجیره های جانبی باشند. هم زنجیرههای جانبی و هم زنجیرههای پلاسما میتوانند پروتکلهای اجماع متفاوتی داشته باشند، اما تفاوت این است که زنجیرههای پلاسما ریشههای مرکل را برای هر بلوک در شبکه اصلی اتریوم منتشر میکنند. ریشههای بلوک قطعات کوچکی از اطلاعات هستند که میتوانیم از آنها برای تأیید اطلاعات مربوط به تراکنشهایی که در زنجیره پلاسما رخ میدهند استفاده کنیم. اگر حمله ای روی یک زنجیره پلاسما اتفاق بیفتد، کاربران می توانند با خیال راحت وجوه خود را با استفاده از شواهد مناسب به شبکه اصلی برگردانند.
-
-### پلاسما در مقابل شاردینگ {#plasma-vs-sharding}
-
-هم زنجیرههای پلاسما و هم زنجیرههای خردهای بهطور دورهای مدارک رمزنگاریشده را در شبکه اصلی اتریوم منتشر میکنند. با این حال، هر دو ویژگی های امنیتی متفاوتی دارند.
-
-زنجیرههای شارد «هدرهای دستهبندی» را به شبکه اصلی ارسال میکنند که حاوی اطلاعات دقیق در مورد هر قطعه داده است. گرهها در شبکه اصلی اعتبار خردههای داده را تأیید و اجرا میکنند، احتمال انتقال خردههای نامعتبر را کاهش میدهند و از شبکه در برابر فعالیتهای مخرب محافظت میکنند.
-
-پلاسما متفاوت است زیرا شبکه اصلی فقط حداقل اطلاعات را در مورد وضعیت زنجیره های کودک دریافت می کند. این بدان معنی است که شبکه اصلی نمی تواند به طور موثر تراکنش های انجام شده در زنجیره های فرزند را تأیید کند و امنیت آنها را کاهش دهد.
-
-**توجه داشته باشید** که شاردینگ بلاک چین اتریوم دیگر در نقشه راه نیست. با مقیاسپذیری از طریق رول آپها و [دنک شاردینگ](/roadmap/danksharding) جایگزین آن شده است.
-
-### از پلاسما استفاده کنید {#use-plasma}
-
-چندین پروژه پیادهسازیهای پلاسما را ارائه میدهند که میتوانید آنها را در برنامههای غیرمتمرکز خود ادغام کنید:
-
-- [پالیگان](https://polygon.technology/) (قبلاً شبکه متیک)
-
-## اطلاعات بیشتر {#further-reading}
-
-- [پلاسما را یاد بگیرید](https://www.learnplasma.org/en/)
-- [یک یادآوری سریع از معنای "امنیت شارد شده" و چرایی اهمیت آن](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/)
-- [Sidechains vs Plasma vs Sharding](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html)
-- [درک پلاسما، قسمت 1: مبانی](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics)
-- [زندگی و مرگ پلاسما](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#)
-
-_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md"
deleted file mode 100644
index c717daa2d86..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md"
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: زنجیرههای جانبی
-description: مقدمهای بر زنجیرههای جانبی که در حال حاضر بهعنوان راهحل مقیاسپذیری توسط جامعه اتریوم استفاده میشود.
-lang: fa
-sidebarDepth: 3
----
-
-زنجیره جانبی، یک بلاکچین جداگانه است که مستقل از اتریوم اجرا میشود و توسط یک پل دو طرفه به شبکه اصلی اتریوم متصل می شود. زنجیره های جانبی میتوانند پارامترهای بلوک و [الگوریتم های اجماع](/developers/docs/consensus-mechanisms/) جداگانهای از اتریوم داشته باشند که اغلب برای پردازش کارآمد تراکنش ها طراحی شده اند. با این حال، استفاده از زنجیره جانبی شامل معایبی نیز میباشد، زیرا آنها ویژگیهای امنیتی اتریوم را به ارث نمیبرند. برخلاف [راه حل های مقیاس بندی لایه 2](/layer-2/)، زنجیره های جانبی تغییرات حالت و دادههای تراکنش را به شبکه اصلی اتریوم ارسال نمیکنند.
-
-همچنین زنجیرههای جانبی برخی از معیارهای عدم تمرکز یا امنیت را قربانی دستیابی به توان عملیاتی و تعداد دادههای ورودی بالا میکنند ([مثلت مقیاسپذیری](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). برخلاف آن، اتریوم متعهد است بدون به خطر انداختن تمرکززدایی و امنیت، همانطور که در [بیانیه چشم انداز](/roadmap/vision/) برای ارتقاء مشخص شده است، مقیاسپذیری کند.
-
-## زنجیرههای جانبی چگونه عمل میکنند؟ {#how-do-sidechains-work}
-
-زنجیرههای جانبی، بلاکچینهای مستقلی با دادههای تاریخی، نقشه راه توسعه و ملاحظات طراحی متفاوت هستند. در حالی که یک زنجیره جانبی ممکن است شباهتهایی سطحی با اتریوم داشته باشد، چندین ویژگی متمایز دارد.
-
-### الگوریتم های اجماع {#consensus-algorithms}
-
-یکی از ویژگیهایی که زنجیرههای جانبی را منحصر به فرد میکند (یعنی متفاوت از اتریوم)، الگوریتم اجماع مورد استفاده در آن است. زنجیرههای جانبی برای اجماع به اتریوم متکی نیستند و میتوانند پروتکلهای اجماع جایگزینی را که مطابق با نیازهایشان باشد، انتخاب کنند. برخی نمونهها از الگوریتمهای اجماع مورد استفاده در زنجیرههای جانبی عبارتند از:
-
-- [اثبات صلاحیت (PoA)](/developers/docs/consensus-mechanisms/poa/)
-- [اثبات سهام واگذار شده](https://en.bitcoin.it/wiki/Delegated_proof_of_stake)
-- [تحمل خطای بیزانسی](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained).
-
-مانند اتریوم، زنجیرههای جانبی دارای گرههای اعتبارسنج هستند که تراکنشها را تائید و پردازش میکنند، بلوکها را تولید میکنند و حالت بلاکچین را ذخیره میکنند. اعتبارسنجها همچنین مسئول حفظ اجماع در سراسر شبکه و ایمنسازی آن در برابر حملات مخرب هستند.
-
-#### پارامترهای بلوک {#block-parameters}
-
-اتریوم محدودیتهایی را برای [زمان بلوکها](/developers/docs/blocks/#block-time) (یعنی مدت زمانی که تولید بلوکهای جدید طول میکشد) و [اندازه بلوکها](/developers/docs/blocks/#block-size) (یعنی مقدار دادههای موجود در هر بلوک، بر حسب گاز) تعیین میکند. اما برخلاف آن، زنجیرههای جانبی اغلب پارامترهای مختلفی مانند زمان بلوکهای سریعتر و محدودیتهای گاز بیشتر را برای دستیابی به توان عملیاتی بالا، تراکنشهای سریع و کارمزدهای پایین اتخاذ میکنند.
-
-در حالی که این امر دارای مزایای مفیدی است، پیامدهای مهمی برای تمرکز زدایی و امنیت شبکه دارد. پارامترهای بلوک، مانند زمان کم برای ایجاد بلوک و اندازه بلوکهای بزرگ، دشواری اجرای یک گره کامل را افزایش میدهند و چند "ابرگره" مسئول حفظ زنجیره میشوند. در چنین سناریویی، احتمال تبانی اعتبارسنجها یا تصاحب مخرب زنجیره، افزایش مییابد.
-
-برای اینکه بلاکچینها بدون آسیب رساندن به تمرکز زدایی، مقیاسپذیر شوند، اجرای یک گره باید برای همه آزاد باشد – نه اینکه تنها نهادهایی با سختافزار تخصصی بتوانند آن را اجرا کنند. به همین دلیل تلاشهایی در حال انجام است تا اطمینان حاصل شود که همه میتوانند [یک گره کامل](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) را در شبکه اتریوم اجرا کنند.
-
-### سازگاری با EVM {#evm-compatibility}
-
-برخی از زنجیرههای جانبی با EVM سازگار هستند و میتوانند قراردادهای توسعهیافته برای [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) را اجرا کنند. زنجیرههای جانبی سازگار با EVM، از قراردادهای هوشمند [نوشته شده با زبان برنامه نویسی Solidity](/developers/docs/smart-contracts/languages/) و همچنین سایر زبانهای قرارداد هوشمند سازگار با EVM پشتیبانی میکنند، به این معنی که قراردادهای هوشمند نوشته شده برای شبکه اصلی اتریوم، روی زنجیرههای جانبی سازگار با EVM نیز کار میکنند.
-
-این به معنی آن است که اگر میخواهید از [برنامه غیرمتمرکزdapp](/developers/docs/dapps/) خود در یک زنجیره جانبی استفاده کنید، فقط باید [قرارداد هوشمند](/developers/docs/smart-contracts/) خود را در این زنجیره جانبی مستقر کنید. این ظاهر و حس مشابه شبکه اصلی اتریوم را دارد و درست مانند آن عمل میکند - شما قراردادها را با زبان Solidity می نویسید و از طریق RPC زنجیرههای جانبی، با زنجیره تعامل میکنید.
-
-از آنجایی که زنجیره های جانبی با EVM سازگار هستند، به عنوان یک [راه حل مقیاس پذیر](/developers/docs/scaling/) مفید برای برنامههای غیرمتمرکز بومی اتریوم در نظر گرفته میشوند. با استقرار برنامه شما روی یک زنجیره جانبی، کاربران میتوانند از هزینههای کمتر گاز و تراکنشهای سریعتر لذت ببرند، به خصوص اگر شبکه اصلی اتریوم شلوغ باشد.
-
-با این حال، همانطور که قبلا توضیح داده شد، استفاده از یک زنجیره جانبی شامل محدودیتهای قابل توجهی میباشد. هر زنجیره جانبی مسئول امنیت خود است و ویژگیهای امنیتی اتریوم را به ارث نمیبرد. این احتمال رفتار مخرب را افزایش میدهد که میتواند بر کاربران شما تائیر بگذارد یا سرمایه آنها را در معرض خطر قرار دهد.
-
-### انتقال دارایی {#asset-movement}
-
-برای اینکه یک بلاکچین جداگانه به یک زنجیره جانبی برای شبکه اصلی اتریوم تبدیل شود، به توانایی انتقال آسان داراییها از و به شبکه اتریوم نیاز دارد. این قابلیت سازگاری دوجانبه با اتریوم، با استفاده از یک پل بلاکچین به دست میآید. [پلها](/bridges/) از قراردادهای هوشمند مستقر در شبکه اصلی اتریوم و یک زنجیره جانبی یا زنجیره جانبی برای کنترل پل زدن وجوه بین آنها استفاده میکنند.
-
-در حالی که پلها به کاربران کمک میکنند وجوه بین اتریوم و زنجیره جانبی را جابجا کنند، داراییها به صورت فیزیکی در دو زنجیره جابجا نمیشوند. در عوض، مکانیزمهایی که معمولاً شامل ضرب کردن و سوزاندن هستند برای انتقال ارزش در زنجیرهها استفاده میشوند. اطلاعات بیشتر در مورد [نحوه عملکرد پلها](/developers/docs/bridges/#how-do-bridges-work).
-
-## مزایا و معایب زنجیرههای جانبی {#pros-and-cons-of-sidechains}
-
-| نقاط مثبت | نقاط ضعف |
-| ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| فناوری زیربنای زنجیرههای جانبی به خوبی تثبیت شده و از تحقیقات گسترده و بهبود در طراحی بهره میبرد. | زنجیره های جانبی برخی از معیارهای عدم تمرکز و عدم نیاز به اعتماد را در ازای مقیاس پذیری معاوضه می کنند. |
-| زنجیره های جانبی از محاسبات عمومی پشتیبانی می کنند و سازگاری با EVM را ارائه می دهند (آنها می توانند برنامههای غیرمتمرکز بومی اتریوم را اجرا کنند). | زنجیره جانبی از یک مکانیزم اجماع جداگانه استفاده میکند و از تضمینهای امنیتی اتریوم بهره نمیبرد. |
-| زنجیرههای جانبی از مدلهای اجماع متفاوت برای پردازش کارآمد تراکنشها و کاهش هزینه تراکنش برای کاربران استفاده میکنند. | زنجیرههای جانبی به مفروضات اعتماد بالاتری نیاز دارند (به عنوان مثال، این که چه حد نصابی از اعتبارسنجهای زنجیره جانبی مخرب میتوانند مرتکب تقلب شوند). |
-| زنجیرههای جانبی سازگار با EVM به برنامههای غیرمتمرکز یا dappها اجازه میدهند اکوسیستم خود را گسترش دهند. | |
-
-### از زنجیرههای جانبی استفاده نمایید {#use-sidechains}
-
-پروژههای متعدد زنجیرههای جانبی را پیادهسازی کرده اند که میتوانید آنها را با dappهای خود ادغام کنید:
-
-- [زنجیره پالیگان با سیستم اثبات سهام (PoS)](https://polygon.technology/solutions/polygon-pos)
-- [Skale](https://skale.network/)
-- [زنجیره Gnosis (xDai سابق)](https://www.gnosischain.com/)
-- [شبکه لوم (Loom)](https://loomx.io/)
-- [Metis Andromeda](https://www.metis.io/)
-
-## بیشتر بخوانید {#further-reading}
-
-- [مقیاسپذیری اتریوم از طریق زنجیرههای جانبی](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _ - منتشر شده در 8 فوریه 2018 توسط جورجیوس کنستانتوپولوس (Georgios Konstantopoulos)_
-
-_آیا میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش کنید و آن را اضافه کنید!_
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md"
deleted file mode 100644
index 4c0a1d3cea6..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md"
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: کانالهای حالت
-description: مقدمهای بر کانالهای استیت و کانالهای پرداخت به عنوان یک راه حل مقیاس پذیر که در حال حاضر توسط جامعه اتریوم استفاده میشود.
-lang: fa
-sidebarDepth: 3
----
-
-کانالهای استیت به شرکتکنندگان این امکان را میدهند که به طور ایمن تراکنشهای خارج از زنجیره را انجام دهند و در عین حال تعامل با اتریوم شبکه اصلی را به حداقل میرسانند. همتایان کانال میتوانند تعداد دلخواه تراکنشهای خارج از زنجیره را انجام دهند در حالی که تنها دو تراکنش درون زنجیرهای را برای باز و بسته کردن کانال ارسال میکنند. این امکان انجام تراکنش بسیار بالا را فراهم میکند و منجر به کاهش هزینه برای کاربران میشود.
-
-## {#how-do-sidechains-work}
-
-بلاک چینهای عمومی، مانند اتریوم، به دلیل معماری توزیع شده با چالشهای مقیاسپذیری مواجه هستند: تراکنشهای روی زنجیره باید توسط همه گرهها اجرا شوند. گرهها باید بتوانند حجم تراکنشها را در یک بلوک با استفاده از سختافزار معمولی مدیریت و محدودیتی را بر روی توان عملیاتی تراکنش اعمال کنند تا شبکه را غیرمتمرکز نگه دارد.
-
-### {#consensus-algorithms}
-
-کانالها پروتکلهای همتا به همتای سادهای هستند که به دو طرف اجازه میدهند تا تراکنشهای زیادی را بین خود انجام دهند و سپس نتایج نهایی را به بلاک چین ارسال کنند. این کانال از رمزنگاری استفاده میکند تا نشان دهد که خلاصه دادههایی که تولید میکنند واقعاً نتیجه مجموعه معتبری از تراکنشهای میانی است. قرارداد هوشمند ["چندامضایی"](/developers/docs/smart-contracts/#multisig) تضمین میکند که تراکنشها توسط طرفهای صحیح امضا شدهاند.
-
-- []()
-- []()
--
-
-با استفاده از کانالها، تغییرات حالت توسط طرفهای ذینفع اجرا و تایید میشود و محاسبات در لایه اجرای اتریوم به حداقل میرسد. این امر باعث کاهش تراکم اتریوم و همچنین افزایش سرعت پردازش تراکنش برای کاربران میشود.
-
-#### {#block-parameters}
-
-هر کانال توسط یک [قرارداد هوشمند چندامضایی](/developers/docs/smart-contracts/#multisig) مدیریت شده که روی اتریوم اجرا میشود. برای باز کردن یک کانال، شرکت کنندگان قرارداد کانال را به صورت زنجیرهای مستقر کرده و وجوه را در آن واریز میکنند.
-
-برای بستن کانال، شرکت کنندگان آخرین وضعیت توافق شده کانال را در زنجیره ارسال میکنند. پس از آن، قرارداد هوشمند وجوه قفل شده را بر اساس موجودی هر یک از شرکت کنندگان در وضعیت نهایی کانال توزیع میکند.
-
-کانالهای همتا به همتا بهویژه برای موقعیتهایی مفید هستند که برخی از شرکتکنندگان از پیش تعریفشده میخواهند با فرکانس بالا بدون تحمیل هزینههای قابل مشاهده انجام دهند. کانالهای بلاک چین در دو دسته قرار میگیرند: **کانال های پرداخت** و **کانال های استیت یا حالت**.
-
-### {#evm-compatibility}
-
-کانال پرداخت به بهترین شکل به عنوان یک "دفتر کل دو طرفه" توصیف شده که به طور جمعی توسط دو کاربر نگهداری میشود. موجودی اولیه دفتر کل، مجموع سپردههای قفل شده در قرارداد زنجیرهای در مرحله افتتاح کانال است.
-
-بهروزرسانی موجودی دفتر کل (یعنی وضعیت کانال پرداخت) به تأیید همه طرفهای کانال نیاز دارد. بهروزرسانی کانال، که توسط همه شرکتکنندگان کانال امضا شده است، مانند تراکنش در اتریوم، نهایی شده در نظر گرفته میشود.
-
-کانالهای پرداخت یکی از اولین راهحلهای مقیاسبندی بودند که برای به حداقل رساندن فعالیت زنجیرهای گرانقیمت تعاملات ساده کاربر (مانند انتقال اتر، مبادله یا سواپ اتمی، پرداختهای خرد) طراحی شدند. شرکتکنندگان کانال میتوانند تعداد نامحدودی از تراکنشهای فوری را بین یکدیگر انجام دهند تا زمانی که مجموع خالص انتقالهای آنها از توکنهای سپردهگذاری شده بیشتر نشود.
-
-جدای از پشتیبانی از پرداختهای خارج از زنجیره، کانالهای پرداخت برای مدیریت منطق انتقال حالت عمومی مفید نیستند. کانالهای حالت برای حل این مشکل و مفید ساختن کانالها برای مقیاسپذیری محاسبات همه منظوره ایجاد شدند.
-
-### {#asset-movement}
-
-کانالهای استیت هنوز اشتراکات زیادی با کانالهای پرداخت دارند. برای مثال، کاربران با مبادله پیامهای امضا شده رمزنگاری شده (تراکنشها)، که سایر شرکتکنندگان کانال نیز باید آنها را امضا کنند، تعامل دارند. اگر یک بهروزرسانی وضعیت پیشنهادی توسط همه شرکتکنندگان امضا نشود، نامعتبر تلقی میشود.
-
-## {#pros-and-cons-of-sidechains}
-
-| | |
-| | |
-| | |
-| | |
-| | |
-| | |
-
-### {#use-sidechains}
-
-- []()
-- []()
-- []()
-- []()
-- []()
-
-## {#further-reading}
-
--
-
-_ _
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md"
deleted file mode 100644
index 0f94e7f2862..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md"
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: ولیدیوم
-description: مقدمه ای بر ولیدیوم به عنوان یک راه حل مقیاس بندی که در حال حاضر توسط انجمن اتریوم استفاده می شود.
-lang: fa
-sidebarDepth: 3
----
-
-ولیدیوم یک [راه حل مقیاسپذیری](/developers/docs/scaling/) است که یکپارچگی تراکنشها را با استفاده از اثبات اعتبار مانند [ رول آپ دانش صفر اعمال میکند](/developers/docs/scaling/zk-rollups/)، اما دادههای تراکنش را در شبکه اصلی اتریوم ذخیره نمیکند. در حالی که در دسترس بودن دادههای خارج از زنجیره باعث ایجاد مبادلات میشود، میتواند منجر به بهبودهای گسترده در مقیاس پذیری شود (ولیدیومها میتوانند ).
-
-## پیش نیازها {#prerequisites}
-
-شما باید صفحه ما را در [مقیاسسازی اتریوم](/developers/docs/scaling/) و [لایه 2](/layer-2) خوانده و درک کرده باشید.
-
-## ولیدیوم چیست؟ {#what-is-validium}
-
-ولیدیومها (Validium) راه حلهای مقیاسبندی هستند که از در دسترس بودن دادههای خارج از زنجیره و محاسبات طراحی شده برای بهبود توان عملیاتی با پردازش تراکنشهای خارج از شبکه اصلی اتریوم استفاده میکنند. مانند رول آپهای دانش صفر (ZK-rollups)، ولیدیوم[اثبات دانش صفر](/glossary/#zk-proof) را برای تأیید تراکنشهای خارج از زنجیره در اتریوم منتشر میکنند. این از انتقال حالت نامعتبر جلوگیری میکند و تضمینهای امنیتی یک زنجیره ولیدیوم را افزایش میدهد.
-
-این «اثبات اعتبار» میتواند به شکل ZK-SNARK (برهان دانش مختصر غیر تعاملی با دانش صفر) یا ZK-STARK (برهان شفاف دانش مقیاس پذیر با دانش صفر) باشد. اطلاعات بیشتر در مورد [اثبات دانش صفر](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/).
-
-وجوه متعلق به کاربران اعتباری توسط یک قرارداد هوشمند در اتریوم کنترل میشود. ولیدیومها دقیقاً مانند رول آپهای دانش صفر برداشتهای تقریباً فوری را ارائه میدهند. پس از تأیید اعتبار درخواست برداشت در شبکه اصلی، کاربران میتوانند با ارائه [مدارک Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) وجوه خود را برداشت کنند. اثبات مرکل گنجاندن تراکنش برداشت کاربر در یک دسته تراکنش تأیید شده را تأیید میکند و به قرارداد زنجیرهای اجازه میدهد تا برداشت را پردازش کند.
-
-با این حال، ممکن است وجوه کاربران ولیدیوم مسدود و برداشت محدود شود. این مورد میتواند اتفاق بیفتد اگر مدیران دسترسی داده در زنجیره ولیدیوم، دادههای حالت خارج از زنجیره را از دسترسی کاربران خارج کنند. بدون دسترسی به دادههای تراکنش، کاربران نمیتوانند اثبات مرکل مورد نیاز برای اثبات مالکیت وجوه و برداشتها را محاسبه کنند.
-
-این تفاوت اصلی بین ولیدیوم و ZK-rollupها است یعنی موقعیت آنها در طیف در دسترس بودن دادهها تفاوت دارد. هر دو راهحل به طور متفاوت به ذخیرهسازی دادهها نگاه میکنند، که پیامدهایی برای امنیت و بدون نیاز به اعتماد دارد.
-
-## ولیدیومها چگونه با اتریوم تعامل دارند؟ {#how-do-validiums-interact-with-ethereum}
-
-ولیدیومها پروتکلهای مقیاسپذیر هستند که بر روی زنجیره موجود اتریوم ساخته شدهاند. اگرچه تراکنشهای خارج از زنجیره را اجرا میکند، یک زنجیره اعتباری توسط مجموعهای از قراردادهای هوشمند مستقر در شبکه اصلی مدیریت میشود، از جمله:
-
-1. **قرارداد تأییدکننده**: قرارداد تأییدکننده اعتبار مدارک ارائه شده توسط اپراتور ولیدیوم را هنگام بهروزرسانی وضعیت تأیید میکند. این عبارت است از اثباتهای ولیدیوم که صحت تراکنشهای خارج از زنجیره را تأیید میکنند و شواهد قابلیت دسترسی دادهها که وجود دادههای تراکنش خارج از زنجیره را تأیید میکنند.
-
-2. **قرارداد اصلی**: قرارداد اصلی تعهدات دولتی (ریشههای مرکل) ارائه شده توسط تولیدکنندگان بلوک را ذخیره میکند و پس از تأیید اعتبار در زنجیره، وضعیت ولیدیوم را به روز می کند. این قرارداد همچنین سپردهها و برداشتها از زنجیره ولیدیوم را پردازش میکند.
-
-ولیدیومها همچنین برای موارد زیر به زنجیره اصلی اتریوم متکی هستند:
-
-### توافق {#settlement}
-
-تراکنشهای انجام شده بر روی یک ولیدیوم را نمیتوان به طور کامل تأیید کرد تا زمانی که زنجیره اصلی اعتبار آنها را تأیید کند. تمام معاملاتی که با ولیدیوم انجام میشوند باید در نهایت در شبکه اصلی حل و فصل شوند. همچنین بلاک چین اتریوم «ضمانتهای تسویه حساب» را برای کاربران اعتباری ارائه میکند، به این معنی که تراکنشهای خارج از زنجیره را نمیتوان پس از تعهد به روی زنجیره، معکوس یا تغییر داد.
-
-### امنیت {#security}
-
-اتریوم که به عنوان یک لایه تسویه حساب عمل میکند، اعتبار انتقال حالت در اعتبار را نیز تضمین میکند. تراکنشهای خارج از زنجیره اجرا شده در زنجیره ولیدیوم از طریق یک قرارداد هوشمند در لایه پایه اتریوم تأیید میشوند.
-
-اگر قرارداد تأییدکننده زنجیرهای، اثبات را نامعتبر بداند، معاملات رد میشوند. این بدان معناست که اپراتورها باید قبل از بهروزرسانی وضعیت ولیدیوم، شرایط اعتبار اعمال شده توسط پروتکل اتریوم را برآورده کنند.
-
-## ولیدیوم چگونه کار میکند؟ {#how-does-validium-work}
-
-### تراکنشها {#transactions}
-
-کاربران تراکنشها را به اپراتور ارسال میکنند، گرهای که مسئول اجرای تراکنشها در زنجیره ولیدیوم است. برخی از ولیدیومها ممکن است از یک اپراتور انحصاری برای اجرای زنجیره استفاده کنند یا به مکانیزم [اثبات سهام (PoS)](/developers/docs/consensus-mechanisms/pos/) برای اپراتورهای چرخشی تکیه کنند.
-
-اپراتور تراکنشها را در یک دسته جمع میکند و آن را برای اثبات به مدار اثبات میفرستد. مدار اثبات، دسته تراکنش (و سایر دادههای مربوطه) را به عنوان ورودی و خروجی میپذیرد که تأیید صحت عملیات را تأیید میکند.
-
-### ثبت تعهد حالت {#state-commitments}
-
-وضعیت اعتبار به صورت درخت مرکل با ریشه ذخیره شده در قرارداد اصلی در اتریوم هش میشود. ریشه مرکل که به عنوان ریشه حالت نیز شناخته میشود، به عنوان یک تعهد رمزنگاری به وضعیت فعلی حسابها و موجودیهای ولیدیوم عمل میکند.
-
-برای انجام یک به روز رسانی حالت، اپراتور باید یک ریشه حالت جدید (پس از اجرای تراکنشها) محاسبه کرده و آن را به قرارداد روی زنجیره ارسال کند. اگر اثبات ولیدیوم بررسی شود، حالت پیشنهادی پذیرفته میشود و ولیدیوم به ریشه حالت جدید تغییر میکند.
-
-### سپردهها و برداشتها {#deposits-and-withdrawals}
-
-کاربران با واریز اتریوم (یا هر توکن سازگار با ERC) در قرارداد روی زنجیره، وجوه را از اتریوم به ولیدیوم منتقل میکنند. این قرارداد، رویداد سپرده را به ولیدیوم خارج از زنجیره منتقل میکند، جایی که آدرس کاربر با مبلغی برابر با سپرده وی اعتبار داده میشود. اپراتور همچنین این تراکنش سپرده را در یک دسته جدید میگنجاند.
-
-برای بازگرداندن وجوه به شبکه اصلی، یک کاربر ولیدیوم تراکنش برداشت را آغاز کرده و آن را به اپراتور ارسال میکند که درخواست برداشت را تأیید کرده و آن را در یک دسته قرار میدهد. داراییهای کاربر در زنجیره ولیدیوم نیز قبل از خروج از سیستم از بین میرود. هنگامی که اثبات اعتبار مرتبط با دسته تأیید شد، کاربر میتواند با قرارداد اصلی تماس بگیرد تا باقی مانده سپرده اولیه خود را برداشت کند.
-
-به عنوان یک مکانیزم ضد سانسور، پروتکل ولیدیوم به کاربران اجازه میدهد تا مستقیماً از قرارداد ولیدیوم بدون مراجعه به اپراتور خارج شوند. در این مورد، کاربران باید مدرک مرکل را به قرارداد تأییدکننده ارائه دهند که نشان دهنده گنجاندن یک حساب در ریشه حالت باشد. در صورت پذیرفته شدن مدرک، کاربر میتواند تابع برداشت قرارداد اصلی را فراخوانی کرده تا وجوه خود را از ولیدیوم خارج کند.
-
-### ارسال دستهای {#batch-submission}
-
-پس از اجرای دستهای از تراکنشها، اپراتور اثبات اعتبار مرتبط را به قرارداد تأیید کننده ارائه میکند و یک ریشه حالت جدید را برای قرارداد اصلی پیشنهاد میکند. اگر اثبات معتبر باشد، قرارداد اصلی وضعیت ولیدیوم را به روز کرده و نتایج تراکنشها را در دسته نهایی میکند.
-
-برخلاف رول آپهای دانش صفر، تولیدکنندگان بلوک در یک ولیدیوم نیازی به انتشار دادههای تراکنش برای دستههای تراکنش ندارند (فقط سرهای بلوک). این مورد باعث میشود ولیدیوم یک پروتکل مقیاسپذیری صرفاً خارج از زنجیره باشد، برخلاف پروتکلهای مقیاسبندی «هیبریدی» (یعنی [لایه 2](/layer-2/)) که دادههای وضعیت را در زنجیره اصلی اتریوم به عنوان `کال دیتا` منتشر میکند.
-
-### دسترسی به دادهها {#data-availability}
-
-همانطور که گفته شد، ولیدیومها از یک مدل قابلیت دسترسی داده خارج از زنجیره استفاده میکنند، که در آن اپراتورها تمام دادههای تراکنش را از شبکه اصلی اتریوم ذخیره میکنند. ردپای کم دادههای زنجیرهای ولیدیوم مقیاسپذیری را بهبود میبخشد (خروجی توسط ظرفیت پردازش دادههای اتریوم محدود نمیشود) و هزینههای کاربر را کاهش میدهد (هزینه انتشار `کال دیتا` کمتر است).
-
-با این حال، در دسترس بودن دادههای خارج از زنجیره مشکلی را ایجاد میکند: ممکن است دادههای لازم برای ایجاد یا تأیید مدارک مرکل در دسترس نباشد. این بدان معنی است که اگر اپراتورها بدخواهانه عمل کنند، ممکن است کاربران نتوانند وجوه خود را از قرارداد زنجیرهای برداشت کنند.
-
-راهحلهای مختلف ولیدیوم سعی میکنند این مشکل را با غیرمتمرکز کردن ذخیرهسازی دادههای حالت حل کنند. این مورد شامل مجبور کردن تولیدکنندگان بلوک برای ارسال دادههای اساسی به "مدیران دسترسی داده" است که مسئول ذخیره دادههای خارج از زنجیره هستند و در صورت درخواست در دسترس کاربران قرار میگیرند.
-
-مدیران دسترسی دادهها در ولیدیوم، با امضای هر دسته اعتباری، در دسترس بودن دادهها را برای تراکنشهای خارج از زنجیره تأیید میکنند. این امضاها شکلی از «اثبات قابلیت دسترسی» را تشکیل میدهند که قرارداد تأییدکننده زنجیرهای، قبل از تأیید بهروزرسانیهای حالت بررسی میکند.
-
-ولیدیومها در رویکردشان به مدیریت قابلیت دسترسی دادهها متفاوت هستند. برخی برای ذخیره دادههای وضعیت به اشخاص مورد اعتماد متکی هستند، در حالی که برخی دیگر از اعتبارسنجهای اختصاص داده شده به طور تصادفی برای این کار استفاده میکنند.
-
-#### کمیته قابلیت دسترسی دادهها (DAC) {#data-availability-committee}
-
-برای تضمین قابلیت دسترسی دادههای خارج از زنجیره، برخی راهحلهای ولیدیوم گروهی از نهادهای مورد اعتماد را که در مجموع به عنوان کمیته قابلیت دسترسی دادهها (DAC) شناخته میشوند، منصوب میکنند تا کپیهایی از حالت را ذخیره و مدرکی دال بر در دسترس بودن داده ارائه کنند. اجرای DAC آسانتر است و به هماهنگی کمتری نیاز دارد زیرا عضویت پایین است.
-
-با این حال، کاربران باید به DAC اعتماد کنند تا دادهها را در صورت نیاز در دسترس قرار دهد (به عنوان مثال، برای تولید اثباتهای مرکل). این امکان وجود دارد که اعضای کمیتههای دسترسی داده [توسط یک عامل مخرب](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view) در معرض خطر قرار گیرند که میتواند دادههای خارج از زنجیره را مخفی کند.
-
-[اطلاعات بیشتر در مورد کمیتههای دسترسی داده در ولیدیوم](https://medium.com/starkware/data-availability-e5564c416424).
-
-#### در دسترس بودن دادههای مسیر {#bonded-data-availability}
-
-سایر ولیدیومها، شرکتکنندگانی را ملزم میکنند که دادههای آفلاین را ذخیره کنند تا توکنها را در یک قرارداد هوشمند به اشتراک بگذارند (یعنی قفل کنند) قبل از اینکه نقش خود را به عهده بگیرند. این سهام به عنوان یک "مسیر" برای تضمین رفتار صادقانه در میان مدیران در دسترس بودن دادهها عمل میکند و مفروضات اعتماد را کاهش میدهد. اگر این شرکت کنندگان نتوانند در دسترس بودن دادهها را اثبات کنند، مسیر مجازات میشود.
-
-در یک طرح در دسترس بودن دادههای مسیر، هر کس میتواند پس از ارائه سهام گذاری مورد نیاز، به نگهداری دادههای خارج از زنجیره اختصاص یابد. این امر مجموعه مدیران در دسترس بودن دادههای واجد شرایط را گسترش میدهد و تمرکزی را که بر کمیتههای در دسترس بودن دادهها (DAC) تأثیر میگذارد، کاهش میدهد. مهمتر از آن، این رویکرد برای جلوگیری از فعالیتهای مخرب بر انگیزههای اقتصاد رمزارزی تکیه میکند، که به طور قابل توجه ایمنتر از انتصاب اشخاص مورد اعتماد برای ایمنسازی دادههای آفلاین در ولیدیوم است.
-
-[اطلاعات بیشتر در مورد در دسترس بودن دادههای مسیر درولیدیومها](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf).
-
-## اراده و ولیدیوم {#volitions-and-validium}
-
-ولیدیومها مزایای زیادی را ارائه میدهند اما با معاوضههایی همراه هستند (به ویژه در دسترس بودن دادهها). اما، مانند بسیاری از راهحلهای مقیاسپذیری، ولیدیومها برای موارد استفاده خاص مناسب هستند - به همین دلیل است که اراده ها ایجاد شدند.
-
-اراده ها یک زنجیره رولآپ ZK و ولیدیوم را ترکیب میکند و به کاربران اجازه میدهد بین دو راه حل مقیاسپذیری جابجا شوند. با ارادهها، کاربران میتوانند از در دسترس بودن دادههای خارج از زنجیره ولیدیوم برای تراکنشهای خاص استفاده کنند، در حالی که آزادی تغییر به راهحل در دسترس بودن داده روی زنجیره (ZK-rollup) را در صورت نیاز حفظ میکنند. این مورد اساساً به کاربران این آزادی را میدهد که مطابق با شرایط منحصر به فرد خود، مبادلاتی را انتخاب کنند.
-
-یک صرافی غیرمتمرکز (DEX) ممکن است استفاده از زیرساخت مقیاسپذیر و خصوصی ولیدیوم را برای معاملات با ارزش ترجیح دهد. همچنین میتواند از ZK-rollup برای کاربرانی استفاده کند که ضمانتهای امنیتی بالاتر و بدون نیاز به اعتماد بودن ZK-rollup را میخواهند.
-
-## سازگاری ولیدیوم و ماشین مجازی اتریوم {#validiums-and-evm-compatibility}
-
-مانند ZK-rollups، اعتبارسنجها بیشتر برای برنامههای کاربردی ساده، مانند مبادله توکن و پرداخت مناسب هستند. پشتیبانی از محاسبات عمومی و اجرای قراردادهای هوشمند در میان ولیدیومها، با توجه به میزان قابلتوجه اثبات دستورالعملهای [EVM](/developers/docs/evm/) در مدار اثبات دانش صفر، دشوار است.
-
-برخی از پروژههای ولیدیوم سعی میکنند با کامپایل کردن زبانهای سازگار با EVM (مانند سالیدیتی، وایپر) برای ایجاد بایت کد سفارشی بهینهسازی شده برای اثبات کارآمد، از این مشکل دوری کنند. یک اشکال این رویکرد این است که VMهای جدید و سازگار با دانش صفر ممکن است از کدهای عملیاتی مهم EVM پشتیبانی نکنند و توسعه دهندگان برای تجربه بهینه باید مستقیماً به زبان سطح بالا بنویسند. این مورد حتی مشکلات بیشتری ایجاد میکند: توسعهدهندگان را مجبور میکند تا Dappهایی را با یک پشته یا استک توسعه کاملاً جدید و سازگاری توقفها با زیرساخت فعلی اتریوم را بسازند.
-
-با این حال، برخی از تیمها در تلاش هستند تا کدهای عملیاتی EVM موجود را برای مدارهای اثبات ZK بهینه کنند. این مورد منجر به توسعه یک ماشین مجازی اتریوم (zkEVM) با دانش صفر میشود، یک ماشین مجازی سازگار با EVM که شواهدی را برای تأیید صحت اجرای برنامه تولید میکند. با zkEVM، زنجیرههای ولیدیوم میتوانند قراردادهای هوشمند را خارج از زنجیره اجرا کنند و مدارک ولیدیوم را برای تأیید محاسبات خارج از زنجیره (بدون نیاز به اجرای مجدد آن) در اتریوم ارسال کنند.
-
-[اطلاعات بیشتر در مورد zkEVMها](https://www.alchemy.com/overviews/zkevm).
-
-## ولیدیومها چگونه اتریوم را مقیاسپذیر میکنند؟ {#scaling-ethereum-with-validiums}
-
-### 1. ذخیرهسازی دادهها خارج از زنجیره {#off-chain-data-storage}
-
-پروژههای مقیاسپذیری لایه ۲، مانند آپتیمیستیک رول آپ و رول آپهای ZK، مقیاسپذیری بینهایت پروتکلهای مقیاسپذیری خالص خارج از زنجیره را معامله میکنند (به عنوان مثال، [پلاسما](/developers/docs/scaling/plasma/)) برای امنیت با انتشار برخی از دادههای تراکنش در لایه 1 یکی از این موارد است. اما این بدان معناست که ویژگیهای مقیاسپذیری جمعآوریها توسط پهنای باند داده در شبکه اصلی اتریوم محدود میشود ([شاردینگ دادهها](/roadmap/danksharding/) به این دلیل پیشنهاد میکند ظرفیت ذخیرهسازی دادههای اتریوم را بهبود بخشد).
-
-ولیدیومها با نگه داشتن تمام دادههای تراکنش خارج از زنجیره و تنها تعهدات پس از وضعیت (و اثبات اعتبار) در هنگام انتقال به روزرسانیهای حالت به زنجیره اصلی اتریوم، به مقیاس پذیری دست مییابند. با این حال، وجود اثباتهای اعتبار، تضمینهای امنیتی بالاتری را نسبت به سایر راهحلهای مقیاسپذیری خالص خارج از زنجیره، از جمله پلاسما و [زنجیرههای جانبی](/developers/docs/scaling/sidechains/) ارائه میدهد. با کاهش حجم دادههایی که اتریوم باید قبل از اعتبارسنجی تراکنشهای خارج از زنجیره پردازش کند، طرحهای ولیدیوم تا حد زیادی توان عملیاتی شبکه اصلی را افزایش میدهند.
-
-### 2. اثبات های بازگشتی {#recursive-proofs}
-
-اثبات بازگشتی، اثبات اعتباری است که اعتبار ادله دیگر را تأیید میکند. این «اثباتها» با تجمیع چندگانه به صورت بازگشتی ایجاد میشوند تا زمانی که یک اثبات نهایی تأییدکننده همه اثبات های قبلی ایجاد شود. اثبات بازگشتی، سرعت پردازش بلاک چین را با افزایش تعداد تراکنشهایی که میتوان به ازای اثبات اعتبار تأیید کرد، افزایش میدهد.
-
-به طور معمول، هر مدرک اعتباری که اپراتور اعتبار برای تأیید به اتریوم ارسال میکند، یکپارچگی یک بلوک واحد را نیز تأیید میکند. در حالی که یک اثبات بازگشتی منفرد میتواند برای تأیید اعتبار چندین بلوک ولیدیوم به طور همزمان استفاده شود - این امکان وجود دارد زیرا مدار اثبات میتواند به صورت بازگشتی چندین اثبات بلوک را در یک اثبات نهایی جمع کند. اگر قرارداد تأییدکننده روی زنجیره، اثبات بازگشتی را بپذیرد، تمام بلوکهای زیربنایی بلافاصله نهایی میشوند.
-
-## جوانب مثبت و منفی ولیدیوم {#pros-and-cons-of-validium}
-
-| مزایا | معایب |
-| ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
-| اثبات اعتبار، یکپارچگی تراکنشهای خارج از زنجیره را اعمال کرده و از نهایی کردن بهروزرسانیهای وضعیت نامعتبر توسط اپراتورها جلوگیری میکند. | تولید اثبات اعتبار نیاز به سختافزار خاصی دارد که خطر تمرکز را به همراه دارد. |
-| کارایی سرمایه را برای کاربران افزایش میدهد (بدون تاخیر در برداشت وجه به اتریوم) | پشتیبانی محدود برای محاسبات عمومی/قراردادهای هوشمند؛ زبانهای تخصصی برای توسعه لازم هستند. |
-| در برابر حملات اقتصادی خاصی که سیستمهای مبتنی بر تقلب در برنامههای کاربردی با ارزش بالا با آنها مواجه میشوند، آسیبپذیر نیست. | قدرت محاسباتی بالا مورد نیاز برای تولید اثبات ZK؛ برای برنامههای کاربردی کم توان مقرون به صرفه نیست. |
-| با ارسال نکردن کال دیتا به شبکه اصلی اتریوم، هزینههای گس را برای کاربران کاهش میدهد. | زمان نهاییسازی کندتر (10-30 دقیقه برای ایجاد اثبات ZK) اما سریعتر در نهایی شدن کامل زیرا تاخیر زمانی اختلاف وجود ندارد. |
-| مناسب برای موارد استفاده خاص، مانند معامله یا بازیهای بلاک چین که حریم خصوصی تراکنشها و مقیاسپذیری را در اولویت قرار میدهند. | میتوان از برداشت وجه توسط کاربران جلوگیری کرد، زیرا برای ایجاد مدارک مالکیت مرکل نیاز است که دادههای خارج از زنجیره همیشه در دسترس باشد. |
-| در دسترس بودن دادههای خارج از زنجیره سطوح بالاتری از توان عملیاتی را فراهم میکند و مقیاسپذیری را افزایش میدهد. | مدل امنیتی بر فرضیات اعتماد و انگیزههای ارز دیجیتال متکی است، برخلاف ZK-rollupها، که صرفاً بر مکانیزمهای امنیتی رمزنگاری متکی هستند. |
-
-### از ولیدیوم/ارادهها استفاده کنید {#use-validium-and-volitions}
-
-پروژههای متعدد پیادهسازیهایی از ولیدیوم و ارادهها را ارائه میدهند که میتوانید آنها را در dappهای خود ادغام کنید:
-
-**StarkWare StarkEx** - _StarkEx یک راه حل مقیاسپذیری لایه 2 اتریوم (L2) است که بر اساس اثبات اعتبار است. میتواند در حالتهای دسترسی به داده ZK-Rollup یا ولیدیوم کار کند._
-
-- [مستندات](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium)
-- [وب سایت](https://starkware.co/starkex/)
-
-**Matter Labs zkPorter**- _zkPorter یک پروتکل مقیاسپذیری لایه 2 است که در دسترس بودن دادهها را با رویکرد ترکیبی ترکیب میکند که ایدههای zkRollup و شاردینگ را با هم ترکیب کند. میتواند بهطور دلخواه بسیاری از شاردها را پشتیبانی کند که هر کدام خطمشی در دسترس بودن دادههای خاص خود را دارند._
-
-- [بلاگ](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf)
-- [مستندات](https://docs.zksync.io/zk-stack/concepts/data-availability)
-- [وب سایت](https://zksync.io/)
-
-## بیشتر بخوانید {#further-reading}
-
-- [شماره Validium And The Layer 2 Two-By-Two — 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two)
-- [ZK-rollupها در مقابل ولیدیوم](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)
-- [اراده و طیف در دسترس بودن دادههای در حال ترکیب](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb)
-- [رول آپها، ولیدیومها و اراده ها: درباره داغترین راه حلهای مقیاس پذیری اتریوم بیاموزید](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions)
diff --git "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" "b/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md"
deleted file mode 100644
index 806f8004636..00000000000
--- "a/public/content/translations/fa/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md"
+++ /dev/null
@@ -1,259 +0,0 @@
----
-title: رولآپهای دانش-صفر
-description: مقدمه ای بر رولآپ های دانش-صفر، یک راه حل مقیاس پذیری که توسط جامعه اتریوم استفاده میشود.
-lang: fa
----
-
-رولآپ های دانش-صفر (ZK-rollups)، [راهحلهای مقیاسپذیری](/developers/docs/scaling/) لایه دوم هستند که با جابجایی محاسبات و حالت ذخیرهسازی به خارج از زنجیره اتریوم، توان عملیاتی را در شبکه اصلی اتریوم افزایش میدهند. رولآپ های دانش-صفر میتوانند هزاران تراکنش را به صورت دستهای پردازش کنند و سپس تنها خلاصهای فشرده از دادهها را به شبکه اصلی اتریوم ارسال کنند. این خلاصهی فشرده دادهها، تغییراتی را که باید در حالت اتریوم شکل بگیرد و چند اثبات رمزنگاری که درست بودن آن تغییرات را ثابت میکند، تعریف میکند.
-
-## موارد مورد نیاز {#prerequisites}
-
-شما باید صفحه ما را در [مقیاسسازی اتریوم](/developers/docs/scaling/) و [لایه 2](/layer-2) خوانده و درک کرده باشید.
-
-## رولآپ دانش-صفر چیست؟ {#what-are-zk-rollups}
-
-**رولآپ های دانش-صفر (ZK-rollups)**، دسته های تراکنشهایی (یا همان رولآپهایی) را که خارج از زنجیره اجرا میشوند را یک دسته میکنند. محاسبات خارج از زنجیره، مقدار دادهای که باید به بلاک چین ارسال شود را کاهش میدهد. اپراتورهای رولآپ های دانش-صفر، خلاصهای را از تغییرات مورد نیاز برای نمایش تمام تراکنشها در یک دسته را به جای ارسال هر تراکنش به صورت جداگانه، میفرستند. آنها همچنین [اثبات اعتبار](/glossary/#validity-proof) را برای اثبات درستی تغییرات خود تولید می کنند.
-
-حالت رولآپ دانش-صفر توسط یک قرارداد هوشمند مستقر در شبکه اتریوم ذخیره و مدیریت می شود. برای بهروزرسانی این حالت، گرههای رولآپ دانش-صفر باید یک اثبات ادعا را برای تأیید ارسال کنند. همانطور که ذکر شد، اثبات ادعا یک تضمین رمزنگاری میباشد که اطمینان میدهد تغییر حالت پیشنهادی توسط رولآپ واقعاً نتیجه اجرای همان دسته از تراکنشهای مربوطه است. این بدان معناست که رولآپ های دانش-صفر به جای پست کردن تمام دادههای تراکنش در زنجیره مانند [رولآپ های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)، تنها به ارائه اثبات ادعا برای نهایی کردن تراکنشها در اتریوم نیاز دارند.
-
-هیچ تاخیری در انتقال وجوه از رولآپ دانش-صفر به اتریوم وجود ندارد، زیرا تراکنش های خروج پس از تائید اعتبار اثبات ادعا توسط قرارداد رولآپ دانش-صفر، انجام می شوند. اما در عوض، برداشت وجوه از رولآپ های خوشبینانه با تأخیر احتمالی همراه است تا هر کسی بتواند تراکنش خروج را با [اثبات تقلب](/glossary/#fraud-proof) به چالش بکشد.
-
-رولآپ های دانش-صفر تراکنش ها را در قالب `calldata` به اتریوم می نویسند. `calldata` محلی است که دادههایی که با فراخوانهای خارجی به توابع قرارداد هوشمند همراه هستند، ذخیره میشوند. اطلاعات موجود در `calldata` در بلاکچین منتشر میشود و به هر کسی اجازه میدهد تا حالت رولآپ را بهطور مستقل بازسازی کند. رولآپ های دانش-صفر از تکنیکهای فشردهسازی برای کاهش دادههای تراکنش استفاده میکنند - برای مثال، حسابها به جای یک آدرس، با یک ایندکس نشان داده میشوند که مصرف ۲۸ بایت داده را کاهش میدهد. انتشار دادهها برو روی شبکه اصلی، هزینه قابل توجهی را برای رولآپها دارد بنابراین فشردهسازی دادهها میتواند هزینهها را برای کاربران کاهش دهد.
-
-## رولآپ های دانش-صفر چگونه با اتریوم تعامل دارند؟ {#zk-rollups-and-ethereum}
-
-زنجیره رولآپ دانش-صفر، یک پروتکل خارج از زنجیره است که در لایه بالایی بلاکچین اتریوم عمل میکند و توسط قراردادهای هوشمند اتریوم روی زنجیره اصلی اتریوم مدیریت می شود. رولآپ های دانش-صفر، تراکنشها را خارج از شبکه اصلی اجرا میکنند، اما بهطور دورهای دستههای تراکنشهای خارج از زنجیره را به یک قرارداد رولآپ مستقر در شبکه اصلی اتریوم متعهد میکنند. این ثبت تراکنش مانند بلاکچین اتریوم تغییر ناپذیر میباشد و زنجیره رولآپ دانش-صفر را تشکیل می دهد.
-
-هسته اصلی رولآپ دانش-صفر از اجزای زیر تشکیل شده است:
-
-1. **قراردادهای هوشمند مستقر در شبکه اتریوم**: همانطور که گفته شد، پروتکل رولآپ دانش-صفر توسط قراردادهای هوشمند در حال اجرا بر روی اتریوم کنترل می شود. این شامل قرارداد اصلی است که بلوکهای رولآپ را ذخیره میکند، سپردهها را ردیابی میکند و بهروزرسانیهای حالت را نظارت میکند. یکی دیگر از قراردادهای مستقر در شبکه اتریوم (قرارداد تأیید کننده) ادعاهای دانش صفر ارائه شده توسط تولیدکنندگان بلوک را تائید می کند. بنابراین، اتریوم به عنوان لایه پایه یا "لایه اول" برای رولآپ دانش-صفر عمل می کند.
-
-2. **ماشین مجازی خارج از زنجیره (VM)**: گرچه که پروتکل رولآپ دانش-صفر در اتریوم در حال اجراست، اجرای تراکنش و ذخیرهسازی حالت در یک ماشین مجازی جداگانه مستقل از [ EVM](/developers/docs/evm/) انجام میشود. این ماشین مجازی یا VM خارج از زنجیره، محیط اجرا برای تراکنشهای رولآپ دانش-صفر است و به عنوان لایه ثانویه یا "لایه دوم" برای پروتکل رولآپ دانش-صفر عمل میکند. اثبات ادعاهایی که در شبکه اتریوم تائید شدهاند، درست بودن انتقال حالت را در ماشین مجازی خارج از زنجیره تضمین می کند.
-
-رولآپ های دانش-صفر "راهحلهای مقیاسپذیری ترکیبی" هستند - پروتکلهای خارج از زنجیره که به طور مستقل عمل میکنند اما امنیت را از اتریوم میگیرند. به خصوص شبکه اتریوم اعتبار بهروزرسانیهای حالت را در رولآپ دانش-صفر اعمال میکند و در دسترس بودن دادهها در حالت رولآپ را پس از هر بهروزرسانی، تضمین میکند. در نتیجه، رولآپ های دانش-صفر بهطور قابلتوجهی امنتر از راهحلهای مقیاسپذیری کاملاً خارج از زنجیره هستند، مانند [زنجیرههای جانبی](/developers/docs/scaling/sidechains/)، که خودشان مسئول ویژگیهای امنیتی خودشان هستند، یا [ولیدیومها](/developers/docs/scaling/validium/) که همچنین تأیید میکنند تراکنشهای روی اتریوم با اثبات ادعاها انجام میشود، اما دادههای تراکنش در جای دیگری ذخیره میشوند.
-
-رولآپ های دانش-صفر برای موارد زیر به پروتکل اصلی اتریوم متکی هستند:
-
-### دسترسی به دادهها {#data-availability}
-
-رولآپ دانش-صفر، دادههای حالت را برای هر تراکنش پردازش شده خارج از زنجیره به اتریوم منتشر میکنند. با این دادهها، افراد یا کسبوکارها میتوانند حالت رولآپ را بازتولید نمایند و خودشان زنجیره را تائید کنند. اتریوم این داده ها را در قالب `calldata` در اختیار همه استفاده کنندگان و شرکت کنندگان شبکه قرار می دهد.
-
-رولآپ های دانش-صفر نیازی به انتشار دادههای تراکنش زیادی روی زنجیره اصلی ندارند، زیرا اثباتهای ادعا قبلاً صحت انتقال حالت را تأیید کرده اند. با این وجود، ذخیره دادهها در زنجیره اصلی اتریوم همچنان مهم است زیرا امکان تائید بدون اجازه و مستقل وضعیت زنجیره لایه دوم را میدهد که به نوبه خود به هر کسی اجازه میدهد دستهای از تراکنشها را ارسال کند و از سانسور یا مسدود کردن زنجیره توسط اپراتورهای بد اندیش جلوگیری میکند.
-
-تعامل کاربران بر روی شبکه اصلی با رولآپ الزامی است. کاربران بدون دسترسی به دادههای ایالتی نمیتوانند موجودی حساب خود را درخواست کنند یا تراکنشهایی (مانند برداشتها) را که به اطلاعات حالت متکی هستند، آغاز کنند.
-
-### نهائی شدن تراکنش {#transaction-finality}
-
-اتریوم به عنوان یک لایه توافق برای رولآپ های دانش-صفر عمل می کند: تراکنش های لایه 2 تنها در صورتی نهایی می شوند که قرارداد لایه 2، اثبات ادعا را بپذیرد. این کار خطر دستکاری کردن زنجیره توسط اپراتورهای مخرب (به عنوان مثال، سرقت وجوه موجود در رولآپ) را از بین میبرد زیرا هر تراکنش باید در شبکه اصلی اتریوم تائید شود. همچنین، اتریوم تضمین میکند که پس از نهائی شدن در لایه اصلی، عملیات انجام شده توسط کاربر، نمیتواند معکوس شود.
-
-### مقاومت در برابر سانسور {#censorship-resistance}
-
-اکثر رولآپ های دانش-صفر از یک "ابر گره" (اپراتور) برای اجرای تراکنش ها، تولید دسته ها و ارسال بلوکها به لایه اصلی اتریوم استفاده میکنند. در حالی که این امر کارائی را تضمین میکند، اما خطر سانسور را افزایش میدهد: اپراتورهای مخرب رولآپ دانش-صفر میتوانند با امتناع از گنجاندن تراکنشهای کاربران در دسته تراکنشها، آنها را سانسور کنند.
-
-به عنوان یک ملاحظه امنیتی، رولآپ دانش-صفر به کاربران این امکان را میدهد که اگر فکر میکنند تراکنشها توسط اپراتور سانسور میشوند، خودشان مستقیماً آن را به قرارداد رولآپ در شبکه اتریوم ارسال نمایند. این به کاربران اجازه میدهد بدون اتکا به اجازه اپراتور، از رولآپ دانش-صفر به اتریوم خارج شوند.
-
-## طرز کار رولآپ دانش-صفر چگونه است؟ {#how-do-zk-rollups-work}
-
-### تراکنشها {#transactions}
-
-کاربران در رولآپ دانش-صفر تراکنش ها را امضا می کنند و برای پردازش و گنجاندن در دسته ارسالی بعدی به اپراتورهای لایه دوم میفرستند. در برخی موارد، اپراتور یک نهاد متمرکز به نام ترتیبدهنده است که تراکنشها را اجرا میکند، آنها را در دسته تراکنشها گردآوری میکند و به لایه اصلی ارسال میکند. ترتیبدهنده در این سیستم تنها نهادی است که مجاز به تولید بلوکهای لایه دوم و افزودن تراکنشهای رولآپ به قرارداد هوشمند رولآپ دانش-صفر است.
-
-سایر رولآپ های دانش-صفر ممکن است نقش اپراتور را با استفاده از مجموعه اطلاعات اعتبارسنجی [اثبات سهام](/developers/docs/consensus-mechanisms/pos/) با یکدیگر تعویض کنند. اپراتورهای احتمالی وجوهی را به قرارداد رولآپ واریز میکنند که اندازه هر سهم در شانس انتخاب شدن سهامداران برای تولید دسته بعدی تأثیر میگذارد. اگر اپراتور بدخواهانه عمل کند، میتوان سهام اپراتور را بعنوان جریمه، قاچ کرد یا اصطلاحاً slashing کرد، که این امر آنها را تشویق میکند تا بلوکهای معتبر را ارسال کنند.
-
-#### نحوه انتشار دادههای تراکنش در اتریوم توسط رولآپ های دانش-صفر {#how-zk-rollups-publish-transaction-data-on-ethereum}
-
-همانطور که توضیح داده شد، دادههای تراکنش در اتریوم به شکل `calldata` منتشر می شوند. `calldata` محلی در یک قرارداد هوشمند است که برای ارسال پارامترهای ورودی به یک تابع استفاده میشود و رفتاری مشابه با [حافظه مموری](/developers/docs/smart-contracts/anatomy/#memory) دارد. در حالی که `calldata` بهعنوان بخشی از حالت اتریوم ذخیره نمیشود، در زنجیره اتریوم به عنوان بخشی از [گزارشهای تاریخچه](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) زنجیره اتریوم باقی خواهد ماند. `calldata` بر حالت اتریوم تأثیری نمیگذارد و آن را به راهی ارزان برای ذخیره دادهها در شبکه اتریوم تبدیل میکند.
-
-کلمه کلیدی `calldata` معمولاً تابعی از قرارداد هوشمند را که توسط یک تراکنش فراخوانی میشود، شناسایی میکند و ورودیهای تابع را در قالب یک دنباله دلخواه از بایتها نگه میدارد و به آن وارد میکند. رولآپ دانش-صفر از `calldata` برای انتشار دادههای فشرده تراکنش، در زنجیره استفاده میکنند. اپراتور رولآپ به سادگی با فراخوانی تابع مورد نیاز در قرارداد رولآپ یک دسته جدید اضافه میکند و دادههای فشرده شده را به عنوان پارامترهای ورودی تابع ارسال میکند. این به کاهش هزینهها برای کاربران کمک میکند، زیرا بخش بزرگی از هزینههای رولآپ صرف ذخیره دادههای تراکنش در شبکه اتریوم میشود.
-
-### ثبت تعهد حالت {#state-commitments}
-
-حالت رولآپ دانش-صفر که شامل حسابها و موجودیهای لایه دوم میشود، در قالب [درخت مرکل](/whitepaper/#merkle-trees) نمایش داده میشود. یک هش رمزنگاری از ریشه درخت مرکل (ریشه مرکل) در قرارداد مستقر در زنجیره اتریوم ذخیره میشود و به پروتکل رولآپ اجازه میدهد تا تغییرات در حالت رولآپ دانش-صفر را ردیابی کند.
-
-پس از اجرای مجموعهای از تراکنشهای جدید، رولآپ به حالت جدید تغییر خواهد کرد. اپراتوری که تغییر حالت را آغاز کرده است باید یک ریشه حالت جدید را محاسبه کرده و به قرارداد مستقر در زنجیره اتریوم ارسال کند. اگر اثبات ادعا مرتبط با دسته توسط قرارداد تأیید کننده، تأیید شود، ریشه مرکل جدید به ریشه کانونی حالت رولآپ دانش-صفر تبدیل می شود.
-
-علاوه بر محاسبه ریشه های حالت، اپراتور رولآپ دانش-صفر همچنین یک ریشه دسته ایجاد می کند - یک ریشه مرکل که شامل تمام تراکنشهای داخل یک دسته است. وقتی که یک دسته جدید ارسال می شود، قرارداد رولآپ ریشه دسته را ذخیره می کند و به کاربران امکان می دهد ثابت کنند که یک تراکنش (به عنوان مثال، درخواست برداشت) در دسته گنجانده شده است. کاربران باید جزئیات تراکنش، ریشهی دسته و یک [اثبات مرکل](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) را ارائه کنند که مسیر محلی که در آنجا شامل شدهاند را نشان می دهد.
-
-### اثباتهای ادعا {#validity-proofs}
-
-ریشه حالت جدیدی که اپراتور رولآپ دانش-صفر به قرارداد زنجیره اصلی اتریوم ارائه میکند، نتیجه بهروز شدن حالت رولآپ است. فرض کنید آلیس 10 توکن برای باب می فرستد، اپراتور به سادگی موجودی آلیس را به مقدار 10 واحد کاهش می دهد و موجودی باب را به مقدار 10 واحد افزایش می دهد. اپراتور سپس دادههای حساب بهروز شده را هش میکند، درخت مرکل مجموعه را بازسازی میکند و ریشه مرکل جدید را به قرارداد روی زنجیره ارسال میکند.
-
-اما تا زمانی که اپراتور ثابت نکند که ریشه مرکل جدید از بهروزرسانیهای صحیح حالت رولآپ منشأ گرفته است، قرارداد رولآپ بهطور خودکار تعهد حالت پیشنهادی را نخواهد پذیرفت. اپراتور رولآپ دانش-صفر، این کار را با ارائه یک اثبات یا گواهی ادعا، که یک تعهد رمزنگاری مختصر است که صحت تراکنشهای دستهای را تأیید میکند، انجام میدهد.
-
-گواهی ادعا به طرفین اجازه می دهد تا صحت یک گزاره را بدون افشای خود گزاره اثبات کنند - از این رو، آنها را اثبات های دانش صفر نیز مینامند. رولآپ های دانش-صفر از گواهی ادعا برای تائید صحت انتقال حالت های رخ داده خارج از زنجیره، بدون نیاز به اجرای مجدد تراکنشها در اتریوم استفاده میکنند. این گواهیها میتوانند در قالب [ZK-SNARK (اسنارک دانش-صفر)](https://arxiv.org/abs/2202.06877) (معادل حروف اول استدلال غیر تعاملی مختصر دانش صفر به انگلیسی) یا [استارک دانش-صفر یا ZK-STARK](https://eprint.iacr.org/2018/046) (معادل حروف ابتدای استدلال شفاف مقیاسپذیر دانش صفر به انگلیسی) باشند.
-
-هم SNARKها و هم STARKها به اثبات یکپارچگی محاسبات خارج از زنجیره در رولآپ های دانش-صفر کمک می کنند، اگرچه که هر نوع گواهی، ویژگی های متمایزی با نوع دیگر گواهی دارد.
-
-**اسنارکهای دانش-صفر**
-
-برای کارکرد پروتکل ZK-SNARK یا همان اسنارکهای دانش-صفر، ایجاد یک رشته مرجع مشترک (CRS) ضروری است: CRS پارامترهای عمومی را برای اثبات و تأیید گواهی ادعا ارائه می کند. امنیت سیستم اثبات بستگی به تنظیمات و ساختار CRS دارد. اگر اطلاعات مورد استفاده برای ایجاد پارامترهای عمومی در اختیار عوامل مخرب قرار گیرد، ممکن است بتوانند گواهیهای ادعا نادرست تولید کنند.
-
-برخی از رولآپ های دانش-صفر سعی میکنند این مشکل را با استفاده از [مراسم محاسباتی چند حزبی (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) که شامل افراد مورد اعتماد، برای تولید پارامترهای عمومی برای مدار ZK-SNARK میشود، حل کنند. هر یک از طرفین مقداری تصادفی (به نام "ضایعات سمی") در ساخت CRS مشارکت می دهند که باید فوراً آن را از بین ببرند.
-
-به این دلیل از افراد مورد اعتماد و تنظیمات مطمئن استفاده می شود چون امنیت ساختار CRS را افزایش می دهند. تا زمانی که فقط یک دست اندرکار صادق و مورد اعتماد، ورودی خود را از بین ببرد، امنیت سیستم ZK-SNARK تضمین می شود. اما همچنان این رویکرد مستلزم اعتماد به دست اندرکاران برای حذف تصادفی نمونه آنها و عدم تضعیف تضمینهای امنیتی سیستم است.
-
-مفروضات اعتماد به کنار، اسنارکهای دانش-صفر به دلیل اندازههای اثبات کوچک و تأیید در بازه زمانی ثابت بدون درنظر گرفتن اندازه ورودیها، دارای محبوبیت زیادی هستند. از آنجایی که اثبات ادعا در زنجیره اصلی بیشتر هزینهها را برای اجرای یک اسنارکهای دانش-صفر تشکیل می دهد، لایه دو ها از اسنارکها برای تولید اثباتهایی استفاده می کنند که می توانند به سرعت و ارزان در شبکه اصلی اتریوم تائید شوند.
-
-**استارکهای دانش-صفر**
-
-همانند اسنارکها (ZK-SNARKs)، استارکها (ZK-STARKs) نیز معتبر بودن محاسبات خارج از زنجیره را بدون آشکار کردن ورودی ها ثابت میکنند. با این وجود، استارکهای دانش-صفر به دلیل بهبود مقیاس پذیری و شفافیتی که ارائه میدهند، به عنوان پیشرفتی در اسنارکهای دانش-صفر در نظر گرفته میشوند.
-
-استارکهای دانش-صفر، "شفاف" هستند، زیرا میتوانند بدون تنظیمات قابل اعتماد یک رشته مرجع مشترک (CRS) کار کنند. در عوض، این استارکها به ارقام تصادفی قابل تائید توسط عموم، جهت تنظیم پارامترهایی که برای تولید و تأیید ادعا هستند، متکی میباشند.
-
-استارکهای دانش-صفر همچنین مقیاس پذیری بیشتری را ارائه می دهند، زیرا زمان مورد نیاز برای محاسبات پشت پرده مربوط به تائید و اثبات گواهیهای ادعا، به طور _شبه خطی_ افزایش می یابد. در اسنارکهای دانش-صفر (ZK-SNARKها)، زمان مورد نیاز برای محاسبات پشت پرده اثبات و راستیآزمایی گواهی ادعابه صورت _خطی_ افزایش مییابد. این بدان معناست که ZK-STARKها نسبت به ZK-SNARKها، به زمان کمتری برای اثبات و تائید مجموعه دادههای بزرگ نیاز دارند، و آنها را به گزینهی مناسبی برای برنامههای با حجم بالا تبدیل میکند.
-
-همچنین استارکهای دانش-صفر یا همان ZK-STARKها، در برابر رایانههای کوانتومی امنتر هستند، در حالی که اعتقاد بر این است که رمزنگاری منحنی بیضی (ECC) که در ZK-SNARKها استفاده میشود، مستعد حملات محاسباتی کوانتومی میباشد. نقطه ضعف ZK-STARKها این است که اندازه های اثبات بزرگ تری تولید می کنند که تأیید آن در اتریوم پرهزینهتر است.
-
-#### گواهیهای اثبات ادعا چگونه در رولآپهای دانش-صفر عمل میکنند؟ {#validity-proofs-in-zk-rollups}
-
-##### ساخت گواهی
-
-قبل از پذیرش تراکنشها، اپراتور بررسی های معمول را انجام می دهد. این شامل تائید موارد زیر است:
-
-- حسابهای فرستنده و گیرنده بخشی از درخت مرکل حالت هستند.
-- فرستنده دارای وجوه کافی برای پردازش تراکنش است.
-- تراکنش صحیح است و با کلید عمومی فرستنده در رولآپ مطابقت دارد.
-- Nonce (عدد یکبار مصرف تراکنش) فرستنده صحیح است و غیره.
-
-به محض این که گره رولآپ دانش-صفر تراکنشهای کافی داشته باشد، آنها را در یک دسته گردآوری میکند و ورودی ها را برای مدار اثبات کامپایل میکند تا در یک گواهی دانش-صفر مختصر کامپایل شود. این شامل:
-
-- یک ریشه درخت مرکل که شامل تمام تراکنشهای دسته است.
-- اثباتهای مرکل برای تراکنشها، جهت اثبات مشمولیت آنها در دسته تراکنشها.
-- گواهیهای مرکل برای هر جفت فرستنده و گیرنده در تراکنشها جهت اثبات این که حساب آنها بخشی از درخت حالت رولآپ میباشد.
-- مجموعهای از ریشههای حالت میانی، که از بهروزرسانی ریشه حالت پس از اعمال بهروزرسانیهای حالت برای هر تراکنش (یعنی کاهش موجودی حساب فرستنده و افزایش موجودی حساب گیرنده) به دست میآید.
-
-مدار اثبات ادعا، گواهی اعتبار ادعا را با "اجرای متوالی" یا همان عمل looping بر روی هر تراکنش و انجام همان بررسیهایی که اپراتور، قبل از پردازش تراکنش آنها انجام داده است، محاسبه می کند. ابتدا با استفاده از اثبات مرکل ارائه شده، تائید میکند که حساب فرستنده بخشی از ریشه حالت موجود است. سپس موجودی فرستنده را کاهش میدهد، nonce آن را افزایش میدهد، دادههای بهروز شده حساب را هش میکند و آن را با اثبات مرکل ترکیب میکند تا یک ریشه مرکل جدید ایجاد کند.
-
-این ریشه مرکل تنها تغییرات در حالت رولآپ دانش-صفر را منعکس میکند: یعنی تغییر در موجودی فرستنده و nonce. این امر امکانپذیر میباشد چون که اثبات مرکلی که برای اثبات وجود حساب استفاده می شود، برای استخراج ریشه حالت جدید نیز استفاده میشود.
-
-مدار اثبات ادعا همان فرآیند را بر حساب گیرنده انجام میدهد. مدار اثبات ادعا بررسی میکند که آیا حساب گیرنده تحت ریشه حالت میانی (با استفاده از گواهی اثبات مرکل) وجود دارد یا خیر، موجودی آنها را افزایش میدهد، دادههای حساب را دوباره هش میکند و آنها را با گواهی اثبات مرکل ترکیب میکند تا یک ریشه حالت جدید ایجاد نماید.
-
-این پروسه برای هر تراکنش تکرار میشود. اجرای هر "حلقه" یا loop، یک ریشه حالت جدید از بهروز رسانی حساب فرستنده و یک ریشه جدید متوالی از بهروز رسانی حساب گیرنده ایجاد میکند. همان گونه که توضیح داده شد، هر بهروز رسانی در ریشه حالت، نشان دهنده بخشی از تغییرات حالت درخت رولآپ است.
-
-مدار اثبات ZK در کل دسته تراکنش تکرار میشود و دنباله بهروزرسانیهایی را تأیید میکند که منجر به یک ریشه حالت نهایی پس از اجرای آخرین تراکنش میشود. آخرین ریشه مرکل محاسبه شده جدیدترین ریشه حالت متعارف ZK-rollup می شود.
-
-##### تایید اثبات
-
-پس از اینکه مدار اثبات صحت بهروزرسانیهای حالت را تأیید کرد، اپراتور L2 اثبات اعتبار محاسبهشده را به قرارداد تأییدکننده در L1 ارسال میکند. مدار تأیید قرارداد اعتبار اثبات را تأیید می کند و همچنین ورودی های عمومی را که بخشی از اثبات است بررسی می کند:
-
-- **ریشه Pre-state**: ریشه حالت قدیمی ZK-rollup (یعنی قبل از اجرای تراکنشهای دستهای) که آخرین وضعیت معتبر شناخته شده زنجیره L2 را منعکس میکند.
-
-- **ریشه پس از وضعیت**: ریشه وضعیت جدید ZK-rollup (یعنی پس از اجرای تراکنشهای دستهای) که منعکسکننده جدیدترین حالت زنجیره L2 است. ریشه post-state ریشه نهایی است که پس از اعمال به روز رسانی های حالت در مدار اثبات به دست می آید.
-
-- **ریشه دسته ای**: ریشه مرکل دسته، که از تراکنش های _مرکلایزینگ_ در دسته و هش کردن ریشه درخت به دست می آید.
-
-- **ورودی های تراکنش**: داده های مرتبط با تراکنش های انجام شده به عنوان بخشی از دسته ارسال شده.
-
-اگر اثبات مدار را برآورده کند (یعنی معتبر است)، به این معنی است که دنبالهای از تراکنشهای معتبر وجود دارد که جمعبندی را از حالت قبلی (از لحاظ رمزنگاری توسط ریشه پیشحالت اثرانگشت) به حالت جدید (از لحاظ رمزنگاری توسط ریشه پس از حالت اثرانگشت) انتقال میدهد. اگر ریشه pre-state با ریشه ذخیره شده در قرارداد رولآپ مطابقت داشته باشد و اثبات معتبر باشد، قرارداد رولآپ ریشه post-state را از اثبات میگیرد و درخت حالت آن را بهروزرسانی میکند تا حالت تغییر یافته رولآپ را منعکس کند.
-
-### ورودی ها و خروجی ها {#entries-and-exits}
-
-کاربران با سپرده گذاری توکن ها در قرارداد رولآپ در زنجیره L1 وارد ZK-rollup می شوند. این تراکنش در صف قرار می گیرد زیرا فقط اپراتورها می توانند تراکنش ها را به قرارداد رولآپ ارسال کنند.
-
-اگر صف سپرده معلق شروع به پر شدن کند، اپراتور ZK-rollup تراکنش های سپرده را می گیرد و آنها را به قرارداد رولآپ ارسال می کند. هنگامی که وجوه کاربر در رول آپ قرار گرفت، می تواند با ارسال تراکنش ها به اپراتور برای پردازش، تراکنش را آغاز کند. کاربران میتوانند با هش کردن دادههای حساب خود، ارسال هش به قرارداد رولآپ، و ارائه یک گواهی اثبات مرکل برای تأیید در برابر ریشه حالت فعلی، موجودیهای رولآپ را تائید کنند.
-
-برداشت کردن داراییها از رولآپ دانش-صفر به شبکه اصلی ساده است. کاربر تراکنش خروج را با ارسال داراییهای خود با رولآپ به یک حساب مشخص برای سوزاندن داراییها آغاز میکند. اگر اپراتور تراکنش را در دسته بعدی که میفرستد قرار دهد، کاربر میتواند درخواست برداشت را به قرارداد روی زنجیره اصلی ارسال کند. این درخواست برداشت شامل موارد زیر خواهد بود:
-
-- اثبات مرکل اثبات میکند که تراکنش کاربر به حساب سوختن در یک دسته تراکنش وجود دارد
-
-- دادههای تراکنش
-
-- ریشه دسته تراکنشها
-
-- آدرس شبکه اصلی یا L1 برای دریافت وجوه واریزی
-
-قرارداد رولآپ دادههای تراکنش را هش میکند، بررسی میکند که آیا ریشه دسته تراکنشها وجود دارد یا خیر، و از اثبات مرکل برای بررسی اینکه آیا هش تراکنش بخشی از ریشه دسته تراکنشها است، استفاده میکند. پس از آن، قرارداد، تراکنش خروج را اجرا میکند و وجوه را به آدرس انتخابی کاربر در L1 ارسال میکند.
-
-## سازگاری رولآپ های دانش-صفر و EVM {#zk-rollups-and-evm-compatibility}
-
-برخلاف رولآپ های خوشبینانه، رولآپ های دانش-صفر به راحتی با [ماشین مجازی اتریوم (EVM)](/developers/docs/evm/) سازگار نیستند. اثبات محاسبات همه منظوره EVM در مدارها از اثبات محاسبات ساده (مانند انتقال توکن که قبلاً توضیح داده شد) دشوارتر و با مصرف منابع بیشتر همراه است.
-
-با این حال، [پیشرفتها در فنآوری دانش-صفر](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) در حال برانگیختن علاقهمندی مجدد به قرار دادن محاسبات EVM در اثباتهای دانش-صفر است. این تلاشها برای ایجاد یک پیادهسازی از EVM دانش-صفر (zkEVM) است که میتواند صحت اجرای برنامه را بهطور مؤثر تائید کند. یک zkEVM کدهای EVM موجود را برای اثبات/تائید در مدارها بازسازی میکند و امکان اجرای قراردادهای هوشمند را فراهم میکند.
-
-همانند EVM، یک zkEVM پس از محاسبه بر روی برخی از ورودیها، بین حالتها انتقال مییابد. تفاوت این است که zkEVM برای تأیید صحت هر مرحله از اجرای برنامه، گواهی اثبات دانش-صفر ایجاد میکند. اثبات گواهی اعتبار میتواند صحت عملیاتی را که حالت ماشین مجازی (حافظه، استک، ذخیرهسازی) و خود محاسبات را لمس میکنند تائید کند (یعنی آیا عملیات کدهای عملیاتی مناسب را فراخوانی کرده و آنها را به درستی اجرا کرده است؟).
-
-انتظار میرود که معرفی رولآپ های دانش-صفر سازگار با EVM به توسعهدهندگان کمک کند تا از مقیاسپذیری و تضمینهای امنیتی گواهیهای اثبات دانش-صفر استفاده کنند. مهمتر از آن، سازگاری با زیرساختهای بومی اتریوم به این معنی است که توسعهدهندگان میتوانند با استفاده از ابزارها و زبانهای آشنا (و آزمایششده در برابر هک و باگ) dappهای سازگار با دانش-صفر بسازند.
-
-## کارمزد رولآپ های دانش-صفر چگونه است؟ {#how-do-zk-rollup-fees-work}
-
-میزان پرداختی که کاربران برای تراکنشهای روی رولآپ های دانش-صفر پرداخت میکنند، دقیقاً مانند شبکه اصلی اتریوم، به کارمزد گاز بستگی دارد. با این حال، هزینه های گاز در لایه دو ها متفاوت عمل میکند و تحت تأثیر هزینههای زیر میباشد:
-
-1. **بازنویسی حالت**: برای نوشتن در حالت اتریوم هزینه ثابتی وجود دارد (یعنی ارسال تراکنش در بلاک چین اتریوم). رولآپ های دانش-صفر این هزینه را با دستهبندی تراکنشها و توزیع هزینههای ثابت بین چندین کاربر کاهش میدهند.
-
-2. **انتشار دادهها**: رولآپ های دانش-صفر دادههای حالت هر تراکنش را به عنوان `calldata` در اتریوم منتشر میکنند. هزینههای `calldata` در حال حاضر توسط [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) کنترل میشود که به ترتیب هزینه 16 گاز را برای بایتهای غیر صفر و 4 گاز را برای بایتهای صفر موجود در `calldata` را تعیین میکند. هزینه پرداخت شده برای هر تراکنش به حجم `calldata` ارسالی در زنجیره اصلی، بستگی دارد.
-
-3. **کارمزدهای اپراتور L2**: این مبلغی است که به عنوان جبران هزینههای محاسباتی انجام شده در پردازش تراکنشها، به اپراتور رولآپ پرداخت میشود، خیلی شبیه به ["هزینههای اولویت (پاداشها)" تراکنش](/developers/docs/gas/#how-are-gas-fees-calculated) در شبکه اصلی اتریوم.
-
-4. **تولید گواهی اثبات و تائید آن**: اپراتورهای رولآپ دانش-صفر، باید برای دستههای تراکنش اثبات ادعا ارائه کنند که نیازمند منابع زیادی است. همچنین، تأیید گواهیهای دانش-صفر در شبکه اصلی اتریوم گاز (حدود 500,000 واحد گاز) مصرف میکند.
-
-جدا از دسته کردن تراکنشها، رولآپ های دانش-صفر با فشردهسازی دادههای تراکنش، هزینهها را برای کاربران کاهش میدهند. میتوانید [نمای کلی به روز](https://l2fees.info/) از هزینههای استفاده از رولآپ دانش-صفر اتریوم را ببینید.
-
-## رولآپ دانش-صفر چگونه اتریوم را مقیاسپذیر می کنند؟ {#scaling-ethereum-with-zk-rollups}
-
-### فشردهسازی دادههای تراکنش {#transaction-data-compression}
-
-رولآپ های دانش-صفر با استفاده از محاسبات خارج از زنجیره، توان عملیاتی و تعداد دادههای ورودی لایه پایه اتریوم را افزایش میدهند، اما تقویت واقعی مقیاسپذیری از فشردهسازی داده های تراکنش حاصل میشود. [اندازه بلوک](/developers/docs/blocks/#block-size) اتریوم دادههایی را که هر بلوک میتواند نگه دارد و در نتیجه تعداد تراکنشهای پردازش شده در هر بلوک را محدود میکند. با فشردهسازی داده های مربوط به تراکنش، رولآپ های دانش-صفر به طور قابل توجهی تعداد تراکنش های پردازش شده در هر بلوک را افزایش میدهند.
-
-رولآپ های دانش-صفر میتوانند دادههای تراکنش را بهتر از رولآپ های خوشبینانه فشرده کنند، زیرا نیازی به ارسال تمام دادههای مورد نیاز برای اعتبارسنجی هر تراکنش ندارند. آنها فقط باید حداقل داده های مورد نیاز برای بازسازی آخرین حالت حسابها و موجودیها را در رولآپ ارسال نمایند.
-
-### اثبات های بازگشتی {#recursive-proofs}
-
-مزیت اثباتهای دانش-صفر این است که گواهیها میتوانند گواهیهای دیگر را تأیید کنند. به عنوان مثال، یک ZK-SNARK میتواند یک ZK-SNARK دیگر را تأیید کند. چنین گواهیهای بازگشتی را "اثباتِ اثبات" مینامند و به طور چشمگیری توان عملیاتی را در رولآپ های دانش-صفر افزایش میدهند.
-
-در حال حاضر، گواهیهای اعتبار به صورت بلوک به بلوک تولید میشوند و برای تائید به قرارداد مستقر بر اتریوم ارسال میشوند. با این حال، تأیید گواهیهای تک بلوکی، توان عملیاتی که رولآپ های دانش-صفر میتوانند به دست آورند را محدود میکند، زیرا زمانی که اپراتور یک گواهی را ارائه و ثبت میکند، تنها یک بلوک نهایی میشود.
-
-در عوض، گواهیهای بازگشتی، نهایی کردن چندین بلوک را با یک گواهی اعتبار امکانپذیر میکنند. این به این دلیل است که مدار اثبات به صورت بازگشتی چندین گواهی بلوک را دستچین میکند تا زمانی که یک اثبات نهایی ایجاد شود. اپراتور لایه دو این گواهی بازگشتی را ارسال میکند و در صورت پذیرش توسط قرارداد، تمام بلوک های مربوطه بلافاصله نهایی میشوند. با گواهیهای بازگشتی، تعداد تراکنشهای رولآپ دانش-صفر که میتوانند در اتریوم در فواصل زمانی مشخص نهایی شوند، افزایش مییابند.
-
-### مزایا و معایب رولآپ دانش-صفر {#zk-rollups-pros-and-cons}
-
-| مزایا | معایب |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| گواهی اثبات اعتبار صحت تراکنشهای خارج از زنجیره را تضمین میکند و از اجرای انتقال حالت نامعتبر توسط اپراتورها جلوگیری میکند. | هزینه مربوط به محاسبات و تأیید اثبات اعتبار قابل توجه است و می تواند هزینهها را برای کاربران رولآپ افزایش دهد. |
-| نهایی شدن تراکنش سریعتر را ارائه میدهد، زیرا به محض تأیید اعتبار گواهی در شبکه اصلی اتریوم، بهروزرسانیهای حالت تأیید میشوند. | ایجاد رولآپ های دانش-صفر سازگار با EVM به دلیل پیچیدگی فناوری دانش-صفر دشوار است. |
-| برای امنیت به مکانیسمهای رمزنگاری بدون نیاز به اعتماد متکی است، نه صداقت مشارکتکنندگانی که ذینفع هستند مثل [رول آپهای خوشبینانه](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | تولید گواهی اثبات اعتبار نیاز به سختافزار تخصصی دارد که ممکن است مشوقی برای کنترل متمرکز زنجیره توسط چند نهاد باشد. |
-| داده های مورد نیاز برای بازیابی حالت خارج از زنجیره را در L1 ذخیره می کند، که امنیت، مقاومت در برابر سانسور و عدم تمرکز را تضمین میکند. | اپراتورهای متمرکز (sequencer یا ترتیبدهنده ها) میتوانند بر ترتیب تراکنشها تأثیر بگذارند. |
-| کاربران از بهرهوری بیشتر سرمایه بهره میبرند و میتوانند بدون تاخیر وجوه را از L2 برداشت نمایند. | الزامات سختافزاری ممکن است تعداد شرکتکنندگان زنجیره را کاهش دهد که میتواند زنجیره را مجبور به تغییر کند و خطر مسدود کردن حالت رولآپ توسط اپراتورهای مخرب و سانسور کاربران را افزایش میدهد. |
-| به فرضیات در حال اجرا بودن بستگی ندارد و کاربران مجبور نیستند زنجیره را برای محافظت از سرمایه خود تأیید کنند. | برخی از سیستمهای اثباتکننده (مانند ZK-SNARK) به تنظیمات قابل اعتماد نیاز دارند که در صورت عدم مدیریت صحیح، به طور بالقوه میتواند مدل امنیتی رولآپ دانش-صفر را به خطر بیندازد. |
-| فشردهسازی بهتر دادهها میتواند به کاهش هزینههای انتشار `calldata` در اتریوم و به حداقل رساندن هزینههای رولآپ برای کاربران کمک کند. | |
-
-### توضیح تصویری از رولآپ های دانش-صفر {#zk-video}
-
-ببینید Finematics چگونه درباره رولآپ دانش-صفر توضیح میدهد:
-
-
-
-### استفاده از رولآپ های دانش-صفر {#use-zk-rollups}
-
-پیاده سازی های متعددی از رولآپ های دانش-صفر وجود دارد که میتوانید آنها را در dappهای خود ادغام کنید:
-
-
-
-## چه کسی روی zkEVM کار میکند؟ {#zkevm-projects}
-
-پروژه هایی که روی zkEVM کار می کنند عبارتند از:
-
-- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM پروژهای است که توسط بنیاد اتریوم برای توسعه یک رولآپ دانش-صفر سازگار با EVM و مکانیزمی برای تولید گواهی اثبات اعتبار برای بلوکهای اتریوم، بنیانگذاری شد._
-
-- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _یک رولآپ غیرمتمرکز دانش-صفر در شبکه اصلی اتریوم است که بر روی یک ماشین مجازی اتریوم با دانش صفر (zkEVM) کار می کند که تراکنش های اتریوم را به روشی شفاف اجرا می کند، از جمله قراردادهای هوشمند با اعتبارسنجی دانش-صفر._
-
-- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll یک شرکت مبتنی بر فناوری است که بر روی ساخت یک راه حل بومی zkEVM Layer 2 برای اتریوم کار میکند._
-
-- **[Taiko](https://taiko.xyz)** - _Taiko یک رولآپ دانش-صفر غیرمتمرکز و معادل اتریوم است (یک [ZK-EVM نوع 1](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._
-
-- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era یک رولآپ دانش-صفر سازگار با EVM است که توسط Matter Labs ساخته شده است و با استفاده از zkEVM خودش اجرا میشود._
-
-- **[Starknet](https://starkware.co/starknet/)** - _StarkNet یک راه حل مقیاس پذیری لایه 2 سازگار با EVM است که توسط StarkWare ساخته شده است._
-
-- **[Morph](https://www.morphl2.io/)** - _Morph یک راهحل مقیاسپذیری ترکیبی است که از گواهی دانش-صفر برای رسیدگی به مشکل چالش حالت لایه 2 استفاده میکند._
-
-## خواندنیهای بیشتر در مورد رولآپ های دانش-صفر {#further-reading-on-zk-rollups}
-
-- [رولآپ دانش-صفر چیست؟](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups)
-- [رولآپ دانش-صفر چیست؟](https://alchemy.com/blog/zero-knowledge-rollups)
-- [STARKها در مقابل SNARKها](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/)
-- [ZkEVM چیست؟](https://www.alchemy.com/overviews/zkevm)
-- [انواع ZK-EVM: معادل اتریوم، معادل ماشین مجازی اتریوم، نوع 1، نوع 4، و دیگر واژههای مرموز](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4)
-- [معرفی zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt)
-- [منابع عالی zkEVM](https://github.com/LuozhuZhang/awesome-zkevm)
-- [پشت صحنه ZK-SNARKS](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html)
-- [SNARK چگونه ممکن است؟](https://vitalik.eth.limo/general/2021/01/26/snarks.html)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md
deleted file mode 100644
index 1dbed4fd9f1..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: ساختار دادهها و رمزگذاری
-description: مروری بر ساختارهای داده بنیادی اتریوم.
-lang: fa
-sidebarDepth: 2
----
-
-اتریوم حجم زیادی از داده ها را ایجاد، ذخیره و انتقال می دهد. این دادهها باید به روشهای استاندارد شده و با حافظه کارآمد قالببندی شوند تا به هر کسی اجازه دهد روی سختافزار نسبتاً درجه متوسط مصرفکننده [گرهی را اجرا کند](/run-a-node/). برای رسیدن به این هدف، چندین ساختار داده خاص در پشته اتریوم استفاده می شود.
-
-## پیشنیازها {#prerequisites}
-
-شما باید با اصول اتریوم و [نرم افزار کاربر](/developers/docs/nodes-and-clients/) آشنا باشید. آشنایی با لایه شبکه و [وایت پیپر اتریوم](/whitepaper/) توصیه می شود.
-
-## ساختارهای داده {#data-structures}
-
-### درخت مرکل پاتریشیا {#patricia-merkle-tries}
-
-درخت های مرکل پاتریشیا ساختارهایی هستند که جفتهای مقدار کلید را در یک آزمون قطعی و رمزنگاری تأیید شده رمزگذاری میکنند. این ها به طور گسترده در لایه اجرایی اتریوم استفاده می شوند.
-
-[جزئیات بیشتر درباره درخت های مرکل پاتریشیا](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
-
-### پیشوند طول بازگشتی {#recursive-length-prefix}
-
-پیشوند طول بازگشتی (RLP) یک روش سریال سازی است که به طور گسترده در لایه اجرایی اتریوم استفاده می شود.
-
-[جزئیات بیشتر درباره RLP](/developers/docs/data-structures-and-encoding/rlp)
-
-### سریال سازی ساده {#simple-serialize}
-
-سریال سازی ساده (SSZ)، به دلیل سازگاری آن با مرکلیزاسیون، فرمت سریال سازی غالب در لایه اجماع اتریوم است.
-
-[جزئیات بیشتر درباره SSZ](/developers/docs/data-structures-and-encoding/ssz)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
deleted file mode 100644
index ea7754e1a20..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
+++ /dev/null
@@ -1,323 +0,0 @@
----
-title: درخت مرکل پاتریشیا
-description: مقدمه ای بر درخت مرکل پاتریشیا.
-lang: fa
-sidebarDepth: 2
----
-
-حالت اتریوم (مجموع همه حسابها، موجودیها و قراردادهای هوشمند)، در نسخه خاصی از ساختار دادهها که عموماً در علوم کامپیوتر به عنوان درخت مرکل شناخته میشود، کدگذاری میشود. این ساختار برای بسیاری از برنامههای کاربردی در رمزنگاری مفید است، زیرا یک رابطه قابل تأیید بین تمام تکههای دادههای درهمتنیده در درخت ایجاد میکند، که منجر به یک مقدار **ریشه** میشود که میتواند برای اثبات چیزهایی در مورد دادهها استفاده شود.
-
-ساختار دادههای اتریوم یک «درخت مرکل-پاتریشیا اصلاحشده» است که به این دلیل نامگذاری شده است که برخی از ویژگیهای PATRICIA (الگوریتم عملی برای بازیابی اطلاعات کدگذاریشده به صورت الفبایی) را به عاریت گرفته و به این دلیل که برای باز**آزمایش**داده های کارآمد مواردی که حالت اتریوم را تشکیل می دهند طراحی شده است.
-
-درخت مرکل-پاتریشیا متغیر قطعی و از نظر رمزنگاری قابل تأیید است: تنها راه برای تولید ریشه حالت، محاسبه آن از تک تک تکه های حالت است، و دو حالت یکسان را می توان به راحتی با مقایسه هش ریشه و هش هایی که منجر به آن شدهاند ثابت کرد (_اثبات مرکل_). برعکس، هیچ راهی برای ایجاد دو حالت مختلف با هش ریشه یکسان وجود ندارد، و هر تلاشی برای تغییر حالت با مقادیر مختلف منجر به یک هش ریشه متفاوت خواهد شد. از نظر تئوری، این ساختار «جام مقدس» کارایی `O(log(n))` را برای درجها، جستجوها و حذفها فراهم میکند.
-
-در آینده نزدیک، اتریوم قصد دارد به ساختار [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees) مهاجرت کند، که بسیاری از فرصتهای جدید را برای بهبود پروتکلهای آینده باز خواهد کرد.
-
-## موارد مورد نیاز {#prerequisites}
-
-برای درک بهتر این صفحه، داشتن دانش اولیه در مورد [هش](https://en.wikipedia.org/wiki/Hash_function)، [درخت مرکل](https://en.wikipedia.org/wiki/Merkle_tree)، [درخت ها](https://en.wikipedia.org/wiki/Trie) و
-سریال سازی3 مفید خواهد بود. >. این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
-
-
-
-## درختهای پایه رادیکس {#basic-radix-tries}
-
-در یک درخت پایه رادیکس، هر گره به صورت زیر به نظر می رسد:
-
-
-
-```
- [i_0, i_1 ... i_n, value]
-```
-
-
-در حالی که `i_0 ... i_n` نمادهای الفبا (اغلب باینری یا هگزا) را نشان می دهد، `مقدار` مقدار پایانی در گره است و مقادیر در ` i_0، i_1 ... i_n` اسلاتها یا `NULL` یا اشارهگر به (در مورد ما، هشهای) گرههای دیگر هستند. این یک ذخیره پایه `(کلید، مقدار)` را تشکیل می دهد.
-
-فرض کنید میخواهید از یک ساختار داده درخت رادیکس برای تداوم سفارش روی مجموعهای از جفتهای مقدار کلیدی استفاده کنید. برای یافتن مقداری که در حال حاضر به کلید `dog` در درخت نگاشت شده است، ابتدا `dog` را به حروف الفبا تبدیل کنید (به `64 6f 67` بدهید) و سپس سعی کنید در درخت پایین بیایید تا مقدار را پیدا کنید. یعنی با جستجوی هش ریشه در یک DB کلید/مقدار مسطح برای یافتن گره ریشه درخت شروع میکنید. این امر، به صورت آرایه ای از کلیدها نشان داده می شود که به گره های دیگر اشاره می کنند. میتوانید از مقدار شاخص `6` به عنوان کلید استفاده کنید و آن را در کلید/مقدار مسطح DB جستجو کنید تا گره را یک سطح پایین بیاورید. سپس index `4` را برای جستجوی مقدار بعدی انتخاب کنید، سپس شاخص `6` را انتخاب کنید و به همین ترتیب، تا زمانی که مسیر را دنبال کردید: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`، شما مقدار گره را جستجو می کنید و نتیجه را نشان میدهید.
-
-بین جستجوی چیزی در "درخت" و کلید/مقدار مسطح زیرین "DB" تفاوت وجود دارد. هر دو ترتیبات کلید/مقدار را تعریف می کنند، اما DB زیربنایی می تواند یک جستجوی سنتی یک مرحله ای از یک کلید را انجام دهد. جستجوی یک کلید در درخت نیاز به جستجوهای متعدد DB زیربنایی برای رسیدن به مقدار نهایی شرح داده شده در بالا دارد. اجازه دهید به دومی به عنوان `مسیر` برای رفع ابهام اشاره کنیم.
-
-عملیات به روز رسانی و حذف برای درختهای radix را می توان به صورت زیر تعریف کرد:
-
-
-
-```
- def update(node,path,value):
- curnode = db.get(node) if node else [ NULL ] * 17
- newnode = curnode.copy()
- if path == '':
- newnode[-1] = value
- else:
- newindex = update(curnode[path[0]],path[1:],value)
- newnode[path[0]] = newindex
- db.put(hash(newnode),newnode)
- return hash(newnode)
-
- def delete(node,path):
- if node is NULL:
- return NULL
- else:
- curnode = db.get(node)
- newnode = curnode.copy()
- if path == '':
- newnode[-1] = NULL
- else:
- newindex = delete(curnode[path[0]],path[1:])
- newnode[path[0]] = newindex
-
- if all(x is NULL for x in newnode):
- return NULL
- else:
- db.put(hash(newnode),newnode)
- return hash(newnode)
-```
-
-
-درخت ریشه «مرکل» با پیوند دادن گرهها با استفاده از هش رمزنگاری ایجاد شده قطعی ساخته میشود. این آدرس دهی محتوا (در کلید/مقدار DB `key == keccak256(rlp(مقدار))`) تضمین یکپارچگی رمزنگاری داده های ذخیره شده را فراهم می کند. اگر هش ریشه یک درخت داده شده به طور عمومی شناخته شده باشد، هرکسی که به دادههای برگ زیرین دسترسی داشته باشد، میتواند با ارائه هشهای هر گره که مقدار خاصی را به ریشه درخت میپیوندد، اثبات کند که سعی میکند یک مقدار معین را در یک مسیر خاص اضافه میکند.
-
-برای یک مهاجم غیرممکن است که اثباتی برای یک جفت `(مسیر، مقدار)` ارائه دهد که وجود ندارد، زیرا هش ریشه در نهایت بر اساس همه هش های زیر آن است. هر گونه تغییر اساسی، هش ریشه را تغییر می دهد. میتوانید هش را بهعنوان نمایش فشردهای از اطلاعات ساختاری در مورد دادهها در نظر بگیرید، که با محافظت پیشتصویر تابع درهمسازی ایمن شده است.
-
-ما به یک واحد اتمی یک درخت ریشه (مثلاً یک کاراکتر هگز یا عدد باینری 4 بیتی) به عنوان "نیبل" اشاره خواهیم کرد. همانطور که در بالا توضیح داده شد، در حین پیمودن یک مسیر یک نوبت، گرهها میتوانند حداکثر به 16 فرزند اشاره داشته باشند اما یک عنصر `مقدار` را شامل میشوند. بنابراین ما آنها را به صورت آرایه ای به طول 17 نشان می دهیم. ما این آرایه های 17 عنصری را "گره های شاخه ای" می نامیم.
-
-
-
-## درخت مرکل پاتریشیا {#merkle-patricia-trees}
-
-درختهای رادیکس یک محدودیت عمده دارند: ناکارآمد هستند. اگر می خواهید یک پیوند `(مسیر، مقدار)` را در جایی که مسیر، مانند اتریوم، 64 کاراکتر طول دارد (تعداد nibble ها در `bytes32`) ذخیره کنید، به بیش از یک کیلوبایت فضای اضافی برای ذخیره یک سطح در هر کاراکتر نیاز خواهیم داشت، و هر جستجو یا حذف 64 مرحله کامل طول خواهد کشید. درخت پاتریشیا معرفی شده در ادامه این مشکل را حل می کند.
-
-
-
-### بهينه سازی {#optimization}
-
-یک گره در درخت مرکل پاتریشیا یکی از موارد زیر است:
-
-1. `NULL` (به عنوان رشته خالی نمایش داده می شود)
-2. `شاخه` یک گره 17 موردی `[ v0 ... v15, vt ]`
-3. `برگ` یک گره 2 موردی `[ encodedPath، مقدار ]`
-4. `افزونه` یک گره 2 موردی `[ encodedPath, key ]`
-
-با 64 مسیر کاراکتر، اجتناب ناپذیر است که پس از عبور از چند لایه اول سعی کنید، به گره ای برسید که در آن مسیر واگرا حداقل برای بخشی از مسیر پایین وجود نداشته باشد. برای جلوگیری از ایجاد حداکثر 15 گره `NULL` پراکنده در طول مسیر، با راهاندازی یک گره `افزونه` به شکل `[ encodedPath, key ] مسیر فرود را میانبر میکنیم`، جایی که `encodedPath` حاوی "مسیر جزئی" برای رد شدن از پیش است (با استفاده از یک رمزگذاری فشرده که در زیر توضیح داده شده است)، و `کلید` برای جستجوی DB بعدی است.
-
-برای یک گره `برگ`، که میتوان آن را با یک پرچم در اولین نیبل `encodedPath` علامتگذاری کرد، مسیر تمام قطعات مسیر گره قبلی را رمزگذاری می کند و ما می توانیم `مقدار` را مستقیماً جستجو کنیم.
-
-با این حال، این بهینهسازی بالا باعث ایجاد ابهام میشود.
-
-هنگام پیمایش مسیرها در نیبل، ممکن است در نهایت با تعداد فرد نیبل برای پیمایش مواجه شویم، اما به این دلیل که همه داده ها در قالب `بایت` ذخیره می شوند. نمی توان بین، به عنوان مثال، nibble `1` و nibbles `01` تفاوت قائل شد (هر دو باید به عنوان `<01>` ذخیره شوند). برای تعیین طول فرد، مسیر جزئی با یک پرچم پیشوند داده می شود.
-
-
-
-### مشخصات: رمزگذاری فشرده دنباله هگزا با پایان دهنده اختیاری {#specification}
-
-علامت گذاری _طول مسیر جزئی باقیمانده فرد در مقابل زوج_ و _گره برگ در مقابل پسوند_ همانطور که در بالا توضیح داده شد در اولین نوک مسیر جزئی هر گره 2 موردی قرار دارد. آنها به موارد زیر منجر می شوند:
-
- hex char bits | node type partial path length
- ----------------------------------------------------------
- 0 0000 | extension even
- 1 0001 | extension odd
- 2 0010 | terminating (leaf) even
- 3 0011 | terminating (leaf) odd
-
-
-حتی برای طول مسیر باقیمانده (`0` یا `2`)، یک نوک `0` "padding" دیگر همیشه در پی میآید.
-
-
-
-```
- def compact_encode(hexarray):
- term = 1 if hexarray[-1] == 16 else 0
- if term: hexarray = hexarray[:-1]
- oddlen = len(hexarray) % 2
- flags = 2 * term + oddlen
- if oddlen:
- hexarray = [flags] + hexarray
- else:
- hexarray = [flags] + [0] + hexarray
- // hexarray now has an even length whose first nibble is the flags.
- o = ''
- for i in range(0,len(hexarray),2):
- o += chr(16 * hexarray[i] + hexarray[i+1])
- return o
-```
-
-
-مثال ها:
-
-
-
-```
- > [ 1, 2, 3, 4, 5, ...]
- '11 23 45'
- > [ 0, 1, 2, 3, 4, 5, ...]
- '00 01 23 45'
- > [ 0, f, 1, c, b, 8, 10]
- '20 0f 1c b8'
- > [ f, 1, c, b, 8, 10]
- '3f 1c b8'
-```
-
-
-در اینجا کد توسعه یافته برای گرفتن یک گره در درخت مرکل پاتریشیا آمده است:
-
-
-
-```
- def get_helper(node,path):
- if path == []: return node
- if node = '': return ''
- curnode = rlp.decode(node if len(node) < 32 else db.get(node))
- if len(curnode) == 2:
- (k2, v2) = curnode
- k2 = compact_decode(k2)
- if k2 == path[:len(k2)]:
- return get(v2, path[len(k2):])
- else:
- return ''
- elif len(curnode) == 17:
- return get_helper(curnode[path[0]],path[1:])
-
- def get(node,path):
- path2 = []
- for i in range(len(path)):
- path2.push(int(ord(path[i]) / 16))
- path2.push(ord(path[i]) % 16)
- path2.push(16)
- return get_helper(node,path2)
-```
-
-
-
-
-### درخت نمونه {#example-trie}
-
-فرض کنید ما درختی می خواهیم حاوی چهار جفت مسیر/مقدار `('do', 'verb')`, `('dog', 'puppy')`, `(' doge، «coins»)`، `(«horse»، «stallion»)`.
-
-ابتدا، هم مسیرها و هم مقادیر را به `بایت` تبدیل می کنیم. در زیر، نمایشهای واقعی بایت برای _مسیرها_ با > نشان داده میشوند، اگرچه _مقادیر_ که برای درک آسان تر همچنان به صورت رشتهها`` نشان داده میشوند (آنها نیز در واقع `بایت` خواهند بود):
-
-
-
-```
- <64 6f> : 'verb'
- <64 6f 67> : 'puppy'
- <64 6f 67 65> : 'coins'
- <68 6f 72 73 65> : 'stallion'
-```
-
-
-اکنون، ما چنین درختی را با جفتهای کلید/مقدار زیر در DB زیرین میسازیم:
-
-
-
-```
- rootHash: [ <16>, hashA ]
- hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
- hashB: [ <00 6f>, hashC ]
- hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
- hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
-```
-
-
-هنگامی که یک گره در داخل گره دیگری ارجاع داده می شود، آنچه شامل می شود `H(rlp.encode(node))` است، که در آن `H(x) = keccak256(x) اگر len(x) > = 32 else x` و `rlp.encode` تابع رمزگذاری [RLP](/developers/docs/data-structures-and-encoding/rlp) است.
-
-توجه داشته باشید که هنگام بهروزرسانی یک درخت، باید جفت کلید/مقدار `(keccak256(x)، x)` را در یک جدول جستجوی دائمی ذخیره کنید _اگر_ گره تازه ایجاد شده دارای طول >= 32 باشد. با این حال، اگر گره کوتاهتر از آن باشد، نیازی به ذخیره چیزی نیست، زیرا تابع f(x) = x قابل برگشت است.
-
-
-
-## درخت ها در اتریوم {#tries-in-ethereum}
-
-تمام درخت های مرکل در لایه اجرایی اتریوم از درخت مرکل پاتریشیا استفاده میکنند.
-
-از یک سر بلوک 3 ریشه از 3 مورد از این درخت ها وجود دارد.
-
-1. stateRoot
-2. transactionsRoot
-3. receiptsRoot
-
-
-
-### درخت حالت {#state-trie}
-
-یک درخت حالت جهانی وجود دارد و هر بار که کلاینت یک بلوک را پردازش می کند، به روز می شود. در آن، یک `مسیر` همیشه: `keccak256(ethereumAddress)` و یک `مقدار` همیشه: `rlp(ethereumAccount)` است. به طور خاص، `حساب` اتریوم یک آرایه 4 موردی از `[nonce,balance,storageRoot,codeHash]` است. در این مرحله، شایان ذکر است که این `storageRoot` ریشه یکی دیگر از درخت های پاتریشیا است:
-
-
-
-### درخت حافظه {#storage-trie}
-
-درخت Storage جایی است که _همه_ دادههای قرارداد زندگی میکنند. برای هر حساب یک فضای ذخیره سازی جداگانه وجود دارد. برای بازیابی مقادیر در موقعیتهای ذخیرهسازی خاص در یک آدرس معین، آدرس ذخیره، موقعیت عدد صحیح دادههای ذخیرهشده در حافظه و شناسه بلوک مورد نیاز است. سپس میتوان آنها را بهعنوان آرگومان به `eth_getStorageAt` تعریفشده در JSON-RPC API ارسال کرد، بهعنوان مثال: برای بازیابی داده ها در اسلات ذخیره سازی 0 برای آدرس `0x295a70b2de5e3953354a6a8344e616ed314d7251`:
-
-
-
-```
-curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
-
-{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
-
-```
-
-
-بازیابی عناصر دیگر در ذخیره سازی کمی بیشتر دخیل است زیرا ابتدا باید موقعیت در درخت حافظه محاسبه شود. موقعیت به عنوان هش `keccak256` آدرس و موقعیت ذخیره سازی محاسبه می شود که هر دو در سمت چپ با صفر تا طول 32 بایت اضافه شده اند. به عنوان مثال، موقعیت داده در شکاف ذخیره سازی 1 برای آدرس `0x391694e7e0b0cce554cb130d723a9d27458f9298` است:
-
-
-
-```
-keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))
-```
-
-
-در یک کنسول Geth، این می تواند به صورت زیر محاسبه شود:
-
-
-
-```
-> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
-undefined
-> web3.sha3(key, {"encoding": "hex"})
-"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
-```
-
-
-بنابراین `مسیر` `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` است. اکنون می توان از آن برای بازیابی داده ها از درخت حافظه مانند قبل استفاده کرد:
-
-
-
-```
-curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
-
-{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
-```
-
-
-توجه: `storageRoot` برای یک حساب اتریوم اگر یک حساب قراردادی نباشد به طور پیشفرض خالی است.
-
-
-
-### درخت تراکنشها {#transaction-trie}
-
-برای هر بلوک یک تراکنش جداگانه وجود دارد که دوباره جفتهای `(کلید، مقدار)` را ذخیره میکند. یک مسیر در اینجا عبارت است از: `rlp(transactionIndex)` که نشان دهنده کلیدی است که با مقدار تعیین شده از سوی این مطابقت دارد:
-
-
-
-```
-if legacyTx:
- value = rlp(tx)
-else:
- value = TxType | encode(tx)
-```
-
-
-اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
-
-
-
-### درخت رسیدها {#receipts-trie}
-
-هر بلوک درخت رسیدهای خود را دارد. یک `مسیر` در اینجا این است: `rlp(transactionIndex)`. `transactionIndex` شاخص آن در بلوکی است که در آن گنجانده شده است. درخت رسیدها هرگز به روز نمی شود. مشابه درخت تراکنشها، رسیدهای جاری و قدیمی وجود دارد. برای استعلام یک رسید خاص در درخت رسیدها، شاخص تراکنش در بلوک آن، بار رسید و نوع تراکنش مورد نیاز است. رسید برگشتی می تواند از نوع `رسیدی` باشد که به عنوان الحاق `TransactionType` و `ReceiptPayload` تعریف می شود یا می تواند از نوع `LegacyReceipt< باشد /0> که به صورت rlp([status, cumulativeGasUsed, logsBloom, logs])`. تعریف میشود.
-
-اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
-
-
-
-## اطلاعات بیشتر {#further-reading}
-
-- [درخت مرکل پاتریشیا اصلاح شده – چگونه اتریوم یک حالت را ذخیره می کند](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
-- [مرکلینگ در اتریوم](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/)
-- [فهمیدن درخت اتریوم](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md
deleted file mode 100644
index 5909276a700..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md
+++ /dev/null
@@ -1,163 +0,0 @@
----
-title: سریال سازی پیشوند با طول بازگشتی (RLP)
-description: تعریف رمزگذاری rlp در لایه اجرایی اتریوم.
-lang: fa
-sidebarDepth: 2
----
-
-سریال سازی پیشوند طول بازگشتی (RLP) به طور گسترده در کلاینت های اجرایی اتریوم استفاده می شود. RLP انتقال داده ها بین گره ها را در یک فرمت فضا-کارا استاندارد می کند. هدف RLP کدگذاری آرایه های تو در تو دلخواه از داده های دوتایی است و RLP روش رمزگذاری اولیه است که برای سریال سازی اشیاء در لایه اجرای اتریوم استفاده می شود. هدف اصلی RLP کدگذاری ساختار است. به استثنای اعداد صحیح مثبت، RLP کدگذاری انواع داده های خاص (مانند رشته ها، شناورها) را به پروتکل های مرتبه بالاتر واگذار می کند. اعداد صحیح مثبت باید به شکل دوتایی با اندین بزرگ و بدون صفرهای ابتدایی نمایش داده شوند (بنابراین مقدار عدد صحیح صفر معادل آرایه بایت خالی می شود). اعداد صحیح مثبت غیر سریالی شده با صفرهای ابتدایی باید توسط هر پروتکل مرتبه بالاتر با استفاده از RLP نامعتبر تلقی شوند.
-
-اطلاعات بیشتر در [مقاله زرد اتریوم (پیوست B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19).
-
-برای استفاده از RLP برای رمزگذاری یک فرهنگ لغت، دو شکل متعارف پیشنهادی عبارتند از:
-
-- از `[[k1,v1],[k2,v2]...]` با کلیدها به ترتیب واژگان استفاده کنید
-- از رمزگذاری درخت پاتریشیا در سطح بالاتر مانند اتریوم استفاده کنید
-
-## تعریف {#definition}
-
-تابع رمزگذاری RLP یک آیتم را می گیرد. یک آیتم به صورت زیر تعریف می شود:
-
-- یک رشته (یعنی آرایه بایت) یک آیتم است
-- لیست اقلام، یک آیتم است
-- یک عدد صحیح مثبت یک آیتم است
-
-به عنوان مثال، همه موارد زیر عبارتند از:
-
-- یک رشته خالی؛
-- رشته حاوی کلمه "گربه"؛
-- لیستی حاوی هر تعداد رشته؛
-- و ساختارهای داده پیچیده تری مانند `["گربه"، ["توله سگ"، "گاو"]، "اسب"، [[]]، "خوک"، [""]، "گوسفند"]`.
-- عدد `100`
-
-توجه داشته باشید که در زمینه بقیه این صفحه، "رشته" به معنای "تعداد معینی از بایت داده های دوتایی" است. هیچ کدگذاری خاصی استفاده نمی شود، توجه داشته باشید که در زمینه بقیه این صفحه، "رشته" به معنای "تعداد معینی از بایت داده های دوتایی" است. هیچ کدگذاری خاصی استفاده نمی شود، و هیچ دانشی در مورد محتوای رشته ها وجود ندارد (به جز مواردی که توسط قانون در مورد اعداد صحیح مثبت غیر حداقلی لازم است).
-
-رمزگذاری RLP به صورت زیر تعریف می شود:
-
-- برای یک عدد صحیح مثبت، به کوتاهترین آرایه بایتی که تفسیر آن عدد صحیح است، تبدیل میشود و سپس طبق قوانین زیر به عنوان یک رشته کدگذاری میشود.
-- برای یک بایت که مقدار آن در محدوده `[0x00, 0x7f]` (اعشاری `[0, 127]`) است، آن بایت رمزگذاری RLP خودش است.
-- در غیر این صورت، اگر یک رشته 0-55 بایت طول داشته باشد، رمزگذاری RLP از یک بایت با مقدار **0x80** (اعشار 128) به اضافه طول رشته و به دنبال آن رشته تشکیل شده است. بنابراین، محدوده اولین بایت `[0x80, 0xb7]` است (dec. `[128, 183]`).
-- اگر یک رشته بیش از 55 بایت طول داشته باشد، رمزگذاری RLP شامل یک بایت منفرد با مقدار **0xb7** (اعشار 183) به اضافه طول بر حسب بایت طول رشته به صورت دوتایی است و به دنبال آن طول رشته و به دنبال آن رشته است. به عنوان مثال، یک رشته 1024 بایتی به صورت `\xb9\x04\x00` (dec. `185, 4, 0`) و به دنبال آن رشته رمزگذاری میشود. در اینجا، `0xb9` (183 + 2 = 185) به عنوان اولین بایت، به دنبال آن 2 بایت `0x0400` (اعشار 1024) که طول رشته واقعی را نشان می دهد. بنابراین، محدوده اولین بایت `[0xb8, 0xbf]` است (اعشار `[184، 191]`).
-- اگر یک رشته 2^64 بایت یا بیشتر باشد، ممکن است رمزگذاری نشود.
-- اگر مجموع بار یک لیست (یعنی طول ترکیبی همه موارد آن که با RLP کدگذاری شده اند) 0-55 بایت باشد، رمزگذاری RLP از یک بایت با مقدار **0xc0** به اضافه طول بار و به دنبال آن الحاق رمزگذاری های RLP اقلام تشکیل میشود. بنابراین، محدوده اولین بایت `[0xc0, 0xf7]` است (اعشار `[192, 247] `).
-- اگر حجم کل یک لیست بیش از 55 بایت باشد، رمزگذاری RLP شامل یک بایت منفرد با مقدار **0xf7** به اضافه طول بر حسب بایت طول بار به صورت دوتایی است و به دنبال آن طول بار، و به دنبال آن الحاق رمزگذاری های RLP اقلام است. بنابراین، محدوده اولین بایت `[0xf8, 0xff]` است (اعشار `[248, 255] `).
-
-در کد، این عبارت است از:
-
-```python
-def rlp_encode(input):
- if isinstance(input,str):
- if len(input) == 1 and ord(input) < 0x80:
- return input
- return encode_length(len(input), 0x80) + input
- elif isinstance(input, list):
- output = ''
- for item in input:
- output += rlp_encode(item)
- return encode_length(len(output), 0xc0) + output
-
-def encode_length(L, offset):
- if L < 56:
- return chr(L + offset)
- elif L < 256**8:
- BL = to_binary(L)
- return chr(len(BL) + offset + 55) + BL
- raise Exception("input too long")
-
-def to_binary(x):
- if x == 0:
- return ''
- return to_binary(int(x / 256)) + chr(x % 256)
-```
-
-## مثال ها {#examples}
-
-- the string "dog" = [ 0x83, 'd', 'o', 'g' ]
-- the list [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]`
-- the empty string ('null') = `[ 0x80 ]`
-- the empty list = `[ 0xc0 ]`
-- the integer 0 = `[ 0x80 ]`
-- the byte '\\x00' = `[ 0x00 ]`
-- the byte '\\x0f' = `[ 0x0f ]`
-- the bytes '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]`
-- [نمایش تئوری مجموعه](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) سه، `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]`
-- رشته "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]`
-
-## رمزگشایی RLP {#rlp-decoding}
-
-با توجه به قوانین و فرآیند رمزگذاری RLP، ورودی رمزگشایی RLP به عنوان آرایه ای از داده های دوتایی در نظر گرفته می شود. فرآیند رمزگشایی RLP به شرح زیر است:
-
-1. با توجه به اولین بایت (یعنی پیشوند) داده های ورودی و رمزگشایی نوع داده، طول داده واقعی و افست؛
-
-2. با توجه به نوع و افست داده، داده ها را به ترتیب رمزگشایی کنید، با رعایت حداقل قانون رمزگذاری برای اعداد صحیح مثبت.
-
-3. به رمزگشایی بقیه ورودی ادامه دهید؛
-
-در میان آنها، قوانین رمزگشایی انواع داده و افست به شرح زیر است:
-
-1. اگر محدوده اولین بایت (یعنی پیشوند) [0x00, 0x7f] باشد و رشته دقیقاً خود اولین بایت باشد، داده یک رشته است.
-
-2. اگر محدوده اولین بایت [0x80, 0xb7] باشد، و رشته ای که طول آن برابر با بایت اول منهای 0x80 است از بایت اول پیروی کند، داده یک رشته است؛
-
-3. اگر محدوده اولین بایت [0xb8, 0xbf] باشد، و طول رشته ای که طول آن بر حسب بایت برابر بایت اول منهای 0xb7 است از بایت اول پیروی می کند و رشته از طول رشته پیروی می کند، داده یک رشته است؛
-
-4. اگر محدوده اولین بایت [0xc0, 0xf7] باشد، و الحاق رمزگذاری های RLP همه آیتم های لیست که کل بار بار برابر با بایت اول منهای 0xc0 است، از بایت اول پیروی می کند، داده یک لیست است؛
-
-5. اگر محدوده اولین بایت [0xf8, 0xff] باشد، و کل محموله فهرستی که طول آن برابر با بایت اول منهای 0xf7 است، از اولین بایت پیروی می کند، و الحاق رمزگذاری های RLP همه آیتم های لیست از کل بار فهرست پیروی می کنند، داده یک لیست است؛
-
-در کد، این عبارت است از:
-
-```python
-def rlp_decode(input):
- if len(input) == 0:
- return
- output = ''
- (offset, dataLen, type) = decode_length(input)
- if type is str:
- output = instantiate_str(substr(input, offset, dataLen))
- elif type is list:
- output = instantiate_list(substr(input, offset, dataLen))
- output += rlp_decode(substr(input, offset + dataLen))
- return output
-
-def decode_length(input):
- length = len(input)
- if length == 0:
- raise Exception("input is null")
- prefix = ord(input[0])
- if prefix <= 0x7f:
- return (0, 1, str)
- elif prefix <= 0xb7 and length > prefix - 0x80:
- strLen = prefix - 0x80
- return (1, strLen, str)
- elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)):
- lenOfStrLen = prefix - 0xb7
- strLen = to_integer(substr(input, 1, lenOfStrLen))
- return (1 + lenOfStrLen, strLen, str)
- elif prefix <= 0xf7 and length > prefix - 0xc0:
- listLen = prefix - 0xc0;
- return (1, listLen, list)
- elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)):
- lenOfListLen = prefix - 0xf7
- listLen = to_integer(substr(input, 1, lenOfListLen))
- return (1 + lenOfListLen, listLen, list)
- raise Exception("input does not conform to RLP encoding form")
-
-def to_integer(b):
- length = len(b)
- if length == 0:
- raise Exception("input is null")
- elif length == 1:
- return ord(b[0])
- return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256
-```
-
-## بیشتر بخوانید {#further-reading}
-
-- [RLP در اتریوم](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919)
-- [اتریوم زیر سقف: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58)
-- [Coglio, A. (2020). پیشوند طول مکرر اتریوم در ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769)
-
-## موضوعات مرتبط {#related-topics}
-
-- [درخت مرکل پاتریشیا](/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md
deleted file mode 100644
index 48bf26d8e19..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: سریال سازی ساده
-description: توضیحی دربارهی فرمت SSZ اتریوم.
-lang: fa
-sidebarDepth: 2
----
-
-**سریال سازی ساده (SSZ)** روش سریال سازی مورد استفاده در زنجیره Beacon است. این سریال سازی، شیوه سریال سازی RLP مورد استفاده در لایه اجرایی در همه جای لایه اجماع، به جز پروتکل کشف همتا را جایگزین میکند. SSZ طوری طراحی شده است که قطعی باشد و همچنین به شکلی کارآمد به فرمت درخت مرکل تبدیل شود. SSZ را میتوان سیستمی در نظر گرفت که دو جزء دارد: یک طرح سریال سازی و یک طرح مرکلازیسیون (طرح مرکلازیسیون پروسه تبدیل اطلاعات به فرمت درخت مرکل را تعریف میکند) که برای افزایش کارآیی هنگام کار با ساختار دادههای سریالی (دنبالهدار) طراحی شده است.
-
-## SSZ چگونه کار میکند؟ {#how-does-ssz-work}
-
-### سریالی کردن {#serialization}
-
-SSZ یک طرح ایجاد دنباله است که خود توصیف نیست - بلکه بر طرحی تکیه دارد که باید از قبل شناخته شده باشد. هدف سریال سازی SSZ، نمایش اشیاء (objectها) با پیچیدگی دلخواه به صورت رشته هایی از بایت است. این یک فرآیند بسیار ساده برای "انواع پایه" است. عنصر به سادگی به بایت های هگزادسیمال تبدیل می شود. انواع پایه عبارتند از:
-
-- اعداد صحیح بدون علامت
-- بولین ها
-
-برای انواع پیچیده "کامپوزیت"، سریال سازی پیچیده تر است، زیرا نوع ترکیب حاوی عناصر متعددی است که ممکن است انواع مختلف یا اندازه های مختلف یا هر دو را داشته باشند. در جایی که این اشیاء همگی دارای طولهای ثابت هستند (یعنی اندازه عناصر بدون در نظر گرفتن مقادیر واقعی آنها همیشه ثابت است) سریالسازی صرفاً تبدیل هر عنصر در نوع ترکیبی است که به رشتههای بایت انددیایی کوچک مرتب شدهاند. این رشتههای بایت به هم پیوسته اند. شیء سریالسازیشده نمایش فهرست بایتی عناصر با طول ثابت را به همان ترتیبی که در شیء بیسریالشده ظاهر میشوند، دارد.
-
-برای انواع با طول های متغیر، داده های واقعی با یک مقدار "افست" در موقعیت آن عنصر در شی سریال شده جایگزین می شوند. داده های واقعی به پشته ای در انتهای شیء سریال شده اضافه می شود. مقدار افست شاخصی برای شروع داده های واقعی در پشته است که به عنوان یک اشاره گر به بایت های مربوطه عمل می کند.
-
-مثال زیر نحوه عملکرد آفستینگ برای ظرفی با عناصر دارای طول ثابت و متغیر را نشان می دهد:
-
-```Rust
-
- struct Dummy {
-
- number1: u64,
- number2: u64,
- vector: Vec,
- number3: u64
- }
-
- dummy = Dummy{
-
- number1: 37,
- number2: 55,
- vector: vec![1,2,3,4],
- number3: 22,
- }
-
- serialized = ssz.serialize(dummy)
-
-```
-
-`serialized` ساختار زیر را خواهد داشت (در اینجا فقط به 4 بیت اضافه می شود، در واقعیت به 32 بیت اضافه می شود و نمایش `int` را برای وضوح حفظ می کند):
-
-```
-[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
------------- ----------- ----------- ----------- ----------
- | | | | |
- number1 number2 offset for number 3 value for
- vector vector
-
-```
-
-برای وضوح به خطوط تقسیم می شود:
-
-```
-[
- 37, 0, 0, 0, # little-endian encoding of `number1`.
- 55, 0, 0, 0, # little-endian encoding of `number2`.
- 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16).
- 22, 0, 0, 0, # little-endian encoding of `number3`.
- 1, 2, 3, 4, # The actual values in `vector`.
-]
-```
-
-این هنوز یک سادهسازی است - اعداد صحیح و صفر در شماتیکهای بالا در واقع به عنوان بایتلیستها ذخیره میشوند، مانند این:
-
-```
-[
- 10100101000000000000000000000000 # little-endian encoding of `number1`
- 10110111000000000000000000000000 # little-endian encoding of `number2`.
- 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16).
- 10010110000000000000000000000000 # little-endian encoding of `number3`.
- 10000001100000101000001110000100 # The actual value of the `bytes` field.
-]
-```
-
-بنابراین مقادیر واقعی برای انواع با طول متغیر در یک پشته در انتهای شیء سریالسازی شده با آفستهای آنها در موقعیتهای صحیح خود در فهرست مرتب شده فیلدها ذخیره میشوند.
-
-برخی موارد خاص نیز وجود دارند که نیاز به فرایند خاصی دارند، مانند نوع `BitList` که نیاز به اضافه کردن یک درپوش طول در حین سریالسازی و حذف در حین جداسازی دارد. جزئیات کامل در [مشخصات SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) موجود است.
-
-### غیرسریالی سازی {#deserialization}
-
-برای غیر سریالی کردن این شی به طرحواره نیاز است. این طرح، چیدمان دقیق دادههای سریالسازیشده را تعریف میکند، طوری که هر عنصر خاص را میتوان از یک لکه بایت به یک شی معنادار با عناصر دارای نوع، مقدار، اندازه و موقعیت مناسب غیرسریالی کرد. این طرح واره است که به غیرسریالی کننده می گوید که چه مقادیری مقادیر واقعی هستند و چه مقادیری افست هستند. همه نامهای فیلد زمانی که یک شی سریالی میشود، ناپدید میشوند، اما طبق طرحواره، پس از سریالسازی مجدداً نمونهسازی میشوند.
-
-برای توضیح تعاملی در این مورد به [ssz.dev](https://www.ssz.dev/overview) مراجعه کنید.
-
-## مرکلیزیشن {#merkleization}
-
-این شیء سریالی SSZ سپس می تواند مرکلیزه شود - که به یک نمایش درخت مرکل از همان داده ها تبدیل می شود. ابتدا تعداد تکه های 32 بایتی در شیء سریالی شده تعیین می شود. اینها "برگ"های درخت هستند. تعداد کل برگ ها باید توان 2 باشد تا هش کردن برگ ها با هم در نهایت یک ریشه درخت هش ایجاد کند. اگر به طور طبیعی اینطور نباشد، برگ های اضافی حاوی 32 بایت صفر اضافه می شود. به صورت نموداری:
-
-```
- hash tree root
- / \
- / \
- / \
- / \
- hash of leaves hash of leaves
- 1 and 2 3 and 4
- / \ / \
- / \ / \
- / \ / \
- leaf1 leaf2 leaf3 leaf4
-```
-
-همچنین مواردی وجود دارد که برگ های درخت به طور طبیعی به روشی که در مثال بالا انجام می شود به طور یکنواخت توزیع نمی کنند. به عنوان مثال، برگ 4 می تواند ظرفی با عناصر متعدد باشد که نیاز به "عمق" اضافی برای افزودن به درخت مرکل دارد و یک درخت ناهموار ایجاد می کند.
-
-به جای ارجاع به این عناصر درختی به عنوان برگ X، گره X و غیره، میتوانیم به آنها شاخصهای تعمیمیافته بدهیم که با ریشه = 1 شروع میشود و در امتداد هر سطح از چپ به راست میشماریم. این شاخص کلی است که در بالا توضیح داده شد. هر عنصر در فهرست سریالسازی شده دارای یک شاخص تعمیمیافته برابر با `2**عمق + idx` است که در آن idx موقعیت صفر نمایهشده آن در شیء سریالسازیشده و عمق تعداد سطوح در درخت مرکل است، که می تواند به عنوان لگاریتم پایه دو تعداد عناصر (برگ) تعیین شود.
-
-## شاخص های تعمیم یافته {#generalized-indices}
-
-یک شاخص تعمیمیافته یک عدد صحیح است که نشاندهنده یک گره در درخت مرکل دوتایی است که در آن هر گره دارای یک شاخص تعمیمیافته `2 ** عمق + شاخص در ردیف` است.
-
-```
- 1 --depth = 0 2**0 + 0 = 1
- 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3
- 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5...
-
-```
-
-این نمایش یک شاخص گره برای هر قطعه داده در درخت مرکل به دست می دهد.
-
-## اثبات چندگانه {#multiproofs}
-
-ارائه فهرستی از شاخصهای تعمیمیافته که یک عنصر خاص را نشان میدهد به ما امکان میدهد آن را نسبت به ریشه درخت هش تأیید کنیم. این ریشه نسخه پذیرفته شده ما از واقعیت است. هر داده ای که ما ارائه می کنیم را می توان با قرار دادن آن در مکان مناسب در درخت مرکل (که توسط شاخص تعمیم یافته آن تعیین می شود) و مشاهده ثابت ماندن ریشه در برابر آن واقعیت تأیید کرد. توابعی در مشخصات [اینجا](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) وجود دارد که نحوه محاسبه حداقل مجموعه گره های مورد نیاز برای تأیید محتویات یک مجموعه خاص از شاخص های تعمیم یافته را نشان می دهند.
-
-به عنوان مثال، برای تأیید داده های شاخص 9 در درخت زیر، به هش داده ها در شاخص های 8، 9، 5، 3، 1 نیاز داریم. هش (8،9) باید برابر با هش (4) باشد که با 5 هش می شود تا 2 تولید شود و هش با 3 برای تولید ریشه درخت 1 است. اگر دادههای نادرستی برای 9 ارائه شود، ریشه تغییر میکند - ما این را تشخیص میدهیم و نمیتوانیم شعبه را تأیید کنیم.
-
-```
-* = data required to generate proof
-
- 1*
- 2 3*
- 4 5* 6 7
-8* 9* 10 11 12 13 14 15
-
-```
-
-## بیشتر بخوانید {#further-reading}
-
-- [ارتقا Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
-- [ارتقا Ethereum: مرکلیزاسیون](https://eth2book.info/altair/part2/building_blocks/merkleization)
-- [پیاده سازی SSZ](https://github.com/ethereum/consensus-specs/issues/2138)
-- [ماشین حساب SSZ](https://simpleserialize.com/)
-- [SSZ.dev](https://www.ssz.dev/)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
deleted file mode 100644
index d4eb95c6b09..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md
+++ /dev/null
@@ -1,189 +0,0 @@
----
-title: تعریف ذخیره سازی مخفی Web3
-description: یک تعریف رسمی برای حافظه پنهان Web3
-lang: fa
-sidebarDepth: 2
----
-
-برای اینکه اپلیکیشن شما بر روی اتریوم کار کند، میتوانید از آبجکت Web3 که توسط کتابخانه web3.js فراهم شده استفاده کنید. در پس زمینه، این کتابخانه از طریق فراخوانی RPC به یک نود محلی متصل میشود. این کتابخانه با هر نود اتریومی که لایه RPC داشته باشد کار میکند.
-
-`web3` شامل آبجکت `eth` میباشد-web3.eth
-
-```js
-var fs = require("fs")
-var recognizer = require("ethereum-keyfile-recognizer")
-
-fs.readFile("keyfile.json", (err, data) => {
- var json = JSON.parse(data)
- var result = recognizer(json)
-})
-
-/** result
- * [ 'web3', 3 ] web3 (v3) keyfile
- * [ 'ethersale', undefined ] Ethersale keyfile
- * null invalid keyfile
- */
-```
-
-این مستندات **ورژن سوم** تعریف حافظه پنهان Web3 میباشند.
-
-## تعریف {#definition}
-
-رمزگذاری و رمزگشایی فایل نسبت به ورژن اول تا حد زیادی تغییری نکرده است، جز این که الگوریتم رمزنگاری دیگر روی AES-128-CBC تثبیت نشده است (AES-128-CTR اکنون لازمه حداقل است). بیشتر معانی و الگوریتمها همانند ورژن اول هستند، به جز `mac`، که به عنوان SHA3 (keccak-256) از ترکیب دومین 16 بایت از چپ از کلید مشتقشده به همراه کل `ciphertext` تعریف میشود.
-
-فایلهای کلید مخفی مستقیما در `~/.web3/keystore` (برای سیستمهایی مانند Unix) و `~/AppData/Web3/keystore` (برای ویندوز) ذخیره میشوند. ممکن است هر چیزی نام گذاری شوند، اما بهترین نام گذاری میتواند `.json` باشد که `` یک UUIDی 128 بیتی است که به کلید مخفی داده میشود (یک پروکسی حفظ حریم خصوصی برای آدرس کلیدهای مخفی).
-
-همه این فایلها یک پسورد مربوط به خودشان را دارند. برای استخراج کلید مخفی یک فایل `.json`، ابتدا باید کلید رمزگذاری فایل را استخراج کرد. در واقع این کار از طریق دریافت پسورد فایلها و دادن آن پسورد به تابع استخراج همانطور که توسط کلید `kdf` تعریف شدهاست، انجام میشود. پارامترهای استاتیک و دینامیک وابسته به KDF برای تابع KDF در کلید `kdfparams` توضیح داده شده است.
-
-PBKDF2 باید توسط تمام پیادهسازیهای دارای حداقل سازگاری پشتیبانی شود، البته به این موارد اشاره شده است:
-
-- `kdf`: `pbkdf2`
-
-kdfparamها برای PBKDF2 عبارتند از:
-
-- `prf`: باید `hmac-sha256` باشد (ممکن است در آینده تمدید شود);
-- `c`: تعداد تکرارها؛
-- `سالت`: سالت به PBKDF منتقل می شود؛
-- `dklen`: طول کلید استخراج شده. باید >=32 باشد.
-
-هنگامی که کلید فایل استخراج شد، باید از طریق استخراج MAC تأیید شود. MAC باید به عنوان هش SHA3 (keccak-256) آرایه بایت محاسبه شود که به عنوان الحاقات 16 بایت دوم سمت چپ کلید استخراج شده با محتویات کلید `متن رمزی` تشکیل شده است، به عنوان مثال.:
-
-```js
-KECCAK(DK[16..31] ++ )
-```
-
-(که در آن `++` اپراتور الحاق است)
-
-این مقدار باید با محتویات کلید `mac` مقایسه شود. اگر متفاوت هستند، یک رمز عبور جایگزین باید درخواست شود (یا عملیات لغو شود).
-
-پس از تأیید کلید فایل، متن رمز (کلید `متن رمز` در فایل) ممکن است با استفاده از الگوریتم رمزگذاری متقارن مشخص شده توسط کلید `رمز` رمزگشایی شود و از طریق کلید `پارام رمز` پارامترگذاری شود. اگر اندازه کلید استخراج شده و اندازه کلید الگوریتم با هم مطابقت نداشته باشند، بایت های صفر و سمت راست کلید استخراج شده باید به عنوان کلید الگوریتم استفاده شوند.
-
-همه پیادهسازیهایی که حداقل مطابقت را دارند باید از الگوریتم AES-128-CTR پشتیبانی کنند که به این صورت مشخص میشود:
-
-- `cipher: aes-128-ctr`
-
-این رمز، پارامترهای زیر را می گیرد که به عنوان کلید برای کلید cipherparams داده می شود:
-
-- `iv`: بردار اولیه سازی 128 بیتی برای رمز.
-
-کلید رمز، 16 بایت سمت چپ کلید استخراج شده است، یعنی `DK[0..15]`
-
-ایجاد/رمزگذاری یک کلید مخفی باید اساساً برعکس این دستورالعملها باشد. مطمئن شوید که `uuid`، `salt` و `iv` واقعا تصادفی هستند.
-
-علاوه بر فیلد `نسخه`، که باید به عنوان یک شناسه "سخت" نسخه عمل کند، پیادهسازیها ممکن است از `minorversion` برای ردیابی تغییرات کوچکتر و بدون شکست در قالب استفاده کنند.
-
-## بردارهای تست {#test-vectors}
-
-جزئیات:
-
-- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
-- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
-- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6`
-- `Password`: `testpassword`
-- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
-
-### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
-
-آزمایش بردار با استفاده از `AES-128-CTR` و `PBKDF2-SHA-256`:
-
-محتوای فایل `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`:
-
-```json
-{
- "crypto": {
- "cipher": "aes-128-ctr",
- "cipherparams": {
- "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
- },
- "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
- "kdf": "pbkdf2",
- "kdfparams": {
- "c": 262144,
- "dklen": 32,
- "prf": "hmac-sha256",
- "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
- },
- "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
- },
- "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
- "version": 3
-}
-```
-
-**متوسط**:
-
-`Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5`
-
-### Scrypt {#scrypt}
-
-بردار آزمایشی با استفاده از AES-128-CTR و Scrypt:
-
-```json
-{
- "crypto": {
- "cipher": "aes-128-ctr",
- "cipherparams": {
- "iv": "740770fce12ce862af21264dab25f1da"
- },
- "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
- "kdf": "scrypt",
- "kdfparams": {
- "dklen": 32,
- "n": 262144,
- "p": 1,
- "r": 8,
- "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
- },
- "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
- },
- "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
- "version": 3
-}
-```
-
-**متوسط**:
-
-`کلید استخراج شده`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c`
-
-## تغییرات از نسخه 1 {#alterations-from-v2}
-
-این نسخه چندین ناسازگاری را با نسخه 1 منتشر شده در [اینجا](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) برطرف می کند. آنها به طور خلاصه عبارتند از:
-
-- حروف بزرگ غیرقابل توجیه و متناقض است (حروف کوچک رمز، حروف مختلط Kdf، حروف بزرگ MAC).
-- به حریم خصوصی و ایرادات غیرضروری میپردازد.
-- `سالت` ذاتاً یک پارامتر تابع مشتق کلید است و شایسته آن است که با آن مرتبط شود، نه به طور کلی با رمزارز.
-- _SaltLen_ غیر ضروری است (فقط آن را از Salt استخراج کنید).
-- تابع استخراج کلید داده شده است، اما الگوریتم رمزنگاری به سختی مشخص شده است.
-- `نسخه` ذاتاً عددی است و در عین حال یک رشته است (نسخهسازی ساختاریافته با یک رشته امکانپذیر است، اما میتواند برای قالب فایل پیکربندی که به ندرت تغییر میکند، خارج از محدوده در نظر گرفته شود).
-- `KDF` و `رمز` به طور فکری مفاهيم خواهر و برادر هستند اما به طور متفاوت سازماندهي شده اند.
-- `MAC` از طریق یک قطعه داده آگنوستیک فضای خالی محاسبه می شود(!)
-
-برای ارائه فایل زیر، تغییراتی در قالب ایجاد شده است که از نظر عملکردی معادل مثال داده شده در صفحه پیوند قبلی است:
-
-```json
-{
- "crypto": {
- "cipher": "aes-128-cbc",
- "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
- "cipherparams": {
- "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
- },
- "kdf": "scrypt",
- "kdfparams": {
- "dklen": 32,
- "n": 262144,
- "p": 1,
- "r": 8,
- "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
- },
- "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
- "version": 1
- },
- "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
- "version": 2
-}
-```
-
-## تغییرات از نسخه 2 {#alterations-from-v2}
-
-نسخه 2 یک پیاده سازی اولیه ++C با تعدادی باگ بود. همه موارد ضروری بدون تغییر از آن باقی می مانند.
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md
deleted file mode 100644
index 519af1b03ef..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/index.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: لایهی شبکه
-description: مقدمه ای بر لایه شبکه اتریوم.
-lang: fa
-sidebarDepth: 2
----
-
-اتریوم یک شبکه همتا به همتا با هزاران گره است که باید بتوانند با استفاده از پروتکل های استاندارد شده با یکدیگر ارتباط برقرار کنند. "لایه شبکه" پشته ای از پروتکل ها است که به آن گره ها اجازه می دهد یکدیگر را پیدا کنند و اطلاعات را مبادله کنند. این شامل اطلاعات "شایعه" (ارتباطات یک به چند) در شبکه و همچنین تعویض درخواست ها و پاسخ ها بین گره های خاص (ارتباط یک به یک) است. هر گره برای اطمینان از ارسال و دریافت اطلاعات صحیح باید به قوانین شبکه خاصی پایبند باشد.
-
-نرمافزار کلاینت دارای دو بخش است (کلینتهای اجرا و کلاینتهای اجماع) که هر کدام دارای پشته شبکه مجزای خود هستند. علاوه بر برقراری ارتباط با سایر گرههای اتریوم، کلاینتهای اجرا و اجماع باید با یکدیگر ارتباط برقرار کنند. در این صفحه توضیح مقدماتی در مورد پروتکل هایی که این ارتباط را فعال می کنند ارائه می دهد.
-
-کلاینت های اجرا تراکنش ها را از طریق شبکه همتا به همتای لایه اجرا شایع می کنند. این امر نیاز به ارتباط رمزگذاری شده بین همتایان تایید شده دارد. هنگامی که یک اعتبارسنج برای پیشنهاد یک بلوک انتخاب می شود، تراکنش ها از مخزن تراکنش های محلی گره از طریق یک اتصال RPC محلی به کلاینت های اجماع منتقل می شوند که در بلوک های بیکن بسته بندی می شوند. کلاینت های اجماع سپس بلوک های بیکن را در شبکه p2p خود شایع می کنند. این به دو شبکه p2p جداگانه نیاز دارد: یکی اتصال کلاینت های اجرا برای شایعات تراکنش و دیگری اتصال کلاینت های اجماع برای شایعات بلوک.
-
-## موارد مورد نیاز {#prerequisites}
-
-مقداری دانش درباره [گره ها و کلاینت ihd](/developers/docs/nodes-and-clients/) اتریوم برای درک این صفحه مفید خواهد بود.
-
-## لایه اجرا {#execution-layer}
-
-پروتکل های شبکه لایه اجرا به دو پشته تقسیم می شوند:
-
-- پشته اکتشاف: بر روی UDP ساخته شده است و به یک گره جدید اجازه می دهد همتاهایی را برای اتصال پیدا کند
-
-- پشته DevP2P: در بالای TCP قرار می گیرد و گره ها را قادر به تبادل اطلاعات می کند
-
-هر دو پشته به صورت موازی کار می کنند. پشته اکتشاف، شرکتکنندگان جدید شبکه را به شبکه تغذیه میکند و پشته DevP2P تعاملات آنها را فعال میکند.
-
-### اکتشاف {#discovery}
-
-اکتشاف فرآیند یافتن گره های دیگر در شبکه است. این بوت استرپ با استفاده از مجموعه کوچکی از بوتنودها انجام می شود (گره هایی که آدرس آنها [هاردکد](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) در کلاینت است تا بتوان آنها را فورا پیدا کرد و کلاینت را به همتایان متصل کرد). این بوتنودها فقط برای معرفی یک گره جدید به مجموعهای از همتایان وجود دارند - این تنها هدف آنهاست، آنها در کارهای عادی کلاینت مانند همگامسازی زنجیره شرکت نمیکنند و تنها در اولین باری که کلاینت چرخانده میشود، استفاده میشوند.
-
-پروتکل مورد استفاده برای تعاملات گره-بوتنود یک شکل تغییر یافته از [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) است که از [جدول هش توزیع شده](https://en.wikipedia.org/wiki/Distributed_hash_table) برای به اشتراک گذاری لیست گره ها استفاده می کند. هر گره دارای نسخه ای از این جدول است که حاوی اطلاعات مورد نیاز برای اتصال به نزدیکترین همتایان خود است. این "نزدیک" بار جغرافیایی ندارد - بلکه در فاصله با شباهت شناسه گره تعریف می شود. جدول هر گره به عنوان یک ویژگی امنیتی به طور منظم به روز می شود. به عنوان مثال، در [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5)، گرههای پروتکل اکتشاف همچنین میتوانند «تبلیغاتی» را ارسال کنند که پروتکلهای فرعی را که کلاینت پشتیبانی میکند، نمایش میدهد و به همتایان اجازه میدهد در مورد پروتکلهایی که هر دو میتوانند برای برقراری ارتباط استفاده کنند، مذاکره کنند.
-
-اکتشاف با یک بازی پینگ پنگ شروع می شود. یک پینگ پنگ موفق، گره جدید را به یک بوت نود "پیوند" می کند. پیام اولیه ای که به بوت نود از وجود گره جدیدی که وارد شبکه می شود هشدار می دهد `PING` است. این `PING` شامل اطلاعات هش شده در مورد گره جدید، بوت نود و یک مهر زمان انقضا است. بوتنود `PING` را دریافت میکند و یک `PONG` حاوی هش `PING` برمیگرداند. اگر هشهای `PING` و `PONG` مطابقت داشته باشند، ارتباط بین گره جدید و بوتنود تأیید میشود و گفته میشود که آنها "متصل" شدهاند.
-
-پس از اتصال، گره جدید می تواند یک درخواست `FIND-NEIGHBOURS` را به بوت نود ارسال کند. داده های بازگردانده شده توسط بوت نود شامل لیستی از همتایان است که گره جدید می تواند به آنها متصل شود. اگر گرهها متصل نباشند، درخواست `FIND-NEIGHBOURS` با شکست مواجه میشود، بنابراین گره جدید نمیتواند وارد شبکه شود.
-
-هنگامی که گره جدید لیستی از همسایگان را از بوت نود دریافت می کند، مبادله PING-PONG را با هر یک از آنها آغاز می کند. پینگپنگهای موفق، گره جدید را با همسایگانش پیوند میدهند و تبادل پیام را ممکن میسازند.
-
-```
-start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours
-```
-
-کلاینت های اجرا در حال حاضر از پروتکل اکتشاف [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) استفاده می کنند و تلاش فعالی برای انتقال به پروتکل [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) وجود دارد.
-
-#### ENR: رکوردهای گره اتریوم {#enr}
-
-این [رکورد گره اتریوم (ENR)](/developers/docs/networking-layer/network-addresses/) یک شی است که شامل سه عنصر اساسی است: یک امضا (هش از محتویات رکورد ساخته شده بر اساس برخی از طرح های هویت توافق شده)، یک شماره دنباله ای که تغییرات را در رکورد ردیابی می کند، و یک لیست دلخواه از جفت های کلیدهای ارزش. این یک فرمت مقاوم در برابر آینده است که امکان تبادل آسان اطلاعات شناسایی بین همتایان جدید را فراهم می کند و فرمت [آدرس شبکه](/developers/docs/networking-layer/network-addresses) ترجیحی برای گره های اتریوم است.
-
-#### چرا اکتشاف بر اساس UDP ساخته شده است؟ {#why-udp}
-
-UDP هیچ گونه بررسی خطا، ارسال مجدد بسته های ناموفق، یا باز و بسته شدن پویا اتصالات را پشتیبانی نمی کند - در عوض، صرف نظر از اینکه آیا با موفقیت دریافت شده است یا خیر، فقط یک جریان مداوم از اطلاعات را به سمت یک هدف شلیک می کند. این عملکرد حداقلی همچنین به هزینه حداقلی تبدیل می شود و این نوع اتصال را بسیار سریع می کند. برای اکتشاف، جایی که یک گره به سادگی میخواهد حضور خود را نشان دهد تا پس از آن یک ارتباط رسمی با همتا برقرار کند، UDP کافی است. با این حال، برای بقیه پشته شبکه، UDP برای هدف امورات مناسب نیست. تبادل اطلاعات بین گرهها بسیار پیچیده است و بنابراین به پروتکل کاملتری نیاز دارد که بتواند از ارسال مجدد، بررسی خطا و غیره پشتیبانی کند. سربار اضافی مرتبط با TCP ارزش عملکرد اضافی را دارد. بنابراین، اکثر پشته P2P روی TCP عمل می کند.
-
-### DevP2P {#devp2p}
-
-DevP2P خودش مجموعه کاملی از پروتکلهایی است که اتریوم برای ایجاد و نگهداری شبکه همتا به همتا پیادهسازی میکند. پس از ورود گره های جدید به شبکه، تعاملات آنها توسط پروتکل هایی در پشته [DevP2P](https://github.com/ethereum/devp2p) کنترل می شود. همه اینها در بالای TCP قرار دارند و شامل پروتکل انتقال RLPx، پروتکل سیمی و چندین پروتکل فرعی هستند. پروتکل [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) پروتکلی است که بر شروع، احراز هویت و حفظ نشست ها بین گره ها حاکم است. RLPx پیام ها را با استفاده از RLP (پیشوند طول بازگشتی) رمزگذاری می کند که یک روش بسیار کارآمد برای رمزگذاری داده ها در یک ساختار حداقلی برای ارسال بین گره ها است.
-
-یک جلسه RLPx بین دو گره با یک ارتباط گیری رمزنگاری اولیه آغاز می شود. این مرحله شامل ارسال یک پیام احراز هویت توسط گره است که سپس توسط همتا تایید می شود. در تأیید موفقیت آمیز، همتا یک پیام تأیید اعتبار برای بازگشت به گره آغازگر تولید می کند. این یک فرآیند تبادل کلید است که گره ها را قادر می سازد به صورت خصوصی و ایمن با هم ارتباط برقرار کنند. یک ارتباط گیری رمزنگاری شده موفق، سپس هر دو گره را تحریک می کند تا پیام "سلام" را به یکدیگر "روی سیم" ارسال کنند. پروتکل سیمی با تبادل موفقیت آمیز پیام های سلام آغاز می شود.
-
-پیام های سلام شامل موارد زیر است:
-
-- نسخه پروتکل
-- شناسه کلاینت
-- پورت
-- شناسه گره
-- لیستی از پروتکل های فرعی پشتیبانی شده
-
-این اطلاعات مورد نیاز برای یک تعامل موفق است زیرا مشخص می کند که چه قابلیت هایی بین هر دو گره به اشتراک گذاشته می شود و ارتباطات را پیکربندی می کند. یک فرآیند مذاکره پروتکل فرعی وجود دارد که در آن لیست های پروتکل های فرعی پشتیبانی شده توسط هر گره با هم مقایسه می شوند و مواردی که برای هر دو گره مشترک هستند می توانند در نشست استفاده شوند.
-
-همراه با پیام های سلام، پروتکل سیم همچنین می تواند یک پیام "قطع اتصال" ارسال کند که به همتایان هشدار می دهد که اتصال بسته خواهد شد. پروتکل سیمی همچنین شامل پیام های PING و PONG است که به صورت دوره ای برای باز نگه داشتن یک جلسه ارسال می شوند. بنابراین مبادلات پروتکل RLPx و سیمی پایههای ارتباط بین گرهها را ایجاد میکنند و داربستی را برای اطلاعات مفیدی که طبق یک پروتکل فرعی خاص مبادله میشوند فراهم میکنند.
-
-### پروتکل های فرعی {#sub-protocols}
-
-#### پروتکل سیمی {#wire-protocol}
-
-هنگامی که همتاها متصل می شوند و یک نشست RLPx شروع می شود، پروتکل سیمی نحوه ارتباط همتاها را مشخص می کند. در ابتدا، پروتکل سیمی سه وظیفه اصلی را تعریف کرد: همگام سازی زنجیره ای، انتشار بلوک و تبادل تراکنش. با این حال، هنگامی که اتریوم به اثبات سهام روی آورد، انتشار بلوک و همگام سازی زنجیره بخشی از لایه اجماع شد. مبادله تراکنش هنوز در اختیار کلاینت اجرا است. تبادل تراکنش به مبادله تراکنش های معلق بین گره ها اشاره دارد تا سازندگان بلوک بتوانند برخی از آنها را برای گنجاندن در بلوک بعدی انتخاب کنند. اطلاعات دقیق درباره این وظایف [اینجا](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) موجود است. کلاینت هایی که از این پروتکل های فرعی پشتیبانی می کنند، آنها را از طریق [JSON-RPC](/developers/docs/apis/json-rpc/) در معرض دید قرار می دهند.
-
-#### les (پروتکل فرعی سبک اتریوم) {#les}
-
-این یک پروتکل حداقلی برای همگام سازی کلاینت های سبک است. به طور سنتی این پروتکل به ندرت مورد استفاده قرار میگرفت زیرا گرههای کامل برای ارائه دادهها به کلاینت های سبک بدون ایجاد انگیزه مورد نیاز هستند. رفتار پیشفرض کلاینتهای اجرا این است که دادههای کلاینت سبک را روی les ارائه نمیکنند. اطلاعات بیشتر در les [جزئیات فنی](https://github.com/ethereum/devp2p/blob/master/caps/les.md) موجود است.
-
-#### Snap {#snap}
-
-[پروتکل snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) یک برنامه افزودنی اختیاری است که به همتایان اجازه میدهد تا تصاویر لحظه ای از وضعیتهای اخیر را مبادله کنند، و به همتایان اجازه میدهد تا دادههای حساب و ذخیرهسازی را بدون نیاز به دانلود گرههای میانی درخل مرکل تأیید کنند.
-
-#### Wit (پروتکل شاهد) {#wit}
-
-[پروتکل شاهد](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) یک برنامه افزودنی اختیاری است که تبادل شاهدان حالت را بین همتایان امکانپذیر میکند و به همگامسازی کلاینت ها با نوک زنجیره کمک میکند.
-
-#### Whisper {#whisper}
-
-Whisper پروتکلی بود که هدف آن ارسال پیام ایمن بین همتایان بدون نوشتن هیچ گونه اطلاعاتی در بلاکچین بود. بخشی از پروتکل سیم DevP2P بود اما اکنون منسوخ شده است. دیگر [پروژه های مرتبط](https://wakunetwork.com/) با اهداف مشابه وجود دارند.
-
-## لایه اجماع {#consensus-layer}
-
-کلاینت های اجماع در یک شبکه همتا به همتا جداگانه با مشخصات متفاوت شرکت می کنند. کلاینت های اجماع باید در شیوع بلوک شرکت کنند تا بتوانند بلوکهای جدید را از همتایان دریافت کنند و زمانی که نوبت به پیشنهاد بلوک رسید، آنها را پخش کنند. مشابه لایه اجرا، ابتدا به یک پروتکل اکتشاف نیاز است تا یک گره بتواند همتایان را پیدا کند و نشست های امنی را برای تبادل بلوک ها، گواهی ها و غیره ایجاد کند.
-
-### اکتشاف {#consensus-discovery}
-
-مشابه کلاینت های اجرا، کلاینت های اجماع از [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) روی UDP برای یافتن همتایان استفاده می کنند. پیادهسازی لایه اجماع discv5 با اجرای کلاینتهای اجرا تنها از این جهت متفاوت است که شامل مبدّلی است که discv5 را به پشته [libP2P](https://libp2p.io/) متصل میکند و DevP2P را منسوخ میکند. جلسههای RLPx لایه اجرا به نفع ارتباطگیری کانال ضد-نویز libP2P منسوخ شده است.
-
-### ENRها {#consensus-enr}
-
-ENR برای گره های اجماع شامل کلید عمومی گره، آدرس IP، پورت های UDP و TCP و دو فیلد خاص اجماع است: فیلد بیتی زیرشبکه گواهی و کلید `eth2`. مورد اول یافتن همتایان شرکت کننده در زیرشبکه های شایعات گویای گواهی را برای گره ها آسان تر می کند. کلید `eth2` نیز حاوی اطلاعاتی در مورد اینکه گره از کدام نسخه فورک اتریوم استفاده می کند، اطمینان حاصل می کند که همتایان به اتریوم مناسب متصل هستند.
-
-### libP2P {#libp2p}
-
-پشته libP2P از تمام ارتباطات پس از اکتشاف پشتیبانی می کند. کلاینت ها می توانند شماره گیری کرده و به IPv4 و/یا IPv6 همانطور که در ENR آنها تعریف شده است گوش دهند. پروتکل های لایه libP2P را می توان به دو حوزه شایعات و درخواست/پاسخ تقسیم کرد.
-
-### شایعات {#gossip}
-
-دامنه شایعات شامل تمام اطلاعاتی است که باید به سرعت در سراسر شبکه پخش شود. این شامل بلوک های بیکن، اثبات ها، امضاها، خروج و جریمه شدن است. این با استفاده از libP2P gossipsub v1 منتقل میشود و متکی به ابردادههای مختلفی است که به صورت محلی در هر گره ذخیره میشوند، از جمله حداکثر اندازه محمولههای شایعات برای دریافت و ارسال. اطلاعات دقیق در مورد دامنه شایعات [اینجا](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub) موجود است.
-
-### درخواست-پاسخ {#request-response}
-
-دامنه درخواست-پاسخ شامل پروتکل هایی برای کلاینت هایی است که اطلاعات خاصی را از همتایان خود درخواست می کنند. به عنوان مثال میتوان به درخواست بلوکهای بیکن خاص با هشهای ریشه خاص یا در محدودهای از اسلاتها اشاره کرد. پاسخ ها همیشه به صورت بایت های رمزگذاری شده SSZ فشرده شده برگردانده می شوند.
-
-## چرا کلاینت اجماع SSZ را به RLP ترجیح می دهد؟ {#ssz-vs-rlp}
-
-SSZ مخفف سریال سازی ساده است. از افست های ثابتی استفاده می کند که رمزگشایی بخش های جداگانه یک پیام رمزگذاری شده را بدون نیاز به رمزگشایی کل ساختار آسان می کند، که برای کلاینت اجماع بسیار مفید است زیرا می تواند به طور موثر بخش های خاصی از اطلاعات را از پیام های رمزگذاری شده بگیرد. همچنین به طور خاص برای ادغام با پروتکلهای مرکل، با افزایش کارایی مرتبط برای Merkleization طراحی شده است. از آنجایی که همه هش ها در لایه اجماع ریشه های مرکل هستند، این باعث بهبود قابل توجهی می شود. SSZ همچنین نمایش منحصر به فرد اعداد را تضمین می کند.
-
-## اتصال کلاینت های اجرا و اجماع {#connecting-clients}
-
-کلاینت های اجماع و اجرا به صورت موازی اجرا می شوند. آنها باید به هم متصل شوند تا کلاینت اجماع بتواند دستورالعمل هایی را برای کلاینت اجرا ارائه دهد و کلاینت اجرا بتواند بسته هایی از تراکنش ها را به کلاینت اجماع ارسال کند تا در بلوک های بیکن گنجانده شوند. ارتباط بین دو کلاینت را می توان با استفاده از یک اتصال RPC محلی به دست آورد. یک API معروف به ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) دستورالعمل های ارسال شده بین دو کلاینت را تعریف می کند. از آنجایی که هر دو کلاینت پشت یک هویت شبکه قرار دارند، یک ENR (رکورد گره اتریوم) به اشتراک می گذارند که حاوی یک کلید جداگانه برای هر کلاینت (کلید eth1 و کلید eth2) است.
-
-خلاصه ای از جریان کنترل در زیر نشان داده شده است، همراه با پشته شبکه مربوطه در پرانتز.
-
-### وقتی کلاینت اجماع یک تولیدکننده بلوک نیست: {#when-consensus-client-is-not-block-producer}
-
-- کلاینت اجماع یک بلوک را از طریق پروتکل شایعات بلوک دریافت می کند (p2p اجماع)
-- کلاینت اجماع بلوک را از قبل تأیید می کند، یعنی اطمینان حاصل می کند که از یک فرستنده معتبر با متادیتا صحیح رسیده است
-- تراکنش های موجود در بلوک به عنوان یک پیلود اجرا (اتصال RPC محلی) به لایه اجرا ارسال می شوند
-- لایه اجرا تراکنش ها را اجرا می کند و وضعیت موجود در هدر بلوک را تأیید می کند (یعنی تطابق هش ها را بررسی می کند)
-- لایه اجرا داده های اعتبارسنج را به لایه اجماع برمی گرداند، بلوک هم الان به عنوان تایید شده در نظر گرفته می شود (اتصال RPC محلی)
-- لایه اجماع، بلوک را به سر بلاکچین خود اضافه می کند و آن را تأیید می کند، تأیید را از طریق شبکه پخش می کند (p2p اجماع)
-
-### وقتی کلاینت اجماع یک تولید کننده بلوک است: {#when-consensus-client-is-block-producer}
-
-- کلاینت اجماع اطلاعیه دریافت می کند که تولید کننده بلوک بعدی است (p2p اجماع)
-- لایه اجماع روش `ایجاد بلوک` را در کلاینت اجرا فرا می خواند (RPC محلی)
-- لایه اجرا به مخزن تراکنش که توسط پروتکل شایعات تراکنش پر شده است دسترسی دارد (p2p اجرا)
-- کلاینت اجرا تراکنش ها را در یک بلوک بسته بندی می کند، تراکنش ها را اجرا می کند و یک هش بلوک ایجاد می کند
-- کلاینت اجماع تراکنش ها و هش بلوک را از کلاینت اجرا می گیرد و به بلوک بیکن اضافه می کند (RPC محلی)
-- کلاینت اجماع بلوک را از طریق پروتکل شایعات بلوک پخش می کند (p2p اجماع)
-- سایر کلاینت ها بلوک پیشنهادی را از طریق پروتکل شایعات بلوک دریافت می کنند و همانطور که در بالا توضیح داده شد اعتبارسنجی می کنند (p2p اجماع)
-
-هنگامی که بلوک توسط اعتبارسنج های کافی تأیید شد، به سر زنجیره اضافه می شود، تنظیم می شود و در نهایت نهایی می شود.
-
-![](cons_client_net_layer.png) ![](exe_client_net_layer.png)
-
-شماتیک لایه شبکه برای مشتریان اجماع و اجرا، از [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
-
-## اطلاعات بیشتر {#further-reading}
-
-[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [مشخصات شبکه لایه اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia به discv5](https://vac.dev/kademlia-to-discv5) [مقاله kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [معرفی p2p اتریوم ](https://p2p.paris/en/talks/intro-ethereum-networking/) [رابطه eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [ویدیوی مرج و جزئیات کلاینت eth2](https://www.youtube.com/watch?v=zNIrIninMgg)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md
deleted file mode 100644
index f1d459e5c81..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: آدرسهای شبکه
-description: مقدمه ای بر آدرس های شبکه.
-lang: fa
-sidebarDepth: 2
----
-
-گره های اتریوم برای اتصال به همتایان باید خود را با برخی از اطلاعات اولیه شناسایی کنند. برای اطمینان از اینکه هر همتای بالقوه می تواند این اطلاعات را تفسیر کند، در یکی از سه فرمت استاندارد شده ای که هر گره اتریوم می تواند درک کند، ارسال می شود: multiaddr، enode، یا Ethereum Node Records (ENR). ENR ها استاندارد فعلی آدرس های شبکه اتریوم هستند.
-
-## موارد مورد نیاز {#prerequisites}
-
-برای درک این صفحه، مقداری آشنایی با [لایه شبکه](/developers/docs/networking-layer/) اتریوم لازم است.
-
-## Multiaddr {#multiaddr}
-
-قالب اصلی آدرس گره اتریوم 'multiaddr' (مخفف 'multi-addresses') بود. Multiaddr یک قالب جهانی است که برای شبکه های همتا به همتا طراحی شده است. آدرس ها به صورت جفت های کلید-مقدار با کلیدها و مقادیری که با یک اسلش رو به جلو از هم جدا شده اند نشان داده می شوند. به عنوان مثال، multiaddr برای یک گره با آدرس IPv4 `192.168.22.27` در حال گوش دادن به پورت TCP `33000` به نظر می رسد:
-
-`/ip4/192.168.22.27/tcp/33000`
-
-برای یک گره اتریوم، multiaddr شامل شناسه گره (هش کلید عمومی آنها) است:
-
-`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br`
-
-## Enode {#enode}
-
-یک Enode راهی برای شناسایی گره اتریوم با استفاده از فرمت آدرس URL است. شناسه گره هگزادسیمال در قسمت نام کاربری URL که از میزبان جدا شده است با استفاده از علامت @ کدگذاری می شود. نام میزبان فقط می تواند به عنوان یک آدرس IP داده شود. نام های DNS مجاز نیستند. پورت موجود در قسمت hostname پورت گوش دادن TCP است. اگر پورت های TCP و UDP (کشف) متفاوت باشند، پورت UDP به عنوان پارامتر پرس و جو "discport" مشخص می شود
-
-در مثال زیر، گره URL گرهای را با آدرس IP `10.3.58.6`، پورت TCP `30303` و پورت کشف UDP `30301` توصیف میکند.
-
-`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301`
-
-## سوابق گره اتریوم (ENR) {#enr}
-
-Ethereum Node Records (ENRs) یک فرمت استاندارد شده برای آدرس های شبکه در اتریوم است. آنها جایگزین multiaddr و enodes می شوند. اینها به ویژه مفید هستند زیرا اجازه تبادل اطلاعات بیشتر بین گره ها را می دهند. ENR شامل یک امضا، شماره دنباله و فیلدهایی است که طرح هویت مورد استفاده برای تولید و اعتبارسنجی امضاها را شرح می دهد. ENR همچنین می تواند با داده های دلخواه سازماندهی شده به عنوان جفتهای مقدار کلید پر شود. این جفتهای مقدار کلید حاوی آدرس IP گره و اطلاعات مربوط به پروتکلهای فرعی هستند که گره قادر به استفاده از آن است. کلاینتهای اجماع از یک [ساختار خاص ENR](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) برای شناسایی نودهای راهاندازی استفاده میکنند و همچنین یک فیلد `eth2` حاوی اطلاعات مربوط به فورک فعلی اتریوم و زیرشبکه شایعه تصدیق را در بر میگیرد (این، گره را به یک مجموعه خاصی از همتایان که گواهینامه های آنها با هم جمع شده است، وصل میکند).
-
-## اطلاعات بیشتر {#further-reading}
-
-[EIP-778: سوابق گره اتریوم (ENR)](https://eips.ethereum.org/EIPS/eip-778) [آدرسهای شبکه در اتریوم](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/)
diff --git a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md
deleted file mode 100644
index aad0835e42a..00000000000
--- a/public/content/translations/fa/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: شبکه پرتال
-description: مروری بر شبکه پورتال - یک شبکه در حال توسعه که برای پشتیبانی از مشتریان با منابع کم طراحی شده است.
-lang: fa
----
-
-اتریوم شبکه ای متشکل از رایانه هایی است که نرم افزار کاربر اتریوم را اجرا می کنند. هر یک از این کامپیوترها "گره" نامیده می شوند. نرم افزار کاربر به یک گره اجازه می دهد تا داده ها را در شبکه اتریوم ارسال و دریافت کند و داده ها را بر اساس قوانین پروتکل اتریوم تأیید می کند. گره ها داده های تاریخی زیادی را در فضای ذخیره سازی دیسک خود نگه می دارند و زمانی که بسته های جدیدی از اطلاعات را که به نام بلوک ها شناخته می شوند از سایر گره های شبکه دریافت می کنند، به آن اضافه می کنند. این برای بررسی اینکه یک گره همیشه اطلاعاتی مطابق با بقیه شبکه دارد ضروری است. این بدان معناست که اجرای یک گره می تواند به فضای دیسک زیادی نیاز داشته باشد. برخی از عملیات گره ها می توانند به مقدار زیادی RAM نیز نیاز داشته باشند.
-
-برای دور زدن این مشکل ذخیره سازی دیسک، گره های "سبک" توسعه یافته اند که به جای ذخیره کردن همه آنها، اطلاعات را از گره های کامل درخواست می کنند. با این حال، این بدان معنی است که گره سبک به طور مستقل اطلاعات را تأیید نمی کند و در عوض به گره دیگری اعتماد دارد. همچنین به این معنی است که گره های کامل باید کار اضافی را برای خدمت به آن گره های سبک انجام دهند.
-
-شبکه پورتال یک طراحی شبکه جدید برای اتریوم است که هدف آن حل مشکل در دسترس بودن داده برای گره های "سبک" بدون نیاز به اعتماد یا اعمال فشار اضافی بر گره های کامل، با اشتراک گذاری داده های لازم در قطعات کوچک در سراسر شبکه است.
-
-جزئیات بیشتر [گره ها و کاربرها](/developers/docs/nodes-and-clients/)
-
-## چرا به شبکه پورتال نیاز داریم {#why-do-we-need-portal-network}
-
-گره های اتریوم کپی کامل یا جزئی خود از بلاک چین اتریوم را ذخیره می کنند. این کپی محلی، برای اعتبارسنجی تراکنش ها و اطمینان از اینکه گره از زنجیره صحیح پیروی می کند استفاده می شود. این دادههای ذخیرهشده محلی، به گرهها اجازه میدهند تا بدون نیاز به اعتماد به هیچ نهاد دیگری، بهطور مستقل تأیید کنند که دادههای ورودی معتبر و صحیح هستند.
-
-این کپی محلی از بلاک چین و داده های مربوط به وضعیت و دریافت، فضای زیادی را در هارد دیسک گره اشغال می کند. به عنوان مثال، یک هارد دیسک 2 ترابایتی برای اجرای یک گره با استفاده از [Geth](https://geth.ethereum.org) جفت شده با یک کلاینت اجماع توصیه می شود. با استفاده از Snap Sync، که فقط داده های زنجیره ای از مجموعه نسبتاً جدید بلوک ها را ذخیره می کند، Geth معمولاً حدود 650 گیگابایت فضای دیسک را اشغال می کند اما در حدود 14 گیگابایت در هفته رشد می کند (شما می توانید گره را به صورت دوره ای به 650 گیگابایت کاهش دهید).
-
-این بدان معناست که اجرای گرهها میتواند گران باشد، زیرا مقدار زیادی از فضای دیسک باید به اتریوم اختصاص داده شود. چندین راه حل برای این مشکل در نقشه راه اتریوم وجود دارد، از جمله [انقضای تاریخچه](/roadmap/statelessness/#history-expiry)، [انقضای وضعیت](/roadmap/statelessness/#state-expiry) و [بی حالت بودن](/roadmap/statelessness/). با این حال، احتمالاً چندین سال تا اجرایی شدن فاصله دارد. همچنین [گره های سبک](/developers/docs/nodes-and-clients/light-clients/) وجود دارند که کپی خود را از داده های زنجیره ای ذخیره نمی کنند، آنها داده های مورد نیاز خود را از گره های کامل درخواست می کنند. با این حال، این بدان معناست که گرههای سبک باید به گرههای کامل اعتماد کنند تا دادههای صادقانه ارائه کنند و همچنین بر گرههای کاملی که باید دادههای مورد نیاز گرههای سبک را ارائه دهند، استرس وارد میکند.
-
-هدف شبکه پورتال ارائه روشی جایگزین برای گره های سبک برای دریافت داده های خود است که نیازی به اعتماد یا اضافه کردن قابل توجه به کاری که باید توسط گره های کامل انجام شود ندارد. روشی که این کار انجام خواهد شد، معرفی روشی جدید برای گرههای اتریوم برای به اشتراک گذاری داده ها در سراسر شبکه است.
-
-## شبکه پورتال چگونه کار می کند؟ {#how-does-portal-network-work}
-
-گره های اتریوم پروتکل های سختگیرانه ای دارند که نحوه ارتباط آنها با یکدیگر را مشخص می کند. کاربرهای اجرا با استفاده از مجموعهای از پروتکلهای فرعی به نام [DevP2P](/developers/docs/networking-layer/#devp2p) ارتباط برقرار میکنند، در حالی که کاربرهای اجماع از پشته متفاوتی از پروتکلهای فرعی به نام [libP2P](/developers/docs/networking-layer/#libp2p) استفاده میکنند. اینها انواع داده هایی را که می توانند بین گره ها ارسال شوند، تعریف می کنند.
-
-![devP2P و libP2P](portal-network-devp2p-libp2p.png)
-
-گرهها همچنین میتوانند دادههای خاصی را از طریق [JSON-RPC API](/developers/docs/apis/json-rpc/) ارائه دهند، به این ترتیب برنامهها و کیف پولها اطلاعات را با گرههای اتریوم مبادله میکنند. با این حال، هیچ یک از اینها پروتکل های ایده آلی برای ارائه داده به کاربرهای سبک نیستند.
-
-کاربرهای سبک در حال حاضر نمی توانند قطعات خاصی از داده های زنجیره ای را از طریق DevP2P یا libP2p درخواست کنند زیرا این پروتکل ها فقط برای فعال کردن همگام سازی زنجیره ای و شایعه پراکنی بلوک ها و تراکنش ها طراحی شده اند. کاربرهای سبک نمیخواهند این اطلاعات را دانلود کنند زیرا این کار باعث میشود که آنها "سبک" بودن را متوقف کنند.
-
-JSON-RPC API یک انتخاب ایدهآل برای درخواست دادههای کاربر سبک نیست، زیرا بر اتصال به یک گره کامل خاص یا ارائهدهنده RPC متمرکز است که میتواند به دادهها سرویس دهد. این بدان معناست که کاربر سبک باید به صداقت آن گره/ارائهدهنده خاص اعتماد کند، و همچنین گره کامل ممکن است مجبور باشد بسیاری از درخواستهای بسیاری از مشتریان سبک را رسیدگی کند و به پهنای باند مورد نیاز آنها بیفزاید.
-
-هدف شبکه پورتال این است که در کل طراحی، به طور خاص برای سبکی، خارج از محدودیت های طراحی مشتریان موجود اتریوم، تجدید نظر کند.
-
-ایده اصلی شبکه پورتال این است که با فعال کردن اطلاعات مورد نیاز مشتریان سبک، مانند دادههای تاریخی و هویت سر فعلی زنجیره، بهترین بیتها از پشته شبکه فعلی را دریافت کند که از طریق یک شبکه غیرمتمرکز همتا به همتا به سبک DevP2P با استفاده از [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (شبیه Bittorrent) ارائه خواهند شد.
-
-ایده این است که بخشهای کوچکی از کل دادههای تاریخی اتریوم و برخی مسئولیتهای گره خاص به هر گره اضافه شود. سپس، درخواستها با جستجوی گرههایی که دادههای خاص درخواست شده را ذخیره میکنند، و با بازیابی آنها از آنها ارائه میشوند.
-
-این مدل معمولی گرههای نوری را وارونه میکند که یک گره را پیدا میکنند و از آنها درخواست میکنند تا حجم زیادی از داده را فیلتر و ارائه کنند. در عوض، آنها به سرعت شبکه بزرگی از گرهها را فیلتر میکنند که هر کدام حجم کمی از دادهها را مدیریت میکنند.
-
-هدف این است که به شبکه غیرمتمرکز مشتریان پورتال سبک وزن اجازه دهیم تا:
-
-- سر زنجیره را دنبال کند
-- داده های زنجیره ای اخیر و گذشته را همگام کند
-- اطلاعات وضعیت را بازیابی کند
-- تراکنش ها را پخش کند
-- تراکنش ها را با استفاده از [EVM](/developers/docs/evm/) اجرا کند
-
-مزایای این طراحی شبکه عبارتند از:
-
-- کاهش وابستگی به ارائه دهندگان متمرکز
-- کاهش استفاده از پهنای باند اینترنت
-- همگام سازی حداقل یا صفر
-- قابل دسترسی برای دستگاه های دارای محدودیت منابع (<1 گیگابایت رم، <100 مگابایت فضای دیسک، 1 CPU)
-
-نمودار زیر عملکردهای کاربرهای موجود را نشان میدهد که میتواند توسط شبکه پورتال ارائه شود و کاربران را قادر میسازد تا به این عملکردها در دستگاههای با منابع بسیار کم دسترسی داشته باشند.
-
-![جدول شبکه پورتال](portal-network-table2.png)
-
-## تنوع مشتری به طور پیش فرض {#client-diversity-as-default}
-
-توسعه دهندگان شبکه پورتال همچنین طراحی را برای ساختن سه مشتری مجزای شبکه پورتال از روز اول انتخاب کردند.
-
-کاربران شبکه پورتال عبارتند از:
-
-- [Trin](https://github.com/ethereum/trin): نوشته شده در Rust
-- [Fluffy](https://nimbus.team/docs/fluffy.html): نوشته شده به زبان Nim
-- [فوق سبک](https://github.com/ethereumjs/ultralight): نوشته شده در تایپ اسکریپت
-- [Shisui](https://github.com/GrapeBaBa/shisui): نوشته شده در Go
-
-داشتن چندین پیادهسازی کاربر مستقل، انعطافپذیری و عدم تمرکز شبکه اتریوم را افزایش میدهد.
-
-اگر یک کاربر مشکلات یا آسیب پذیری هایی را تجربه کند، سایر کاربرها می توانند به آرامی به کار خود ادامه دهند و از یک نقطه شکست جلوگیری کنند. علاوه بر این، پیادهسازیهای متنوع مشتری، نوآوری و رقابت را تقویت میکند، باعث پیشرفتها و کاهش خطرات تککِشتی در اکوسیستم میشود.
-
-## بیشتر بخوانید {#futher-reading}
-
-- [شبکه پورتال (Piper Merriam در Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA).
-- [دیسکورد شبکه پورتال](https://discord.gg/CFFnmE7Hbs)
-- [وب سایت شبکه پورتال](https://www.ethportal.net/)
diff --git a/public/content/translations/fa/26) Miscellaneous/about/index.md b/public/content/translations/fa/26) Miscellaneous/about/index.md
deleted file mode 100644
index 10f2e68e7fa..00000000000
--- a/public/content/translations/fa/26) Miscellaneous/about/index.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: درباره ما
-description: درباره تیم، جامعه و ماموریت ethereum.org
-lang: fa
----
-
-# در ارتباط با ethereum.org {#about-ethereumorg}
-
-ethereum.org یک منبع عمومی منبع باز برای جامعه اتریوم است که هر کسی میتواند با آن همکاری کند. ما یک تیم اصلی کوچک داریم که با مشارکت هزاران نفر از اعضای جامعه در سراسر جهان به حفظ و توسعه سایت اختصاص داده شده است.
-
-## یادداشتی در مورد اسامی {#a-note-on-names}
-
-معمولاً افراد نامها را در چشمانداز اتریوم اشتباه میگیرند، که میتواند منجر به مدلهای ذهنی ضعیف در مورد نحوه عملکرد اتریوم شود. در اینجا یک توضیح سریع برای روشن کردن موارد وجود دارد:
-
-### اتریوم {#ethereum}
-
-اتریوم یک شبکه عمومی، یک بلاکچین و یک پروتکل منبع باز است متعلق به یک جامعه جهانی متشکل از ده ها هزار توسعه دهنده، اپراتورهای گره، دارندگان ETH و کاربرانی که توسط آنها عملیاتی می شود، حکمرانی می شود و مدیریت می شود.
-
-[جزئیات بیشتر اتریوم](/what-is-ethereum/)
-
-[جرئیات بیشتر حکمرانی اتریوم](/governance/)
-
-### اتر (ETH) {#ether-or-eth}
-
-اتر (همچنین با نماد علامت گذاری آن، ETH شناخته می شود) ارز بومی است که در اتریوم معامله می شود. ETH برای پرداخت هزینه استفاده از شبکه اتریوم (به شکل کارمزد تراکنش) مورد نیاز است. ETH همچنین با سهام گذاری برای ایمن سازی شبکه استفاده می شود. وقتی مردم در مورد قیمت اتریوم صحبت می کنند، به دارایی ETH اشاره می کنند.
-
-[جزئیات بیشتر درباره ETH](/eth/)
-
-[جزئیات بیشتر درباره سهامگذاری ETH](/staking/)
-
-### بنیاد اتریوم {#ethereum-foundation}
-
-یک سازمان غیر انتفاعی، که در ابتدا توسط فروش جمعی ETH تأمین مالی شد و به پشتیبانی از شبکه و اکوسیستم اتریوم اختصاص یافت.
-
-[جزئیات بیشتر درباره بنیاد اتریوم](/foundation/)
-
-### ethereum.org {#ethereum-org}
-
-یک وب سایت عمومی و منبع باز و منبع آموزشی برای جامعه اتریوم. ethereum.org توسط یک تیم اصلی کوچک، که توسط بنیاد اتریوم تامین مالی میشود، با مشارکت هزاران نفر از اعضای جامعه در سراسر جهان هدایت میشود.
-
-این صفحه اطلاعات بیشتری در مورد ethereum.org را پوشش میدهد.
-
-## ماموریت ما {#our-mission}
-
-**ماموریت وبسایت ethereum.org این است که بهترین درگاه جامعه در حال رشد اتریوم باشد**
-
-ما در تلاش هستیم تا یک منبع آموزشی قابل فهم برای همه موضوعات مرتبط با اتریوم بسازیم که به کاربران جدید کمک میکند تا با اتریوم و مفاهیم کلیدی آن آشنا شوند. ما میخواهیم:
-
-- اتریوم را با کسانی که در این تکنولوژی جدید هستند توضیح دهیم
-- به کاربران جدید کمک کنیم تا شروع به استفاده از ETH و اتریوم کنند
-- به توسعهدهندگان جدید کمک کنیم تا ساختن را شروع کنند
-- تازههای دنیای اتریوم را پوشش دهیم
-- ویترین منابعی باشیم که توسط جامعه تولید میشود
-- آموزشهای اتریوم را به هر زبان که ممکن است ارائه کنیم
-
-برای دستیابی به این ماموریت، تیم ما روی دو هدف اصلی در ethereum.org تمرکز میکند:
-
-### 1. بهبود تجربه کاربری برای بازدیدکنندگان ethereum.org {#visitors}
-
-- محتوا را گسترش دهید، بهبود دهید و به روز نگه دارید
-- قابلیت استفاده و دسترسی را از طریق بهترین شیوه های محلی سازی و توسعه وب بهبود بخشید
-- تعامل کاربر را از طریق ویژگیهایی مانند نظرسنجی، آزمونها و ادغام Web3 افزایش دهید
-- وب سایت را سبک و کارآمد نگه دارید
-
-### 2. جامعه مشارکتکنندگان ما را رشد، تقویت و توانمند سازید {#community}
-
-- تعداد کل مشارکتکنندگان در وب سایت را افزایش دهید
-- حفظ مشارکتکنندگان را از طریق مشارکت، قدردانی و پاداش بهبود بخشید
-- اعضای جامعه را توانمند کنید تا مشارکتهای چشمگیری داشته باشند
-- تسهیل تنوع بیشتر مشارکتها: کد، محتوا، طراحی، ترجمه، تعدیل
-- پایگاه کد را مدرن، تمیز و مستند نگه دارید
-
-## اصول اصلی {#core-principles}
-
-ما چند اصل اساسی داریم که به ما کمک میکنند ماموریت خود را به انجام برسانیم.
-
-### 1. ethereum.org یک درگاه برای اتریوم است 🌎 {#core-principles-1}
-
-ما میخواهیم که کاربران ما سود داشته باشند و سوالات آن ها پاسخ داده شود. به همین دلیل درگاه ما نیاز دارد تا اطلاعات، "magic moments" و لینکهای منابع جامعه را که وجود دارند، ترکیب کند. هدف ما این است که محتوای ما "پرتال جذب افراد" باشد، نه یک جایگزین برای انبوهی از اطلاعات که همین الان وجود دارند. ما به دنبال متحد کردن و پشتیبانی اطلاعات ساخته شده توسط جامعه هستیم که موجب شفافیت آن و قابل دسترس بودن آن میشود. [جامعه اتریوم](/community/) قلب تپنده آن است: ما صرفا نباید به آن ها سرویس بدهیم، بلکه با آن ها کار کنیم و بازخورد آن ها را در نظر بگیریم. این وبسایت تنها برای استفاده جامعه الان نیست، بلکه برای جامعهای است که امیدواریم رشد کند. ما باید به خاطر داشته باشیم که جامعه ما جهانی است، و تمام مردم از هر زبان، منطقه و فرهنگی را شامل میشود.
-
-### 2. ethereum.org همواره در حال تکامل است ⚒ {#core-principles-2}
-
-اتریوم و جامعه ما همواره در حال جهش هستند، و نیز ethereum.org. و به این خاطر است که سایت دارای یک طراحی ساده است& یک ساختار مدولار. ما زمانی که میفهمیم مردم چگونه از سایت استفاده میکنند تغییرات مرحلهای انجام میدهیم. ما متن باز هستیم، با یک جامعه مشارکتگر، بنابراین شما هم میتوانید پیشنهاد دهید و ما را کمک کنید. [درباره مشارکت بیاموزید](/contributing/)
-
-### 3. ethereum.org یک وبسایت معمولی نیست 🦄 {#core-principles-3}
-
-اتریوم یک چیز بزرگ است: که یک جامعه، تکنولوژی، و مجموعه ای از ایده ها و موارد دیگر است. این بدان معنی است که سایت نیاز دارد تا تجربههای کاربران مختلف را رسیدگی کند، "از یک توسعه دهنده که یک ابزار مشخص میخواهد" گرفته تا "یک تازهکار که مقداری اتر خریده و حتی معنی کیف پول را نمیداند". "بهترین وبسایت برای پلتفرم زنجیره بلوکی چیست؟" یک سؤال با جواب باز است - ما پیشرو هستیم. ساختن آن به آزمایش نیاز دارد.
-
-## نقشه راه محصول {#roadmap}
-
-تیم اصلی ethereum.org برای در دسترستر کردن کارمان و تقویت همکاری بیشتر در جامعه، یک نمای کلی از اهداف نقشه راه فصلی ما را منتشر میکند.
-
-[نقشه راه سهماهه سوم 2024 ما را ببینید](https://github.com/ethereum/ethereum-org-website/issues/13399)
-
-**چطور است؟** ما همیشه از بازخورد درباره نقشه راه مان قدردانی می کنیم - اگر چیزی وجود دارد که فکر می کنید باید روی آن کار کنیم، لطفاً به ما اطلاع دهید! ما از ایدهها و روابط عمومی هر کس در جامعه استقبال میکنیم.
-
-**میخواهید مشارکت کنید؟** [درباره مشارکت بیشتر بیاموزید](/contributing/)، [در توییتر با ما تماس بگیرید](https://twitter.com/ethdotorg)، یا به بحثهای جامعه در
-
-سرور دیسکورد ما بپیوندید< /3>.
-
-
-
-## اصول طراحی کنید {#design-principles}
-
-ما از مجموعه ای از [اصول طراحی](/contributing/design-principles/) برای پیشبرد محتوا و تصمیمات طراحی در وبسایت استفاده می کنیم.
-
-
-
-## سیستم طراحی {#design-system}
-
-ما یک [سیستم طراحی](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) ساختیم و منتشر کردیم تا ویژگیها را سریعتر ارسال کنیم و به اعضای انجمن اجازه دهیم در طراحی باز ethereum.org شرکت کنند.
-
-می خواهید شرکت کنید؟[در فیگما](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System) بخش [مشکل گیت هاب](https://github.com/ethereum/ethereum-org-website/issues/6284) را دنبال کنید و به گفتگو در [ کانال دیسکورد ما بپیوندید](https://discord.gg/ethereum-org).
-
-
-
-## راهنمای سبک {#style-guide}
-
-ما [یک راهنمای سبک](/contributing/style-guide/) برای استانداردسازی ابعاد مشخصی از محتوای نوشتاری داریم تا فرایند کار ساده و هموارتر شود.
-
-حتما [اصول طراحی](/contributing/design-principles/) و [راهنمای سبک](/contributing/style-guide/) را مطالعه کنید و اگر دوست داشتید [به سایت ما کمک کنید](/contributing/).
-
-ما از بازخورد در مورد اصول طراحی، سیستم طراحی و راهنمای سبکمان استقبال میکنیم. به یاد داشته باشید، ethereum.org برای جامعه و از طرف جامعه است.
-
-
-
-## مجوز {#license}
-
-وب سایت ethereum.org منبع باز است و تحت [مجوز MIT](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) ساخته شده است، مگر اینکه خلاف آن مشخص شده باشد. اطلاعات بیشتر در مورد [شرایط استفاده](/terms-of-use/) از ethereum.org.
-
-
-
-## شغل های موجود {#open-jobs}
-
-اگرچه این وبسایت متن باز است و همه می توانند روی آن کار کنند، تیمی مختص به ethereum.org و پروژه های دیگر وب بنیاد اتریوم داریم.
-
-مشاغل موجود را در اینجا می نویسیم. اگر نقشی در اینجا برای خود نمی بینید، به [سرور دیسکورد ما](https://discord.gg/ethereum-org) بروید و به ما اطلاع دهید که چگونه می خواهید با ما کار کنید!
-
-آیا به چیزی فراتر از تیم ethereum.org فکر می کنید؟ [سایر مشاغل مربوط به اتریوم را در اینجا چک کنید](/community/get-involved/#ethereum-jobs/).
diff --git a/public/content/translations/fa/26) Miscellaneous/enterprise/index.md b/public/content/translations/fa/26) Miscellaneous/enterprise/index.md
deleted file mode 100644
index 23e1f61976a..00000000000
--- a/public/content/translations/fa/26) Miscellaneous/enterprise/index.md
+++ /dev/null
@@ -1,199 +0,0 @@
----
-title: تشکیلات سازمانی بر بستر شبکه اصلی اتریوم
-description: راهنماها، مقالات و ابزارهایی درباره برنامه های کاربردی سازمانی در بلاک چین عمومی اتریوم
-lang: fa
----
-
-# اتریوم برای سازمان {#ethereum-for-enterprise}
-
-اتریوم میتواند به انواع مختلف شرکتها، از جمله شرکتهای بزرگ کمک کند:
-
-- افزایش اعتماد و کاهش هزینه های هماهنگی بین طرف های تجاری
-- بهبود پاسخگویی شبکه تجاری و کارایی عملیاتی
-- مدل های کسب و کار جدید و فرصت های خالق ارزش بسازید
-- سازمان آنها به طور رقابتی آینده نگر است
-
-در سالهای اولیه، بسیاری از برنامههای بلاک چین سازمانی بر روی زنجیرههای بلاک چین یا کنسرسیوم سازگار با اتریوم با مجوز خصوصی ساخته شدند. امروزه، به لطف پیشرفتهای فناوری که توان عملیاتی بیشتر، هزینه تراکنش کمتر و حفظ حریم خصوصی را ممکن میسازد، اکثر برنامههای کاربردی سازمانی که از فناوری اتریوم استفاده میکنند بر روی شبکه اصلی اتریوم یا روی
-
-زنجیره لایه 2
.
-
-
-
-
-## منابع {#enterprise-resources}
-
-
-
-### بیشتر بخوانید {#further-reading}
-
-منابع غیر فنی برای درک اینکه چگونه کسب و کارها می توانند از اتریوم بهره ببرند
-
-- [چرا بلاک چین برای تجارت و بیزینس مفید است؟](https://entethalliance.org/why-are-blockchains-useful-for-business/) - _ در خصوص ارزش بلاک چینها از طریق لنز پیشبینیپذیری بحث کنید_
-- [گزارش آمادگی تجاری سال 2023 اتحادیه اتریوم](https://entethalliance.org/eea-ethereum-business-readiness-report-2023/) - _پتانسیل و قابلیتهای اتریوم عمومی و اکوسیستم گستردهتر اتریوم برای کسبوکارها را بررسی میکند._
-- [_اتریوم برای کسب و کار_ نوشته پل برادی](https://www.uapress.com/product/ethereum-for-business/)، _یک راهنمای ساده به زبان انگلیسی برای موارد کاربردی است که بازدهی از مدیریت دارایی تا پرداختها و زنجیرههای تأمین را ایجاد میکند._
-
-
-
-### سازمانها {#organizations}
-
-برخی تلاشهای مشترک برای مورد پسند کردن اتریوم سازمانی توسط سازمانهای مختلف انجام شده است
-
-- [اتحادیه اتریوم برای کسبوکارها](https://entethalliance.org/) - اتحادیه اتریوم (EEA) به سازمانها کمک میکند تا فناوری اتریوم را در عملیات روزانه کسبوکار خود انتخاب و استفاده کنند. هدف آن، تسریع کسب و کار اتریوم از طریق پشتیبانی حرفهای و تجاری، حمایت و ترویج، تحقیقات، توسعه استانداردها و خدمات اعتماد اکوسیستم است.
-- [شورای جهانی تجارت بلاکچین (GBBC)](https://www.gbbc.io/) - اتحادیهای صنعتی برای اکوسیستم فناوری بلاکچین است. با جلب توجه سیاستگذاران و نظارتکنندگان، برگزاری رویدادها و بحثهای گسترده، و انجام تحقیقات، GBBC به ترویج بیشتر بلاکچین برای ایجاد جوامعی امنتر، عادلانهتر و کارآمدتر متعهد است.
-
-
-
-
-## منابع توسعه دهنده سازمانی {#enterprise-developer-resources}
-
-
-
-### محصولات و خدمات {#products-and-services}
-
-- [4EVERLAND](https://www.4everland.org/) - _ خدمات RPC و APIها و ابزارهایی را برای میزبانی برنامههای غیرمتمرکز و فعال کردن ذخیرهسازی غیرمتمرکز در اتریوم ارائه میدهد_
-- [Alchemy](https://www.alchemy.com/) - _خدمات و ابزارهای API را برای ساخت و نظارت بر برنامههای کاربردی در اتریوم ارائه میکند_
-- [Blast](https://blastapi.io/) - _یک پلتفرم API که APIهای RPC/WSS را برای شبکه اصلی بایگانی اتریوم و شبکههای آزمایشی فراهم میکند._
-- [Blockapps](https://blockapps.net/) - _اجرای پروتکل اتریوم سازمانی، ابزار و APIهایی که پلتفرم STRATO را تشکیل می دهند._
-- [Chainstack](https://chainstack.com/) - _شبکه اصلی و شبکه آزمایشی زیرساخت اتریوم که در ابرهای عمومی & مجزای مشتریان میزبانی میشود._
-- [ConsenSys](https://consensys.io/) - _طیف وسیعی از محصولات و ابزارها را برای ساخت بر روی اتریوم و همچنین خدمات مشاوره و توسعه سفارشی ارائه می کند._
-- [Crossmint](http://crossmint.com/) _پلتفرم توسعه Web3 درجه سازمانی برای استقرار قراردادهای هوشمند، فعال کردن پرداختهای کارت اعتباری و زنجیرهای متقابل و استفاده از APIها برای ایجاد، توزیع، فروش، ذخیره و ویرایش NFTها._
-- [Envision Blockchain](https://envisionblockchain.com/) - _خدمات مشاوره و توسعه متمرکز بر سازمان را با تخصص در شبکه اصلی اتریوم ارائه می دهد_
-- [EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _با صدور RFQ، قراردادها، سفارشات خرید و فاکتورها در سراسر شبکه شرکای تجاری مورد اعتماد شما، گردش کار تدارکات را فراهم می کند._
-- [Hyperledger Besu](https://www.hyperledger.org/use/besu) - _یک مشتری منبع باز اتریوم متمرکز بر سازمان که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است_
-- [Infura](https://infura.io/) - _دسترسی API مقیاس پذیر به شبکه های اتریوم و IPFS_
-- [Kaleido](https://kaleido.io/) - _یک پلتفرم توسعه متمرکز بر سازمان که برنامه های کاربردی ساده شده بلاک چین و دارایی های دیجیتال را ارائه می دهد_
-- [NodeReal](https://nodereal.io/) - _ارائه دهنده زیرساخت مقیاسپذیر بلاکچین و خدمات API برای اکوسیستم Web3_
-- [Moralis](http://moralis.io/) - _گرهها و APIهای درجه سازمانی با گواهینامه SOC2 نوع 2_
-- [Provide](https://provide.services/) - _میانافزار دانش صفر برای کسبوکارها_
-- [QuickNode](https://www.quicknode.com/) - _ارائه دهنده نودهای قابل اعتماد و سریع با API های سطح بالا مانند API NFT، API Token و غیره، همچنین ارائه مجموعهای یکپارچه از محصولات و راهکارهای متناسب با شرکتها_
-- [Tenderly](https://tenderly.co) - _یک پلت فرم توسعه Web3 که اشکال زدایی، مشاهده پذیری و بلوک های ساختمان زیرساخت را برای توسعه، آزمایش، نظارت و اجرای قراردادهای هوشمند فراهم می کند_
-- [Unbright](https://unibright.io/) - _تیمی از متخصصان، معماران، توسعه دهندگان و مشاوران بلاک چین با بیش از 20 سال تجربه در فرآیندهای تجاری و یکپارچه سازی_
-- [Zeeve](https://www.zeeve.io/) - _مجموعه ای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساخت و API برای برنامه های Web3 سازمانی ارائه می دهد._
-
-
-
-### ابزار و کتابخانه ها {#tooling-and-libraries}
-
-- [Baseline Project](https://www.baseline-protocol.org/) - _مجموعه ای از ابزارها و کتابخانه ها است که به شرکت ها کمک می کند تا فرآیندهای تجاری پیچیده و چند جانبه و گردش کار را با حفظ حریم خصوصی هماهنگ کنند و در عین حال داده ها را در سیستم های ثبت مربوطه نگهداری کنند. این استاندارد دو یا چند ماشین حالت را قادر میسازد تا با استفاده از یک شبکه بهعنوان یک چارچوب مرجع مشترک، سازگاری دادهها و تداوم گردش کار را به دست آورند و حفظ کنند._
-- [Chainlens](https://www.chainlens.com/) - _SaaS و پلتفرم داده و تجزیه و تحلیل بلاک چین اولیه از آزمایشگاههای Web3_
-- [Ernst & Young's 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _برنامه ای برای انتقال برنامه های ERC20، ERC721 و ERC1155 با دانش صفر، با استفاده از یک جمعبندی خوش بینانه_
-- [Truffle Suite](https://trufflesuite.com) - _مجموعه توسعه بلاک چین (ترافل، گاناش، دریزل)_
-
-
-
-### راه حل های مقیاس پذیری {#scalability-solutions}
-
-اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/لایه دوم) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
-
-
-
-## برنامههای کاربردی سازمانی در شبکه اصلی اتریوم فعال میشوند {#enterprise-live-on-mainnet}
-
-در اینجا برخی از برنامههای کاربردی سازمانی که بر روی شبکه عمومی اتریوم و لایه دوم توسط شرکتهای سنتی غیربلاک چین ساخته شدهاند، آورده شده است.
-
-
-
-### پرداختها {#payments}
-
-- [مرورگر بریو (Brave)](https://basicattentiontoken.org/) - _به کاربران برای توجه آنها به تبلیغات، بیسیک اتنشن توکن (BAT) پرداخت میکند و کاربران نیز میتوانند از طریق BAT برای حمایت از ناشران پرداخت انجام دهند_
-- [شهر لوگانو، سوئیس](https://bitcoinsuisse.com/news/city-of-lugano-accepts-crypto-payments) - _پرداخت مالیات و سایر خدمات شهری_
-- [اتریوم ادز](https://ethereumads.com/) - _به اپراتورهای وبسایت اجازه میدهد فضای تبلیغاتی را بفروشند و از طریق اتریوم پول دریافت کنند_
-- [hCaptcha](https://www.hcaptcha.com/) - _سیستم CAPTCHA پیشگیری از ربات که به اپراتورهای وبسایت برای کارهای انجام شده توسط کاربران برای برچسب زدن دادهها برای یادگیری ماشین پرداخت میکند. اکنون توسط Cloudflare مستقر شده است_
-- [Opera MiniPay](https://www.opera.com/products/minipay) - _پرداختهای موبایلی را برای مردم آفریقا از طریق کیف پول غیرسرپرستی در دسترستر و ایمنتر میکند و از شماره تلفنها برای تراکنش آسان_ استفاده میکند
-- [Roxpay ](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
-- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p /13560384) - _پرداختهای بین المللی با استیبل کوین_
-- [Toku](https://www.toku.com/) - _دستمزد، مدیریت کمک هزینه توکنی، رعایت مالیات، استخدام محلی، مزایا و & راهحلهای منابع انسانی توزیع شده_
-- [Xerof](https://www.xerof.com/) - _پرداختهای سریع و ارزان بینالمللی (برون مرزی) B2B را تسهیل میکند_
-
-
-
-### امور مالی {#finance}
-
-- [ABN AMRO](https://tokeny.com/tokeny-fuels-abn-amro-bank-in-tokenizing-green-bonds-on-polygon/) - _با توکنی، مسیرهای سبز توکن شده_
-- [Crowdz](https://crowdz.io/) - _پلتفرم امور مالی و فاکتورهای دریافتنیها_
-- [Mata Capital](https://consensys.io/blockchain-use-cases/finance/mata-capital) - _توکنسازی سرمایهگذاری در املاک و مستغلات_
-- [Obligate](https://www.obligate.com/) - _ اوراق قرضه زنجیرهای و اوراق تجاری تحت نظارت و احراز هویت_
-- [زیمنس](https://press.siemens.com/global/en/pressrelease/siemens-issues-first-digital-bond-blockchain) - _ صدور مسیر_
-- [سیلا](https://silamoney.com/) - _بانکداری و پرداختهای ACH به عنوان سرویس، با استفاده از یک استیبل کوین_
-- [Societe Generale FORGE](https://www.sgforge.com/product/bonds/) - _صدور مسیر_
-- [Taurus](https://www.taurushq.com/) - _ضمانتهای توکن شده صادر میکند_
-
-
-
-### توکنیزه کردن دارایی {#tokenization}
-
-- [AgroToken](https://agrotoken.io/en/) - _توکنسازی و معامله کالاهای کشاورزی_
-- [بیت باند (Bitbond)](https://www.bitbond.com/) - _صدور، تسویه و نگهداری داراییهای مالی را با توکنسازی بهبود میبخشد_
-- [بلاک اسکوئر (Blocksquare)](https://blocksquare.io/) - _زیرساخت توکنسازی برای املاک و مستغلات_
-- [سانتریفیوژ (Centrifuge)](https://centrifuge.io/) - _تامین مالی، بدهی و داراییهای دریافتنیهای توکن شده_
-- [کلیرمتیک (Clearmatics)](https://www.clearmatics.com) - _پلتفرمهای شبکه غیرمتمرکز را برای مبادله همتا به همتای ارزش توکن میسازد_
-- [dClimate](https://www.dclimate.net/) - _اکوسیستم اطلاعات آب و هوایی غیرمتمرکز_
-- [Fabrica](https://www.fabrica.land/) - _پلتفرمی برای دیجیتالی کردن داراییهای املاک و مستغلات، وامگیری دیفای و معامله دارایی_
-- [Fasset](https://www.fasset.com/) - _پلتفرمی برای پشتیبانی از زیرساختهای پایدار_
-- [نوری](https://nori.com/) - _زیرساخت بازار منبع باز برای امکان اندازهگیری و کسب درآمد از فعالیتهای پروژههای حذف کربن_
-- [پراپی (Propy)](https://propy.com/) - _پلتفرمی برای خودکارسازی معاملات املاک مسکونی با قراردادهای هوشمند_
-- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند. _
-- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد em>
-
- - [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات< /em>
-
- - [تالو (Thallo)](https://www.thallo.io/) - _پلتفرمی برای ادغام اعتبارات کربن دیجیتال در معاملات تجاری_
-- [Tokenchampions](https://tokenchampions.com/) - _حقوق تصویر بازیکنان فوتبال اروپا را توکنیزه میکند_
-
-
-
-### ثبت دادهها {#notarization-of-data}
-
-- [ ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _خبرگزاری ایتالیایی با اخبار جعلی مبارزه میکند و خوانندگان را قادر میسازد تا منشأ اخبار را با ضبط آنها در شبکه اصلی تأیید کنند_
-- [Breitling](https://www.coindesk.com/breitling-arianee-all-new-watches-ethereum) - _منشأ و تاریخچه تعمیر را در اتریوم ثبت میکند_
-- [BRØK](https://www.xn--brk-1na.no/) - _پلتفرم جداول کپ برای شرکتهای ثبت نشده در بورس عمومی توسط دولت نروژ ارائه شده است _
-- [گواهی](https://certifaction.com/) - _امضاهای الکترونیکی معتبر قانونی با حریم خصوصی-by-design_
-- [EthSign](https://ethsign.xyz/) - _اسناد الکترونیکی امضا شده را در بلاکچین اتریوم ثبت میکند_
-- [Stacktical](https://stacktical.com/) - _توسعه نرمافزار، صدور و امضای دیجیتالی قراردادهای سطح سرویس (SLA) را با قابلیتهای بومی فعال میکند_
-- [وریزون](https://decrypt.co/46745/verizon-news-press-releases-ethereum-full-transparency) - _گزارشهای مطبوعاتی را در اتریوم برای اطمینان از مسئولیت پذیری و اعتماد شرکت نشان میدهد_
-- [ولف تون](https://www.mef.net/edge-view-blog/automated-secure-timely-sla-reporting-is-finally-a-reality/) - _توسط MEF و مدیریت Sage گزارشدهی توافقنامه سطح خدمات بین شرکتهای مخابراتی را خودکار میکند_
-
-
-
-### زنجیره تامین {#supply-chain}
-
-- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using -ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
-- [کارگوایکس](https://cargox.io/) - _ارائهدهنده بارنامه الکترونیکی و انتقال اسناد برای حمل و نقل_
-- [Circularize](https://www.circularise.com/) - _یک راهحل ردیابی سرتاسر برای مواد خام ساخته شده در محصولات است_
-- [مدیر قرارداد EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _شرکتها را قادر میسازد تا در جریان کاری تدارکات، صدور RFQ، قراردادها، سفارشها خرید و فاکتورها در شبکهای از شرکای تجاری شرکت کنند_
-- [ماین اسپایدر](https://www.minespider.com/) - _ردیابی و منشأ زنجیره تامین و ردیابی انتشار CO2_
-- [Morpheus.network](https://morpheus.network/) - _پلتفرم اتوماسیون زنجیره تامین_
-- [StaTwig](https://statwig.com/) - _عملیات زنجیره تامین_
-- [TradeTrust](https://www.tradetrust.io/) - _بارنامههای الکترونیکی (eBLs) را برای حمل و نقل بین المللی تأیید میکند_
-- [Transmute](https://transmute.industries/) - _پلتفرم تبادل داده برای معامله جهانی؛ از تراکنشهای با هویت غیرمتمرکز در اتریوم_ پشتیبانی میکند
-
-
-
-### بیمه {#insurance}
-
-- [آربول (Arbol)](https://www.arbolmarket.com/) - _بیمه پارمتریک برای پوشش خطرات مربوط به آب و هوا_
-- [Etherisc](https://etherisc.com/) - _بیمه غیرمتمرکز برای انواع خطرات_
-- [Nayms](https://www.nayms.com/) - _یک فضای دیجیتال برای ایجاد برنامههای بیمه، افزایش و معامله سرمایه، نوشتن ریسک و ریلهای پرداخت برای تراکنشهای حق بیمه و ادعا، ساخته شده با AON_
-
-
-
-### هویت، اعتبار و گواهینامه {#credentials}
-
-- [BCdiploma](https://www.bcdiploma.com/) - _دیپلمها، گواهیها و مدارک خرد را دیجیتالی و تأیید میکند_
-- [مدارک هایلند](https://www.hylandcredentials.com) - _دیپلمهای دیجیتال و سایر مدارک تحصیلی، مجوزها و گواهینامهها_
-- [برنامه اقامت دیجیتال پالائو](https://rns.id/) - _به شهروندان جهانی این امکان را میدهد که کارت شناسایی قانونی صادر شده توسط دولت پالائو داشته باشند em>
-
- - [Spherity](https://www.spherity.com/) - _راهحلهای مدیریت هویت دیجیتال را برای ایجاد اعتماد دیجیتال در اکوسیستمها، با تمرکز بر هویتهای غیرمتمرکز و اعتبار قابل تأیید ارائه میدهد_
-- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
-
-
-
-### سرگرمی، NFT و وفاداری
-
-- [چرخ دنده مجازی آدیداس (Adidas Virtual Gear)](https://www.adidas.com/metaverse) - _مجموعه NFT چرخ دنده مجازی_
-- [سندباکس موزه بریتانیا](https://decrypt.co/150405/british-museum-enter-metaverse-via-sandbox) - _یک مجموعه توکن غیرقابل تعویض_
-- [Fruitlab](https://fruitlab.com/) - _پلتفرمی برای گیمرها برای کسب درآمد از تماشا، اشتراکگذاری و بازیهای آنلاین_
-- [Nike Swoosh](https://www.swoosh.nike/) - _یک پلتفرم انافتی_
-- [متاورس سوثبیز](https://metaverse.sothebys.com/) - _یک بازار دیجیتال هنر NFT توسط Sothebyها_
-
-اگر میخواهید به این فهرست اضافه کنید، لطفاً به [دستورالعملهای مشارکت](/contributing/) مراجعه کنید.
diff --git a/public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md b/public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md
deleted file mode 100644
index 5992f822f04..00000000000
--- a/public/content/translations/fa/26) Miscellaneous/enterprise/private-ethereum/index.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: اتریوم خصوصی برای تشکیلات سازمانی
-description: منابعی برای اپلیکیشن تشکیلات سازمانی بر بستر بلاک چین های خصوصی اتریوم.
-lang: fa
----
-
-# اتریوم خصوصی برای تشکیلات سازمانی {#private-ethereum-for-enterprise}
-
-اپلیکیشن های بلاک چین تشکیلات سازمانی میتوانند بر روی شبکه اصلی اتریوم بدون مجوز عمومی یا بر روی بلاک چین های خصوصی که مبتنی بر فناوری اتریوم هستند ساخته شوند. برای اطلاعات بیشتر در مورد ساخت اپلیکیشن بر بستر شبکه عمومی اصلی اتریوم، به [شبکه اصلی اتریوم برای شرکتها](/enterprise/) مراجعه کنید.
-
-## منابع توسعه دهندگان برای تشکیلات سازمانی اتریوم {#developer-resources-private-enterprise-ethereum}
-
-### سازمانها {#organisations}
-
-برخی از تلاشهای مشترک برای مورد پسند کردن تشکیلات سازمانی اتریوم توسط سازمانهای مختلف انجام شده است:
-
-- [اتحادیه تشکیلات سازمانی اتریوم](https://entethalliance.org/) EEA سازمانها را قادر میسازد تا فناوری اتریوم را در عملیات تجاری روزانه خود بپذیرند و از آن استفاده کنند. ما اکوسیستم اتریوم را برای ایجاد فرصتهای تجاری جدید، تشویق به پذیرش صنعت، و یادگیری و همکاری با یکدیگر توانمند میکنیم.
-- [Hyperledger](https://hyperledger.org) _Hyperledger یک تلاش مشترک منبع باز است که برای پیشرفت فناوریهای بلاک چین بینصنعتی ایجاد شده است. این یک همکاری جهانی است که توسط بنیاد لینوکس میزبانی می شود، از جمله رهبران امور مالی، بانکداری، اینترنت اشیا، زنجیره تامین، تولید و فناوری. این بنیاد پروژههایی در خود دارد که با پشته اتریوم کار میکنند، از جمله [Besu](https://www.hyperledger.org/use/besu)._
-
-### پروتکل و زیرساخت {#protocol-and-infrastructure}
-
-- [Chainstack](https://chainstack.com/) _پلتفرم میان ابری و چند پروتکلی بهعنوان سرویسی که به کسبوکارها اجازه میدهد تا به سرعت، استقرار و مدیریت شبکه ها و سرویس های غیرمتمرکز را ایجاد کنند_
-- [Clearmatics Autonity](https://www.clearmatics.com/about/) _مجموعه پروتکلهایی که پروتکلهای p2p را پیادهسازی میکند و اپلیکیشن و زیرساخت کلاینت را ارائه میکند_
-- [هایپرلجر بسو](https://www.hyperledger.org/use/besu) _کاربر منبع باز اتریوم که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است که شامل چندین الگوریتم اجماع از جمله اثبات کار و اثبات قدرت است (IBFT، IBFT 2.0، Ethash و Clique). طرح های مجوز جامع آن به طور خاص برای استفاده در یک محیط کنسرسیوم طراحی شده است._
-- [Kaleido](https://kaleido.io/) _پلتفرم فول-استک برای ساخت و اجرای اکوسیستمهای تشکیلات اقتصادی ترکیبی میان ابری_
-- [Zeeve](https://www.zeeve.io/) _مجموعهای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساختها و APIهای سازمانی برنامه های Web3 ارائه میکند_
diff --git a/public/content/translations/fa/26) Miscellaneous/foundation/index.md b/public/content/translations/fa/26) Miscellaneous/foundation/index.md
deleted file mode 100644
index f79f30dff9d..00000000000
--- a/public/content/translations/fa/26) Miscellaneous/foundation/index.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: بنیاد اتریوم
-description: درباره بنیاد اتریوم (EF) بیشتر بدانید که یک سازمان غیرانتفاعی است که وقف حمایت از اتریوم و فن آوری های مرتبط با آن است.
-hideEditButton: true
-lang: fa
----
-
-# درباره بنیاد اتریوم {#about-the-ethereum-foundation}
-
-
-
-[بنیاد اتریوم](http://ethereum.foundation/)(EF) یک سازمان غیرانتفاعی است که وقف حمایت از [اتریوم](/what-is-ethereum/) و فن آوری های مرتبط با آن است.
-
-بنیاد اتریوم یک شرکت و یا حتی یک سازمان غیرانتفاعی سنتی نیست. نقش بنیاد، رهبری یا کنترل اتریوم نیست، و حتی بنیاد تنها نهادی نیست که به تامین مالی توسعه فن آوری های مرتبط با اتریوم میپردازد. بنیاد اتریوم بخشی از [اکوسیستمی](/community/) بسیار بزرگتر است.
-
-## ابتکارات بنیاد اتریوم {#ethereum-foundation-initiatives}
-
-### برنامه حمایت اکوسیستم {#ecosystem-support-program}
-
-[برنامه پشتیبانی اکوسیستم](https://esp.ethereum.foundation/) برای شتابدهی به رشد اکوسیستم، برای پروژه ها و افراد فعال در جامعه اتریوم حمایت مالی و غیر مالی فراهم میکند. برنامه پشتیبانی اکوسیستم نسخه ای گسترش داده شده از برنامه حمایت مالی اتریوم است که بر حمایت مالی از اکوسیستم تمرکز داشت.
-
-درباره برنامه پشتیبانی اتریوم، دریافت کنندگان قبلی پشتیبانی، و روند درخواست کمک هزینه در [esp.ethereum.foundation](https://esp.ethereum.foundation/) اطلاعات بیشتر دریافت کنید. همچنین برای آگاهی از آخرین اخبار و اطلاعیه ها میتوانید [ وبلاگ برنامه پشتیبانی اکوسیستم](https://blog.ethereum.org/category/ecosystem-support-program/) و یا [@EF_ESP](https://twitter.com/EF_ESP) را دنبال کنید.
-
-### Devcon {#devcon}
-
-از سال 2014، بنیاد اتریوم کنفرانس سالانه دِوکان، را برای تمام توسعه دهندگان، محققان، اندیشمندان و سازندگان اکوسیستم اتریوم برگزار میکند.
-
-شما میتوانید در [archive.devcon.org](https://archive.devcon.org/) به تمام محتوای ویدیویی مطالب ارائه شده در هر کنفرانس از زمان پیدایش آن دسترسی پیدا کنید.
-
-برای اطلاعات بیشتر، نگاه کنید به [devcon.org](https://devcon.org/)، و نگاهی به [وبلاگ دِوکان](https://devcon.org/en/blogs/) بیندازید، یا برای اخرین اطلاعیه ها، صفحه[@efdevcon](https://twitter.com/EFDevcon) را دنبال کنید.
-
-### برنامه فلوشیپ {#fellowship-program}
-
-[برنامه فلوشیپ بنیاد اتریوم](https://fellowship.ethereum.foundation/) ابتکاری است برای از بین بردن شکاف بین فرهنگ ها، ملت ها و طبقات اقتصادی مختلف. برنامه فلوشیپ بنیاد اتریوم با شناسایی و حمایت از افراد منحصر به فرد و بااستعداد باعث کوچک کردن این شکاف طبقاتی میشود، و موانع ورود برای افراد و جوامعی را که نمایندگان کمتری دارند که آینده Web3 را بسازند، از بین میبرد.
-
-[در fellowship.ethereum.foundation مطالب بیشتر را ببینید](https://fellowship.ethereum.foundation/).
-
-
-
-برای اطلاع بیشتر در مورد بنیاد و حوزه کاری آن، سایت [ethereum.foundation](http://ethereum.foundation/) را ببینید، و یا سری به [وبلاگ بنیاد اتریوم](https://blog.ethereum.org/) بزنید تا از اخرین اخبار بنیاد آگاه شوید.
diff --git a/public/content/translations/fa/27) Contributing/contributing/design-principles/index.md b/public/content/translations/fa/27) Contributing/contributing/design-principles/index.md
deleted file mode 100644
index 3c406e6ae09..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/design-principles/index.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: اصول طراحی
-lang: fa
-description: اصول طراحی ethereum.org و تصمیم گیری های محتوایی
----
-
-# اصول طراحی ما {#contributing-to-ethereumorg-}
-
- سلام، به اصول طراحی برای ethereum.org خوش آمدید. این بخشی از یک فرآیند مداوم برای تکامل و بهبود ethereum.org است.
-
-اصول ما، ظاهر و حس سایت و محتوایی که در آن وجود دارد را مشخص می کند.
-
-پیش از [عضویت در ethereum.org](/contributing/) باید این موارد را مطالعه کنید.
-
-## اصول طراحی چیست؟ {#ways-to-contribute}
-
-نگران نباشید، خیلی ساده اند! **اصول طراحی** مجموعه ای از دستورالعمل هایی هستند که ما در هنگام طراحی (یعنی ایجاد، حفظ یا به روز رسانی) چیزی به آن ها استناد می کنیم.
-
-در زمینه ethereum.org، این اصول طراحی پایه و اساس چیزی است که میخواهیم وبسایت نشان دهد و به جهان ارائه دهد. آن ها هم آرمانی هستند **و** هم کاربردی. این تنها _ظاهر_ وب سایت نیست، بلکه نحوه _کارکرد_ و حتی _احساسی_ است که در فرد ایجاد می کند. همه چیز، از رنگ ها گرفته تا چیدمان صفحه و نحوه صحبت درباره اتریوم در وب سایت باید با این اصول ارائه شود.
-
-## اصول در عمل {#how-decisions-about-the-site-are-made}
-
-به مثال زیر توجه کنید. یکی از این اصول "اعتبار" است، به این معنی که ما می خواهیم بازدیدکنندگان سایت _احساس کنند_ و _بدانند_ که سایت قابل اعتماد است - درست مانند اکوسیستم گستردهتر اتریوم. در این اصل، ما 3 "زیر اصول" کاربردی داریم که معتقدیم گام های عملی هستند که می توانیم برای معتبر کردن سایت برداریم:
-
-- _"تازه"_ یعنی محتوا را به روز نگه دارید.
-- _"اثبات اجتماعی"_ یعنی نشان دادن اندازه، تنوع و فعالیت اکوسیستم (میدانید: پیشرفت ارتقا اتریوم، دیفای (DeFi)، بازی، تمام هکاتون ها و...)
-- _"سازگار"_ یعنی ثبات در طراحی سایت و لحن و درستی نگارش.
-
-بنابراین هنگامی که ما در حال تصمیم گیری در مورد طراحی، یا تصمیم گیری در مورد کپی رایت هستیم، می توانیم به اصل "اعتبار" اشاره کنیم و بپرسیم:
-
-- _"آیا این سایت اطلاعات بهروز شده را منعکس می کند؟"_
-- _"ما چگونه و در کجا اندازه و فعالیت اکوسیستم را نشان می دهیم؟"_
-- _"آیا طرح های پیشنهادی جدید یکی از اعضای جامعه که در حال بررسی آن ها هستم، با طرح فعلی و نوشته های موجود در سایت همخوانی دارد؟"_
-
-## اصول طراحی ethereum.org {#contributors}
-
-### 1. الهام بخش {#1-inspirational}
-
-سایت باید الهام بخش کاربران باشد تا ببینند اتریوم چگونه می تواند دنیا را تغییر دهد. باید افراد را به اکتشاف، بازی و سرهم بندی با ابزارها و برنامه های اکوسیستم اتریوم ترغیب کند.
-
-- **رادیکال**: این سایت باید اهداف بلندپروازانه اتریوم را برای تغییر عمده جهان بیان کند. باید واضح باشد که Ethereum تنها یک دسته فن آوری جدید نیست - بلکه یک فن آوری تحول آفرین است.
-- **توانمندسازی از طریق آموزش:** سایت باید افراد را آموزش دهد تا بتوانند پتانسیل اتریوم را درک کنند، جایگاه خود را در اکوسیستم پیدا کنند و برای مشارکت در آن احساس قدرت کنند.
-
-هدایت بصری • محتوا
-
-### 2. جهانی {#2-universal}
-
-اتریوم یک پروژه جهانی و غیر متمرکز است و مخاطبان ما این موضوع را منعکس می کنند. سایت باید این دورنما را داشته باشد که برای همه قابل دسترس باشد و نسبت به بسیاری از فرهنگ های جهان حساس باشد.
-
-- **دسترسی پذیر:** سایت باید از دستورالعمل های دسترسی - از جمله برای افرادی که اتصالات با پهنای باند پایین دارند - پیروی کند.
-- **ساده و سرراست:** سایت باید ساده و بدون ابهام باشد. متن نباید از زبانی استفاده کند که ممکن است در ترجمه اشتباه تعبیر شود یا گم شود.
-- **اتریوم چند وجهی است:** اتریوم یک پروژه، یک مجموعه کد، یک جامعه و یک چشم انداز است. اتریوم به دلایل مختلف برای افراد مختلف ارزشمند است و راه های زیادی برای مشارکت در آن وجود دارد.
-
-سیستم های نوشتاری • استفاده از رنگ • هدایت بصری • محتوا
-
-### 3. یک داستان خوب {#3-a-good-story}
-
-وب سایت باید مانند یک داستان خوب عمل کند. بازدیدکنندگان در یک سفر هستند و محتوایی که ارائه می دهید بخشی از آن است. مشارکت های شما باید در یک روایت روشن قرار گیرند: روایتی با یک آغاز (نقطه ورود / مقدمه)، میانی (مجموعه ای از آموخته ها و بینش ها)، و پایانی (پیوند(ها) به منابع مرتبط، یا مراحل بعدی).
-
-- **سلسله مراتبی**: یک معماری اطلاعاتی واضح و سلسله مراتبی به بازدیدکنندگان سایت ethereum.org کمک می کند تا سایت را "به عنوان یک داستان" در مسیر رسیدن به اهداف خود دنبال کنند.
-- **سنگ محک:** ما سنگ محک برای هر کسی هستیم که به دنبال پاسخ است. ما نمی خواهیم جایگزین بسیاری از منابعی شویم که در حال حاضر وجود دارند. ما پاسخ میدهیم & گامهای بعدی قابلاطمینان را ارائه میدهیم.
-
-سفرهای کاربر • محتوا
-
-### 4. اعتبار {#4-credible}
-
-افراد ممکن است به دنبال معرفی خود به اکوسیستم اتریوم باشند یا ممکن است شکاک باشند. این مسئولیت را در نحوه برقراری ارتباط بپذیرید. اطمینان حاصل کنید که هر دو با اطمینان بیشتری از اکوسیستم اتریوم خارج می شوند.
-
-- **تازه:** همیشه به روز.
-- **اثبات اجتماعی:** نشان دادن اندازه، تنوع و فعالیت اکوسیستم.
-- **سازگار:** ثبات در طراحی و محتوا اعتبار را نشان میدهد.
-
-هدایت بصری • محتوا
-
-### 5. بهبود مشارکتی {#5-collaborative-improvement}
-
-وب سایت حاصل کار بسیاری از مشارکت کنندگان است، درست مانند اکوسیستم به عنوان یک کل.
-
-- **باز:** شفافیت کد منبع، فرآیندها و پروژهها را در سراسر اکوسیستم جشن می گیریم.
-- **قابل توسعه:** مدولار بودن یک تمرکز کلیدی در پشت هر کاری است که انجام میدهیم، بنابراین مشارکتها نیز باید ماژولار باشند. طراحی اصلی، کد جزء& و اجرای سایت باید امکان توسعه آسان آن را در آینده فراهم کند.
-- **تجربی:** ما دائماً در حال آزمایش، تست و تکرار هستیم.
-- ** مشارکتی:** این پروژه همه ما را گرد هم می آورد.
-- **پایدار:** آمادهسازی برای نگهداری طولانی مدت توسط جامعه
-
-شما می توانید اصول طراحی ما را در عمل [در سایت ما](/) ببینید.
-
-## بازخورد بدهید {#give-feedback}
-
-**نظرات خود را در مورد این سند با ما در میان بگذارید!** یکی از اصول پیشنهادی ما "**بهبود مشارکتی**" است، به این معنی که ما می خواهیم وب سایت، محصول بسیاری از مشارکت کنندگان باشد. بنابراین باتوجه به این اصل، می خواهیم این اصول طراحی را با جامعه اتریوم به اشتراک بگذاریم.
-
-در حالی که این اصول روی وب سایت ethereum.org متمرکز شده اند، امیدواریم که بسیاری از آن ها نماینده ارزش های کلی اکوسیستم اتریوم باشند (به عنوان مثال می توانید تاثیر [اصول وایتپیپر اتریوم](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy) را ببینید). شاید حتی بخواهید برخی از آن ها را در پروژه خود بگنجانید!
-
-نظرات خود را از طریق [سرور Discord](https://discord.gg/ethereum-org) یا به وسیله [ایجاد یک مسئله](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) با ما در میان بگذارید.
diff --git a/public/content/translations/fa/27) Contributing/contributing/design/index.md b/public/content/translations/fa/27) Contributing/contributing/design/index.md
deleted file mode 100644
index 34fc9131d43..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/design/index.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: همکاری در طراحی
-description: همکاری طراحی با ethereum.org
-lang: fa
----
-
-# همکاری طراحی با ethereum.org {#design-contributions}
-
-طراحی، یک بخش حیاتی هر پروژه است، و با اختصاص دادن زمان و مهارتهای طراحیتان به ethereum.org میتوانید به بهتر شدن تجربه کاربری بازدیدکنندگان ما کمک کنید. مشارکت در یک پروژه منبع باز فرصتی را برای کسب تجربه مرتبط و توسعه مهارت های خود در یک محیط مشارکتی فراهم می کند. شما این شانس را خواهید داشت که با دیگر طراحان، توسعه دهندگان و اعضای جامعه کار کنید، که همگی دیدگاه ها و بینش های منحصر به فرد خود را خواهند داشت.
-
-در نهایت، این یک راه عالی برای ایجاد یک نمونه کار متنوع و چشمگیر است که مهارت های طراحی شما را به نمایش می گذارد.
-
-## روش مشارکت؟
-
-### در مورد نمونه های اولیه طراحی بازخورد بدهید {#design-critique}
-
-ما گاهی برای آزمایش ایده های خام خود به کمک نیاز داریم. این یک راه عالی برای مشارکت بدون هیچ دانش فنی است.
-
-1. تیم طراحی یک طرح ماکت را در [Discord](https://discord.com/invite/ethereum-org) و در [GitHub](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) به اشتراک خواهد گذاشت.
-2. برای ارائه بازخورد از طریق عملکرد نظرات، از طریق طرح ها راهنمایی خواهید شد.
-3. نتیجه در مسئله گیتهاب به اشتراک گذاشته می شود و سپس توسط تیم بسته می شود.
-
-### در تحقیقات نظرسنجی شرکت کنید {#answer-surveys}
-
-به این روشها در وب سایت ما بازخورد ارائه کنید:
-
-1. بازدید از ethereum.org و خواندن صفحات.
-2. کلیک بر روی ویجت بازخورد در گوشه سمت راست پایین و پاسخ به سوالات مربوط به طراحی و محتوا.
-3. روی سوالات با فرمت آزاد تمرکز کنید.
-
-### مسائل مربوط به طراحی را در وب سایت بیابید و گزارش دهید {#report-design-issues}
-
-Ethereum.org وبسایتی است با ویژگیها و محتوای زیاد که سریع در حال رشد است. برخی از UIها به راحتی می توانند منسوخ شوند یا می توانند بهبود یابند. اگر با چنین موردی مواجه شدید، لطفا گزارش دهید تا توجه ما را به خود جلب کند.
-
-1. وب سایت را مرور کنید و به طراحی آن توجه کنید.
-2. در صورت مشاهده هر گونه مشکل بصری یا UX، اسکرین شات بگیرید و یادداشت کنید.
-3. مشکلات پیدا شده را با استفاده از [گزارش باگ](https://github.com/ethereum/ethereum-org-website/issues/new/choose) گزارش دهید.
-
-### تغییرات طراحی را پیشنهاد بدهید {#propose-design-changes}
-
-اگر در چالشهای طراحی احساس راحتی میکنید، میتوانید از صفحه مسائل گیتهاب ما دیدن کنید و [مسائل مرتبط با طراحی](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) را فیلتر کنید.
-
-1. وب سایت ما را مرور کنید و به طراحی آن توجه کنید یا به مخزن گیتهاب ما بروید و مسائل دارای علامت [“Design required”](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8) را بررسی کنید.
-2. در مورد راه حل ایده بگیرید و آن را طراحی کنید. (در حالت ایده آل از [سیستم طراحی](https://www.figma.com/community/file/1134414495420383395) ما استفاده کنید).
-3. راه حل را در مسئله مربوطه پیشنهاد دهید یا [یک راه حل جدید ایجاد کنید.](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request)
-4. منتظر بررسی تیم طراحی باشید.
-
-### سیستم طراحی را با هم بسازیم {#Contribute-to-design-system}
-
-سیستم طراحی ما طراحی ethereum.org را سرگرم کننده و آسان می کند. اگر شما یک طراح با تجربه هستید، می توانید به ما در تهیه بسیاری از اجزای وب سایت کمک کنید.
-
-1. مشکلی را برای کار از [برد سیستم طراحی](https://github.com/ethereum/ethereum-org-website/labels/design%20system) در GitHub انتخاب کنید یا یک مورد جدید ایجاد کنید.
-2. درخواست کنید موضوع انتخاب شده به شما اختصاص داده شود.
-3. طراحی قطعه درخواست شده در فیگما را آغاز کنید.
-4. پس از نیاز به بررسی یا راهنمایی، آن را با تیم طراحی در گیتهاب به اشتراک بگذارید.
-5. تیم طراحی بررسی خواهد کرد.
-6. تیم طراحی، تغییرات را در فایل اصلی خواهد گنجاند و فایل را برای جامعه منتشر خواهد کرد.
-
-### مطالب مرتبط با طراحی را در وب سایت بنویسید {#write-design-articles}
-
-جامعه توسعه دهندگان اتریوم قوی است، اما جامعه طراحی کمی عقبتر است. اگر شما یک طراح با دانش Web3 هستید، لطفاً در نظر داشته باشید که آموخته های خود را با جامعه بزرگتر به اشتراک بگذارید تا همه با هم رشد و پیشرفت کنیم. ما [صفحه ای برای طراحی اتریوم داریم](/developers/docs/design-and-ux/) که می توانید در آن مشارکت کنید. همچنین میتوانید [خطمشیهای لیستینگ](/contributing/design/adding-design-resources) ما را بررسی کنید.
-
-1. در مورد موضوعات طراحی که باید در ethereum.org پوشش داده شود و برای طراحان در فضا میتوانند مفید باشند، فکر کنید.
-2. به مخزن گیتهاب ما بروید و [مسئلهای را مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new) که یک موضوع را پیشنهاد میدهد (فعلا محتوا را ننویسید).
-3. منتظر تایید تیم طراحی باشید.
-4. پس از تایید، محتوا را بنویسید.
-5. آن را در مسئله گیتهاب مربوطه ارائه کنید.
-
-### تصاویر جدید بکشید {#prepare-illustrations}
-
-تصویرسازیها یکی از قدرتمندترین ابزارها برای توضیح موضوعات انتزاعی هستند. با افزودن نمودارها و اینفوگرافیک ها پتانسیل بسیار زیادی وجود دارد. به هر حال، یک تصویر می تواند هزاران کلمه را بیان کند.
-
-1. به وبسایت ما بروید و صفحاتی را ببینید که در آنها میتوان اینفوگرافیکهای جدید اضافه کرد.
-2. مطمئن شوید که سبک تصویر با [داراییهای](/assets/) ما مطابقت دارد.
-3. به مخزن گیتهاب ما بروید و در مورد ارائه تصویر [یک مسئله مطرح کنید](https://github.com/ethereum/ethereum-org-website/issues/new).
-4. تیم طراحی آن را بررسی خواهد کرد.
-5. ما یک مسئله جدید ایجاد می کنیم تا از یک توسعه دهنده بخواهیم تصویر جدید را اجرا کند.
diff --git a/public/content/translations/fa/27) Contributing/contributing/index.md b/public/content/translations/fa/27) Contributing/contributing/index.md
deleted file mode 100644
index 2dd47a1bc41..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/index.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: در حال مشارکت
-description: در مورد روش های مختلفی که می توانید به ethereum.org کمک کنید، بیاموزید
-lang: fa
----
-
-# مشارکت در ethereum.org 🦄 {#contributing-to-ethereumorg}
-
-Ethereum.org یک پروژه اجرا شده منبع باز با **بیش از 12000** مشارکت کننده است که به ترجمه، نگارش، طراحی و نگهداری وبسایت کمک می کنند.
-
-ما از جامعهای استقبال میکنیم که به شما کمک میکند در اکوسیستم اتریوم رشد کرده و آموزش ببینید و در عین حال به طور معناداری مشارکت کنید و تجربیات عملی مرتبط را کسب کنید!
-
-## روش های مشارکت {#ways-to-contribute}
-
-**ترجمه**
-- [به برنامه ترجمه بپیوندید](/contributing/translation-program/) – به ما کمک کنید ethereum.org را به زبان های جدید ترجمه کنیم
-
-**توسعه**
-- [روی یک مسئله باز کار کنید](https://github.com/ethereum/ethereum-org-website/issues) - کاری که ما تشخیص داده ایم نیاز به انجام دارد
-
-**طراحی**
-- [کمک به طراحی وب سایت](/contributing/design/) طراحان همه سطوح می توانند به بهبود وب سایت کمک کنند
-
-**محتوا**
-- [ایجاد/ویرایش محتوا](/contributing/#how-to-update-content) - صفحات جدیدی پیشنهاد دهید یا تغییراتی را در آنچه قبلاً در اینجا وجود دارد ایجاد کنید
-- [افزودن منابع جامعه](/contributing/content-resources/) - یک مقاله یا منبع مفید را به صفحه مربوطه اضافه کنید
-- [یک منبع طراحی پیشنهاد کنید](/contributing/design/adding-design-resources/) – منابع طراحی مفید را اضافه کنید، بهروزرسانی کنید و حذف کنید
-- [افزودن اصطلاح به واژه نامه](/contributing/adding-glossary-terms/) – به ما در ادامه گسترش [واژه نامه](/glossary/) اتریوم کمک کنید
-- [آزمونها](/contributing/quizzes/) - بانکهای سوالات آزمون را برای صفحه مربوطه اضافه، بهروزرسانی و حذف کنید
-
-**ایده برای ویژگیها**
-- [درخواست یک ویژگی](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – در مورد هر ایده ای که برای یک ویژگی یا طراحی جدید دارید به ما اطلاع دهید
-
-**لیستینگ های محصول**
-- [افزودن صرافی](/contributing/adding-exchanges/) – افزودن صرافی به [صرافییاب](/get-eth/#country-picker) ما
-- [افزودن محصول](/contributing/adding-products/) - یک دپ (dapp) یا کیف پول به صفحه مربوطه اضافه کنید
-- [افزودن ابزارهای توسعه دهنده](/contributing/adding-developer-tools/) – یک ابزار توسعه دهنده را به صفحه مربوطه اضافه کنید
-- [افزودن یک لایه 2](/contributing/adding-layer-2s/) - یک لایه 2 را به صفحه مربوطه اضافه کنید
-- [افزودن یک محصول یا خدمات سهامگذاری](/contributing/adding-staking-products/) – پروژه ای اضافه کنید که به تسهیل سهامگذاری انفرادی، سهامگذاری ادغام شده، یا سهامگذاری به عنوان خدمات کمک می کند
-- [افزودن کیف پول](/contributing/adding-wallets/) – افزودن کیف پول برای [صفحه جستجوی کیف پول](/wallets/find-wallet/)
-- [پیشنهاد پروژه برای صفحه DeSci ما](/contributing/adding-desci-projects/) – اضافه کردن پروژه ای بر پایه اتریوم که به دانش غیرمتمرکز کمک می کند
-
-سوال دیگری دارید؟ 🤔 عضو [سرور دیسکورد](https://discord.gg/ethereum-org) ما شوید
-
-## اولین اقدامات خوب برای شروع مشارکت
-
-اینها چند کار جاری هستند که می توانید به ما در حل آنها کمک کنید و مسئولیت آنها را بپذیرید. برای اکثر آنها به حساب گیتهاب نیاز دارید زیرا اکثر تغییرات در وب سایت از طریق گیتهاب انجام می شود.
-
-
-
-مشاهده تمام کارها
-
-## چطور میتوان در ethereum.org کار کرد {#how-to-update-content}
-
-اگر میخواهید در [برنامه ترجمه](/contributing/translation-program/) مشارکت کنید، از شما میخواهیم یک حساب در [Crowdin](https://crowdin.com/project/ethereum-org) ایجاد کنید. برای هر چیز دیگر - اضافه کردن یا ویرایش محتوا یا تصاویر به وب سایت، رفع اشکالات، کار بر روی کارهای باز - به یک حساب [GitHub](https://github.com/) نیاز دارید.
-
-تمام به روز رسانی ها از طریق فرآیند PR مربوط به GitHub انجام می شود. این بدان معنی است که شما یک نسخه محلی از وب سایت ایجاد می کنید، تغییرات خود را ایجاد می کنید و درخواست می کنید تا تغییرات خود را ادغام کنید. اگر قبلاً این کار را نکردهاید، دستورالعملهای موجود در پایین [مخزن GitHub](https://github.com/ethereum/ethereum-org-website) ما را دنبال کنید.
-
-برای کار بر روی هر چیزی به اجازه نیاز ندارید، اما همیشه بهتر است به ما اطلاع دهید که قصد انجام چه کاری را دارید. روش انجام این کار:
-
-- اظهار نظر در مورد یک مسئله یا PR در [GitHub](https://github.com/ethereum/ethereum-org-website)
-- ارسال پیام در [سرور دیسکورد](https://discord.gg/ethereum-org) ما
-
-قبل از مشارکت، مطمئن شوید که با موارد زیر آشنا هستید:
-
-- [دیدگاه ethereum.org](/about/) در حال تکامل
-- [اصول طراحی](/contributing/design-principles/) ما
-- [راهنمای سبک](/contributing/style-guide/) ما
-- [آیین رفتاری](/community/code-of-conduct) ما
-
-
-
-## نحوه تصمیم گیری در مورد سایت {#how-decisions-about-the-site-are-made}
-
-تصمیم گیری در مورد روابط عمومی فردی، تکامل طراحی و ارتقاءهای عمده توسط تیمی از سراسر اکوسیستم اتریوم گرفته می شود. این تیم شامل مدیران پروژه، توسعه دهندگان، طراحان، بازاریابی و ارتباطات و کارشناسان موضوع است. ورودی جامعه، هر تصمیم را اطلاع می دهد: بنابراین لطفاً در مسائل سؤالات خود را مطرح کنید، PR ارسال کنید یا با تیم تماس بگیرید:
-
-- [website@ethereum.org](mailto:website@ethereum.org)
-- [@ethdotorg](https://twitter.com/ethdotorg)
-- [سرور دیسکورد](https://discord.gg/ethereum-org)
-
-### یادداشتی در مورد سرقت ادبی {#plagiarism}
-
-هنگام مشارکت هر گونه محتوا یا محصول در ethereum.org فقط از اثر یا محتوای اصلی خود استفاده کنید که اجازه استفاده از آن را دارید. بسیاری از پروژههای موجود در اکوسیستم اتریوم از مجوز منبع باز استفاده میکنند که امکان اشتراکگذاری رایگان اطلاعات را فراهم میکند. با این حال، اگر نمی توانید این اطلاعات را پیدا کنید، سعی نکنید آن را به ethereum.org اضافه کنید. هر درخواست ادغام که به عنوان سرقت ادبی تلقی شود رد خواهد شد.
-
-## در فضای منبع باز تازه کار هستید؟ {#new-to-open-source}
-
-ما در مخزن GitHub خود موانع کمی برای ورود مسائل داریم که به طور خاص برای توسعه دهندگانی که به تازگی با منبع باز کار میکنند، با برچسب [اولین مسئله خوب](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) طراحی شده اند.
-
-## توکن موفقیت روی زنجیر (OAT) خود را مطالبه کنید {#oat}
-
-اگر مشارکت شما در ethereum.org ادغام شود، فرصتی برای مطالبه یک توکن ویژه در [Galxe](https://app.galxe.com/quest/ethereumorg) خواهید داشت. توکن OAT دلیلی بر این است که شما کمک کردید اکوسیستم کمی بهتر شود.
-
-[جزئیات بیشتر درباره OATها](https://help.galxe.com/en/articles/7067290-galxe-oats-reward-and-celebrate-achievements)
-
-### چگونه درخواست کنید
-1. به [سرور دیسکورد](https://discord.gg/ethereum-org) ما بپیوندید.
-2. لینک مشارکت خود را در کانال `#🥇 | اثبات مشارکت` قرار دهید
-3. منتظر بمانید تا یکی از اعضای تیم ما لینک OAT را برای شما ارسال کند.
-4. OAT خود را درخواست کنید!
-
-برای مطالبه OAT فقط باید از کیف پول های خودسرپرستی استفاده کنید. از حسابهای صرافی یا سایر حسابهایی که کلیدهای خصوصی را در اختیار ندارید، استفاده نکنید، زیرا به شما اجازه دسترسی و مدیریت OAT را نمیدهند.
-
-## GitPOAP خود را مطالبه کنید {#claim-gitpoap}
-
-GitPOAP همچنین به طور خودکار مشارکت ادغام شده شما را تشخیص می دهد و به شما امکان می دهد یک POAP مشارکت کننده منحصر به فرد جداگانه را در خود پلتفرم آنها ایجاد کنید!
-
-
-### چگونه درخواست کنیم {#how-to-claim}
-
-1. [GitPOAP](https://www.gitpoap.io) را ببینید.
-2. از طریق گزینه ورود به سیستم با کیف پول خود یا حتی با ایمیل خود ارتباط برقرار کنید.
-3. نام کاربری گیتهاب، آدرس اتر، نامهای ENS یا هرگونه GitPOAP خود را جستجو کنید تا بررسی کنید واجد شرایط هستید یا خیر.
-4. اگر حساب گیتهاب شما واجد شرایط باشد، می توانید یک GitPOAP ایجاد کنید!
-
-## مشارکت کنندگان {#contributors}
-
-
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md
deleted file mode 100644
index 830700d36da..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/translation-program/faq/index.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: سوالات متداول برنامه ترجمه
-lang: fa
-description: سوالات متداول درباره برنامه ترجمه ethereum.org
----
-
-# راهنمای ترجمه ethereum.org {#translating-ethereum-guide}
-
-اگر در برنامه ترجمه تازه وارد هستید و تردید دارید که وارد شوید، در اینجا برخی از سوالات متداول هستند که میتوانند به شما کمک کنند کار را آغاز کنید. از این راهنما برای یافتن پاسخ به متداول ترین پرسش ها استفاده کنید.
-
-## آیا می توانم برای ترجمه ethereum.org دستمزد دریافت کنم؟ {#compensation}
-
-Ethereum.org یک وب سایت منبع باز است، به این معنی که هر کس می تواند مشارکت کند.
-
-برنامه ترجمه ethereum.org یک برنامه جانبی آن است و با فلسفه مشابه سازماندهی شده است.
-
-هدف برنامه ترجمه این است که محتوای اتریوم را برای همه، صرف نظر از زبان هایی که صحبت می کنند، در دسترس قرار دهد. همچنین به هر فرد دوزبانه اجازه می دهد تا با اکوسیستم اتریوم درگیر شود و به روشی قابل دسترس مشارکت کند.
-
-به همین دلیل، برنامه ترجمه آزاد و داوطلبانه است و شرکت در آن شامل پرداخت دستمزد نمی باشد. اگر می خواستیم به مترجمان بابت تعداد کلماتی که ترجمه می کنند دستمزد بدهیم، فقط می توانستیم از کسانی که تجربه ترجمه کافی دارند (مترجمان حرفه ای) دعوت کنیم تا به برنامه ترجمه بپیوندند. این امر برنامه ترجمه را انحصاری میکرد و ما را از دستیابی به اهداف مشخص شده باز میداشت، به ویژه: اجازه دادن به همه برای مشارکت و درگیر شدن با اکوسیستم.
-
-ما تمام تلاش خود را می کنیم تا مشارکت کنندگان خود را قادر به موفقیت در اکوسیستم اتریوم کنیم. بسیاری از مشوق های غیر پولی مانند: [ارائه POAP](/contributing/translation-program/acknowledgements/#poap) و [گواهی مترجم](/contributing/translation-program/acknowledgements/#certificate) و همچنین سازماندهی [ تابلوهای امتیازات ترجمه](/contributing/translation-program/acknowledgements/) و [فهرست کردن همه مترجمان ما در سایت](/contributing/translation-program/contributors/) وجود دارند.
-
-## چگونه می توانم سطرهای دارای `` را ترجمه کنم؟ {#tags}
-
-هر متن به شکل نوشته خالص نوشته نمیشود. متن هایی هستند که متشکل از اسکریپت های مختلفی مثل تگ های اچتیامال (`<0>`,`0>`) هستند.
-
-- متن داخل تگ ها را ترجمه کنید اما خود تگ ها را ترجمه نکنید. هیچ چیزی درون `<` و `>` نباید ترجمه یا حذف شود.
-- جهت امن نگه داشتن متن، پیشنهاد میکنیم روی دکمه "Copy Source" در گوشه پایین چپ کلیک کنید. این کار متن اولیه را کپی و در قسمت متن درج میکند. این به شما اجازه میدهد مشخص کنید که تگ ها کجا هستند و کمک میکند از اشتباه جلوگیری کنید.
-
-![رابط Crowdin با دکمه کپی از منبع، مشخص شده است](./html-tag-strings.png)
-
-شما میتوانید موقعیت تگ ها را درون متن تغییر داده و آنرا مطابق زبان خود طبیعی تر کنید - فقط اطمینان حاصل کنید تمام تگ جابجا شود.
-
-برای اطلاعات عمیقتر در مورد کار با تگها و اجزای کد، لطفاً به [راهنمای سبک ترجمه ethereum.org](/contributing/translation-program/translators-guide/#dealing-with-tags) مراجعه کنید.
-
-## متن ها کجا زندگی میکنند؟ {#strings}
-
-اغلب اوقات ممکن است کلمه های زبان منبع به تنهایی برای ارائه ترجمه دقیق کافی نباشد.
-
-- برای اطلاعات بیشتر به «اسکرین شات ها» و «زمینه» نگاهی بیندازید. در بخش سطر منبع، تصویر اسکرین شات پیوست شده را خواهید دید که نحوه استفاده از سطر در متن را به شما نشان می دهد.
-- هنگامی که مطمئن نیستید، یک پرچم در "بخش نظرات" قرار دهید. [نمیدانید چگونه نظر بدهید؟](#comment)
-
-![نشان دادن این که چگونه پسزمینه برای یک سطر دارای اسکرینشات قابل ارائه است](./source-string.png)
-
-![یک اسکرینشات نمونه برای زمینه اضافه شد](./source-string-2.png)
-
-## چگونه می توانم نظر بگذارم یا سوال بپرسم؟ می خواهم یک مسئله یا اشتباه تایپی را با پرچم نشان دهم... {#comment}
-
-اگر میخواهید روی متن خاصی که نیاز به توجه دارد پرچم قرار دهید، با خیالی آسوده نظر خود را بگذارید.
-
-- بر روی دکمه دوم نوار سمت راست بالا کلیک کنید. زبانه مخفی در سمت راست شما ظاهر خواهد شد. یک نظر جدید بگذارید و روی مربع "Issue" در پایین کلیک کنید. میتوانید نوع مساله را با انتخاب یکی از گزینههای منوی کرکرهای مشخص کنید.
-- پس از ارسال، این مورد به تیم ما گزارش می شود. ما مشکل را برطرف خواهیم کرد و با پاسخ دادن به نظر شما و بستن مسئله به شما اطلاع خواهیم داد.
-- اگر یک ترجمه نادرست را گزارش کنید، ترجمه و پیشنهاد شما توسط یک فرد با زبان اصلی در تجدید نظر بعدی بررسی میشود.
-
-![نشان دادن نحوه ارائه نظرات و مسائل](./comment-issue.png)
-
-## حافظه ترجمه یا TM چیست؟ {#translation-memory}
-
-حافظه ترجمه (TM) یکی از ویژگی های Crowdin است که تمام متن های ترجمه شده قبلی را در [ethereum.org](http://ethereum.org/) ذخیره می کند. هنگامی که یک متن ترجمه می شود، به طور خودکار در TM پروژه ما ذخیره می شود. این میتواند ابزاری مفید برای کمک به شما به منظور صرفهجویی در زمان باشد!
-
-- به بخش «پیشنهادات TM و MT» نگاه کنید و خواهید دید که دیگر مترجمان چگونه متن مشابه یا یکسانی را ترجمه کرده اند. اگر گزینهای با درجه تطابق بالا پیدا کردید، با خاطری آسوده با کلیک بر روی آن به ترجمه آن مراجعه کنید.
-- اگر چیزی در لیست وجود ندارد، میتوانید ترجمههای قبلی را در TM جستجو کنید و برای هماهنگی، مجددا از آنها استفاده کنید.
-
-![اسکرین شات حافظه ترجمه](./translation-memory.png)
-
-## چگونه از واژه نامه Crowdin استفاده کنم؟ {#glossary}
-
-اصطلاحات اتریوم بخش مهم دیگری از کار ترجمه ما است، زیرا اغلب اصطلاحات فناوری جدید هنوز در بسیاری از زبانها بومیسازی نشده اند. همچنین اصطلاحاتی وجود دارند که در زمینه های مختلف معانی متفاوت دارند. [درباره ترجمه اصطلاحات اتریوم بیشتر بدانید](#terminology)
-
-واژه نامه Crowdin بهترین مکان برای شفاف سازی اصطلاحات و تعاریف است. برای مراجعه به واژه نامه دو راه وجود دارد.
-
-- ابتدا، هنگامی که یک عبارت با خط زیر را در متن زیان منبع پیدا کردید، می توانید ماوس را روی آن قرار دهید و تعریف مختصری از آن را مشاهده کنید.
-
-![یک مثال از تعریف واژه نامه](./glossary-definition.png)
-
-- دوم، اگر عبارتی را دیدید که برایتان آشنا نیست اما زیر آن خط کشیده نشده است، می توانید آن را در زبانه واژه نامه (دکمه سوم ستون سمت راست) جستجو کنید. در آنجا توضیحاتی در مورد اصطلاحات خاص و مواردی که اغلب در پروژه استفاده می شود را خواهید یافت.
-
-![یک اسکرین شات که نشان می دهد کجا باید برگه واژه نامه را در Crowdin پیدا کنید](./glossary-tab.png)
-
-- اگر هنوز نتوانستید آن را پیدا کنید، فرصتی برای اضافه کردن یک عبارت جدید است! ما توصیه می کنیم آن را در یک موتور جستجو بیابید و توضیحات را به واژه نامه اضافه کنید. این کمک بزرگی به مترجمان دیگر برای درک بهتر این اصطلاح خواهد کرد.
-
-![یک اسکرین شات که نشان می دهد چگونه می توان یک اصطلاح واژه نامه را به Crowdin اضافه کرد](./add-glossary-term.png)
-
-### سیاست ترجمه اصطلاحات {#terminology}
-
-_برای نامها (برندها، شرکتها، افراد) و اصطلاحات فناوری جدید (بیکن چین، زنجیرههای شارد و غیره)_
-
-اتریوم اصطلاحات جدیدی را ارائه می کند که اخیراً ابداع شده اند. برخی اصطلاحات از مترجمی به مترجم دیگر متفاوت است زیرا هیچ ترجمه رسمی به زبان مربوطه آنها وجود ندارد. چنین ناهماهنگی هایی می تواند باعث سوء تفاهم شود و خوانا بودن را کاهش دهد.
-
-با توجه به تنوع زبانی و استانداردسازی های مختلف در هر زبان، ارائه یک سیاست یکپارچه ترجمه اصطلاحات که بتواند در همه زبان های پشتیبانی شده قابل انطباق باشد، تقریبا غیرممکن بوده است.
-
-پس از بررسی دقیق، به این تصمیم رسیدیم که پرکاربردترین اصطلاحات را به شما مترجمان بسپاریم.
-
-هنگامی که اصطلاحی را پیدا می کنید که برای شما ناآشنا است، پیشنهاد می کنیم:
-
-- به [واژه نامه اصطلاحات](#glossary) مراجعه کنید، ممکن است ببینید که مترجمان دیگر پیشتر چگونه آن را ترجمه کرده اند. اگر فکر میکنید اصطلاحی که قبلاً ترجمه شده مناسب نیست، با آسودگی یک عبارت جدید را به واژهنامه Crowdin بیافزایید و ترجمه خود را بازیابی کنید.
-- اگر چنین ترجمه قبلی در واژه نامه وجود ندارد، توصیه می کنیم آن را در یک موتور جستجو یا مقالهای در یک رسانه جستجو کنید که نشان می دهد این عبارت واقعاً چگونه در جامعه شما استفاده می شود.
-- اگر اصلاً هیچ مرجعی پیدا نکردید، با آسودگی به درک خود اعتماد کنید و ترجمه جدیدی را به زبان خود پیشنهاد دهید!
-- اگر برای انجام این کار اعتماد به نفس کمتری دارید، اصطلاح را ترجمه نشده بگذارید. گاهی اوقات، اصطلاحات انگلیسی در ارائه تعاریف دقیق بیش از اندازه کافی هستند.
-
-توصیه میکنیم نام برندها، شرکتها و کارکنان را ترجمه نشده بگذارید زیرا ممکن است ترجمه باعث سردرگمی غیر ضروری و مشکلات بهینه سازی موتور جستجو (SEO) شود.
-
-## روند ویرایش چگونه است؟ {#review-process}
-
-برای اطمینان از سطح مشخصی از کیفیت و سازگاری در ترجمههایمان، ما با [Acolad](https://www.acolad.com/)، یکی از بزرگترین ارائهدهندگان خدمات زبان در سطح جهان، کار میکنیم. Acolad دارای 20،000 کارشناس حرفه ای زبان است، به این معنی که آنها می توانند برای هر زبان و نوع محتوایی که نیاز داریم، داوران حرفه ای ارائه دهند.
-
-روند ویرایش ساده است. هنگامی که یک [سبد محتوا](/contributing/translation-program/content-buckets) 100٪ ترجمه شد، ما سفارش بررسی آن سبد محتوا را می دهیم. فرآیند ویرایش مستقیماً در Crowdin انجام می شود. پس از تکمیل ویرایش، وبسایت را با محتوای ترجمه شده به روز می کنیم.
-
-## چگونه به زبان خودم محتوا اضافه کنم؟ {#adding-foreign-language-content}
-
-هماکنون، تمام محتواهای غیر انگلیسی مستقیما از انگلیسی ترجمه میشوند و هر محتوایی که در زبانی غیر از انگلیسی موجود باشد نمیتواند به دیگر زبانها اضافه شود.
-
-برای پیشنهاد محتوای جدید به ethereum.org، میتوانید در گیتهاب [یک مسئله ثبت کنید.](https://github.com/ethereum/ethereum-org-website/issues). در صورت اضافه شدن، این محتوا به انگلیسی نوشته میشود و با استفاده از Crowdin به دیگر زبانها ترجمه میشود.
-
-ما در نظر داریم پشتیبانی برای محتواهای غیر انگلیسی را در آیندهای نزدیک اضافه کنیم.
-
-## در ارتباط باشید {#contact}
-
-متشکریم که تمام این مطالب را مطالعه کردید. امیدواریم این کار به شما کمک کند تا در برنامه ما حضور داشته باشید. به [کانال ترجمه دیسکورد](https://discord.gg/ethereum-org) ما بپیوندید و در آن از دیگر مترجمین سوال بپرسید و با آنها همکاری کنید، یا با ما با ایمیل translations@ethereum.org در ارتباط باشید!
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md
deleted file mode 100644
index 994adc6f47a..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/translation-program/how-to-translate/index.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: چگونه ترجمه کنیم
-lang: fa
-description: راهنمای استفاده از Crowdin جهت ترجمه ethereum.org
----
-
-# چگونه ترجمه کنیم {#how-to-translate}
-
-## راهنمای تصویری {#visual-guide}
-
-برای افرادی که یادگیری تصویری را ترجیح میدهند، راهنمای ساخت حساب کاربری Crowdin با لوکا را تماشا کنید. همچنین میتوانید تمامی مراحل طی شده را در قالب متن، در بخش بعدی پیدا کنید.
-
-
-
-## راهنمای نوشتاری {#written-guide}
-
-### به پروژه ما در سایت Crowdin بپیوندید {#join-project}
-
-شما باید به حساب کاربری خود در Crowdin وارد شوید و یا اگر از قبل حسابی ندارید، ثبتنام کنید. برای ثبت نام تنها چیزی که لازم است یک حساب ایمیل و رمز عبور است.
-
-
- به پروژه ما بپیوندید
-
-
-### زبان خود را انتخاب کنید {#open-language}
-
-بعد از ورود به حساب Crowdin، شما جزئیات پروژه و لیست تمامی زبانهای موجود را مشاهده خواهید کرد. همچنین، هر زبان شامل اطلاعاتی درباره تعداد کل کلمات قابل ترجمه و یک نمای کلی از مقدار محتوای ترجمه و تائید شده در آن زبان میباشد.
-
-زبانی که میخواهید ترجمه کنید را انتخاب نموده تا لیست فایلهای موجود برای ترجمه را مشاهده کنید.
-
-![فهرست زبان ها در Crowdin](./list-of-languages.png)
-
-### سندی را برای کار پیدا کنید {#find-document}
-
-محتوای وب سایت به تعدادی اسناد و سطل محتوا تقسیم می شود. می توانید پیشرفت هر سند را در سمت راست بررسی کنید - اگر پیشرفت ترجمه زیر 100٪ است، لطفا مشارکت کنید!
-
-زبان خود را در فهرست نمی بینید؟ [یک مسئله باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new/choose) یا در [دیسکورد](/discord/) ما بپرسید
-
-![فایل های ترجمه شده و ترجمه نشده در Crowdin](./crowdin-files.png)
-
-نکتهای در مورد سبد های محتوا: ما از «سبد های محتوا» در Crowdin استفاده میکنیم تا ابتدا محتوای دارای بالاترین اولویت منتشر شود. زمانی که یک زبان، برای مثال [فیلیپینی](https://crowdin.com/project/ethereum-org/fil#) را نگاه میکنید، پوشههایی برای سبد محتوا میبینید («۱. صفحه خانه»، «۲. ضروریات"، "3. اکتشاف"، و غیره).
-
-ما به شما توصیه میکنیم به ترتیب (... → ۳ → ۲ → ۱) ترجمه کنید که صفحات با بیشترین استفاده اول ترجمه شوند.
-
-[درباره سبدهای محتوای ethereum.org بیشتر بیاموزید](/contributing/translation-program/content-buckets/)
-
-### ترجمه کنید {#translate}
-
-پس از انتخاب فایلی که می خواهید ترجمه کنید، در ویرایشگر آنلاین باز خواهد شد. اگر قبلاً از Crowdin استفاده نکردهاید، میتوانید از این راهنمای سریع برای مرور اصول اولیه استفاده کنید.
-
-![ویرایشگر آنلاین Crowdin](./online-editor.png)
-
-**_1 – نوار کناری سمت چپ_**
-
-- ترجمه نشده (قرمز) – متنی که هنوز روی آن کار نشده است. اینها متن هایی هستند که باید ترجمه کنید.
-- ترجمه شده (سبز) - متنی که قبلا ترجمه شده است، اما هنوز بازبینی نشده است. میتوانید ترجمههای دیگری را پیشنهاد دهید یا با استفاده از دکمههای «+» و «-» در ویرایشگر، به ترجمههای موجود رأی دهید.
-- تایید شده (علامت تیک) - متنی که قبلاً بررسی شده و در حال حاضر در وبسایت فعال است.
-
-همچنین میتوانید از دکمههای بالای صفحه به منظور جستجوی متنی خاص، فیلتر کردن آنها بر اساس وضعیت یا تغییر نما استفاده کنید.
-
-**_2 - بخش ویرایشگر_**
-
-منطقه اصلی ترجمه - متن مبدأ در بالا با زمینه و اسکرینشات های اضافی، در صورت وجود، نمایش داده می شود. برای پیشنهاد ترجمه جدید، ترجمه خود را در قسمت "Enter translation here" وارد کنید و روی Save کلیک کنید.
-
-همچنین میتوانید ترجمههای موجود متن و ترجمهها به زبانهای دیگر و همچنین تطبیق حافظه ترجمه و پیشنهادات ترجمه ماشینی را در این بخش بیابید.
-
-**_3 - نوار کناری سمت راست_**
-
-اینجا جایی است که می توانید نظرات، گزینههای حافظه ترجمه و گزینههای واژه نامه را بیابید. نمای پیشفرض نظرات را نشان میدهد و به مترجمان اجازه میدهد با هم ارتباط برقرار کنند، مسائل را مطرح کنند یا ترجمههای نادرست را گزارش کنند.
-
-با استفاده از دکمههای بالای صفحه، میتوانید به حافظه ترجمه بروید که در آن میتوانید ترجمههای موجود را جستجو کنید، یا به واژهنامه بروید که حاوی توضیحات و ترجمههای استاندارد واژههای کلیدی است.
-
-میخواهید بیشتر بدانید؟ با خیالی راحت می توانید [اسناد نحوه استفاده از ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) را بررسی کنید
-
-### فرایند بازبینی {#review-process}
-
-هنگامی که ترجمه را کامل کردید (یعنی همه فایلهای سبد محتوا 100% را نشان میدهد)، خدمات ترجمه حرفهای ما محتوا را بررسی میکند (و احتمالاً ویرایش میکند). پس از تکمیل بررسی (یعنی وقتی پیشرفت بازبینی 100٪ شد)، آن را به وب سایت اضافه می کنیم.
-
-
- لطفا از ترجمههای ماشینی برای ترجمه پروژه استفاده نکنید. همه ترجمهها پیش از اضافه شدن به وبسایت بررسی میشوند. اگر ترجمههای شما، ترجمه ماشینی به نظر برسند، رد میشوند و افرادی که از ترجمههای ماشینی استفاده کنند معمولا از پروژه حذف میشوند.
-
-
-### در ارتباط باشید {#get-in-touch}
-
-سوالی دارید؟ یا می خواهید با تیم ما و سایر مترجمان همکاری کنید؟ لطفاً در کانال [سرور دیسکورد ethereum.org](/discord/) ما پست کنید
-
-همچنین می توانید از طریق translations@ethereum.org با ما در تماس باشید
-
-از مشارکت شما در برنامه ترجمه ethereum.org سپاسگزاریم!
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/index.md
deleted file mode 100644
index f97ffa43681..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/translation-program/index.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: برنامه ترجمه
-lang: fa
-description: اطلاعاتی درباره برنامه ترجمه ethereum.org
----
-
-# برنامه ترجمه {#translation-program}
-
-برنامه ترجمه یک تلاش مشترک برای ترجمه ethereum.org به زبان های مختلف است تا این وب سایت برای میلیاردها غیر انگلیسی زبان در سراسر جهان در دسترس تر باشد.
-
-![](./enterprise-eth.png)
-
-## در ترجمه به ما کمک کنید {#help-us-translate}
-
-برنامه ترجمه ethereum.org باز است و هر کس می تواند مشارکت کند!
-
-1. ابتدا باید وارد حساب Crowdin خود شوید یا ثبت نام کنید.
-2. زبانی را که می خواهید در آن مشارکت کنید انتخاب کنید.
-3. قبل از شروع، لطفاً راهنمای [نحوه ترجمه](/contributing/translation-program/how-to-translate/) را برای یادگیری نحوه استفاده از Crowdin و [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) را برای نکات و بهترین روش ها مطالعه کنید.
-4. ترجمههای ماشینی تایید نخواهند شد.
-5. همه ترجمهها قبل از اضافه شدن به سایت اصلی بررسی میشوند، بنابراین قبل از انتشار ترجمههای شما تأخیر کوتاهی وجود خواهد داشت.
-
-_به دیسکورد [ethereum.org Discord](/discord/) بپیوندید تا در ترجمه ها همکاری کنید، سؤال بپرسید، نظرات و ایده ها را به اشتراک بگذارید، یا به یک گروه ترجمه بپیوندید._
-
-
- شروع به ترجمه کنید
-
-
-## درباره برنامه ترجمه {#about-us}
-
-جامعه اتریوم قصد دارد جهانی و فراگیر باشد، با این حال بسیاری از محتوای آن فقط مختص انگلیسی زبانها است و 6 میلیارد غیرانگلیسی زبان دنیا کنار گذاشته شده اند. برای اینکه ethereum.org به عنوان پورتال اتریوم برای جامعه جهانی عمل کند، ما بر این باوریم که ارائه محتوای اتریوم به زبان مادری برای غیر انگلیسی زبانان ضروری است.
-
-هدف از برنامه ترجمه ethereum.org این است که با ترجمه ethereum.org و دیگر مطالب اتریوم به تعداد زیادی از زبانها، در دسترس همگان قرار گیرد.
-
-درباره [مأموریت و چشم انداز](/contributing/translation-program/mission-and-vision) برنامه ترجمه ethereum.org بیشتر بخوانید.
-
-### پیشرفت ما تاکنون {#our-progress}
-
-- [بیش از **6,000 +** مترجم](/contributing/translation-program/contributors/)
-- **62** زبان در سایت موجود است
-- [ترجمه **3 میلیون** کلمه در سال 2023](/contributing/translation-program/acknowledgements/)
-
-
-
-### تقدیرات {#acknowledgements}
-
-Ethereum.org توسط هزاران نفر از اعضای انجمن، ترجمه شده و این جامعه بخش کلیدی برنامه ترجمه است. ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. در اینجا برخی از قدردانی های ما از مترجمان آمده است. ما می خواهیم از مترجمان خود قدردانی کنیم و از آنها در مسیر شغلی شان حمایت کنیم. در اینجا برخی از قدردانی های ما از مترجم ها آمده است:
-
-#### گواهی {#certificate}
-
-اگر در برنامه ترجمه مشارکت کرده اید و حداقل 5000 کلمه ترجمه شده شما تایید شده است، واجد شرایط دریافت گواهی مترجم ethereum.org هستید. [جزئیات بیشتر در باره گواهیها](/contributing/translation-program/acknowledgements/#certificate)
-
-#### OATها {#oats}
-
-مشارکت کنندگان در برنامه ترجمه بر اساس تعداد کلمات ترجمه شده در سال 2024، واجد شرایط OAT های مختلف (توکن های موفقیت زنجیره ای) هستند. OATها NFTهایی هستند که مشارکت شما در برنامه ترجمه ethereum.org را ثابت می کنند. [جزئیات بیشتر درباره OATها](/contributing/translation-program/acknowledgements/#oats)
-
-#### قدردانی از مترجمها {#translator-acknowledgements}
-
-قدردانی عمومی از مترجمان برتر ما از طریق [تابلوهای امتیازات](/contributing/translation-program/acknowledgements/) و [فهرستی از همه مشارکت کنندگان در برنامه ترجمه](/contributing/translation-program/contributors/) می باشد.
-
-#### پاداشها {#rewards}
-
-در گذشته، ما به فعالترین مشارکتکنندگان خود، بلیطهایی برای کنفرانسهای اتریوم مانند [Devcon](https://devcon.org/en/) و [Devconnect](https://devconnect.org/) و همچنین کادوهای انحصاری ethereum.org پاداش دادهایم.
-
-ما دائماً به روشهای جدید و نوآورانه برای پاداش دادن به مشارکتکنندگان خود فکر میکنیم، پس با ما همراه باشید!
-
-### راهنماها و منابع {#guides-and-resources}
-
-اگر در برنامه ترجمه مشارکت می کنید یا به فکر مشارکت هستید، باید راهنمای ترجمه زیر را بررسی کنید:
-
-- [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) _– دستورالعمل ها و نکاتی برای مترجمان ethereum.org_
-- [سؤالات متداول ترجمه](/contributing/translation-program/faq/) _– پرسشها و پاسخهای متداول درباره برنامه ترجمه ethereum.org_
-- [راهنمای ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) _– یک راهنمای عمیق برای استفاده از ویرایشگر آنلاین Crowdin و برخی ویژگی های پیشرفته Crowdin_
-- [سطل های محتوا](/contributing/translation-program/content-buckets/)_ – کدام صفحات در هر سطل محتوای ethereum.org گنجانده شده است_
-
-برای بررسی دیگر ابزارهای مفید ترجمه، انجمن های مترجمین و پست های وبلاگ برنامه ترجمه، لطفاً از [صفحه منابع](/contributing/translation-program/resources/) دیدن کنید.
-
-## در ارتباط باشید {#get-in-touch}
-
-سوالی دارید؟ یا می خواهید با تیم ما و سایر مترجمان همکاری کنید؟ لطفاً در کانال [سرور دیسکورد ethereum.org](https://discord.gg/ethereum-org) ما پست کنید
-
-همچنین می توانید از طریق translations@ethereum.org با ما در تماس باشید
-
-## برنامه ترجمه خود را شروع کنید {#starting-a-translation-program}
-
-ما به ترجمه محتوای اتریوم به زبانهای هر چه بیشتر و در دسترس قرار دادن محتوای آموزشی برای همه تعهد داریم. در راستای تمرکزمان بر ترجمه، میخواهیم به سایر پروژههای اتریوم در سازماندهی، مدیریت و بهبود تلاشهای ترجمه آنها کمک کنیم.
-
-به همین دلیل، ما یک [کتابچه برنامه ترجمه](/contributing/translation-program/playbook/) تهیه کرده ایم که حاوی نکات و بهترین روش هایی است که در فرآیند ترجمه ethereum.org به کار گرفته ایم.
-
-آیا میخواهید بیشتر همکاری کنید یا از برخی منابع ترجمهمان استفاده کنید؟ آیا بازخوردی در مورد کتاب بازی دارید؟ ما دوست داریم از نظرات شما در translations@ethereum.org آگاه شویم.
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md
deleted file mode 100644
index 408c60791ed..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/translation-program/mission-and-vision/index.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: مأموریت و چشمانداز
-lang: fa
-description: ماموریت و چشم انداز برنامه ترجمه ethereum.org
----
-
-# مأموریت و چشمانداز {#mission-and-vision}
-
-جامعه اتریوم قصد دارد جهانی و فراگیر باشد، با این حال بسیاری از محتوای آن فقط مختص انگلیسی زبانها است و 6 میلیارد غیرانگلیسی زبان دنیا کنار گذاشته شده اند. برای اینکه ethereum.org به عنوان پورتال اتریوم برای جامعه جهانی عمل کند، ما بر این باوریم که ارائه محتوای اتریوم به زبان مادری برای غیر انگلیسی زبانان ضروری است.
-
-هدف از برنامه ترجمه ethereum.org این است که با ترجمه ethereum.org و دیگر مطالب اتریوم به تعداد زیادی از زبانها، در دسترس همگان قرار گیرد.
-
-## ماموریت ما {#our-mission}
-
-- ارائه نسخههای ترجمهشده وبسایت به بازدیدکنندگان در سراسر جهان برای یادگیری درباره اتریوم به زبان مادری شان
-- تسهیل ورود اعضای بیشتر به جامعه جهانی اتریوم
-- امکان پذیر کردن دسترسی بیشتر و فراگیرتر شدن اشتراک گذاری اطلاعات و دانش اتریوم
-- توانمند ساختن اعضای جامعه برای همکاری در زمینه ترجمه با اتریوم و ایجاد اثر خود در اکوسیستم
-- شناسایی، ایجاد ارتباط و ارائه راهنمایی برای مشارکت کنندگان پرشوری که به دنبال مشارکت در اکوسیستم هستند
-
-## چشمانداز ما {#our-vision}
-
-- ترجمه محتوای اساسی برای اعضای جامعه اتریوم از بسیاری از کشورها و بخشهای جهان تا جایی که ممکن است
-- پشتیبانی اشتراکگذاری دانش به زبانهای مختلف برای ایجاد یک جامعه آگاه و آموزش دیده
-- افزایش فراگیری و دسترسی اتریوم، با حذف موانع زبانی که از پیوستن غیرانگلیسی زبانان به اکوسیستم جلوگیری می کند
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md
deleted file mode 100644
index fa7e39d5113..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/translation-program/resources/index.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: منابعی برای مترجمان
-lang: fa
-description: منابع مفید برای مترجمان ethereum.org
----
-
-# منابع {#resources}
-
-میتوانید برخی از راهنماها و ابزارهای مفید برای مترجمان ethereum.org، و همچنین انجمنهای ترجمه و بروزرسانیها را در زیر بیابید.
-
-## راهنماییها {#guides}
-
-- [راهنمای سبک ترجمه](/contributing/translation-program/translators-guide/) _– دستورالعمل ها و نکاتی برای مترجمان ethereum.org_
-- [سؤالات متداول ترجمه](/contributing/translation-program/faq/) _– پرسشها و پاسخهای متداول درباره برنامه ترجمه ethereum.org_
-- [راهنمای ویرایشگر آنلاین Crowdin](https://support.crowdin.com/online-editor/) _– یک راهنمای عمیق برای استفاده از ویرایشگر آنلاین Crowdin و برخی ویژگی های پیشرفته Crowdin_
-- [سطل های محتوا](/contributing/translation-program/content-buckets/)_ – کدام صفحات در هر سطل محتوای ethereum.org گنجانده شده است_
-
-## ابزارها {#tools}
-
-- [پورتال زبان مایکروسافت](https://www.microsoft.com/en-us/language) _– برای یافتن و بررسی ترجمههای استاندارد اصطلاحات فنی، مفید است_
-- [Linguee](https://www.linguee.com/) _– موتور جستجو برای ترجمه ها و فرهنگ لغت که امکان جستجو بر اساس کلمه یا عبارت را فراهم می کند_
-- [جستجوی عبارت Proz](https://www.proz.com/search/) _– پایگاه داده لغت نامه ها و واژه نامه های ترجمه برای اصطلاحات تخصصی_
-- [Eurotermbank](https://www.eurotermbank.com/) _– مجموعههایی از اصطلاحات اروپایی به ۴۲ زبان_
-
-## جوامع {#communities}
-
-- [گروه های ترجمه خاص زبان در دیسکورد](/discord/) _– ابتکاری برای ارتباط مترجمان ethereum.org با گروه های ترجمه_
-- [گروه مترجمان چینی](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _– صفحه ایده برای هماهنگی آسانتر میان مترجمان چینی_
-
-## آخرین به روزرسانی ها {#latest-updates}
-
-برای به روز نگه داشتن آخرین پیشرفت برنامه ترجمه، می توانید [وبلاگ بنیاد اتریوم](https://blog.ethereum.org/) را دنبال کنید:
-
-- [به روز رسانی نقاط عطف اکتبر ۲۰۲۱](https://blog.ethereum.org/2021/10/04/translation-program-update/)
-- [به روز رسانی نقاط عطف دسامبر 2020](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/)
-- [به روز رسانی نقاط عطف ژوئیه 2020](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/)
-- [راه اندازی برنامه ترجمه اوت 2019](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/)
-
-## ساعات کاری برای مترجمین {#office-hours}
-
-ما برای مترجمین، ساعات کاری را در چهارشنبه دوم هر ماه داریم. این ساعات در کانال صوتی (غیرمتنی) #office-hours در [ethereum.org Discord](/discord/) نگهداری میشوند که می توانید زمان دقیق و جزییات بیشتر را در آن بیابید.
-
-ساعات کاری به مترجمان ما امکان میدهد درباره فرآیند ترجمه سؤال بپرسند، درباره برنامه بازخورد ارائه کنند، ایدههای خود را به اشتراک بگذارند یا با تیم اصلی ethereum.org چت کنند. در نهایت، میخواهیم از این ارتباطات برای برقراری ارتباط با پیشرفتهای اخیر در برنامه ترجمه و به اشتراک گذاشتن نکات و دستورالعملهای کلیدی با همکاران مان استفاده کنیم.
-
-اگر شما یک مترجم ethereum.org هستید یا علاقه دارید باشید، میتوانیم در یکی از این جلسات به ما ملحق شوید.
diff --git a/public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md b/public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md
deleted file mode 100644
index 730a2a34a0c..00000000000
--- a/public/content/translations/fa/27) Contributing/contributing/translation-program/translators-guide/index.md
+++ /dev/null
@@ -1,293 +0,0 @@
----
-title: راهنمای مترجمان
-lang: fa
-description: دستورالعمل ها و نکات برای مترجمان ethereum.org
----
-
-# راهنمای سبک ترجمه Ethereum.org {#style-guide}
-
-راهنمای سبک ترجمه ethereum.org حاوی برخی از مهم ترین دستورالعمل ها، دستورالعمل ها و نکات برای مترجمان است که به ما کمک می کند تا وبسایت را بومی سازی کنیم.
-
-این سند به عنوان یک راهنمای کلی عمل می کند و مختص هیچ زبانی نیست.
-
-اگر سؤال، پیشنهاد یا بازخوردی دارید، میتوانید با ما در آدرس ایمیل translations@ethereum.org تماس بگیرید، به هندل @ethdotorg در Crowdin پیام ارسال کنید، یا [به دیسکورد ما بپیوندید](https://discord.gg/ethereum-org) که در آنجا میتوانید در کانال #translations به ما پیام بدهید یا با هر یک از اعضای تیم تماس بگیرید.
-
-## استفاده از Crowdin {#using-crowdin}
-
-میتوانید دستورالعملهای اساسی در مورد نحوه پیوستن به پروژه در Crowdin و نحوه استفاده از ویرایشگر آنلاین Crowdin را در [صفحه برنامه ترجمه](/contributing/translation-program/#how-to-translate) بیابید.
-
-اگر میخواهید درباره Crowdin و استفاده از برخی از ویژگیهای پیشرفته آن اطلاعات بیشتری کسب کنید، [کتابخانه Crowdin](https://support.crowdin.com/online-editor/) حاوی تعداد زیادی راهنماهای مفید و مروری بر همه عملکردهای Crowdin است.
-
-## دریافت ماهیت پیام {#capturing-the-essence}
-
-هنگام ترجمه محتوای ethereum.org، از ترجمه تحتالفظی اکیداً خودداری کنید.
-
-مهم این است که ترجمه ها جوهر پیام را در بر بگیرند. این میتواند به معنای بازنویسی عبارات خاص یا استفاده از ترجمههای توصیفی به جای ترجمه کلمه به کلمه محتوا باشد.
-
-زبان های مختلف قواعد گرامری، قراردادها و ترتیب کلمات متفاوتی دارند. هنگام ترجمه، لطفاً به نحوه ساختار جملات در زبان مقصد توجه داشته باشید و از ترجمه تحتالفظی منبع انگلیسی خودداری کنید، زیرا این کار می تواند منجر به ساختار ضعیف جمله و خوانایی آن شود.
-
-به جای ترجمه کلمه به کلمه متن مبدأ، توصیه می شود کل جمله را بخوانید و آن را با معادل های زبان مقصد مطابقت دهید.
-
-## رسمی مقابل غیررسمی {#formal-vs-informal}
-
-ما از فرم رسمی آدرس استفاده می کنیم که همیشه مودبانه و مناسب برای همه بازدیدکنندگان است.
-
-استفاده از آدرس رسمی به ما این امکان را می دهد که از به نظر رسیدن غیررسمی یا توهین آمیز جلوگیری کنیم و بدون در نظر گرفتن سن و جنسیت بازدیدکننده کار می کند.
-
-بیشتر زبان های هند و اروپایی و آفریقایی-آسیایی از ضمایر شخصی دوم شخص مخصوص جنسیت استفاده می کنند که بین مذکر و مؤنث تمایز قائل می شود. هنگام خطاب کردن کاربر یا استفاده از ضمایر ملکی، میتوانیم از فرض جنسیت بازدیدکننده خودداری کنیم، زیرا شکل رسمی آدرس، صرف نظر از نحوه شناسایی آنها، عموماً قابل اجرا و سازگار است.
-
-## واژگان و معنی ساده و واضح {#simple-vocabulary}
-
-هدف ما این است که محتوای موجود در وبسایت را برای افراد هر چه بیشتری قابل درک کنیم.
-
-در اغلب موارد، با استفاده از کلمات کوتاه و ساده که به راحتی قابل درک هستند، می توان به این امر دست یافت. اگر چندین ترجمه ممکن برای یک کلمه خاص در زبان شما با همان معنی وجود داشته باشد، بهترین گزینه اغلب کوتاهترین کلمهای است که به وضوح معنی را منعکس میکند.
-
-## سیستم نوشتاری {#writing-system}
-
-Ethereum.org به چندین زبان با استفاده از سیستم های نوشتاری جایگزین (یا اسکریپت های نوشتن) به لاتین در دسترس است.
-
-تمام محتوا باید با استفاده از سیستم نوشتاری صحیح برای زبان شما ترجمه شود و نباید شامل هیچ کلمه ای باشد که با حروف لاتین نوشته شده باشد.
-
-هنگام ترجمه محتوا، باید اطمینان حاصل کنید که ترجمه ها سازگار هستند و شامل هیچ گونه حروف لاتین نمی شوند.
-
-یک تصور غلط رایج این است که اتریوم همیشه باید به زبان لاتین نوشته شود. این بیشتر نادرست است، لطفاً از املای اتریوم بومی زبان خود استفاده کنید (به عنوان مثال 以太坊 در چینی، إيثيريوم در عربی و غیره).
-
-**موارد فوق در مورد زبانها صدق نمیکند، جایی که نامهای خاص بهعنوان قاعده نباید ترجمه شوند.**
-
-## ترجمه متادیتای صفحه {#translating-metadata}
-
-برخی از صفحات حاوی ابرداده در صفحه هستند، مانند «عنوان»، «زبان»، «توضیحات»، «نوار کناری» و غیره.
-
-ما محتوایی را که مترجمان هرگز نباید هنگام آپلود صفحات جدید در Crowdin ترجمه کنند، پنهان می کنیم، به این معنی که تمام متادیتا های قابل مشاهده برای مترجمان در Crowdin باید ترجمه شوند.
-
-لطفاً هنگام ترجمه هر رشته ای که متن مبدأ "en" است، به ویژه مراقب باشید. این نشان دهنده زبانی است که صفحه به آن در دسترس است و باید به [کد زبان ISO برای زبان شما](https://www.andiamo.co.uk/resources/iso-language-codes/) ترجمه شود. این رشته ها باید همیشه با استفاده از حروف لاتین ترجمه شوند، نه خط نوشتاری، بومی زبان مقصد.
-
-اگر مطمئن نیستید از کدام کد زبان استفاده کنید، می توانید حافظه ترجمه را در Crowdin بررسی کنید یا کد زبان خود را در URL صفحه در ویرایشگر آنلاین Crowdin پیدا کنید.
-
-چند نمونه از کدهای زبان برای رایجترین زبانها:
-
-- عربی - ar
-- چینی ساده - zh
-- فرانسه - fr
-- هندی - hi
-- اسپانیایی - es
-
-## عناوین مقالات خارجی {#external-articles}
-
-برخی رشته ها حاوی عناوین مقالات خارجی هستند. اکثر صفحات مستندات توسعه دهنده ما حاوی پیوندهایی به مقالات خارجی برای مطالعه بیشتر هستند. رشته های حاوی عناوین مقالات باید بدون توجه به زبان مقاله ترجمه شوند تا از تجربه کاربری سازگارتر بازدیدکنندگانی که صفحه را به زبان خود مشاهده می کنند اطمینان حاصل شود.
-
-میتوانید نمونههایی از شکل ظاهری این رشتهها برای مترجمان و نحوه شناسایی آنها را در زیر بیابید (پیوندهای مقالهها را میتوانید بیشتر در پایین این صفحات، در بخش «مطالعه بیشتر» پیدا کنید):
-
-![عنوان مقالات در sidebar.png](./article-titles-in-sidebar.png) ![عنوان مقالات در editor.png](./article-titles-in-editor.png)
-
-## هشدارهای Crowdin {#crowdin-warnings}
-
-Crowdin دارای یک ویژگی داخلی است که به مترجمان هنگام اشتباه کردن هشدار می دهد. اگر فراموش کنید برچسبی را از منبع اضافه کنید، عناصری را که نباید ترجمه شوند، چندین فاصله متوالی اضافه کنید، علائم نگارشی پایان را فراموش کنید و غیره را فراموش کنید، قبل از ذخیره ترجمه به طور خودکار به شما در این مورد هشدار می دهد. اگر چنین هشداری را مشاهده کردید، لطفاً به عقب برگردید و ترجمه پیشنهادی را دوباره بررسی کنید.
-
-**هرگز این اخطارها را نادیده نگیرید، زیرا معمولاً به این معنی است که چیزی اشتباه است یا اینکه ترجمه قسمتی کلیدی از متن منبع را از دست داده است.**
-
-نمونه ای از هشدار Crowdin هنگامی که فراموش می کنید یک برچسب به ترجمه خود اضافه کنید: ![نمونه ای از هشدار Crowdin](./crowdin-warning-example.png)
-
-## نحوه کار با برچسب ها و تکه های کد {#dealing-with-tags}
-
-بسیاری از محتوای منبع حاوی برچسب ها و متغیرهایی هستند که در ویرایشگر Crowdin با رنگ زرد مشخص شده اند. اینها کارکردهای مختلفی دارند و باید به درستی به آنها پرداخت.
-
-**تنظیمات Crowdin**
-
-برای سهولت در مدیریت برچسب ها و کپی مستقیم آنها از منبع، توصیه می کنیم تنظیمات خود را در ویرایشگر Crowdin تغییر دهید.
-
-1. تنظیمات را باز کنید ![نحوه باز کردن تنظیمات در ویرایشگر](./editor-settings.png)
-
-2. تا بخش «نمایش برچسبهای HTML» به پایین بروید
-
-3. گزینه 'Hide' را انتخاب کنید ![لطفاً گزینه "پنهان کردن" را انتخاب کنید](./hide-tags.png)
-
-4. روی 'Save' کلیک کنید
-
-با انتخاب این گزینه دیگر متن کامل تگ نمایش داده نمی شود و یک عدد جایگزین می شود. هنگام ترجمه، با کلیک بر روی این تگ، به طور خودکار تگ دقیق در قسمت ترجمه کپی می شود.
-
-**لینکها**
-
-ممکن است متوجه لینک های کامل به صفحات در ethereum.org یا وبسایت های دیگر شوید.
-
-این لینک ها باید با منبع یکسان باشند و تغییر یا ترجمه نشوند. اگر لینکی را ترجمه کنید یا به هر نحوی آن را تغییر دهید، حتی فقط بخشی از آن را حذف کنید، مانند اسلش (/)، منجر به شکستگی و غیرقابل استفاده شدن لینک می شود.
-
-بهترین راه برای مدیریت لینک ها این است که آنها را مستقیماً از منبع کپی کنید، یا با کلیک بر روی آنها یا با استفاده از دکمه "کپی منبع" (Alt+C).
-
-![مثال link.png](./example-of-link.png)
-
-لینک ها همچنین در متن مبدأ به شکل برچسب ظاهر می شوند (یعنی <0> 0>). اگر ماوس را روی برچسب نگه دارید، ویرایشگر محتوای کامل آن را نشان می دهد - گاهی اوقات این برچسب ها نشان دهنده لینکها هستند.
-
-بسیار مهم است که لینک ها را از منبع کپی کنید و ترتیب آنها را تغییر ندهید.
-
-اگر ترتیب تگ ها تغییر کند، لینکی که آنها نشان می دهند شکسته می شود.
-
-![نمونه ای از لینکهای داخل tags.png](./example-of-links-inside-tags.png)
-
-**برچسب ها و متغیرها**
-
-متن منبع حاوی انواع مختلفی از تگ ها است که همیشه باید از منبع کپی شوند و هرگز تغییر نکنند. مانند موارد بالا، ترتیب این برچسب ها در ترجمه نیز باید مانند منبع باقی بماند.
-
-برچسب ها همیشه حاوی یک تگ باز و بسته هستند. در بیشتر موارد، متن بین تگ های باز و بسته باید ترجمه شود.
-
-مثال: ``غیرمتمرکز``
-
-`` - _برچسب باز که متن را پررنگ می کند_
-
-غیرمتمرکز - _متن قابل ترجمه_
-
-`` - _بستن برچسب_
-
-![مثالی از tags.png 'بولد'](./example-of-strong-tags.png)
-
-تکههای کد باید کمی متفاوت از برچسبهای دیگر باشند، زیرا حاوی کدهایی هستند که نباید ترجمه شوند.
-
-مثال: ``نانس`
`
-
-`` - _برچسب باز، که حاوی یک قطعه کد است_
-
-نانس- _متن غیرقابل ترجمه_
-
-`
` - _بستن برچسب_
-
-![مثال کد snippets.png](./example-of-code-snippets.png)
-
-متن منبع همچنین حاوی برچسب های کوتاه شده است که فقط حاوی اعداد هستند، به این معنی که عملکرد آنها بلافاصله مشخص نمی شود. میتوانید ماوس را روی این برچسبها نگه دارید تا ببینید دقیقاً کدام عملکرد را انجام میدهند.
-
-در مثال زیر، میتوانید آیتم های نگه داشتن ماوس را ببینید <0> برچسب نشان می دهد که نشان دهنده `` است و حاوی یک قطعه کد است، بنابراین محتوای داخل این برچسب ها نباید ترجمه شود.
-
-![نمونه ای از تگهای مبهم.png](./example-of-ambiguous-tags.png)
-
-## فرمها/اختصارات کوتاه یا کامل {#short-vs-full-forms}
-
-اختصارات زیادی در وب سایت استفاده می شود، به عنوان مثال. dapps و NFT و DAOو DeFi و غیره این اختصارات معمولاً در زبان انگلیسی استفاده می شوند و اکثر بازدیدکنندگان وب سایت با آنها آشنا هستند.
-
-از آنجایی که آنها معمولاً ترجمههای ثابتی به زبانهای دیگر ندارند، بهترین راه برای نزدیک شدن به این عبارات و اصطلاحات مشابه، ارائه یک ترجمه تشریحی از فرم کامل، و اضافه کردن مخفف انگلیسی در پرانتز است.
-
-این اختصارات را ترجمه نکنید، زیرا اکثر مردم با آنها آشنا نیستند و نسخه های بومی سازی شده برای اکثر بازدیدکنندگان منطقی نیست.
-
-نمونه ای از نحوه ترجمه dapps:
-
-- برنامه های غیرمتمرکز (dapps) → _فرم کامل ترجمه شده (مخفف انگلیسی در پرانتز)_
-
-## واژگانی بدون معادل های معین {#terms-without-established-translations}
-
-ممکن است برخی از اصطلاحات به زبان های دیگر ترجمه نشده باشند و به طور گسترده با اصطلاح اصلی انگلیسی شناخته می شوند. چنین اصطلاحاتی عمدتاً شامل مفاهیم جدیدتری مانند اثبات کار، اثبات سهام، بیکن چین، سهامگذاری و غیره هستند.
-
-در حالی که ترجمه این اصطلاحات می تواند غیرطبیعی به نظر برسد، از آنجایی که نسخه انگلیسی معمولاً در زبان های دیگر نیز استفاده می شود، توصیه می شود که آنها ترجمه شوند.
-
-هنگام ترجمه آنها، خلاقیت به خرج دهید، از ترجمه های تشریحی استفاده کنید یا به سادگی آنها را به معنای واقعی کلمه ترجمه کنید.
-
-**دلیل اینکه بیشتر اصطلاحات باید به جای ترک برخی به انگلیسی ترجمه شوند، این واقعیت است که این اصطلاحات جدید در آینده گستردهتر خواهند شد، زیرا افراد بیشتری استفاده از اتریوم و فناوری های مرتبط را شروع می کنند. اگر میخواهیم افراد بیشتری را از سراسر جهان به این فضا بفرستیم، باید اصطلاحات قابل فهمی را به هرچه بیشتر زبانهای ممکن ارائه کنیم، حتی اگر نیاز داشته باشیم خودمان آن را ایجاد کنیم.**
-
-## دکمهها و & CTAها {#buttons-and-ctas}
-
-وب سایت حاوی دکمه های متعددی است که باید متفاوت از سایر مطالب ترجمه شوند.
-
-متن دکمه را می توان با مشاهده اسکرین شات های زمینه، که با بیشتر رشته ها متصل است، یا با بررسی زمینه در ویرایشگر، که شامل عبارت "دکمه" است، شناسایی کرد.
-
-ترجمههای دکمهها باید تا حد امکان کوتاه باشند تا از عدم تطابق قالببندی جلوگیری شود. علاوه بر این، ترجمه دکمه باید ضروری باشد، یعنی یک دستور یا درخواست ارائه کنید.
-
-![چگونه یک button.png را پیدا کنیم](./how-to-find-a-button.png)
-
-## ترجمه برای عموم مردم جهان {#translating-for-inclusivity}
-
-بازدیدکنندگان Ethereum.org از سرتاسر جهان و از زمینه های علمی مختلف می آیند. بنابراین، زبان وبسایت باید خنثی و پذیرای همه باشد و نه انحصاری.
-
-یکی از جنبه های مهم این موضوع بی طرفی جنسیتی است. این را می توان با استفاده از فرم رسمی خطاب و پرهیز از هرگونه کلمه جنسیت خاص در ترجمه ها به راحتی به دست آورد.
-
-شکل دیگری از فراگیری، تلاش برای ترجمه برای مخاطبان جهانی است، نه خاص کشور، نژاد یا منطقه.
-
-در نهایت، زبان باید برای همه مخاطبان و سنین مناسب باشد.
-
-## ترجمههای خاص زبان {#language-specific-translations}
-
-هنگام ترجمه، مهم است که قوانین گرامری، قراردادها و قالببندی استفاده شده در زبان خود را به جای کپی کردن از منبع رعایت کنید. متن مبدأ از قوانین و قراردادهای دستور زبان انگلیسی پیروی می کند که برای بسیاری از زبان های دیگر قابل اجرا نیست.
-
-شما باید از قوانین زبان خود آگاه باشید و بر این اساس ترجمه کنید. اگر به کمک نیاز دارید، با ما تماس بگیرید و ما به شما کمک می کنیم تا منابعی در مورد نحوه استفاده از این عناصر در زبان خود پیدا کنید.
-
-چند نمونه از مواردی که باید به طور خاص به آن توجه داشت:
-
-### نشانه گذاری، قالب بندی {#punctuation-and-formatting}
-
-**حروف بزرگ**
-
-- تفاوت های زیادی در حروف بزرگ در زبان های مختلف وجود دارد.
-- در زبان انگلیسی رایج است که همه کلمات را در عناوین و نام ها، ماه ها و روزها، نام زبان ها، تعطیلات و غیره با حروف بزرگ بنویسند. در بسیاری از زبان های دیگر، این از نظر گرامری نادرست است، زیرا آنها قوانین حروف بزرگ متفاوتی دارند.
-- برخی از زبان ها نیز قوانینی در مورد بزرگ کردن ضمایر شخصی، اسم ها و صفت های خاص دارند که در انگلیسی حروف بزرگ نیستند.
-
-**فاصله گذاری**
-
-- قوانین املایی، استفاده از فاصله ها را برای هر زبان تعریف می کنند. از آنجایی که فاصله ها در همه جا استفاده می شوند، این قوانین جزو برخی از متمایزترینها هستند، و فاصلهها از برخی از عناصری هستند که اشتباه ترجمه شده اند.
-- برخی از تفاوت های رایج در فاصله بین انگلیسی و سایر زبان ها:
- - فاصله قبل از واحدهای اندازه گیری و ارزها (به عنوان مثال USD، EUR، KB، MB)
- - فاصله قبل از علائم درجه (به عنوان مثال °C و ℉)
- - فاصله قبل از برخی از علائم نگارشی، به ویژه بیضی (…)
- - فاصله قبل و بعد از اسلش (/)
-
-**لیستها**
-
-- هر زبانی مجموعه ای متنوع و پیچیده از قوانین برای نوشتن لیست ها دارد. اینها می توانند تفاوت قابل توجهی با انگلیسی داشته باشند.
-- در برخی از زبان ها، اولین کلمه هر خط جدید باید با حروف بزرگ باشد، در حالی که در برخی دیگر، خطوط جدید باید با حروف کوچک شروع شوند. بسیاری از زبان ها نیز بسته به طول هر خط، قوانین متفاوتی در مورد حروف بزرگ در لیست ها دارند.
-- همین امر در مورد علامت گذاری آیتم های خطی نیز صدق می کند. نقطه نگاری پایانی در لیست ها بسته به زبان می تواند نقطه (**.**)، کاما (**،**) یا نقطه ویرگول (**;**) باشد.
-
-**علامت نقل قول**
-
-- زبان ها از علامت های نقل قول مختلف استفاده می کنند. کپی کردن ساده نقل قول انگلیسی از منبع اغلب نادرست است.
-- برخی از رایج ترین انواع علامت نقل قول عبارتند از:
- - „example text“
- - ‚example text’
- - »example text«
- - “example text”
- - ‘example text’
- - «example text»
-
-**خط فاصله و خط تیره**
-
-- در زبان انگلیسی، خط فاصله (-) برای پیوستن کلمات یا قسمت های مختلف یک کلمه استفاده می شود، در حالی که خط تیره (–) برای نشان دادن محدوده یا مکث استفاده می شود.
-- بسیاری از زبان ها قوانین مختلفی برای استفاده از خط فاصله و خط تیره دارند که باید رعایت شود.
-
-### قالبها {#formats}
-
-**اعداد**
-
-- تفاوت اصلی در نوشتن اعداد در زبان های مختلف جداکننده ای است که برای اعشار و هزاران استفاده می شود. برای هزارگان، این می تواند نقطه، کاما یا فاصله باشد. به طور مشابه، برخی از زبان ها از نقطه اعشار استفاده می کنند، در حالی که برخی دیگر از کاما اعشاری استفاده می کنند.
- - چند نمونه از اعداد بزرگ:
- - انگلیسی – **1,000.50**
- - اسپانیایی – **1.000,50**
- - فرانسه – **1 000,50**
-- یکی دیگر از نکات مهم در هنگام ترجمه اعداد، علامت درصد است. می توان آن را به روش های مختلفی نوشت: **100%**، **100 %** یا **%100**.
-- در نهایت، اعداد منفی را می توان بسته به زبان به صورت متفاوتی نمایش داد: -100، 100-، (100) یا [100].
-
-**تاریخ**
-
-- هنگام ترجمه تاریخ، یکسری ملاحظات و تفاوت ها بر اساس زبان وجود دارد. اینها شامل قالب تاریخ، جداکننده، حروف بزرگ و صفرهای ابتدایی است. همچنین بین تاریخ های کامل و عددی تفاوت هایی وجود دارد.
- - چند نمونه از فرمت های مختلف تاریخ:
- - انگلیسی بریتانیا (dd/mm/yyyy) – 1st January, 2022
- - انگلیسی امریکا (mm/dd/yyyy) – January 1st, 2022
- - چینی (yyyy-mm-dd) – 2022 年 1 月 1 日
- - فرانسه (dd/mm/yyyy) – 1er janvier 2022
- - ایتالیایی (dd/mm/yyyy) – 1º gennaio 2022
- - آلمانی (dd/mm/yyyy) – 1. Januar 2022
-
-**ارزها**
-
-- به دلیل فرمت ها، قراردادها و تبدیل های مختلف، ترجمه ارزها می تواند چالش برانگیز باشد. به عنوان یک قاعده کلی، لطفاً ارزها را همان منبع نگه دارید. میتوانید ارز محلی و تبدیل خود را در پرانتز اضافه کنید تا خواننده به نفع خود باشد.
-- تفاوت های اصلی در نوشتن ارزها در زبان های مختلف شامل قرار دادن نمادها، کاماهای اعشاری در مقابل اعشار، فاصله و اختصارات در مقابل نمادها است.
- - محل قرارگیری سمبلها: 100$ یا $100
- - ویرگول به عنوان اعشار یا نقطه به عنوان اعشار: مثلاً 100,50$ یا 100.50$
- - فاصله گذاری: مثلاً 100$ یا 100 $
- - مخفف یا سمبل: مثلاً 100 $ یا 100 USD
-
-**واحدهای اندازهگیری**
-
-- به عنوان یک قاعده کلی، لطفاً واحدهای اندازه گیری را مطابق منبع نگه دارید. اگر کشور شما از سیستم دیگری استفاده می کند، می توانید تبدیل آن را در پرانتز قرار دهید.
-- جدای از بومی سازی واحدهای اندازه گیری، توجه به تفاوت در نحوه رویکرد زبان ها به این واحدها نیز مهم است. تفاوت اصلی فاصله بین عدد و واحد است که بر اساس زبان می تواند متفاوت باشد. نمونه هایی از این شامل 100kB در مقابل 100 kB یا 50ºF در مقابل 50 ºF هستند.
-
-## نتيجه گيری {#conclusion}
-
-ترجمه ethereum.org فرصتی عالی برای آشنایی با جنبه های مختلف اتریوم است.
-
-هنگام ترجمه سعی کنید عجله نکنید. راحت باشید و لذت ببرید!
-
-از اینکه با برنامه ترجمه مشارکت داشتید و به ما کمک میکنید تا وبسایت را برای مخاطبان بیشتری در دسترس قرار دهید، سپاسگزاریم. جامعه اتریوم یک جامعه جهانی است و ما خوشحالیم که شما بخشی از آن هستید!
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md
deleted file mode 100644
index d99215d3d21..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-desci-projects/index.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: افزودن پروژه های DeSci
-description: سیاستی که هنگام افزودن لینک به پروژهها در صفحه DeSci در ethereum.org استفاده میکنیم
-lang: fa
----
-
-# افزودن پروژه ها {#adding-projects}
-
-ما میخواهیم مطمئن شویم که پروژههای متنوعی را نشان میدهیم و تصویر خوبی از چشمانداز DeSci ارائه میدهیم.
-
-هر کس آزاد است پروژه ای را برای فهرست کردن در صفحه DeSci در ethereum.org پیشنهاد کند. به همین ترتیب، هر کس که متوجه پروژهای شود که دیگر مرتبط نیست یا دیگر معیارهای واجد شرایط بودن ما را برآورده نمیکند، میتواند حذف آن را پیشنهاد دهد.
-
-## چارچوب تصمیمات {#the-decision-framework}
-
-### معیارهای گنجانده شدن: موارد ضروری {#the-must-haves}
-
-- **کد/داده منبع باز** - باز بودن کد و داده، یک اصل اصلی DeSci است، بنابراین پروژه های DeSci نباید منبع بسته باشند. پایگاه کد باید در دسترس باشد و به طور ایده آل برای PRها باز باشد.
-- **پروژههای DeSci باید غیرمتمرکز باشند** - این میتواند شامل اداره شدن توسط یک DAO یا ساختن با پشته فناوری غیرمتمرکز از جمله کیفپولهای غیرمتمرکز باشد. احتمالاً شامل قراردادهای هوشمند قابل بازرسی در اتریوم است.
-- **اطلاعات لیستینگ صادقانه و دقیق** - انتظار می رود هر فهرست پیشنهادی از پروژه ها با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات خود را تحریف کنند، مانند منبع باز اعلان کردن کد پروژه در حالی که برخلاف واقعیت باشد، حذف خواهند شد.
-- **تعهد آشکار به گسترش دسترسی به علم** - یک پروژه DeSci باید بتواند نحوه مشارکت در علم را برای عموم مردم، نه فقط برای دارندگان توکن/NFT، بیان کند.
-- **دسترسیپذیری جهانی** - پروژه شما دارای محدودیتهای جغرافیایی یا الزامات KYC نباشد که افراد خاصی را از دسترسی به خدمات شما محروم میکند.
-- **وبسایت و مستندات اطلاعاتی** - مهم است که بازدیدکنندگان وبسایت پروژه بتوانند بفهمند که پروژه واقعاً چه میکند، چگونه به تمرکززدایی زیرساختهای علمی کمک میکند و افراد چگونه مشارکت میکنند.
-- **پروژه باید بخشی از اکوسیستم اتریوم باشد** - در ethereum.org ما معتقدیم که اتریوم (و لایههای 2 آن) لایه پایه مناسب برای جنبش DeSci است.
-- **پروژه نسبتاً به خوبی تثبیت شده است** - این پروژه دارای کاربران واقعی است که چندین ماه می توانند به خدمات پروژه دسترسی داشته باشند.
-
-### امتیازات ممکن
-
-- **در چندین زبان موجود است** - پروژه شما به چندین زبان ترجمه شده و به کاربران در سراسر جهان امکان دسترسی به آن را می دهد.
-- **منابع آموزشی** - محصول شما باید برای کمک به کاربران و آموزش آنها، یک تجربه نصب خوب طراحی شده داشته باشد. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
-- **ممیزی های طرف ثالث** - محصول شما به صورت حرفه ای از نظر آسیب پذیری توسط طرف ثالث مورد اعتماد بازرسی شده است.
-- **نقطه تماس** - یک نقطه تماس برای پروژه (این ممکن است توسط نماینده ای از یک DAO یا انجمن باشد) به ما کمک زیادی می کند تا هنگام ایجاد تغییرات اطلاعات دقیق را دریافت کنیم. این امر، بروزرسانی ethereum.org را در هنگام جمعآوری اطلاعات آینده قابل مدیریت نگه می دارد.
-
-## نگهداری {#maintenance}
-
-از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
-
-- اطمینان حاصل کنید که همه پروژه های لیست شده هنوز معیارهای ما را برآورده می کنند
-- بررسی کنید هیچ محصولی پیشنهاد نشده است که معیارهای ما را بیشتر از مواردی که در حال حاضر لیست شده است برآورده می کند
-
-Ethereum.org توسط جامعه منبع باز نگهداری می شود و ما به جامعه برای کمک به بهروز نگه داشتن این موضوع متکی هستیم. اگر متوجه هر گونه اطلاعات در مورد پروژه های لیست شده شدید که نیاز به بهروزرسانی دارند، لطفاً یک مسئله یا درخواست ادغام را در مخزن گیتهاب ما باز کنید.
-
-## شرایط استفاده {#terms-of-use}
-
-لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md
deleted file mode 100644
index 2201c53b86c..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-developer-tools/index.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: افزودن ابزار های توسعهدهنده
-lang: fa
-description: معیارهای ما برای فهرست کردن ابزارهای توسعه دهنده در ethereum.org
----
-
-# در حال افزودن ابزار های توسعهدهنده {#contributing-to-ethereumorg-}
-
-ما میخواهیم مطمئن شویم که بهترین منابع توسعهدهنده ممکن را فهرست کردهایم تا افراد بتوانند با اعتماد به نفس ایجاد کنند و پشتیبانی مورد نیاز خود را داشته باشند.
-
-اگر ابزار توسعهدهنده مفیدی وجود دارد که ما آن را فراموش کرده ایم، آن را در جایی مناسب پیشنهاد کنید.
-
-ما در حال حاضر ابزارهای توسعه دهنده را در سرتاسر [پورتال توسعه دهنده](/developers/) خود فهرست میکنیم.
-
-**به راحتی می توانید موارد اضافه شده جدید را به صفحات مناسب پیشنهاد دهید.**
-
-## چگونه تصمیم می گیریم {#ways-to-contribute}
-
-ارسالیهای ابزار توسعه دهنده با معیارهای زیر ارزیابی می شوند:
-
-**آیا به طور عمده با ابزارهایی که قبلاً فهرست شده است متمایز است؟**
-
-- دسته ها یا انواع ابزارهای جدید
-- ویژگی های جدید در مقایسه با ابزارهای مشابه موجود
-- هدف گذاری شده در یک مورد خاص که توسط ابزارهای مشابه موجود پوشش داده نشده است
-
-**آیا ابزار به خوبی مستند شده است؟**
-
-- آیا مستندات وجود دارد؟
-- آیا استفاده از ابزار کافی است؟
-- آیا به تازگی به روز شده است؟
-
-**آیا ابزار به طور گسترده استفاده می شود؟**
-
-- ما معیارهایی مانند ستاره های GitHub، آمار دانلود، و اینکه آیا توسط شرکت ها یا پروژه های شناخته شده استفاده می شود را در نظر خواهیم گرفت
-
-**آیا ابزار از کیفیت کافی برخوردار است؟**
-
-- آیا اشکالات مکرر وجود دارد؟
-- آیا ابزار قابل اعتماد است؟
-- آیا ابزار به طور فعال نگهداری می شود؟
-
-**آیا ابزار منبع باز است؟**
-
-بسیاری از پروژه ها در فضای اتریوم منبع باز هستند. به احتمال زیاد ما پروژه های منبع باز را فهرست می کنیم که به توسعه دهندگان جامعه اجازه می دهند کد را بررسی کرده و در آن مشارکت کنند.
-
----
-
-## سفارش محصول {#product-ordering}
-
-محصولات از قدیمی ترین تا جدیدترین محصول اضافه شده به صفحه نمایش داده می شوند، مگر اینکه محصولات به طور خاص مرتب شده باشند، مثلا بر اساس حروف الفبا. به عبارت دیگر، جدیدترین محصولات به انتهای لیست اضافه می شوند.
-
----
-
-## ابزار توسعه دهنده خود را اضافه کنید {#how-decisions-about-the-site-are-made}
-
-اگر میخواهید یک ابزار توسعهدهنده را به ethereum.org اضافه کنید و معیارها را برآورده میکند، مسئلهای در GitHub ایجاد کنید.
-
-
- افزودن مسئله
-
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md
deleted file mode 100644
index 0bfad40bb95..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-exchanges/index.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: افزودن صرافی
-description: ضوابطی که ما به هنگام اضافه کردن صرافیها به وبسایت ethereum.org استفاده می کنیم
-lang: fa
----
-
-# افزودن صرافیهای شبکه اتریوم {#adding-ethereum-exchanges}
-
-هر کس آزاد است اضافه شدن صرافیهای جدید به وبسایت ethereum.org را پیشنهاد دهد.
-
-در حال حاضر ما آنها را در اینجا فهرست کردهایم:
-
-- [ethereum.org/get-eth](/get-eth/)
-
-این صفحه به کاربر اجازه میدهد محل زندگی خود را به عنوان ورودی ارائه دهد و مشاهده کند که از چه صرافیهایی میتواند استفاده نماید. این کمک میکند تا هرگونه محدودیت جغرافیایی هرچه زودتر آشکار شود.
-
-بنابر همین موضوع، زمانی که شما یک صرافی را پیشنهاد میکنید ما به اطلاعات خاصی نیاز داریم.
-
-**نکته:** اگر میخواهید که یک صرافی غیرمتمرکز را فهرست کنید، نگاهی به [ضوابط ما برای فهرست نمودن کیف پولها و برنامههای غیرمتمرکز](/contributing/adding-products/) بیاندازید.
-
-## آنچه ما نیاز داریم {#what-we-need}
-
-- محدودیتهای جغرافیایی که بر صرافی اعمال میشوند. محدودیتهای جغرافیایی مرتبط با صرافی باید در صفحه یا بخش اختصاصی وبسایت صرافی به تفصیل بیان شوند.
-- ارزهایی که کاربران میتوانند استفاده کنند تا ETH بخرند
-- مدرک اثبات این که صرافی یک شرکت تجاری قانونی میباشد
-- هرگونه اطلاعات اضافی که ممکن است داشته باشید - این اطلاعات میتواند اطلاعاتی درباره شرکت مانند سالهای فعالیت، پشتوانه مالی و غیره باشد.
-
-ما به این اطلاعات نیازمندیم تا بتوانیم به صورت دقیق [به کاربران کمک کنیم تا صرافی را که میتوانند استفاده نمایند پیدا کنند](/get-eth/#country-picker).
-
-و همچنین ethereum.org میتواند اطمینان بیشتری داشته باشد که صرافی قانونی است و خدمات امن ارائه میدهد.
-
----
-
-## صرافی خود را اضافه کنید {#add-exchange}
-
-اگر میخواهید یک صرافی را به ethereum.org اضافه نمائید، یک مسئله در وبسایت گیتهاب ایجاد کنید.
-
-
- یک مسئله ایجاد کنید
-
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md
deleted file mode 100644
index c908ba2b000..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-glossary-terms/index.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: افزودن عبارات واژه نامه
-lang: fa
-description: ضوابط ما برای اضافه کردن یک عبارت به واژه نامه اتریوم
----
-
-# افزودن عبارات واژه نامه {#contributing-to-ethereumorg-}
-
-فضای اتریوم روز به روز در حال تغییر است. اصطلاحات جدید دائماً وارد فرهنگ لغات کاربران اتریوم می شوند و ما به کمک شما برای گردآوری یک مرجع دقیق و به روز برای همه عبارات مربوط اتریوم نیاز داریم. نگاهی به [واژه نامه](/glossary/) کنونی ما بیاندازید سپس اگر میخواهید در بهبود آن کمک کنید متن پایین را مطالعه کنید!
-
-## معیارها {#criteria}
-
-اصطلاحات جدید واژه نامه بر اساس معیار های زیر بررسی میشوند:
-
-- آیا این اصطلاح/تعریف به روز است و منسوخ نشده است؟
-- آیا در حال حاضر عبارت مشابه آن در فرهنگ لغات وجود دارد؟ (اگر بله، فواید اضافه کردن اصطلاح جدید در مقابل بروزرسانی اصطلاحات موجود در واژه نامه را مقایسه کنید)
-- آیا عبارت/تعریف جدید عاری از تبلیغات محصول یا سایر محتوای تبلیغاتی است؟
-- آیا این اصطلاح/تعریف مستقیما به اتریوم مربوط میشود؟
-- آیا عبارت جدید تعریفی عینی، دقیق و عاری از قضاوت یا نظر شخصی دارد؟
-- آیا منبع قابل اعتماد است؟ آیا آنها منابع خود را اعلام کرده اند؟
-
----
-
-## عبارت خود را اضافه کنید {#how-decisions-about-the-site-are-made}
-
-اگر میخواهید عبارتی به واژه نامه ethereum.org اضافه کنید که شرایط بالا را دارد، [درخواستی در گیتهاب ثبت کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml).
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md
deleted file mode 100644
index 6dd2e94af0d..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-layer-2s/index.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: افزودن لایه 2ها
-description: ضوابط ما برای اضافه کردن یک لایه 2 به ethereum.org
-lang: fa
----
-
-# افزودن لایه 2ها {#adding-layer-2}
-
-ما میخواهیم مطمئن شویم که بهترین منابع ممکن را فهرست کرده باشیم تا کاربران بتوانند با خیالی آسوده از فضای لایه 2ها استفاده کنند.
-
-هر کس آزاد است اضافه شدن یک لایه 2 جدید را به ethereum.org پیشنهاد دهد. اگر یک لایه 2 وجود دارد که ما آن را از قلم انداختهایم، **[لطفاً آن را پیشنهاد کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!**
-
-در حال حاضر ما لایه 2ها را در صفحات زیر فهرست میکنیم:
-
-- [اندوخته های خوشبینانه](/developers/docs/scaling/optimistic-rollups/)
-- [رولآپهای دانش-صفر](/developers/docs/scaling/zk-rollups/)
-- [لایه 2](/layer-2/)
-
-لایه 2 یک مفهوم و الگوی نسبتاً جدید و هیجان انگیز برای اتریوم است. ما تلاش کردیم که یک چارچوب منصفانه برای بررسی و فهرست در ethereum.org ایجاد کنیم، اما معیارهای فهرست بندی در طول زمان تغییر می کنند و تکامل می یابند.
-
-## چارچوب تصمیمات {#decision-framework}
-
-### معیارهای گنجانده شدن: موارد ضروری {#criteria-for-inclusion-the-must-haves}
-
-**فهرست شدن در L2BEAT**
-
-- به منظور این که پروژه جهت فهرست شدن در نظر گرفته شود، باید قبلاً در [L2BEAT](https://l2beat.com) فهرست شده باشد. L2BEAT یک سنجش ریسک برجسته از پروژههای لایه 2 انجام میدهد که ما برای ارزیابی پروژه های لایه 2 به آن متکی هستیم. **اگر پروژهای در L2BEAT نشان داده نشده باشد، ما آن را به عنوان لایه 2 در ethereum.org فهرست نخواهیم کرد.**
-- [ببینید چگونه میتوانید پروژه لایه 2 خود را به L2BEAT اضافه کنید](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md).
-
-**کد منبع باز**
-
-- کد شما باید قابل دسترسی باشد و شما باید در گیتهاب، PRهایی از جامعه گستردهتر را قبول کنید.
-
-**دسته بندی لایه 2**
-
-ما در حال حاضر دسته های زیر را به عنوان راه حل لایه 2 در نظر میگیریم:
-
-- رول آپ خوش بینانه
-- رول آپ دانش صفر
-
-_ما راه حلهای مقیاس پذیر دیگری را که از اتریم به عنوان لایه امنیت یا لایه دسترسی به اطلاعات استفاده نمیکنند، لایه 2 در نظر نمیگیریم._
-
-**اتریوم برای دسترسی به اطلاعات**
-
-- در دسترس بودن اطلاعات یک معیار متمایز کننده میان لایه 2 و سایر راه حلهای مقیاس پذیری است. یک پروژه **باید** از شبکه اصلی اتریوم برای دسترسی به اطلاعات استفاده نماید تا برای فهرست شدن در نظر گرفته شود.
-
-**پل ها**
-
-- کاربران چگونه میتوانند به فضای این لایه 2 وارد شوند؟
-
-**تاریخی که پروژه عرضه و منتشر شد**
-
-- لایه 2 حداقل باید به مدت 6 ماه در شبکه اصلی اتریوم "زنده" بوده باشد
-
-- پروژههای جدیدی که هنوز توسط کاربران آزمایش نشدهاند، شانس کمتری برای فهرست شدن دارند.
-
-**حسابرسی امنیتی**
-
-- چه از طریق حسابرسی امنیتی برون سازمانی، تیم داخلی امنیت یا هر روش دیگری، امنیت محصول شما باید به شکل قابل اطمینان مورد آزمایش قرار گرفته باشد. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
-
-**پایگاه فعال کاربران**
-
-- ما معیارهایی همچون تاریخچه موجودی کل قفل شده یا TVL، آمار تراکنشها و اینکه آیا توسط شرکتها یا پروژههای شناخته شده استفاده میشود یا نه را در نظر میگیریم
-
-**تیم توسعه فعال**
-
-- ما یک لایه 2 را که یک تیم فعال ندارد که روی پروژه کار کند، لیست نخواهیم کرد.
-
-**جستجوگر بلوک**
-
-- پروژه های لیست شده نیازمند یک جستجوگر بلاک فعال هستند تا به کاربران اجازه دهند به راحتی در شبکه کاوش نمایند.
-
-### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#nice-to-haves}
-
-**پشتیبانی پروژه با صرافیها**
-
-- آیا کابران قادر به واریز و/یا برداشت مستقیم به/از یک صرافی هستند؟
-
-**لینک به اکوسیستم برنامه های غیرمتمرکز موجود در لایه 2**
-
-- ما علاقهمندیم بتوانیم اطلاعاتی را در مورد کارهایی که کاربران میتوانند انتظار داشته باشند در این لایه 2 انجام دهند، ارائه دهیم. (برای مثال https://portal.arbitrum.io/, https://www.optimism.io/apps)
-
-**فهرست قراردادهای توکن**
-
-- از آنجا که داراییها در لایه 2 آدرس جدیدی خواهند داشت، اگر منبعی از لیست توکنها وجود دارد، لطفاً آن را به اشتراک بگذارید.
-
-**پشتیبانی از کیف پول بومی**
-
-- آیا کیف پولها بهصورت بومی از لایه 2 پشتیبانی میکنند؟
-
-## لایه 2 خود را اضافه کنید {#add-exchange}
-
-اگر میخواهید یک لایه 2 را به ethereum.org اضافه نمائید، یک مسئله در وبسایت گیتهاب ایجاد کنید.
-
-
- یک مسئله ایجاد کنید
-
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md
deleted file mode 100644
index a7c0a46e2c9..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-products/index.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: افزودن محصولات
-description: سیاست و ضوابطی که ما به هنگام اضافه کردن محصولات به ethereum.org استفاده می کنیم
-lang: fa
----
-
-# افزودن محصولات اتریوم {#adding-products}
-
-هر کسی آزاد است تا برنامه های غیرمتمرکز جدید را پیشنهاد دهد تا به محتوای ethereum.org، در محلی که مناسب آن است، اضافه شود. **خیر، ما برنامه غیرمتمرکز شما را به صفحه اصلی خود اضافه نخواهیم کرد** 😜
-
-لیست فعلی برنامه های غیرمتمرکز:
-
-- ethereum.org/dapps
-- ethereum.org/get-eth
-
-**لطفا فقط پیشنهادهای جدید را به این صفحه اضافه کنید.**
-
-اگرچه از افزودن پیشنهادهای جدید استقبال میکنیم، اما برنامههای غیرمتمرکز فعلی را بر اساس تجربهای که میخواهیم برای کاربرانمان ایجاد کنیم، انتخاب کردهایم. این معیارها بر اساس برخی از اصول طراحی ما میباشد:
-
-- _الهام بخش_: هر چیزی در ethereum.org، باید چیز جدیدی را به کاربران ارائه دهد
-- _یک داستان خوب_: آنچه فهرست شده باید یک لحظه "آهاااا فهمیدم" را برای کاربر ایجاد کند
-- _معتبر_: همه چیز باید کسب و کار/پروژه قانونی باشد تا خطر برای کاربران به حداقل برسد
-
-در کل، **ethereum.org میخواهد یک "تجربه ورود و استفاده آسان" را برای کاربران جدید فراهم نماید**. به همین دلیل، ما برنامه های غیرمتمرکز را بر اساس ویژگیهای زیر اضافه میکنیم:
-
-- سهولت در استفاده
-- سازگاری متقابل با سایر محصولات
-- امنیت
-- ماندگاری
-
-این هم از جزئیات بیشتر درباره چارچوب تصمیم گیری ما. برای ارائه بازخورد یا پیشنهاد تغییرات، درنگ نکنید.
-
-## چارچوب تصمیمات {#decision-framework}
-
-### معیارهای گنجانده شدن: موارد ضروری {#criteria-for-inclusion-the-must-haves}
-
-- **محصول از منظر امنیتی آزمایش شده باشد** - چه از طریق حسابرسی امنیتی خارجی، از طریق یک تیم امنیت داخلی یا هر روش دیگر، امنیت محصول شما باید به طور قابل اتکا، آزمایش شود. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
-- **محصولی که بیش از 6 ماه "عرضه و منتشر" شده باشد** - این مهر تائید دیگری بر امنیت محصول میباشد. 6 ماه بازه زمانی مناسبی برای یافتن نواقص امنیتی و راههای هک کردن، میباشد.
-- **یک تیم فعال بر روی آن کار میکنند** - این مورد کیفیت محصول را تضمین میکند و به کاربر اطمینان خاطر میدهد که برای سؤالات و مشکلاتش پشتیبانی دریافت خواهد کرد.
-- **اطلاعات فهرست شده صادقانه و دقیق** - انتظار میرود هر گونه پیشنهاد پروژه ها، با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات ارسالی برای فهرست شدن را جعل می کنند، مانند اعلام "منبع باز" بودن محصول، در حالی که اینگونه نباشد، حذف خواهند شد.
-
-### معیارهای رتبه بندی: داشتن آنها خوب است {#criteria-for-ranking-the-nice-to-haves}
-
-به دلیل معیارهای زیر ممکن است برنامه غیرمتمرکز شما به اندازه سایرین در ethereum.org، به صورت برجسته نمایش داده نشود.
-
-**برنامه های غیرمتمرکز**
-
-- **بتوانید از طریق اکثر کیف پول های فهرست شده به آن دسترسی داشته باشید** - برنامههای غیرمتمرکز، باید با اکثر کیف پول هایی که در ethereum.org فهرست شده اند کار کنند.
-- **کاربران بتوانند خودشان آن را امتحان کنند -** یک کاربر باید بتواند از نرمافزار غیرمتمرکز شما استفاده کند و به نتیجهای ملموس دست یابد.
-- **سهولت در جذب کاربر** - محصول شما باید دارای یک تجربه ساده ورود و استفاده باشد و کاربران بتوانند کمک دریافت کنند و آموزش ببینند. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
-- **غیرسرپرستی** - کاربران خودشان وجوه خود را کنترل کنند. اگر پروژه و محصول شما زمانی ناپدید شود، کاربران همچنان بتوانند به وجوه خود دسترسی داشته باشند و آن را جابجا کنند.
-- **قابل دسترسی جهانی** - محصول شما دارای محدودیتهای جغرافیایی یا الزامات KYC نباشد که افراد خاصی را از دسترسی به خدمات شما محروم کند.
-- **کد منبع باز** - کد شما باید در دسترس باشد و باید PRها را از جامعه گستردهای بپذیرید.
-- **جامعه پروژه** - شما باید یک جامعه اختصاصی داشته باشید، میتواند در برنامه Discord باشد که در آن کاربران میتوانند با تیم شما برای دریافت کمک یا پیشنهاد ویژگیهای جدید تعامل داشته باشند.
-
-## معیارهای در حال اجرا {#criteria-in-practice}
-
-هرچه تعداد بیشتری از معیارها را پر کنید، احتمال بیشتری وجود دارد که محصول شما به ethereum.org راه پیدا کند.
-
-اگر یک محصول جدید پیشنهاد شود که معیارهای ضروری و برخی از غیر ضروریها را داشته باشد، محصول فهرست شدهای که فقط معیارهای ضروری را داشته باشد ممکن است حذف شود.
-
-موارد دیگری که در این تصمیم موثر هستند:
-
-- آیا اضافه کردن محصول به فهرست به جای جایگزینی آن با محصولی دیگر، باعث به هم ریختن صفحه می شود؟
- - سایت ما در درجه اول آموزشی است و هدف اصلی آن توضیح اتریوم و مفاهیم مربوط به آن است. با افزودن گزینه های بسیار زیاد برای کاربران، ممکن است صفحات کمتر قابل خواندن و در نتیجه کمتر مفید باشند.
-- آیا صفحه کنونی، کاربر را با انتخابهای متعدد فلج می کند؟
- - درست مثل زمانی که ساعتها در حال مرور Netflix مینشینید زیرا نمیتوانید در مورد چیزی برای تماشا تصمیم بگیرید. بمباران کردن کاربران جدید با انتخابهای بیش از حد، یک ریسک است.
-
-این یک تصمیم در طراحی است که ethereum.org مسئول آن است.
-
-اما مطمئن باشید، **لینکهایی به وبسایتهای دیگر وجود خواهد داشت که برنامههای غیرمتمرکز بیشتری را رتبهبندی میکنند**
-
-### سفارش محصول {#product-ordering}
-
-محصولات از جدیدترین تا قدیمیترین زمان اضافه شدن نمایش داده می شوند، مگر اینکه ترتیب محصولات به طور خاصی باشد، برای مثال بر اساس حروف الفبا. به عبارت دیگر، جدیدترین محصولات به انتهای لیست اضافه می شوند.
-
-### شرایط استفاده {#terms-of-use}
-
-لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
-
-## نگهداری {#maintenance}
-
-از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
-
-- اطمینان حاصل کنیم که همه برنامههای لیست شده هنوز معیارهای ما را برآورده می کنند
-- اطمینان حاصل کنیم هیچ محصولی پیشنهاد نشده باشد که معیارهای بیشتری از محصولات فهرست شده فعلی را رعایت کند و آن را اضافه نکرده باشیم
-
-شما می توانید با بررسی و اطلاع رسانی در این مورد کمک کنید. [یک مسئله در گیتهاب ایجاد کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) یا یک ایمیل به [website@ethereum.org](mailto:website@ethereum.org) ارسال کنید
-
-_ما همچنین در حال بررسی گزینههای رأیگیری هستیم تا جامعه اتریوم بتواند اولویتهای خود را نشان دهد و بهترین محصولات موجود را برای توصیه ما برجسته کند._
-
----
-
-## محصول خود را اضافه کنید {#add-your-product}
-
-اگر می خواهید یک برنامه غیرمتمرکز به ethereum.org اضافه کنید که معیارها را رعایت می کند، در وبسایت GitHub یک مسئله ایجاد کنید.
-
-
- یک مسئله ایجاد کنید
-
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md
deleted file mode 100644
index 79eb75fd7fd..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-staking-products/index.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-title: افزودن محصولات یا خدمات سهامگذاری
-description: سیاستی که هنگام افزودن محصولات یا سرویسهای سهامگذاری به ethereum.org استفاده میکنیم
-lang: fa
----
-
-# افزودن محصولات یا خدمات سهامگذاری {#adding-staking-products-or-services}
-
-ما می خواهیم مطمئن شویم که بهترین منابع ممکن را فهرست می کنیم و در عین حال کاربران را ایمن و مطمئن نگه می داریم.
-
-هر کس میتواند آزادانه پیشنهاد اضافه کردن محصولات یا خدمات سهامگذاری را در ethereum.org بدهد. اگر موردی وجود دارد که از قلم افتاده است، **[لطفاً آن را پیشنهاد دهید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!**
-
-ما در حال حاضر محصولات و خدمات سهامگذاری را در صفحات زیر فهرست می کنیم:
-
-- [سهام گذاری انفرادی](/staking/solo/)
-- [سهامگذاری بهعنوان یک خدمت](/staking/saas/)
-- [استخرهای سهامگذاری](/staking/pools/)
-
-اثبات سهام از 1 دسامبر 2020 در بیکن چین فعال است. در حالی که سهامگذاری هنوز نسبتاً جدید است، ما سعی کرده ایم یک چارچوب منصفانه و شفاف برای بررسی در ethereum.org ایجاد کنیم، اما معیارهای فهرست کردن در طول زمان تغییر می کند و تکامل می یابد و در نهایت به صلاحدید تیم وب سایت ethereum.org است.
-
-## چارچوب تصمیمات {#the-decision-framework}
-
-تصمیم برای فهرست کردن یک محصول در ethereum.org به هیچ عاملی بستگی ندارد. هنگام تصمیم گیری برای فهرست کردن یک محصول یا خدمات، چندین معیار با هم در نظر گرفته می شوند. هر چه تعداد این معیارها بیشتر باشد، احتمال فهرست شدن آن بیشتر است.
-
-**اول اینکه از کدام دسته از محصولات یا خدمات است؟**
-
-- ابزار گره یا کاربر
-- مدیریت کلید
-- سهام گذاری به عنوان یک سرویس (SaaS)
-- استخر سهامگذاری
-
-در حال حاضر، ما فقط محصولات یا خدمات را در این دسته بندی ها فهرست می کنیم.
-
-### معیارهای شمول {#criteria-for-inclusion}
-
-محصولات یا خدمات سهامگذاری با معیارهای زیر ارزیابی می شوند:
-
-**پروژه یا سرویس چه زمانی راه اندازی شد؟**
-
-- آیا شواهدی وجود دارد که نشان دهد محصول یا خدمت چه زمانی در دسترس عموم قرار گرفت؟
-- این برای تعیین امتیاز "نبرد آزمایش شده" محصولات استفاده می شود.
-
-**آیا از پروژه به طور فعال نگهداری می شود؟**
-
-- آیا یک تیم فعال در حال توسعه پروژه وجود دارد؟ چه افرادی دخیل هستند؟
-- فقط محصولاتی که به طور فعال نگهداری می شوند در نظر گرفته خواهند شد.
-
-**آیا محصول یا خدمات فاقد واسطه های قابل اعتماد/انسانی است؟**
-
-- چه مراحلی در تجربه کاربران، نیازمند اعتماد به انسانها برای نگه داشتن کلیدهای سرمایهشان یا توزیع صحیح جوایز است؟
-- این برای تعیین امتیاز "بی اعتماد" محصول یا خدمات استفاده می شود.
-
-**آیا پروژه اطلاعات دقیق و قابل اعتمادی را ارائه می دهد؟**
-
-- بسیار مهم است که وب سایت محصول دارای اطلاعات به روز، دقیق و غیر گمراه کننده باشد، به خصوص اگر مربوط به پروتکل اتریوم یا سایر فناوری های مرتبط باشد.
-- موارد ارسالی حاوی اطلاعات نادرست، جزئیات قدیمی، یا اظهارات احتمالی گمراه کننده در مورد اتریوم یا سایر موضوعات مرتبط، فهرست نخواهند شد یا اگر قبلاً فهرست شده باشند حذف خواهند شد.
-
-**چه پلتفرم هایی پشتیبانی می شوند؟**
-
-- یعنی Linux, macOS, Windows, iOS, Android
-
-#### نرم افزار و قراردادهای هوشمند {#software-and-smart-contracts}
-
-برای هر نرم افزار سفارشی یا قراردادهای هوشمند درگیر:
-
-**آیا همه چیز منبع باز است؟**
-
-- پروژه های منبع باز باید یک مخزن کد منبع در دسترس عموم داشته باشند
-- این برای تعیین امتیاز "منبع باز" محصولات استفاده می شود.
-
-**آیا محصول از مرحله توسعه _بتا_ خارج شده است؟**
-
-- محصول در چرخه توسعه خود در کجا قرار دارد؟
-- محصولات در مرحله بتا برای درج در ethereum.org در نظر گرفته نمی شوند
-
-**آیا نرم افزار مورد بازرسی امنیتی خارجی قرار گرفته است؟**
-
-- اگر نه، آیا برنامه ای برای انجام ممیزی خارجی وجود دارد؟
-- این برای تعیین امتیاز "ممیزی شده" محصولات استفاده می شود.
-
-**آیا پروژه دارای برنامه پاداش باگ است؟**
-
-- اگر نه، آیا برنامهای برای ایجاد جایزه باگ امنیتی وجود دارد؟
-- از این برای تعیین امتیاز "جایزه باگ" محصولات استفاده می شود.
-
-#### ابزار گره یا کاربر {#node-or-client-tooling}
-
-برای محصولات نرم افزاری مرتبط با تنظیم، مدیریت یا مهاجرت گره یا کاربر:
-
-**کدام کاربر لایه اجماع (به عنوان مثال. Lighthouse, Teku, Nimbus, Prysm) پشتیبانی می شود؟**
-
-- کدام کاربرها پشتیبانی می شوند؟ آیا کاربر می تواند انتخاب کند؟
-- این برای تعیین امتیاز "چند کاربری" محصولات استفاده می شود.
-
-#### سهامگذاری بهعنوان یک خدمت {#staking-as-a-service}
-
-برای [فهرستهای سهامگذاری به عنوان خدمات](/staking/saas/) (به عنوان مثال عملیات گره واگذار شده):
-
-**هزینه های مربوط به استفاده از خدمات چیست؟**
-
-- ساختار هزینه چگونه است، به عنوان مثال. آیا هزینه ماهانه برای خدمات وجود دارد؟
-- آیا سهام گذاری اضافی وجود دارد؟
-
-**آیا کاربران ملزم به ثبت نام برای یک حساب کاربری هستند؟**
-
-- آیا کسی می تواند بدون اجازه یا KYC از این سرویس استفاده کند؟
-- این برای تعیین امتیاز "بدون مجوز" محصولات استفاده می شود.
-
-**چه کسی کلیدهای امضا، و کلیدهای برداشت را در اختیار دارد؟**
-
-- کاربر به چه کلیدهایی دسترسی دارد؟ سرویس به چه کلیدهایی دسترسی پیدا می کند؟
-- این برای تعیین امتیاز "بی اعتماد" محصولات استفاده می شود.
-
-**تنوع مشتری گره های در حال بهره برداری چیست؟**
-
-- چند درصد از کلیدهای اعتبارسنج توسط مشتری لایه اجماع اکثریت (CL) اجرا می شود؟
-- در آخرین ویرایش، Prysm کاربر لایه اجماع است که توسط اکثر اپراتورهای گره اجرا می شود، که برای شبکه خطرناک است. اگر هر کاربر CL در حال حاضر توسط بیش از 33٪ از شبکه استفاده می شود، ما اطلاعات مربوط به استفاده از آن را درخواست می کنیم.
-- این برای تعیین امتیاز "مشتریان متنوع" محصولات استفاده می شود.
-
-#### استخر سهامگذاری {#staking-pool}
-
-برای [خدمات سهامداری ادغام شده](/staking/pools/):
-
-**حداقل ETH مورد نیاز برای سهام گذاری چیست؟**
-
-- مثلا 0.01 ETH
-
-**کارمزدها یا الزامات مربوط به سهام گذاری چیست؟**
-
-- چند درصد از پاداش ها به عنوان کارمزد حذف می شود؟
-- آیا سهام گذاری اضافی وجود دارد؟
-
-**آیا توکن نقدینگی وجود دارد؟**
-
-- توکن ها شامل چه مواردی می شوند؟ چطور کار می کنند؟ آدرس های قرارداد چیست؟
-- این برای تعیین امتیاز "توکن نقدینگی" محصولات استفاده می شود.
-
-**آیا کاربران می توانند به عنوان یک اپراتور گره شرکت کنند؟**
-
-- برای اجرای کاربران اعتبارسنج با استفاده از وجوه ادغام شده چه چیزی لازم است؟
-- آیا این به مجوز یک فرد، شرکت یا DAO نیاز دارد؟
-- این برای تعیین امتیاز "گره های بدون مجوز" محصولات استفاده می شود.
-
-**تنوع کاربر اپراتورهای گره استخر چیست؟**
-
-- چند درصد از اپراتورهای گره کاربر لایه اجماع اکثریت (CL) را اجرا می کنند؟
-- در آخرین ویرایش، Prysm کاربر لایه اجماع است که توسط اکثر اپراتورهای گره اجرا می شود، که برای شبکه خطرناک است. اگر هر کاربر CL در حال حاضر توسط بیش از 33٪ از شبکه استفاده می شود، ما اطلاعات مربوط به استفاده از آن را درخواست می کنیم.
-- این برای تعیین امتیاز "مشتریان متنوع" محصولات استفاده می شود.
-
-### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#other-criteria}
-
-**چه رابط های کاربری پشتیبانی می شوند؟**
-
-- یعنی Browser app, desktop app, mobile app, CLI
-
-**برای ابزار گره، آیا نرم افزار راه آسانی برای جابجایی بین مشتریان ارائه می دهد؟**
-
-- آیا کاربر می تواند به راحتی و با خیال راحت مشتریان را با استفاده از ابزار تغییر دهد؟
-
-**برای SaaS، چند اعتباردهنده در حال حاضر توسط این سرویس کار میکنند؟**
-
-- این به ما ایده ای از میزان دسترسی شما تا کنون می دهد.
-
-## نحوه نمایش نتایج {#product-ordering}
-
-[معیارهای گنجاندن](#criteria-for-inclusion) بالا برای محاسبه امتیاز تجمیعی برای هر محصول یا خدمات استفاده میشود. این به عنوان وسیله ای برای مرتب سازی و نمایش محصولاتی که معیارهای عینی خاصی دارند استفاده می شود. هر چه معیارهای بیشتری برای شواهد ارائه شود، محصول در رده بالاتر مرتب می شود و پیوندها بر اساس بار تصادفی می شوند.
-
-منطق کد و وزن این معیارها در حال حاضر در [این جزء جاوا اسکریپت](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) در مخزن ما موجود است.
-
-## محصول یا سرویس خود را اضافه کنید {#add-product}
-
-اگر میخواهید محصول یا خدماتی را به ethereum.org اضافه کنید، یک مسئله در گیتهاب ایجاد کنید.
-
-
- یک مسئله ایجاد کنید
-
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md b/public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md
deleted file mode 100644
index 8f1e1e21f81..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/adding-wallets/index.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: افزودن کیف پول
-description: سیاستی که هنگام افزودن کیفپول به ethereum.org استفاده می کنیم
-lang: fa
----
-
-# افزودن کیف پول {#adding-wallets}
-
-ما میخواهیم مطمئن شویم که یک طیف گسترده از کیف پولهایی را که کاربران به وسیله آنها میتوانند از ویژگیهای غنی اتریوم استفاده نمایند را نشان میدهیم.
-
-هر کس میتواند اضافه شدن کیف پول جدید به سایت ethereum.org را پیشنهاد کند. اگر کیف پولی وجود دارد که آن را جا انداختیم، لطفاً آن را پیشنهاد دهید!
-
-لیست کیف پولهای فعلی:
-
-- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/)
-
-کیف پولها به سرعت در اتریوم تغییر میکنند. ما تلاش کردیم که یک چارچوب منصفانه برای بررسی و فهرست در ethereum.org ایجاد کنیم، اما معیارهای فهرست بندی در طول زمان تغییر می کنند و تکامل می یابند.
-
-## چارچوب تصمیمات {#the-decision-framework}
-
-### معیارهای گنجانده شدن: موارد ضروری {#the-must-haves}
-
-- **امنیت محصول آزمایش شده باشد** - امنیت کیف پول شما از طریق حسابرسی امنیتی، تیم داخلی امنیت، منبع باز بودن کد یا سایر روشها، باید کاملاً تضمین شده باشد. این کار ریسک کاربران ما را کاهش می دهد و به ما نشان می دهد که امنیت را جدی می گیرید.
-- **کیف پول حداقل به مدت شش ماه برای استفاده در دسترس بوده یا توسط یک گروه معتبر و با شهرت قابل ردیابی عرضه شده باشد** - این امر نشان دیگر امنیت است. شش ماه بازه زمانی مناسبی برای یافتن نقصهای امنیتی حیاتی میباشد. همچنین گذشت شش ماه به تمایز پروژههای معتبر با پروژههایی که صرفا فورک شدهاند کمک میکند.
-- **یک تیم فعال بر روی آن کار میکنند** - این مورد کیفیت کیف پول را تضمین میکند و به کاربر اطمینان میدهد که برای سؤالات و مشکلاتش پشتیبانی دریافت خواهد کرد.
-- **اطلاعات فهرست شده صادقانه و دقیق** - انتظار میرود هر گونه پیشنهاد پروژه ها، با اطلاعات صادقانه و دقیق همراه باشد. محصولاتی که اطلاعات خود را تحریف کنند، مانند منبع باز اعلان کردن کد پروژه در حالی که برخلاف واقعیت باشد، حذف خواهند شد.
-- **نقطه تعامل** - یک نقطه تعامل با کیف پول کمک بزرگی به ما میکند تا به هنگام اعمال تغییرات اطلاعات دقیقی کسب نمائیم. این امر، بروزرسانی ethereum.org را در هنگام جمعآوری اطلاعات آینده قابل مدیریت نگه می دارد.
-- **تراکنشهای EIP-1559 (نوع2)** - کیف پول شما باید از تراکنشهای EIP-1559 (نوع2) برای تراکنشهای شبکه اصلی اتریوم پشتیبانی کند.
-- **تجربه کاربری خوب** - در حالی که UX یک مفهوم ذهنی است، اگر چندین عضو اصلی تیم محصول را آزمایش کنند و استفاده از آن دشوار باشد، ما حق عدم تایید کیفپول را برای خود محفوظ می داریم و در عوض پیشنهادهای مفیدی برای بهبود ارائه می دهیم. این کار برای محافظت از پایگاه کاربرانمان که عمدتاً از مبتدیان تشکیل شده است انجام میشود.
-
-### حذف محصول {#product-removals}
-
-- **اطلاعات به روز شده** - ارائه دهندگان کیفپول مسئول ارسال مجدد اطلاعات کیفپول خود هر 6 ماه یکبار برای اطمینان از اعتبار و مرتبط بودن اطلاعات ارائه شده هستند (حتی اگر هیچ تغییری در محصول آنها وجود نداشته باشد). اگر تیم محصول نتواند این کار را انجام دهد، ethereum.org ممکن است پروژه را از صفحه حذف کند.
-
-### سایر معیارها: بهتر است پروژه پیشنهادی آنها را داشته باشد {#the-nice-to-haves}
-
-- **دسترسیپذیری جهانی** - کیفپول شما دارای محدودیت های جغرافیایی یا الزامات KYC نیست که افراد خاصی را از دسترسی به خدمات شما محروم می کند.
-- **به چندین زبان موجود است** - کیف پول شما به چندین زبان ترجمه شده است و به کاربران در سراسر جهان امکان دسترسی به آن را می دهد.
-- **منبع باز** - کل پایگاه کد پروژه شما (نه فقط ماژول ها) باید در دسترس باشد و باید روابط عمومی از جامعه گستردهتر را بپذیرید.
-- **غیرسرپرستی** - کاربران وجوه خود را کنترل می کنند. اگر پروژه و محصول شما زمانی ناپدید شود، کاربران همچنان بتوانند به وجوه خود دسترسی داشته باشند و آن را جابجا کنند.
-- **پشتیبانی از کیف پول سخت افزاری** - کاربران می توانند کیف پول سخت افزاری خود را برای امضای تراکنش ها متصل کنند.
-- **WalletConnect** - کاربران می توانند با استفاده از WalletConnect به دپها (dapps) متصل شوند.
-- **وارد کردن نقاط پایانی RPC اتریوم ** - کاربران میتوانند دادههای RPC گره را وارد کنند و به آنها امکان میدهد به گره مورد نظر خود یا سایر شبکههای سازگار با EVM متصل شوند.
-- **NFT ها** - کاربران می توانند NFT های خود را در کیف پول مشاهده کرده و با آنها تعامل داشته باشند.
-- **اتصال به برنامه های اتریوم** - کاربران می توانند به برنامه های اتریوم متصل شوند و از آنها استفاده کنند.
-- **سهامگذاری** - کاربران میتوانند مستقیماً از طریق کیف پول اقدام به سهامگذاری کنند.
-- **سوآپها** - کاربران میتوانند توکنها را از طریق کیف پول سوآپ کنند.
-- **شبکه های چند زنجیره ای** - کیف پول شما به طور پیش فرض از دسترسی کاربران به چندین شبکه بلاکچین پشتیبانی می کند.
-- **شبکه های لایه 2** - کیف پول شما به طور پیش فرض از دسترسی کاربران به شبکه های لایه 2 پشتیبانی می کند.
-- **سفارشی کردن کارمزدهای گس** - کیف پول شما به کاربران امکان می دهد کارمز گس تراکنش خود را سفارشی کنند (کارمزد پایه، کارمزد اولویت، حداکثر کارمزد).
-- **پشتیبانی از ENS** - کیف پول شما به کاربران امکان می دهد تراکنش ها را به نام های ENS ارسال کنند.
-- **پشتیبانی از ERC-20** - کیف پول شما به کاربران امکان می دهد آدرس قراردادهای توکن ERC-20 را وارد کنند یا به طور خودکار توکن های ERC-20 را جستجو و نمایش دهند.
-- **خرید رمزارز** - کیف پول شما از کاربرانی پشتیبانی میکند که مستقیماً رمزارز را خریداری میکنند و به آن متصل میشوند.
-- **فروش به قیمت فیات** - کیف پول شما از کاربرانی پشتیبانی میکند که مستقیماً به کارت یا حساب بانکی به فیات بفروشند و برداشت کنند.
-- **چندامضایی** - کیف پول شما از چندین امضا برای امضای تراکنش پشتیبانی می کند.
-- **بازیابی اجتماعی** - کیف پول شما از نگهبانان پشتیبانی میکند و اگر کاربر عبارت اصلی خود را با استفاده از این محافظها گم کند، میتواند کیف پول خود را بازیابی کند.
-- **تیم پشتیبانی اختصاصی** - کیف پول شما دارای یک تیم پشتیبانی اختصاصی است که کاربران می توانند در صورت بروز مشکلات به آن مراجعه کنند.
-- **منابع/اسناد آموزشی** - محصول شما باید یک تجربه نصب خوب طراحی شده برای کمک و آموزش کاربران داشته باشد. یا محتوایی مانند مقالات یا ویدیوهای "چگونه انجام دهیم؟" وجود داشته باشد.
-
-## افزودن یک کیف پول {#adding-a-wallet}
-
-اگر میخواهید یک کیف پول به ethereum.org اضافه کنید، یک مسئله در گیتهاب ایجاد کنید.
-
-
- یک مسئله ایجاد کنید
-
-
-## نگهداری {#maintenance}
-
-از آنجا که ماهیت اتریوم سیال و تغییر پذیر است، تیمها و محصولات میآیند و میروند و نوآوری روزانه اتفاق میافتد، بنابراین ما بررسیهای معمول محتوای خود را انجام خواهیم داد تا:
-
-- اطمینان حاصل کنید که همه کیف پول ها و دپ های لیست شده هنوز معیارهای ما را برآورده می کنند.
-- اطمینان حاصل کنیم هیچ محصولی پیشنهاد نشده باشد که معیارهای بیشتری از محصولات فهرست شده فعلی را رعایت کند و آن را اضافه نکرده باشیم
-
-ethereum.org توسط جامعه منبع باز نگهداری می شود و ما به جامعه برای کمک به بهروز نگه داشتن این موضوع متکی هستیم. اگر متوجه هر گونه اطلاعاتی در مورد کیف پول های لیست شده اید که باید به روز شوند، لطفاً [یک مسئله باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) یا [درخواستهای ادغام](https://github.com/ethereum/ethereum-org-website/pulls) ارسال کنید!
-
-
-## شرایط استفاده {#terms-of-use}
-
-لطفاً به [شرایط استفاده](/terms-of-use/) ما نیز مراجعه کنید. اطلاعات در ethereum.org، صرفاً برای اطلاعات عمومی ارائه شده است.
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md b/public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md
deleted file mode 100644
index 0788f58b182..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/content-resources/index.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: اضافه کردن منابع محتوا
-lang: fa
-description: معیارهای ما برای لیست کردن منابع محتوا در ethereum.org
----
-
-# اضافه کردن منابع محتوا {#adding-content-resources}
-
-ما نمی توانیم امیدوار باشیم که همه چیز Ethereum را پوشش دهیم بنابراین سعی می کنیم برخی از مقالات، آموزش ها، خبرنامه ها، صفحه های شغلی و منابع محتوایی مختلف را که جامعه ایجاد می کند به نمایش بگذاریم. این موارد اغلب اطلاعات عمیق تری در مورد موضوعاتی که کاربران ممکن است به آن ها علاقه مند باشند، فراهم می کنند.
-
-اگر یک منبع محتوایی وجود دارد که احساس می کنید باید به یک صفحه اضافه شود، با خیال راحت آن را در جایی مناسب پیشنهاد دهید.
-
-## چگونه تصمیم می گیریم {#how-we-decide}
-
-منابع یادگیری با معیارهای زیر ارزیابی خواهند شد:
-
-- آیا محتوا به روز است?
-- آیا برای محتوا پرداخت هم هست؟
-- آیا اطلاعات دقیق هستند؟ آیا واقعی است یا مبتنی بر نظر؟
-- آیا نویسنده قابل اعتماد است؟ آیا آنها منابع خود را اعلام کرده اند؟
-- آیا این محتوا ارزش متمایزی دارد که منابع/لینک های موجود پوشش نمی دهند؟
-- آیا این محتوا به درد یکی از [شخصیت های کاربری](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c) ما می خورد؟
-
----
-
-## منابع محتوای خود را اضافه کنید {#add-your-content-resource}
-
-اگر می خواهید یک منبع محتوا به ethereum.org اضافه کنید و معیارها را رعایت می کند، در GitHub یک مسئله ایجاد کنید.
-
-
- یک مسئله ایجاد کنید
-
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md b/public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md
deleted file mode 100644
index c6fb9945253..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/design/adding-design-resources/index.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: افزودن منابع طراحی
-description: دستورالعمل ها و الزامات برای اطمینان از کیفیت مواد طراحی در ethereum.org
-lang: fa
----
-
-# افزودن منابع طراحی {#adding-design-resources}
-
-هر کسی می تواند مواد طراحی جدید را به [طراحی و تجربه کاربری در صفحه Web3](/developers/docs/design-and-ux/) پیشنهاد دهد.
-
-توجه داشته باشید که تمرکز این صفحه بر ارائه ارزش کاربری به طراحان مشتاق Web3 است. بخش طراحی، برای تبلیغ خدمات، محصولات یا پلتفرم های شما نیست.
-
-برای اطمینان از استاندارد بالای اطلاعات و ترویج بینشهای ارزشمند، ما یک خطمشی فهرستبندی ایجاد کردهایم:
-
-## مطالعات پژوهشی و داشبوردها {#Research-studies}
-
-1. روش شناسی منطقی
-
-الف. روش باید به وضوح نحوه جمع آوری داده ها را مشخص کند.
-
-ب. تعداد شرکت کنندگان در تحقیق باید ذکر شود.
-
-ج. روش های تحقیق مورد استفاده باید شرح داده شود.
-
-2. ارتباط با طراحان Web3 و موارد استفاده معمول طراحی
-
-الف. موضوع تحقیق باید با طراحان Web3 مرتبط باشد و به موارد استفاده رایج از طراحی بپردازد.
-
-3. بر ارائه دیدگاه تمرکز کنید
-
-الف. هدف اصلی متن باید به اشتراک گذاشتن دیدگاه باشد تا ترویج یک پروژه یا شرکت خاص.
-
-## مقالات {#Articles}
-
-1. ارتباط با طراحان/محققان Web3 و موارد استفاده معمول طراحی Web3
-
-الف. موضوع مقاله باید مربوط به طراحان و محققان Web3 باشد و بر موارد استفاده از طراحی Web3 متداول متمرکز باشد.
-
-2. کیفیت پایه نگارش
-
-الف. مقاله باید عاری از اشتباهات گرامری و املایی باشد.
-
-ب. باید بر ارائه دیدگاه ها و مطالب کلیدی تاکید شود.
-
-ج. نوشته باید مختصر و دقیق باشد.
-
-3. هدف مقاله
-
-الف. هدف اصلی مقاله باید به اشتراک گذاشتن دیدگاه باشد تا تبلیغ یک پروژه یا شرکت خاص.
-
-## جوامع / DAOها {#Communities-and-DAOs}
-
-1. وبسایت باید به وضوح نحوه پیوستن به DAO/جامعه را نشان دهد
-
-2. مزایای آشکار عضویت
-
-الف. مزایای عضویت باید به طور برجسته نشان داده شوند.
-
-**مثالها**: دریافت بازخورد در مورد کار، دسترسی به فرصتهای شغلی یا جوایز، اشتراکگذاری دیدگاه های طراحی و تحقیق.
-
-3. ارتباط فعال و پر جنب و جوش در دیسکورد
-
-الف. جامعه دیسکورد باید ارتباط پر جنب و جوش و فعالی را به نمایش بگذارد.
-
-ب. مدیران باید به طور فعال در حفظ جامعه و تسهیل بحث ها مشارکت داشته باشند.
-
-ج. جامعه باید سابقه مکالمات ارزشمند و سازنده را در دو هفته گذشته نشان دهد.
-
-با رعایت این معیارها، هدف ما ایجاد یک محیط پر رونق و به اشتراکگذاری دانش در جامعه است. ما معتقدیم که این خط مشی لیست مجاز تضمین می کند که کاربران ما به منابع قابل اعتماد، مرتبط و روشنگر دسترسی دارند. از درک و همکاری شما در حفظ کیفیت محتوا در بستر ما سپاسگزاریم.
diff --git a/public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md b/public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md
deleted file mode 100644
index 77c2a880896..00000000000
--- a/public/content/translations/fa/28) Contributing 2/contributing/quizzes/index.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: اضافه کردن یک آزمون
-description: سیاستی که هنگام اضافه کردن آزمونها به ethereum.org استفاده میکنیم
-lang: fa
----
-
-# آزمون ها {#quizzes}
-
-آزمونها فرصتی هستند برای کاربران تا خود را امتحان کنند و ببینند آیا محتوای صفحهای که تازه خواندهاند را درک کردهاند یا نه. سؤالات باید فقط بر اساس محتوای ارائه شده در صفحه باشند و نباید درباره اطلاعاتی که در صفحه ذکر نشده است، پرسیده شوند.
-
-ساختار سؤالات باید به صورت زیر باشد. متن سؤال، یک پاسخ صحیح با توضیح دلیل صحت آن، و سه پاسخ نادرست هر کدام با توضیح درباره دلیل نادرست بودنشان.
-
-برای مشاهده برخی نمونههای آزمونهای فعلی، به اینجا مراجعه کنید:
-
-- [لایه 2](/layer-2)
-- [نیفتی](/nft/)
-- [اتریوم چیست؟](/what-is-ethereum/)
-- [اتر (ETH) چیست؟](/eth/)
-
-## اضافه کردن یک آزمون یادگیری
-
-اگر صفحهای وجود دارد که هنوز آزمون یادگیری برای آن ایجاد نشده است، لطفا [یک درخواست جدید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) برای آن ثبت کنید.
-
-لطفا اطلاعات زیر را ارائه دهید:
-
-- صفحهای که میخواهید آزمون را به آن اضافه کنید
-- 5 سؤال با اطلاعات زیر:
- - بخشی از صفحه که سؤال بر اساس آن است
- - عنوان سؤال
- - یک پاسخ صحیح به همراه توضیحاتی درباره دلیل صحت آن
- - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
-
-## اضافه کردن یک سؤال آزمون
-
-اگر سؤالی وجود دارد که می خواهید به بانک سؤالات آزمون اضافه کنید، لطفا [یک درخواست جدید باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) و اطلاعات زیر را ارائه دهید:
-
-- صفحه ای که می خواهید سؤال آزمون را به آن اضافه کنید
-- برای هر سؤال (که اضافه می شود) اطلاعات زیر را ارائه کنید:
- - بخشی از صفحه که سؤال بر اساس آن است
- - عنوان سؤال
- - یک پاسخ صحیح به همراه توضیحاتی دربارهی دلیل صحت آن
- - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
-
-## بهروز رسانی یک سؤال آزمون
-
-اگر سؤالی وجود دارد که می خواهید به بانک سؤالات آزمون اضافه کنید، لطفا [یک درخواست جدید باز کنید](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) و اطلاعات زیر را ارائه دهید:
-
-- صفحه ای که می خواهید سؤال آزمون را در آن بهروز رسانی کنید
-- برای هر سؤالی که بهروز رسانی میشود، اطلاعات زیر را ارائه دهید:
- - بخشی از صفحه که سؤال بر اساس آن است
- - عنوان سؤالی که میخواهید بهروز رسانی کنید
- - عنوان بهروز رسانی شده سؤال
- - یک پاسخ صحیح به همراه توضیحاتی درباره دلیل صحت آن
- - سه پاسخ نادرست، هر کدام به همراه توضیحی درباره دلیل نادرست بودن آنها
-
-## حذف یک سؤال آزمون
-
-اگر محتوا برای یک سؤال در صفحه وجود ندارد و باید حذف شود، لطفا [یک درخواست](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) برای حذف سؤال ارسال کنید و اطلاعات زیر را بدهید:
-
-- صفحه ای که می خواهید سؤال آزمون را در آن حذف کنید
-- پرسشی که می خواهید حذف کنید
-- توضیح در صورت لزوم برای دلیل حذف پرسش
From 85eea5a4b3a0de58a20a2a16f29075be2b5dc993 Mon Sep 17 00:00:00 2001
From: Corwin Smith
Date: Wed, 16 Oct 2024 14:56:19 -0600
Subject: [PATCH 3/9] build errors
---
public/content/translations/fa/about/index.md | 4 +--
.../content/translations/fa/bridges/index.md | 16 +++++------
public/content/translations/fa/desci/index.md | 4 +--
.../fa/developers/docs/dapps/index.md | 2 +-
.../patricia-merkle-trie/index.md | 2 +-
.../fa/developers/docs/evm/index.md | 4 +--
.../fa/developers/docs/mev/index.md | 6 ++--
.../developers/docs/networking-layer/index.md | 2 +-
.../nodes-and-clients/archive-nodes/index.md | 4 +--
.../client-diversity/index.md | 2 +-
.../node-architecture/index.md | 2 +-
.../fa/developers/docs/oracles/index.md | 10 +++----
.../smart-contracts/composability/index.md | 4 +--
.../formal-verification/index.md | 2 +-
.../docs/smart-contracts/testing/index.md | 18 ++++++------
.../docs/smart-contracts/verifying/index.md | 4 +--
.../docs/standards/tokens/erc-223/index.md | 6 ++--
.../fa/developers/docs/transactions/index.md | 23 +--------------
.../fa/energy-consumption/index.md | 2 +-
.../translations/fa/enterprise/index.md | 28 ++++++++-----------
.../translations/fa/roadmap/dencun/index.md | 7 ++---
.../translations/fa/social-networks/index.md | 8 +++---
.../translations/fa/staking/solo/index.md | 7 ++---
.../translations/fa/whitepaper/index.md | 11 +++-----
24 files changed, 71 insertions(+), 107 deletions(-)
diff --git a/public/content/translations/fa/about/index.md b/public/content/translations/fa/about/index.md
index 10f2e68e7fa..3302f9c8362 100644
--- a/public/content/translations/fa/about/index.md
+++ b/public/content/translations/fa/about/index.md
@@ -96,9 +96,7 @@ ethereum.org یک منبع عمومی منبع باز برای جامعه اتر
**میخواهید مشارکت کنید؟** [درباره مشارکت بیشتر بیاموزید](/contributing/)، [در توییتر با ما تماس بگیرید](https://twitter.com/ethdotorg)، یا به بحثهای جامعه در
-سرور دیسکورد ما بپیوندید< /3>.
-
-
+سرور دیسکورد ما بپیوندید.
## اصول طراحی کنید {#design-principles}
diff --git a/public/content/translations/fa/bridges/index.md b/public/content/translations/fa/bridges/index.md
index 11b0c468bba..f2616b0be16 100644
--- a/public/content/translations/fa/bridges/index.md
+++ b/public/content/translations/fa/bridges/index.md
@@ -18,7 +18,7 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
شما اهل آمريكا هستيد و می خواهيد به اروپا سفر كنيد. شما دلار داريد ولي به يورو نياز داريد. براي تبديل دلار به يورو از يك صرافي با كارمزد كم كمك مي گيريد.
-اما، اگر بخواهید یک صرافی مشابه برای استفاده از یک [بلاکچین](/glossary/#blockchain) متفاوت ایجاد کنید، چه میکنید؟ فرض کنید میخواهید [اتر](/glossary/#ether) در شبکه اصلی اتریوم را با اتر در [آربیتروم](https://arbitrum.io/) مبادله کنید. مثل تبديل پولي كه براي يورو انجام داديم، به يك مكانيزم نياز داريم تا بتوانيم اتر بلاك چين اصلي را به اتر بلاك چين آربیتروم تبديل كنيم. پل ها چنين انتقالي را امكان پذير مي كنند. در اين مثال [ آربیتروم داراي يك پل اصلي است ](https://bridge.arbitrum.io/) كه مي تواند اتر را از شبکه اصلی به آربیتروم انتقال دهد.
+اما، اگر بخواهید یک صرافی مشابه برای استفاده از یک [بلاکچین](/glossary/#blockchain) متفاوت ایجاد کنید، چه میکنید؟ فرض کنید میخواهید [اتر](/glossary/#ether) در شبکه اصلی اتریوم را با اتر در [آربیتروم](https://arbitrum.io/) مبادله کنید. مثل تبديل پولي كه براي يورو انجام داديم، به يك مكانيزم نياز داريم تا بتوانيم اتر بلاك چين اصلي را به اتر بلاك چين آربیتروم تبديل كنيم. پل ها چنين انتقالي را امكان پذير مي كنند. در اين مثال [آربیتروم داراي يك پل اصلي است](https://bridge.arbitrum.io/) كه مي تواند اتر را از شبکه اصلی به آربیتروم انتقال دهد.
## چرا به پلها نياز داريم؟ {#why-do-we-need-bridges}
@@ -77,10 +77,10 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
به طور مشخص می توان گفت که در پلهایی که نیاز به اعتماد می باشد شما به پلتفرم مورد نظر اعتماد می کنید در حالی که در پلهای بدون اعتماد با حداقل اعتماد کردن و صرفا با فرض درست بودن دامنه های زیر ساخت کار انجام می شود. این اصطلاحات در زیر توضیح داده شده است:
-- بدون اعتماد**: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط آرجون بوپتانی در این مقاله
- توضیح داده شده است
+- بدون اعتماد**: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط آرجون بوپتانی در این مقاله
+ توضیح داده شده است
- - در مدل دارای اعتماد:** با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
+ - در مدل دارای اعتماد:** با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
برای این که تفاوت های اساسی بین دو روش بهتر جا بیفتد یک مثال ارائه می شود:
@@ -103,15 +103,15 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
پلها در مرحله ابتدایی توسعه می باشند. به عبارتی طراحی بهینه پلها هنوز به صورت کامل کشف نشده است. استفاده از هر کدام از پلها خطر مربوط به خود را دارد:
-- خطر قرارداد هوشمند —** وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
+- خطر قرارداد هوشمند —** وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
- - خطر تکنولوژی—** خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
+ - خطر تکنولوژی—** خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
با این حال پلهای نیازمند به اعتماد از آنجا که تصورهای اعتماد را افزایش میدهند، می توانند خطرات مضاعفی را به همراه داشته باشند، مثل:
- - خطر سانسور—** کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
+ - خطر سانسور—** کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
- - خطر سرپرستی—** کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند
+ - خطر سرپرستی—** کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند
دارایی های کابرها در خطر هستند اگر:
diff --git a/public/content/translations/fa/desci/index.md b/public/content/translations/fa/desci/index.md
index 9e0160ec762..1605d32e043 100644
--- a/public/content/translations/fa/desci/index.md
+++ b/public/content/translations/fa/desci/index.md
@@ -68,7 +68,7 @@ DeSci در حال ساخت مجموعه ابزارهای علمی برای ور
مطالعات نشان داده اند که پانل های بررسی کمک هزینه در انتخاب پیشنهادهای با کیفیت بالا کار ضعیفی انجام می دهند، زیرا همان پیشنهادات ارائه شده به پانل های مختلف نتایج بسیار متفاوتی دارند. از آنجایی که بودجه کمیابتر شده است، این بودجه در مجموعه کوچکتری از محققان ارشد با پروژههای محافظهکارانهتر متمرکز شده است. این اثر یک چشم انداز سرمایه گذاری بیش از حد رقابتی ایجاد کرده است، انگیزه های انحرافی را تقویت می کند و نوآوری را خفه می کند.
-Web3 این پتانسیل را دارد که با آزمایش مدلهای انگیزشی مختلف که توسط DAOs و Web3 به طور گسترده ایجاد شدهاند، این مدل بودجه شکسته را مختل کند. [تأمین مالی ماسبق برای کالاهای عمومی](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) و [تأمین مالی درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) و [حاکمیت DAO](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) و [ساختارهای تشویقی توکنیزه شده](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) ساختارهای تشویقی توکنیزه شده، برخی از ابزارهای Web3 هستند که می توانند تأمین مالی علمی را متحول کنند.
+Web3 این پتانسیل را دارد که با آزمایش مدلهای انگیزشی مختلف که توسط DAOs و Web3 به طور گسترده ایجاد شدهاند، این مدل بودجه شکسته را مختل کند. [تأمین مالی ماسبق برای کالاهای عمومی](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) و [تأمین مالی درجه دوم](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) و [حاکمیت DAO](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) و [ساختارهای تشویقی توکنیزه شده](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) ساختارهای تشویقی توکنیزه شده، برخی از ابزارهای Web3 هستند که می توانند تأمین مالی علمی را متحول کنند.
### مالکیت و توسعه IP {#ip-ownership}
@@ -110,7 +110,7 @@ Web3 این پتانسیل را دارد که با آزمایش مدلهای
- [Cerebrum DAO : منبع یابی و راه حل های مفید برای سلامت مغز پیشرفته و جلوگیری از عصب تباهی (تخریب نورونی)](https://www.cerebrumdao.com/)
- [CryoDAO: سرمایه گذاری پروژه های بلندپروازانه در حوزه ارز های دیجیتال](https://www.cryodao.org)
-ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط مشی فهرست [](/contributing/adding-desci-projects/) ما نگاه کنید!
+ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط مشی فهرست ما نگاه کنید!
## بیشتر بخوانید {#further-reading}
diff --git a/public/content/translations/fa/developers/docs/dapps/index.md b/public/content/translations/fa/developers/docs/dapps/index.md
index 5ff228dde35..f50a87f0ab9 100644
--- a/public/content/translations/fa/developers/docs/dapps/index.md
+++ b/public/content/translations/fa/developers/docs/dapps/index.md
@@ -59,7 +59,7 @@ lang: fa
- [گیتهاب](https://github.com/paulrberg/create-eth-app)
**One Click Dapp _- ابزار FOSS برای تولید صفحات فرانت dapp از
-ABI.
+ABI>.
- [oneclickdapp.com](https://oneclickdapp.com)
- [گیت هاب](https://github.com/oneclickdapp/oneclickdapp-v1)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
index ea7754e1a20..e42f25eaefa 100644
--- a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
@@ -16,7 +16,7 @@ sidebarDepth: 2
## موارد مورد نیاز {#prerequisites}
برای درک بهتر این صفحه، داشتن دانش اولیه در مورد [هش](https://en.wikipedia.org/wiki/Hash_function)، [درخت مرکل](https://en.wikipedia.org/wiki/Merkle_tree)، [درخت ها](https://en.wikipedia.org/wiki/Trie) و
-سریال سازی3 مفید خواهد بود. >. این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
+سریال سازی مفید خواهد بود. . این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
diff --git a/public/content/translations/fa/developers/docs/evm/index.md b/public/content/translations/fa/developers/docs/evm/index.md
index a7a5d7ef135..940f960e366 100644
--- a/public/content/translations/fa/developers/docs/evm/index.md
+++ b/public/content/translations/fa/developers/docs/evm/index.md
@@ -8,7 +8,7 @@ lang: fa
## پیشنیازها {#prerequisites}
-برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/ Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و درخت مرکل.
+برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و درخت مرکل.
## از دفتر کل تا ماشین حالات متناهی {#from-ledger-to-state-machine}
@@ -16,7 +16,7 @@ lang: fa
در حالی که اتریوم دارای رمزارز بومی خود (اتر) است که تقریباً بهطور کامل از قوانین شهودی مشابهی پیروی میکند، کارکرد بسیار قدرتمندتری را نیز ممکن میسازد: [قراردادهای هوشمند](/developers/docs/smart-contracts/). برای این ویژگی پیچیدهتر، قیاس پیچیدهتری نیز لازم است. به جای یک دفتر کل توزیع شده، اتریوم یک [ماشین حالات متناهی](https://wikipedia.org/wiki/Finite-state_machine) توزیعشده است. وضعیت اتریوم یک ساختار دادهی بزرگ است که نهتنها همه حسابها و موجودیها را در خود نگه میدارد، بلکه _وضعیت ماشین_ را نیز در خود جای میدهد که میتواند طبق مجموعهای از قوانین از پیش تعریفشده از بلوکی به بلوک دیگر تغییر کند و کد ماشینی دلخواه را اجرا کند. قوانین خاص تغییر حالت از بلوک به بلوک توسط EVM تعریف شده است.
-![نموداری که ساختار EVM را نشان میدهد](./evm.png) _نمودار برگرفته از[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+![نموداری که ساختار EVM را نشان میدهد](./evm.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## تابع گذار حالت اتریوم {#the-ethereum-state-transition-function}
diff --git a/public/content/translations/fa/developers/docs/mev/index.md b/public/content/translations/fa/developers/docs/mev/index.md
index 33ef8da3222..39d2f7a5180 100644
--- a/public/content/translations/fa/developers/docs/mev/index.md
+++ b/public/content/translations/fa/developers/docs/mev/index.md
@@ -68,7 +68,7 @@ MEV به چند روش در بلاک چین ظاهر می شود.
یک جستجوگر می تواند اثر قیمت تقریبی این معامله بزرگ را روی جفت UNI/DAI محاسبه کند و بلافاصله _قبل از_ معامله بزرگ، سفارش خرید بهینه را اجرا کند، UNI را ارزان بخرد، سپس دستور فروش را فوراً _ پس از_ تجارت بزرگ اجرا کند و آن را به قیمت بالاتر ناشی از سفارش بزرگ بفروشد.
-با این حال، ساندویچ کردن خطرناک تر است زیرا اتمی نیست (برخلاف آربیتراژ DEX، همانطور که در بالا توضیح داده شد) و مستعد [حمله salmonella ](https://github.com/Defi-Cartel/salmonella) است.
+با این حال، ساندویچ کردن خطرناک تر است زیرا اتمی نیست (برخلاف آربیتراژ DEX، همانطور که در بالا توضیح داده شد) و مستعد [حمله salmonella](https://github.com/Defi-Cartel/salmonella) است.
### MEV در NFT {#mev-examples-nfts}
@@ -112,7 +112,7 @@ MEV کلا بد نیست - پیامدهای مثبت و منفی برای MEV ر
در حالی که بسیاری از جستجوگران هنوز از MEV درآمد خوبی کسب می کنند، با شناخته شدن فرصت ها و رقابت جستجوگران بیشتر و بیشتر برای فرصت های مشابه، اعتبار سنج ها درآمد کل MEV بیشتری را به دست خواهند آورد (زیرا همان نوع حراج گس که در ابتدا در بالا توضیح داده شد. در Flashbots نیز اتفاق می افتد، البته به صورت خصوصی، و اعتبار سنج ها درآمد حاصل از گس را دریافت می کنند). MEV نیز منحصر به اتریوم نیست و با رقابتی شدن فرصت ها در اتریوم، جستجوگران به سمت بلاک چین های جایگزین مانند زنجیره هوشمند بایننس حرکت می کنند، جایی که فرصت های MEV مشابه با اتریوم با رقابت کمتری وجود دارد.
-از سوی دیگر، انتقال از اثبات کار به اثبات سهام و تلاش مداوم برای مقیاسبندی اتریوم با استفاده از جمعآوریها، همگی چشمانداز MEV را به روشهایی تغییر میدهند که هنوز تا حدودی نامشخص است. هنوز به خوبی شناخته نشده است که چگونه داشتن پیشنهاد دهندگان بلوک تضمین شده که از قبل کمی شناخته شده اند، دینامیک استخراج MEV را در مقایسه با مدل احتمالی در اثبات کار تغییر می دهد یا چگونه این امر هنگام [انتخاب رهبر مخفی منفرد0 مختل می شود ](https://ethresear.ch/t/secret-non-single-leader-election/11789) و [فناوری اعتبارسنج توزیع شده](/staking/dvt/) پیاده سازی می شود. به طور مشابه، باید دید چه فرصتهای MEV زمانی وجود دارد که بیشتر فعالیتهای کاربر از اتریوم خارج میشوند و روی رولآپ های لایه 2 و شاردهای آن منتقل میشوند.
+از سوی دیگر، انتقال از اثبات کار به اثبات سهام و تلاش مداوم برای مقیاسبندی اتریوم با استفاده از جمعآوریها، همگی چشمانداز MEV را به روشهایی تغییر میدهند که هنوز تا حدودی نامشخص است. هنوز به خوبی شناخته نشده است که چگونه داشتن پیشنهاد دهندگان بلوک تضمین شده که از قبل کمی شناخته شده اند، دینامیک استخراج MEV را در مقایسه با مدل احتمالی در اثبات کار تغییر می دهد یا چگونه این امر هنگام [انتخاب رهبر مخفی منفرد مختل می شود](https://ethresear.ch/t/secret-non-single-leader-election/11789) و [فناوری اعتبارسنج توزیع شده](/staking/dvt/) پیاده سازی می شود. به طور مشابه، باید دید چه فرصتهای MEV زمانی وجود دارد که بیشتر فعالیتهای کاربر از اتریوم خارج میشوند و روی رولآپ های لایه 2 و شاردهای آن منتقل میشوند.
## MEV در اثبات سهام اتریوم (PoS) {#mev-in-ethereum-proof-of-stake}
@@ -122,7 +122,7 @@ MEV کلا بد نیست - پیامدهای مثبت و منفی برای MEV ر
در اتریوم پس از ادغام، اعتبارسنج ها (با سپرده گذاری امنیتی 32 اتریوم) در مورد اعتبار بلوک های اضافه شده به زنجیره بیکن اتفاق نظر دارند. از آنجایی که 32 ETH ممکن است از دسترس بسیاری خارج باشد، [پیوستن به یک استخر سهام](/staking/pools/) ممکن است گزینه عملی تری باشد. با این وجود، توزیع سالم [سهامگذاران انفرادی](/staking/solo/) ایده آل است، زیرا تمرکز اعتبارسنج ها را کاهش می دهد و امنیت اتریوم را بهبود می بخشد.
-با این حال، اعتقاد بر این است که استخراج MEV قادر به تسریع تمرکز اعتبارسنج است. این تا حدی به این دلیل است که اعتبارسنج ها [درآمد کمتری برای پیشنهاد بلوکها ](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) نسبت به ماینرهای قبلی دارند، استخراج MEV از زمان ادغام تا حد زیادی [درآمد اعتبارسنج ها را تحت تأثیر قرار میدهد](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb).
+با این حال، اعتقاد بر این است که استخراج MEV قادر به تسریع تمرکز اعتبارسنج است. این تا حدی به این دلیل است که اعتبارسنج ها [درآمد کمتری برای پیشنهاد بلوکها](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) نسبت به ماینرهای قبلی دارند، استخراج MEV از زمان ادغام تا حد زیادی [درآمد اعتبارسنج ها را تحت تأثیر قرار میدهد](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb).
استخرهای بزرگتر سهامگذاری احتمالاً منابع بیشتری برای سرمایه گذاری در بهینه سازی های لازم برای جذب فرصت های MEV خواهند داشت. هرچه این استخرها MEV بیشتری استخراج کنند، منابع بیشتری برای بهبود قابلیتهای استخراج MEV (و افزایش درآمد کلی) دارند، که اساساً [اقتصاد مقیاس](https://www.investopedia.com/terms/e/economiesofscale.asp#) ایجاد میکند.
diff --git a/public/content/translations/fa/developers/docs/networking-layer/index.md b/public/content/translations/fa/developers/docs/networking-layer/index.md
index 519af1b03ef..91b4c252c85 100644
--- a/public/content/translations/fa/developers/docs/networking-layer/index.md
+++ b/public/content/translations/fa/developers/docs/networking-layer/index.md
@@ -152,4 +152,4 @@ SSZ مخفف سریال سازی ساده است. از افست های ثابت
## اطلاعات بیشتر {#further-reading}
-[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [مشخصات شبکه لایه اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia به discv5](https://vac.dev/kademlia-to-discv5) [مقاله kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [معرفی p2p اتریوم ](https://p2p.paris/en/talks/intro-ethereum-networking/) [رابطه eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [ویدیوی مرج و جزئیات کلاینت eth2](https://www.youtube.com/watch?v=zNIrIninMgg)
+[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [مشخصات شبکه لایه اجماع](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia به discv5](https://vac.dev/kademlia-to-discv5) [مقاله kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [معرفی p2p اتریوم](https://p2p.paris/en/talks/intro-ethereum-networking/) [رابطه eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [ویدیوی مرج و جزئیات کلاینت eth2](https://www.youtube.com/watch?v=zNIrIninMgg)
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md
index a26391d9d4c..eecb1201c1a 100644
--- a/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/archive-nodes/index.md
@@ -45,9 +45,7 @@ sidebarDepth: 2
- تحلیلگران امنیتی
- توسعهدهندگان برنامههای غیرمتمرکز یا Dappها
- حسابرسی و انطباق
-سرویسهای رایگان مختلف وجود دارند که امکان دسترسی به دادههای تاریخی را فراهم میکنند. از آنجا که اجرای یک گره آرشیو پرزحمت تر است، دسترسی به آن از طریق سرویسهای مختلف عمدتاً محدود بوده و ممکن است این سرویسها تنها بعضی اوقات کار کنند. اگر پروژۀ شما نیاز به دسترسی پیوسته به دادههای تاریخی دارد، بهتر است خودتان یک گره آرشیو بر روی سیستمتان اجرا کنید.
-
-
+سرویسهای رایگان مختلف وجود دارند که امکان دسترسی به دادههای تاریخی را فراهم میکنند. از آنجا که اجرای یک گره آرشیو پرزحمت تر است، دسترسی به آن از طریق سرویسهای مختلف عمدتاً محدود بوده و ممکن است این سرویسها تنها بعضی اوقات کار کنند. اگر پروژۀ شما نیاز به دسترسی پیوسته به دادههای تاریخی دارد، بهتر است خودتان یک گره آرشیو بر روی سیستمتان اجرا کنید.
## اجراها و کاربرد
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md
index 9a2fcf0b6b2..86aed0cd0c2 100644
--- a/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/client-diversity/index.md
@@ -43,7 +43,7 @@ sidebarDepth: 2
![نمودار دایرهای که تنوع کلاینت را نشان میدهد](./client-diversity.png) _دادههای نمودار از [ethernodes.org](https://ethernodes.org) و [ clientdiversity.org](https://clientdiversity.org/)_
-دو نمودار دایرهای بالا تصاویری فوری از تنوع کلاینت فعلی برای لایههای اجرا و اجماع (در زمان نگارش در ژانویه 2022) را نشان میدهند. لایهی اجرا غالباً در سلطهی [Geth](https://geth.ethereum.org/) است، [Open Ethereum با فاصله دوم است، ](https://openethereum.github.io/) [Erigon](https://github.com/ledgerwatch/erigon) سوم است و [Nethermind](https://nethermind.io/) چهارم است، و در عین حال سایر کلاینتها که کمتر از 1% شبکه را تشکیل میدهند. رایجترین کلاینت مورد استفاده در لایهی اجماع - [Prysm](https://prysmaticlabs.com/#projects) - به اندازه Geth غالب نیست، اما در عین حال بیش از 60% از شبکه را نمایندگی میکند. [Lighthouse](https://lighthouse.sigmaprime.io/) و [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) به ترتیب 20% و حدود 14% حضور دارند و سایر کلاینتها بهندرت استفاده میشوند.
+دو نمودار دایرهای بالا تصاویری فوری از تنوع کلاینت فعلی برای لایههای اجرا و اجماع (در زمان نگارش در ژانویه 2022) را نشان میدهند. لایهی اجرا غالباً در سلطهی [Geth](https://geth.ethereum.org/) است، [Open Ethereum با فاصله دوم است،](https://openethereum.github.io/) [Erigon](https://github.com/ledgerwatch/erigon) سوم است و [Nethermind](https://nethermind.io/) چهارم است، و در عین حال سایر کلاینتها که کمتر از 1% شبکه را تشکیل میدهند. رایجترین کلاینت مورد استفاده در لایهی اجماع - [Prysm](https://prysmaticlabs.com/#projects) - به اندازه Geth غالب نیست، اما در عین حال بیش از 60% از شبکه را نمایندگی میکند. [Lighthouse](https://lighthouse.sigmaprime.io/) و [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) به ترتیب 20% و حدود 14% حضور دارند و سایر کلاینتها بهندرت استفاده میشوند.
داده های لایه اجرا از [Ethernodes](https://ethernodes.org) در 23 ژانویه 2022 به دست آمدند. دادههای کلاینتهای اجماع از [Michael Sproul](https://github.com/sigp/blockprint) گرفته شده است. بهدست آوردن دادههای کاربر اجماع دشوارتر است، زیرا کاربرهای لایه اجماع همیشه دارای ردپاهای واضحی نیستند که بتوان از آنها برای شناسایی استفاده کرد. دادهها با استفاده از یک الگوریتم طبقهبندی تولید شدهاند که گاهی برخی از کلاینتهای اقلیت را گیج میکند (برای جزئیات بیشتر به [اینجا](https://twitter.com/sproulM_/status/1440512518242197516) مراجعه کنید). در نمودار بالا، این طبقهبندیهای مبهم یک برچسب یا این/یا آن (بهعنوان مثال Nimbus/Teku) دارند. با وجود این، واضح است که اکثریتِ شبکه Prysm را اجرا میکند. دادهها، تصویری از مجموعهی ثابتی از بلوکها هستند (در این مورد، بلوکهای بیکن در اسلاتهای 2048001 تا 2164916) و حضور غالب Prysm گاهی اوقات بالاتر و بیش از 68% بوده است. علیرغم صرفاً یک تصویر بودن، مقادیر نمودار درک کلی خوبی از وضعیت فعلی تنوع کلاینت ارائه میدهند.
diff --git a/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md
index d98b0f7bc75..28c9e4aaead 100644
--- a/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md
+++ b/public/content/translations/fa/developers/docs/nodes-and-clients/node-architecture/index.md
@@ -6,7 +6,7 @@ lang: fa
یک گره اتریوم از دو کاربر تشکیل شده است: یک [کاربر اجرا](/developers/docs/nodes-and-clients/#execution-clients) و یک [کاربر اجماع](/developers/docs/nodes-and-clients/#consensus-clients).
-زمانی که اتریوم از [مکانیسم اثبات کار](/developers/docs/consensus-mechanisms/pow/) استفاده میکرد، یک کاربر اجرا برای اجرای یک گره کامل اتریوم کافی بود. اما، از زمان اجرای [مکانیسم اثبات سهام](/developers/docs/consensus-mechanisms/pow/)، کاربر اجرا میبایست در کنار نرمافزار دیگری به نام [کاربر اجماع ](/developers/docs/nodes-and-clients/#consensus-clients) استفاده شود.
+زمانی که اتریوم از [مکانیسم اثبات کار](/developers/docs/consensus-mechanisms/pow/) استفاده میکرد، یک کاربر اجرا برای اجرای یک گره کامل اتریوم کافی بود. اما، از زمان اجرای [مکانیسم اثبات سهام](/developers/docs/consensus-mechanisms/pow/)، کاربر اجرا میبایست در کنار نرمافزار دیگری به نام [کاربر اجماع](/developers/docs/nodes-and-clients/#consensus-clients) استفاده شود.
نمودار زیر رابطۀ بین دو کاربر اتریوم را نشان میدهد. هر یک از این دو کاربر به شبکههای همتا به همتای (P2P) مخصوص خود متصل میشوند. دلیل نیاز به شبکههای همتا به همتای جداگانه این است که: کاربرهای اجرا تراکنشها را از طریق شبکۀ همتا به همتای خود شایعه میکنند که آنها را قادر میسازد استخر تراکنشهای محلی خود را مدیریت کنند، در حالی که کاربرهای اجماع، بلوکها را از طریق شبکۀ همتا به همتا شایعه میکنند، که امکان اجماع و رشد زنجیره را فراهم میکند.
diff --git a/public/content/translations/fa/developers/docs/oracles/index.md b/public/content/translations/fa/developers/docs/oracles/index.md
index 64c34080230..b72571325ee 100644
--- a/public/content/translations/fa/developers/docs/oracles/index.md
+++ b/public/content/translations/fa/developers/docs/oracles/index.md
@@ -358,7 +358,7 @@ contract PriceConsumerV3 {
برخی از برنامههای بلاکچین، مانند بازیهای مبتنی بر بلاکچین یا طرحهای بختآزمایی، به سطح بالایی از غیرقابل پیشبینی و تصادفی بودن نیاز دارند تا به طور مؤثر کار کنند. با این حال، اجرای قطعی بلاکچینها تصادفی بودن را از بین میبرد.
-رویکرد اولیه استفاده از توابع رمزنگاری شبه تصادفی، مانند `بلاک هش` بود، اما اینها ممکن [توسط ماینرها](https://ethereum.stackexchange.com/questions/3140/risk-of-using- blockhash-other-miners-preventing-attack#:~:text=است%20که%20the%20miners%20can,to%20one%20of%20the%20players.) برای حل مشکل الگوریتم اثبات کار دستکاری شوند. همچنین، [تغییر به اثبات سهام](/roadmap/merge/) اتریوم به این معنی است که توسعهدهندگان دیگر نمیتوانند برای تصادفی بودن روی زنجیره به `بلاک هش` اعتماد کنند. در عوض، [مکانیزم RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) بیکون چین یک منبع جایگزین برای تصادفی بودن فراهم میکند.
+رویکرد اولیه استفاده از توابع رمزنگاری شبه تصادفی، مانند `بلاک هش` بود، اما اینها ممکن [توسط ماینرها](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=است%20که%20the%20miners%20can,to%20one%20of%20the%20players.) برای حل مشکل الگوریتم اثبات کار دستکاری شوند. همچنین، [تغییر به اثبات سهام](/roadmap/merge/) اتریوم به این معنی است که توسعهدهندگان دیگر نمیتوانند برای تصادفی بودن روی زنجیره به `بلاک هش` اعتماد کنند. در عوض، [مکانیزم RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) بیکون چین یک منبع جایگزین برای تصادفی بودن فراهم میکند.
امکان تولید ارزش تصادفی خارج از زنجیره و ارسال آن در زنجیره وجود دارد، اما انجام این کار الزامات اعتماد بالایی را به کاربران تحمیل میکند. آنها باید باور داشته باشند که ارزش واقعی از طریق مکانیسمهای غیرقابل پیشبینی ایجاد شده است و در حمل و نقل تغییر نکرده است.
@@ -380,7 +380,7 @@ contract PriceConsumerV3 {
برخی از شبکههای اوراکل غیرمتمرکز خدمات اتوماسیون را ارائه میکنند که به گرههای اوراکل خارج از زنجیره اجازه میدهد تا عملکردهای قرارداد هوشمند را بر اساس پارامترهای تعریف شده توسط کاربر فعال کنند. به طور معمول، این امر مستلزم «ثبت» قرارداد هدف با سرویس اوراکل، تأمین بودجه برای پرداخت به اپراتور اوراکل و مشخص کردن شرایط یا زمانهای شروع قرارداد است.
-[شبکه کیپر](https://chain.link/keepers) چین لینک گزینههایی را برای قراردادهای هوشمند برای برونسپاری وظایف تعمیر و نگهداری منظم به روشی به حداقل رسیده و غیرمتمرکز ارائه میدهد. [داکیومنت کیپر ](https://docs.chain.link/docs/chainlink-keepers/introduction/) را برای اطلاعات در مورد سازگار کردن قرارداد خود با کیپر و استفاده از سرویس Upkeep بخوانید.
+[شبکه کیپر](https://chain.link/keepers) چین لینک گزینههایی را برای قراردادهای هوشمند برای برونسپاری وظایف تعمیر و نگهداری منظم به روشی به حداقل رسیده و غیرمتمرکز ارائه میدهد. [داکیومنت کیپر](https://docs.chain.link/docs/chainlink-keepers/introduction/) را برای اطلاعات در مورد سازگار کردن قرارداد خود با کیپر و استفاده از سرویس Upkeep بخوانید.
## نحوه استفاده از اوراکلهای بلاک چین {#use-blockchain-oracles}
@@ -411,12 +411,12 @@ contract PriceConsumerV3 {
**مقالات**
- [اوراکل بلاک چین چیست؟](https://chain.link/education/blockchain-oracles) — _چین لینک_
-- [اوراکل بلاک چین چیست؟](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _پاتریک کالینز< /em>
+- [اوراکل بلاک چین چیست؟](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _پاتریک کالینز_
- [اوراکلهای غیرمتمرکز: مروری جامع](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _ژولین تیونارد_
- [اجرای اوراکل بلاک چین در اتریوم](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) - *پدرو کاستا*
- [چرا قراردادهای هوشمند نمیتوانند تماسهای API برقرار کنند؟](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
-- [چرا به اوراکلهای غیرمتمرکز نیاز داریم](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) — _Bankless< /em>
-- [پس میخواهید از اوراکل قیمت استفاده کنید](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
+- [چرا به اوراکلهای غیرمتمرکز نیاز داریم](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) — _Bankless_
+- [پس میخواهید از اوراکل قیمت استفاده کنید](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
**ویدیوها**
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md b/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md
index 3e0b74870d6..a42b316dd62 100644
--- a/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md
+++ b/public/content/translations/fa/developers/docs/smart-contracts/composability/index.md
@@ -7,7 +7,7 @@ incomplete: true
## معرفی مختصر {#a-brief-introduction}
-قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. برای تبدیل شدن به یک توسعه دهنده dapp نیازی به نوشتن قرارداد هوشمند خود ندارید، فقط باید بدانید که چگونه با آنها تعامل داشته باشید. برای مثال، میتوانید از قراردادهای هوشمند موجود در [Uniswap](https://uniswap.exchange/swap)، یک صرافی غیرمتمرکز، برای مدیریت همه منطق مبادله توکن ها در برنامه خود استفاده کنید - لازم نیست از صفر شروع کنید. برخی از قراردادهای [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) و v3 را بررسی کنید.
+قراردادهای هوشمند در اتریوم عمومی هستند و می توان آنها را به عنوان APIهای باز در نظر گرفت. برای تبدیل شدن به یک توسعه دهنده dapp نیازی به نوشتن قرارداد هوشمند خود ندارید، فقط باید بدانید که چگونه با آنها تعامل داشته باشید. برای مثال، میتوانید از قراردادهای هوشمند موجود در [Uniswap](https://uniswap.exchange/swap)، یک صرافی غیرمتمرکز، برای مدیریت همه منطق مبادله توکن ها در برنامه خود استفاده کنید - لازم نیست از صفر شروع کنید. برخی از قراردادهای [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) و v3 را بررسی کنید.
## ترکیبپذیری چیست؟ {#what-is-composability}
@@ -29,7 +29,7 @@ incomplete: true
### چرخه توسعه کوتاه تر {#shorter-development-cycle}
-در زمان تولید [اپلیکیشن های غیرمتمرکز](/dapps/#what-are-dapps) (یا dapp ها) ترکیب پذیری می تواند باعث کاهش حجم کار توسعه دهنده های نرمافزار شود. [همانطور که Naval Ravikant می گوید: ](https://twitter.com/naval/status/1444366754650656770) "متن باز یعنی هر مشکلی فقط باید یکبار حل شود."
+در زمان تولید [اپلیکیشن های غیرمتمرکز](/dapps/#what-are-dapps) (یا dapp ها) ترکیب پذیری می تواند باعث کاهش حجم کار توسعه دهنده های نرمافزار شود. [همانطور که Naval Ravikant می گوید:](https://twitter.com/naval/status/1444366754650656770) "متن باز یعنی هر مشکلی فقط باید یکبار حل شود."
اگر یک قرارداد هوشمند میتواند یک مشکل را حل کند، سایر توسعه دهنده ها می توانند از آن استفاده کنند و نیازی نیست که یک مشکل یکسان را دوباره حل کنند. بدین ترتیب توسعه دهنده ها میتوانند با استفاده از کتابخانه های موجود و اضافه کردن قابلیت های اضافی به آنها، اپلیکیشن های غیر متمرکز جدیدی را بسازند.
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md
index ac046a229b2..767205b82f2 100644
--- a/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md
+++ b/public/content/translations/fa/developers/docs/smart-contracts/formal-verification/index.md
@@ -161,7 +161,7 @@ function safe_add(uint x, uint y) returns(uint z){
#### نیاز به قابلیت اطمینان {#need-for-reliability}
راستیآزمایی رسمی برای ارزیابی درستی سیستمهای حیاتی ایمنی استفاده میشود که خرابی آنها میتواند عواقب مخربی مانند مرگ، جراحت یا خرابی مالی داشته باشد. قراردادهای هوشمند، برنامههای کاربردی با ارزشی هستند که مقادیر زیادی از ارزش را کنترل میکنند و خطاهای ساده در طراحی میتواند منجر به
-خسارت جبرانناپذیر برای کاربران شود. با این حال، تأیید رسمی یک قرارداد قبل از استقرار، میتواند تضمینهایی را افزایش دهد که پس از اجرا بر روی بلاکچین، مطابق انتظار عمل میکند.
+خسارت جبرانناپذیر برای کاربران شود. با این حال، تأیید رسمی یک قرارداد قبل از استقرار، میتواند تضمینهایی را افزایش دهد که پس از اجرا بر روی بلاکچین، مطابق انتظار عمل میکند.
قابلیت اطمینان یک کیفیت بسیار مطلوب در هر قرارداد هوشمند است، به خصوص به این دلیل که کد مستقر شده در ماشین مجازی اتریوم (EVM) معمولاً تغییرناپذیر است. از آنجایی که بروزرسانیهای پس از راهاندازی به راحتی قابل دسترسی نیستند، نیاز به تضمین قابلیت اطمینان قراردادها تأیید رسمی را ضروری میکند. راستیآزمایی رسمی میتواند مسائل پیچیدهای مانند سرریز و سرریز اعداد صحیح، ورود مجدد و بهینهسازی ضعیف گاز را شناسایی کند که ممکن است از دست حسابرسان و آزمایشکنندگان خارج شود.
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md b/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md
index beb008abc76..3349ec8baa1 100644
--- a/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md
+++ b/public/content/translations/fa/developers/docs/smart-contracts/testing/index.md
@@ -5,7 +5,7 @@ lang: fa
---
بلاک چین های عمومی مانند اتریوم تغییر ناپذیر هستند و تغییر کد قراردادهای هوشمند پس از استقرار را دشوار می کند. الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر این، یک ارتقا فقط میتواند یک خطا را پس از کشف آن برطرف کند - اگر مهاجم ابتدا آسیبپذیری را کشف کند، قرارداد هوشمند شما در معرض خطر سوء استفاده قرار میگیرد.
-الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر آن، بروزرسانی، فقط میتواند خطا را_پس از _ کشف شدن آن تصحیح کند - اگر یک مهاجم، زودتر از تصحیح آن خطا، خطا را پیدا کند، قرارداد هوشمند مربوطه در معرض سوء استفاده واقع میشود.
+الگوهای ارتقای قرارداد برای انجام "ارتقای مجازی" وجود دارد، اما اجرای آنها دشوار است و نیاز به اجماع اجتماعی دارد. علاوه بر آن، بروزرسانی، فقط میتواند خطا را_پس از _ کشف شدن آن تصحیح کند - اگر یک مهاجم، زودتر از تصحیح آن خطا، خطا را پیدا کند، قرارداد هوشمند مربوطه در معرض سوء استفاده واقع میشود.
به همین علت است که تست کردن قراردادهای هوشمند پیش از [دیپلوی](/developers/docs/smart-contracts/deploying/) بر روی شبکه اصلی، به عنوان حداقل میزان رعایت [ایمنی](/developers/docs/smart-contracts/security/) تلقی می شود. برای تست و ارزیابی میزان صحت کدهای قراردادهای هوشمند، تکنیک های مختلفی وجود دارد؛ این که انتخاب شما کدام تکنیک و به چه صورت باشد به نیازمندی و خواست خود شما بر میگردد. ضمناً، مجموعه های تستی که متشکل از ابزارها و نگرش های مختلف باشند به عنوان گزینه ای ایدهآل برای کشف و عیب یابی نواقص امنیتی کم اهمیت و پر اهمیت در کد کانترکت می باشند.
@@ -75,7 +75,7 @@ lang: fa
##### 1. منطق تجاری و گردش کار قراردادهای خود را درک کنید
-قبل از نوشتن تستهای واحد، دانستن اینکه یک قرارداد هوشمند چه ویژگیهایی را ارائه میدهد و کاربران چگونه به آن عملکردها دسترسی خواهند داشت و از آنها استفاده میکنند، کمک میکند. این مورد به ویژه برای اجرای [تستهای مسیر درست](https://en.m.wikipedia.org/wiki/Happy_path) مفید است که تعیین میکند آیا توابع در قرارداد، خروجی صحیح را برای ورودیهای معتبر کاربر برمیگردانند یا خیر. ما این مفهوم را با استفاده از این مثال (مختلف) از [یک قرارداد مزایده](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple- توضیح خواهیم داد. open-auction)
+قبل از نوشتن تستهای واحد، دانستن اینکه یک قرارداد هوشمند چه ویژگیهایی را ارائه میدهد و کاربران چگونه به آن عملکردها دسترسی خواهند داشت و از آنها استفاده میکنند، کمک میکند. این مورد به ویژه برای اجرای [تستهای مسیر درست](https://en.m.wikipedia.org/wiki/Happy_path) مفید است که تعیین میکند آیا توابع در قرارداد، خروجی صحیح را برای ورودیهای معتبر کاربر برمیگردانند یا خیر. ما این مفهوم را با استفاده از این مثال (مختلف) از [یک قرارداد مزایده](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) توضیح خواهیم داد.
@@ -152,7 +152,7 @@ function auctionEnd() external {
- کاربرانی که موفق به برنده شدن در مناقصه نشوند با وجوه خود اعتبار داده میشوند
-**نکته**: روش دیگری برای تست مفروضات، نوشتن تستهایی است که [مادیفایر یا اصلاحکننده تابع](https://docs.soliditylang.org/en/v0.8.16/contracts را راهاندازی میکنند. html#function-modifiers) در یک قرارداد، به خصوص عبارتهای `require`، `assert` و `if…else`.
+**نکته**: روش دیگری برای تست مفروضات، نوشتن تستهایی است که [مادیفایر یا اصلاحکننده تابع](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) را راهاندازی میکنند در یک قرارداد، به خصوص عبارتهای `require`، `assert` و `if…else`.
@@ -182,7 +182,7 @@ function auctionEnd() external {
در حالی که تست واحد عملکردهای قرارداد را به صورت مجزا اشکال زدایی میکند، تستهای یکپارچهسازی اجزای یک قرارداد هوشمند را به عنوان یک کل ارزیابی میکنند. تست یکپارچه سازی میتواند مشکلات ناشی از فراخوانیهای قراردادی متقابل یا تعامل بین عملکردهای مختلف در یک قرارداد هوشمند را شناسایی کند. به عنوان مثال، تستهای یکپارچهسازی میتوانند به بررسی اینکه آیا مواردی مانند [ارثبری](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) و وابستگی به درستی کار میکنند یا خیر کمک میکند.
-تست یکپارچهسازی در صورتی مفید است که قرارداد شما در طول اجرا از معماری مدولار استفاده کند یا با سایر قراردادهای زنجیرهای ارتباط برقرار کند. یکی از راههای اجرای تستهای یکپارچهسازی این است که [بلاک چین](/glossary/#fork) را در یک ارتفاع خاص (با استفاده از ابزاری مانند [Forge](https://book.getfoundry.sh فورک کنید. /forge/fork-testing) یا [هاردهت](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) و تعاملات بین قرارداد شما و قراردادهای مستقر را شبیهسازی کنید.
+تست یکپارچهسازی در صورتی مفید است که قرارداد شما در طول اجرا از معماری مدولار استفاده کند یا با سایر قراردادهای زنجیرهای ارتباط برقرار کند. یکی از راههای اجرای تستهای یکپارچهسازی این است که [بلاک چین](/glossary/#fork) را در یک ارتفاع خاص (با استفاده از ابزاری مانند [Forge](https://book.getfoundry.sh/forge/fork-testing) فورک کنید. یا [هاردهت](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) و تعاملات بین قرارداد شما و قراردادهای مستقر را شبیهسازی کنید.
بلاک چین فورک شده مشابه شبکه اصلی رفتار خواهد کرد و دارای حسابهایی با وضعیتها و موجودیهای مرتبط است. اما فقط به عنوان یک محیط توسعه محلی سندباکس شده عمل میکند، به این معنی که برای تراکنشها به ETH واقعی نیاز نخواهید داشت، همچنین تغییرات شما بر پروتکل واقعی اتریوم تأثیر نمیگذارد.
@@ -200,7 +200,7 @@ function auctionEnd() external {
یک آنالایزر استاتیک کد منبع یک قرارداد هوشمند را به عنوان ورودی دریافت کرده و نتایج را با اعلام اینکه آیا قرارداد یک ویژگی را برآورده میکند یا نه، خروجی میگیرد. بر خلاف تحلیل پویا، تحلیل استاتیک شامل اجرای قرارداد برای تجزیه و تحلیل آن برای صحت نیست. تجزیه و تحلیل استاتیک در عوض درباره تمام مسیرهای احتمالی که یک قرارداد هوشمند میتواند در طول اجرا طی کند (به عنوان مثال، با بررسی ساختار کد منبع برای تعیین معنای آن برای عملیات قراردادها در زمان اجرا) استدلال میکند.
-[Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) و [تست استاتیک](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) روشهای رایج برای اجرای تحلیل استاتیک در قراردادها هستند. هر دو نیازمند تجزیه و تحلیل نمایشهای سطح پایین اجرای قرارداد هستند، مانند [درخت نحو انتزاعی](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) و [کنترل نمودارهای جریان](https: //www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) خروجی توسط کامپایلر.
+[Linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) و [تست استاتیک](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) روشهای رایج برای اجرای تحلیل استاتیک در قراردادها هستند. هر دو نیازمند تجزیه و تحلیل نمایشهای سطح پایین اجرای قرارداد هستند، مانند [درخت نحو انتزاعی](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) و [کنترل نمودارهای جریان](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) خروجی توسط کامپایلر.
در بیشتر موارد، تجزیه و تحلیل استاتیک برای تشخیص مسائل ایمنی مانند استفاده از ساختارهای ناامن، خطاهای نحوی یا نقض استانداردهای کدگذاری در کد قرارداد مفید است. با این حال، آنالایزرهای استاتیک به طور کلی در تشخیص آسیبپذیریهای عمیقتر نامطلوب هستند و ممکن است مثبت کاذب بیش از حد تولید کنند.
@@ -287,7 +287,7 @@ function auctionEnd() external {
همانطور که ذکر شد، تست دقیق به ندرت میتواند عدم وجود اشکال یا باگ در قرارداد را تضمین کند. رویکردهای تأیید رسمی میتوانند تضمینهای قویتری از صحت ارائه دهند، اما در حال حاضر استفاده از آنها دشوار است و هزینههای قابل توجهی را متحمل میشود.
-با این وجود، میتوانید با بررسی کد مستقل، امکان شناسایی آسیبپذیریهای قرارداد را بیشتر کنید. [ممیزی یا آدیت قراردادهای هوشمند](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) و [پاداشهای باگ](https://medium. com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) دو راه برای ترغیب دیگران به تجزیه و تحلیل قراردادهای شما هستند.
+با این وجود، میتوانید با بررسی کد مستقل، امکان شناسایی آسیبپذیریهای قرارداد را بیشتر کنید. [ممیزی یا آدیت قراردادهای هوشمند](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) و [پاداشهای باگ](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) دو راه برای ترغیب دیگران به تجزیه و تحلیل قراردادهای شما هستند.
ممیزیها توسط حسابرسان با تجربه در یافتن موارد نقص امنیتی و شیوههای توسعه ضعیف در قراردادهای هوشمند انجام میشود. ممیزی معمولاً شامل تست (و احتمالاً تأیید رسمی) و همچنین بررسی دستی کل پایگاه کد است.
@@ -335,7 +335,7 @@ function auctionEnd() external {
- **[سایفرین آدرین](https://cyfrin.io/tools/aderyn)** - _تحلیلگر استاتیک مبتنی بر استاتیک که به طور خاص برای امنیت و توسعه قراردادهای هوشمند وب3 طراحی شده است._
-- **[ویک](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - < em x-id="4">چارچوب تحلیل استاتیک مبتنی بر پایتون با آشکارسازهای آسیبپذیری و کیفیت کد، چاپگرهایی برای استخراج اطلاعات مفید از کد و پشتیبانی برای نوشتن زیرماژولهای سفارشی.
+- **[ویک](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _چارچوب تحلیل استاتیک مبتنی بر پایتون با آشکارسازهای آسیبپذیری و کیفیت کد، چاپگرهایی برای استخراج اطلاعات مفید از کد و پشتیبانی برای نوشتن زیرماژولهای سفارشی._
@@ -347,9 +347,9 @@ function auctionEnd() external {
- **[مانتیکر](https://manticore.readthedocs.io/en/latest/index.html)** - _فریم ورک اجرای نمادین پویا برای تجزیه و تحلیل بایت کد ماشین مجازی اتریوم است._
-- **[میثریل (Mythril)](https://github.com/ConsenSys/mythril-classic)** - _ ابزار ارزیابی بایت کد ماشین مجازی اتریوم برای شناسایی آسیبپذیریهای قرارداد با استفاده از تجزیه و تحلیل تینت، تجزیه و تحلیل کونکولیک، و بررسی جریان کنترل است._
+- **[میثریل (Mythril)](https://github.com/ConsenSys/mythril-classic)** - _ابزار ارزیابی بایت کد ماشین مجازی اتریوم برای شناسایی آسیبپذیریهای قرارداد با استفاده از تجزیه و تحلیل تینت، تجزیه و تحلیل کونکولیک، و بررسی جریان کنترل است._
-- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _ Scribble یک زبان مشخصات و ابزار تأیید زمان اجرا است که به شما امکان میدهد قراردادهای هوشمند را با ویژگیهایی حاشیه نویسی کنید که به شما امکان میدهد به طور خودکار قراردادها را با ابزارهایی مانند Diligence Fuzzing یا MythX تست کنید._
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble یک زبان مشخصات و ابزار تأیید زمان اجرا است که به شما امکان میدهد قراردادهای هوشمند را با ویژگیهایی حاشیه نویسی کنید که به شما امکان میدهد به طور خودکار قراردادها را با ابزارهایی مانند Diligence Fuzzing یا MythX تست کنید._
diff --git a/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md
index b88037cb5e7..1e4ce2c62c1 100644
--- a/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md
+++ b/public/content/translations/fa/developers/docs/smart-contracts/verifying/index.md
@@ -64,7 +64,7 @@ lang: fa
توجه داشته باشید که در اینجا توضیح ساده ای از تائید کردن را به میان آورده ایم، و در این پروسه استثناهای بسیاری وجود دارند که ممکن است توضیحات متفاوتی با آنچه که در حال صحبت در اینجا هستیم داشته باشند، مثلاً در زمانی که
-متغیرهای از نوع immutable" داشته باشیم.
+متغیرهای از نوع immutable" داشته باشیم.
@@ -80,7 +80,7 @@ lang: fa
اتراسکن اجازه کامپایل مجدد بایتکد قرارداد از پی لود داده اصلی (کد، آدرس کتابخانه، تنظیمات کامپایلر، آدرس قرارداد، و ...) را به شما می دهد در صورتی که بایتکد مجدد کامپایل شده، با بایتکد (و پارامترهای کانستراکتور) قراردادی بر روی بلاکچین (آن-چین) منطبق باشد، سپس [قرارداد وریفای می شود](https://info.etherscan.com/types-of-contract-verification/).
-هنگامی که قرارداد وریفای شود، کد قرارداد شما برچسب "verified" دریافت کرده و به منظور حسابرسی و آدیت شدن سایرین، بر روی اتراسکن منتشر می شود. همچنین به قسمت قراردادهای وریفای شده0> یا همان verified contracts -که مخزنی از قراردادهای هوشمند با کدهای وریفای شده است- اضافه می شود.
+هنگامی که قرارداد وریفای شود، کد قرارداد شما برچسب "verified" دریافت کرده و به منظور حسابرسی و آدیت شدن سایرین، بر روی اتراسکن منتشر می شود. همچنین به قسمت قراردادهای وریفای شده یا همان verified contracts -که مخزنی از قراردادهای هوشمند با کدهای وریفای شده است- اضافه می شود.
اتر اسکن، پر استفاده ترین ابزار وریفای و تائید قراردادهای هوشمند است. هرچند، سرویس وریفای قراردادهای اتراسکن نواقصی نیز دارد: از جمله این نواقص می توان به ناتوانی در مقایسه **هش متادیتا**ی بایتکد آن-چین و بایتکد مجدد کامپایل شده اشاره کرد. بنابراین می توان گفت که تطابقهای اتراسکن از نوع تطابق جزئی است.
diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md
index 5bfacb62270..ff0172e93a7 100644
--- a/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md
+++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md
@@ -20,10 +20,10 @@ ERC-223 به یک سری از محدودیتهای استاندارد ERC-20
## پیش نیازها {#prerequisites}
-- [حسابها](/توسعهدهندهها/اسناد/حساب)
-- [قراردادهای هوشمند](/توسعهدهندهها/اسناد/قراردادهای هوشمند/)
+- [حسابها](/developers/docs/accounts)
+- [قراردادهای هوشمند](/developers/docs/smart-contracts/)
- [Token standards](/developers/docs/standards/tokens/)
-- [ERC-20](/توسعهدهندهها/اسناد/استانداردها/توکنها/erc-20/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
## ساختار{#body}
diff --git a/public/content/translations/fa/developers/docs/transactions/index.md b/public/content/translations/fa/developers/docs/transactions/index.md
index 0430b80cc8b..ed15c6551fa 100644
--- a/public/content/translations/fa/developers/docs/transactions/index.md
+++ b/public/content/translations/fa/developers/docs/transactions/index.md
@@ -125,9 +125,7 @@ lang: fa
با توجه به مشخصات ABI، مقادیر صحیح (مانند آدرسها که اعداد صحیح 20 بایتی هستند) در ABI به صورت کلمات 32 بایتی ظاهر میشوند که ممکن است یک یا چند صفر در ابتدای آنها قرار داده شود. بنابراین ما میدانیم که آدرس `«to»`
`4f6742badb049791cd9a302791cd9a302791cd99a32791cd99a310.com است.
-مقدار` 0x3b0559f4 = 990206452 است.
-
-
+مقدار` 0x3b0559f4 = 990206452 است.
## انواع تراکنشها {#types-of-transactions}
@@ -137,23 +135,18 @@ lang: fa
- تراکنشهای استقرار قرارداد: تراکنش بدون آدرس «to»، که در آن از فیلد دادهها برای کد قرارداد استفاده میشود.
- اجرای قرارداد: تراکنشی که با یک قرارداد هوشمند مستقر تعامل دارد. در این مورد، آدرس «to»، آدرس قرارداد هوشمند است.
-
-
### دربارهی گاز {#on-gas}
همانطور که گفته شد، انجام تراکنشها [گاز](/developers/docs/gas/) مصرف میکند. تراکنشهای انتقال ساده به 21000 واحد گاز نیاز دارند.
بنابراین برای اینکه باب 1 اتر را به آلیس با `baseFeePerGas` به میزان 190 gwei و `maxPriorityFeePerGas` به میزان 10 gwei ارسال کند، باب باید هزینهی زیر را بپردازد:
-
-
```
(190 + 10) * 21000 = 4,200,000 gwei
--یا--
0.0042 اتر
```
-
مقدار **1.0042 اتر** از حساب باب کسر خواهد شد (1 اتر برای آلیس + 0.0042 اتر برای هزینه گاز)
به حساب آلیس **1.0+ اتر** بستانکار خواهد شد
@@ -166,8 +159,6 @@ lang: fa
هر گازی که در تراکنش استفاده نشده باشد به حساب کاربری مسترد میشود.
-
-
### تعاملات قرارداد هوشمند {#smart-contract-interactions}
گاز برای هر تراکنشی که شامل یک قرارداد هوشمند است، لازم است.
@@ -176,8 +167,6 @@ lang: fa
برخلاف زمانی که با استفاده از `eth_call` قابل دسترسی است، این توابع `نما` یا `خالص` معمولاً به صورت داخلی نیز فراخوانده می شوند (یعنی از خود قرارداد یا از قرارداد دیگری) که کارمزد گس را به همراه دارد.
-
-
## چرخهی حیات تراکنش {#transaction-lifecycle}
هنگامی که تراکنش ارسال شد، موارد زیر اتفاق میافتد:
@@ -189,16 +178,12 @@ lang: fa
3. به منظور تایید و "موفقیت آمیز" در نظر گرفته شدن تراکنش شما، یک اعتبارسنج باید تراکنش شما را انتخاب کرده و داخل یک بلوک قرار دهد.
4. با گذر زمان بلوکی که حامل تراکنش شما است به وضعیت "مشروع" و سپس "نهایی" برروز رسانی می شود. این ارتقاها موجب می شوند که کاملا مطمئن شوید که تراکنش شما موفقیت آمیز بوده و هرگز تغییر نخواهد کرد. زمانی که یک بلوک "نهایی" شد فقط تنها زمانی که مورد یک حمله در حد و سطح شبکه قرار بگیرد می تواند تغییر یابد که چندین میلیارد دلار هزینه به بار خواهد آورد.
-
-
## یک نسخهی آزمایشی تصویری {#a-visual-demo}
آستین را تماشا کنید که شما را دربارهی تراکنشها، گاز و استخراج راهنمایی میکند.
-
-
## پاکت تراکنش تایپشده {#typed-transaction-envelope}
اتریوم در ابتدا یک قالب برای تراکنشها داشت. هر تراکنش حاوی نانس (nonce)، قیمت گاز، حد گاز، آدرس گیرنده، مقدار، داده، v، r و s بود. این فیلد ها [کدگذاری شده RLP](/developers/docs/data-structures-and-encoding/rlp/) هستند، تا چیزی شبیه این به نظر برسند:
@@ -224,18 +209,12 @@ lang: fa
3. **تراکنشهای نوع 2** که معمولاً به تراکنشهای EIP-1559 گفته میشوند، تراکنشهایی هستند که در [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)، در [بهروزرسانی لندن](/history/#london) اتریوم معرفی شدهاند. آنها به مدل تراکنش استاندارد در شبکه اتریوم تبدیل شدهاند. این تراکنشها یک مکانیزم جدید بازار کارمزد را معرفی میکنند که با تفکیک کارمزد معامله به کارمزد پایه و کارمزد اولویت، قابلیت پیشبینی را بهبود میبخشد. آنها با بایت `0x02` شروع می شوند و شامل فیلدهایی مانند `maxPriorityFeePerGas` و `maxFeePerGas` میشوند. تراکنشهای نوع 2 اکنون به دلیل انعطافپذیری و کارایی، پیشفرض هستند، بهویژه در دورههای شلوغی بالای شبکه به دلیل توانایی آنها در کمک به کاربران در مدیریت قابل پیشبینیتر کارمزد تراکنشها مورد توجه قرار میگیرند. مقدار TransactionType برای این تراکنش ها `0x2` است.
-
-
-
-
## بیشتر بخوانید {#further-reading}
- [EIP-2718: پاکت تراکنش تایپشده](https://eips.ethereum.org/EIPS/eip-2718)
_آیا منبعی اجتماعی میشناسید که به شما کمک کرده باشد؟ این صفحه را ویرایش کنید و به آن اضافه کنید!_
-
-
## موضوعات مرتبط {#related-topics}
- [حسابها](/developers/docs/accounts/)
diff --git a/public/content/translations/fa/energy-consumption/index.md b/public/content/translations/fa/energy-consumption/index.md
index 01ba4a77081..694722162fa 100644
--- a/public/content/translations/fa/energy-consumption/index.md
+++ b/public/content/translations/fa/energy-consumption/index.md
@@ -37,7 +37,7 @@ lang: fa
جدول و نمودار بالا فوق همچنین شامل مقایسه های بیت کوین و اتریوم اثبات کار است. توجه به این نکته ضروری است که مصرف انرژی شبکههای اثبات کار ثابت نیست و روز به روز تغییر میکند. تخمینها نیز ممکن است بین منابع بهطور گسترده متفاوت باشند. این موضوع نه تنها در مورد میزان انرژی مصرفشده، بلکه در مورد منابع آن انرژی و اصول اخلاقی مرتبط با آن، [مباحثات](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) ظریف را به خود جلب میکند. مصرف انرژی لزوماً دقیقاً به ردپای محیطزیستی مربوط نمیشود زیرا پروژههای مختلف ممکن است از منابع انرژی متفاوت استفاده کنند، از جمله انرژیهای تجدیدپذیر با نسبت کمتر یا بیشتر. برای مثال، [شاخص مصرف برق بیتکوین دانشگاه کمبریج](https://ccaf.io/cbnsi/cbeci/comparisons) یعنی شاخص Cbeci نشان میدهد که تقاضای شبکه بیتکوین از نظر تئوری میتواند با سوخت گاز یا برق تامین شود که در غیر این صورت در انتقال و توزیع از بین میرود. راه حل اتریوم در مسیر پایداری، جایگزینی بخش نیازمندِ انرژیِ شبکه با یک گزینه سبز بود.
-مصرف انرژی و انتشار کربن برای صنایع مختلف را می توانید در [سایت شاخص پایداری شبکه بلاک چین کمبریج ](https://ccaf.io/cbnsi/ethereum) ببینید.
+مصرف انرژی و انتشار کربن برای صنایع مختلف را می توانید در [سایت شاخص پایداری شبکه بلاک چین کمبریج](https://ccaf.io/cbnsi/ethereum) ببینید.
## تخمینهای قبل از تراکنش {#per-transaction-estimates}
diff --git a/public/content/translations/fa/enterprise/index.md b/public/content/translations/fa/enterprise/index.md
index 23e1f61976a..f2c02abe4e6 100644
--- a/public/content/translations/fa/enterprise/index.md
+++ b/public/content/translations/fa/enterprise/index.md
@@ -14,8 +14,7 @@ lang: fa
- سازمان آنها به طور رقابتی آینده نگر است
در سالهای اولیه، بسیاری از برنامههای بلاک چین سازمانی بر روی زنجیرههای بلاک چین یا کنسرسیوم سازگار با اتریوم با مجوز خصوصی ساخته شدند. امروزه، به لطف پیشرفتهای فناوری که توان عملیاتی بیشتر، هزینه تراکنش کمتر و حفظ حریم خصوصی را ممکن میسازد، اکثر برنامههای کاربردی سازمانی که از فناوری اتریوم استفاده میکنند بر روی شبکه اصلی اتریوم یا روی
-
-زنجیره لایه 2.
+زنجیره لایه 2
@@ -83,7 +82,7 @@ lang: fa
### راه حل های مقیاس پذیری {#scalability-solutions}
-اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/لایه دوم) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
+اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/layer-2) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
@@ -100,8 +99,8 @@ lang: fa
- [اتریوم ادز](https://ethereumads.com/) - _به اپراتورهای وبسایت اجازه میدهد فضای تبلیغاتی را بفروشند و از طریق اتریوم پول دریافت کنند_
- [hCaptcha](https://www.hcaptcha.com/) - _سیستم CAPTCHA پیشگیری از ربات که به اپراتورهای وبسایت برای کارهای انجام شده توسط کاربران برای برچسب زدن دادهها برای یادگیری ماشین پرداخت میکند. اکنون توسط Cloudflare مستقر شده است_
- [Opera MiniPay](https://www.opera.com/products/minipay) - _پرداختهای موبایلی را برای مردم آفریقا از طریق کیف پول غیرسرپرستی در دسترستر و ایمنتر میکند و از شماره تلفنها برای تراکنش آسان_ استفاده میکند
-- [Roxpay ](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
-- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p /13560384) - _پرداختهای بین المللی با استیبل کوین_
+- [Roxpay](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
+- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p/13560384) - _پرداختهای بین المللی با استیبل کوین_
- [Toku](https://www.toku.com/) - _دستمزد، مدیریت کمک هزینه توکنی، رعایت مالیات، استخدام محلی، مزایا و & راهحلهای منابع انسانی توزیع شده_
- [Xerof](https://www.xerof.com/) - _پرداختهای سریع و ارزان بینالمللی (برون مرزی) B2B را تسهیل میکند_
@@ -132,13 +131,11 @@ lang: fa
- [Fasset](https://www.fasset.com/) - _پلتفرمی برای پشتیبانی از زیرساختهای پایدار_
- [نوری](https://nori.com/) - _زیرساخت بازار منبع باز برای امکان اندازهگیری و کسب درآمد از فعالیتهای پروژههای حذف کربن_
- [پراپی (Propy)](https://propy.com/) - _پلتفرمی برای خودکارسازی معاملات املاک مسکونی با قراردادهای هوشمند_
-- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند. _
-- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد em>
-
- - [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات< /em>
-
+- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند._
+- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد
+ - [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات
- [تالو (Thallo)](https://www.thallo.io/) - _پلتفرمی برای ادغام اعتبارات کربن دیجیتال در معاملات تجاری_
-- [Tokenchampions](https://tokenchampions.com/) - _حقوق تصویر بازیکنان فوتبال اروپا را توکنیزه میکند_
+- [Tokenchampions](https://tokenchampions.com/) - _حقوق تصویر بازیکنان فوتبال اروپا را توکنیزه میکند_
@@ -157,7 +154,7 @@ lang: fa
### زنجیره تامین {#supply-chain}
-- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using -ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
+- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using-ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
- [کارگوایکس](https://cargox.io/) - _ارائهدهنده بارنامه الکترونیکی و انتقال اسناد برای حمل و نقل_
- [Circularize](https://www.circularise.com/) - _یک راهحل ردیابی سرتاسر برای مواد خام ساخته شده در محصولات است_
- [مدیر قرارداد EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _شرکتها را قادر میسازد تا در جریان کاری تدارکات، صدور RFQ، قراردادها، سفارشها خرید و فاکتورها در شبکهای از شرکای تجاری شرکت کنند_
@@ -181,12 +178,9 @@ lang: fa
- [BCdiploma](https://www.bcdiploma.com/) - _دیپلمها، گواهیها و مدارک خرد را دیجیتالی و تأیید میکند_
- [مدارک هایلند](https://www.hylandcredentials.com) - _دیپلمهای دیجیتال و سایر مدارک تحصیلی، مجوزها و گواهینامهها_
-- [برنامه اقامت دیجیتال پالائو](https://rns.id/) - _به شهروندان جهانی این امکان را میدهد که کارت شناسایی قانونی صادر شده توسط دولت پالائو داشته باشند em>
-
+- [برنامه اقامت دیجیتال پالائو](https://rns.id/) - _به شهروندان جهانی این امکان را میدهد که کارت شناسایی قانونی صادر شده توسط دولت پالائو داشته باشند_
- [Spherity](https://www.spherity.com/) - _راهحلهای مدیریت هویت دیجیتال را برای ایجاد اعتماد دیجیتال در اکوسیستمها، با تمرکز بر هویتهای غیرمتمرکز و اعتبار قابل تأیید ارائه میدهد_
-- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
-
-
+- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
### سرگرمی، NFT و وفاداری
diff --git a/public/content/translations/fa/roadmap/dencun/index.md b/public/content/translations/fa/roadmap/dencun/index.md
index eaa3d7d4664..6d71ce8ec05 100644
--- a/public/content/translations/fa/roadmap/dencun/index.md
+++ b/public/content/translations/fa/roadmap/dencun/index.md
@@ -34,8 +34,7 @@ Cancun-Deneb (Dencun) یک ارتقاء شبکه اتریوم است که **پر
شبکههای رولآپ پردازش _processing_ (یا "اجرای") تراکنشها را جدا از شبکه اصلی انجام میدهند و سپس یک مدرک رمزنگارشده و/یا داده تراکنش فشرده از نتایج را برای نگهداری سوابق در شبکه اصلی منتشر میکنند. ذخیرهسازی این مدارک هزینهای را به همراه دارد (در قالب [گس]](/glossary/#gas))، که قبل از پروتو-دنکشاردینگ، باید به طور دائم توسط تمام اپراتورهای گره شبکه ذخیره می شد و این کار را به یک کار گران تبدیل می کرد.
معرفی پروتو-دنکشاردینگ در ارتقای Dencun، ذخیرهسازی ارزانتر دادهها را برای این اثباتها اضافه میکند، زیرا تنها اپراتورهای گره را ملزم میکند تا این دادهها را برای حدود 18 روز ذخیره کنند، پس از آن میتوان دادهها را با خیال راحت حذف کرد تا از گسترش نیازمندیهای سختافزاری جلوگیری شود. از آنجا که رولآپها معمولاً یک دوره برداشت 7 روزه دارند، مدل امنیتی آنها تا زمانی که حبابها در لایه 1 برای این مدت در دسترس باشند، تغییر نمیکنند. فرصت هرس 18 روزه یک بافر قابل توجه برای این دوره فراهم می کند.
-
-[اطلاعات بیشتر در مورد مقیاسدهی اتریوم](/نقشه راه/مقیاسپذیری/)
+اطلاعات بیشتر در مورد مقیاسدهی اتریوم
## چگونه دسترسی به داده های قدیمی توده پیدا می شود؟ {#historical-access}
@@ -58,7 +57,7 @@ Cancun-Deneb (Dencun) یک ارتقاء شبکه اتریوم است که **پر
## چگونه این ارتقا به نقشه راه گستردهتر اتریوم کمک میکند؟ {#roadmap-impact}
-پروتو-دنکشاردینگ زمینه را برای اجرای کامل [دنکشاردینگ](/نقشه راه/دنکشاردینگ/) فراهم می کند. دنکشاردینگ برای توزیع ذخیرهسازی داده های رولآپ در میان اپراتورهای گره طراحی شده است، بنابراین هر اپراتور فقط باید بخش کوچکی از کل داده ها را مدیریت کند. این توزیع تعداد تودههای داده در هر بلوک را افزایش میدهد، که برای مقیاسپذیری اتریوم برای مدیریت کاربران و تراکنشهای بیشتر ضروری است.
+پروتو-دنکشاردینگ زمینه را برای اجرای کامل دنکشاردینگ فراهم می کند. دنکشاردینگ برای توزیع ذخیرهسازی داده های رولآپ در میان اپراتورهای گره طراحی شده است، بنابراین هر اپراتور فقط باید بخش کوچکی از کل داده ها را مدیریت کند. این توزیع تعداد تودههای داده در هر بلوک را افزایش میدهد، که برای مقیاسپذیری اتریوم برای مدیریت کاربران و تراکنشهای بیشتر ضروری است.
این مقیاسپذیری برای [پشتیبانی از میلیاردها کاربر در اتریوم] (/نقشه راه/مقیاسپذیری/) با هزینههای مقرون به صرفه و برنامههای پیشرفتهتر، و در عین حال حفظ یک شبکه غیرمتمرکز، بسیار مهم است. بدون این تغییرات، تقاضاهای سخت افزاری برای اپراتورهای گره افزایش می یابد و منجر به نیاز به تجهیزات گرانقیمت فزاینده می شود. این میتواند اپراتورهای کوچکتر را قیمتگذاری کند و منجر به تمرکز کنترل شبکه در میان چند اپراتور بزرگ شود که در تضاد با اصل عدم تمرکز است.
@@ -116,5 +115,5 @@ _آموزش فضای توده با دوموتی — توسط Bankless_
- [اعلامیه شبکه اصلی دنکان](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _وبلاگ بنیاد اتریوم_
- [راهنمای سفر به اتریوم: پروتو-دنکشاردینگ](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _توسط Jon Charbonneau_
- [سؤالات متداول پروتو-دنکشاردینگ](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _توسط ویتالیک بوترین_
-- [شرح عمیق پیشنهاد EIP-4844: هسته ارتقاء کنکان](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core- of-the-cancun-upgrade-de7b13761d2c) - _توسط Ebunker_
+- [شرح عمیق پیشنهاد EIP-4844: هسته ارتقاء کنکان](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c) - _توسط Ebunker_
- [گزارش تمام توسعههای ریشهای شماره 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _توسط تیم بیکو_
diff --git a/public/content/translations/fa/social-networks/index.md b/public/content/translations/fa/social-networks/index.md
index e3352a79d85..68318a38ae2 100644
--- a/public/content/translations/fa/social-networks/index.md
+++ b/public/content/translations/fa/social-networks/index.md
@@ -23,9 +23,9 @@ summaryPoint3: توکن ها و نیفتی ها راه های جدیدی برا
### شبکه های اجتماعی غیرمتمرکز چگونه کار می کنند؟ {#decentralized-social-networks-overview}
-شبکههای اجتماعی غیرمتمرکز دستهای از [ برنامههای کاربردی غیرمتمرکز (dapps) ](/dapps/) هستند که توسط [ قراردادهای هوشمند ](/glossary/#smart-contract) مستقر در بلاک چین پشتیبانی می شوند. کد قرارداد به عنوان پشتیبان این برنامه ها عمل می کند و منطق تجاری آنها را تعریف می کند.
+شبکههای اجتماعی غیرمتمرکز دستهای از [برنامههای کاربردی غیرمتمرکز (dapps)](/dapps/) هستند که توسط [قراردادهای هوشمند](/glossary/#smart-contract) مستقر در بلاک چین پشتیبانی می شوند. کد قرارداد به عنوان پشتیبان این برنامه ها عمل می کند و منطق تجاری آنها را تعریف می کند.
-پلتفرمهای رسانههای اجتماعی سنتی برای ذخیره اطلاعات کاربر، کد برنامه و سایر اشکال داده به پایگاههای داده متکی هستند. ولی این باعث ایجاد نقاط شکست واحد می شود و خطر قابل توجهی را ایجاد می کند. به عنوان مثال، سرورهای فیس بوک در اکتبر 2021 به طرز بدنامی [ برای ساعت ها آفلاین شدند ](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) و کاربران را از پلتفرم قطع کردند.
+پلتفرمهای رسانههای اجتماعی سنتی برای ذخیره اطلاعات کاربر، کد برنامه و سایر اشکال داده به پایگاههای داده متکی هستند. ولی این باعث ایجاد نقاط شکست واحد می شود و خطر قابل توجهی را ایجاد می کند. به عنوان مثال، سرورهای فیس بوک در اکتبر 2021 به طرز بدنامی [برای ساعت ها آفلاین شدند](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) و کاربران را از پلتفرم قطع کردند.
شبکه های اجتماعی غیرمتمرکز در یک [شبکه همتا به همتا (peer-to-peer)](/glossary/#peer-to-peer-network) وجود دارند که شامل هزاران گره (nodes) در سراسر جهان است حتی اگر برخی از گره ها از کار بیفتند، شبکه بدون وقفه اجرا می شود و برنامه ها را در برابر خرابی ها و قطعی ها مقاوم می کند.
@@ -57,7 +57,7 @@ summaryPoint3: توکن ها و نیفتی ها راه های جدیدی برا
[ Mirror](https://mirror.xyz/) یک پلتفرم نوشتاری دارای web3 فعال است که هدف آن غیرمتمرکز بودن و مالکیت کاربر است. کاربران می توانند با اتصال کیف پول خود به صورت رایگان در Mirror بخوانند و بنویسند. کاربران همچنین می توانند نوشته ها را درخواست کرده و همچنین نویسندگان مورد علاقه خود را دنبال کنند.
-پستهای منتشر شده در Mirror بهطور دائم در Arweave، یک پلتفرم ذخیرهسازی غیرمتمرکز، ذخیره میشوند و میتوانند بهعنوان [ توکنهای غیرقابل تعویض قابل جمعآوری (NFT) ](/nft/) به نام Writing NFT ذخیره شوند. نوشتن NFT برای نویسندگان کاملاً رایگان است و جمعآوری آن در [لایه 2](/glossary/#layer-2) اتریوم انجام میشود - که باعث میشود تراکنشها ارزان، سریع و سازگار با محیطزیست باشند.
+پستهای منتشر شده در Mirror بهطور دائم در Arweave، یک پلتفرم ذخیرهسازی غیرمتمرکز، ذخیره میشوند و میتوانند بهعنوان [توکنهای غیرقابل تعویض قابل جمعآوری (NFT)](/nft/) به نام Writing NFT ذخیره شوند. نوشتن NFT برای نویسندگان کاملاً رایگان است و جمعآوری آن در [لایه 2](/glossary/#layer-2) اتریوم انجام میشود - که باعث میشود تراکنشها ارزان، سریع و سازگار با محیطزیست باشند.
### MINDS {#minds}
@@ -80,7 +80,7 @@ summaryPoint3: توکن ها و نیفتی ها راه های جدیدی برا
ردیت دارای[امتیازهای تبلیغشده در انجمن](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) است که توکنهای ERC-20 هستند که کاربران میتوانند آنها را با ارسال محتوای با کیفیت و مشارکت در انجمنهای آنلاین (سابردیتها) کسب کنند. برای دریافت امتیازات و امتیازات انحصاری، میتوانید این توکنها را در یک سابردیت بازخرید کنید. برای این پروژه، ردیت با آربیتروم کار میکند، که یک شبکه [لایه 2](/glossary/#layer-2) است که برای مقیاسبندی تراکنشهای اتریوم طراحی شده است.
-این برنامه در حال حاضر فعال است و زیر ردیت r/CryptoCurrency نسخه Community Points خود را به نام [ "Moons" ](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki) اجرا می کند. طبق توضیحات رسمی، Moons "به پوسترها، نظر دهندگان و ناظران برای مشارکت آنها در subreddit پاداش می دهد." زیرا این توکن ها هستند از آنجایی که این توکن ها روی بلاک چین قرار دارند (کاربران آنها را در کیف پول دریافت می کنند)، مستقل از Reddit هستند و نمی توان آنها را برداشت.
+این برنامه در حال حاضر فعال است و زیر ردیت r/CryptoCurrency نسخه Community Points خود را به نام ["Moons"](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki) اجرا می کند. طبق توضیحات رسمی، Moons "به پوسترها، نظر دهندگان و ناظران برای مشارکت آنها در subreddit پاداش می دهد." زیرا این توکن ها هستند از آنجایی که این توکن ها روی بلاک چین قرار دارند (کاربران آنها را در کیف پول دریافت می کنند)، مستقل از Reddit هستند و نمی توان آنها را برداشت.
علاوه بر استفاده از امتیازات انجمن برای باز کردن قفل ویژگیهای خاص، کاربران میتوانند آنها را با فیات در صرافیها مبادله کنند. همچنین، امتیازات انجمن که یک کاربر در اختیار دارد، تأثیر او را بر فرآیند تصمیمگیری در جامعه تعیین میکند.
diff --git a/public/content/translations/fa/staking/solo/index.md b/public/content/translations/fa/staking/solo/index.md
index fb58f459331..e0f650f4b3e 100644
--- a/public/content/translations/fa/staking/solo/index.md
+++ b/public/content/translations/fa/staking/solo/index.md
@@ -199,9 +199,8 @@ Staking Launchpad یک برنامه منبعباز است که به شما ک
- [مشکل تنوع کلاینت اتریوم](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
- [کمک به تنوع کلاینتها](https://www.attestant.io/posts/helping-client-diversity/) - _جیم مکدونالد 2022_
- [ تنوع کلاینت در لایهی اجماع اتریوم](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_
-- نحوهی خرید سختافزار اعتبارسنج اتریوم - _EthStaker 2022_
-
- - [گامبهگام: نحوهی پیوستن به شبکهی آزمایشی اتریوم 2.0](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) - _ بوتا_
-- [نکات پیشگیری از برخورد شدید Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _راول جردن 2020 _
+- نحوهی خرید سختافزار اعتبارسنج اتریوم - _EthStaker 2022_
+ - [گامبهگام: نحوهی پیوستن به شبکهی آزمایشی اتریوم 2.0](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) - _بوتا_
+- [نکات پیشگیری از برخورد شدید Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _راول جردن 2020_
diff --git a/public/content/translations/fa/whitepaper/index.md b/public/content/translations/fa/whitepaper/index.md
index 42e678b2a6f..f678b445ff0 100644
--- a/public/content/translations/fa/whitepaper/index.md
+++ b/public/content/translations/fa/whitepaper/index.md
@@ -16,11 +16,9 @@ _با وجود عمری چندین ساله، ما این مقاله را حفظ
## یک پلتفرم قرارداد هوشمند و برنامهی غیرمتمرکز نسل بعدی {#a-next-generation-smart-contract-and-decentralized-application-platform}
-توسعه بیت کوین توسط ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب به عنوان یک تحول اساسی درصنعت پول و رمزارز مورد استقبال قرار گرفته است، اولین نمونه یک دارایی دیجیتال که به طور همزمان نه هیچ پشتوانه یا "[ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" دارد و نه هیچ مرجع عرضه متمرکز یا کنترل کننده. با این حال، یکی از بخشهای - شاید مهم تر - تجربه بیت کوین زیربنای فناوری زنجیره بلوکی آن به عنوان ابزاری برای اجماع توزیع شده است، و توجهات به سرعت در حال شروع به تغییر به این جنبه دیگر بیت کوین است. کاربردهای جایگزین رایج فناوری بلاک چین شامل استفاده از دارایی های دیجیتال درون بلاک چین برای نشان دادن ارزهای سفارشی و ابزارهای مالی ("[سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lBEoW2T ویرایش)")، مالکیت یک دستگاه فیزیکی زیربنایی ("[اموال هوشمند](https://en.bitcoin.it/wiki/Smart_Property)")، داراییهای غیرقابل تعویض مانند نامهای دامنه ("[Namecoin](http://namecoin.org)")، و همچنین برنامههای پیچیدهتر شامل داشتن داراییهای دیجیتال که مستقیماً توسط یک قطعه کد کنترل میشوند. اجرای قوانین دلخواه ("[هوشمند قراردادها](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") یا حتی "
-
-سازمان های مستقل غیرمتمرکز" (DAOs). آنچه اتریوم قصدش را دارد فراهمسازی یک زنجیره بلوکی با یک زبان برنامه نویسی توکار تورینگ-کامل تمام عیار است که بتوان از آن برای ساخت "قرارداد" هایی که میتوانند برای کد کردن توابع انتقال وضعیت دلخواه مورد استفاده قرار بگیرند بهره برد، که به کاربرها اجازه ساخت هر کدام از سیستم های پیشتر ذکر شده را و همچنین بسیاری از انواع دیگری که حتی تصورشان را هم هنوز نکرده ایم میدهد، صرفاً با به نوشته در آوردن منطق آن در چند خط کد.
-
+توسعه بیت کوین توسط ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب به عنوان یک تحول اساسی درصنعت پول و رمزارز مورد استقبال قرار گرفته است، اولین نمونه یک دارایی دیجیتال که به طور همزمان نه هیچ پشتوانه یا "[ارزش ذاتی](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" دارد و نه هیچ مرجع عرضه متمرکز یا کنترل کننده. با این حال، یکی از بخشهای - شاید مهم تر - تجربه بیت کوین زیربنای فناوری زنجیره بلوکی آن به عنوان ابزاری برای اجماع توزیع شده است، و توجهات به سرعت در حال شروع به تغییر به این جنبه دیگر بیت کوین است. کاربردهای جایگزین رایج فناوری بلاک چین شامل استفاده از دارایی های دیجیتال درون بلاک چین برای نشان دادن ارزهای سفارشی و ابزارهای مالی "[سکه های رنگی](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lBEoW2T) ویرایش"، مالکیت یک دستگاه فیزیکی زیربنایی ("[اموال هوشمند](https://en.bitcoin.it/wiki/Smart_Property)")، داراییهای غیرقابل تعویض مانند نامهای دامنه ("[Namecoin](http://namecoin.org)")، و همچنین برنامههای پیچیدهتر شامل داشتن داراییهای دیجیتال که مستقیماً توسط یک قطعه کد کنترل میشوند. اجرای قوانین دلخواه ("[هوشمند قراردادها](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") یا حتی "
+سازمان های مستقل غیرمتمرکز مبتنی بر بلاک چین (DAOs). آنچه اتریوم قصدش را دارد فراهمسازی یک زنجیره بلوکی با یک زبان برنامه نویسی توکار تورینگ-کامل تمام عیار است که بتوان از آن برای ساخت "قرارداد" هایی که میتوانند برای کد کردن توابع انتقال وضعیت دلخواه مورد استفاده قرار بگیرند بهره برد، که به کاربرها اجازه ساخت هر کدام از سیستم های پیشتر ذکر شده را و همچنین بسیاری از انواع دیگری که حتی تصورشان را هم هنوز نکرده ایم میدهد، صرفاً با به نوشته در آوردن منطق آن در چند خط کد.
## مقدمه ای بر بیت کوین و مفاهیم موجود {#introduction-to-bitcoin-and-existing-concepts}
@@ -105,8 +103,7 @@ APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
2. بررسی کنید که مُهر زمانی بلوک بزرگتر از بلوک قبلی باشد[fn2](#notes) و کمتر از 2 ساعت در آینده باشد
3. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
4. حالت `S[0]` را حالت پایانی بلوک قبل بگذار.
-5. فرض کن `TX` لیست تراکنشهای بلوک با تعداد `n` تراکنش است. برای همه `i` در `0...n-1`، `S[i+1] = APPLY(S[i], TX[i]) را تنظیم کنید /code> اگر هر برنامه ای خطا را برمیگرداند، از آن خارج شوید و false را برگردانید.
-True را برگردانید و S[n]` را به عنوان وضعیت در انتهای این بلوک ثبت کنید.
+5. فرض کن `TX` لیست تراکنشهای بلوک با تعداد `n` تراکنش است. برای همه `i` در `0...n-1`، `S[i+1] = APPLY(S[i], TX[i]) را تنظیم کنید /code> اگر هر برنامه ای خطا را برمیگرداند، از آن خارج شوید و false را برگردانید. True را برگردانید و S[n]` را به عنوان وضعیت در انتهای این بلوک ثبت کنید.
در واقع هر تراکنش در بلوک باید یک انتقال حالت معتبر را از حالت قبل از انجام تراکنش به حالت جدید انجام دهد. باید توجه کرد که حالت به هیچ صورتی در بلوک ثبت نمیشود؛ این یک موضوع تماما انتزاعی است برای این که توسط گرههای اعتبارسنج به خاطر سپرده شود و تنها میتوان (به صورت ایمن) با شروع از حالت بلوک پیدایش و حرکت بر روی تراکنشهای هر بلوک، حالت بلوک فعلی را به دست آورد. علاوه بر این، توجه کنید که ترتیبی که استخراجگر تراکنشها را در بلوک ثبت میکند مهم است؛ اگر دو تراکنش آ و ب وجود داشته باشند به طوری که ب یک UTXOی ساختهشده از آ را خرج کند، در این صورت بلوک معتبر است اگر آ قبل از ب ثبت شود و نه برعکس.
@@ -262,7 +259,7 @@ if !self.storage[calldataload(0)]:
### اجرای کد {#code-execution}
-کد در قراردادهای اتریوم به زبان بایت کد مبتنی بر پشته، سطح پایین نوشته می شود که به آن «کد ماشین مجازی اتریوم» یا «کد EVM» گفته می شود. کد شامل یک سری بایت است که هر بایت نشان دهنده یک عملیات است. به طور کلی، اجرای کد یک حلقه بی نهایت است که شامل انجام مکرر عملیات در شمارنده برنامه فعلی (که از صفر شروع می شود) و سپس افزایش شمارنده برنامه به یک اندازه، تا رسیدن به انتهای کد یا یک خطا یا < دستورالعمل 0>STOP
یا `RETURN` شناسایی شد. عملیات به سه نوع فضای ذخیرهسازی دادهها دسترسی دارند:
+کد در قراردادهای اتریوم به زبان بایت کد مبتنی بر پشته، سطح پایین نوشته می شود که به آن «کد ماشین مجازی اتریوم» یا «کد EVM» گفته می شود. کد شامل یک سری بایت است که هر بایت نشان دهنده یک عملیات است. به طور کلی، اجرای کد یک حلقه بی نهایت است که شامل انجام مکرر عملیات در شمارنده برنامه فعلی (که از صفر شروع می شود) و سپس افزایش شمارنده برنامه به یک اندازه، تا رسیدن به انتهای کد یا یک خطا یا < دستورالعمل 0>STOP یا `RETURN` شناسایی شد. عملیات به سه نوع فضای ذخیرهسازی دادهها دسترسی دارند:
- این **پشته**، محفظهای که میتوان آنها را به بیرون فرستاد و مقادیر را به آن منتقل کرد
- **Memory**، یک آرایه بایت بی نهایت قابل گسترش است
From 4e968c7a02a1d58a806a492b801f5e78f4ff65d7 Mon Sep 17 00:00:00 2001
From: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
Date: Wed, 16 Oct 2024 19:54:06 -0700
Subject: [PATCH 4/9] fix: crowdin markdown syntax
---
public/content/translations/fa/about/index.md | 12 +----
.../content/translations/fa/bridges/index.md | 46 ++++++++-----------
public/content/translations/fa/desci/index.md | 2 +-
3 files changed, 21 insertions(+), 39 deletions(-)
diff --git a/public/content/translations/fa/about/index.md b/public/content/translations/fa/about/index.md
index 3302f9c8362..0631920e18b 100644
--- a/public/content/translations/fa/about/index.md
+++ b/public/content/translations/fa/about/index.md
@@ -94,24 +94,18 @@ ethereum.org یک منبع عمومی منبع باز برای جامعه اتر
**چطور است؟** ما همیشه از بازخورد درباره نقشه راه مان قدردانی می کنیم - اگر چیزی وجود دارد که فکر می کنید باید روی آن کار کنیم، لطفاً به ما اطلاع دهید! ما از ایدهها و روابط عمومی هر کس در جامعه استقبال میکنیم.
-**میخواهید مشارکت کنید؟** [درباره مشارکت بیشتر بیاموزید](/contributing/)، [در توییتر با ما تماس بگیرید](https://twitter.com/ethdotorg)، یا به بحثهای جامعه در
-
-سرور دیسکورد ما بپیوندید.
+**میخواهید مشارکت کنید؟** [درباره مشارکت بیشتر بیاموزید](/contributing/)، [در توییتر با ما تماس بگیرید](https://twitter.com/ethdotorg)، یا به بحثهای جامعه در [سرور دیسکورد ما بپیوندید](https://discord.gg/ethereum-org).
## اصول طراحی کنید {#design-principles}
ما از مجموعه ای از [اصول طراحی](/contributing/design-principles/) برای پیشبرد محتوا و تصمیمات طراحی در وبسایت استفاده می کنیم.
-
-
## سیستم طراحی {#design-system}
ما یک [سیستم طراحی](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) ساختیم و منتشر کردیم تا ویژگیها را سریعتر ارسال کنیم و به اعضای انجمن اجازه دهیم در طراحی باز ethereum.org شرکت کنند.
می خواهید شرکت کنید؟[در فیگما](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System) بخش [مشکل گیت هاب](https://github.com/ethereum/ethereum-org-website/issues/6284) را دنبال کنید و به گفتگو در [ کانال دیسکورد ما بپیوندید](https://discord.gg/ethereum-org).
-
-
## راهنمای سبک {#style-guide}
ما [یک راهنمای سبک](/contributing/style-guide/) برای استانداردسازی ابعاد مشخصی از محتوای نوشتاری داریم تا فرایند کار ساده و هموارتر شود.
@@ -120,14 +114,10 @@ ethereum.org یک منبع عمومی منبع باز برای جامعه اتر
ما از بازخورد در مورد اصول طراحی، سیستم طراحی و راهنمای سبکمان استقبال میکنیم. به یاد داشته باشید، ethereum.org برای جامعه و از طرف جامعه است.
-
-
## مجوز {#license}
وب سایت ethereum.org منبع باز است و تحت [مجوز MIT](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) ساخته شده است، مگر اینکه خلاف آن مشخص شده باشد. اطلاعات بیشتر در مورد [شرایط استفاده](/terms-of-use/) از ethereum.org.
-
-
## شغل های موجود {#open-jobs}
اگرچه این وبسایت متن باز است و همه می توانند روی آن کار کنند، تیمی مختص به ethereum.org و پروژه های دیگر وب بنیاد اتریوم داریم.
diff --git a/public/content/translations/fa/bridges/index.md b/public/content/translations/fa/bridges/index.md
index f2616b0be16..58f72124dde 100644
--- a/public/content/translations/fa/bridges/index.md
+++ b/public/content/translations/fa/bridges/index.md
@@ -77,16 +77,14 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
به طور مشخص می توان گفت که در پلهایی که نیاز به اعتماد می باشد شما به پلتفرم مورد نظر اعتماد می کنید در حالی که در پلهای بدون اعتماد با حداقل اعتماد کردن و صرفا با فرض درست بودن دامنه های زیر ساخت کار انجام می شود. این اصطلاحات در زیر توضیح داده شده است:
-- بدون اعتماد**: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط آرجون بوپتانی در این مقاله
- توضیح داده شده است
-
- - در مدل دارای اعتماد:** با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
-
- برای این که تفاوت های اساسی بین دو روش بهتر جا بیفتد یک مثال ارائه می شود:
-
- فرض کنید شما داخل گیت امنیتی فرودگاه هستید. دو روش برای گیت کنترل وجود دارد:
-
- 1. روش دستی - که تمام جزئیات بلیت و کارت شناسایی توسط افسران مربوطه قبل از دادن کارت پرواز انجام می شود.
+- **بدون اعتماد**: داشتن امنیت معادل با دامنه های زیر ساخت. که توسط [آرجون بوپتانی در این مقاله](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17) توضیح داده شده است
+- در **مدل دارای اعتماد:** با افزودن تاییدکنندههای بیرونی، میزان امنیت از سطح زیرساخت خارج میشود که این کار باعث کاهش امنیت اقتصادی رمز ارز می شود.
+
+برای این که تفاوت های اساسی بین دو روش بهتر جا بیفتد یک مثال ارائه می شود:
+
+فرض کنید شما داخل گیت امنیتی فرودگاه هستید. دو روش برای گیت کنترل وجود دارد:
+
+1. روش دستی - که تمام جزئیات بلیت و کارت شناسایی توسط افسران مربوطه قبل از دادن کارت پرواز انجام می شود.
2. کنترل توسط خودتان - با دستگاه انجام می شود که در آن اطلاعات پروازتان را وارد میکنید و اگر همه چیز درست باشد، کارت پرواز را دریافت میکنید.
یک پست بازرسی دستی، شبیه یک مدل مورد اعتماد است زیرا برای عملیات خود به شخص ثالث یعنی مقامات رسمی وابسته است. به عنوان کاربر به مراکز معتبر اعتماد می کنید تا تصمیم درست را بگیرند و از اطلاعات خصوصی شما به درستی استفاده کنند.
@@ -97,25 +95,21 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
-
-
## خطر استفاده از پلها {#bridge-risk}
پلها در مرحله ابتدایی توسعه می باشند. به عبارتی طراحی بهینه پلها هنوز به صورت کامل کشف نشده است. استفاده از هر کدام از پلها خطر مربوط به خود را دارد:
-- خطر قرارداد هوشمند —** وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
-
- - خطر تکنولوژی—** خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
-
- با این حال پلهای نیازمند به اعتماد از آنجا که تصورهای اعتماد را افزایش میدهند، می توانند خطرات مضاعفی را به همراه داشته باشند، مثل:
-
- - خطر سانسور—** کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
-
- - خطر سرپرستی—** کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند
-
- دارایی های کابرها در خطر هستند اگر:
-
- - یک باگ در قرارداد هوشمند باشد
+- **خطر قرارداد هوشمند —** وجود باگ در کد ممکن است باعث از بین رفتن دارایی بشود
+- **خطر تکنولوژی—** خطای نرم افزاری و باگ کد و خطای انسانی و حملات خرابکاری احتمال دارد اقدامات کاربران را مختل کند
+
+با این حال پلهای نیازمند به اعتماد از آنجا که تصورهای اعتماد را افزایش میدهند، می توانند خطرات مضاعفی را به همراه داشته باشند، مثل:
+
+- **خطر سانسور—** کنترل کنندگان پل به صورت تئوریک می توانند کاربران را از انتقال دارایی هایشان در پل منع کنند
+- **خطر سرپرستی—** کنترل کنندگان پل حتی می توانند اقدام به تبانی برای دزدی دارایی های کاربران کنند
+
+دارایی های کابرها در خطر هستند اگر:
+
+- یک باگ در قرارداد هوشمند باشد
- کاربر مرتکب خطا شود
- بلاکچین مورد استفاده هک شود
- اپارتورهای پل در پلهای نیاز به اعتماد صادق نباشند
@@ -127,8 +121,6 @@ _Web3 به راهحلهای مقیاسپذیری اكوسيستم لا
-
-
## بیشتر بخوانید {#further-reading}
- [EIP-5164: اجرای کراسچین](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658)_تاریخ 18 ژوئن 2022 - برندان اسلتاین_
diff --git a/public/content/translations/fa/desci/index.md b/public/content/translations/fa/desci/index.md
index 1605d32e043..6050be4c140 100644
--- a/public/content/translations/fa/desci/index.md
+++ b/public/content/translations/fa/desci/index.md
@@ -110,7 +110,7 @@ Web3 این پتانسیل را دارد که با آزمایش مدلهای
- [Cerebrum DAO : منبع یابی و راه حل های مفید برای سلامت مغز پیشرفته و جلوگیری از عصب تباهی (تخریب نورونی)](https://www.cerebrumdao.com/)
- [CryoDAO: سرمایه گذاری پروژه های بلندپروازانه در حوزه ارز های دیجیتال](https://www.cryodao.org)
-ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط مشی فهرست ما نگاه کنید!
+ما از پیشنهادهایی برای فهرست کردن پروژههای جدید استقبال میکنیم - لطفاً برای شروع به خط [مشی فهرست](/contributing/adding-desci-projects/) ما نگاه کنید!
## بیشتر بخوانید {#further-reading}
From 1f5dd2fbc155e07616d1c9f28bee07bff48d0b6b Mon Sep 17 00:00:00 2001
From: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
Date: Wed, 16 Oct 2024 20:06:01 -0700
Subject: [PATCH 5/9] fix: crowdin markdown syntax
---
.../fa/developers/docs/dapps/index.md | 7 +--
.../patricia-merkle-trie/index.md | 62 +------------------
.../fa/developers/docs/evm/index.md | 4 +-
3 files changed, 4 insertions(+), 69 deletions(-)
diff --git a/public/content/translations/fa/developers/docs/dapps/index.md b/public/content/translations/fa/developers/docs/dapps/index.md
index f50a87f0ab9..7cde444a77a 100644
--- a/public/content/translations/fa/developers/docs/dapps/index.md
+++ b/public/content/translations/fa/developers/docs/dapps/index.md
@@ -58,8 +58,7 @@ lang: fa
- [گیتهاب](https://github.com/paulrberg/create-eth-app)
-**One Click Dapp _- ابزار FOSS برای تولید صفحات فرانت dapp از
-ABI>.
+**One Click Dapp _- ابزار FOSS برای تولید صفحات فرانت dapp از [ABI](/glossary/#abi)._**
- [oneclickdapp.com](https://oneclickdapp.com)
- [گیت هاب](https://github.com/oneclickdapp/oneclickdapp-v1)
@@ -81,8 +80,6 @@ lang: fa
- [اسناد](https://docs.crossmint.com)
- [دیسکورد](https://discord.com/invite/crossmint)
-
-
## بیشتر بخوانید {#further-reading}
- [کاوش در برنامههای غیرمتمرکز](/dapps)
@@ -93,8 +90,6 @@ lang: fa
_میخواهید در مورد منابع جامعه که به شما کمک کرده بدانید؟ این صفحه را ویرایش و اضافه کنید!_
-
-
## موضوعات مرتبط {#related-topics}
- [مقدمه ای بر پشته اتریوم](/developers/docs/ethereum-stack/)
diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
index e42f25eaefa..42a5716204f 100644
--- a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
+++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md
@@ -15,22 +15,16 @@ sidebarDepth: 2
## موارد مورد نیاز {#prerequisites}
-برای درک بهتر این صفحه، داشتن دانش اولیه در مورد [هش](https://en.wikipedia.org/wiki/Hash_function)، [درخت مرکل](https://en.wikipedia.org/wiki/Merkle_tree)، [درخت ها](https://en.wikipedia.org/wiki/Trie) و
-سریال سازی مفید خواهد بود. . این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
-
-
+برای درک بهتر این صفحه، داشتن دانش اولیه در مورد [هش](https://en.wikipedia.org/wiki/Hash_function)، [درخت مرکل](https://en.wikipedia.org/wiki/Merkle_tree)، [درخت ها](https://en.wikipedia.org/wiki/Trie) و [سریال سازی](https://en.wikipedia.org/wiki/Serialization) مفید خواهد بود. این مقاله با توضیح یک [درخت ریشه](https://en.wikipedia.org/wiki/Radix_tree) اصلی آغاز میشود، سپس به تدریج تغییرات لازم برای ساختار داده بهینهتر اتریوم را معرفی میکند.
## درختهای پایه رادیکس {#basic-radix-tries}
در یک درخت پایه رادیکس، هر گره به صورت زیر به نظر می رسد:
-
-
```
[i_0, i_1 ... i_n, value]
```
-
در حالی که `i_0 ... i_n` نمادهای الفبا (اغلب باینری یا هگزا) را نشان می دهد، `مقدار` مقدار پایانی در گره است و مقادیر در ` i_0، i_1 ... i_n` اسلاتها یا `NULL` یا اشارهگر به (در مورد ما، هشهای) گرههای دیگر هستند. این یک ذخیره پایه `(کلید، مقدار)` را تشکیل می دهد.
فرض کنید میخواهید از یک ساختار داده درخت رادیکس برای تداوم سفارش روی مجموعهای از جفتهای مقدار کلیدی استفاده کنید. برای یافتن مقداری که در حال حاضر به کلید `dog` در درخت نگاشت شده است، ابتدا `dog` را به حروف الفبا تبدیل کنید (به `64 6f 67` بدهید) و سپس سعی کنید در درخت پایین بیایید تا مقدار را پیدا کنید. یعنی با جستجوی هش ریشه در یک DB کلید/مقدار مسطح برای یافتن گره ریشه درخت شروع میکنید. این امر، به صورت آرایه ای از کلیدها نشان داده می شود که به گره های دیگر اشاره می کنند. میتوانید از مقدار شاخص `6` به عنوان کلید استفاده کنید و آن را در کلید/مقدار مسطح DB جستجو کنید تا گره را یک سطح پایین بیاورید. سپس index `4` را برای جستجوی مقدار بعدی انتخاب کنید، سپس شاخص `6` را انتخاب کنید و به همین ترتیب، تا زمانی که مسیر را دنبال کردید: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`، شما مقدار گره را جستجو می کنید و نتیجه را نشان میدهید.
@@ -39,8 +33,6 @@ sidebarDepth: 2
عملیات به روز رسانی و حذف برای درختهای radix را می توان به صورت زیر تعریف کرد:
-
-
```
def update(node,path,value):
curnode = db.get(node) if node else [ NULL ] * 17
@@ -72,21 +64,16 @@ sidebarDepth: 2
return hash(newnode)
```
-
درخت ریشه «مرکل» با پیوند دادن گرهها با استفاده از هش رمزنگاری ایجاد شده قطعی ساخته میشود. این آدرس دهی محتوا (در کلید/مقدار DB `key == keccak256(rlp(مقدار))`) تضمین یکپارچگی رمزنگاری داده های ذخیره شده را فراهم می کند. اگر هش ریشه یک درخت داده شده به طور عمومی شناخته شده باشد، هرکسی که به دادههای برگ زیرین دسترسی داشته باشد، میتواند با ارائه هشهای هر گره که مقدار خاصی را به ریشه درخت میپیوندد، اثبات کند که سعی میکند یک مقدار معین را در یک مسیر خاص اضافه میکند.
برای یک مهاجم غیرممکن است که اثباتی برای یک جفت `(مسیر، مقدار)` ارائه دهد که وجود ندارد، زیرا هش ریشه در نهایت بر اساس همه هش های زیر آن است. هر گونه تغییر اساسی، هش ریشه را تغییر می دهد. میتوانید هش را بهعنوان نمایش فشردهای از اطلاعات ساختاری در مورد دادهها در نظر بگیرید، که با محافظت پیشتصویر تابع درهمسازی ایمن شده است.
ما به یک واحد اتمی یک درخت ریشه (مثلاً یک کاراکتر هگز یا عدد باینری 4 بیتی) به عنوان "نیبل" اشاره خواهیم کرد. همانطور که در بالا توضیح داده شد، در حین پیمودن یک مسیر یک نوبت، گرهها میتوانند حداکثر به 16 فرزند اشاره داشته باشند اما یک عنصر `مقدار` را شامل میشوند. بنابراین ما آنها را به صورت آرایه ای به طول 17 نشان می دهیم. ما این آرایه های 17 عنصری را "گره های شاخه ای" می نامیم.
-
-
## درخت مرکل پاتریشیا {#merkle-patricia-trees}
درختهای رادیکس یک محدودیت عمده دارند: ناکارآمد هستند. اگر می خواهید یک پیوند `(مسیر، مقدار)` را در جایی که مسیر، مانند اتریوم، 64 کاراکتر طول دارد (تعداد nibble ها در `bytes32`) ذخیره کنید، به بیش از یک کیلوبایت فضای اضافی برای ذخیره یک سطح در هر کاراکتر نیاز خواهیم داشت، و هر جستجو یا حذف 64 مرحله کامل طول خواهد کشید. درخت پاتریشیا معرفی شده در ادامه این مشکل را حل می کند.
-
-
### بهينه سازی {#optimization}
یک گره در درخت مرکل پاتریشیا یکی از موارد زیر است:
@@ -104,8 +91,6 @@ sidebarDepth: 2
هنگام پیمایش مسیرها در نیبل، ممکن است در نهایت با تعداد فرد نیبل برای پیمایش مواجه شویم، اما به این دلیل که همه داده ها در قالب `بایت` ذخیره می شوند. نمی توان بین، به عنوان مثال، nibble `1` و nibbles `01` تفاوت قائل شد (هر دو باید به عنوان `<01>` ذخیره شوند). برای تعیین طول فرد، مسیر جزئی با یک پرچم پیشوند داده می شود.
-
-
### مشخصات: رمزگذاری فشرده دنباله هگزا با پایان دهنده اختیاری {#specification}
علامت گذاری _طول مسیر جزئی باقیمانده فرد در مقابل زوج_ و _گره برگ در مقابل پسوند_ همانطور که در بالا توضیح داده شد در اولین نوک مسیر جزئی هر گره 2 موردی قرار دارد. آنها به موارد زیر منجر می شوند:
@@ -116,12 +101,9 @@ sidebarDepth: 2
1 0001 | extension odd
2 0010 | terminating (leaf) even
3 0011 | terminating (leaf) odd
-
حتی برای طول مسیر باقیمانده (`0` یا `2`)، یک نوک `0` "padding" دیگر همیشه در پی میآید.
-
-
```
def compact_encode(hexarray):
term = 1 if hexarray[-1] == 16 else 0
@@ -139,11 +121,8 @@ sidebarDepth: 2
return o
```
-
مثال ها:
-
-
```
> [ 1, 2, 3, 4, 5, ...]
'11 23 45'
@@ -155,11 +134,8 @@ sidebarDepth: 2
'3f 1c b8'
```
-
در اینجا کد توسعه یافته برای گرفتن یک گره در درخت مرکل پاتریشیا آمده است:
-
-
```
def get_helper(node,path):
if path == []: return node
@@ -184,17 +160,12 @@ sidebarDepth: 2
return get_helper(node,path2)
```
-
-
-
### درخت نمونه {#example-trie}
فرض کنید ما درختی می خواهیم حاوی چهار جفت مسیر/مقدار `('do', 'verb')`, `('dog', 'puppy')`, `(' doge، «coins»)`، `(«horse»، «stallion»)`.
ابتدا، هم مسیرها و هم مقادیر را به `بایت` تبدیل می کنیم. در زیر، نمایشهای واقعی بایت برای _مسیرها_ با > نشان داده میشوند، اگرچه _مقادیر_ که برای درک آسان تر همچنان به صورت رشتهها`` نشان داده میشوند (آنها نیز در واقع `بایت` خواهند بود):
-
-
```
<64 6f> : 'verb'
<64 6f 67> : 'puppy'
@@ -202,11 +173,8 @@ sidebarDepth: 2
<68 6f 72 73 65> : 'stallion'
```
-
اکنون، ما چنین درختی را با جفتهای کلید/مقدار زیر در DB زیرین میسازیم:
-
-
```
rootHash: [ <16>, hashA ]
hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
@@ -215,13 +183,10 @@ sidebarDepth: 2
hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]
```
-
هنگامی که یک گره در داخل گره دیگری ارجاع داده می شود، آنچه شامل می شود `H(rlp.encode(node))` است، که در آن `H(x) = keccak256(x) اگر len(x) > = 32 else x` و `rlp.encode` تابع رمزگذاری [RLP](/developers/docs/data-structures-and-encoding/rlp) است.
توجه داشته باشید که هنگام بهروزرسانی یک درخت، باید جفت کلید/مقدار `(keccak256(x)، x)` را در یک جدول جستجوی دائمی ذخیره کنید _اگر_ گره تازه ایجاد شده دارای طول >= 32 باشد. با این حال، اگر گره کوتاهتر از آن باشد، نیازی به ذخیره چیزی نیست، زیرا تابع f(x) = x قابل برگشت است.
-
-
## درخت ها در اتریوم {#tries-in-ethereum}
تمام درخت های مرکل در لایه اجرایی اتریوم از درخت مرکل پاتریشیا استفاده میکنند.
@@ -232,20 +197,14 @@ sidebarDepth: 2
2. transactionsRoot
3. receiptsRoot
-
-
### درخت حالت {#state-trie}
یک درخت حالت جهانی وجود دارد و هر بار که کلاینت یک بلوک را پردازش می کند، به روز می شود. در آن، یک `مسیر` همیشه: `keccak256(ethereumAddress)` و یک `مقدار` همیشه: `rlp(ethereumAccount)` است. به طور خاص، `حساب` اتریوم یک آرایه 4 موردی از `[nonce,balance,storageRoot,codeHash]` است. در این مرحله، شایان ذکر است که این `storageRoot` ریشه یکی دیگر از درخت های پاتریشیا است:
-
-
### درخت حافظه {#storage-trie}
درخت Storage جایی است که _همه_ دادههای قرارداد زندگی میکنند. برای هر حساب یک فضای ذخیره سازی جداگانه وجود دارد. برای بازیابی مقادیر در موقعیتهای ذخیرهسازی خاص در یک آدرس معین، آدرس ذخیره، موقعیت عدد صحیح دادههای ذخیرهشده در حافظه و شناسه بلوک مورد نیاز است. سپس میتوان آنها را بهعنوان آرگومان به `eth_getStorageAt` تعریفشده در JSON-RPC API ارسال کرد، بهعنوان مثال: برای بازیابی داده ها در اسلات ذخیره سازی 0 برای آدرس `0x295a70b2de5e3953354a6a8344e616ed314d7251`:
-
-
```
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
@@ -253,20 +212,14 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [
```
-
بازیابی عناصر دیگر در ذخیره سازی کمی بیشتر دخیل است زیرا ابتدا باید موقعیت در درخت حافظه محاسبه شود. موقعیت به عنوان هش `keccak256` آدرس و موقعیت ذخیره سازی محاسبه می شود که هر دو در سمت چپ با صفر تا طول 32 بایت اضافه شده اند. به عنوان مثال، موقعیت داده در شکاف ذخیره سازی 1 برای آدرس `0x391694e7e0b0cce554cb130d723a9d27458f9298` است:
-
-
```
keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))
```
-
در یک کنسول Geth، این می تواند به صورت زیر محاسبه شود:
-
-
```
> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
undefined
@@ -274,28 +227,20 @@ undefined
"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
```
-
بنابراین `مسیر` `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` است. اکنون می توان از آن برای بازیابی داده ها از درخت حافظه مانند قبل استفاده کرد:
-
-
```
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
```
-
توجه: `storageRoot` برای یک حساب اتریوم اگر یک حساب قراردادی نباشد به طور پیشفرض خالی است.
-
-
### درخت تراکنشها {#transaction-trie}
برای هر بلوک یک تراکنش جداگانه وجود دارد که دوباره جفتهای `(کلید، مقدار)` را ذخیره میکند. یک مسیر در اینجا عبارت است از: `rlp(transactionIndex)` که نشان دهنده کلیدی است که با مقدار تعیین شده از سوی این مطابقت دارد:
-
-
```
if legacyTx:
value = rlp(tx)
@@ -303,19 +248,14 @@ else:
value = TxType | encode(tx)
```
-
اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
-
-
### درخت رسیدها {#receipts-trie}
هر بلوک درخت رسیدهای خود را دارد. یک `مسیر` در اینجا این است: `rlp(transactionIndex)`. `transactionIndex` شاخص آن در بلوکی است که در آن گنجانده شده است. درخت رسیدها هرگز به روز نمی شود. مشابه درخت تراکنشها، رسیدهای جاری و قدیمی وجود دارد. برای استعلام یک رسید خاص در درخت رسیدها، شاخص تراکنش در بلوک آن، بار رسید و نوع تراکنش مورد نیاز است. رسید برگشتی می تواند از نوع `رسیدی` باشد که به عنوان الحاق `TransactionType` و `ReceiptPayload` تعریف می شود یا می تواند از نوع `LegacyReceipt< باشد /0> که به صورت rlp([status, cumulativeGasUsed, logsBloom, logs])`. تعریف میشود.
اطلاعات بیشتر در این مورد را می توان در اسناد [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) یافت.
-
-
## اطلاعات بیشتر {#further-reading}
- [درخت مرکل پاتریشیا اصلاح شده – چگونه اتریوم یک حالت را ذخیره می کند](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd)
diff --git a/public/content/translations/fa/developers/docs/evm/index.md b/public/content/translations/fa/developers/docs/evm/index.md
index 940f960e366..6f617f165d6 100644
--- a/public/content/translations/fa/developers/docs/evm/index.md
+++ b/public/content/translations/fa/developers/docs/evm/index.md
@@ -8,7 +8,7 @@ lang: fa
## پیشنیازها {#prerequisites}
-برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و درخت مرکل.
+برای درک EVM آشنایی اولیه با اصطلاحات رایج در علوم کامپیوتر مانند [بایت](https://wikipedia.org/wiki/Byte)، [حافظه](https://wikipedia.org/wiki/Computer_memory) و یک [پشته](https://wikipedia.org/wiki/Stack_(abstract_data_type)) ضروری است. همچنین راحت بودن با مفاهیم رمزنگاری/بلاکچین مانند [توابع هش](https://wikipedia.org/wiki/Cryptographic_hash_function) و مفید خواهد بود[درخت مرکل](https://wikipedia.org/wiki/Merkle_tree).
## از دفتر کل تا ماشین حالات متناهی {#from-ledger-to-state-machine}
@@ -16,7 +16,7 @@ lang: fa
در حالی که اتریوم دارای رمزارز بومی خود (اتر) است که تقریباً بهطور کامل از قوانین شهودی مشابهی پیروی میکند، کارکرد بسیار قدرتمندتری را نیز ممکن میسازد: [قراردادهای هوشمند](/developers/docs/smart-contracts/). برای این ویژگی پیچیدهتر، قیاس پیچیدهتری نیز لازم است. به جای یک دفتر کل توزیع شده، اتریوم یک [ماشین حالات متناهی](https://wikipedia.org/wiki/Finite-state_machine) توزیعشده است. وضعیت اتریوم یک ساختار دادهی بزرگ است که نهتنها همه حسابها و موجودیها را در خود نگه میدارد، بلکه _وضعیت ماشین_ را نیز در خود جای میدهد که میتواند طبق مجموعهای از قوانین از پیش تعریفشده از بلوکی به بلوک دیگر تغییر کند و کد ماشینی دلخواه را اجرا کند. قوانین خاص تغییر حالت از بلوک به بلوک توسط EVM تعریف شده است.
-![نموداری که ساختار EVM را نشان میدهد](./evm.png) _نمودار برگرفته از [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+![نموداری که ساختار EVM را نشان میدهد](./evm.png) _نمودار برگرفته از[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## تابع گذار حالت اتریوم {#the-ethereum-state-transition-function}
From a3b235d6964968e5636fea6822f6c1ef02e75229 Mon Sep 17 00:00:00 2001
From: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
Date: Wed, 16 Oct 2024 20:23:58 -0700
Subject: [PATCH 6/9] fix: crowdin markdown syntax
---
.../translations/fa/enterprise/index.md | 54 ++++---------------
1 file changed, 11 insertions(+), 43 deletions(-)
diff --git a/public/content/translations/fa/enterprise/index.md b/public/content/translations/fa/enterprise/index.md
index f2c02abe4e6..736149c7c1d 100644
--- a/public/content/translations/fa/enterprise/index.md
+++ b/public/content/translations/fa/enterprise/index.md
@@ -13,16 +13,11 @@ lang: fa
- مدل های کسب و کار جدید و فرصت های خالق ارزش بسازید
- سازمان آنها به طور رقابتی آینده نگر است
-در سالهای اولیه، بسیاری از برنامههای بلاک چین سازمانی بر روی زنجیرههای بلاک چین یا کنسرسیوم سازگار با اتریوم با مجوز خصوصی ساخته شدند. امروزه، به لطف پیشرفتهای فناوری که توان عملیاتی بیشتر، هزینه تراکنش کمتر و حفظ حریم خصوصی را ممکن میسازد، اکثر برنامههای کاربردی سازمانی که از فناوری اتریوم استفاده میکنند بر روی شبکه اصلی اتریوم یا روی
-زنجیره لایه 2
-
-
+در سالهای اولیه، بسیاری از برنامههای بلاک چین سازمانی بر روی زنجیرههای بلاک چین یا کنسرسیوم سازگار با اتریوم با مجوز خصوصی ساخته شدند. امروزه، به لطف پیشرفتهای فناوری که توان عملیاتی بیشتر، هزینه تراکنش کمتر و حفظ حریم خصوصی را ممکن میسازد، اکثر برنامههای کاربردی سازمانی که از فناوری اتریوم استفاده میکنند بر روی شبکه اصلی اتریوم یا روی [زنجیره لایه 2](/layer-2) ساخته میشوند.
## منابع {#enterprise-resources}
-
-
### بیشتر بخوانید {#further-reading}
منابع غیر فنی برای درک اینکه چگونه کسب و کارها می توانند از اتریوم بهره ببرند
@@ -31,8 +26,6 @@ lang: fa
- [گزارش آمادگی تجاری سال 2023 اتحادیه اتریوم](https://entethalliance.org/eea-ethereum-business-readiness-report-2023/) - _پتانسیل و قابلیتهای اتریوم عمومی و اکوسیستم گستردهتر اتریوم برای کسبوکارها را بررسی میکند._
- [_اتریوم برای کسب و کار_ نوشته پل برادی](https://www.uapress.com/product/ethereum-for-business/)، _یک راهنمای ساده به زبان انگلیسی برای موارد کاربردی است که بازدهی از مدیریت دارایی تا پرداختها و زنجیرههای تأمین را ایجاد میکند._
-
-
### سازمانها {#organizations}
برخی تلاشهای مشترک برای مورد پسند کردن اتریوم سازمانی توسط سازمانهای مختلف انجام شده است
@@ -41,12 +34,8 @@ lang: fa
- [شورای جهانی تجارت بلاکچین (GBBC)](https://www.gbbc.io/) - اتحادیهای صنعتی برای اکوسیستم فناوری بلاکچین است. با جلب توجه سیاستگذاران و نظارتکنندگان، برگزاری رویدادها و بحثهای گسترده، و انجام تحقیقات، GBBC به ترویج بیشتر بلاکچین برای ایجاد جوامعی امنتر، عادلانهتر و کارآمدتر متعهد است.
-
-
## منابع توسعه دهنده سازمانی {#enterprise-developer-resources}
-
-
### محصولات و خدمات {#products-and-services}
- [4EVERLAND](https://www.4everland.org/) - _ خدمات RPC و APIها و ابزارهایی را برای میزبانی برنامههای غیرمتمرکز و فعال کردن ذخیرهسازی غیرمتمرکز در اتریوم ارائه میدهد_
@@ -69,29 +58,20 @@ lang: fa
- [Unbright](https://unibright.io/) - _تیمی از متخصصان، معماران، توسعه دهندگان و مشاوران بلاک چین با بیش از 20 سال تجربه در فرآیندهای تجاری و یکپارچه سازی_
- [Zeeve](https://www.zeeve.io/) - _مجموعه ای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساخت و API برای برنامه های Web3 سازمانی ارائه می دهد._
-
-
### ابزار و کتابخانه ها {#tooling-and-libraries}
- [Baseline Project](https://www.baseline-protocol.org/) - _مجموعه ای از ابزارها و کتابخانه ها است که به شرکت ها کمک می کند تا فرآیندهای تجاری پیچیده و چند جانبه و گردش کار را با حفظ حریم خصوصی هماهنگ کنند و در عین حال داده ها را در سیستم های ثبت مربوطه نگهداری کنند. این استاندارد دو یا چند ماشین حالت را قادر میسازد تا با استفاده از یک شبکه بهعنوان یک چارچوب مرجع مشترک، سازگاری دادهها و تداوم گردش کار را به دست آورند و حفظ کنند._
- [Chainlens](https://www.chainlens.com/) - _SaaS و پلتفرم داده و تجزیه و تحلیل بلاک چین اولیه از آزمایشگاههای Web3_
- [Ernst & Young's 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _برنامه ای برای انتقال برنامه های ERC20، ERC721 و ERC1155 با دانش صفر، با استفاده از یک جمعبندی خوش بینانه_
-- [Truffle Suite](https://trufflesuite.com) - _مجموعه توسعه بلاک چین (ترافل، گاناش، دریزل)_
-
-
### راه حل های مقیاس پذیری {#scalability-solutions}
-اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/layer-2) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
-
-
+اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/لایه دوم) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
## برنامههای کاربردی سازمانی در شبکه اصلی اتریوم فعال میشوند {#enterprise-live-on-mainnet}
در اینجا برخی از برنامههای کاربردی سازمانی که بر روی شبکه عمومی اتریوم و لایه دوم توسط شرکتهای سنتی غیربلاک چین ساخته شدهاند، آورده شده است.
-
-
### پرداختها {#payments}
- [مرورگر بریو (Brave)](https://basicattentiontoken.org/) - _به کاربران برای توجه آنها به تبلیغات، بیسیک اتنشن توکن (BAT) پرداخت میکند و کاربران نیز میتوانند از طریق BAT برای حمایت از ناشران پرداخت انجام دهند_
@@ -99,13 +79,11 @@ lang: fa
- [اتریوم ادز](https://ethereumads.com/) - _به اپراتورهای وبسایت اجازه میدهد فضای تبلیغاتی را بفروشند و از طریق اتریوم پول دریافت کنند_
- [hCaptcha](https://www.hcaptcha.com/) - _سیستم CAPTCHA پیشگیری از ربات که به اپراتورهای وبسایت برای کارهای انجام شده توسط کاربران برای برچسب زدن دادهها برای یادگیری ماشین پرداخت میکند. اکنون توسط Cloudflare مستقر شده است_
- [Opera MiniPay](https://www.opera.com/products/minipay) - _پرداختهای موبایلی را برای مردم آفریقا از طریق کیف پول غیرسرپرستی در دسترستر و ایمنتر میکند و از شماره تلفنها برای تراکنش آسان_ استفاده میکند
-- [Roxpay](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
-- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p/13560384) - _پرداختهای بین المللی با استیبل کوین_
+- [Roxpay ](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
+- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p /13560384) - _پرداختهای بین المللی با استیبل کوین_
- [Toku](https://www.toku.com/) - _دستمزد، مدیریت کمک هزینه توکنی، رعایت مالیات، استخدام محلی، مزایا و & راهحلهای منابع انسانی توزیع شده_
- [Xerof](https://www.xerof.com/) - _پرداختهای سریع و ارزان بینالمللی (برون مرزی) B2B را تسهیل میکند_
-
-
### امور مالی {#finance}
- [ABN AMRO](https://tokeny.com/tokeny-fuels-abn-amro-bank-in-tokenizing-green-bonds-on-polygon/) - _با توکنی، مسیرهای سبز توکن شده_
@@ -117,8 +95,6 @@ lang: fa
- [Societe Generale FORGE](https://www.sgforge.com/product/bonds/) - _صدور مسیر_
- [Taurus](https://www.taurushq.com/) - _ضمانتهای توکن شده صادر میکند_
-
-
### توکنیزه کردن دارایی {#tokenization}
- [AgroToken](https://agrotoken.io/en/) - _توکنسازی و معامله کالاهای کشاورزی_
@@ -131,14 +107,12 @@ lang: fa
- [Fasset](https://www.fasset.com/) - _پلتفرمی برای پشتیبانی از زیرساختهای پایدار_
- [نوری](https://nori.com/) - _زیرساخت بازار منبع باز برای امکان اندازهگیری و کسب درآمد از فعالیتهای پروژههای حذف کربن_
- [پراپی (Propy)](https://propy.com/) - _پلتفرمی برای خودکارسازی معاملات املاک مسکونی با قراردادهای هوشمند_
-- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند._
-- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد
- - [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات
- - [تالو (Thallo)](https://www.thallo.io/) - _پلتفرمی برای ادغام اعتبارات کربن دیجیتال در معاملات تجاری_
+- [RealT](https://realt.co/) - _سرمایهگذاران در سرتاسر جهان میتوانند در بازار املاک و مستغلات ایالات متحده از طریق موارد کاملاً منطبق، کسری و مالکیت توکن شده خرید کنند. _
+- [روبی (Rubey)](https://www.rubey.be/) - _پلتفرمی که هنرهای سطح بالا را توکنیزه میکند تا آن را برای سرمایهگذاران خرد در دسترس قرار دهد_
+- [سوارم (Swarm)](https://swarm.com/) - _پلتفرمی متمرکز بر دیجیتالی کردن و معامله داراییهای دنیای واقعی به روشی مطابق با مقررات_
+- [تالو (Thallo)](https://www.thallo.io/) - _پلتفرمی برای ادغام اعتبارات کربن دیجیتال در معاملات تجاری_
- [Tokenchampions](https://tokenchampions.com/) - _حقوق تصویر بازیکنان فوتبال اروپا را توکنیزه میکند_
-
-
### ثبت دادهها {#notarization-of-data}
- [ ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _خبرگزاری ایتالیایی با اخبار جعلی مبارزه میکند و خوانندگان را قادر میسازد تا منشأ اخبار را با ضبط آنها در شبکه اصلی تأیید کنند_
@@ -150,11 +124,9 @@ lang: fa
- [وریزون](https://decrypt.co/46745/verizon-news-press-releases-ethereum-full-transparency) - _گزارشهای مطبوعاتی را در اتریوم برای اطمینان از مسئولیت پذیری و اعتماد شرکت نشان میدهد_
- [ولف تون](https://www.mef.net/edge-view-blog/automated-secure-timely-sla-reporting-is-finally-a-reality/) - _توسط MEF و مدیریت Sage گزارشدهی توافقنامه سطح خدمات بین شرکتهای مخابراتی را خودکار میکند_
-
-
### زنجیره تامین {#supply-chain}
-- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using-ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
+- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using -ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
- [کارگوایکس](https://cargox.io/) - _ارائهدهنده بارنامه الکترونیکی و انتقال اسناد برای حمل و نقل_
- [Circularize](https://www.circularise.com/) - _یک راهحل ردیابی سرتاسر برای مواد خام ساخته شده در محصولات است_
- [مدیر قرارداد EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _شرکتها را قادر میسازد تا در جریان کاری تدارکات، صدور RFQ، قراردادها، سفارشها خرید و فاکتورها در شبکهای از شرکای تجاری شرکت کنند_
@@ -164,23 +136,19 @@ lang: fa
- [TradeTrust](https://www.tradetrust.io/) - _بارنامههای الکترونیکی (eBLs) را برای حمل و نقل بین المللی تأیید میکند_
- [Transmute](https://transmute.industries/) - _پلتفرم تبادل داده برای معامله جهانی؛ از تراکنشهای با هویت غیرمتمرکز در اتریوم_ پشتیبانی میکند
-
-
### بیمه {#insurance}
- [آربول (Arbol)](https://www.arbolmarket.com/) - _بیمه پارمتریک برای پوشش خطرات مربوط به آب و هوا_
- [Etherisc](https://etherisc.com/) - _بیمه غیرمتمرکز برای انواع خطرات_
- [Nayms](https://www.nayms.com/) - _یک فضای دیجیتال برای ایجاد برنامههای بیمه، افزایش و معامله سرمایه، نوشتن ریسک و ریلهای پرداخت برای تراکنشهای حق بیمه و ادعا، ساخته شده با AON_
-
-
### هویت، اعتبار و گواهینامه {#credentials}
- [BCdiploma](https://www.bcdiploma.com/) - _دیپلمها، گواهیها و مدارک خرد را دیجیتالی و تأیید میکند_
- [مدارک هایلند](https://www.hylandcredentials.com) - _دیپلمهای دیجیتال و سایر مدارک تحصیلی، مجوزها و گواهینامهها_
- [برنامه اقامت دیجیتال پالائو](https://rns.id/) - _به شهروندان جهانی این امکان را میدهد که کارت شناسایی قانونی صادر شده توسط دولت پالائو داشته باشند_
- - [Spherity](https://www.spherity.com/) - _راهحلهای مدیریت هویت دیجیتال را برای ایجاد اعتماد دیجیتال در اکوسیستمها، با تمرکز بر هویتهای غیرمتمرکز و اعتبار قابل تأیید ارائه میدهد_
-- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
+- [Spherity](https://www.spherity.com/) - _راهحلهای مدیریت هویت دیجیتال را برای ایجاد اعتماد دیجیتال در اکوسیستمها، با تمرکز بر هویتهای غیرمتمرکز و اعتبار قابل تأیید ارائه میدهد_
+- [Zug Digital ID](https://ezug.ch/en/) - _یک سیستم هویت مبتنی بر بلاک چین در سوئیس است که به ساکنان دسترسی دیجیتالی به خدمات دولتی و عملکردهای پشتیبانی مانند قرض گرفتن دوچرخه الکترونیکی و رأی گیری شهرداری ارائه میدهد_
### سرگرمی، NFT و وفاداری
From e29f9a7db9eefbe1d8efba7b90eb192a0f740fe4 Mon Sep 17 00:00:00 2001
From: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
Date: Wed, 16 Oct 2024 20:24:07 -0700
Subject: [PATCH 7/9] revert: private enterprise import
---
.../fa/enterprise/private-ethereum/index.md | 26 -------------------
1 file changed, 26 deletions(-)
delete mode 100644 public/content/translations/fa/enterprise/private-ethereum/index.md
diff --git a/public/content/translations/fa/enterprise/private-ethereum/index.md b/public/content/translations/fa/enterprise/private-ethereum/index.md
deleted file mode 100644
index 5992f822f04..00000000000
--- a/public/content/translations/fa/enterprise/private-ethereum/index.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: اتریوم خصوصی برای تشکیلات سازمانی
-description: منابعی برای اپلیکیشن تشکیلات سازمانی بر بستر بلاک چین های خصوصی اتریوم.
-lang: fa
----
-
-# اتریوم خصوصی برای تشکیلات سازمانی {#private-ethereum-for-enterprise}
-
-اپلیکیشن های بلاک چین تشکیلات سازمانی میتوانند بر روی شبکه اصلی اتریوم بدون مجوز عمومی یا بر روی بلاک چین های خصوصی که مبتنی بر فناوری اتریوم هستند ساخته شوند. برای اطلاعات بیشتر در مورد ساخت اپلیکیشن بر بستر شبکه عمومی اصلی اتریوم، به [شبکه اصلی اتریوم برای شرکتها](/enterprise/) مراجعه کنید.
-
-## منابع توسعه دهندگان برای تشکیلات سازمانی اتریوم {#developer-resources-private-enterprise-ethereum}
-
-### سازمانها {#organisations}
-
-برخی از تلاشهای مشترک برای مورد پسند کردن تشکیلات سازمانی اتریوم توسط سازمانهای مختلف انجام شده است:
-
-- [اتحادیه تشکیلات سازمانی اتریوم](https://entethalliance.org/) EEA سازمانها را قادر میسازد تا فناوری اتریوم را در عملیات تجاری روزانه خود بپذیرند و از آن استفاده کنند. ما اکوسیستم اتریوم را برای ایجاد فرصتهای تجاری جدید، تشویق به پذیرش صنعت، و یادگیری و همکاری با یکدیگر توانمند میکنیم.
-- [Hyperledger](https://hyperledger.org) _Hyperledger یک تلاش مشترک منبع باز است که برای پیشرفت فناوریهای بلاک چین بینصنعتی ایجاد شده است. این یک همکاری جهانی است که توسط بنیاد لینوکس میزبانی می شود، از جمله رهبران امور مالی، بانکداری، اینترنت اشیا، زنجیره تامین، تولید و فناوری. این بنیاد پروژههایی در خود دارد که با پشته اتریوم کار میکنند، از جمله [Besu](https://www.hyperledger.org/use/besu)._
-
-### پروتکل و زیرساخت {#protocol-and-infrastructure}
-
-- [Chainstack](https://chainstack.com/) _پلتفرم میان ابری و چند پروتکلی بهعنوان سرویسی که به کسبوکارها اجازه میدهد تا به سرعت، استقرار و مدیریت شبکه ها و سرویس های غیرمتمرکز را ایجاد کنند_
-- [Clearmatics Autonity](https://www.clearmatics.com/about/) _مجموعه پروتکلهایی که پروتکلهای p2p را پیادهسازی میکند و اپلیکیشن و زیرساخت کلاینت را ارائه میکند_
-- [هایپرلجر بسو](https://www.hyperledger.org/use/besu) _کاربر منبع باز اتریوم که تحت مجوز Apache 2.0 توسعه یافته و به زبان جاوا نوشته شده است که شامل چندین الگوریتم اجماع از جمله اثبات کار و اثبات قدرت است (IBFT، IBFT 2.0، Ethash و Clique). طرح های مجوز جامع آن به طور خاص برای استفاده در یک محیط کنسرسیوم طراحی شده است._
-- [Kaleido](https://kaleido.io/) _پلتفرم فول-استک برای ساخت و اجرای اکوسیستمهای تشکیلات اقتصادی ترکیبی میان ابری_
-- [Zeeve](https://www.zeeve.io/) _مجموعهای از محصولات و ابزارها را برای ساخت بر روی اتریوم، همچنین زیرساختها و APIهای سازمانی برنامه های Web3 ارائه میکند_
From 564ec8f4c6b360778a3f03fa279d0f2edb10c148 Mon Sep 17 00:00:00 2001
From: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
Date: Wed, 16 Oct 2024 20:25:35 -0700
Subject: [PATCH 8/9] fix: markdown syntax
---
public/content/translations/fa/enterprise/index.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/public/content/translations/fa/enterprise/index.md b/public/content/translations/fa/enterprise/index.md
index 736149c7c1d..5a0d2851a1c 100644
--- a/public/content/translations/fa/enterprise/index.md
+++ b/public/content/translations/fa/enterprise/index.md
@@ -115,7 +115,7 @@ lang: fa
### ثبت دادهها {#notarization-of-data}
-- [ ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _خبرگزاری ایتالیایی با اخبار جعلی مبارزه میکند و خوانندگان را قادر میسازد تا منشأ اخبار را با ضبط آنها در شبکه اصلی تأیید کنند_
+- [ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _خبرگزاری ایتالیایی با اخبار جعلی مبارزه میکند و خوانندگان را قادر میسازد تا منشأ اخبار را با ضبط آنها در شبکه اصلی تأیید کنند_
- [Breitling](https://www.coindesk.com/breitling-arianee-all-new-watches-ethereum) - _منشأ و تاریخچه تعمیر را در اتریوم ثبت میکند_
- [BRØK](https://www.xn--brk-1na.no/) - _پلتفرم جداول کپ برای شرکتهای ثبت نشده در بورس عمومی توسط دولت نروژ ارائه شده است _
- [گواهی](https://certifaction.com/) - _امضاهای الکترونیکی معتبر قانونی با حریم خصوصی-by-design_
From f984a40d212e07e503ce079acb4e9ed96ab96c5b Mon Sep 17 00:00:00 2001
From: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
Date: Wed, 16 Oct 2024 22:34:19 -0700
Subject: [PATCH 9/9] fix: crowdin markdown syntax
---
public/content/translations/fa/enterprise/index.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/public/content/translations/fa/enterprise/index.md b/public/content/translations/fa/enterprise/index.md
index 5a0d2851a1c..ea23cc48c54 100644
--- a/public/content/translations/fa/enterprise/index.md
+++ b/public/content/translations/fa/enterprise/index.md
@@ -61,12 +61,12 @@ lang: fa
### ابزار و کتابخانه ها {#tooling-and-libraries}
- [Baseline Project](https://www.baseline-protocol.org/) - _مجموعه ای از ابزارها و کتابخانه ها است که به شرکت ها کمک می کند تا فرآیندهای تجاری پیچیده و چند جانبه و گردش کار را با حفظ حریم خصوصی هماهنگ کنند و در عین حال داده ها را در سیستم های ثبت مربوطه نگهداری کنند. این استاندارد دو یا چند ماشین حالت را قادر میسازد تا با استفاده از یک شبکه بهعنوان یک چارچوب مرجع مشترک، سازگاری دادهها و تداوم گردش کار را به دست آورند و حفظ کنند._
-- [Chainlens](https://www.chainlens.com/) - _SaaS و پلتفرم داده و تجزیه و تحلیل بلاک چین اولیه از آزمایشگاههای Web3_
+- [Chainlens](https://www.chainlens.com/) - _SaaS و پلتفرم داده و تجزیه و تحلیل بلاک چین اولیه از آزمایشگاههای Web Labs_
- [Ernst & Young's 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _برنامه ای برای انتقال برنامه های ERC20، ERC721 و ERC1155 با دانش صفر، با استفاده از یک جمعبندی خوش بینانه_
### راه حل های مقیاس پذیری {#scalability-solutions}
-اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/لایه دوم) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
+اکثر برنامههای بلاک چین جدید بر روی زنجیرههای [لایه 2](/layer-2) ساخته میشوند. لایه 2 مجموعهای از فناوریها یا سیستمها هستند که روی اتریوم (لایه 1) اجرا میشوند، ویژگیهای امنیتی را از لایه 1 به ارث میبرند و ظرفیت پردازش تراکنش بیشتر (پهنای باند)، هزینههای تراکنش کمتر (هزینه عملیاتی) و تایید تراکنشهای سریعتری نسبت به لایه 1 ارائه میکنند. راه حل های مقیاس بندی لایه 2 توسط لایه 1 ایمن شده اند، اما برنامه های بلاک چین را قادر می سازند تا کاربران یا اقدامات یا داده های بیشتری را نسبت به لایه 1 مدیریت کنند. بسیاری از آنها از پیشرفتهای اخیر در رمزنگاری و اثبات دانش صفر (ZK) برای به حداکثر رساندن عملکرد و امنیت استفاده میکنند و برخی از آنها سطح بیشتری از حریم خصوصی را ارائه میدهند.
## برنامههای کاربردی سازمانی در شبکه اصلی اتریوم فعال میشوند {#enterprise-live-on-mainnet}
@@ -80,7 +80,7 @@ lang: fa
- [hCaptcha](https://www.hcaptcha.com/) - _سیستم CAPTCHA پیشگیری از ربات که به اپراتورهای وبسایت برای کارهای انجام شده توسط کاربران برای برچسب زدن دادهها برای یادگیری ماشین پرداخت میکند. اکنون توسط Cloudflare مستقر شده است_
- [Opera MiniPay](https://www.opera.com/products/minipay) - _پرداختهای موبایلی را برای مردم آفریقا از طریق کیف پول غیرسرپرستی در دسترستر و ایمنتر میکند و از شماره تلفنها برای تراکنش آسان_ استفاده میکند
- [Roxpay ](https://www.roxpay.ch/) - _صورتحساب و دارایی پرداخت به ازای استفاده را خودکار میکند_
-- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p /13560384) - _پرداختهای بین المللی با استیبل کوین_
+- [SAP مرکز ارز دیجیتال](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p/13560384) - _پرداختهای بین المللی با استیبل کوین_
- [Toku](https://www.toku.com/) - _دستمزد، مدیریت کمک هزینه توکنی، رعایت مالیات، استخدام محلی، مزایا و & راهحلهای منابع انسانی توزیع شده_
- [Xerof](https://www.xerof.com/) - _پرداختهای سریع و ارزان بینالمللی (برون مرزی) B2B را تسهیل میکند_
@@ -126,7 +126,7 @@ lang: fa
### زنجیره تامین {#supply-chain}
-- [بیرا پرونی](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using -ey-opschain-traceability) _NFTها را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
+- [Birra Peroni](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using-ey-opschain-traceability) _NFTs را برای هر دسته جدید آبجو ایجاد میکند که باعث میشود دید و کارایی بیشتری در سراسر زنجیره تامین خود داشته باشد_
- [کارگوایکس](https://cargox.io/) - _ارائهدهنده بارنامه الکترونیکی و انتقال اسناد برای حمل و نقل_
- [Circularize](https://www.circularise.com/) - _یک راهحل ردیابی سرتاسر برای مواد خام ساخته شده در محصولات است_
- [مدیر قرارداد EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _شرکتها را قادر میسازد تا در جریان کاری تدارکات، صدور RFQ، قراردادها، سفارشها خرید و فاکتورها در شبکهای از شرکای تجاری شرکت کنند_